A working example of a persistent container actually running a service?

[rberger]

So I've been trying to get something that could be used as a complete persistent service and seem to be missing some fundamental concepts. I can't seem to even get chef-metal-docker to create a container and run a command.

I set up chef-zero -H 0.0.0.0 server running on my ubuntu 14.04 workstation instance and uploaded a simple cookbook (https://github.com/rberger/chef-metal-min/cookbooks/min_app and also the apt cookbook)

I'm using this chef-zero server for both the workstation chef-client runs and the container chef-client runs so as to minimize ip address and routing issues.

If I create a provisioner_options in min_app/recipes/min.rb of:

with_provisioner_options 'base_image' => 'ubuntu:precise',  'create_container' => { 'command' =>  'ls -l /opt'}

and do a chef-client run on the workstation:

chef-client -o min_app::min -l info

The chef-client run fails but the container is created and if I start the container again it generates the output:

docker start -i -a 12ee3aafaa9a
total 0

Which shows that the container doesn't have chef installed.

If I then set the provisioner to:

with_provisioner_options 'base_image' => 'ubuntu:precise'

The chef-client run on my workstation will create the min_image docker image but it has the chef-client -l info as the command. (Not sure why it created those extra containers):

$ docker ps -a
CONTAINER ID        IMAGE               COMMAND                CREATED              STATUS              PORTS               NAMES
5f10d4a7230b        8859b13fbf47        chef-client -l info    About a minute ago   Exit 0                                  min
0796e0785921        4d4020697ca8        /bin/sh -c #(nop) AD   2 minutes ago        Exit 0                                  hopeful_engelbart
bab6f286bc43        061845e6cee3        /bin/sh -c #(nop) AD   2 minutes ago        Exit 0                                  hungry_darwin
35d4161453cf        2644d502c274        /bin/sh -c #(nop) AD   2 minutes ago        Exit 0                                  cocky_pike
dfb83a23e339        779457a7795b        /bin/sh -c #(nop) AD   2 minutes ago        Exit 0                                  desperate_pike

If I then change the provisioner to:

with_provisioner_options 'base_image' => 'min_image:latest',  'create_container' => { 'command' =>  'ls -l /opt'}

and then run the chef-client on the workstation it all succeeds (the workstation and the container chef-client runs) but it still executes the command chef-client -l info and not ls -l /opt:

$ docker ps -a
CONTAINER ID        IMAGE               COMMAND                CREATED             STATUS              PORTS               NAMES
bc331b9b81f2        231fbb21f23a        chef-client -l info    18 seconds ago      Exit 0                                  min

So what am I doing wrong? Does anyone have an example of creating a container and confirming that the command is actually executed?

Once I can do that, the next thing would be to know how to make it so the container stays up and runs one or more processes.

Thanks!

[jkeiser]

Yarr, I didn't realize you were asking a question, not a PR, and dove into my interface refactor without looking back. Give me a bit; I've bumped this back in my queue. Super sorry :(

[rberger]

I figured you were. Busy. I'm at Monitorama thru we'd though I may try to do some chef metal hacking at the Wednesday hackathon here if you send out something.

As far as I can tell I could not get the docker Provisioner to build a container and then actually execute the command that was set in the Provisioner options. It would always just run chef-client -l info

---

Robert J . Berger +1 408-838-8896 http://blog.ibd.com

On May 5, 2014, at 10:14 AM, John Keiser [email protected] wrote:

Yarr, I didn't realize you were asking a question, not a PR, and dove into my interface refactor without looking back. Give me a bit; I've bumped this back in my queue. Super sorry :(

— Reply to this email directly or view it on GitHub.

[jkeiser]

CC'ing @tduffield, who is working on a rethink of this provisioner. Your recipe code looks right; I'm unclear why it's not doing what you want. This is the code that it should be switching in to:

https://github.com/opscode/chef-metal-docker/blob/master/lib/chef_metal_docker/docker_provisioner.rb#L82

[rberger]

So nothing I do seems to impact what the command is executed (it always is set to chef-client -l info)

Also noticed that when I run chef-client on the workstation, it runs the stuff on the local machine, and then it seems to fork chef-client on the target container (I think) twice and each time its doing a

- run 'chef-client -l info' on min

Not sure what's up with that.

So again, it would be really helpful to have a real example that clearly runs a command (other than chef-client) on the target container.

[jsierles]

Is this provisioner accepting patches or will it be rewritten? Currently it's not working due to some changes in chef-metal.

[jkeiser]

It will be adjusted very soon to the new changes in chef-metal master--it should still work against the existing released chef-metal, though.

[francoisledroff]

I'm eager to see this chef-metal docker provisioner coming, Will that be align, complement or overlap with the recent announcement on http://docs.opscode.com/containers.html ?

[zfeldstein]

I've recently run into this issue. It seems like a bug with specifying ports in docker_options hash. I was using this as my recipe:

machine 'web_server' do from_image 'web_server' recipe 'apt' recipe 'apache2' chef_environment "ztest" machine_options :docker_options => { :command => '/usr/sbin/apache2ctl -D FOREGROUND' } end

Each time it would only run the chef-client -l auto commands. After debugging it seems that it tries to run my apachec2tl command but fails as the -p switch is thrown with no values to the docker CLI, which causes the command not to run. If I change my recipe to this:

machine 'web_server' do from_image 'web_server' recipe 'apt' recipe 'apache2' chef_environment "ztest" machine_options :docker_options => { :command => '/usr/sbin/apache2ctl -D FOREGROUND', :ports => 80 } end

I can get a container to persist.

[jkeiser]

This is working; but we need to get a working example into the docs. Putting in Ready