leverage exec for transport and implements connect_to_machine and stop_machine

[mwrock]

This PR simplifies reconverging and changing the state of running containers by levereging exec in the transport. It also implements connect_to_machine and thus allows one to use the machine_execute and machine_file resources on docker containers.

This ended up being bringing in some fairly deep changes so here are some implementation notes:

• Removes the Gemfile.lock and adds basic entries to the empty .gitignore file to provide a better dev experience.
• Replaces the apache based readme example with the ssh_server cookbook. Currently the apache example fails to start the container. The apache::default recipe is empty and the command /usr/sbin/httpd is not applicable to the ubuntu base image used. Even using /usr/sbin/apache2 and the apache2::default cookbook had some config errors. The ssh_server cookbook just worked and results in a running container.
• There was a fair amount of "dead code" in the transport that I deleted. It was called by the execute_old code deleted over a year ago and I found it added confusion to the class.
• Much of the initial container port, volume, etc. setup is moved to the driver and is now a one-time operation done in machine_allocate and simple runs a vanilla bash loop as suggested by @marc- . machine_allocate now creates the container but it is "unconverged" and not running the final command. However it does have the ports, volumes, etc properly configured.
• So the transport now just delegates to Docker::Container.exec
• Writes to the container writes to the container mount usually located in /var/lib/docker
• This now streams stdout/err similar to most of the other drivers using stream_chunk
• The docker_container_machine commits images after convergence and if the command has changed, starts a new container
• Container and image lookups now prefer IDs and the implementation ensures these are kept in alignment with the machine/image spec.

One thing that is a definite hack and I think is due to a bug in chef-provisioning is this line in allocate_machine:

machine_spec.from_image = action_handler.provider.new_resource.from_image

from_image is not set in the provider until after the call to allocate_machine

I'll submit a separate PR to chef-provisioning to address tis unless someone thinks this is necessary.

[marc-]

I think

container = Docker::Container.create('Image' => image.id, 'Cmd' => Shellwords.split(@command), 'name' => container_name)

more convenient way to run container.

[mwrock]

Its kind of a wash since create doesn't start the container so either way you have to perform 2 operations.

[marc-]

I think it does https://github.com/swipely/docker-api/blob/master/lib/docker/container.rb#L227 . Anyways it's minor and totally up to you.

[mwrock]

@marc- I found a different approach to writing to the container that works on both ubuntu and centos hosts. Just commited it but it writes to the /proc filesystem under the Pid of the container.

[marc-]

Yes, this will work (I actually didn't know, that one can access container's file system this way, good finding).
But what if we have a remote docker daemon? Please checkout following commands:

cat random_file | docker -H 192.168.34.7:2376 exec -i my_container /bin/sh -c 'cat > random_file'

This is for writing file. And following for reading:

docker -H 192.168.34.7:2376 exec -i my_container /bin/sh -c 'cat random_file' > random_file

This will work both for local docker daemon and remote.
I'm currently looking into how to make chef-provisioning-docker work with Docker Swarm (#55), which uses remote docker daemon to communicate with nodes, and I would appreciate if you consider approach above.

[mwrock]

squashed and rebased

[marc-]

I have concerns regarding to while loop here. What if we rather use /bin/sh -l with -i docker run flag instead. Check this:

docker run -i -d ubuntu /bin/sh -l

[mwrock]

what are your concerns? changing this to running interactively fundamentally changes how this all flows. I don't think cmd.run_command would simply return and leave you with a running container.

[tyler-ball]

Hey @mwrock - now that chef-boneyard/chef-provisioning#366 is merged you should just be able to use from_image = machine_options.from_image correct?

[mwrock]

That's right . As long as this gem takes a dependency on the new version of chef-provisioning.

[tyler-ball]

Hey @mwrock - do you need any help getting this across the finish line?

[mwrock]

It has been a couple weeks, but last I checked this all worked well. The only outstanding issue would be refactoring the from_image to use the new code in master in chef-provisioning. We'd want to wait for a new chef-provisioning release and then tie this gem to that version otherwise the refactoring would break. I think that could be done in a separate PR.

Is there anything else here we think needs changing?

[mwrock]

ah sweet thanks!