test-kitchen / kitchen-docker Goto Github PK

A Test Kitchen Driver for Docker

License: Apache License 2.0

Ruby 97.61% Dockerfile 1.44% PowerShell 0.95%

managed-by-terraform hacktoberfest ruby-gem test-kitchen testing ruby

kitchen-docker's Introduction

Test Kitchen


Website	https://kitchen.ci/
Source Code	https://kitchen.ci/docs/getting-started/introduction/
Slack	#test-kitchen channel on Chef Community Slack

Test Kitchen is an integration tool for developing and testing infrastructure code and software on isolated target platforms.

Getting Started Guide

To learn how to install and setup Test Kitchen for developing infrastructure code, check out the Getting Started Guide.

If you want to get going super fast, then try the Quick Start next...

Quick Start

Test Kitchen is a RubyGem and can be installed with:

gem install test-kitchen

If you use Bundler, you can add gem "test-kitchen" to your Gemfile and make sure to run bundle install.

Next add support to your library, Chef cookbook, or empty project with kitchen init:

kitchen init

A kitchen.yml file will be created in your project base directory. This file describes your testing configuration; what you want to test and on which target platforms. Each of these suite and platform combinations are called instances. By default your instances will be converged with Chef Solo and run in Vagrant virtual machines.

Get a listing of your instances with:

kitchen list

Run Chef Infra Client on an instance, in this case default-ubuntu-2004, with:

kitchen converge default-ubuntu-2004

Destroy all instances with:

kitchen destroy

You can clone a Chef Infra cookbook project that contains Test Kitchen support and run through all the instances in serial by running:

kitchen test

Usage

There is help included with the kitchen help subcommand which will list all subcommands and their usage:

kitchen help test

More verbose logging for test-kitchen can be specified when running test-kitchen from the command line using:

kitchen test -l debug

For the provisioner (e.g. chef-solo or chef-infra) add a log_level item to the provisioner section of the .kitchen.yml For more information on setting log_level see the configuration documentation.

Documentation

Documentation is being added on the Test Kitchen website. Please read and contribute to improve them!

Versioning

Test Kitchen aims to adhere to Semantic Versioning 2.0.0.

Community and Ecosystem

If you would like to see a few of the plugins or ecosystem helpers, please look at ECOSYSTEM.md.

Development

Source hosted at GitHub
Report issues/questions/feature requests on GitHub Issues

Pull requests are very welcome! Make sure your patches are well tested. Ideally create a topic branch for every separate change you make. For example:

Fork the repo
Create your feature branch (git checkout -b my-new-feature)
Commit your changes (git commit -am 'Added some feature')
Push to the branch (git push origin my-new-feature)
Create a new Pull Request

Authors

Created by Fletcher Nichol ([email protected]).

Maintained by Chef Software and a growing community of contributors.

License

Apache License, Version 2.0 (see LICENSE)

kitchen-docker's People

Contributors

Stargazers

Watchers

Forkers

fujin bhouse agoddard ricardoamaro petecheslock computerlyrik adnichols inokappa nathwill webframp coderanger trinitronx johnrengelman spheromak adorechic ewr grepory kanoapps muratayusuke madhatter schrodinger atomic-penguin jgillis01 nyasukun aigeruth kavanista aleredevices peterabbott casvannoort nberg miketheman tbe tkak nathanzook mohitsethi paulpeterson grubernaut jeanmertz amaltson kisoku marcy-terui flashvoid darklore phosphene lusis alteryx appneta mmalcze ekrupnik projectflorida tknerr sivgeet cpakman patcon mauriceteunissen http-418 tragus rhass-r7 canademar msabramo zuazo-forks wtanaka lengshuiyulangcn snahelou pnaicker333 rifelpet sgerrand proffalken h4ck3rm1k3 jdrago999 puckel miry livingstaccato hartmantis jefflaplante jedipunkz corux timani mmckinst acondrat walterdolce thedrow redfive chris-rock td-4242 shift konstantinous ehartmann aaronblythe krestenkjaer drrk dsklopp karouf tsunokawa jschripsema gregretkowski gregsymons ddaymn me2d change

kitchen-docker's Issues

kitchen-docker can't stop container

Sometimes, kitchen-docker fails to stop the container. It seems that the container is already stopped when kitchen-docker is going to stop it, and then fails. Here's the output of a sudo kitchen test --destroy=passing:

[0m�[31m>>>>>> ------Exception-------�[0m
�[31m>>>>>> Class: Kitchen::ActionFailed�[0m
�[31m>>>>>> Message: Failed to complete #destroy action: [Expected process to exit with [0], but received '1'
---- Begin output of docker -H unix:///var/run/docker.sock stop dac87b6c073df63e7f58613300e146cfeff137e5d191f6ecddd08f9542434acd ----
STDOUT: 
STDERR: Error response from daemon: Cannot stop container dac87b6c073df63e7f58613300e146cfeff137e5d191f6ecddd08f9542434acd: no such process
2014/10/30 00:48:30 Error: failed to stop one or more containers
---- End output of docker -H unix:///var/run/docker.sock stop dac87b6c073df63e7f58613300e146cfeff137e5d191f6ecddd08f9542434acd ----
Ran docker -H unix:///var/run/docker.sock stop dac87b6c073df63e7f58613300e146cfeff137e5d191f6ecddd08f9542434acd returned 1]�[0m
�[31m>>>>>> ----------------------�[0m
�[31m>>>>>> Please see .kitchen/logs/kitchen.log for more details�[0m
�[31m>>>>>> Also try running `kitchen diagnose --all` for configuration
�[0m

I have no clue why are we experiencing this issue, but it's annoying because in our ci the run is reported as failure, although tests passed.

Here's the log from kitchen.log:

I, [2014-10-29T22:57:49.706244 #31107]  INFO -- Kitchen: -----> Starting Kitchen (v1.2.1)
I, [2014-10-29T22:57:52.122111 #31107]  INFO -- Kitchen: -----> Cleaning up any prior instances of <kurento-dev-integration-ubuntu-1404>
I, [2014-10-29T22:57:52.122879 #31107]  INFO -- Kitchen: -----> Destroying <kurento-dev-integration-ubuntu-1404>...
I, [2014-10-29T22:57:52.246725 #31107]  INFO -- Kitchen: -----> Testing <kurento-dev-integration-ubuntu-1404>
I, [2014-10-29T22:57:52.247248 #31107]  INFO -- Kitchen: -----> Creating <kurento-dev-integration-ubuntu-1404>...
I, [2014-10-29T22:57:56.090282 #31107]  INFO -- Kitchen: -----> Converging <kurento-dev-integration-ubuntu-1404>...
I, [2014-10-30T00:47:53.554371 #31107]  INFO -- Kitchen: -----> Setting up <kurento-dev-integration-ubuntu-1404>...
I, [2014-10-30T00:47:53.596585 #31107]  INFO -- Kitchen: -----> Verifying <kurento-dev-integration-ubuntu-1404>...
I, [2014-10-30T00:47:53.602269 #31107]  INFO -- Kitchen: -----> Destroying <kurento-dev-integration-ubuntu-1404>...
E, [2014-10-30T00:48:30.375460 #31107] ERROR -- Kitchen: ------Exception-------
E, [2014-10-30T00:48:30.375663 #31107] ERROR -- Kitchen: Class: Kitchen::ActionFailed
E, [2014-10-30T00:48:30.375785 #31107] ERROR -- Kitchen: Message: Failed to complete #destroy action: [Expected process to exit with [0], but received '1'
---- Begin output of docker -H unix:///var/run/docker.sock stop dac87b6c073df63e7f58613300e146cfeff137e5d191f6ecddd08f9542434acd ----
STDOUT: 
STDERR: Error response from daemon: Cannot stop container dac87b6c073df63e7f58613300e146cfeff137e5d191f6ecddd08f9542434acd: no such process
2014/10/30 00:48:30 Error: failed to stop one or more containers
---- End output of docker -H unix:///var/run/docker.sock stop dac87b6c073df63e7f58613300e146cfeff137e5d191f6ecddd08f9542434acd ----
Ran docker -H unix:///var/run/docker.sock stop dac87b6c073df63e7f58613300e146cfeff137e5d191f6ecddd08f9542434acd returned 1]
E, [2014-10-30T00:48:30.375903 #31107] ERROR -- Kitchen: ---Nested Exception---
E, [2014-10-30T00:48:30.376003 #31107] ERROR -- Kitchen: Class: Kitchen::ShellOut::ShellCommandFailed
E, [2014-10-30T00:48:30.376097 #31107] ERROR -- Kitchen: Message: Expected process to exit with [0], but received '1'
---- Begin output of docker -H unix:///var/run/docker.sock stop dac87b6c073df63e7f58613300e146cfeff137e5d191f6ecddd08f9542434acd ----
STDOUT: 
STDERR: Error response from daemon: Cannot stop container dac87b6c073df63e7f58613300e146cfeff137e5d191f6ecddd08f9542434acd: no such process
2014/10/30 00:48:30 Error: failed to stop one or more containers
---- End output of docker -H unix:///var/run/docker.sock stop dac87b6c073df63e7f58613300e146cfeff137e5d191f6ecddd08f9542434acd ----
Ran docker -H unix:///var/run/docker.sock stop dac87b6c073df63e7f58613300e146cfeff137e5d191f6ecddd08f9542434acd returned 1
E, [2014-10-30T00:48:30.376233 #31107] ERROR -- Kitchen: ------Backtrace-------
E, [2014-10-30T00:48:30.376344 #31107] ERROR -- Kitchen: /var/lib/gems/1.9.1/gems/test-kitchen-1.2.1/lib/kitchen/shell_out.rb:70:in `rescue in     run_command'
E, [2014-10-30T00:48:30.376454 #31107] ERROR -- Kitchen: /var/lib/gems/1.9.1/gems/test-kitchen-1.2.1/lib/kitchen/shell_out.rb:59:in `run_command'
E, [2014-10-30T00:48:30.376556 #31107] ERROR -- Kitchen: /var/lib/gems/1.9.1/gems/test-kitchen-1.2.1/lib/kitchen/driver/base.rb:158:in `run_command'
E, [2014-10-30T00:48:30.376658 #31107] ERROR -- Kitchen: /var/lib/gems/1.9.1/gems/kitchen-docker-1.5.0/lib/kitchen/driver/docker.rb:111:in     `docker_command'
E, [2014-10-30T00:48:30.376775 #31107] ERROR -- Kitchen: /var/lib/gems/1.9.1/gems/kitchen-docker-1.5.0/lib/kitchen/driver/docker.rb:246:in `rm_container'
E, [2014-10-30T00:48:30.376867 #31107] ERROR -- Kitchen: /var/lib/gems/1.9.1/gems/kitchen-docker-1.5.0/lib/kitchen/driver/docker.rb:87:in `destroy'
E, [2014-10-30T00:48:30.377009 #31107] ERROR -- Kitchen: /var/lib/gems/1.9.1/gems/test-kitchen-1.2.1/lib/kitchen/instance.rb:273:in `public_send'
E, [2014-10-30T00:48:30.377107 #31107] ERROR -- Kitchen: /var/lib/gems/1.9.1/gems/test-kitchen-1.2.1/lib/kitchen/instance.rb:273:in `block in     perform_action'
E, [2014-10-30T00:48:30.377249 #31107] ERROR -- Kitchen: /var/lib/gems/1.9.1/gems/test-kitchen-1.2.1/lib/kitchen/instance.rb:308:in `call'
E, [2014-10-30T00:48:30.377350 #31107] ERROR -- Kitchen: /var/lib/gems/1.9.1/gems/test-kitchen-1.2.1/lib/kitchen/instance.rb:308:in `synchronize_or_call'
E, [2014-10-30T00:48:30.377446 #31107] ERROR -- Kitchen: /var/lib/gems/1.9.1/gems/test-kitchen-1.2.1/lib/kitchen/instance.rb:283:in `block in action'
E, [2014-10-30T00:48:30.377535 #31107] ERROR -- Kitchen: /usr/lib/ruby/1.9.1/benchmark.rb:280:in `measure'
E, [2014-10-30T00:48:30.377627 #31107] ERROR -- Kitchen: /var/lib/gems/1.9.1/gems/test-kitchen-1.2.1/lib/kitchen/instance.rb:282:in `action'
E, [2014-10-30T00:48:30.377733 #31107] ERROR -- Kitchen: /var/lib/gems/1.9.1/gems/test-kitchen-1.2.1/lib/kitchen/instance.rb:273:in `perform_action'
E, [2014-10-30T00:48:30.377838 #31107] ERROR -- Kitchen: /var/lib/gems/1.9.1/gems/test-kitchen-1.2.1/lib/kitchen/instance.rb:268:in `destroy_action'
E, [2014-10-30T00:48:30.377967 #31107] ERROR -- Kitchen: /var/lib/gems/1.9.1/gems/test-kitchen-1.2.1/lib/kitchen/instance.rb:246:in `block in     transition_to'
E, [2014-10-30T00:48:30.378062 #31107] ERROR -- Kitchen: /var/lib/gems/1.9.1/gems/test-kitchen-1.2.1/lib/kitchen/instance.rb:245:in `each'
E, [2014-10-30T00:48:30.378150 #31107] ERROR -- Kitchen: /var/lib/gems/1.9.1/gems/test-kitchen-1.2.1/lib/kitchen/instance.rb:245:in `transition_to'
E, [2014-10-30T00:48:30.378240 #31107] ERROR -- Kitchen: /var/lib/gems/1.9.1/gems/test-kitchen-1.2.1/lib/kitchen/instance.rb:152:in `destroy'
E, [2014-10-30T00:48:30.378331 #31107] ERROR -- Kitchen: /var/lib/gems/1.9.1/gems/test-kitchen-1.2.1/lib/kitchen/instance.rb:171:in `block in test'
E, [2014-10-30T00:48:30.378429 #31107] ERROR -- Kitchen: /usr/lib/ruby/1.9.1/benchmark.rb:280:in `measure'
E, [2014-10-30T00:48:30.378514 #31107] ERROR -- Kitchen: /var/lib/gems/1.9.1/gems/test-kitchen-1.2.1/lib/kitchen/instance.rb:166:in `test'
E, [2014-10-30T00:48:30.378599 #31107] ERROR -- Kitchen: /var/lib/gems/1.9.1/gems/test-kitchen-1.2.1/lib/kitchen/command.rb:109:in `public_send'
E, [2014-10-30T00:48:30.378686 #31107] ERROR -- Kitchen: /var/lib/gems/1.9.1/gems/test-kitchen-1.2.1/lib/kitchen/command.rb:109:in `block (2 levels) in     run_action'
E, [2014-10-30T00:48:30.378784 #31107] ERROR -- Kitchen: ----------------------

Support for --net switch

Hi there,

Many thanks for creating this excellent driver! Would it be possible to add an option to start containers with the --net switch, "--net host" for example?

Without this, statements such as:
/sbin/sysctl -w net.ipv4.tcp_syncookies=1

Fail at the moment, as this does not appear to be exposed without setting the --net host switch.

Not sure if this will break anything else however.

Thanks!

OracleLinux 5 container converge error: closed stream

https://gist.github.com/stormerider/c92325be6cd0931f3e36

Has anyone seen this kind of thing before? I'm really not sure what's going on there. As far as I can tell, for some reason during the run, the docker container seems to just go away. I'm not sure if that's because chef-solo failed and it terminated automatically, or if TK reaped it because it lost communication, or what.

If I restart the container, I'm able to run chef-solo fine.

Does docker keep a log of container spinups/commands/etc., beyond what the kitchen log would show? As you can see in the gist, the Kitchen log doesn't really show much more than inside the kitchen verify.

I'm stumped as to what's going on and could really use some assistance in how to best go about debugging this, because I'm at a total loss.

uninitialized constant Syck (NameError)

Running into the following error with Syck in Gemfile&installed.
Using rvm and ruby 2.2.0.
Please advice.

.rvm/gems/ruby-2.2.0/gems/safe_yaml-0.9.7/lib/safe_yaml/syck_node_monkeypatch.rb:42:in `<top (required)>': uninitialized constant Syck (NameError)

Support for berkshelf

I'm working today with vagrant, vagrant-lxc, kitchen-vagrant and vagrant-berkshelf which is a really good stack to help test chef recipes.

I recently tried docker to manage container images and I wanted to give kitchen-docker a try. It is really great, but today the berkshelf part is really missing to be able to test recipes with dependencies (all chef recipes).

What should be done to add berkshelf support ?
Thanks for your help

"Driver usage" docs URL is a dead link

I started trying to setup kitchen-docker last night and noticed in the README.md that the link for "Driver usage" under "Installation and Setup" is a dead link. Any chance of pointing this to something helpful? Many thanks!!

/var/run/sshd is now created in a tmpfs and ephemeral

One of the things that kitchen-docker does to set up a testing container is to create the /var/run/sshd directory and commit that to an image. However, as of moby/moby@905795e , this will no longer work as every time you restart the container /run (hence /var/run/sshd) will get blown away.

It seems like we should create a script to run sshd after creating /var/run/sshd, and use that as the container command instead. This script could be staged during Dockerfile preparation.

{code}

!/bin/sh

mkdir -p /var/run/sshd
exec /usr/sbin/sshd -D -o UsePAM=no -o UseDNS=no
{code}

Message of "Waiting for localhost 22" does not stop.

When I execute the "kitchen create": message of "Waiting for localhost 22" does not stop.I discovered that the port number of the container is not known to test-kitchen-1.0.0.beta.4/lib/kitchen/ssh.rb.

I wonder if it happens around only me.
Please confirm following.

My Environment

Ubuntu 13.10
lxc-docker-0.6.7
kitchen-docker 0.10.0
test-kitchen 1.0.0.beta.4

My .kitchen.yml


---
driver_plugin: docker
driver_config:
  require_chef_omnibus: true

platforms:
- name: ubuntu-12.04
  driver_config:
    username: kitchen
    password: kitchen

suites:
- name: default
  run_list: ["recipe[cookbook]"]
  attributes: {}

Step

following execute steps

sudo bundle exec kitchen create

Waiting for localhost:22... does not stop

       }]
       [kitchen::driver::docker command] END (0m0.02s)
       Waiting for localhost:22...
       Waiting for localhost:22...

To Press Ctrl + C stop.

container status

CONTAINER ID        IMAGE               COMMAND                CREATED              STATUS              PORTS                   NAMES
348afb81f484        8648dff97a96        /usr/sbin/sshd -D -o   About a minute ago   Up About a minute   0.0.0.0:49190->22/tcp   slate_fish

Question: if bind_uri is deprecated, how remotelly access docker instance

Hi, I would like to run kitchen tests on remote docker. For this purpose I use vagrant to deploy docker instance using your cookbook.

However to use it, then I need to access it remotely (and for sure securely). So I agree using exposed port 4242 through bind_uri is not secure and deprecated, but what are the other alternatives?

Do we have cookboos that expose the docker.sock over https?
Does Kitchen-CI have an option to tunnel remote unix:/var/run/docker.sock socket to kitchen host?

Thanks in advance.

kitchen converge fails behind proxy

If configured my driver with the proxy settings. But converging the image fails because the proxy settings are only used for executing commands but not in the Dockerfile itself, which kitchen-docker creates. The build_dockerfile method doesn't use the proxy. Therefore the apt-get update fails ... I'd suggest to rewrite this step be be issued as a command, once the docker image has been built. The problem here is if I'm going to include the proxy in the Dockerfile this image only works with this proxy. That's the reason all RUN commands have to be executed after the image has been converged and must not be part of the Dockerfile itself.

fedora platform not supported

Probably needs to be placed in here.

Looks like ti might be legit: https://registry.hub.docker.com/_/fedora/tags/manage/

Seeing double output for bats tests

I'm running via https://github.com/fnichol/dvm on OS X using chef zero as provisioner, and I see output like this.

I'm not sure where the problem is… If I try to run with -l warn then all test output is printed on the same line, overwriting itself, so I only end up seeing one line with the name of one test.

Running the same suite on a plain VM with vagrant driver shows correct output.

getting docker usage output when running kitchen command

Hi,
I don't know when it started but now there is an annoying bug,

Whenever I run kitchen with a subcommand, I get the docker usage in the output.

Unable to upload Chef files - SSH

I am trying to get Test Kitchen to use Docker containers for our Chef cookbook testing, using chef-solo.

I have the following installed on my machine:

test-kitchen (1.2.1)
docker (1.3.2)
kitchen-docker (1.7.0)

I have a Dockerfile as shown below, which installs the version of Chef we use, as well as the gems needed for testing, etc.

FROM centos:centos6
MAINTAINER Eric Krupnik <[email protected]>

# Update and install base tools
RUN yum update -y && yum groupinstall -y "Development Tools"

# Install packages needed for Ruby and rmv
RUN yum install -y gcc-c++ patch readline readline-devel zlib zlib-devel
RUN yum install -y libyaml-devel libffi-devel openssl-devel make
RUN yum install -y bzip2 autoconf automake libtool bison iconv-devel
RUN yum install -y which tar

# Install Ruby Version Manager (rvm)
RUN gpg --keyserver hkp://keys.gnupg.net --recv-keys D39DC0E3
RUN curl -L get.rvm.io | bash -s stable
RUN source /usr/local/rvm/scripts/rvm
RUN source /etc/profile.d/rvm.sh

# Install Ruby 1.9.3
RUN /bin/bash -l -c "rvm requirements"
RUN /bin/bash -l -c "rvm install 1.9.3"

# Set the Ruby version to use
RUN /bin/bash -l -c "rvm use 1.9.3 --default"

# By default, add the --no-ri and --no-doc to all 'gem install' commands
RUN echo "gem: --no-ri --no-rdoc" > ~/.gemrc

# Install the gems
RUN /bin/bash -l -c "gem install bundler"
RUN /bin/bash -l -c "gem install ohai -v=6.18.0"
RUN /bin/bash -l -c "gem install chef -v=11.6.0"
RUN /bin/bash -l -c "gem install ruby-shadow"
RUN /bin/bash -l -c "gem install minitest-chef-handler -v=1.0.1"
RUN /bin/bash -l -c "gem install ci_reporter -v=1.9.0"
RUN /bin/bash -l -c "gem uninstall ci_reporter -v=2.0.0" || true
RUN /bin/bash -l -c "gem install mixlib-shellout -v=1.4.0"
RUN /bin/bash -l -c "gem uninstall mixlib-shellout -v=1.6.0" || true
RUN /bin/bash -l -c "gem uninstall ohai -v=7.4.0" || true

# Create and populate Test Kitchen cache
# Note: The trailing slashes for the destination are required
RUN mkdir -p /tmp/kitchen/cache
ADD <our_artifactory_url>/com/oracle/java/jdk/7u67/jdk-7u67-linux-x64.tar.gz /tmp/kitchen/cache/
ADD <our_artifactory_url>/org/apache/tomcat/apache-tomcat/7.0.56/apache-tomcat-7.0.56.tar.gz /tmp/kitchen/cache/

I am successfully able to build an image using this Dockerfile, by running the command:

 docker build -t="ekrupnik/test:latest" .

and can confirm that the image exists by running docker images:


REPOSITORY          TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
ekrupnik/test       latest              ca982e782896        27 hours ago          809.3 MB

I then try to set my .kitchen.yml file to use this newly built image, which has the version of Chef I want already installed, and cache preloaded for faster test cycles. My .kitchen.yml file looks like:


---
driver_plugin: docker
driver:
  name: docker
  use_sudo: false
driver_config:
  require_chef_omnibus: false

platforms:
- name: centos
  driver_config:
    platform: centos
    image: ekrupnik/test:latest
suites:
- name: default
  provisioner:
    solo_rb:
      environment: CHEFDEV
  encrypted_data_bag_secret_key_path: "<path_to_the_key>"
  data_bags_path: "../../data_bags"
  roles_path: "../../roles"
  environments_path: "../../environments"
  run_list: ["recipe[rup_utils]", "recipe[minitest-handler]"]
  attributes:
    cloud:
      provider: "ec2"

Looking at the kitchen-docker code, I can see that the docker driver will add certain packages (mostly login and SSH related), both for centos specific packages and then also for all platforms.

When I run kitchen-test -l=debug, I can see it is using the ekrupnik/test:latest and then gets permission denied error when uploading files starts:

-----> Starting Kitchen (v1.2.1)
D      [kitchen::driver::docker command] BEGIN (docker >> /dev/null 2>&1)
D      [kitchen::driver::docker command] END (0m0.02s)
D      Berksfile found at /RUP/workspaces/infrastructure/ccc-chef/cookbooks/rup_utils/Berksfile, loading Berkshelf
/home/cccadmin/.rvm/gems/ruby-1.9.3-p551/gems/json-1.8.1/lib/json/version.rb:3: warning: already initialized constant VERSION
/home/cccadmin/.rvm/gems/ruby-1.9.3-p551/gems/json-1.8.1/lib/json/version.rb:4: warning: already initialized constant VERSION_ARRAY
/home/cccadmin/.rvm/gems/ruby-1.9.3-p551/gems/json-1.8.1/lib/json/version.rb:5: warning: already initialized constant VERSION_MAJOR
/home/cccadmin/.rvm/gems/ruby-1.9.3-p551/gems/json-1.8.1/lib/json/version.rb:6: warning: already initialized constant VERSION_MINOR
/home/cccadmin/.rvm/gems/ruby-1.9.3-p551/gems/json-1.8.1/lib/json/version.rb:7: warning: already initialized constant VERSION_BUILD
/home/cccadmin/.rvm/gems/ruby-1.9.3-p551/gems/json-1.8.1/lib/json/common.rb:99: warning: already initialized constant NaN
/home/cccadmin/.rvm/gems/ruby-1.9.3-p551/gems/json-1.8.1/lib/json/common.rb:101: warning: already initialized constant Infinity
/home/cccadmin/.rvm/gems/ruby-1.9.3-p551/gems/json-1.8.1/lib/json/common.rb:103: warning: already initialized constant MinusInfinity
/home/cccadmin/.rvm/gems/ruby-1.9.3-p551/gems/json-1.8.1/lib/json/common.rb:128: warning: already initialized constant UnparserError
D      Berkshelf 2.0.14 library loaded
-----> Cleaning up any prior instances of <default-centos>
-----> Destroying <default-centos>...
       Finished destroying <default-centos> (0m0.00s).
-----> Testing <default-centos>
-----> Creating <default-centos>...
D      [kitchen::driver::docker command] BEGIN (docker -H unix:///var/run/docker.sock build -)
       Sending build context to Docker daemon  2.56 kB
       Sending build context to Docker daemon
       Step 0 : FROM ekrupnik/test:latest
        ---> 380c1d1d996b
       Step 1 : RUN yum clean all
        ---> Using cache
        ---> 4d207a3c779f
       Step 2 : RUN yum install -y sudo openssh-server openssh-clients which curl
        ---> Using cache
        ---> ae2e40e2de42
       Step 3 : RUN ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key -N ''
        ---> Using cache
        ---> 5e84cf748f84
       Step 4 : RUN ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key -N ''
        ---> Using cache
        ---> 3d2e1f2b8476
       Step 5 : RUN useradd -d /home/kitchen -m -s /bin/bash kitchen
        ---> Using cache
        ---> 822b8c1fe35f
       Step 6 : RUN echo kitchen:kitchen | chpasswd
        ---> Using cache
        ---> 14aaba805c8f
       Step 7 : RUN echo 'kitchen ALL=(ALL) NOPASSWD:ALL' >> /etc/sudoers
        ---> Using cache
        ---> c767c1a531ef
       Step 8 : RUN echo 'kitchen ALL=(ALL) NOPASSWD:ALL' >> /etc/sudoers.d/kitchen
        ---> Using cache
        ---> dac87bcf2c14
       Successfully built dac87bcf2c14
D      [kitchen::driver::docker command] END (0m0.42s)
D      [kitchen::driver::docker command] BEGIN (docker -H unix:///var/run/docker.sock run -d -p 22 dac87bcf2c14 /usr/sbin/sshd -D -o UseDNS=no -o UsePAM=no -o PasswordAuthentication=yes -o UsePrivilegeSeparation=no -o PidFile=/tmp/sshd.pid)
       511a400bdd456b8be5e5bb41c8f34f5e22f9754a75153e9ee9df239ce32b50ba
D      [kitchen::driver::docker command] END (0m0.41s)
D      [kitchen::driver::docker command] BEGIN (docker -H unix:///var/run/docker.sock inspect 511a400bdd456b8be5e5bb41c8f34f5e22f9754a75153e9ee9df239ce32b50ba)
       [{
           "AppArmorProfile": "",
           "Args": [
        "-D",
        "-o",
        "UseDNS=no",
        "-o",
        "UsePAM=no",
        "-o",
        "PasswordAuthentication=yes",
        "-o",
        "UsePrivilegeSeparation=no",
        "-o",
        "PidFile=/tmp/sshd.pid"
           ],
           "Config": {
        "AttachStderr": false,
        "AttachStdin": false,
        "AttachStdout": false,
        "Cmd": [
            "/usr/sbin/sshd",
            "-D",
            "-o",
            "UseDNS=no",
            "-o",
            "UsePAM=no",
            "-o",
            "PasswordAuthentication=yes",
            "-o",
            "UsePrivilegeSeparation=no",
            "-o",
            "PidFile=/tmp/sshd.pid"
        ],
        "CpuShares": 0,
        "Cpuset": "",
        "Domainname": "",
        "Entrypoint": null,
        "Env": [
            "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
        ],
        "ExposedPorts": {
            "22/tcp": {}
        },
        "Hostname": "511a400bdd45",
        "Image": "dac87bcf2c14",
        "Memory": 0,
        "MemorySwap": 0,
        "NetworkDisabled": false,
        "OnBuild": null,
        "OpenStdin": false,
        "PortSpecs": null,
        "StdinOnce": false,
        "Tty": false,
        "User": "",
        "Volumes": null,
        "WorkingDir": ""
           },
           "Created": "2015-01-10T18:36:16.541847658Z",
           "Driver": "devicemapper",
           "ExecDriver": "native-0.2",
           "HostConfig": {
        "Binds": null,
        "CapAdd": null,
        "CapDrop": null,
        "ContainerIDFile": "",
        "Devices": [],
        "Dns": null,
        "DnsSearch": null,
        "ExtraHosts": null,
        "Links": null,
        "LxcConf": [],
        "NetworkMode": "bridge",
        "PortBindings": {
            "22/tcp": [
                {
                    "HostIp": "",
                    "HostPort": ""
                }
            ]
        },
        "Privileged": false,
        "PublishAllPorts": false,
        "RestartPolicy": {
            "MaximumRetryCount": 0,
            "Name": ""
        },
        "SecurityOpt": null,
        "VolumesFrom": null
           },
           "HostnamePath": "/var/lib/docker/containers/511a400bdd456b8be5e5bb41c8f34f5e22f9754a75153e9ee9df239ce32b50ba/hostname",
           "HostsPath": "/var/lib/docker/containers/511a400bdd456b8be5e5bb41c8f34f5e22f9754a75153e9ee9df239ce32b50ba/hosts",
           "Id": "511a400bdd456b8be5e5bb41c8f34f5e22f9754a75153e9ee9df239ce32b50ba",
           "Image": "dac87bcf2c14307c7f3cedbd5a2cefd29bc15d741002957241b41bf5dfea9b91",
           "MountLabel": "system_u:object_r:svirt_sandbox_file_t:s0:c857,c920",
           "Name": "/trusting_brattain",
           "NetworkSettings": {
        "Bridge": "docker0",
        "Gateway": "172.17.42.1",
        "IPAddress": "172.17.0.141",
        "IPPrefixLen": 16,
        "MacAddress": "02:42:ac:11:00:8d",
        "PortMapping": null,
        "Ports": {
            "22/tcp": [
                {
                    "HostIp": "0.0.0.0",
                    "HostPort": "49198"
                }
            ]
        }
           },
           "Path": "/usr/sbin/sshd",
           "ProcessLabel": "system_u:system_r:svirt_lxc_net_t:s0:c857,c920",
           "ResolvConfPath": "/var/lib/docker/containers/511a400bdd456b8be5e5bb41c8f34f5e22f9754a75153e9ee9df239ce32b50ba/resolv.conf",
           "State": {
        "ExitCode": 0,
        "FinishedAt": "0001-01-01T00:00:00Z",
        "Paused": false,
        "Pid": 8647,
        "Restarting": false,
        "Running": true,
        "StartedAt": "2015-01-10T18:36:17.032588383Z"
           },
           "Volumes": {},
           "VolumesRW": {}
       }
       ]
D      [kitchen::driver::docker command] END (0m0.03s)
       Finished creating <default-centos> (0m1.51s).
-----> Converging <default-centos>...
       Preparing files for transfer
D      Creating local sandbox in /tmp/default-centos-sandbox-20150110-8584-cgkxm
       Resolving cookbook dependencies with Berkshelf 2.0.14...
D      Using Berksfile from /RUP/workspaces/infrastructure/ccc-chef/cookbooks/rup_utils/Berksfile
       Removing non-cookbook files before transfer
       Preparing data bags
D      Using data bags from /RUP/workspaces/infrastructure/ccc-chef/data_bags
       Preparing environments
D      Using environments from /RUP/workspaces/infrastructure/ccc-chef/environments
       Preparing roles
D      Using roles from /RUP/workspaces/infrastructure/ccc-chef/roles
       Preparing encrypted data bag secret
D      Using secret from /RUP/.chef/access_data_bag_key_CHEFDEV
D      [SSH] kitchen@localhost:49198<{:user_known_hosts_file=>"/dev/null", :paranoid=>false, :password=>"kitchen", :port=>49198}> (sudo -E rm -rf /tmp/kitchen/cookbooks /tmp/kitchen/data /tmp/kitchen/data_bags /tmp/kitchen/environments /tmp/kitchen/roles /tmp/kitchen/clients ; mkdir -p /tmp/kitchen)
D      [SSH] opening connection to kitchen@localhost:49198<{:user_known_hosts_file=>"/dev/null", :paranoid=>false, :password=>"kitchen", :port=>49198}>
       Transfering files to <default-centos>
D      Cleaning up local sandbox in /tmp/default-centos-sandbox-20150110-8584-cgkxm
>>>>>> ------Exception-------
>>>>>> Class: Kitchen::ActionFailed
>>>>>> Message: Failed to complete #converge action: [scp: /tmp/kitchen/dna.json: Permission denied
]
>>>>>> ----------------------
>>>>>> Please see .kitchen/logs/kitchen.log for more details
>>>>>> Also try running `kitchen diagnose --all` for configuration

D      ------Exception-------
D      Class: Kitchen::ActionFailed
D      Message: Failed to complete #converge action: [scp: /tmp/kitchen/dna.json: Permission denied
]
D      ---Nested Exception---
D      Class: RuntimeError
D      Message: scp: /tmp/kitchen/dna.json: Permission denied

D      ------Backtrace-------
D      /home/cccadmin/.rvm/gems/ruby-1.9.3-p551/gems/net-scp-1.1.2/lib/net/scp.rb:392:in `await_response_state'
D      /home/cccadmin/.rvm/gems/ruby-1.9.3-p551/gems/net-scp-1.1.2/lib/net/scp.rb:363:in `block (3 levels) in start_command'
D      /home/cccadmin/.rvm/gems/ruby-1.9.3-p551/gems/net-ssh-2.7.0/lib/net/ssh/connection/channel.rb:311:in `call'
D      /home/cccadmin/.rvm/gems/ruby-1.9.3-p551/gems/net-ssh-2.7.0/lib/net/ssh/connection/channel.rb:311:in `process'
D      /home/cccadmin/.rvm/gems/ruby-1.9.3-p551/gems/net-ssh-2.7.0/lib/net/ssh/connection/session.rb:222:in `block in preprocess'
D      /home/cccadmin/.rvm/gems/ruby-1.9.3-p551/gems/net-ssh-2.7.0/lib/net/ssh/connection/session.rb:222:in `each'
D      /home/cccadmin/.rvm/gems/ruby-1.9.3-p551/gems/net-ssh-2.7.0/lib/net/ssh/connection/session.rb:222:in `preprocess'
D      /home/cccadmin/.rvm/gems/ruby-1.9.3-p551/gems/net-ssh-2.7.0/lib/net/ssh/connection/session.rb:205:in `process'
D      /home/cccadmin/.rvm/gems/ruby-1.9.3-p551/gems/net-ssh-2.7.0/lib/net/ssh/connection/session.rb:169:in `block in loop'
D      /home/cccadmin/.rvm/gems/ruby-1.9.3-p551/gems/net-ssh-2.7.0/lib/net/ssh/connection/session.rb:169:in `loop'
D      /home/cccadmin/.rvm/gems/ruby-1.9.3-p551/gems/net-ssh-2.7.0/lib/net/ssh/connection/session.rb:169:in `loop'
D      /home/cccadmin/.rvm/gems/ruby-1.9.3-p551/gems/net-ssh-2.7.0/lib/net/ssh/connection/channel.rb:269:in `wait'
D      /home/cccadmin/.rvm/gems/ruby-1.9.3-p551/gems/net-scp-1.1.2/lib/net/scp.rb:279:in `upload!'
D      /home/cccadmin/.rvm/gems/ruby-1.9.3-p551/gems/test-kitchen-1.2.1/lib/kitchen/ssh.rb:70:in `upload!'
D      /home/cccadmin/.rvm/gems/ruby-1.9.3-p551/gems/test-kitchen-1.2.1/lib/kitchen/ssh.rb:76:in `upload_path!'
D      /home/cccadmin/.rvm/gems/ruby-1.9.3-p551/gems/test-kitchen-1.2.1/lib/kitchen/driver/ssh_base.rb:119:in `block in transfer_path'
D      /home/cccadmin/.rvm/gems/ruby-1.9.3-p551/gems/test-kitchen-1.2.1/lib/kitchen/driver/ssh_base.rb:119:in `each'
D      /home/cccadmin/.rvm/gems/ruby-1.9.3-p551/gems/test-kitchen-1.2.1/lib/kitchen/driver/ssh_base.rb:119:in `transfer_path'
D      /home/cccadmin/.rvm/gems/ruby-1.9.3-p551/gems/test-kitchen-1.2.1/lib/kitchen/driver/ssh_base.rb:46:in `block in converge'
D      /home/cccadmin/.rvm/gems/ruby-1.9.3-p551/gems/test-kitchen-1.2.1/lib/kitchen/ssh.rb:47:in `initialize'
D      /home/cccadmin/.rvm/gems/ruby-1.9.3-p551/gems/test-kitchen-1.2.1/lib/kitchen/driver/ssh_base.rb:43:in `new'
D      /home/cccadmin/.rvm/gems/ruby-1.9.3-p551/gems/test-kitchen-1.2.1/lib/kitchen/driver/ssh_base.rb:43:in `converge'
D      /home/cccadmin/.rvm/gems/ruby-1.9.3-p551/gems/test-kitchen-1.2.1/lib/kitchen/instance.rb:273:in `public_send'
D      /home/cccadmin/.rvm/gems/ruby-1.9.3-p551/gems/test-kitchen-1.2.1/lib/kitchen/instance.rb:273:in `block in perform_action'
D      /home/cccadmin/.rvm/gems/ruby-1.9.3-p551/gems/test-kitchen-1.2.1/lib/kitchen/instance.rb:308:in `call'
D      /home/cccadmin/.rvm/gems/ruby-1.9.3-p551/gems/test-kitchen-1.2.1/lib/kitchen/instance.rb:308:in `synchronize_or_call'
D      /home/cccadmin/.rvm/gems/ruby-1.9.3-p551/gems/test-kitchen-1.2.1/lib/kitchen/instance.rb:283:in `block in action'
D      /home/cccadmin/.rvm/rubies/ruby-1.9.3-p551/lib/ruby/1.9.1/benchmark.rb:280:in `measure'
D      /home/cccadmin/.rvm/gems/ruby-1.9.3-p551/gems/test-kitchen-1.2.1/lib/kitchen/instance.rb:282:in `action'
D      /home/cccadmin/.rvm/gems/ruby-1.9.3-p551/gems/test-kitchen-1.2.1/lib/kitchen/instance.rb:273:in `perform_action'
D      /home/cccadmin/.rvm/gems/ruby-1.9.3-p551/gems/test-kitchen-1.2.1/lib/kitchen/instance.rb:256:in `converge_action'
D      /home/cccadmin/.rvm/gems/ruby-1.9.3-p551/gems/test-kitchen-1.2.1/lib/kitchen/instance.rb:246:in `block in transition_to'
D      /home/cccadmin/.rvm/gems/ruby-1.9.3-p551/gems/test-kitchen-1.2.1/lib/kitchen/instance.rb:245:in `each'
D      /home/cccadmin/.rvm/gems/ruby-1.9.3-p551/gems/test-kitchen-1.2.1/lib/kitchen/instance.rb:245:in `transition_to'
D      /home/cccadmin/.rvm/gems/ruby-1.9.3-p551/gems/test-kitchen-1.2.1/lib/kitchen/instance.rb:141:in `verify'
D      /home/cccadmin/.rvm/gems/ruby-1.9.3-p551/gems/test-kitchen-1.2.1/lib/kitchen/instance.rb:170:in `block in test'
D      /home/cccadmin/.rvm/rubies/ruby-1.9.3-p551/lib/ruby/1.9.1/benchmark.rb:280:in `measure'
D      /home/cccadmin/.rvm/gems/ruby-1.9.3-p551/gems/test-kitchen-1.2.1/lib/kitchen/instance.rb:166:in `test'
D      /home/cccadmin/.rvm/gems/ruby-1.9.3-p551/gems/test-kitchen-1.2.1/lib/kitchen/command.rb:109:in `public_send'
D      /home/cccadmin/.rvm/gems/ruby-1.9.3-p551/gems/test-kitchen-1.2.1/lib/kitchen/command.rb:109:in `block (2 levels) in run_action'
D      ----------------------

I can also confirm that the docker container is indeed stared, by running docker ps:

CONTAINER ID        IMAGE               COMMAND                CREATED              STATUS              PORTS                   NAMES
511a400bdd45        dac87bcf2c14        "/usr/sbin/sshd -D -   About a minute ago   Up About a minute   0.0.0.0:49198->22/tcp   trusting_brattain

If I do NOT use the image I built, and just use a community centos image, things seem to work. I do this by removing the line image: ekrupnik/test:latest from my .kitchen.yml file, and enabling the Chef omnibus installer (require_chef_omnibus: true).

Can anyone please suggest what might be wrong? Has anyone run into this before?

CC: @fnichol

Container must be 'rm' as well as 'kill'

Looks like we're killing the container and removing the image -- but the interim containers will still be left on the filesystem.

'docker ps -a' shows 'em.

We should extend https://github.com/portertech/kitchen-docker/blob/master/lib/kitchen/driver/docker.rb#L53 to 'rm' the container after killing.

Failure when checking dependencies

Hello,

kitchen-docker fails to load when checking the dependencies, saying docker cli is not installed.

I managed to debug it and it looks like it's trying to run sudo docker but kitchen-docker does not have a tty available to ask me for a password, so the command fails:

---- Begin output of sudo -E docker > /dev/null ----
STDOUT: 
STDERR: sudo: no tty present and no askpass program specified

So, using export SUDO_ASKPASS=/usr/bin/ssh-askpass works but it's not optimal because it requires inserting my root password everytime I execute kitchen.

Add support for remote docker hosts

Docker can now bind the API daemon to other sockets, including TCP. It would be nice to expose a docker_host config option which just adds the -H option to all the commands. You would still need the docker CLI tools installed locally, but for someone that does dev on a Mac it would be super handy still.

Have to run as root

Everytime I run kitchen test I get this:

------Exception-------
Class: Kitchen::UserError

Message: You must first install the Docker CLI tool http://www.docker.io/gettingstarted/

Please see .kitchen/logs/kitchen.log for more details
Also try running kitchen diagnose --all for configuration

The docker cli tool is in my path:

proberts@MBLTProberts:~$ which docker
/usr/bin/docker

If I run kitchen test as root or using sudo it works fine. I haven't had a lot of time to try and diagnose. My user is a part of the docker group.

I will spend a little more time on it as soon as I am past this project, id really hope to not have to use sudo or root to run kitchen with docker in future projects.

This is on ubuntu 14.04LTS.

ssh to kitchen docker with no need to input password

Forgive me, if it's a solved problem.

Each time I run "kitchen login" to docker container, I will have to input password of "kitchen" manually.
Is there a supported way to inject my ssh key to docker container, to avoid this?

I can wrap this by playing with provision_command, but it would be a little ugly.

Support SUSE platform

Wondering what it would take to support SUSE as a platform.

Comes up without sshd when `run_command: /sbin/init`

Data: https://gist.github.com/jordansissel/dc98a4684b2b07b5a3a8

kitchen converge ... ends up looping saying:

       Waiting for 192.168.59.103:49168...
       Waiting for 192.168.59.103:49168...
       Waiting for 192.168.59.103:49168...

Seems like forever, so I checked the docker container:

% docker exec $(grep container_id .kitchen/default-ubuntu-1404.yml | fex 2) ps -ef
UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  0 06:25 ?        00:00:00 /sbin/init
root        23     1  0 06:25 ?        00:00:00 @sbin/plymouthd --mode=boot --attach-to-session
root        29     1  0 06:25 ?        00:00:00 plymouth-upstart-bridge
root        32     1  0 06:25 ?        00:00:00 mountall --daemon
root      2893     0  0 06:27 ?        00:00:00 ps -ef

Thoughts?

If I docker exec ... to start sshd manually, things work ok.

kitchen-docker does not properly detect Docker CLI tool on Ubuntu 14.04

The Docker CLI tool is called docker.io in the new Ubuntu 14.04 Docker package. When I try using the kitchen-docker plugin on Ubuntu 14.04, I get the following error because it is looking for docker instead of docker.io:

kitchen list
>>>>>> ------Exception-------
>>>>>> Class: Kitchen::UserError
>>>>>> Message: You must first install the Docker CLI tool     http://www.docker.io/gettingstarted/
>>>>>> ----------------------
>>>>>> Please see .kitchen/logs/kitchen.log for more details
>>>>>> Also try running `kitchen diagnose --all` for configuration

Warning: '-privileged' is deprecated, it will be replaced by '--privileged' soon. See usage.

I'm seeing the following errors in the output of kitchen-docker

Warning: '-privileged' is deprecated, it will be replaced by '--privileged' soon. See usage.

I searched the open issues (very quickly) and didn't see anything for this one. It seems like it would likely be a very quick fix.

SSH connection failed

I'm running into an issue where is appears test-kitchen isn't waiting long enough to SSH when I'm using /sbin/init for my run_command. If I wait a couple of second, I can then ssh into the instance. Is this something that can be addressed by kitchen-docker or are there any workarounds I might employ?

I'm trying to solve the problem of runit not starting when the package has been installed. On Debian systems, which I'm testing on, it starts via the inittab and the runit cookbook handles this by issuing a telinit once the package is installed.

$ sudo kitchen converge
-----> Starting Kitchen (v1.2.1)
-----> Creating <default-debian-74>...
       Step 0 : FROM dgivens/wheezy
        ---> f8c92d987c7a
       Step 1 : ENV DEBIAN_FRONTEND noninteractive
        ---> Using cache
        ---> 47cd72727fd3
       Step 2 : RUN dpkg-divert --local --rename --add /sbin/initctl
        ---> Using cache
        ---> 68a0adca627d
       Step 3 : RUN ln -sf /bin/true /sbin/initctl
        ---> Using cache
        ---> 22aa8539b9a5
       Step 4 : RUN apt-get update
        ---> Using cache
        ---> e7a978183de9
       Step 5 : RUN apt-get install -y sudo openssh-server curl lsb-release
        ---> Using cache
        ---> c3c4b40c5f5f
       Step 6 : RUN mkdir -p /var/run/sshd
        ---> Using cache
        ---> 44186f2bdfc1
       Step 7 : RUN useradd -d /home/kitchen -m -s /bin/bash kitchen
        ---> Using cache
        ---> 7bd45f37b4a4
       Step 8 : RUN echo kitchen:kitchen | chpasswd
        ---> Using cache
        ---> b20a2a304c97
       Step 9 : RUN echo 'kitchen ALL=(ALL) NOPASSWD:ALL' >> /etc/sudoers
        ---> Using cache
        ---> bec122d32801
       Successfully built bec122d32801
       e79dce6f1a2b245a4314ece432944f0e93f33783b6e75d76783cbed778b2b652
       [{
           "ID": "e79dce6f1a2b245a4314ece432944f0e93f33783b6e75d76783cbed778b2b652",
           "Created": "2014-03-07T13:59:25.340911399Z",
           "Path": "/sbin/init",
           "Args": [],
           "Config": {
        "Hostname": "e79dce6f1a2b",
        "Domainname": "",
        "User": "",
        "Memory": 0,
        "MemorySwap": 0,
        "CpuShares": 0,
        "AttachStdin": false,
        "AttachStdout": false,
        "AttachStderr": false,
        "PortSpecs": null,
        "ExposedPorts": {
            "22/tcp": {}
        },
        "Tty": false,
        "OpenStdin": false,
        "StdinOnce": false,
        "Env": [
            "HOME=/",
            "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
            "DEBIAN_FRONTEND=noninteractive"
        ],
        "Cmd": [
            "/sbin/init"
        ],
        "Dns": null,
        "Image": "bec122d32801",
        "Volumes": null,
        "VolumesFrom": "",
        "WorkingDir": "",
        "Entrypoint": null,
        "NetworkDisabled": false,
        "OnBuild": null
           },
           "State": {
        "Running": true,
        "Pid": 12513,
        "ExitCode": 0,
        "StartedAt": "2014-03-07T13:59:25.491002705Z",
        "FinishedAt": "0001-01-01T00:00:00Z",
        "Ghost": false
           },
           "Image": "bec122d328011c78d9fe642c0b8d858894c9a5271da51b465831a6e718c935a2",
           "NetworkSettings": {
        "IPAddress": "172.17.0.2",
        "IPPrefixLen": 16,
        "Gateway": "172.17.42.1",
        "Bridge": "docker0",
        "PortMapping": null,
        "Ports": {
            "22/tcp": [
                {
                    "HostIp": "0.0.0.0",
                    "HostPort": "49195"
                }
            ]
        }
           },
           "ResolvConfPath": "/etc/resolv.conf",
           "HostnamePath": "/var/lib/docker/containers/e79dce6f1a2b245a4314ece432944f0e93f33783b6e75d76783cbed778b2b652/hostname",
           "HostsPath": "/var/lib/docker/containers/e79dce6f1a2b245a4314ece432944f0e93f33783b6e75d76783cbed778b2b652/hosts",
           "Name": "/dreamy_davinci5",
           "Driver": "aufs",
           "Volumes": {},
           "VolumesRW": {},
           "HostConfig": {
        "Binds": null,
        "ContainerIDFile": "",
        "LxcConf": [],
        "Privileged": false,
        "PortBindings": {
            "22/tcp": [
                {
                    "HostIp": "0.0.0.0",
                    "HostPort": "49195"
                }
            ]
        },
        "Links": null,
        "PublishAllPorts": false
           }
       }]
       Finished creating <default-debian-74> (0m0.55s).
-----> Converging <default-debian-74>...
       Preparing files for transfer
       Resolving cookbook dependencies with Berkshelf 2.0.14...
       Removing non-cookbook files before transfer
       Preparing data bags
       Preparing environments
       Preparing encrypted data bag secret
       [SSH] connection failed, retrying (#<Net::SSH::Disconnect: connection closed by remote host>)
       [SSH] connection failed, retrying (#<Net::SSH::Disconnect: connection closed by remote host>)
$$$$$$ [SSH] connection failed, terminating (#<Net::SSH::Disconnect: connection closed by remote host>)
>>>>>> Converge failed on instance <default-debian-74>.
>>>>>> Please see .kitchen/logs/default-debian-74.log for more details
>>>>>> ------Exception-------
>>>>>> Class: Kitchen::ActionFailed
>>>>>> Message: connection closed by remote host
>>>>>> ----------------------
daniel.givens@jenkins-n02:~/fusion$ ssh kitchen@localhost -p 49195
The authenticity of host '[localhost]:49195 ([127.0.0.1]:49195)' can't be established.
ECDSA key fingerprint is 84:80:c6:6b:86:bd:47:ed:35:53:0c:e2:99:07:bd:99.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[localhost]:49195' (ECDSA) to the list of known hosts.
kitchen@localhost's password: 
Linux e79dce6f1a2b 3.11.0-13-generic #20-Ubuntu SMP Wed Oct 23 07:38:26 UTC 2013 x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
kitchen@e79dce6f1a2b:~$

Why is docker-api no longer used?

There's no explanation anywhere for why this was removed / moved to the deprecated branch.

Also it would be nice if the CHANGELOG were actually updated with the changes in each version. Currently it's blank / set to version 0.1.0, but the current version of the gem is version 1.2.1

parse_container_id broken in docker 0.4.7

Docker 0.4.7 was just released and parse_container_id is broken. From what I have been able to find out so far in def run_container(state) output = run_command(cmd) is returning a blank string now.

Generic Dockerfile support

I've added this to kitchen-docker-api - feel free to pull this change in or I'm happy to submit a PR for this if there's interest. I feel like this is a better long-term approach to supporting all the variant ways folks want to run containers.

adnichols/kitchen-docker-api#1

volumes don't seem to work the docker way

Looks like I don't have much luck with making volumes work in kitchen-docker.
Added a volume and container inspect shows:

    "Volumes": {
        "/var/lib/activemq": "/var/lib/docker/vfs/dir/20fb19056...."
    },
    "VolumesRW": {
        "/var/lib/activemq": true

I was expecting gem would create a local directory on docker host and attach that to the container, such as in:

    "Volumes": {
        "/var/lib/activemq": "/var/lib/activemq"

I wonder whether u could shed some light on how kitchen-docker gem deals with volumes.

Driver config below:

platforms:
  - name: ubuntu-12.04
    driver_config:
      platform: ubuntu
      require_chef_omnibus: false
      socket: tcp://my.docker.host:5000
      image: myorg/activemq:5.11.1
      use_cache: false
      use_sudo: false
      hostname: amq.my.docker.host
      instance_name: amq
      volume: /var/lib/activemq

Cannot destroy container

Hi!

I'm running test-kitchen with the kitchen-docker driver on CircleCI. Getting this error during a kitchen test run during the destroy phase:

>>>>>> ------Exception-------
>>>>>> Class: Kitchen::ActionFailed
>>>>>> Message: Failed to complete #destroy action: [Expected process to exit with [0], but received '1'
---- Begin output of sudo -E docker -H unix:///var/run/docker.sock rm 0eae74f4d59d1556449cf00051ac4585a49bf3712453e93a26983dff665e448c ----
STDOUT: 
STDERR: Error response from daemon: Cannot destroy container 0eae74f4d59d1556449cf00051ac4585a49bf3712453e93a26983dff665e448c: Driver btrfs failed to remove root filesystem 0eae74f4d59d1556449cf00051ac4585a49bf3712453e93a26983dff665e448c: Failed to destroy btrfs snapshot: operation not permitted
time="2015-01-13T16:43:50Z" level="fatal" msg="Error: failed to remove one or more containers"
---- End output of sudo -E docker -H unix:///var/run/docker.sock rm 0eae74f4d59d1556449cf00051ac4585a49bf3712453e93a26983dff665e448c ----
Ran sudo -E docker -H unix:///var/run/docker.sock rm 0eae74f4d59d1556449cf00051ac4585a49bf3712453e93a26983dff665e448c returned 1]
>>>>>> ----------------------
>>>>>> Please see .kitchen/logs/kitchen.log for more details
>>>>>> Also try running `kitchen diagnose --all` for configuration

More details:

Any ideas?

README needs installation instructions

The README doesn't mention it but rake will hang on Mac OSX unless boot2docker is up and running and you can do docker ps, etc.

Kitchen tests failing on creating /etc/sudoers.d/kitchen

Greetings, I am getting the following error when running kitchen tests with the latest version of kitchen-docker (1.7.0):

Step 8 : RUN echo 'kitchen ALL=(ALL) NOPASSWD:ALL' >> /etc/sudoers.d/kitchen ---> Running in 6231397dcf8f /bin/sh: /etc/sudoers.d/kitchen: No such file or directory

On another box running version 1.5.0 of kitchen-docker, this problem does not exist as the RUN echo '#{username} ALL=(ALL) NOPASSWD:ALL' >> /etc/sudoers.d/#{username} is not in the docker.rb file.

As a workaround, I've deleted this line from my docker.rb file. This is on a CentOS 5 docker container. I have not tested against any other docker OS containers.

Thanks

Using Docker driver in Kitchen (Windows Environment)

I have built docker Client on Windows as per https://ahmetalpbalkan.com/blog/compiling-docker-cli-on-windows/.
I have boot2Docker where my Docker Daemon resides.
I have installed test-kitchen and kitchen-docker driver in windows.

After above setup, I am able to manage boot2docker images in windows environment.

C:\Users\dshah001\kitchen\docker>docker images
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
hello-world latest e45a5af57b00 11 weeks ago 910 B

Issue: When I try running "kitchen list", it still cannot recognize docker CLI.

------Exception-------
Class: Kitchen::UserError

Message: You must first install the Docker CLI tool http://www.docker.io/gettingstarted/

Please see .kitchen/logs/kitchen.log for more details
Also try running kitchen diagnose --all for configuration

My .kitchen.yml file is below:

driver:
name: docker

provisioner:
name: chef_solo

platforms:

name: ubuntu-12.04
name: centos-6.4

suites:

name: default
run_list:
attributes:

Is there something I need to define in my .kitchen.yml so it can recognize my Docker CLI in Windows.

new ubuntu doesn't generate en_US.UTF-8 locale

I hit an issue with some encoding, and noticed this when i rebuild all docker/kitchen boxes:

$ kitchen login no-bag-ubuntu-1204
kitchen@-------'s password:
/usr/bin/xauth:  file /home/kitchen/.Xauthority does not exist
-bash: warning: setlocale: LC_ALL: cannot change locale (en_US.UTF-8)

Resolved it by running:

 $ sudo locale-gen en_US.UTF-8

on the container.

orphan docker instances are left around sometimes

Hi,

I believe this is likely due to .kitchen/#{suite}.yml being out of sync from the actual server. I don't have a working example of this currently; I dealt with it a lot at my last $client when I used kitchen-docker a lot.

Reproducing this typically for me was an early failure after bootstrapping the docker instance. But i'm sure there are more ways to have the suite yaml get out of sync.

Refs #30

Passwordless sudo for 'kitchen' user

Otherwise using sudo for chef, etc, doesn't work as it should. This should be done by the Dockerfile I suppose.

kitchen-docker drive space usage

I was experimenting with kitchen-docker on a rhel machine recently and ran into some issues regarding the /var/lib/docker directory. It seems that a large portion of drive space is consumed during the test kitchen run, and is not recovered afterward. Is this expected behavior? For example, drive space usage for /var during a run looks like:

1.4G (start) -> 11G (converge) -> 7G (after destroy)

even though the base container is relatively small.

I recognize that this is probably due to the way that docker works (as multiple containers are spawned during the run), but any information on how to best manage this would be helpful. I ran a similar test on an ubuntu VM and got the same results.

current .kitchen.yml


---
driver_plugin: docker
driver_config:
  require_chef_omnibus: true
  remove_images: true

platforms:
- name: centos
  driver_config:
    image: centos
    platform: rhel

suites:
- name: default
  run_list: ["recipe[jenkins_wrapper]"]
  attributes: {}

test-kitchen (1.1.1)
kitchen-docker (0.13.0)

Sorry if this is the wrong place to post, the readme indicated this was the preferred avenue for questions.

Methods exceeded maximum allowed ABC complexity

Rake is failing for unknown reasons on my Mac.

rake -tv
** Invoke default (first_time)
** Invoke quality (first_time)
** Invoke cane (first_time)
** Execute cane

Methods exceeded maximum allowed ABC complexity (1):

lib/kitchen/driver/docker.rb Kitchen::Driver::Docker#build_run_command 16

Lines violated style requirements (7):

lib/kitchen/driver/docker.rb:32 Line is >80 characters (88)
lib/kitchen/driver/docker.rb:36 Line is >80 characters (115)
lib/kitchen/driver/docker.rb:37 Line is >80 characters (92)
lib/kitchen/driver/docker.rb:65 Line is >80 characters (91)
lib/kitchen/driver/docker.rb:168 Line is >80 characters (85)
lib/kitchen/driver/docker.rb:218 Line is >80 characters (93)
lib/kitchen/driver/docker.rb:250 Line is >80 characters (88)

Class and Module definitions require explanatory comments on previous line (1):

lib/kitchen/driver/docker/erb.rb:23 DockerERBContext

Total Violations: 9

File transfer bottleneck

Not sure if it's specific to the docker driver, or test kitchen as a whole,
but I experience a bottleneck when I try to converge, saying:
Transferring files to
It takes a while until the files are actually being transferred, and the converge starts.
Can this be resolved by using a mount for the files instead?

Need to be more proactive responding to pull requests and issues

@portertech is it possible that you could show some more love to this project? You had a flurry of merges in December but nothing since then.

If you don't have time or given up on this project, maybe adding more people to the repo so we can get some traction on maintaining the driver.

Add support for --cap-add and --cap-remove flag

In order to run some services, for example tomcat on ubuntu, a container requires the capability SYS_PTRACE, others the init.d daemon startup will fail.

Discovered this while writing some test kitchen serverspec tests and switched from vagrant to docker driver and the tests started failing.

Set container name

Just so I don't forget, it would be nice to have the container name set to something useful like the full suite name (plus random bits or time) so I can figure out which tests are using all my RAM.

kitchen login prompts for password

I've tried to figure out what's not moving along correctly, and finally threw my hands up in the air at my own inability to grok this, so here I am asking about it.

Most kitchen drivers provide the user/name and password, so that you don't have to type a password. kitchen-vagrant handles this correctly.

With kitchen-docker, I must type in the default password any time I want to log in.

I can see that there's a setting for username/password in the code and this user/password combo does indeed work, since the kitchen setup/converge/verify/test all work over ssh, right?

$ kitchen login -l debug source-ubuntu-1204
D      [kitchen::driver::docker command] BEGIN (docker > /dev/null)
D      [kitchen::driver::docker command] END (0m0.00s)
D      Berksfile found at /Users/miketheman/code/miketheman/nginx/Berksfile, loading Berkshelf
D      Berkshelf 3.1.5 library loaded
D      Login command: ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o LogLevel=VERBOSE -p 49156 [email protected] (Options: {})
Warning: Permanently added '[192.168.42.43]:49156' (RSA) to the list of known hosts.
[email protected]'s password:
Authenticated to 192.168.42.43 ([192.168.42.43]:49156).
Last login: Sat Sep  6 14:59:15 2014 from 192.168.42.1
kitchen@3b5d8f92de41:~$

Related gems:

kitchen-docker (1.5.0)
test-kitchen (1.2.1)

My .kitchen.local.yml:

driver:
  name: docker
  socket: tcp://192.168.42.43:2375 # boot2docker

And now I don't know where else to look.

Readme 'driver usage' link not found

On the read me if you click the 'Driver usage' link the server cannot be found - even if you find the correct server in the URL the path is still unknown.

Installation and Setup

Please read the Driver usage page for more details. <= link on this line....

Adding files to build using custom Dockerfile (file not found due to lack of context)

I am specifying a custom dockerfile in my .kitchen.yml.

Reading through how test-kitchen handles this, I can see it shells out using mixlib-shellout and that my docker file is passed as an :input parameter.

By my initial reading of test-kitchen and mixlib-shellout code this means the Dockerfile will be passed to docker client via stdin, and as such (according to my limited knowledge of docker) has no context.

Does this mean I cannot use ADD statements within my custom Dockerfiles when using your driver? Without a context, docker will be unable to locate files.

Any advice for a relative docker newbie would be gratefully received.

OSX Mavericks sudo problem

I am able to partly converge a container whenever I set use:sudo to false. However I need sudo to restart a service and it errors out on my init.d steps. If I set use:sudo to true, I get an error about requirements on docker cli tool.

My setup:
OSX 10.9.4
boot2docker
docker 1.2.0 from brew

[Query] Concurrency

I have a Chef CI pipeline where Jenkins polls cookbook repos and runs /concurrent/ integration tests using in-house developed kitchen-openvz driver. One issue I had with that was that I had to ensure that creation of containers and assigning of IPs are ran synchronously. I really want to switch to docker so I wonder if kitchen-docker cares for these kinds of situations (and does it have to or it's a docker feature/enhancement )

Thoughts on how to support public keys

I been wanting to add support for ssh public keys. I have worked out a method of doing so, but I would like to hear some input before I go ahead and write the code.

These are the steps I have come up with to handle it.

Write out a tmp Dockerfile to /tmp/container_id
Copy the key file to /tmp/container_id
If there was a key add the following new line to the docker file
- ADD keyfile.pub /home/kitchen/.ssh/authorized_keys
Run docker build /tmp/container_id

Writing out the Dockerfile to a directory is necessary to use the ADD command. It will not work with docker build -. If anyone knows of a better way to handle this please let me know.

Save containers from failed 'kitchen test' runs

It would be nice to have a variant to --destroy=always like --destroy=successful to only reap the containers when the build is succesful, and leave the other ones running or at least saved and tagged in their current state.

This way when we have kitchen-docker plugged into continuous integration, rather than needing to repeat the test on our own machine we can just ssh in and peek into the container.

I can come up with a patch, I think, but it might take a while.

We can running the test without using ssh

Thank you for new version release the other day.

We had better not use ssh on Docker container.
See also http://jpetazzo.github.io/2014/06/23/docker-ssh-considered-evil/

And we have some issues like #40 #81

So, I have an idea to solve them.
And the idea has been implemented on this driver plugin that made from scratch.
https://github.com/marcy-terui/kitchen-docker_cli

I started to make the plugin because it was thought to have stopped development.
But, the mainstream of kitchen-docker has resumed development.
And I have welcome it.

@portertech
If you want, I 'm going to make and send some PRs.
But, they become big changes.
Therefore, there are some possibilities that become unstable.
So, I want to hear what you think.

Port mapping

Provide ability to nat ports to the host when running containers.