Using packer to build lightweight go based docker containers

[i0n]

Hi chaps.

Admittedly I haven't done a huge amount of poking around on this issue, but I have a theory.

Use case:
Use packer to build a docker container from the 'scratch' base image. This is all you need to run a statically linked go binary.

Problem:
When using the file provisioner, packer seems to be attempting to use /bin/bash inside the container (which in the case of scratch base image doesn't exist).

Tests:
Using a standard Dockerfile works perfectly (COPY)
Using a "normal" base image (like ubuntu) with packer works perfectly.

Question:
It is of course perfectly possible to achieve the desired docker image without using packer, but I wondered if this is a known issue or simply a use case that has slipped through the net?

Why?
The difference is pretty big: My test container (with a small simple go binary) ballooned from 7.3mb when using scratch to 195.7mb when forced to use ubuntu base image.

[rickard-von-essen]

Agree, it would be great if packer cloud use the docker cp command to put files in the container.

@i0n Could you provide a sample config for this?

[i0n]

Sure. Do you mean what the packer.json would look like to provision a container like this?

I imagine something like:

{
  "builders": [{
    "type": "docker",
    "image": "scratch",
    "commit": true
  }],
  "provisioners": [
    {
      "type": "file",
      "source": "pathofbinary/app",
      "destination": "/bin/app"
    }
  ],
  "post-processors": [
    [
      {
          "type": "docker-tag",
          "repository": "i0nw/super-awesome-app",
          "tag": "0.1"
      },
      "docker-push"
    ]
  ]
}

[rickard-von-essen]

After some digging I found the following issues:

1. The default run_command is ["-d", "-i", "-t", "{{.Image}}", "/bin/bash" ]. This is seems to be the cause this assumption:

When using the file provisioner, packer seems to be attempting to use /bin/bash inside the container

Which is not true. The run_command can be altered, but in the scratch image there is noting to run so for the rest of my test is switched to tianon/true

{
  "builders": [
    {
      "type": "docker",
      "image": "tianon/true",
      "export_path": "image.tar",
      "pull": "true",
      "run_command": [
        "-d", "-i", "-t", "{{.Image}}", "/true"
      ]
    }
  ],
 "provisioners": [
    {
      "type": "file",
      "source": "go-program",
      "destination": "/bin/app"
    }
  ]
}

This running this works if the file-provisioner is omited, but with it fails with:

2015/02/13 08:59:43 packer-builder-docker: 2015/02/13 08:59:43 Running the provision hook
2015/02/13 08:59:43 ui: ==> docker: Uploading go-program => /bin/app
2015/02/13 08:59:43 packer-provisioner-file: 2015/02/13 08:59:43 [INFO] 0 bytes written for 'uploadData'
2015/02/13 08:59:43 [INFO] 0 bytes written for 'uploadData'
2015/02/13 08:59:43 packer-builder-docker: 2015/02/13 08:59:43 Executing in container ff8850179f13148a3845a50fb7b201ed59b4f5eb6bb0da6ec93b51224ebdf4ad: "(command cp /packer-files/upload873520235 /bin/app) >/packer-files/cmd529516238 2>&1; echo $? >/packer-files/cmd529516238-exit"
2015/02/13 08:59:45 ui error: ==> docker: Upload failed: Upload failed with non-zero exit status: 1 

2. This fails on command cp ... since that aren't available.

[mwhooker]

I think this should be fixed as part of the docker API in #4186