Publish docker images

[ravishivt]

In #2181, there was discussion on publishing puppeteer-compatible docker images in Cirrus CI. This would be very convenient to have automated images built and readily available.

Publishing to GCR through Google's official google-container repository would make the most sense, given this is a Google project. Docker Hub is also an option.

[aslushnikov]

@ravishivt what do you want to be in the image? The one we currently use for Cirrus is just a set of dependencies to make Chromium work: Dockerfile.linux. Is it valuable enough for you?

+cc @fkorotkov:

[ravishivt]

Ideally, the Dockerfile would match what's recommended in the official docs. That looks to have more best practices followed, uses node-slim for a smaller image, and actually has puppeteer installed and ready to go.

My thought is to build the doc's Dockerfile in an automated process (e.g. Cirrus) and push it to GCR.

[ebidel]

@ravishivt how would you want to run your pptr scripts against the container? The current dockerfile cats the file and passes it in like this:

docker run -i --rm --cap-add=SYS_ADMIN \
   --name puppeteer-chrome puppeteer-chrome-linux \
   node -e "`cat yourscript.js`"

Which is not great IMO. Maybe we can do this using a mount point instead. Not sure the best practice for "passing in" files to a docker container.

[ravishivt]

@ebidel I agree with you that mount points are more common. However, the Dockerfile wouldn't specify those volume mounts because it can only mount what's available at build time, not run time. More common than the `cat yourscript.js` solution is to specify a volume mount at container runtime:

docker run -i --rm --cap-add=SYS_ADMIN \
   --name puppeteer-chrome puppeteer-chrome-linux \
   --volume ${PWD}/yourscript.js:/ \
   node -e /yourscript.js

btw, my (selfish) goal is to create a Dockerfile for rendertron which would extend the official puppeteer image that I'm requesting here, i.e. FROM puppeteer:latest. That way I don't have to build puppeteer and rendertron in one container. So I'm not planning to mount/run custom scripts. See GoogleChrome/rendertron#93 (comment) for a sample Dockerfile that would extend puppeteer's image once it exists.

[WeihanLi]

Is there an official docker image for puppeteer available now?If not, is there a plan?

[c5c86a]

@aslushnikov having an image that is just the file Dockerfile.linux is very valuable as :

1. we don't have to wait for apt
2. we don't have to deal with sandbox in the CI environment

Anyone can push such image but the question is if anyone will maintain it.

[WeihanLi]

I've built a docker image based on the docker.linux here,hope anyone would like to use

[aslushnikov]

@nicosmaris we currently use Docker images to run tests on Cirrus CI: Dockerfile.linux. It is guaranteed that tip-of-tree Puppeteer works with this image.

[h2non]

Having an official Debian-based Docker image coupled to the specific Chromium version that is guaranteed to work properly with each specific Puppeteer release would be paramount.

Currently, it's quite difficult to get it working with the compatible Chromium version in major Linux distribution unless you build Chromium from source.

[ericis]

Yes, an official distribution of maintained puppeteer docker images in a docker registry would we awesome! I understand that the puppeteer project itself uses Docker.linux, but I believe the OP was requesting a NEW, official puppeteer project that publishes a few flavors of docker images for use by the community.

[ericis]

@WeihanLi thanks for sharing the image. Unfortunately, many companies won't be able to use a personal image like this purely based on risk. This would be mitigated by an official docker image from the project maintainers.

[WeihanLi]

@ericis Yeah, totally agree, hope for an official puppeteer docker image also

[steren]

I would like to revive this Feature Request

The use cases I can identify for an official base image are:

1. Running Puppeteer on CI systems. CI systems have standardized on containers for environment customization (e.g. gitHub Actions, Google Cloud Build...)
2. Running Puppeteer on container-based execution platforms (Google Cloud Run, Kubernetes , fly.io...)
3. Running a specific version of Puppeteer on a local dev machine without having to install the exact list of needed dependencies (e.g. exact version of Chrome)

Regarding 2.: I am the Product Manager for Google Cloud Run, and I would like to make it easier for Cloud Run developers to use Puppeteer. Today, the issue is that developers have to google for a Dockerfile and copy paste it. Personally, I had to try 2 different Dockerfiles before finding one that actually worked.

It would be helpful if instead of copy pasting a Dockerfile, developers could build on top of an official container base image.
To achieve that, they would only need to use FROM puppeteer-chrome at the top of their Dockerfiles.
They could even directly run the container image if they do not need to customize its content, e.g. docker run --cap-add=SYS_ADMIN puppeteer-chrome index.js

At minimum, I would expect a Debian base image tagged for every published puppeteer versions. On top of that, a latest tag would point at the latest version. I would also recommend an alpine-based container image.

A version with Chromium would be a great start, and we can imagine later a version with Firefox (as requested in #7242)

Regarding hosting the container image, the obvious choice is DockerHub which is very popular but comes with rate limits. The team could also consider offering a public image in Google Cloud Artifact Registry (which is the successor of Container Registry).

[andyearnshaw]

I'm interested in this too, but I think that some of the assumptions made around mounting or mapping volumes is unnecessary. I agree with what @steren said, you could run the container directly and then connect to it using puppeteer.connect(), in a similar vein to browserless/chrome:

docker run -p 3000:3000 puppeteer/chrome:latest

Chromium is now running, so we can connect. Our script (run locally, not inside the container) runs as normal:

const browser = await puppeteer.connect({ browserWSEndpoint: 'ws://localhost:3000' });

I've also added #8272 which would support launching Chromium in the docker image directly. I think this would just make the whole approach to using Puppeteer in a docker environment completely seamless.

[stale]

We're marking this issue as unconfirmed because it has not had recent activity and we weren't able to confirm it yet. It will be closed if no further activity occurs within the next 30 days.

[meyfa]

Ping, I would still very much like for this to exist :)

[moltar]

Looks like the official Docker image is now available via #8315, big thanks to @OrKoN!

That should unlock the possibility of releasing the official image as part of the general release cycle.

I think publishing to GitHub image registry should be enough, as Docker Hub requires a subscription these days.

Instructions are very straightforward: https://docs.github.com/en/actions/publishing-packages/publishing-docker-images#publishing-images-to-github-packages

[moltar]

Ha! It looks like this is already in progress and/or done!

https://github.com/puppeteer/puppeteer/blob/main/.github/workflows/publish-docker.yml

[OrKoN]

Yeah, we are testing the automatic publishing right now. The image should be available soon!

[steren]

Thanks, for completeness, can you capture here the URL of the published docker image?

Note that DockerHub would probably still be the de-facto place for developers to look for this image.

[moltar]

@steren https://github.com/puppeteer/puppeteer/pkgs/container/puppeteer

[OrKoN]

We will probably only publish to GitHub registry for now. Let me keep this issue opened as I am actually still working on the docs update.

[andyearnshaw]

Great news on getting the package published. I have a small suggestion: can the published package be changed from puppeteer/puppeteer to puppeteer/chrome? This will leave room for puppeteer/firefox in the future.

Unless the plan is to have both browsers in the same image?

[OrKoN]

Currently, we don't have plans for publishing the image containing Firefox as the Firefox support is still experimental. Perhaps the Mozilla team might want to publish an image containing Firefox later. So if that happens, we would likely to install all supported browsers into puppeteer/puppeteer image and create browser-specific images like puppeteer/puppeteer-chrome etc.