Question on base images

[sarahethompson]

Hi
HashiCorp Release Engineering here.
We had a question on some changes that we are hoping to make to the dockerfiles for our official images (Consul and Vault).

Is it possible for us to derive our official images from the images that we push to hashicorp/consul hashicorp/vault?

e.g
FROM hashicorp/vault:4.3.2

Due to the way we currently build our docker images, this would help significantly and avoid us having to maintain two separate dockerfiles for each product.

I notice that here it states that official images can only be derived from other official images with a few notable exceptions. However I see elasticsearch are doing what we would like to do and rebundling images that they maintain (https://github.com/docker-library/elasticsearch/blob/master/7/Dockerfile).

# This image re-bundles the Docker image from the upstream provider, Elastic.
FROM docker.elastic.co/elasticsearch/elasticsearch:7.16.3@sha256:0efc3a054ae97ad00cccc33b9ef79ec022970b2a9949893db4ef199edcdca2ce

Thanks for any clarity you can give us

[tianon]

Unfortunately, elasticsearch (and logstash + kibana) was a one-time exception and honestly hasn't gone well, so that model is not one we'll be likely to accept again.

[tianon]

As an alternative, can we help maintain the Dockerfiles in some way?

[sarahethompson]

Hi @tianon - sorry for the delay. We are going to instead move the contents of the existing (docker official) dockerfile to the other dockerfile in our product repo(s) and make it the default target. That way we can easily share the entrypoint.sh (between targets) and make it easier for teams to maintain. This works fine with Bashbrew and I can see nothing in the docs to say we shouldn't do this..

[yosifkit]

It's not a hard requirement for the Dockerfiles to be in a separate repo, but a quick warning about putting the Dockerfile in the root of the upstream repo: #11100 (comment). As noted in that comment, there are a few issues that could crop up: Dockerfile and other "packaging" changes between upstream releases and the need for extreme care about docker build context (COPY targets) and how that might affect the generated diffs (diff-pr.sh).

[sarahethompson]

Thanks @yosifkit. We are only doing a COPY .release/docker/docker-entrypoint.sh /usr/local/bin/docker-entrypoint.sh in the new default target so this should be ok. I take your point about potentially having to make changes to the dockerfile between releases of the software itself. We have really only ever modified the version number in the dockerfile in the last number of years (and twice updated the PGP key - although we could add a additional step to our build workflow to run a bashbrew build to verify things like this).

We're building all of our release artifacts on every commit now from the product repo (including the docker image that we push to hashicorp/vault) so we're trying to avoid having to maintain an almost identical dockerfile (and identical entrypoint.sh) in a separate repo (for the official image). A product engineer could make an update to the dockerfile or entrypoint.sh in the product repo but forget to do it in the docker-vault repo for example.

We could have automation to try to keep them in sync but this would introduce overhead and complexity that we're trying to avoid if possible.

[yosifkit]

Unfortunately, since we don't have any configuration points to just build a single target within a multistage build, I think that Dockerfile would fail to build for us (since our process would attempt to build the first stage and fail to COPY the file). We can handle a custom Dockerfile name, so two Dockerfiles in the one directory with one named Dockerfile.official or something can work (like mysql).

[sarahethompson]

Thanks, it seemed that Bashbrew just built the default target when I tried this locally so I thought it would be ok - but we can move it into a separate dockerfile and use File: Dockerfile.official - this makes it easier as we can move this to the folder where the entrypoint.sh lives (.release/docker) and specify Directory: .release/docker which should help with the build context issue. Thanks for your help!

[yosifkit]

The information above is still correct and answers the questions about being FROM an image outside of Docker Official Images and about hosting the Dockerfile in the upstream code repo.

Given the transition to deprecate the Hashicorp images in DOI, I'll go ahead and close this issue. (docker-library/docs#2283, docker-library/docs#2291)