Reliably Deploying Rails Applications: Hassle free provisioning, reliable deployment (2014)

5.4 - Applying a node definition to a VPS

Overview

In this section we’ll take our simple Redis cookbook and apply it to a VPS.

An important note. This Redis configuration is intended to be a simple example of using chef, in practice such a system would have several other components including security and user management. For this reason this setup should not be used in production, instead look to Section 6 onwards for a production ready stack.

Download additional cookbooks

In this simple example, we’re manually copying the cookbooks we need into site-cookbooks. Recall that when we created our simple Redis role in the previous chapter, we used two new cookbooks; monit_configs-tlq and monit-tlq. In order for our role to work, we’ll need to clone these cookbooks into site-cookbooks.

Move into the site-cookbooks directory and enter:

1 git@github.com:TalkingQuickly/monit-tlq.git

2 git@github.com:TalkingQuickly/monit_configs-tlq.git

To add these.

Set up the VPS

Begin by creating a VPS on your favorite cloud provider, my preference for testing is Digital Ocean and Linode for production. I suggest using Ubuntu 12.04.

Once your image is ready, copy your public key

1 ssh-copy-id root@yourserverip

Install chef on the remote machine

Now move into the root of our cookbook directory (my_first_chef_repo).

It used to be necessary to manually install chef on the remote machine, happily knife solo will now take care of this for us. Use the following command to install chef on the remote machine:

1 bundle exec knife solo prepare root@yourserverip

This will:

· Create a file yourserverip.json within the nodes folder

· SSH into the remote machine

· Detect the operating system

· Install the correct version of chef

Now enter the below (from 5.2) into the yourserverip.json file:

1 {

2 "redis": {

3 "dont_bind" : false

4 },

5 "run_list":

6 [

7 "role[redis-server]"

8 ]

9 }

Applying the recipe is simple, just enter the following command:

1 bundle exec knife solo cook root@yourserverip

The cook command will:

· SSH into the remote machine

· Copy your local recipe files to the remote machine

· Apply the recipes and show the output

If you now ssh into the remote machine you can verify that the redis-server package is installed using:

1 dpkg -l redis-server

Additionally if you look at our config file in cat /etc/redis/redis.conf

You’ll see that it matches the config file we defined in 5.1, in particular that it includes the line:

1 bind 127.0.0.1

which correctly reflects the dont_bind: false parameter in our node definition file.

Make a change and re-apply

So far we’ve shown that chef allows us to define the steps we would normally take to provision a new server, define them in an easy to read format and apply them to a fresh VPS.

Chefs real power is in allowing us to manage the process of iterating on a server configuration.

Let’s say, for example, that we’d begun as above with the “dont_bind” parameter set to false. Further down the line we discover we need to share the Redis install with other machines and so allow external connections.

Change the yourserverip.json file to have dont_bind set to true:

1 {

2 "redis": {

3 "dont_bind" : true

4 },

5 "run_list":

6 [

7 "role[redis-server]"

8 ]

9 }

Save the file and enter the command to apply the node definition to the remote machine again:

1 bundle exec knife solo cook root@yourserverip

You’ll see from the output that chef detects that there have been no changes to our Redis script in init.d but when it comes to redis.conf it detects the changes and updates it, displaying the diff in the output.

Once the command completes, if you ssh into the server and re-examine out redis.conf file, you’ll see that the bind 127.0.0.1 line has been removed in accordance with our dont_bind: true attribute.

Summing Up

Chef allows us to easily define the commands we need to provision a server and the file changes which go with these.

When we make changes to these setups, chef will intelligently detect where we have made changes and apply these accordingly.

This makes it simple to iterate on our infrastructure configuration whilst maintaining a blueprint to easily recreate it either when we need to scale or to recover from server failures.

It should be noted here that there are limits to the type of change chef will automatically detect. Whilst chef will detect additions and subtractions to/ from configuration files (e.g. anything templates are being used for), it will not automatically handle the removal of a recipe or role.

So for example if we initially included the redis-server role in our run list and subsequently removed it, chef would not attempt to uninstall the packages associated with that node or remove the config files.

In the next chapter we’ll begin working with the example Rails Configuration template available at:

https://github.com/TalkingQuickly/rails-server-template

This template forms the basis of a configuration we can use in a production environment using exactly the principals and methods discussed in this section.