-
Notifications
You must be signed in to change notification settings - Fork 18.9k
Description
I just brought this up in IRC and @erikh mentioned the idea had been rejected. I'm opening this issue to register our need for this feature. We've gone to a tremendous amount of trouble to work around its non-presence, and I think it would be helpful to a lot of users. Here's why:
1. Layer count limits
We use BTRFS, so this doesn't actually matter to us, but AUFS's limit of 42 layers means that creating a layer for (especially) each piece of metadata can cause some complex images to approach this limit.
2. File size
In the past, we needed the full .git directory available briefly during our build process. Currently we'd have to model this like so with a Dockerfile:
ADD git_repo /app
RUN do_stuff_with_git && rm -rf /app/.git
Unfortunately, ADD and RUN can't occupy the same layer, so the .git directory is a permanent feature of the image hierarchy, adding (for us) 350MB to each image build on our core product.
3. Sensitive information
This is part of our build process:
1. Pass a private key into the container
2. Decrypt some encrypted data stored in the git repo (API tokens and DB passwords, etc.)
3. Perform some action with the encrypted data
4. Discard the decrypted secrets and private key
With the current builder model, this is impossible to do without the private key and plaintext secrets appearing in the final image hierarchy.
In this case we'd have to model the process as:
ADD privatekey /privatekey
RUN decrypt -o /secrets && do_stuff --with /secrets && rm -f /privatekey /secrets
Since ADD and RUN can never occupy the same layer, the private key is stuck in our image hierarchy.
4. Cosmetic
The way people have to chain together long sequences of RUN commands with && feels really awkward.
We've written a huge amount of code to work around this limitation. It would certainly simplify our lives if this were accepted as a feature, and I'd be really surprised to hear we're alone.
The implementation I expect makes the most sense is:
RUN a
BEGIN
RUN b
RUN c
RUN d
COMMIT
RUN e
# layers a, b+c+d, e
...however, ignoring the AUFS issues, the only really important thing is some way to be able to run a command after adding files within the same layer.
/cc FYI @graemej @marc-barry @sirupsen @ibawt @tobi