#berkshelf

One of the easiest ways to get started is by using Berkshelf but here is also where most of the problems come in - so I decided to write a blog post on it and do a presentation on my findings.

It might be easy to get berkshelf via chef-dk but that’s not much fun for few reasons: not a clear understanding how bits fit together, locked into a concrete version of berkshelf - things can start to break if updated on their own, not the latest, bleeding edge version by definition - which is not much fun.

Here it goes. To start we need latest stable ruby version (2.2.2 at the time of writing).

rvm install 2.2.2 # install latest stable ruby version at the time of writing rvm use 2.2.2 # using installed ruby version gem install berkshelf # install berkshelf

Now that we have berkshelf installed lets install virtualbox, vagrant and test-kitchen so that we can start writing infrastucture code.

apt-get install virtualbox -y # install oracle virtual box wget https://bit.ly/vagrant172 dpkg -i vagrant172 # install vagrant for automating vboxes gem install test-kitchen # installs test-kitchen gem so that berks puts it into Gemfile

Lets scaffold our cookbook called hello-infra

berks cookbook hello-infra # generate infrastructure as code layout

and pull in dependecies.

cd hello-infra gem install bundler # install bundler gem bundle install # install test-kitchen from Gemfile

Lets change defaults to use chef-zero instead of chef-solo and use debian instead of ubuntu. Vagrant will work faster with debian than ubuntu since it’s server distro and less stuff comes with it pre-installed.

sed -i 's/chef_solo/chef_zero/g' .kitchen.yml # use chef zero instead of solo sed -i 's/ubuntu-12.04/debian-7.8/g' .kitchen.yml # use debian instead of ubuntu sed -i '10d' .kitchen.yml # remove centos from platfor list to begin with

Test-kitchen comes with handy commands to see if we got the configuration right.

kitchen list # outputs list of boxes configured kitchen diagnose # outputs the list of box properties

Lets create the box, converge and verify to make sure we have everything set up correctly and good to start writing infrastructure code.

kitchen create # creates a new virtual box > 8 min in case it has to download box from internet kitchen converge # converges instance with recipe kitchen verify # verify tests after box's converged, first time around will pull down and install chef

The initial .kitchen.yml file should look like this:

provisioner: name: chef_zero platforms: - name: debian-7.8 suites: name: default run_list: [‘hello-infra’]

To demonstrate test-kitchen lets build a simple nodejs app powered by supervisor and reverse proxied by nginx iteratively using TDD cycle. Lets create our first failing infrastructure test.

describe command('node -v’) do its(:exit_status) { should eq 0 } end

And run tests.

kitchen verify # should output failing test

To make the test pass we need to make changes to these files.

tail -1 metadata.rb depends 'nodejs' tail -1 Bershelf cookbook 'nodejs' cat recipes/default.rb include_recipe 'nodejs'

Now after running kitchen converge the tests pass and nodejs is installed on server. We repeat these TDD steps for creating a simple hello-world nodejs app, installing nginx, and configuring supervisor service. The resulting file tree structure looks like this:

. ├── attributes ├── Berksfile ├── Berksfile.lock ├── CHANGELOG.md ├── chefignore ├── files │   └── default │   ├── default │   └── simple.js ├── Gemfile ├── Gemfile.lock ├── libraries ├── LICENSE ├── metadata.rb ├── providers ├── README.md ├── recipes │   └── default.rb ├── resources ├── setup.sh ├── spec │   └── default_spec.rb ├── teardown.sh ├── templates │   └── default ├── test │   └── integration │   └── default │   ├── bats │   │   └── autorestart.bats │   ├── rspec │   │   └── hello-world_spec.rb │   └── serverspec │   └── webserver_spec.rb ├── Thorfile └── Vagrantfile

The contents of the test files are:

cat test/integration/default/serverspec/webserver_spec.rb require 'serverspec' set :backend, :exec describe command('node -v') do its(:exit_status) { should eq 0 } end describe port(3000) do it { should be_listening } end describe port(80) do it { should be_listening } end cat test/integration/default/bats/autorestart.bats #!/usr/bin/env bats @test 'should automaticaly restart hello world app' { run pkill node sleep 5 command curl localhost:3000 } cat test/integration/default/rspec/hello_world_spec.rb require 'net/http' describe 'website' do it 'should send greatings' do endpoint = Net::HTTP.new('localhost', 80) response = endpoint.get('/') expect(response.body).to match 'Hello World' end end

The contents of files are:

cat recipe/default.rb include_recipe 'nodejs' include_recipe 'supervisor' cookbook_file 'simple.js' do path 'srv/simple.js' end package 'nginx' cookbook_file 'default' do path '/etc/nginx/sites-available/default' notifies :restart, 'service[nginx]' end service 'nginx' do action [:start] end supervisor_service 'hello-world' do command 'node /srv/simple.js' action :enable autostart true autorestart true end cat files/default/simple.js var http = require('http'); http.createServer(function(req, res) { res.writeHead(200); res.end('Hello World'); }).listen(3000); cat files/default/default server { location / { proxy_pass http://127.0.0.1:3000; } }

To demonstrate chefspec I've also added spec/default_spec.rb for recipe.

require 'chefspec' require 'chefspec/berkshelf' describe 'test::default' do let(:chef_run) { ChefSpec::SoloRunner.converge(described_recipe) } before do stub_command("netstat -l | grep :3000").and_return(false) end it 'installs nodejs recipe' do expect(chef_run).to include_recipe('nodejs') end it 'installs nginx package' do expect(chef_run).to install_package('nginx') end it 'enables nginx' do expect(chef_run).to start_service('nginx') end end

Chefspec can come in handy when testing combinations of data bags and commands running on multiple platforms, however I would only use them if something's hard or takes very long time to test using integration tests. Integration tests give the most confidence and aren't tied to implementation - verifies that implementation fulfils the contract. This makes implemtation easy to change without breaking tests.

Yesterday I ran into a problem with the vagrant-berkshelf plugin. When I was running vagrant up, i got the following exception:

/Users/apapai/.vagrant.d/gems/gems/vagrant-berkshelf-4.0.1/lib/vagrant-berkshelf/action/upload.rb:73:in `read': wrong number of arguments (0 for 1..4) (ArgumentError)

This sounds bad. But luckily it's just a typo. Since nobody uses nowadays custom config for berkshelf, it was not caught by others.

もうね、正直使うのやめたいｗｗ

でも OpsWorks が Chef 使えっていうんだからしょうがない… なんだかんだ、デファクトスタンダードだしな。

ハマりどころとしては2点。

リポジトリURLとバージョン(タグ)の指定方法 specify repository URL and version(tag name) at the same time

ネストされた Berksfile (依存関係) の解決 resolve dependencies for nested Berkfile

!! この記事は Qiita に移動しました !!

When you have to build a list, its always nice to have it ordered, but what is very important, is the order that you choose and how that affects the outcome.

Collection of useful links

Simple berkshelf and vagrant examples.  Good beginning post:

http://red-badger.com/blog/2013/06/24/berkshelf-application-cookbooks/

Writing Chef cookbooks the berkshelf way.  These blog entries from Mischa Taylor are the best I've found explaining a full development iteration cycle using berkshelf with vagrant:

http://misheska.com/blog/2013/06/16/getting-started-writing-chef-cookbooks-the-berkshelf-way/

Seth Vargo on using individual cookbooks with Berkshelf

http://sethvargo.com/20130102/moving-to-individual-cookbooks/

Good guide on basic cookbook authoring