Packer: Docker build fails using a local image as base image

Created on 18 Jun 2015  路  6Comments  路  Source: hashicorp/packer

Hello!
When building my template with the docker builder, I have an error when I try to specify an image which is local to my docker instance.

Here is a snippet of my config:

  • Mac OSX
  • Boot2Docker-cli version: v1.6.2 Git commit: cb2c3bc
  • docker Docker version 1.6.2, build 7c8fca2
  • go version go1.4.2 darwin/amd64
  • Packer v0.7.5+ (build from github tree, commit:

commit edf3415c6e2248c8096f9c16cbad5022b73d6f21
Author: Mitchell Hashimoto mitchell.[email protected]
Date: Fri May 29 17:10:14 2015 -0700

As an isolated test, I've used the following templates:
template1.json

{
    "builders": [
        {
            "commit": true,
            "image": "ubuntu",
            "type": "docker"
        }
    ],
    "post-processors": [
        {
            "force": true,
            "repository": "increment-image",
            "type": "docker-tag"
        }
    ]
}

template2.json

{
    "builders": [
        {
            "commit": true,
            "image": "increment-image",
            "type": "docker"
        }
    ],
    "post-processors": [
        {
            "force": true,
            "repository":"full-image",
            "type": "docker-tag"
        }
    ]
}

I run the following commands:

$ packer build template1.json
docker output will be in this color.

==> docker: Creating a temporary directory for sharing data...
==> docker: Pulling Docker image: ubuntu
    docker: Pulling repository ubuntu
    docker: 6d4946999d4f: Pulling image (latest) from ubuntu
    docker: 6d4946999d4f: Pulling image (latest) from ubuntu, endpoint: https://registry-1.docker.io/v1/
    docker: 6d4946999d4f: Pulling dependent layers
    docker: 428b411c28f0: Download complete
    docker: 435050075b3f: Download complete
    docker: 9fd3c8c9af32: Download complete
    docker: 6d4946999d4f: Download complete
    docker: 6d4946999d4f: Download complete
    docker: Status: Image is up to date for ubuntu:latest
==> docker: Starting docker container...
    docker: Run command: docker run -v /Users/corentin/tmp/packer-docker100110748:/packer-files -d -i -t ubuntu /bin/bash
    docker: Container ID: aa66e22918f14ae3bfde97169d83c87b5827e309a8a5f44da2f7ae95ea3e24aa
==> docker: Committing the container
    docker: Image ID: 512d31c02c5409e455f9715ffc2d69acc7dc232439a10a6ac4644a8722fe3e50
==> docker: Killing the container: aa66e22918f14ae3bfde97169d83c87b5827e309a8a5f44da2f7ae95ea3e24aa
==> docker: Running post-processor: docker-tag
    docker (docker-tag): Tagging image: 512d31c02c5409e455f9715ffc2d69acc7dc232439a10a6ac4644a8722fe3e50
    docker (docker-tag): Repository: increment-image
Build 'docker' finished.

==> Builds finished. The artifacts of successful builds are:
--> docker: Imported Docker image: 512d31c02c5409e455f9715ffc2d69acc7dc232439a10a6ac4644a8722fe3e50
--> docker: Imported Docker image: increment-image

$ docker images
REPOSITORY               TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
increment-image          latest              512d31c02c54        12 seconds ago      188.3 MB

$ packer build template2.json 
docker output will be in this color.

==> docker: Creating a temporary directory for sharing data...
==> docker: Pulling Docker image: increment-image
    docker: Pulling repository increment-image
    docker: time="2015-06-17T20:53:42-07:00" level=fatal msg="Error: image library/increment-image:latest not found"
==> docker: Error pulling Docker image: Bad exit status: 1
Build 'docker' errored: Error pulling Docker image: Bad exit status: 1

==> Some builds didn't complete successfully and had errors:
--> docker: Error pulling Docker image: Bad exit status: 1

==> Builds finished but no artifacts were created.
bug buildedocker

Most helpful comment

There is an explicit workaround by adding "pull": false into template2.json. Not sure if this is the intended usage or whether a more implicit check for a local image would be useful.

$ cat template2.json
{
    "builders": [
        {
            "commit": true,
            "pull": false,
            "image": "increment-image",
            "type": "docker"
        }
    ],
    "post-processors": [
        {
            "force": true,
            "repository":"full-image",
            "type": "docker-tag"
        }
    ]
}
$ packer build template2.json
docker output will be in this color.

==> docker: Creating a temporary directory for sharing data...
==> docker: Starting docker container...
    docker: Run command: docker run -v /var/folders/17/8pm_zzbd09z02zfzgs17l4n80000gn/T/packer-docker480317963:/packer-files -d -i -t increment-image /bin/bash
    docker: Container ID: 3288a06403c00ef8aaae975e872501b6e565dbd90308016b2c9b9d4b7be65990
==> docker: Committing the container
    docker: Image ID: 6cadf8f8b003c4f6497b8ab28e1ee0a3645a4612d26132aa638c2388467a3c87
==> docker: Killing the container: 3288a06403c00ef8aaae975e872501b6e565dbd90308016b2c9b9d4b7be65990
==> docker: Running post-processor: docker-tag
    docker (docker-tag): Tagging image: 6cadf8f8b003c4f6497b8ab28e1ee0a3645a4612d26132aa638c2388467a3c87
    docker (docker-tag): Repository: full-image
Build 'docker' finished.

==> Builds finished. The artifacts of successful builds are:
--> docker: Imported Docker image: 6cadf8f8b003c4f6497b8ab28e1ee0a3645a4612d26132aa638c2388467a3c87
--> docker: Imported Docker image: full-image

All 6 comments

Interesting bug. Thanks!

There is an explicit workaround by adding "pull": false into template2.json. Not sure if this is the intended usage or whether a more implicit check for a local image would be useful.

$ cat template2.json
{
    "builders": [
        {
            "commit": true,
            "pull": false,
            "image": "increment-image",
            "type": "docker"
        }
    ],
    "post-processors": [
        {
            "force": true,
            "repository":"full-image",
            "type": "docker-tag"
        }
    ]
}
$ packer build template2.json
docker output will be in this color.

==> docker: Creating a temporary directory for sharing data...
==> docker: Starting docker container...
    docker: Run command: docker run -v /var/folders/17/8pm_zzbd09z02zfzgs17l4n80000gn/T/packer-docker480317963:/packer-files -d -i -t increment-image /bin/bash
    docker: Container ID: 3288a06403c00ef8aaae975e872501b6e565dbd90308016b2c9b9d4b7be65990
==> docker: Committing the container
    docker: Image ID: 6cadf8f8b003c4f6497b8ab28e1ee0a3645a4612d26132aa638c2388467a3c87
==> docker: Killing the container: 3288a06403c00ef8aaae975e872501b6e565dbd90308016b2c9b9d4b7be65990
==> docker: Running post-processor: docker-tag
    docker (docker-tag): Tagging image: 6cadf8f8b003c4f6497b8ab28e1ee0a3645a4612d26132aa638c2388467a3c87
    docker (docker-tag): Repository: full-image
Build 'docker' finished.

==> Builds finished. The artifacts of successful builds are:
--> docker: Imported Docker image: 6cadf8f8b003c4f6497b8ab28e1ee0a3645a4612d26132aa638c2388467a3c87
--> docker: Imported Docker image: full-image

Thanks @markpeek!
The workaround works fine.

The way I understand the pull option as false is: "don't download images from the hub to save me data and/or prevent me from using public images I might not trust".
It would be great to still fix the issue in packer and be more consistent with docker. Eg. if local image exists, then don't try to pull it (give precedence of local over remote).

If we want to keep the "disable pull" option, then we need to check if the local image doesn't exist so we can make a decision to pull or not. (To do that, I think the best would be to use "docker inspect" and verify that what we found is an image and not a container).
If the pull option is not necessary/used, removing the pull whatsoever should automatically fallback to docker's local then remote behavior.

@markpeek Thank you very much. It saves me a lot of time.

+1 possible that the default action should be to check local then remote?

I think this comes down to having pull default to true or to false. I don't see a strong argument either way, so I think it's best to defer to existing behavior.

If you have a better solution you'd like to bring up, please open a new issue with [RFC] default docker image pull behavior or something similar

Was this page helpful?
0 / 5 - 0 ratings