sous-chefs / docker Goto Github PK
View Code? Open in Web Editor NEWDevelopment repository for the docker cookbook
Home Page: https://supermarket.chef.io/cookbooks/docker
License: Apache License 2.0
Development repository for the docker cookbook
Home Page: https://supermarket.chef.io/cookbooks/docker
License: Apache License 2.0
Once an image exists in the local graph, there seems to be no way to update it. It's common for an image's :latest
tag to be updated on the registry. How can we ensure we always have the right :latest
?
I have an in-progress PR that implements:
docker_image 'user/image' do
action :pull
force true
done
..but I wanted to get some feedback before moving forward.
TODO from cgroups recipe:
# TODO: Platforms handled here should be fixed in control_groups cookbook
# Possibly: https://github.com/hw-cookbooks/control_groups/
Getting an odd dependency loop:
Downloading powershell from the cookbooks site at version 1.1.2 to /home/bfosberry/workspace/gamekick-recipes/chef/cookbooks/powershell.tar.gz
Cookbook saved: /home/bfosberry/workspace/gamekick-recipes/chef/cookbooks/powershell.tar.gz
Removing pre-existing version.
Uncompressing powershell version 1.1.2.
removing downloaded tarball
No changes made to powershell
Checking out the master branch.
Installing windows to /home/bfosberry/workspace/gamekick-recipes/chef/cookbooks
Checking out the master branch.
Pristine copy branch (chef-vendor-windows) exists, switching to it.
Downloading windows from the cookbooks site at version 1.12.4 to /home/bfosberry/workspace/gamekick-recipes/chef/cookbooks/windows.tar.gz
Cookbook saved: /home/bfosberry/workspace/gamekick-recipes/chef/cookbooks/windows.tar.gz
Removing pre-existing version.
Uncompressing windows version 1.12.4.
removing downloaded tarball
No changes made to windows
Checking out the master branch.
Installing chef_handler to /home/bfosberry/workspace/gamekick-recipes/chef/cookbooks
Checking out the master branch.
Pristine copy branch (chef-vendor-chef_handler) exists, switching to it.
Downloading chef_handler from the cookbooks site at version 1.1.4 to /home/bfosberry/workspace/gamekick-recipes/chef/cookbooks/chef_handler.tar.gz
Cookbook saved: /home/bfosberry/workspace/gamekick-recipes/chef/cookbooks/chef_handler.tar.gz
Removing pre-existing version.
Uncompressing chef_handler version 1.1.4.
removing downloaded tarball
No changes made to chef_handler
Checking out the master branch.
Installing powershell to /home/bfosberry/workspace/gamekick-recipes/chef/cookbooks
Checking out the master branch.
Pristine copy branch (chef-vendor-powershell) exists, switching to it.
Downloading powershell from the cookbooks site at version 1.1.2 to /home/bfosberry/workspace/gamekick-recipes/chef/cookbooks/powershell.tar.gz
Cookbook saved: /home/bfosberry/workspace/gamekick-recipes/chef/cookbooks/powershell.tar.gz
Removing pre-existing version.
Uncompressing powershell version 1.1.2.
removing downloaded tarball
No changes made to powershell
Checking out the master branch.
Installing windows to /home/bfosberry/workspace/gamekick-recipes/chef/cookbooks
Checking out the master branch.
Pristine copy branch (chef-vendor-windows) exists, switching to it.
Downloading windows from the cookbooks site at version 1.12.4 to /home/bfosberry/workspace/gamekick-recipes/chef/cookbooks/windows.tar.gz
Cookbook saved: /home/bfosberry/workspace/gamekick-recipes/chef/cookbooks/windows.tar.gz
Removing pre-existing version.
Uncompressing windows version 1.12.4.
removing downloaded tarball
No changes made to windows
Checking out the master branch.
Installing chef_handler to /home/bfosberry/workspace/gamekick-recipes/chef/cookbooks
Checking out the master branch.
Pristine copy branch (chef-vendor-chef_handler) exists, switching to it.
Downloading chef_handler from the cookbooks site at version 1.1.4 to /home/bfosberry/workspace/gamekick-recipes/chef/cookbooks/chef_handler.tar.gz
Cookbook saved: /home/bfosberry/workspace/gamekick-recipes/chef/cookbooks/chef_handler.tar.gz
Removing pre-existing version.
Uncompressing chef_handler version 1.1.4.
removing downloaded tarball
No changes made to chef_handler
Checking out the master branch.
Installing powershell to /home/bfosberry/workspace/gamekick-recipes/chef/cookbooks
Checking out the master branch.
Pristine copy branch (chef-vendor-powershell) exists, switching to it.
Downloading powershell from the cookbooks site at version 1.1.2 to /home/bfosberry/workspace/gamekick-recipes/chef/cookbooks/powershell.tar.gz
Cookbook saved: /home/bfosberry/workspace/gamekick-recipes/chef/cookbooks/powershell.tar.gz
Removing pre-existing version.
Uncompressing powershell version 1.1.2.
removing downloaded tarball
No changes made to powershell
Checking out the master branch.
Installing windows to /home/bfosberry/workspace/gamekick-recipes/chef/cookbooks
Checking out the master branch.
Pristine copy branch (chef-vendor-windows) exists, switching to it.
Downloading windows from the cookbooks site at version 1.12.4 to /home/bfosberry/workspace/gamekick-recipes/chef/cookbooks/windows.tar.gz
Cookbook saved: /home/bfosberry/workspace/gamekick-recipes/chef/cookbooks/windows.tar.gz
Removing pre-existing version.
Uncompressing windows version 1.12.4.
removing downloaded tarball
No changes made to windows
Checking out the master branch.
Installing chef_handler to /home/bfosberry/workspace/gamekick-recipes/chef/cookbooks
Checking out the master branch.
Pristine copy branch (chef-vendor-chef_handler) exists, switching to it.
Downloading chef_handler from the cookbooks site at version 1.1.4 to /home/bfosberry/workspace/gamekick-recipes/chef/cookbooks/chef_handler.tar.gz
Cookbook saved: /home/bfosberry/workspace/gamekick-recipes/chef/cookbooks/chef_handler.tar.gz
Removing pre-existing version.
Uncompressing chef_handler version 1.1.4.
removing downloaded tarball
No changes made to chef_handler
Checking out the master branch.
Installing powershell to /home/bfosberry/workspace/gamekick-recipes/chef/cookbooks
Checking out the master branch.
Pristine copy branch (chef-vendor-powershell) exists, switching to it.
Downloading powershell from the cookbooks site at version 1.1.2 to /home/bfosberry/workspace/gamekick-recipes/chef/cookbooks/powershell.tar.gz
Cookbook saved: /home/bfosberry/workspace/gamekick-recipes/chef/cookbooks/powershell.tar.gz
Removing pre-existing version.
Uncompressing powershell version 1.1.2.
removing downloaded tarball
No changes made to powershell
Checking out the master branch.
Installing windows to /home/bfosberry/workspace/gamekick-recipes/chef/cookbooks
Checking out the master branch.
Pristine copy branch (chef-vendor-windows) exists, switching to it.
Getting the following error on
test-kitchen 1.0.0.beta3
2013-09-25T21:02:29+00:00] INFO: Running start handlers
[2013-09-25T21:02:29+00:00] INFO: Start handlers complete.
[2013-09-25T21:02:29+00:00] WARN: found a directory docker_test in the cookbook path, but it contains no cookbook files. skipping.
Compiling Cookbooks...
[2013-09-25T21:02:29+00:00] ERROR: Running exception handlers
[2013-09-25T21:02:29+00:00] ERROR: Exception handlers complete
Chef Client failed. 0 resources updated
[2013-09-25T21:02:29+00:00] FATAL: Stacktrace dumped to /tmp/kitchen-chef-solo/cache/chef-stacktrace.out
[2013-09-25T21:02:29+00:00] FATAL: Chef::Exceptions::CookbookNotFound: Cookbook docker_test not found. If you're loading docker_test from another cookbook, make sure you configure the dependency in your metadata
>>>>>> Converge failed on instance <image-lwrp-ubuntu-1204>.
>>>>>> Please see .kitchen/logs/image-lwrp-ubuntu-1204.log for more details
>>>>>> ------Exception-------
>>>>>> Class: Kitchen::ActionFailed
>>>>>> Message: SSH exited (1) for command: [sudo -E chef-solo --config /tmp/kitchen-chef-solo/solo.rb --json-attributes /tmp/kitchen-chef-solo/dna.json --log_level info]
>>>>>> ----------------------
vagrant-berkshelf is installed, and runs before:
Resolving cookbook dependencies with Berkshelf
Using docker (0.7.1)
Installing golang (1.0.2) from git: 'git://github.com/buth/chef-golang.git' with branch: 'master' at ref: 'd1d3778a68786749f03fd368c5a6b428619534e7'
Installing lxc (1.1.2) from git: 'git://github.com/hw-cookbooks/lxc.git' with branch: 'master' at ref: 'b36edd578a1296754c124c99ce9aee6e72238812'
Installing modules (0.1.3) from git: 'git://github.com/Youscribe/modules-cookbook.git' with branch: 'master' at ref: 'a7de3c4c47e345f9cf53574493e72f7af7fc3b74'
Using minitest-handler (0.2.1)
Using docker_test (0.2.0) at './test/cookbooks/docker_test'
Using apt (2.1.1)
Using git (2.6.0)
Using dmg (2.0.0)
Using build-essential (1.4.2)
Using yum (2.3.2)
Using windows (1.10.0)
Using chef_handler (1.1.4)
Using runit (1.2.0)
Using dpkg_autostart (0.1.8)
I noticed that the LWRP's are not verifying return codes except in one place:
$ git grep -n 'error!'
providers/container.rb:224: dr.error!
Is this on purpose? It seems like it'd be more appropriate to use shell_out!
(which verifies exit codes) everywhere instead of shell_out
(which doesn't). Specifically, it'd be nice if docker_image
with action :pull
failed fast so that docker_container
doesn't try to start a container that failed to pull.
Official docs: http://docs.docker.io/en/latest/installation/mac/
Deprecate (remove in chef-docker 1.0) LXC handling?
Existing behavior should be moved to a build_if_missing action. Similar functionality just added to pull action in 0.28.0.
Running a 12.04 Ubuntu machine with Chef 11.10.4 and using only the docker cookbook as the sole recipe getting installed via include_recipe 'docker' I get this error
[2014-02-21T17:32:44+00:00] ERROR: uninitialized constant Chef::Mixin::PowershellOut
ec2-54-205-17-117.compute-1.amazonaws.com Recipe Compile Error in /var/chef/cache/cookbooks/windows/providers/feature_powershell.rb [47/543]
ec2-54-205-17-117.compute-1.amazonaws.com ================================================================================
ec2-54-205-17-117.compute-1.amazonaws.com
ec2-54-205-17-117.compute-1.amazonaws.com
ec2-54-205-17-117.compute-1.amazonaws.com NameError
ec2-54-205-17-117.compute-1.amazonaws.com ---------
ec2-54-205-17-117.compute-1.amazonaws.com uninitialized constant Chef::Mixin::PowershellOut
ec2-54-205-17-117.compute-1.amazonaws.com
ec2-54-205-17-117.compute-1.amazonaws.com
ec2-54-205-17-117.compute-1.amazonaws.com Cookbook Trace:
ec2-54-205-17-117.compute-1.amazonaws.com ---------------
ec2-54-205-17-117.compute-1.amazonaws.com /var/chef/cache/cookbooks/windows/providers/feature_powershell.rb:8:in `class_from_file'
ec2-54-205-17-117.compute-1.amazonaws.com
ec2-54-205-17-117.compute-1.amazonaws.com
ec2-54-205-17-117.compute-1.amazonaws.com Relevant File Content:
ec2-54-205-17-117.compute-1.amazonaws.com ----------------------
ec2-54-205-17-117.compute-1.amazonaws.com /var/chef/cache/cookbooks/windows/providers/feature_powershell.rb:
ec2-54-205-17-117.compute-1.amazonaws.com
ec2-54-205-17-117.compute-1.amazonaws.com 1: #
ec2-54-205-17-117.compute-1.amazonaws.com 2: # Author:: Greg Zapp (<[email protected]>)
ec2-54-205-17-117.compute-1.amazonaws.com 3: # Cookbook Name:: windows
ec2-54-205-17-117.compute-1.amazonaws.com 4: # Provider:: feature_powershell
ec2-54-205-17-117.compute-1.amazonaws.com 5: #
ec2-54-205-17-117.compute-1.amazonaws.com 6:
ec2-54-205-17-117.compute-1.amazonaws.com 7: include Chef::Provider::WindowsFeature::Base
ec2-54-205-17-117.compute-1.amazonaws.com 8>> include Chef::Mixin::PowershellOut
ec2-54-205-17-117.compute-1.amazonaws.com 9: include Windows::Helper
ec2-54-205-17-117.compute-1.amazonaws.com 10:
ec2-54-205-17-117.compute-1.amazonaws.com 11: def install_feature(name)
ec2-54-205-17-117.compute-1.amazonaws.com 12: cmd = powershell_out("Install-WindowsFeature #{@new_resource.feature_name}")
ec2-54-205-17-117.compute-1.amazonaws.com 13: Chef::Log.info(cmd.stdout)
ec2-54-205-17-117.compute-1.amazonaws.com 14: end
Anyone else seeing this?
Ubuntu's default runlevel (the userspace compatibility one) is defined in /etc/init/rc-sysinit.conf as 2:
# Default runlevel, this may be overriden on the kernel command-line
# or by faking an old /etc/inittab entry
env DEFAULT_RUNLEVEL=2
The template for the Upstart config only starts Docker on runlevel 3. So using the chef-docker cookbook, docker never starts on boot unless you modify your default runlevel.
A quick grep through all the upstart configs on my relatively fresh 13.04 box shows that nothing else starts on runlevel 3 only. Of the few things that do start on numeric runlevels, they all start on [2345] or at the very least [23]. The example in the runlevel(7) manpage says that you typically use:
start on runlevel [2345]
stop on runlevel [!2345]
A trivial change, but I didn't want to do a pull request without understanding if I'm missing something obvious.
I think now you have to install a gem via Vagrant's internal rubygems.
vagrant gem install vagrant-berkshelf
Similar to Puppet's: http://docs.docker.io/en/latest/use/puppet/
At each chef-client
or knife solo cook
, docker is stopped then restarted event if nothing has changed, no update, no configuration change.
Maybe it would be more interesting to user notifies :restart, "service[docker]"
? To restart it only when needed. (First deployment, Update and Confinguration change)
Investigate if this affects us and remediate if so.
When using the docker_image LWRP, I run into this issue: http://blog.mx17.net/2014/02/12/dockerfile-file-directory-error-using-add/
I have tried every combination of paths to try and get it working, but it seems the way to fix it is to use the dot notation described in the post.
It seems that if I override node["docker"]["version"]
to 0.8.0, I get the following error when running on a CentOS 6.5 Vagrant box (strange that it's in the when 'debian', 'ubuntu'
):
Chef::Exceptions::Package
-------------------------
Version 0.8.0 of docker-io not found. Did you specify both version and release? (version-release, e.g. 1.84-10.fc6)
Resource Declaration:
---------------------
# In /tmp/vagrant-chef-1/chef-solo-1/cookbooks/docker/recipes/package.rb
5: package 'docker-io' do
6: version node['docker']['version']
7: action node['docker']['package']['action'].intern
8: end
9: when 'debian', 'ubuntu'
Compiled Resource:
------------------
# Declared in /tmp/vagrant-chef-1/chef-solo-1/cookbooks/docker/recipes/package.rb:5:in `from_file'
package("docker-io") do
action [:install]
retries 0
retry_delay 2
package_name "docker-io"
version "0.8.0"
cookbook_name :docker
recipe_name "package"
end
I've tried overriding node["docker"]["binary"]["version"]
without overriding node["docker"]["version"]
, but then the docker cookbook just installs the latest Docker instead of 0.8.0.
Berkshelf resolved to version 0.31.0 of the cookbook.
Docker 0.8 has experimental btrfs support. Probably would be great to include a default installation path for the filesystem if it lowers barrier of entry for testing.
I have a really simple recipe wherein I have this in my default recipe include_recipe 'docker'
(along with metadata dependency). This is on Ubuntu 12.04. It appears to install ok, but I get timeout messages once I try to use the LWRPs.
[2014-02-24T22:21:27+00:00] ERROR: docker_image[bflad/testcontainerd] (wickett_docker_host::default line 19) had an error: Helpers::Docker::DockerNotReady: docker timeout exceeded
On the actual box, docker daemon isnt running, and this shows in syslog
...
Feb 24 23:37:12 ip-10-179-7-67 kernel: [18612947.242918] init: docker main process (6188) terminated with status 1
Feb 24 23:37:12 ip-10-179-7-67 kernel: [18612947.242969] init: docker main process ended, respawning
Feb 24 23:37:12 ip-10-179-7-67 kernel: [18612947.297530] init: docker main process (6198) terminated with status 1
Feb 24 23:37:12 ip-10-179-7-67 kernel: [18612947.297581] init: docker main process ended, respawning
Feb 24 23:37:12 ip-10-179-7-67 kernel: [18612947.352694] init: docker main process (6208) terminated with status 1
Feb 24 23:37:12 ip-10-179-7-67 kernel: [18612947.352745] init: docker main process ended, respawning
Feb 24 23:37:12 ip-10-179-7-67 kernel: [18612947.409807] init: docker main process (6218) terminated with status 1
Feb 24 23:37:12 ip-10-179-7-67 kernel: [18612947.409862] init: docker main process ended, respawning
Feb 24 23:37:12 ip-10-179-7-67 kernel: [18612947.467876] init: docker main process (6226) terminated with status 1
Feb 24 23:37:12 ip-10-179-7-67 kernel: [18612947.467928] init: docker main process ended, respawning
Feb 24 23:37:12 ip-10-179-7-67 kernel: [18612947.525358] init: docker main process (6234) terminated with status 1
Feb 24 23:37:12 ip-10-179-7-67 kernel: [18612947.525409] init: docker respawning too fast, stopped
From what I could tell it seems like I could just include_recipe 'docker'
and it would set it all up. Is that the case?
Should I have other dependencies installed to make it work on 12.04?
I was wondering how to conditionally stop a docker container. I have a deployment process that I am writing that needs to stop a running docker container if it is running or if it is not running, then it should cleanly exit and continue on.
I tried something like this:
docker_container "#{app.name}" do
action :stop
not_if('sudo docker ps | grep "#{app.name}" | wc -l')
end
But that didn't seem to work. I am really new to using Chef and Ruby in general, so any help or step in the right direction would be appreciated. Thanks!
Request for comment on adding this feature to all init scripts for docker daemon.
Hey,
When I'm using the cookbook to upgrade docker, it fails with exit code 100. Upon logging into the machine and running "apt-get -f install" I see this:
$ sudo apt-get -f install
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 39 not upgraded.
2 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Setting up lxc-docker-0.7.0 (0.7.0) ...
Configuration file `/etc/init/docker.conf'
==> Modified (by you or by a script) since installation.
==> Package distributor has shipped an updated version.
What would you like to do about it ? Your options are:
Y or I : install the package maintainer's version
N or O : keep your currently-installed version
D : show the differences between the versions
Z : start a shell to examine the situation
The default action is to keep your current version.
*** docker.conf (Y/I/N/O/D/Z) [default=N] ?
Installing new version of config file /etc/init.d/docker ...
Setting up lxc-docker (0.7.0) ...
This is obviously expected, as the chef cookbook overwrites this file. I think we need to somehow preseed dpkg to know what to do in this scenario, then ensure we overwrite the docker.conf + restart docker again AFTER the package installs.
I'm not sure how to do this though, but I can look into it when I have time if you aren't sure either.
I may be wrong here, but I think https://github.com/bflad/chef-docker/blob/master/providers/registry.rb#L29 is always returning true, causing the docker login command to always be skipped. Would checking new_resource.update_by_last_action? have the desired effect? I'm guessing the point of the check is to make sure the login command is only called once for a particular server. I'll try it out and post a PR if it works.
Hey Brian,
I've been testing out this cookbook on 13.10 (in anticipation of 14.04 release), and I'm finding the LXC cookbook, as well as the dpkg-autostart cookbook it depends on, it causing lots of headaches on newer ubuntu releases.
In addition, the cookbook does a lot of additional stuff that's simply not needed for docker (such as creating network interfaces and installing rubygems).
Would you be amenable to removing the dependency from the cookbook and installing the required LXC packages directly? If so I'll get a PR in tomorrow.
Thanks,
Jay
There isn't a community cookbook for this yet, so may need to create a new one.
Currently, you can only specify one bind_uri. Docker supports specifying more than one.
I'll begin work on a PR to do this within a week or so if you'll accept it + this hasn't been fixed by then.
Thanks!
From TODO in devicemapper recipe:
# TODO: Move to its own cookbook
I added a restart notification to the template resource that creates a config file one of my containers relies on. The whole template & docker_container resources look like this:
docker_container 'registry' do
detach true
port '5000:5000'
env ['SETTINGS_FLAVOR=prod']
volume ['/mnt/docker-registry-storage:/tmp/registry', '/mnt/docker-registry-config:/docker-registry/config']
end
template "/mnt/docker-registry-config/config.yml" do
owner "root"
group "docker"
mode "664"
action :create
source "docker-registry-config.yml.erb"
variables :config => {
:loglevel => "debug",
:storage => "local",
:storage_path => "/tmp/registry",
:secret_key => Chef::EncryptedDataBagItem.load("secrets", "docker_registry")["secret_key"]
}
notifies :restart, "docker_container[registry]" # <--- what I added
end
After updating the template, I saw
Recipe: base::docker
* docker_container[registry] action restart
in the Chef output, but the changes didn't take effect until I manually stopped and re-ran the registry container.
Chef (solo) is complaining about the id
Also the id used as container attrute does not work with my chef 11.8
I think the id attribute is used by resource as id attribute
solved this here: computerlyrik/chef-docker@332dff6~1...332dff6
do not know ho to make a pull request out of it
The upstart init script depends on inotifywait (inotify-tools on ubuntu) which isn't installed anywhere in the cookbook, causing the init script to constantly fail with exit 127.
I am not sure if i am getting this right....i am new to docker and this cookbook.
I think chef warns about declaring a same-name resource more than once.
If i think about my (future) configuration:
docker_container "some_image" do
command "/run/my/service1"
action :start
end
docker_container "some_image" do
command "/run/my/service2"
action :start
end
chef will send a warning.
Proposal: use the hostname for name_attribute.
It's pretty unreadable on one big long page.
I noticed that the supported service discovery types are Systemd and Upstart. My needs require Runit, which I was able to get something quickly working. Below are my main files that I use to achieve this:
#!/bin/sh
exec 2>&1
exec docker start <%= @app.name %>
directory "/etc/sv/#{app.name}/" do
action :create
end
template "/etc/sv/#{app.name}/run" do
source "runit.config.erb"
user "root"
owner "root"
group "root"
variables({
:app => app,
})
mode 0755
action :create
end
link "/etc/service/#{app.name}" do
to "/etc/sv/#{app.name}"
mode 0755
link_type :symbolic
action :create
end
My question is if there is a more elegant/better way to achieve this? I would greatly prefer if I could achieve the same results using the chef-docker cookbook. I am new to Chef and Ruby, so all help is greatly appreciated. Thanks!
Hi, I am experiencing a weird error on my Vagrant (Ubuntu 12.04) installation.
I am using latest chef configured with config.omnibus.chef_version = :latest
The recipe looks like:
docker_image node.buildstep.image_name do
tag 'buildstep'
image_url node.buildstep.stack_url
action :build
end
It seems that it trying to run the right command which is docker build -t buildstep:buildstep github.com/progrium/buildstep
.
When I run this command manually as root in my vagrant installation it works nicely and it returns code 0. While chef fails:
STDERR:
---- End output of docker build -t buildstep:buildstep github.com/progrium/buildstep ----
[2013-12-10T05:21:36+00:00] FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1)
Nothing more, no backtrace. Thank you for a help
I'm trying out this recipe and had the following error on vagrant up ubuntu1304
after following the instructions. I'm relatively new to vagrant, new to chef and definitely new to using as complete a configuration as this, so I may need some guidance on how to provide decent information. Running on Mac OS X Mountain Lion using Vagrant 1.27.
The VM is up and running and I can ssh to it - it's just the docker setup that didn't complete.
Here is the relevant part of the vagrant up output:
[2013-08-07T02:53:03+00:00] DEBUG: Loading cookbook lxc's resources from /tmp/vagrant-cache/chef-solo-1/cookbooks/lxc/resources/container.rb
[2013-08-07T02:53:03+00:00] DEBUG: filtered backtrace of compile error: /tmp/vagrant-cache/chef-solo-1/cookbooks/lxc/resources/container.rb:18:in `class_from_file'
[2013-08-07T02:53:03+00:00] DEBUG: filtered backtrace of compile error: /tmp/vagrant-cache/chef-solo-1/cookbooks/lxc/resources/container.rb:18:in `class_from_file'
[2013-08-07T02:53:03+00:00] DEBUG: backtrace entry for compile error: '/tmp/vagrant-cache/chef-solo-1/cookbooks/lxc/resources/container.rb:18:in `class_from_file''
[2013-08-07T02:53:03+00:00] DEBUG: Line number of compile error: '18'
================================================================================
Recipe Compile Error in /tmp/vagrant-cache/chef-solo-1/cookbooks/lxc/resources/container.rb
================================================================================
NameError
---------
uninitialized constant Chef::EncryptedDataBagItem::DEFAULT_SECRET_FILE
Cookbook Trace:
---------------
/tmp/vagrant-cache/chef-solo-1/cookbooks/lxc/resources/container.rb:18:in `class_from_file'
Relevant File Content:
----------------------
/tmp/vagrant-cache/chef-solo-1/cookbooks/lxc/resources/container.rb:
11: attribute :server_uri, :kind_of => String
12: attribute :chef_environment, :kind_of => String, :default => '_default'
13: attribute :node_name, :kind_of => String
14: attribute :run_list, :kind_of => Array
15: attribute :chef_enabled, :kind_of => [TrueClass, FalseClass], :default => false
16: attribute :chef_retries, :kind_of => Fixnum, :default => 0
17: attribute :copy_data_bag_secret_file, :kind_of => [TrueClass, FalseClass], :default => false
18>> attribute :data_bag_secret_file, :kind_of => String, :default => Chef::EncryptedDataBagItem::DEFAULT_SECRET_FILE
19: attribute :default_bridge, :kind_of => String
20: attribute :static_ip, :kind_of => String
21: attribute :static_netmask, :kind_of => String, :default => '255.255.255.0'
22: attribute :static_gateway, :kind_of => String
23: attribute :default_config, :kind_of => [TrueClass, FalseClass], :default => true
24: attribute :default_fstab, :kind_of => [TrueClass, FalseClass], :default => true
25: attribute :container_commands, :kind_of => Array, :default => []
26: attribute :initialize_commands, :kind_of => Array, :default => []
27: attribute :clone, :kind_of => String
[2013-08-07T02:53:03+00:00] DEBUG: Re-raising exception: NameError - uninitialized constant Chef::EncryptedDataBagItem::DEFAULT_SECRET_FILE
/tmp/vagrant-cache/chef-solo-1/cookbooks/lxc/resources/container.rb:18:in `class_from_file'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/mixin/from_file.rb:42:in `class_eval'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/mixin/from_file.rb:42:in `class_from_file'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/resource/lwrp_base.rb:54:in `build_from_file'
When trying to run the docker:default recipe in a new vagrant instance my chef run fails while running the lxc:default recipe. An issue reported by @paulczar for the lxc cookbook shows the error message I am getting and proposes a possible solution. I'm providing a link here so people can quickly determine if their failing builds are caused by the same issue
Here the error message reported on PR mentioned above:
Setting up lxc (0.7.5-3ubuntu67) ... Configuration file `/etc/default/lxc' ==> File on system created by you or by a script. ==> File also in package provided by package maintainer. What would you like to do about it ? Your options are: Y or I : install the package maintainer's version N or O : keep your currently-installed version D : show the differences between the versions Z : start a shell to examine the situation The default action is to keep your current version. *** lxc (Y/I/N/O/D/Z) [default=N] ? invoke-rc.d: policy-rc.d denied execution of start. lxc-net start/running
I've found that several edge cases in the current LWRPs are caused by failures in parsing or handling the output from docker
shell commands. Docker has a REST API, which should be much more reliable for communicating without issue. There's even a ruby client implementing the api: https://github.com/swipely/docker-api
The major drawback of such an approach, AFAIK, is that the docker api sometimes makes breaking changes. We might have to handle various versions of docker differently (although hopefully this is stabilizing as we're approaching docker 1.0)
Starting a docker container after using this cookbook on a brand-new install of Ubuntu 13.10 results in an error:
docker run hrafique/oracle-jdk7 java -version
lxc-start: failed to spawn '4acb69c65da0d6b94d3c46cdad9f282385e9bb2131afd462d9991aabe550bb84'
Installing cgroup-bin fixes this.
I'm provisioning new Ubuntu 13.10 nodes in EC2 using knife-ec2. When I use docker::default to install Docker and then a docker_container resource after that, I get the error:
dial unix /var/run/docker.sock: no such file or directory
But when I SSH into the machine, that file is there and docker is running.
Here's the command that it attempts to run the container with:
docker run -cidfile /var/run/registry.cid -d -e SETTINGS_FLAVOR=prod -name registry -p 5000:5000 -v /mnt/docker-registry-storage:/tmp/registry -v /mnt/docker-registry-config:/docker-registry/config registry
When I SSH in immediately after the first Chef run, that command succeeds.
Any ideas?
From TODO in lxc recipe:
# TODO: Platforms handled here should be fixed in lxc cookbook
# Currently: https://github.com/hw-cookbooks/lxc/
Creating in case we need to add to sysconfig/default files.
It would be very useful to be able to specify the run command when committing a container, like in the case where some one needs to interact with Docker outside of Chef and may have no access to the run command specified in the recipe.
[2014-01-02T21:37:22+00:00] INFO: Running queued delayed notifications before re-raising exception
[2014-01-02T21:37:22+00:00] DEBUG: Re-raising exception: Mixlib::ShellOut::ShellCommandFailed - docker_container[cassandra-dev] (my_cookbook::my_recipe line 37) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '1'
---- Begin output of docker run -cidfile /var/run/trusty-cassandra-standalone.cid -d -name trusty-cassandra-standalone -p 9160:9160 jayofdoom/trusty-cassandra-standalone ----
STDOUT:
STDERR: 2014/01/02 21:37:22 Error: create: Conflict, The name trusty-cassandra-standalone is already assigned to 17c85bdc5d0c. You have to delete (or rename) that container to be able to assign trusty-cassandra-standalone to a container again.
---- End output of docker run -cidfile /var/run/trusty-cassandra-standalone.cid -d -name trusty-cassandra-standalone -p 9160:9160 jayofdoom/trusty-cassandra-standalone ----
Ran docker run -cidfile /var/run/trusty-cassandra-standalone.cid -d -name trusty-cassandra-standalone -p 9160:9160 jayofdoom/trusty-cassandra-standalone returned 1
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/mixlib-shellout-1.2.0/lib/mixlib/shellout.rb:251:in `invalid!'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/mixlib-shellout-1.2.0/lib/mixlib/shellout.rb:237:in `error!'
/tmp/vagrant-chef-1/chef-solo-1/cookbooks/docker/providers/container.rb:157:in `run'
/tmp/vagrant-chef-1/chef-solo-1/cookbooks/docker/providers/container.rb:43:in `block in class_from_file'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/provider/lwrp_base.rb:138:in `instance_eval'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/provider/lwrp_base.rb:138:in `block in action'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/provider.rb:118:in `run_action'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/resource.rb:625:in `run_action'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/runner.rb:49:in `run_action'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/runner.rb:81:in `block (2 levels) in converge'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/runner.rb:81:in `each'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/runner.rb:81:in `block in converge'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/resource_collection.rb:98:in `block in execute_each_resource'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/resource_collection/stepable_iterator.rb:116:in `call'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/resource_collection/stepable_iterator.rb:116:in `call_iterator_block'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/resource_collection/stepable_iterator.rb:85:in `step'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/resource_collection/stepable_iterator.rb:104:in `iterate'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/resource_collection/stepable_iterator.rb:55:in `each_with_index'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/resource_collection.rb:96:in `execute_each_resource'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/runner.rb:80:in `converge'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/client.rb:429:in `converge'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/client.rb:494:in `do_run'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/client.rb:199:in `block in run'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/client.rb:193:in `fork'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/client.rb:193:in `run'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/application.rb:183:in `run_chef_client'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/application/solo.rb:239:in `block in run_application'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/application/solo.rb:231:in `loop'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/application/solo.rb:231:in `run_application'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/application.rb:66:in `run'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/bin/chef-solo:25:in `<top (required)>'
/usr/bin/chef-solo:23:in `load'
/usr/bin/chef-solo:23:in `<main>'
[2014-01-02T21:37:22+00:00] ERROR: Running exception handlers
[2014-01-02T21:37:22+00:00] ERROR: Exception handlers complete
[2014-01-02T21:37:22+00:00] FATAL: Stacktrace dumped to /var/chef/cache/chef-stacktrace.out
[2014-01-02T21:37:22+00:00] DEBUG: Mixlib::ShellOut::ShellCommandFailed: docker_container[cassandra-dev] (my_cookbook::my_recipe line 37) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '1'
---- Begin output of docker run -cidfile /var/run/trusty-cassandra-standalone.cid -d -name trusty-cassandra-standalone -p 9160:9160 jayofdoom/trusty-cassandra-standalone ----
STDOUT:
STDERR: 2014/01/02 21:37:22 Error: create: Conflict, The name trusty-cassandra-standalone is already assigned to 17c85bdc5d0c. You have to delete (or rename) that container to be able to assign trusty-cassandra-standalone to a container again.
---- End output of docker run -cidfile /var/run/trusty-cassandra-standalone.cid -d -name trusty-cassandra-standalone -p 9160:9160 jayofdoom/trusty-cassandra-standalone ----
Ran docker run -cidfile /var/run/trusty-cassandra-standalone.cid -d -name trusty-cassandra-standalone -p 9160:9160 jayofdoom/trusty-cassandra-standalone returned 1
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/mixlib-shellout-1.2.0/lib/mixlib/shellout.rb:251:in `invalid!'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/mixlib-shellout-1.2.0/lib/mixlib/shellout.rb:237:in `error!'
/tmp/vagrant-chef-1/chef-solo-1/cookbooks/docker/providers/container.rb:157:in `run'
/tmp/vagrant-chef-1/chef-solo-1/cookbooks/docker/providers/container.rb:43:in `block in class_from_file'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/provider/lwrp_base.rb:138:in `instance_eval'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/provider/lwrp_base.rb:138:in `block in action'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/provider.rb:118:in `run_action'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/resource.rb:625:in `run_action'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/runner.rb:49:in `run_action'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/runner.rb:81:in `block (2 levels) in converge'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/runner.rb:81:in `each'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/runner.rb:81:in `block in converge'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/resource_collection.rb:98:in `block in execute_each_resource'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/resource_collection/stepable_iterator.rb:116:in `call'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/resource_collection/stepable_iterator.rb:116:in `call_iterator_block'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/resource_collection/stepable_iterator.rb:85:in `step'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/resource_collection/stepable_iterator.rb:104:in `iterate'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/resource_collection/stepable_iterator.rb:55:in `each_with_index'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/resource_collection.rb:96:in `execute_each_resource'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/runner.rb:80:in `converge'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/client.rb:429:in `converge'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/client.rb:494:in `do_run'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/client.rb:199:in `block in run'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/client.rb:193:in `fork'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/client.rb:193:in `run'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/application.rb:183:in `run_chef_client'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/application/solo.rb:239:in `block in run_application'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/application/solo.rb:231:in `loop'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/application/solo.rb:231:in `run_application'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/lib/chef/application.rb:66:in `run'
/opt/chef/embedded/lib/ruby/gems/1.9.1/gems/chef-11.6.0/bin/chef-solo:25:in `<top (required)>'
/usr/bin/chef-solo:23:in `load'
/usr/bin/chef-solo:23:in `<main>'
[2014-01-02T21:37:22+00:00] FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1)
Chef never successfully completed! Any errors should be visible in the
output above. Please fix your recipes so that they properly complete.
My immediate hunch is that we aren't finding the container in load_current_resource somehow if it's not running. I'll dig into this more later.
Hi,
Thanks for the cookbook, I was wondering if it was not designed to be idempotent ?
I am basically using the docker_container resource, however with each chef run a new container is created !
Any hints ?
Add node['docker']['group_members']
attribute and group recipe that utilizes group resource.
This is less a direct "issue" and more a question about how you guys do things, and if the cookbook facilitates something in a way I don't expect right now.
Lets say I have a container running some software. I build the container using something like this in my chef repo:
git '/data/software' do
repository "https://github.com/org/software"
revision "master"
end
docker_image "software-image" do
path "/data/software"
cmd_timeout 60000
action :build
end
docker_container "software-container" do
container_name "software-container"
image "software-image"
init_type "upstart"
volume ["/data/persistentdata:/data/persistentdata"]
command "--datadir /data/persistentdata"
detach true
end
What would be the steps you'd follow to update the container when the git repository updates? Should I have to write out all the orchestration in chef? Create a versioned image and container? Something like this, perhaps?
docker_image "software-#{version}" do
path "/data/software"
action :build
end
docker_container "software-container-#{oldversion}" do
[snip]
action :remove
end
docker_container "software-container-#{version}" do
[snip]
action :create
end
All the options I've found seem tedious or difficult, and I'm curious how you're solving that problem.
Thanks,
Jay
Do we care? Probably would complicate things, but submitting issue for discussion.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.