Now obviously Google has a bit of an advantage here what with Chrome being their own tech but there are so many blogs out there with people talking about complicated Docker solutions just to run headless Chrome in the cloud.
It would be great if we could get a solution where we could run Puppeteer in much the same way, or allow web apps to run Chrome without having to be inside Docker and we could manage a pool of Chromes without having to manage Docker as well.57 votes
Headless Chrome requires some libraries to be installed that aren’t available in the containers we use in Linux consumption. You can, however, run your function app in a Docker container with the libraries installed. Custom containers are currently supported in the Premium and App Service plans. Take a look at this example from a community member of a Dockerfile with the dependencies: https://github.com/estruyf/azure-function-node-puppeteer/blob/master/Dockerfile
Requesting the ability to be able to schedule Azure function runtime updates from the portal. At present the runtime updates are pushed by Microsoft at random times which could impact service availability and customer experience. We need the ability to be able to either define a schedule for the function runtime updates or be able to manually perform those updates at a time that is convenient to the customer.1 vote
This is a great idea, however we have no plans to implement it in the near future.
Keep the votes coming!
Azure Functions PM Team
Right now the sandbox applies to azure function apps even when they're running in docker. Docker is the sandbox in that case. Further, things like System.Drawing.Common aren't effected on Linux the same as they are on Windows so there should be no issue requiring the sandbox to interfere.
So Azure Functions should disable the sand-boxing when running in docker entirely.
Failing that, it should disable the System.Drawing.Common limitations if running on Linux.1 vote
- Don't see your idea?