Coder Social home page Coder Social logo

garethr-docker's Introduction

Puppet module for installing, configuring and managing Docker from the official repository or alternatively from EPEL on RedHat based distributions.

Puppet Forge Build Status Documentation Status Puppet Forge Downloads Puppet Forge Endorsement

Support

This module is currently tested on:

  • Debian 8.0
  • Debian 7.8
  • Ubuntu 12.04
  • Ubuntu 14.04
  • Centos 7.0
  • Centos 6.6

It may work on other distros and additional operating systems will be supported in the future. It's definitely been used with the following too:

  • Archlinux
  • Amazon Linux
  • Fedora
  • Gentoo

Examples

Usage

The module includes a single class:

include 'docker'

By default this sets up the docker hosted repository if necessary for your OS and installs the docker package and on Ubuntu, any required Kernel extensions.

If you don't want this module to mess about with your Kernel then you can disable this feature like so. It is only enabled (and supported) by default on Ubuntu:

class { 'docker':
  manage_kernel => false,
}

If you want to configure your package sources independently, inform this module to not auto-include upstream sources (This is already disabled on Archlinux as there is no further upstream):

class { 'docker':
  use_upstream_package_source => false,
}

Docker recently launched new official repositories which are now the default for the module from version 5. If you want to stick with the old repositories you can do so with the following:

class { 'docker':
  package_name => 'lxc-docker',
  package_source_location => 'https://get.docker.com/ubuntu',
  package_key_source => 'https://get.docker.com/gpg',
  package_key => '36A1D7869245C8950F966E92D8576A8BA88D21E',
  package_release => 'docker',
}

Docker also provide a commercially supported version of the Docker Engine, called Docker CS, available from a separate repository. This can be installed with the module using the following:

class { 'docker':
  docker_cs => true,
}

The module also now uses the upstream repositories by default for RHEL based distros, including Fedora. If you want to stick with the distro packages you should use the following:

class { 'docker':
  use_upstream_package_source => false,
  package_name => 'docker',
}

By default the docker daemon will bind to a unix socket at /var/run/docker.sock. This can be changed, as well as binding to a tcp socket if required.

class { 'docker':
  tcp_bind        => ['tcp://127.0.0.1:4243','tcp://10.0.0.1:4243'],
  socket_bind     => 'unix:///var/run/docker.sock',
  ip_forward      => true,
  iptables        => true,
  ip_masq         => true,
  bridge          => br0,
  fixed_cidr      => '10.20.1.0/24',
  default_gateway => '10.20.0.1',
}

For TLS setup you should upload related files (such as CA certificate, server certificate and key) and use their paths in manifest

class { 'docker':
  tcp_bind        => ['tcp://0.0.0.0:2376'],
  tls_enable      => true,
  tls_cacert      => '/etc/docker/tls/ca.pem',
  tls_cert        => '/etc/docker/tls/cert.pem',
  tls_key         => '/etc/docker/tls/key.pem',
}

Unless specified this installs the latest version of docker from the docker repository on first run. However if you want to specify a specific version you can do so, unless you are using Archlinux which only supports the latest release. Note that this relies on a package with that version existing in the reposiroty.

class { 'docker':
  version => '0.5.5',
}

And if you want to install a specific rpm package of docker you can do so:

class { 'docker' :
  manage_package              => true,
  use_upstream_package_source => false,
  package_name                => 'docker-engine'
  package_source              => 'https://get.docker.com/rpm/1.7.0/centos-6/RPMS/x86_64/docker-engine-1.7.0-1.el6.x86_64.rpm',
  prerequired_packages        => [ 'glibc.i686', 'glibc.x86_64', 'sqlite.i686', 'sqlite.x86_64', 'device-mapper', 'device-mapper-libs', 'device-mapper-event-libs', 'device-mapper-event' ]
}

And if you want to track the latest version you can do so:

class { 'docker':
  version => 'latest',
}

In some cases dns resolution won't work well in the container unless you give a dns server to the docker daemon like this:

class { 'docker':
  dns => '8.8.8.8',
}

To add users to the Docker group you can pass an array like this:

class { 'docker':
  docker_users => ['user1', 'user2'],
}

To add daemon labels you can pass an array like this:

class { 'docker':
  labels => ['storage=ssd','stage=production'],
}

The class contains lots of other options, please see the inline code documentation for the full options.

Images

The next step is probably to install a docker image; for this we have a defined type which can be used like so:

docker::image { 'base': }

This is equivalent to running docker pull base. This is downloading a large binary so on first run can take a while. For that reason this define turns off the default 5 minute timeout for exec. Takes an optional parameter for installing image tags that is the equivalent to running docker pull -t="precise" ubuntu:

docker::image { 'ubuntu':
  image_tag => 'precise'
}

Note: images will only install if an image of that name does not already exist.

A images can also be added/build from a dockerfile with the docker_file property, this equivalent to running docker build -t ubuntu - < /tmp/Dockerfile

docker::image { 'ubuntu':
  docker_file => '/tmp/Dockerfile'
}

Images can also be added/build from a directory containing a dockerfile with the docker_dir property, this is equivalent to running docker build -t ubuntu /tmp/ubuntu_image

docker::image { 'ubuntu':
  docker_dir => '/tmp/ubuntu_image'
}

You can trigger a rebuild of the image by subscribing to external events like Dockerfile changes:

docker::image { 'ubuntu':
  docker_file => '/tmp/Dockerfile'
  subscribe => File['/tmp/Dockerfile'],
}

file { '/tmp/Dockerfile':
  ensure => file,
  source => 'puppet:///modules/someModule/Dockerfile',
}

You can also remove images you no longer need with:

docker::image { 'base':
  ensure => 'absent'
}

docker::image { 'ubuntu':
  ensure    => 'absent',
  image_tag => 'precise'
}

If using hiera, there's a docker::images class you can configure, for example:

---
  classes:
    - docker::images

docker::images::images:
  ubuntu:
    image_tag: 'precise'

Containers

Now you have an image you can launch containers:

docker::run { 'helloworld':
  image   => 'base',
  command => '/bin/sh -c "while true; do echo hello world; sleep 1; done"',
}

This is equivalent to running the following:

docker run -d base /bin/sh -c "while true; do echo hello world; sleep 1; done"

This will launch a Docker container managed by the local init system.

Run also takes a number of optional parameters:

docker::run { 'helloworld':
  image           => 'base',
  command         => '/bin/sh -c "while true; do echo hello world; sleep 1; done"',
  ports           => ['4444', '4555'],
  expose          => ['4666', '4777'],
  links           => ['mysql:db'],
  net             => 'my-user-def-net',
  volumes         => ['/var/lib/couchdb', '/var/log'],
  volumes_from    => '6446ea52fbc9',
  memory_limit    => '10m', # (format: '<number><unit>', where unit = b, k, m or g)
  cpuset          => ['0', '3'],
  username        => 'example',
  hostname        => 'example.com',
  env             => ['FOO=BAR', 'FOO2=BAR2'],
  env_file        => ['/etc/foo', '/etc/bar'],
  dns             => ['8.8.8.8', '8.8.4.4'],
  restart_service => true,
  privileged      => false,
  pull_on_start   => false,
  before_stop     => 'echo "So Long, and Thanks for All the Fish"',
  before_start    => 'echo "Run this on the host before starting the Docker container"',
  after           => [ 'container_b', 'mysql' ],
  depends         => [ 'container_a', 'postgres' ],
  extra_parameters => [ '--restart=always' ],
}

Ports, expose, env, env_file, dns and volumes can be set with either a single string or as above with an array of values.

Specifying pull_on_start will pull the image before each time it is started.

Specifying before_stop will execute a command before stopping the container.

The after option allows expressing containers that must be started before. This affects the generation of the init.d/systemd script.

The depends option allows expressing container dependencies. The depended container will be started before this container(s), and this container will be stopped before the depended container(s). This affects the generation of the init.d/systemd script. You can use depend_services to specify dependency for generic services (non-docker) that should be started before this container.

extra_parameters : An array of additional command line arguments to pass to the docker run command. Useful for adding additional new or experimental options that the module does not yet support.

The service file created for systemd based systems enables automatic restarting of the service on failure by default.

To use an image tag just append the tag name to the image name separated by a semicolon:

docker::run { 'helloworld':
  image   => 'ubuntu:precise',
  command => '/bin/sh -c "while true; do echo hello world; sleep 1; done"',
}

By default the generated init scripts will remove the container (but not any associated volumes) when the service is stopped or started. This behaviour can be modified using the following, with defaults shown:

docker::run { 'helloworld':
  remove_container_on_start => true,
  remove_volume_on_start    => false,
  remove_container_on_stop  => true,
  remove_volume_on_stop     => false,
}

If using hiera, there's a docker::run_instance class you can configure, for example:

---
  classes:
    - docker::run_instance

  docker::run_instance::instance:
    helloworld:
      image: 'ubuntu:precise'
      command: '/bin/sh -c "while true; do echo hello world; sleep 1; done"'

Networks

As of Docker 1.9.x, Docker has official support for networks. The module now exposes a type, docker_network, used to manage those. This works like:

docker_network { 'my-net':
  ensure   => present,
  driver   => 'overlay',
  subnet   => '192.168.1.0/24',
  gateway  => '192.168.1.1',
  ip_range => '192.168.1.4/32',
}

Only the name is required, along with an ensure value. If you don't pass a driver Docker network will use the default bridge. Note that some networks require the Docker daemon to be configured to use them, for instance for the overlay network you'll need a cluster store configured. You can do that on the docker class like so:

extra_parameters => '--cluster-store=<backend>://172.17.8.101:<port> --cluster-advertise=<interface>:2376'

If using hiera, there's a docker::networks class you can configure, for example:

---
  classes:
    - docker::networks

docker::networks::networks:
  local-docker:
    ensure: 'present'
    subnet: '192.168.1.0/24'
    gateway: '192.168.1.1'

The network defined can then be used on a docker::run resource with the net parameter.

Compose

Docker Compose allows for describing a set of containers in a simple YAML format, and then running a command to build and run those containers. The docker_compose type included in the module allows for using Puppet to run Compose. This means you can have Puppet remediate any issues and make sure reality matches the model in your Compose file.

Before using the docker_compose type make sure the docker-compose utility is installed:

class {'docker::compose': 
  ensure => present,
}

Here's an example. Given the following Compose file:

compose_test:
  image: ubuntu:14.04
  command: /bin/sh -c "while true; do echo hello world; sleep 1; done"

That could be added to the machine you're running Puppet using a file resource or any other means.

Then define a docker_compose resource pointing at the Compose file like so:

docker_compose { '/tmp/docker-compose.yml':
  ensure  => present,
}

Now when Puppet runs it will automatically run Compose is required, for example because the relevant Compose services aren't running.

You can also pass additional options (for example to enable experimental features) as well as provide scaling rules. The following example requests 2 containers be running for example. Puppet will now run Compose if the number of containers for a given service don't match the provided scale values.

docker_compose { '/tmp/docker-compose.yml':
  ensure  => present,
  scale   => {
    'compose_test' => 2,
  },
  options => '--x-networking'
}

It is also possible to give options to the docker-compose up command such as --remove-orphans using the up_args option.

Swarm mode

Docker Engine 1.12 includes swarm mode for natively managing a cluster of Docker Engines called a swarm. You can now cluster your Docker engines with the one of the following Puppet resources. For a swarm manager:

docker::swarm {'cluster_manager':
  init           => true,
  advertise_addr => '192.168.1.1',
  listen_addr    => '192.168.1.1',  
} 

In the above example we have configured a swarm manager with init => true then set the advertise_addr and listen_addr. Both the advertise_addr and listen_addr are set for the cluster communications between nodes. Please note the advertise_addr and listen_addr must be set for a multihomed server. For more advance flags to configure raft snapshots etc please read the readme at the top of the docker::swarm class.

For a swarm worker:

docker::swarm {'cluster_worker':
join           => true,
advertise_addr => '192.168.1.2',
listen_addr    => '192.168.1.2,
manager_ip     => '192.168.1.1',
token          => 'SWMTKN-1-2lw8bnr57qsu74d6iq2q1wr2wq2i334g7425dfr3zucimvh4bl-2vwn6gysbdj605l37c61iixie'
} 

In this example we have joined a node to the cluster using join => true. For a worker node or second manager you need to pass a current managers ip address manager_ip => '192.168.1.1' The other important configuration is the token you pass to the manager. The token will define the nodes role in the cluster, as there will be a token to create another manager and a different token for the worker nodes.

To remove a node from a cluster use the following:

docker::swarm {'cluster_worker':
ensure => absent
}

Docker services

Docker services allow to create distributed applications across multiple swarm nodes. A service is a set of containers that are replicated across your swarm. To configure a service with Puppet code please see the following examples

To create a service

docker::services {'redis':
    create => true,   
    service_name => 'redis',
    image => 'redis:latest',
    publish => '6379:639',
    replicas => '5', 
    extra_params => ['--update-delay 1m', '--restart-window 30s']
  }

In this example we are creating a service called redis, as it is a new service we have set create => true. The service_name resource is the name which Docker knows the service as. The image resource is the image you want to base the service off, publish is the ports that want exposed to the outside world for the service to be consumed, replicas sets the amount of tasks (containers) that you want running in the service, extra_params allows you to configure any of the other flags that Docker gives you when you create a service for more info see docker service create --help

To update the service

docker::services {'redis_update':
  create => false,
  update => true,
  service_name => 'redis',
  replicas => '3',
}

In this example we have taken the service that we created earlier `redis` set the `create => false` and this time added `update => true`. We then decleared the service name `redis` we have then updated the servce to have only 3 replicas, not 5. The `extra_params` resource is also available in the update class.

To scale a service
```puppet
docker::services {'redis_scale':
  create => false,
  scale => true,
  service_name => 'redis',
  replicas => '10', 
}

In this example we have used the command docker service scale with Puppet code. We have taken our service redis set the create => false and scale => true When using scale you have to declare your service_name then the number of replicas that you want. In this example we are going to scale to 10

To remove a service

docker::services {'redis':
  ensure => 'absent',
  service_name => 'redis',
}

To remove a a service from your swarm just set ensure => absent and the service_name of your service.

Private registries

By default images will be pushed and pulled from index.docker.io unless you've specified a server. If you have your own private registry without authentication, you can fully qualify your image name. If your private registry requires authentication you may configure a registry:

docker::registry { 'example.docker.io:5000':
  username => 'user',
  password => 'secret',
  email    => '[email protected]',
}

You can logout of a registry if it is no longer required.

docker::registry { 'example.docker.io:5000':
  ensure => 'absent',
}

If using hiera, there's a docker::registry_auth class you can configure, for example:

docker::registry_auth::registries:
  'example.docker.io:5000':
    username: 'user1'
    password: 'secret'
    email: '[email protected]'

Exec

Docker also supports running arbitrary commands within the context of a running container. And now so does the Puppet module.

docker::exec { 'cron_allow_root':
  detach       => true,
  container    => 'mycontainer',
  command      => '/bin/echo root >> /usr/lib/cron/cron.allow',
  tty          => true,
  unless       => 'grep root /usr/lib/cron/cron.allow 2>/dev/null',
}

garethr-docker's People

Contributors

bcicen avatar bmcbm avatar bobtfish avatar bwalex avatar commial avatar coreone avatar cornelf avatar cr7pt0gr4ph7 avatar eliasp avatar fredrikt avatar furhouse avatar garethr avatar jamescarr avatar javierbertoli avatar jfarrell avatar jfroche avatar jhoblitt avatar jonnytdevops avatar jovandeginste avatar jumanjiman avatar justin8 avatar ldx avatar luckyraul avatar n0coast avatar paschdan avatar phemmer avatar scotty-c avatar solarkennedy avatar specialunderwear avatar ves 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  avatar  avatar

garethr-docker's Issues

pull latest container

I'm trying to figure out the best way to upgrade the docker containers using puppet.

Currently trying:

    docker::image { 'kohana-remove':
      ensure  => 'absent',
      image   => 'docker.ukwm.local:5000/ukwm/container',
      require => Class['ukwm::packages::docker'],
    }
    ->
    docker::image { 'kohana-install':
      ensure  => 'latest',
      image   => 'docker.ukwm.local:5000/ukwm/container',
      require => Class['ukwm::packages::docker'],
    }
    ->
    docker::run { 'kohana':
      image           => 'docker.ukwm.local:5000/ukwm/container',
      ports           => ['81:80', '2221:22'],
      use_name        => true,
      restart_service => true,
      privileged      => false,
    }

Which outputs:

Error: docker rmi docker.ukwm.local:5000/ukwm/container returned 1 instead of one of [0]
Error: /Stage[main]/Stats::Backend::Kohana/Docker::Image[kohana-remove]/Exec[docker rmi docker.ukwm.local:5000/ukwm/container]/returns: change from notrun to 0 failed: docker rmi docker.ukwm.local:5000/ukwm/container returned 1 instead of one of [0]
Warning: /Stage[main]/Ukwm::Backend::Kohana/Docker::Image[kohana-install]/Exec[docker pull docker.ukwm.local:5000/ukwm/stats-kohana]: Skipping because of failed dependencies
Warning: /Stage[main]/Ukwm::Backend::Kohana/Docker::Run[kohana]/File[/etc/init/docker-kohana.conf]: Skipping because of failed dependencies
Warning: /Stage[main]/Ukwm::Backend::Kohana/Docker::Run[kohana]/Service[docker-kohana]: Skipping because of failed dependencies

So maybe an option of force docker rm -f <container>

What would be nicer, is if could notify run that the image has been update. Then it could stop, remove, and restart container.

This would be the command I'd use.

    docker::image { 'kohana-install':
      ensure  => 'latest',
      image   => 'docker.ukwm.local:5000/ukwm/container',
      require => Class['ukwm::packages::docker'],
    }

    docker::run { 'kohana':
      image           => 'docker.ukwm.local:5000/ukwm/container',
      ports           => ['81:80', '2221:22'],
      use_name        => true,
      restart_service => true,
      privileged      => false,
    }

docker run --rm could be added to accomplish some of that.

Centos/RHEL package name.

The package is now included in the default repos as 'docker'. There is a request open on EPEL now to remove the old docker-io package, it might be worth changing this before it is actually gone from upstream.

Bad package name generated on Linode on Ubuntu 14.04

So on installing on a stock Linode ubuntu 14.04 server this module generated the package name linux-image-extra-3.14.5-x86_64-linode42 while I believe the appropriate package is linux-image-extra-3.13.0-24-generic. I'm not sure the best way to address this but a simple work around would be to allow this parameter to be specified (I do not believe that is currently possible).

Specify custom package name

The logic in install.pp which assumes package name based on $docker::use_upstream_package_source is not exactly correct.
According to http://docs.docker.com/installation/ubuntulinux/ package name is docker.io for Ubuntu Trusty and lxc-docker for other versions.
My use case is that I don't want to use upstream package repository as I provide those packages via my local mirror, the end result is that this module tries to install docker.io on a system which lxc-docker should be used.
I have implemented functionality that selects package_name (with possibility to set explicitly) based on the $::operatingsystemrelease, but there are many tests that are designed according to previously mentioned logic and fixing them could potentially brake backward compatibility for this module.
Also I have noticed that in tests, you use lsbdistid and put 'debian' there, which even for debian should be 'Debian', for ubuntu is 'Ubuntu', this does not matter as you don't use those facts anywhere. Also it seems you do use $::operatingsystemrelease but test cases for maverick are missing this value. I think it would be good to provide some consistency, either do not provide facts that are not used or provide most of the distro-present facts for each distribution.If you can suggest what would be the best way to fix this I can work on that and make a pull request.

Update: I have created pull request #74 for that, I think this code is fairly backward compatible.

Module should have option to manage DOCKER_HOST environment variable

When specifying a tcp_bind, in order for this to actually be usable the DOCKER_HOST environment variable needs to be populated with the tcp_bind value:

Proposed solution:

if $tcp_bind {
  file { '/etc/profile.d/docker-host.sh': 
    ensure  => file,
    content => "export DOCKER_HOST=${tcp_bind}"
  }
}

APT

Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Duplicate declaration: Class[Apt] is already declared; cannot redeclare at /etc/puppet/manifests/nodes/node-common.pp:28 on node server.local

Your module apt to install itself I am getting conflicts where I'm installing with Apt as well.

upstart job runs too early

When doing a system restart, Upstart tries to start my docker containers too early. In /var/log/upstart/docker-test.log, I am seeing:

2013/10/07 15:38:50 dial unix /var/run/docker.sock: no such file or directory

I am running Ubuntu Precise with a 3.8.0-31-generic kernel

[Feature Request] Add Amazon Linux Support

Adding support for Amazon Linux shouldn't be to hard to add as it's 98% the same has RHEL/CentOS/Fedora. I have a fork in the works but hopefully someone can beat me to the task.

params version default inconsistency

From the README page :

Unless specified this installs the latest version of docker from the docker inc repository.

But looking at the code the default is undef (https://github.com/garethr/garethr-docker/blob/master/manifests/params.pp#L6). There is even a check that will ensure the value is not undefined.

For information, the check is even done twice:
https://github.com/garethr/garethr-docker/blob/master/manifests/init.pp#L108
https://github.com/garethr/garethr-docker/blob/master/manifests/install.pp#L8

IMHO, the default should be changed to latest in source code (both check would be unnecessary)

Cheers

fails to start docker service on debian jessie

Using the garethr-docker puppet module, I get:

"Error: /Stage[main]/Docker::Service/Service[docker]: Could not evaluate: Could not find init script for 'docker'"

reading the code shows, for debian:

file { '/etc/init.d/docker':
ensure => 'absent',
notify => Service['docker'],
}

Have I encountered a bug here? Or am I missing something in its usage?

Ignore OS release and override package name

The current install.pp limits install on RHEL based systems to those >= 6.5. There are instances where the package may be available for older versions of an OS so I'd like to propose removing the version check that the module does. Additionally given that the option exists to set 'use_upstream_package_source' to false, it would be nice to override the package_name. For example, in my current environment I have RHEL 6u4 and the docker-io package is available, however the module bails because of the OS version. If it passed the version check the package name would be wrong (module has package_name set to 'docker' for RHEL < 7.0).

It seems to me that if the package is available then the puppet module shouldn't care what OS version i'm running. I'll gladly provide a PR if this seems like a good idea.

https://github.com/garethr/garethr-docker/blob/master/manifests/install.pp#L75

UPDATE: The package name is actually fine for RHEL6.4, simply removing the OS version check is enough to install docker using this module.

Service failures on Ubuntu 14.04

On Ubuntu 14.04, the installation of Docker using the following fails:

node default { 
  class { 'docker': }
}

It fails like this:

Error: /Stage[main]/Docker::Service/Service[docker]: Could not evaluate: Could not find init script or upstart conf file for 'docker'
Error: /Stage[main]/Docker::Service/Service[docker]: Failed to call refresh: Could not find init script or upstart conf file for 'docker' 
Error: /Stage[main]/Docker::Service/Service[docker]: Could not find init script or upstart conf file for 'docker'

Since the service name is hardcoded to docker and the actual service script is called docker.io, this fails.

Docker Versions Fail?

Hey Gareth!

Thanks a million for this module, super useful.

One thing we've noticed is defining a different version causes an error. Digging and we discover:

ubuntu@box:~$ sudo apt-get install lxc-docker=0.6.4

Reading package lists... Done
Building dependency tree       
Reading state information... Done
E: Version '0.6.4' for 'lxc-docker' was not found

When it seems like Docker name spaces their releases a little different (note the - instead of the =):

ubuntu@box:~$ sudo apt-get install lxc-docker-0.6.4

Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages will be REMOVED:
  lxc-docker lxc-docker-0.6.6
The following NEW packages will be installed:
  lxc-docker-0.6.4
0 upgraded, 1 newly installed, 2 to remove and 4 not upgraded.
Need to get 1,667 kB of archives.
After this operation, 5,539 kB disk space will be freed.
Do you want to continue [Y/n]? n

Do you have advice on handling this?

unable to install 0.12 on centos

i just installed this module today and 0.12 is out and the module install 0.11.
when i set the version to '0.1.2' i got this error.
{code}
Error: Could not find resource 'Package[docker-io]' for relationship from 'Class[Epel]' on node calpercdbdev01.test.com
{code}

Docker on Ubuntu 14.04

Since Docker is part of the distribution on Ubuntu 14.04, there should be a parameter to enable the use of the default package (docker.io) instead of the package from the external repository.

Docker install fails

I've just tried using my puppet install script on another computer, but same vagrant script and I'm getting a strange one.

Seems like docker is installing "cgroup-lite".

==> default: Notice: /Stage[main]/Docker::Install/Package[cgroup-lite]/ensure: ensure changed 'purged' to 'present'
==> default: Notice: /Stage[main]/Docker::Install/Apt::Source[docker]/Apt::Key[Add key: A88D21E9 from Apt::Source docker]/Apt_key[Add key: A88D21E9 from Apt::Source docker]/ensure: created
==> default: Notice: /Stage[main]/Stats::Backend::Kohana/Docker::Run[kohana]/File[/etc/init/docker-kohana.conf]/ensure: created
==> default: Info: /Stage[main]/Stats::Backend::Kohana/Docker::Run[kohana]/File[/etc/init/docker-kohana.conf]: Scheduling refresh of Service[docker-kohana]
==> default: Info: /Stage[main]/Stats::Backend::Kohana/Docker::Run[kohana]/File[/etc/init/docker-kohana.conf]: Scheduling refresh of Service[docker-kohana]
==> default: Notice: /Stage[main]/Stats::Backend::Kohana/Docker::Run[kohana]/Service[docker-kohana]/ensure: ensure changed 'stopped' to 'running'
==> default: Info: /Stage[main]/Stats::Backend::Kohana/Docker::Run[kohana]/Service[docker-kohana]: Unscheduling refresh on Service[docker-kohana]
==> default: Error: Could not find command 'docker'
==> default: Error: /Stage[main]/Stats::Backend::Kohana/Docker::Image[kohana]/Exec[docker pull docker.ukwm.local:5000/ukwm/stats-kohana]/returns: change from notrun to 0 failed: Could not find command 'docker'

I'm going to keep looking.

[Feature Request] Add Archlinux support

This shouldn't require too much work. Currently there is no environment file for the default docker service, but I've opened a bug request with the maintainer to add one, once that is done this should be pretty trivial.

[Feature Request] docker::stop / docker::rm

It should be possible to stop and remove containers somehow Basically the opposite of docker::run. Otherwise it is not possible to get rid of containers you don't need anymore.

Perhaps something like this:

// Will stop all containers with that image (and tag)
docker::stop { 'helloworld':
image => 'base:tag'
}

// Will remove all containers with that image (and tag)
docker::remove { 'helloworld':
image => 'base:tag'
}

Building from dockerfiles / ghost processes

Hi,

Firstly, apologies if the following is obvious or if what I'm doing is just plain wrong. I'm quite to new to some of this stuff.

I am trying to, in one step: instantiate a vagrant box which, through puppet provisioning, builds several docker images from Dockerfiles and starts them.

I am experimenting with functionality for building images from Dockerfiles: jvaughan/garethr-docker@2e34bb2

However, it seems that docker::image is missing the requirement for docker::install, so was failing because of the lack of a docker executable to run.

I've tried adding

require docker::image

within the image class. This does satisfy the install dependency and means that the image gets built.

However, it seems to be triggering additional refreshes of the docker service, and this is causing my container to become ghosted in docker. The same ghosting occurs if I manually run

service docker restart

Do you have any suggestions of the best way to proceed?

BTW, if the 'build from dockerfile' functionality is considered useful, I will do a pull request once I have written some tests.

For what is docker::run use_name good?

Hello,

I did not found the meaning of use_name on docker::run. What is it good for?
Maybe this should be documented, as well as the default options for this deftype on the readme file.

Need $docker::manage_firewall option

Hey Gareth:

It seems that while docker is managing the creation of rules in the FORWARD chain, that it leaves the policies on every chain set to ACCEPT and the docker host particularly vulnerable, with all ports wide open. I want to use the puppetlabs/firewall module to lock things down and to manage the ports I need to open to the world for my haproxy, db servers and other services. But I want to do that without messing up what is happening with the docker rule set.

This evening I had a short exchange on the #docker channel on this subject. I'm imagining a new defined type docker::firewall which would be invoked by docker::run, and perhaps as well by a new docker::firewall::legacy_containers (might not be the right name there) which would handle managing the firewall for already running containers or containers which were run directly with the docker client, and in a way not otherwise managed by puppet.

23:50:12 hesco | I'm nearly ready to bring the iptables rule set run on my docker hosts under puppet management with the puppetlabs-firewall module. But the first thing the firewall module will do is flush whatever is already there. My question is this? What will it take to make docker rebuild its own rule set on top of what I'm doing with puppet? And how long would that take? Can't really afford to break things at this hour, when I'm hoping to go to bed soon. Can anyone advise me on how docker manages its iptables rule set and what might be expected if I run this test?

00:03:20 akerl | hesco: In my experience, if you're doing other things with iptables, it quickly becomes saner to have $other_thing manage all the rules and tell Docker to leave iptables alone

00:07:35 hesco | akerl: ok, I'll buy that. So it sounds like I need some sort of new defined type which will harvest the published ports out of docker ps and convert those into rules for the FORWARD chain, perhaps.

00:08:06 akerl | That would be snazzy

00:10:48 hesco | sounds like a patch for the garethr/docker module.

So, is this something which seems germane to your module, as I imagine? Would you consider such a patch? Or should I develop it under a distinct namespace?

-- Hugh

Change in docker run parameters not refreshed properly on CentOS/RHEL

The /etc/rc.d/init.d/docker- script that gets created with the docker-run.erb template on CentOS/RHEL6 doesn't do a "docker rm" - so if you change any value, during the refresh you get a puppet agent error. The container is stopped, and can't be restarted because the name is already allocated. A "docker rm" added to the stop function in the init script would allow that to work properly.

So, something along the lines of:

--- a/docker/templates/etc/init.d/docker-run.erb
+++ b/docker/templates/etc/init.d/docker-run.erb
@@ -94,6 +94,9 @@ stop() {
             echo -n $"Stopping $prog: "
             docker stop $(cat $cidfile)
             retval=$?
+            docker rm $(cat $cidfile)
+            retval2=$?
+            retval=$((retval + retval2))
             [ $retval -eq 0 ] && rm -f $lockfile $cidfile
             return $retval
         else

(that's the patch we're working with in our module, anyway)

ubuntu precise: docker service does not start with new docker-1.2.0 module if "apparmor" is not installed

Hi there,

First - Thanks for writing this awesome module!

I was eager to try your new docker-1.2.0 module as I wanted to use the new linux-image-generic-lts-saucy kernel on my Ubuntu 12.04 VMs. I'd previously been using the docker-1.1.3 module without issue on my Ubuntu 12.04 VMs.

Unfortunately I could not to get this working, even when starting from a clean VM. From my VM:

uname vagrant@vi-packages9:~$ uname -a
Linux vi-packages9 3.11.0-26-generic #45~precise1-Ubuntu SMP Tue Jul 15 04:02:35 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

vagrant@vi-packages9:~$ sudo docker ps
2014/08/21 16:47:57 Cannot connect to the Docker daemon. Is 'docker -d' running on this host?

From /var/log/upstart/docker.log:

2014/08/21 16:54:14 docker daemon: 1.1.2 d84a070; execdriver: native; graphdriver:
[670c4a8f] +job serveapi(unix:///var/run/docker.sock)
[670c4a8f] +job initserver()
[670c4a8f.initserver()] Creating server
[670c4a8f] +job init_networkdriver()
2014/08/21 16:54:14 Listening for HTTP on unix (/var/run/docker.sock)
[670c4a8f] -job init_networkdriver() = OK (0)
2014/08/21 16:54:14 WARNING: Your kernel does not support cgroup swap limit.
Error loading docker apparmor profile: exit status 1 (Feature buffer full.)

I found the solution at https://www.digitalocean.com/community/questions/start-docker-error-message :

sudo apt-get install apparmor

I think your puppet module should install this apparmor package, at least on Ubuntu 12.04.

Thanks!
Dan

[Feature Request] No_proxy as an Array

In template /etc/default/docker.erb, no_proxy can be written with:

<% if @no_proxy -%>
export no_proxy='<%= Array(@no_proxy).join(',') %>'
<% end -%>

This should keep compatibility with current version (in 1.2.2, no_proxy is a String instance).

This patch allows one to use a list for configuration which permits the use of YAML references.

.9 upgrade breaks cgroups

After booting into a puppetized machine that used docker I had to use this fix to get docker running properly

moby/moby#2683 (comment)

specifically: when I ran docker run -i -t ubuntu /bin/bash I got [error] client.go:2315 Error resize: Error: bad file descriptor

Running without -t gave nothing
Running any docker build commands just gave an unexplained exit status code 1 message

Restarting Upstart Services Doesn't Re-read the config

If upstart is in use (debian), then when asked to restart a docker::run thing, it will notify the service:

true => Service["docker-${sanitised_title}"],

That is good.

However, if options were changes (lets say you change a published port from 80=>88), Upstart will not take those changes into effect after a restart:
http://upstart.ubuntu.com/faq.html#reload
only after a stop.

In my experience, the best practice is to have configuration parameters in a /etc/default/bla file that can be sourced on restart. That way the /etc/init/bla.conf doesn't ever have to change, and parameters are loaded on each restart.

With this docker module, this is not really super, we end up baking all the configuration of a docker::run into the upstart config.

Alternatively, the only way I've been able to sanely do this in puppet is a puppet exec to stop the service and start it back up when the upstart script changes.

Would you accept a PR for that? Or would you consider it outside the scope? (in some sense this is "not a bug" in upstart land)

TLDR:

Expected: Changing the docker::run config will restart a docker with new config
Actual: The docker is restarted, but not with the new config

Proposed fix: A puppet exec to work around the fact that upstart only re-reads its config upon stop/start.

str2bool(): Requires either string to work with at modules/docker/manifests/run.pp:63

Hi. Calling class { 'docker': } and docker::image works fine. With docker::run however:

Error: Could not retrieve catalog from remote server: Error 400 on SERVER: str2bool(): Requires either string to work with at /etc/puppet/environments/production/modules/docker/manifests/run.pp:63 on node foo

Puppet client is Ubuntu 14.04 fresh install, with docker 1.20. insalled via class { 'docker': }.
Puppet server is 3.6.2 on ubuntu 12.04. Puppet-stdlib had to be updated to the latest version.

Possible fix:
In manifests/run.pp
$restart_service = true,
..
$notify = str2bool($restart_service) ? {

if I change that as follows (because the variable is already a boolean):
$notify = $restart_service ? {
and near line 106:
#if str2bool($restart_service) {
if $restart_service {

then it works fine.

Docker pull no longer takes a -t parameter

I'm running Ubuntu 14.04 with latest lxc-docker:

Client version: 1.2.0
Client API version: 1.14
Go version (client): go1.3.1
Git commit (client): fa7b24f
OS/Arch (client): linux/amd64
Server version: 1.2.0
Server API version: 1.14
Go version (server): go1.3.1
Git commit (server): fa7b24f

When I try running the following:

docker::image{ 'rfkrocktk/puppetmaster':
     image_tag => '1.0.5',
}

The actual command which is run is sudo docker pull -t="1.0.5" rfkrocktk/puppetmaster. This causes Docker to download every version of my Docker image (5 of them at 600MB each).

When I edit it to read the following:

docker::image { 'rfkrocktk/puppetmaster:1.0.5': }

It works properly, however it runs the Docker pull command each time because the $image_find command doesn't work properly with the given name above.

TL;DR: Docker got rid of the -t parameter to docker pull and now just expects the following format:

vagrant@vagrant-trusty64:~$ sudo docker help pull

Usage: docker pull NAME[:TAG]

Pull an image or a repository from the registry

I'll see if I can contribute a fix, but this is broken.

Add service_provider parameter to docker class.

I'm hitting the issues mentioned in the following post and it seems that the only work around at the moment is to add a service_provider parameter to the docker class to enable it to be settable. I'm happy to make the changes and do pull request if you think that is a good idea.

http://ask.puppetlabs.com/question/13635/how-to-use-puppet-modules-that-require-upstart-with-docker/

Docker containers don't really support the puppet upstart service provider and the only work around I know of at the moment is to set provider=base. Seems like a good idea to expose the provider as a parameter anyway.

Include managed-by-Puppet warning in all over-written files

# We over-wrote this file using Puppet. If you change it, it'll
# get changed back at the next Puppet run -- perhaps every 
# hour, or perhaps at reboot. 
#
# Of course, this message doesn't have to be this long, but
# without any warning at all you could waste hours trying to
# figure out why this file keeps changing back to some 
# plausible-looking but not-what-you-intended and not-in-the-
# source-code version of itself.

storage-device option for puppet class

Hi,

Thanks for the docker puppet module; it's really great.

I run Ubuntu 12.04 and lately I've wanted to switch from the default storage-driver "aufs" to the "devicemapper" storage driver.

I've looked through the module code pretty thoroughly, but I wasn't able to find a way to specify this as a parameter. Ideally I could just say

class { 'docker':
      storage_driver="devicemapper"
}

Is this something that currently exists? If not would you be willing to accept a pull request (with full test coverage of course)?

Cheers,
Mike

option to reboot machine on kernel upgrade

Having the correct kernel doesn't mean that the system is using it. It would be nice to have the option to restart a server after the module upgrades a kernel and assert that a recent version is being used.

Expose --net Option to docker::run

Currently there is only a disable_network switch in docker::run. It was introduced with #41. Docker has more options on the --net command line option as documented here.

As I need the host option, it would be very helpful for me if the whole --net would be exposed in docker::run.

image.pp doesn't update newer images in private repositories

This is more of an RFE than a bug, but I think it's how most folks approaching the Docker puppet module would expect it to work.

When administering containers on several systems, a reasonable practice would be to use a Docker private registry to store images, and then specify image tags that include the private registry name. I.e.

  docker::image { 'privaterepohost.example.com/myopsorg/awesomeimage': 
    ensure => 'present',
    image_tag => 'latest'
  }

Images that reference a private repository should be checked against the private repository to see if they need to be refreshed with "docker pull".

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.