Code Monkey home page Code Monkey logo

kitchen-docker's Introduction

Kitchen-Docker

Build Status Gem Version Coverage License

A Test Kitchen Driver and Transport for Docker.

MAINTAINERS WANTED: This Test-Kitchen driver is currently without a maintainer and has many known issues. If you're interested in maintaining this driver for the long run including expanding the CI testing please reach out on Chef Community Slack: #test-kitchen. Until such a time that this driver is maintained we highly recommend the kitchen-dokken for Chef Infra testing with Docker containers.

Requirements

Installation and Setup

Please read the Test Kitchen docs for more details.

Example (Linux) .kitchen.local.yml:

---
driver:
  name: docker
  env_variables:
    TEST_KEY: TEST_VALUE

platforms:
- name: ubuntu
  run_list:
  - recipe[apt]
- name: centos
  driver_config:
    image: centos
    platform: rhel
  run_list:
  - recipe[yum]

transport:
  name: docker

Example (Windows) .kitchen.local.yml:

---
driver:
  name: docker

platforms:
- name: windows
  driver_config:
    image: mcr.microsoft.com/windows/servercore:1607
    platform: windows
  run_list:
  - recipe[chef_client]

transport:
  name: docker
  env_variables:
    TEST_KEY: TEST_VALUE

Default Configuration

This driver can determine an image and platform type for a select number of platforms.

Examples:

---
platforms:
- name: ubuntu-18.04
- name: centos-7

This will effectively generate a configuration similar to:

---
platforms:
- name: ubuntu-18.04
  driver_config:
    image: ubuntu:18.04
    platform: ubuntu
- name: centos-7
  driver_config:
    image: centos:7
    platform: centos

Configuration

binary

The Docker binary to use.

The default value is docker.

Examples:

  binary: docker.io
  binary: /opt/docker

socket

The Docker daemon socket to use. By default, Docker will listen on unix:///var/run/docker.sock (On Windows, npipe:////./pipe/docker_engine), and no configuration here is required. If Docker is binding to another host/port or Unix socket, you will need to set this option. If a TCP socket is set, its host will be used for SSH access to suite containers.

Examples:

  socket: unix:///tmp/docker.sock
  socket: tcp://docker.example.com:4242

If you are using the InSpec verifier on Windows, using named pipes for the Docker engine will not work with the Docker transport. Set the socket option with the TCP socket address of the Docker engine as shown below:

socket: tcp://localhost:2375

The Docker engine must be configured to listen on a TCP port (default port is 2375). This can be configured by editing the configuration file (usually located in C:\ProgramData\docker\config\daemon.json) and adding the hosts value:

"hosts": ["tcp://0.0.0.0:2375"]

Example configuration is shown below:

{
  "registry-mirrors": [],
  "insecure-registries": [],
  "debug": true,
  "experimental": false,
  "hosts": ["tcp://0.0.0.0:2375"]
}

If you use Boot2Docker or docker-machine set your DOCKER_HOST environment variable properly with export DOCKER_HOST=tcp://192.168.59.103:2375 or eval "$(docker-machine env $MACHINE)" then use the following:

socket: tcp://192.168.59.103:2375

image

The Docker image to use as the base for the suite containers. You can find images using the Docker Index.

The default will be computed, using the platform name (see the Default Configuration section for more details).

isolation

The isolation technology for the container. This is not set by default and will use the default container isolation settings.

For example, the following driver configuration options can be used to specify the container isolation technology for Windows containers:

# Hyper-V
isolation: hyperv

# Process
isolation: process

platform

The platform of the chosen image. This is used to properly bootstrap the suite container for Test Kitchen. Kitchen Docker currently supports:

  • arch
  • debian or ubuntu
  • amazonlinux, rhel, centos, fedora, oraclelinux, almalinux or rockylinux
  • gentoo or gentoo-paludis
  • opensuse/tumbleweed, opensuse/leap, opensuse or sles
  • windows

The default will be computed, using the platform name (see the Default Configuration section for more details).

require_chef_omnibus

Determines whether or not a Chef Omnibus package will be installed. There are several different behaviors available:

  • true - the latest release will be installed. Subsequent converges will skip re-installing if chef is present.
  • latest - the latest release will be installed. Subsequent converges will always re-install even if chef is present.
  • <VERSION_STRING> (ex: 10.24.0) - the desired version string will be passed the the install.sh script. Subsequent converges will skip if the installed version and the desired version match.
  • false or nil - no chef is installed.

The default value is true.

disable_upstart

Disables upstart on Debian/Ubuntu containers, as many images do not support a working upstart.

The default value is true.

provision_command

Custom command(s) to be run when provisioning the base for the suite containers.

Examples:

  provision_command: curl -L https://www.opscode.com/chef/install.sh | bash
  provision_command:
    - apt-get install dnsutils
    - apt-get install telnet
driver_config:
  provision_command: curl -L https://www.opscode.com/chef/install.sh | bash
  require_chef_omnibus: false

env_variables

Adds environment variables to Docker container

Examples:

  env_variables:
    TEST_KEY_1: TEST_VALUE
    SOME_VAR: SOME_VALUE

use_cache

This determines if the Docker cache is used when provisioning the base for suite containers.

The default value is true.

use_sudo

This determines if Docker commands are run with sudo.

The default value depends on the type of socket being used. For local sockets, the default value is true. For remote sockets, the default value is false.

This should be set to false if you're using boot2docker, as every command passed into the VM runs as root by default.

remove_images

This determines if images are automatically removed when the suite container is destroyed.

The default value is false.

run_command

Sets the command used to run the suite container.

The default value is /usr/sbin/sshd -D -o UseDNS=no -o UsePAM=no -o PasswordAuthentication=yes -o UsePrivilegeSeparation=no -o PidFile=/tmp/sshd.pid.

Examples:

  run_command: /sbin/init

memory

Sets the memory limit for the suite container in bytes. Otherwise use Dockers default. You can read more about memory.limit_in_bytes here.

cpu

Sets the CPU shares (relative weight) for the suite container. Otherwise use Dockers defaults. You can read more about cpu.shares here.

volume

Adds a data volume(s) to the suite container.

Examples:

  volume: /ftp
  volume:
  - /ftp
  - /srv

volumes_from

Mount volumes managed by other containers.

Examples:

  volumes_from: repos
  volumes_from:
  - repos
  - logging
  - rvm

mount

Attach a filesystem mount to the container (NOTE: supported only in docker 17.05 and newer).

Examples:

  mount: type=volume,source=my-volume,destination=/path/in/container
  mount:
  - type=volume,source=my-volume,destination=/path/in/container
  - type=tmpfs,tmpfs-size=512M,destination=/path/to/tmpdir

tmpfs

Adds a tmpfs volume(s) to the suite container.

Examples:

  tmpfs: /tmp
  tmpfs:
  - /tmp:exec
  - /run

dns

Adjusts resolv.conf to use the dns servers specified. Otherwise use Dockers defaults.

Examples:

  dns: 8.8.8.8
  dns:
  - 8.8.8.8
  - 8.8.4.4

http_proxy

Sets an http proxy for the suite container using the http_proxy environment variable.

Examples:

  http_proxy: http://proxy.host.com:8080

https_proxy

Sets an https proxy for the suite container using the https_proxy environment variable.

Examples:

  https_proxy: http://proxy.host.com:8080

forward

Set suite container port(s) to forward to the host machine. You may specify the host (public) port in the mappings, if not, Docker chooses for you.

Examples:

  forward: 80
  forward:
  - 22:2222
  - 80:8080

hostname

Set the suite container hostname. Otherwise use Dockers default.

Examples:

  hostname: foobar.local

privileged

Run the suite container in privileged mode. This allows certain functionality inside the Docker container which is not otherwise permitted.

The default value is false.

Examples:

  privileged: true

cap_add

Adds a capability to the running container.

Examples:

cap_add:
- SYS_PTRACE

cap_drop

Drops a capability from the running container.

Examples:

cap_drop:
- CHOWN

security_opt

Apply a security profile to the Docker container. Allowing finer granularity of access control than privileged mode, through leveraging SELinux/AppArmor profiles to grant access to specific resources.

Examples:

security_opt:
  - apparmor:my_profile

dockerfile

Use a custom Dockerfile, instead of having Kitchen-Docker build one for you.

Examples:

  dockerfile: test/Dockerfile

instance_name

Set the name of container to link to other container(s).

Examples:

  instance_name: web

links

Set instance_name(and alias) of other container(s) that connect from the suite container.

Examples:

 links: db:db
  links:
  - db:db
  - kvs:kvs

publish_all

Publish all exposed ports to the host interfaces. This option used to communicate between some containers.

The default value is false.

Examples:

  publish_all: true

devices

Share a host device with the container. Host device must be an absolute path.

Examples:

devices: /dev/vboxdrv
devices:
  - /dev/vboxdrv
  - /dev/vboxnetctl

build_context

Transfer the cookbook directory (cwd) as build context. This is required for Dockerfile commands like ADD and COPY. When using a remote Docker server, the whole directory has to be copied, which can be slow.

The default value is true for local Docker and false for remote Docker.

Examples:

  build_context: true

build_options

Extra command-line options to pass to docker build when creating the image.

Examples:

  build_options: --rm=false
  build_options:
    rm: false
    build-arg: something

run_options

Extra command-line options to pass to docker run when starting the container.

Examples:

  run_options: --ip=1.2.3.4
  run_options:
    tmpfs:
    - /run/lock
    - /tmp
    net: br3

build_tempdir

Relative (to build_context) temporary directory path for built Dockerfile.

Example:

  build_tempdir: .kitchen

use_internal_docker_network

If you want to use kitchen-docker from within another Docker container you'll need to set this to true. When set to true uses port 22 as the SSH port and the IP of the container that chef is going to run in as the hostname so that you can connect to it over SSH from within another Docker container.

Examples:

  use_internal_docker_network: true

docker_platform

Configure the CPU platform (architecture) used by docker to build the image.

Examples:

  docker_platform: linux/arm64
  docker_platform: linux/amd64

Development

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:

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

License

Copyright 2013-2016, [Sean Porter](https://github.com/portertech)
Copyright 2015-2016, [Noah Kantrowitz](https://github.com/coderanger)

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

kitchen-docker's People

Contributors

adnichols avatar aigeruth avatar amalucelli avatar ashiqueps avatar brandocorp avatar coderanger avatar cpuid avatar cruwe avatar dalehamel avatar damacus avatar dependabot-preview[bot] avatar ehartmann avatar es1o avatar fnichol avatar garethgreenaway avatar gregsymons avatar gtmanfred avatar http-418 avatar indirect avatar jeffreycoe avatar jmauntel avatar kitchen-porter avatar madhatter avatar marcy-terui avatar portertech avatar renovate[bot] avatar rulerof avatar tas50 avatar tbe avatar terminalmage avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

kitchen-docker's Issues

[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 )

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!

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

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.

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.

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.

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.

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.

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:~$ 

/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}

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.

Port mapping

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

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....

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.

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.

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?

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.

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

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: ----------------------

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?

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.

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)

"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!!

screen shot 2014-01-31 at 1 43 18 pm

screen shot 2014-01-31 at 1 44 44 pm

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

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.

Using Docker driver in Kitchen (Windows Environment)

  1. I have built docker Client on Windows as per https://ahmetalpbalkan.com/blog/compiling-docker-cli-on-windows/.
  2. I have boot2Docker where my Docker Daemon resides.
  3. 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.

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

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

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.

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.

kitchen-docker-bats-run

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.

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.

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.

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.

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 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.

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

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

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:

  1. test-kitchen (1.2.1)
  2. docker (1.3.2)
  3. 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

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

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

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

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.