👍 👍 👍 👍 👍

I agree with you Currently the ADD command is IMO far too magical

Here are my comments:

• We should keep options in one keyword
• Dockerfile syntax should be easy to learn, no need to have so many commands
• Right now with your example there is no way to untar a remote tarball, I would suggest something like:
  • COPY/INJECT -> copy local/remote files/directory/archive in the image
  • UNTAR -> copy local/remote archive in the image and untar them

Massive +1s, and I love @vieux's suggestion of just COPY and UNTAR commands to remove some of the magic here. This is a major roadblock for a couple of my projects right now.

As a side note, the hash verification stuff was already covered in #2579, and I think that'd be the appropriate place to discuss that further, especially since splitting ADD alone is a big enough topic for one issue. :)

I think the "remote download" items could also do with Last-Modified and/or ETag HEAD lookups for when we eventually get "ADD caching", but that's not really the discussion here either. 👍

I can work with COPY and UNTAR.

explicit > implicit +1

why UNTAR rather than RUN tar zxvf?

ie, INSERT a_tarfile then (do i need to set a WORKDIR?) RUN tar zxvf a_tarfile

first up, INSERT is thus the same as docker insert and when i need to run something...

One difference is that "run tar" depends on the version of tar available in the image. It's better to guarantee the same version everywhere (ideally docker would embed its own implementation) , and insome scenarios the images will not have tar at all.

On Tue, Dec 10, 2013 at 11:05 PM, Sven Dowideit notifications@github.com
wrote:

why UNTAR rather than RUN tar zxvf?
ie, INSERT a_tarfile then (do i need to set a WORKDIR?) RUN tar zxvf a_tarfile

first up, INSERT is thus the same as docker insert and when i need to run something...

Reply to this email directly or view it on GitHub:
#3050 (comment)

understood

Also because that would double the size of our base images, not to mention where does the original tar come from when we start with nothing?

I think it's very important that we keep the ability to create a layer entirely from a tar (for our base images at least), I would just be extremely grateful for a way to do so with a remote tar too, and if we could disentangle ADD while we're at it, I see that as a win, personally.

Another vote for disentangling it. I've just run into a problem, and even my hacky workaround wasn't enough to get around the ADD magic.

I've got a tarball in my context (local) that needs to get copied into the image compressed (it gets used later on directly, not decompressed). I started out trying to ADD it, but discovered that it got untarred. As a workaround, I renamed it to .foo instead of .tar.gz and it still got decompressed!

Not sure what my next attempt is going to be, but it'd be awesome if there were a straightforward way to just say "copy this file as-is".

Edit: A final workaround that actually worked:

Before hand:
openssl enc -aes-256-cbc -k password -in myfilename.tar.gz -out myfilename.encrypted

In Dockerfile:
ADD ./myfilename.encrypted /root/
RUN openssl enc -d -aes-256-cbc -k password -in /root/myfilename.encrypted -out /root/myfilename.tar.gz

Dockerfile / docker build should implement minimal functionality, and instead delegate to commands which are available on the CLI as docker <cmd> ….

I think ADD is the biggest offender on this front. Some symptoms:

• ADD in a Dockerfile is confusing and doesn't have its own documentation page.
• docker add doesn't exist; no CLI mechanism to recursively add a local directory to an image.

I imagine ADD is tricky because it depends on the build context (tarred $PWD sent to the docker daemon). But I'm sure we can work around that. If running with a build context, use that; if not, tar and send the specified directory to be added to the image.

Maybe this warrants an issue, not a comment, but it seems very relevant here.

We have a bunch of bugs on ADD at the moment. What's the best way to pitch a strawman implementation?