Docker "RUN" how-to!

[Daniel Ortega]

Is it possible to use packer to replicate this Dockerfile? https://github.com/geerlingguy/docker-debian9-ansible/blob/master/Dockerfile#L9

Basically I want to execute "Docker RUN" installating some packages (sudo and systemd) and start that container using "/lib/systemd/systemd". Is it possible? 

The problems that I have includes:

1. Docker RUN is not supported (or is not described in the official doc)
2. I cannot put scripts after docker container start
3. I don't know how to create a image, then tag this image and try to start using "/lib/system/systemd"

[Rickard von Essen]

1) RUN would be similar to use the shell provisioner.

2) If you mean something like COPY or ADD that would be similar to use the file provisioner.

3) I don't think I follow what you ask for here, can you elaborate?

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/mitchellh/packer/issues
IRC: #packer-tool on Freenode
---
You received this message because you are subscribed to the Google Groups "Packer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to packer-tool...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/packer-tool/fe9fe6d9-0c25-49ae-8b5d-aec868495b36%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Daniel Ortega]

We want to use our Java docker image (tagged as idealista/8u181-stretch-openjdk-headless in Docker Hub) which is based in Debian Stretch Slim. 

This image doesn't have systemd (neither official image, nor our derived image one), so this package should be installed to be used later to configure our services. AFAIK, if you want to use systemd to manage services, this process should be the first -> should be present in Docker run command. But the problem is, before installation /lib/system/systemd is not present, so the container cannot start. This could be solved using RUN when you are using Dockerfiles, because that commands are executed in the image "build phase". You can install systemd before and execute /lib/system/systemd at container startup. 

We don't know how to solve this using only Packer to build our images.

[Vincent Rubiolo]

Hi Daniel,

On 2/12/19 2:29 AM, Daniel Ortega wrote:

We want to use our Java docker image (tagged as idealista/8u181-stretch-openjdk-headless in Docker Hub) which is based in Debian Stretch Slim. 

This image doesn't have systemd (neither official image, nor our derived image one), so this package should be installed to be used later to configure our services. AFAIK, if you want to use systemd to manage services, this process should be the first -> should be present in Docker run command. But the problem is, before installation /lib/system/systemd is not present, so the container cannot start. This could be solved using RUN when you are using Dockerfiles, because that commands are executed in the image "build phase". You can install systemd before and execute /lib/system/systemd at container startup.

As Rickard said, you can use a shell provisioner to run any command you want (in this case the one to start systemd) once your container is up with Packer. Another solution is to override the RUN command (as per https://www.packer.io/docs/builders/docker.html#run_command) to specify what you want.

So in short I'd advise:

1. Start your container with Packer using the default settings.
   
2. Install the packages you want (either via a shell or Ansible provisioner), like systemd.
   
3. In your shell provisioner, manually start systemd, then use it to configure the services

AFAIK, systemd must be running when you use commands like 'service' but it does not need to be started when the container starts (there are ways to do that if needed).

On a related note, I had a similar issue with the container not starting, because the default Packer 'docker run' command relies on /bin/bash +  not having an entrypoint set (cf https://github.com/hashicorp/packer/issues/6920). The changes was made but later reverted because of backward compatibility issues. You might find the issue useful in your case tool.

Let us know how it goes,

Vincent

[Rickard von Essen]

I think there is som confusion of what RUN in a Dockerfile does. It executes the command during the build of the image. That would be handled by a shell provisioner in Packer. 

What process gets started when you run the container from the resulting image is handled by ENTRYPOINT and CMD those can be set in packer with the changes 1).

So to produce a image that runs systemd do:

a) shell provisioner to install systemd and services

b) change the ENTRYPOINT/CMD in changes to run systemd.

1) https://packer.io/docs/builders/docker.html#changes

// Rickard

PS. Multiprocess containers can (and should) really be questioned.

--

This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/mitchellh/packer/issues
IRC: #packer-tool on Freenode
---
You received this message because you are subscribed to the Google Groups "Packer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to packer-tool...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/packer-tool/72c11e2b-38c1-2890-8ba0-ae3da7012f40%40datameer.com.

[Justin DynamicD]

Im going to go in a different direction:  why are we pre-installing a docker image on your server image?  Seems like a pretty strong anti pattern (saves very little deployment time and ties infra to app).

[Vincent Rubiolo]

Hi Rickard,

On 2/12/19 11:48 AM, Rickard von Essen wrote:

I think there is som confusion of what RUN in a Dockerfile does. It executes the command during the build of the image. That would be handled by a shell provisioner in Packer. 

What process gets started when you run the container from the resulting image is handled by ENTRYPOINT and CMD those can be set in packer with the changes 1).

So to produce a image that runs systemd do:

a) shell provisioner to install systemd and services

b) change the ENTRYPOINT/CMD in changes to run systemd.

1) https://packer.io/docs/builders/docker.html#changes

Thanks for the clarification between running a container and building it, this was needed indeed (I realized my explanation might not have been clear enough on this front).

Vincent

[Daniel Ortega]

Hi all,

I think there is som confusion of what RUN in a Dockerfile does

I don't agree, my problem it's about something that is called "docker builder" in Packer cannot be used to build anything (as I cannot execute any "RUN" command). Maybe it's a semantic question.

So to produce a image that runs systemd do:

a) shell provisioner to install systemd and services

b) change the ENTRYPOINT/CMD in changes to run systemd.

It's clear to me that using some provisioners you can do a workaround for other cases, but I think that is not for systemd. AFAIK, systemd should be the first daemon to start and the last daemon to stop. 

Thanks everyone for your suggestions! :)

[Rickard von Essen]

Since I fail to explain how this works I suggest that you post an example Dockerfile here and I'll translate it to a similar Packer template.

To view this discussion on the web visit https://groups.google.com/d/msgid/packer-tool/0995fd92-484f-4b8d-9685-3dff1e4aae3d%40googlegroups.com.

[Vincent Rubiolo]

Hi Daniel,

On 2/14/19 5:57 AM, Daniel Ortega wrote:

I think there is som confusion of what RUN in a Dockerfile does

I don't agree, my problem it's about something that is called "docker builder" in Packer cannot be used to build anything (as I cannot execute any "RUN" command). Maybe it's a semantic question.

We use the Packer Docker builder on a daily basis to build containers for k8s and this works well for us so I think your stance is a bit strong :)

So to produce a image that runs systemd do:

a) shell provisioner to install systemd and services

b) change the ENTRYPOINT/CMD in changes to run systemd.

It's clear to me that using some provisioners you can do a workaround for other cases, but I think that is not for systemd. AFAIK, systemd should be the first daemon to start and the last daemon to stop.

Do you have any evidence to support that claim? The 'first thing to start and last to stop' is from a runtime point of view when the container is running. When building, I think (but I have not tried) that what only matters is that you have systemd running.

As Rickard said, let's see with your sample Dockerfile what you want to do.

Vincent

[Vincent Rubiolo]

Hi Daniel,

Any followups on this issue?

Thanks for the heads-up,

Vincent

To view this discussion on the web visit https://groups.google.com/d/msgid/packer-tool/CALz9Rt_NvJEt%3DQFkejfx7NqcdAbMMLxiKK3d4JZ0Z%2Bu0y-di7Q%40mail.gmail.com.

[Daniel Ortega]

Hi Vincent,

As I wasn't capable to do that with Packer, I finally use Ansible to build my Docker Image. 

I wan't able with Packer to take our JDK image (idealista/jdk:8u181-stretch-openjdk-headless that is Debian Stretch with openJDK installed), then install systemd and systemd-sysv (using RUN or similar) and finally declare /sbin/init as command to launch the container by default using CMD. 

Needed changes could be seen in this Dockerfile: 

https://github.com/idealista/zookeeper_role/blob/ab15bee3a92a8a62a09d0c7cd33326f5a5936bd9/dockerhub/Dockerfile

We need to install those packages because our ZooKeeper role needs it. As I describe in other messages, AFAIK if you want to use systemd, that process should be the first process started in that container.

TL;DR it's impossible to me to install a package (in this case systemd) in docker build phase and then use it to launch the container.

Is it possible to achieve that using Packer instead of a Dockerfile + Ansible?

Thanks in advance,

Daniel