The Ultimate Guide to Configuring a Rails App on Amazon EC2 with Chef: Part 3

This article ends a series of posts we wrote about configuring Rails apps with the Chef automation platform and Amazon EC2. Gained knowledge in previous parts, we’ll finish writing cookbooks and secure our server. We’ll also go through the whole process of deployment of the Spree application on Ruby on Rails to EC2 instance we set up earlier.

Security setup

At this stage, you need to secure your app by installing and configuring OpenSSH.

OpenSSH

To enable authentication via SSH, install OpenSSH using the openssh cookbook.

Add the necessary dependencies in the Berksfile.

Create a cookbook.

Set the metadata for the cookbook.

Create default attributes for the cookbook.

Cancel authentication with the password_authentication password and disable print_motd, which determines whether the SSH daemon should print the contents of the /etc/motd file when the user logs on to the server.

Create a default recipe for the cookbook.

Then you need to connect an external cookbook to install Redis.

Finally, add all these cookbooks to the security role.

In roles/security.rb

Also add the security role to the run list of the YOUR_IP_ADDRESS.json node.

Managing and monitoring system processes

At this stage, you need to monitor the state of the processes for the following installed software:

• PostgreSQL
• Redis
• Nginx
• Puma

To monitor the state of these processes, use Monit. To install and configure Monit, use chef-monit.

Add the necessary dependencies in the Berksfile.

Create a cookbook.

Set the metadata for the cookbook.

To make it more convenient to support app attributes in future, move the Monit username and password attributes to app-attributes:

Replace USERNAME and PASSWORD with your own values. Later (in the part about application deployment), we’ll show you a way to store this kind of information more securely using encrypted_data_bags.

Now create default attributes for the cookbook.

Define the following attributes:

Now you can write recipes and templates of the Monit configuration for the software listed above.

PostgreSQL

Let’s create a recipe to connect Monit to PostgreSQL.

Сonnect an external cookbook and a PostgreSQL template with configurations.

Then create a template.

Write the following:

Next, update the run list for the database role.

Redis

Create a recipe to connect Monit to Redis.

You need to connect an external cookbook and connect the Redis template to your configurations.

Create a template.

Add the following to this template:

Now, add this recipe to the web role.

Nginx

Let’s create a recipe to integrate Monit with Nginx.

Сonnect an external cookbook and integrate the Nginx template with configurations.

Now create a template.

In this template, write the following:

You also need to add this recipe, which has also been added to the web role.

Puma

Create a recipe to integrate Monit with Puma.

You need to connect an external cookbook and integrate the Puma template with configurations.

Next, create a template.

Write the following in this template:

Then add this recipe to the web role.

Deployment

Setup

We’ll look at how you can deploy an app using Chef in this section of our tutorial.

The basics

Let’s start from creating the app-deploy cookbook where you’ll describe the recipe for app deployment.

First, add dependencies to the metadata.

Use encrypted_data_bags to store confidential project information like the password from the database or keys from external services (AWS and others).

Why do we use encrypted_data_bags?

The main reason is security. With encrypted_data_bags, all data is stored in an encrypted form. So even if an attacker gets access to the repository with scripts, they won’t be able to use the confidential information.

To be able to use encrypted data bags, you need to create a file where the encryption and decryption keys will be stored. Use OpenSSL to generate the private key and put it in the file encrypted_data_bag_secret.

Warning!!! If you overwrite the existing encrypted_data_bag_secret file or delete it, you won’t be able to decrypt previously encrypted data.

In the terminal, run this command to create a key:

Warning!!! You shouldn’t store the created file in the repository. You should, however, share this file with your team members. Therefore, you need to add it to .gitignore.

Next, indicate the encrypted_data_bag_secret add-on for knife solo.

Using knife solo, create a configuration file for the dev environment with the private key.

In the text editor opened by terminal, enter the database credentials, secret application keys, and Monit credentials.

Once you’ve saved your data to /data_bags/configs/dev.json, you’ll see that this data is now encrypted.

Replace the values set in 5.2 and 5.5 steps with those that were set during the 5.2 Database setup and 5.5 Monit setup steps.

You can edit data from encrypted data bags using the following command:

And you can read this data with this command:

Since your keys and credentials are now stored in an encrypted_data_bag, you can remove the explicit definition of Monit credentials from app-attributes.

Set up SSH

The application is in the private repository. Therefore, to shrink the project, use an SSH wrapper. To do this, you’ll need to have SSH keys which you’ll put in your cookbook.

If you don’t have an SSH key, you can generate one using the command below. You must not set a password on the private key as this password will block the chef-client during the launch of deployment scripts. You’ll also need to specify your email address instead of example@gmail.com.

Then, create a directory – site-cookbooks/app-deploy/files – where you’ll put the private and public keys.

Afterward, put the keys in the created files.

Warning!!! You should add the site-cookbooks/app-deploy/files/default directory to .gitignore since no one should know your private key.

Next, create a default recipe where you’ll further describe the deployment process.

At the top of this file, define the variables you’ll be working with in the recipe:

Now we’ll start to describe the recipe for deploying the application.

The recipe will consist of several stages:

• Using SSH keys
• Creating shared directories
• Creating a database and Puma configuration

Using SSH keys

First, we’ll describe the usage of SSH keys:

Create shared directories

Create database and PUMA configurations

1. Database configuration

Let’s describe the use of the template with the configuration for database access.

Next we’ll create a template:

2. Application configurations

Here you need to describe the generation of the application.yml file where you’ll be storing the project environment variables.

3. Puma

Now you need to describe how to use the template with configurations:

You also need to create the template with the configuration:

4. Sidekiq configurations

First, describe how to use the template with the Sidekiq configuration:

Next, create a template with the configuration.

Deployment

Now we want to introduce the application deployment. Generally, deployment happens in four stages:

1. Checkout ‒ The chef-client uses the Source Code Management (SCM) resource to get the specified application revision and places a clone or checkout in the subdirectory of the deploy directory named cached-copy. Then a copy of the application is placed in this subdirectory.
2. Migrate ‒ If the migration is to be run, the chef-client symbolically links the database configuration file into the checkout (config/database.yml by default) and runs the migration command. For a Ruby on Rails application, migration_command is usually set to rake db: migrate.
3. Symlink ‒ Directories for shared and temporary files are removed from the checkout (log, tmp/pids, and public/system by default). After that, you need to create any necessary directories (tmp, public, and config by default) if they don’t exist. At the end of this step, you symlink shared directories into the current release, public/system, tmp/pids, and log directories, and then symlink the release directory to current.
4. Restart ‒ Restart the app using the restart command set in the recipe.

Here are the tasks for application deployment one by one:

Applying Configurations

Now you need to add the app-deploy cookbook to the deploy role to use this cookbook further in the node.

Describe basic information about the role and its run list.

Next, add this role to the general run list of the nodes/YOUR_IP_ADDRESS.json node.

Now you’re ready to apply the scripts you’ve written to launch the app on the server.

Install Chef and apply all configurations using the following command:

Once you’ve completed the deployment, the Spree application will be available through public DNS. In our example, the address is ec2-18-221-230-71.us-east-2.compute.amazonaws.com.

Now you can log on to the server via SSH as the deployer user:

In future, you can deploy the app to a remote machine with the following command:

On a global scale, Chef allows you to take advantage of dynamic infrastructure, easily start new servers, and safely dispose of servers when they’re replaced by newer configurations or when load decreases.

We hope this tutorial has been helpful for you. Share your experience using Chef in the comments below.