Lighthouse-ci: Define a standard docker image for Lighthouse

[paulirish]

I believe this means upstreaming the work done here:

• https://github.com/GoogleChromeLabs/gulliver/tree/master/lighthouse_machine
• https://github.com/ebidel/lighthouse-ci/tree/master/builder

---

The lighthouse service within should be easily accessible over HTTP.
I kind of preferred the basic REST api within lighthouse_machine, but perhaps we should chat more about the API.

@ebidel wanna take a first whack at this?

[ebidel]

OH hai, missed this. I can take this on. The work is mostly done.

FWIW, the REST APIS for both projects are the same, the only diff being POST vs. GET. We could support both which is what this was doing for a bit.

There are couple of things we need to decide on:

1. Where do we want the Dockerfile/code to live?
2. Do we want to put it up on Dockerhub. Not sure everything that entails.
3. Define a release/update plan for 2. Again, not sure how versioning and stuff works with Docker.
4. Do we include running a web service as part of this. Something for people to "try it"?
5. probably should work great from a REST endpoint and CLI invocation.
6. Consider upstream the logging in https://github.com/ebidel/lighthouse-hue/blob/master/server.js#L59 or use @paulirish's piping method to see realtime logs as LH audits. Maybe provide that as an option rather than a default.

Anything else?

[amedina]

A couple of comments:

1. Google exists as an organization in docker hub: https://hub.docker.com/u/google/; that may be a good place for publishing it
2. Including a web service for people to "try it" would be nice, but optional. An easier approach would just to provide easy instructions for people to try locally

[ebidel]

I've added 6 to lighthouse-ci. If you use the GET rest endppiont, you'll see logs stream from LH. Once the run is complete, it redirects to the report. Either json/html depending on what you specify.

ex: https://builder-dot-lighthouse-ci.appspot.com/ci?format=html&key=123&url=https://example.com/

[paulirish]

Where do we want the Dockerfile/code to live?

a root subfolder in this lighthouse repo

Do we want to put it up on Dockerhub. Not sure everything that entails.
Define a release/update plan for 2. Again, not sure how versioning and stuff works with Docker.

we can do this all later when we're ready.

Do we include running a web service as part of this. Something for people to "try it"?
probably should work great from a REST endpoint and CLI invocation.

IMO no. starts to confuse the product story.

Consider upstream the logging in ebidel/lighthouse-hue:server.js@master#L59 or use @paulirish's piping method to see realtime logs as LH audits. Maybe provide that as an option rather than a default.

I've added [this] to lighthouse-ci. https://github.com/ebidel/lighthouse-ci/commit/cad9d02354c0ee484081506e81ddd605759b5e05

Sweet! nice one.

[ebidel]

I'm going to research the smallest image that makes everything cook.

[ebidel]

Here's the original:

FROM ubuntu:latest
lighthouse_ci            latest              9228e6afd36d        2 minutes ago       864MB

Doing some much needed pruning and using node 6 gets to:

FROM node:6-slim
lighthouse_ci            latest              909b49601a61        29 seconds ago       703MB

8 is actually smaller and has the added benefit of new es6 features and faster v8:

FROM node:8-slim
lighthouse_ci            latest              628602d20bcb        About a minute ago   692MB

FROM:node9-alpine would be even small but Alpine ships a Chrome 61 package. We need Chrome 63+ to work well with headless Chrome.

Still looking at more stuff...

[frvge]

I'd like to request an official lighthouse-cli in Docker that doesn't run as a webservice, but more as a commandline tool. We currently have https://github.com/MatthiasWinkelmann/lighthouse-chromium-alpine-docker and there are others too, but they all stop working regularly due to various upgrades on lighthouse's side it seems.

Would that fit this issue, or should I create a new one?

[ebidel]

The plan is to support both :)

[ebidel]

This is mostly done with the changes in https://github.com/ebidel/lighthouse-ci/commit/a0daba66d590e72af74282449e70f38694217b2b and covers all the requirements listed in https://github.com/GoogleChrome/lighthouse/issues/3715#issuecomment-342364544.

Other key things:

• supports running the container as a CLI or lighthouse as a web service (e.g. send a url to endpoint, get a score)
• supports headless and headlful chrome (via xvfb). There are two Dockerfiles for each. Headless is default.
• Image is smaller than before. ~690MB.

The new README covers all the goods.

Left to do: upstream the work here and ship a blessed image on Dockerhub.

[frvge]

@ebidel , first of all, thanks for your efforts.

I seem to be unable to use the --save-artifacts and --save-assets because the entrypoint is already forcing an output path of stdout and lighthouse hits an error if it's specified multiple times.

If I uncomment the WORKDIR, remove the predefined --output-path=stdout in the entrypoint, do a manual build to get the changes in my image, and then use the "node" user in the docker run I can get the behavior that I need:

docker run -u="node" -v $(pwd)/reports:/home/chrome/reports -it --rm --cap-add=SYS_ADMIN lighthouse_ci --output=json --output-path=./myrun1 --save-artifacts --save-assets  https://www.mysite.com

gives me the wanted data in my local ./reports folder \o/

The chrome user can't write to / (default workdir, so I uncomment that again in the Dockerfile)
The user that seems to create folders during the creation of volumes seems to be "node", so "chrome" also can't write to folders created by "node" even if it's in chrome's home folder. That's why I'm specifying -u="node". Maybe there are other ways around it?

[ebidel]

Thanks for the feedback @frvge. I like the simplicity of piping a report to a file b/c it cuts back on a lot of the Docker noise :) Of course it makes things less flexible.

I think we might want to make volumes work, especially if artifacts and assets need to be saved. Is that the primary reason why stdout isn't enough? I think all the other flags should work.

docker run -it --rm --cap-add=SYS_ADMIN lighthouse_ci --quiet --output=json https://example.com > report.json

[paulirish]

Left to do: upstream the work here and ship a blessed image on Dockerhub.

@ebidel let's do that this sprint! 🚗 ya?

[frvge]

@ebidel , that's correct.

[ebidel]

@paulirish yea sg.

[paulirish]

@ebidel do you think you can 1) upstream the work from lighthouse-ci into this repo and 2) publish the image on dockerhub this sprint?

[ebidel]

Sorry, keep getting pulled in different directions. I have a branch 1/2 done. When does the new sprint end?

[paulirish]

all good! 2 weeks from now

[boyney123]

Hey,

@ebidel did this ever get pushed to docker?

I'm exploring a performance tool at the moment, that supports monitoring of performance metrics. https://github.com/boyney123/garie

For now, I have created my own lighthous_ci docker image and hosted on docker hub, but would be great to move over to the official one?

[oleggromov]

Hey guys, everyone is really looking forward to having an official Docker image for Lighthouse!

[frvge]

@ebidel , what's the status here? Maybe my PR to fix some reviews can help? I tried to get a dockerized version to work again with a pull from master but as usual I'm hitting all kinds of issues :(
-> edit: I fixed my main issue of the browser not booting up. The problem was that Debian Stretch does not enable user namespace mapping by default. https://superuser.com/questions/1094597/enable-user-namespaces-in-debian-kernel helped a lot. I think this gotcha should be mentioned somewhere in the docs. Docker uses the kernel of the host machine so the host machine has a big impact here.

[connorjclark]

There seems to be much overlap between the needs for a Docker image & LHCI + the action. I don't think it makes sense for use to manage a docker image - my vote would be to close this issue.

[patrickhulce]

I think the biggest issue with an official docker image is the set of expectations that folks will inevitably have for it as a stable environment that I'm nearly certain won't be true.

There certainly is some overlap for docker-based CI setups and maintaining an official docker image that might be nice though. We can transfer this issue to the lighthouse-ci repo perhaps?

[connorjclark]

I think the biggest issue with an official docker image is the set of expectations that folks will inevitably have for it as a stable environment that I'm nearly certain won't be true.

+1

There certainly is some overlap for docker-based CI setups and maintaining an official docker image that might be nice though. We can transfer this issue to the lighthouse-ci repo perhaps?

ya

[patrickhulce]

Current status of this as it pertains to lighthouse-ci:

• We will define a docker image that contains all the necessary dependencies to run Lighthouse that can be used in GitlabCI, CircleCI, etc.
• This docker image will not be recommended as the way to run lighthouse in a stable environment, merely a convenience.

[patrickhulce]

Docker image documentation: https://github.com/GoogleChrome/lighthouse-ci/tree/master/docs/recipes/docker-client

Example of it live in action with Circle CI: https://github.com/patrickhulce/patrickhulce.com/blob/2c917f4d3a10f7cc730e16980a9e2422636cdd29/.circleci/config.yml