test-kitchen / kitchen-docker Goto Github PK
View Code? Open in Web Editor NEWA Test Kitchen Driver for Docker
License: Apache License 2.0
A Test Kitchen Driver for Docker
License: Apache License 2.0
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
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
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
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.
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.
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
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.
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.
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
.
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.
---
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: {}
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 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
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
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.
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.
Otherwise using sudo for chef, etc, doesn't work as it should. This should be done by the Dockerfile I suppose.
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.
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.
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}
mkdir -p /var/run/sshd
exec /usr/sbin/sshd -D -o UsePAM=no -o UseDNS=no
{code}
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
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:~$
Provide ability to nat ports to the host when running containers.
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.
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.
Wondering what it would take to support SUSE as a platform.
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)
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.
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.
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.
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....
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.
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::UserErrorMessage: You must first install the Docker CLI tool http://www.docker.io/gettingstarted/
Please see .kitchen/logs/kitchen.log for more details
Also try runningkitchen diagnose --all
for configuration
My .kitchen.yml file is below:
driver:
name: docker
provisioner:
name: chef_solo
platforms:
suites:
Is there something I need to define in my .kitchen.yml so it can recognize my Docker CLI in Windows.
@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.
Everytime I run kitchen test I get this:
------Exception-------
Class: Kitchen::UserErrorMessage: You must first install the Docker CLI tool http://www.docker.io/gettingstarted/
Please see .kitchen/logs/kitchen.log for more details
Also try runningkitchen 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.
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.
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.
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: ----------------------
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
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.
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?
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.
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!
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 )
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
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.
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:
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.
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?
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.
Probably needs to be placed in here.
Looks like ti might be legit: https://registry.hub.docker.com/_/fedora/tags/manage/
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.
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.