Feature/post processor docker dockerfile

[jgkim]

The Packer Docker Dockerfile post-processor takes an artifact from the docker builder that was committed and adds information such as exposed ports, shared volumes, and other metadata by using Dockerfile. This allows you to use the other Docker post-processors such as docker-tag to tag it or docker-push to push the image to a registry.

An example is shown below, showing only the post-processor configuration:

{
  "type": "docker-dockerfile",
  "maintainer": "James G. Kim <jgkim@jayg.org>",
  "cmd": ["/bin/bash"],
  "label": {
    "version": "1.0"
  },
  "expose": [8080],
  "volume": ["/var/log"]
}

[georgevicbell]

Is this missing some commands? Run/Add/Copy are in there according to the docker docs...in any case this would be useful.

[jgkim]

@georgevicbell I have intentionally not added those commands (i.e., RUN, ADD, OR COPY) since they can be achieved by the packer docker builder or other post-processors.

[warroyo]

what is the status on this pull request? is anyone working on the conflicts ? This would be really great functionality to be added.

[jgkim]

@warroyo I think there is no conflict with this pull request. We need decisions to be made by @mitchellh or others. And, as you know this issue is somewhat similar to #2193.

[rbclark]

I have been using this plugin and it has been invaluable for my ability to use Docker with Packer. I would love to see this merged into master to make the plugin easier to access.

[jgkim]

@mitchellh Could you give us some comments? Do you think what is missing here? What do we need to do more to merge this?

[miorimmax]

I'm curious, why is ONBUILD not supported? Here we use it for things like ONBUILD ADD Gemfile Gemfile.lock /app/ and ONBUILD RUN bundle install --deployment on our base images, so the app's Dockerfiles don't have to do this over and over.

I can't see how a provisioner would replace this kind of functionality, am I missing something? :)

[jgkim]

@miorimmax Since Packer builds Docker containers without the use of Dockerfiles, unfortunately it is not possible to use ONBUILD with Packer. I think reusing the Packer template is one way to do the same thing with ONBUILD.

[CorbanR]

+1

[davidkarlsen]

Any progress on this? @mitchellh WDYT?

[jsoriano]

Building with this id can fail with docker 1.8.X: moby/moby#16218

[romankor]

+1

[tabbi89]

+1

[georgevicbell]

+1

[georgevicbell]

Is this likely to get merged for the next release? Is there anything stopping it from being merged?

[rickard-von-essen]

@markpeek Have you tested this? Any reason to not try to add this in 0.9.0. I can do some testing and try to merge it before 0.9.0 if there is no issues.

@cbednarski or should we wait?

[cbednarski]

I haven't tested this, but I'm prepping the 0.9 RC so let's wait until 0.9 is finalized. We can include this in 0.10 (which will be relatively soon).

[vtolstov]

ping...

[vtolstov]

@jgkim does it possible to add docker file to exiting artifice file ?

[vtolstov]

I want something like this

"post-processors": [
    [
      {
        "type": "artifice",
        "files": [ "output/filesystem.tar.gz" ]
      },
      {
        "type": "docker-import",
        "repository": "vtolstov/exherbo-current-x86_64"
      },
      {
        "type": "docker-dockerfile",
        "entrypoint": ["/usr/sbin/init"]
      },
      "docker-push"
    ]
  ]

[gregorskii]

Is this ticket still moving?

Will likely need to look into the updates on jgkim/packer-post-processor-docker-dockerfile#3 to fix Docker 1.1+.

Thanks!

[jgkim]

@gregorskii Actually, this PR is not being actively maintained, and that repo is some what different from this PR. If you can make a PR to this repo related to this PR, I will be happy to review and merge it.

[gregorskii]

There was already a pr there related to docker 1.1+. Was pinging here to see if it was getting merged back into Packer itself.

Thanks for the code in the other repo. Appreciate it.

[haad]

I'm little bit lost do you plan to merge this repo into packer or what's the plan ?

[gregorskii]

@jgkim I see per above that the new repo is a fork of Packer itself. I can't open an issue in that repo because it is a fork (I presume).

Essentially the issue in jgkim/packer-post-processor-docker-dockerfile#3 is that the Docker image ID format has changed jgkim/packer-post-processor-docker-dockerfile@9e18262#diff-7e7d9161fd32d5be0e07bedea13dc538L35 like so. The repo here is also a large amount of commits behind Packer master.

Are we going to get resolution of this ticket as a update to Packer itself? Or a plugin we have to install? Currently I am using a fork of this repo with the fix detailed in pull 3.

Thanks

[mwhooker]

Hi all,

I'm taking over maintenance for packer. If anyone would like to try to sync this up with whatever fork's being maintained and rebase it, I'd be happy to try and work on getting it merged. For now though I've untargeted this from any releases since I'm not sure it's actively being worked on

[jgkim]

@gregorskii Sorry, I've found that I turned off the issues feature. I've turned it on again so you can open an issue there.

@mwhooker I will try to rebase the code and fix some issues in a few months. In the meantime, if anyone wants to work on this, let me know so I can add you as a collaborator.

[rickard-von-essen]

I'll close this since this seems abandon and this is covered in the provisioner in #4202. If someone would like to continue with this please rebase this code and open a new PR.

[gregorskii]

Does that task provide the same features? That's for pull and change metadata, ideally in this feature one would provision an image with new software and then add new metadata. Maybe they accomplish the same thing, but I think order matters.

What do you think?

[rickard-von-essen]

@gregorskii It provides access to --author, --message, and -change. See Docker Engine - commit for details.

So yes it provides everything this post-processor would provide.

[gregorskii]

@rickard-von-essen Awesome, I see what it provides. I was just curious about the order that it edits it in. In a typical packer file I would be doing this:

{
  "variables": {
    "IMAGE_NAME": "{{env `IMAGE_NAME`}}",
    "IMAGE_ORG": "{{env `IMAGE_ORG`}}",
    "IMAGE_TAG": "{{env `IMAGE_TAG`}}",
    "WORKING_DIR": "api",
    "USER": "api"
  },
  "builders": [
    {
      "type": "docker",
      "image": "node:{{user `NODE_VERSION`}}",
      "commit": true
    }
  ],
  "provisioners": [
    {
      "type": "shell",
      "inline": [
        "groupadd -r {{user `USER`}}",
        "useradd -r -g {{user `USER`}} {{user `USER`}} -d /{{user `WORKING_DIR`}}",
        "mkdir -p /{{user `WORKING_DIR`}}"
      ]
    },
    {
      "type": "file",
      "source": "api/package.json",
      "destination": "/{{user `WORKING_DIR`}}/package.json"
    },
    {
      "type": "shell",
      "inline": [
        "cd /{{user `WORKING_DIR`}}",
        "npm install",
        "chown -R {{user `USER`}}:{{user `USER`}} /{{user `WORKING_DIR`}}",
        "rm -rf /var/lib/apt/lists/*",
        "apt-get clean"
      ]
    }
  ],
  "post-processors": [
    [{
      "type": "docker-dockerfile",
      "workdir": "/{{user `WORKING_DIR`}}",
      "user": "{{user `USER`}}",
      "expose": [8080]
    },{
      "type": "docker-tag",
      "repository": "{{user `IMAGE_ORG`}}/{{user `IMAGE_NAME`}}",
      "tag": "{{user `IMAGE_TAG`}}"
    }]
  ]
}

Where following the order it would pull a node image, run some provisioners inside of it, then lastly change the metadata of the new image.

In this case its simply editing the workdir and ports, but if the metadata were doing something more complex like adding paths that exist only AFTER provisioning would that create any order of operations issues? I suppose it would not if Packer is simply running the "Docker" image as a machine image then applying metadata, but I wanted to confirm.

Thanks for the update. Getting metadata in there is a great addition however it is accomplished. :)