Docker official image

[yosifkit]

This is a follow-up to facebook/hhvm#6126 (comment).

We have a PR from a community member to add an hhvm image to the Docker Official Repos, but wanted to reach out to the upstream to see if they wanted to be involved. Any interest 😄?

[jwatzman]

@fredemmott should weigh in on this.

[fredemmott]

Comment is still accurate, we're planning on supporting fredemmott/hhvm and fredemmott/hhvm-proxygen (and moving them to the hhvm/ organization). This isn't set in stone, but the PR doesn't look like an improvement:

Advantages of PR:

• supports fastcgi

Technical advantages of ours:

• uses the prebuilt packages. We currently do not have any possibility of supporting another from-source build
• supports Proxygen (HTTP server instead of FastCGI)
• separate packages for 'hhvm' and 'hhvm/proxygen' - an 'hhvm/fastcgi' image could be added fairly easily

Other issues:

• baptistedonaux/docker-images@f9614b4 worries me - no explanation for why it's gone? There's no branch either.
• entrypoint.sh seems like a subjective convenience, I don't think it should be there
• we won't support/endorse it (i.e. it'll be 'unsupported community-provided') unless we have push access and it's based on our binary packages. This is both so that we can honor our LTS promises and push security updates at the same time as they're announced.

[tianon]

https://github.com/baptistedonaux/docker-hhvm is the location of the latest Dockerfiles for the PR, which does address some of your points (building from packages instead of source, etc)

IMO it'd be fantastic if you guys wanted to have https://github.com/hhvm/docker or something similar instead -- we'd be happy to help with the technical/process parts of making sure the top-level hhvm image stayed reasonably up to date with the repo, and it's not at all unusual for one of our upstreams to also maintain their own image under a prefix (like hhvm/hhvm, for example).

I would like to stress pretty heavily that we don't want to burden your team or do anything against your wishes. We're interested in making sure hhvm users can have a good, consistent Docker experience. 😄

[fredemmott]

https://github.com/fredemmott/hhvm-docker is what's currently likely to become hhvm/hhvm + related images

If there's both a top-level hhvm and hhvm/hhvm, and both are relatively up to date, in what situations should an end-user pick one over the other?

[tianon]

Good question! 😄 (I don't necessarily have the answer -- top-level in my mind for that case would mostly be about discoverability.)

[psftw]

A recent example that comes to mind is neo4j/neo4j and neo4j. In that case, the former is an automated build that has been used for both testing builds and release builds, whereas the Official Repo only receives the latest production releases. There was actually a change that they made in the upstream code with version 2.3.0 to make it more Docker-friendly so previous versions are only available in neo4j/neo4j, which may also see additional backported versions over time to support users. The benefits to using the Official Repo that come to mind: layer caching to save redundant data transfer, security updates from base images downward are built in to the process, and there is a guarantee that updates will get a second set of eyes before being pushed. If your organization is already quite sophisticated in producing images, then the differences would be less.

In a nutshell, an Official Repository is promoted on DockerHub, and signifies a collaborative effort between the dedicated Official Repos team and either the upstream author/vendor (preferred) or a passionate user. Not every upstream wants to commit to this process, which involves a benevolent human gatekeeper, even though much of the overhead can be automated away. In the case of hhvm, based on a quick read of the discussion, it may be duplicate work to maintain the same (or similar) things in two places. Anything I can do to convince you to collaborate on an Official Repo? 🎁 Obviously I'm a little biased here, but I think there is significant benefit for users.

[fredemmott]

Would you be fine adopting a similar tag structure? In particular as well as the common 'latest' tag, we'd like '3.9-lts-latest' or similar. - if we'd have started earlier, there'd also be 3.3-lts-latest (no longer updated), 3.6-lts-latest (still-supported), and in the future, there'll be 3.12-lts-latest.

We support 3.(x % 3 === 0) release for ~ 1 year, and tracking one of these is probably a better bet than latest for most people. On a similar line, I should probably add '3.10-latest' to our tags....

Also, how fast (and public?) are turn-arounds for new releases? The separate organization approach lets us have an image built and ready to push at the same time we make security issues public.

[yosifkit]

As far as tag structure, we don't have any rules written down. We generally drop the text "latest" from being in any other tag, since it is just repetitive. latest itself is really just the default image; for example in ubuntu it is 14.04 instead of something from 15, since that is what people should be using when they don't specify a tag, like in docker run -it --rm ubuntu.

We have images that maintain multiple versions, like node and some that only have one version, like nginx, so however many versions you want to support is fine by us. Generally they are something like, 3.10.0, 3.10, 3, and latest being aliases, and 3.9.1, 3.9, 3.9-lts, 3-lts, and lts being aliases. It depends on if you want the tags that follow a series like 3-lts.

The process for updating an official repo is just making a PR to change the library/hhvm file in docker-library/official-images. This file contains the tags with their git url, commit id, and Dockerfile directory. We do a quick check of the changes from the last commit ids to ensure consistency and Dockerfile best practices. Once we see it and the changes look fine we run a local build test (ie ./test-pr.sh 1043) as a sanity test and then merge. Depending on build time, this can be as short as a few minutes. This is usually limited to 8-5 PST M-F, but there can be extenuating circumstances. Once merged, we pull the code on the build server, and it builds and pushes to docker hub (all the code that builds and pushes is open and part of the official-images repository). If you have a security release coming up that you don't want to advertise in a PR just yet, and want a quick merge, we don't mind a heads up via email or IRC.

The documentation that appears on the Docker Hub is controlled by docker-library/docs. The supported tags section is generated from the coresponding library/ file in official-images. When items are removed from the library file, they are automatically removed from the list in the readme, but the old tags are still be available to pull from the Docker Hub.

Hopefully that answers some of your questions, feel free to ask more here and/or come chat on freenode IRC in #docker-library.

[fredemmott]

This sounds very promising; I can change our images to match that system. Broader changes/co-operating are likely to need to wait until Januarary.

[yosifkit]

Thanks @fredemmott, we are always excited when an upstream wants to maintain their official image. 👍

Would you like us to hold off on accepting an official image for HHVM until you submit one? Or should we accept the images from @baptistedonaux in docker-library/official-images#1043 now and then transfer them to your images at a later date?

[fredemmott]

I'd rather hold-off - if we transfer, there'll probably be a behavior change (eg that entrypoint.sh), which could be annoying/surprising for users, especially as we'd expect to re-use the existing tag names.

[fredemmott]

I'm not directly working on HHVM any more. cc @paulbiss or @Orvid