"docker save" does not store image tags. #3877
Comments
|
It's inconsistent: |
|
Since a single image ID can have multiple names/tags, I'd say the behavior of those first two is exactly what I'd expect (ie, if you've done something like |
|
The problem is really that currently there's no way to know, after calling docker load, what was loaded. If you load an image, you can't then instantiate it, because you don't know its ID. |
|
The docs for |
|
👍 The third use-case needs to preserve the tag imho, and I agree with better output from load. |
|
+1 to Eric. |
|
SHA should get the names and tags associated with that too. Also +1 for documentation in docker save that itemizes what gets stored. "Contains all parent layers, and all tags + versions" is misleading if by design, it does not save tags + versions. |
|
i'm attempting to workaround this issue on my end using this script: # docker-save.sh
#!/bin/bash -ex
# Wrapper for 'docker save' fixing,
# https://github.com/dotcloud/docker/issues/3877
# In addition: this script will always save exactly one image (possibly
# multiple tags).
IMAGE=$1
TARGET=$2
NAME=`echo $IMAGE | awk -F':' '{print $1}'`
ID=`docker inspect $IMAGE | scripts/json 0.id`
TAGS=`docker images --no-trunc | grep $ID | awk '{print $2}'`
DIR=`mktemp -d --suffix=-docker-save`
pushd $DIR
docker save $ID > $TARGET
echo "{\"$NAME\":{" > repositories
for TAG in $TAGS; do
echo "\"$TAG\":\"$ID\"," >> repositories
done
echo "}}" >> repositories
tar -r -f $TARGET repositories
popd
rm -rf $DIRhowever, it seems to me that a tar file created by 'docker save' cannot be manipulated by GNU tar. |
|
and the added 'repositories' file is missing for some reason. i see some strange files appended to it instead: |
yup, the culprit turns out to be GNU tar (or docker's tar being incompatible with it). using Python's tarfile module works. here is the working wrapper script working around this issue: https://gist.github.com/srid/9424614 |
|
Any development on this issue? |
|
What versions are you working with? There were inconsistent behavior, but has been fixed recently |
|
The current (and correct) behavior is as follows: docker save repoSaves all tagged images + parents in the repo, and creates a repositories file listing the tags docker save repo:tagSaves tagged image + parents in repo, and creates a repositories file listing the tag docker save imageidSaves image + parents, does not create repositories file. The save relates to the image only, and tags are left out by design and left as an exercise for the user to populate based on their own naming convention. |
|
@fkautz The second one works for you? If I try and save a repo:tag, it fails to create the directory because it's trying to create a directory with a colon in it (well that's my guess): docker save matt/centos:6.5.0.2014.07.21 |
|
I tried it in trunk and saw it work. What version are you running?
|
|
I'm running 1.1.2. Have you tried with a namespace? Here's a reproduction: |
|
It appears that the namespace is actually the culprit, not the version. If I take the same example but build without a namespace, it works: |
|
Also, saving with namespace/tag (dropping version) does work. So to sum up: |
|
I did not try it with a namespace. I'll give it a try.
|
|
all the behaviour seen in master (042b642) is expected behaviour. |
|
The comment that closes this issue is unclear as to whether the current released behaviour is considered to be 'expected behaviour' or whether there is a fix to the current release that will appear in the next release (as a result of being in master). Certainly I'm finding two issues when using the
I would have expected that saving an image with an explicit version would save only that image and its associated layers. When saving an image without an explicit version it is probably beneficial that it saves all of the versions and their associated layers. |
|
Your question hits my concern. I'm unfortunately not in a position to say whether this works in master but I know it exhibits these issues in the current latest release 1.1.2. The closing comment is not at all clear on what should or shouldn't work and I don't know if master at the time of the comment corresponds to the current 1.1.2 or a future release with 'fixed' behaviour. |
|
@sroebuck this has been marked closed because it was confirmed to be fixed in 'master'. The presence of this fix will be in the next release (1.2) |
|
Very Easy, make a df on command line, and you will see where docker has monted his container, so you can tar it. |
|
I've found that saving a image by id does not preserve the name and tag. Is this intentional? I understand the digest sha overrides the tag, but I don't see why the loaded image (last command) cannot contain the original image name. daniel@gin-nuest:~$ docker --version
Docker version 1.12.5, build 7392c3b
daniel@gin-nuest:~$ docker pull busybox
Using default tag: latest
latest: Pulling from library/busybox
fdab12439263: Pull complete
Digest: sha256:f102731ae8898217038060081c205aa3a4ae3f910c2aaa7b3adeb6da9841d963
Status: Downloaded newer image for busybox:latest
daniel@gin-nuest:~$ docker save busybox > busybox_name.tar
daniel@gin-nuest:~$ docker load < busybox_name.tar
Loaded image: busybox:latest
Loaded image ID: sha256:1efc1d465fd6255396d0efd90a899f57aba2b7b294b02d5f55c6f5505ca9f3e5
Loaded image ID: sha256:e02e811dd08fd49e7f6032625495118e63f597eb150403d02e3238af1df240ba
daniel@gin-nuest:~$ docker save busybox:latest > busybox_name-latest.tar
daniel@gin-nuest:~$ docker load < busybox_name-latest.tar
Loaded image: busybox:latest
daniel@gin-nuest:~$ docker save busybox:latest@sha256:f102731ae8898217038060081c205aa3a4ae3f910c2aaa7b3adeb6da9841d963 > busybox_name-digest.tar
daniel@gin-nuest:~$ docker load < busybox_name-digest.tarLoaded image ID: sha256:1efc1d465fd6255396d0efd90a899f57aba2b7b294b02d5f55c6f5505ca9f3e5
daniel@gin-nuest:~$ docker save busybox@sha256:f102731ae8898217038060081c205aa3a4ae3f910c2aaa7b3adeb6da9841d963 > digest.tar
daniel@gin-nuest:~$ docker load < digest.tarLoaded image ID: sha256:1efc1d465fd6255396d0efd90a899f57aba2b7b294b02d5f55c6f5505ca9f3e5
|
A single digest can be tagged under multiple names; when saving by digest, the |
|
I wrote a shell script to save all the docker images with repo + tag info as .tar files, see https://gist.github.com/attila123/8f60a0ebce15b6065975ba35e3be7d75 |
|
@thaJeztah IMO, |
|
I use this one liner, may be it helps:
|
and others
If you call "docker save repo:tag", the resulting tarball will not contain the repo or tag, and there's no way that I can see to figure out what image is inside such a tarball, short of extracting the json and building the revision history yourself. IE, if you're handed a "docker saved" image, the only way to figure out what was loaded when you do "docker load" is to compare "docker images" from before and after.
Docker inspect should work on tarballs, and docker save should store repos and tags.
The text was updated successfully, but these errors were encountered: