
Amazon Cloud Auto-Configuration with Chef-Solo
- From the sandbox
- Tutorial
Hello!
In this article I want to talk about autoconfiguration in the cloud. For example, we’ll run an ec2 instance on which WordPress will “get ready”.
By autoconfiguration, I understand the automatic installation and configuration of packages, the deployment of applications. The configuration process should go without ssh login to the configurable instance, literally with one command.

To get an instance with WordPress installed, we need Amazon EC2 API Tools and Chef-Solo , as well as a cookbook for it.
Cookbook is a collection of recipes according to which Chef-Solo will “prepare” the server (configure it). We will need several such "cookbooks", namely:
Everything except wp is a cookbook from the community repository . wp is a simple one-recipe cookbook with which Chef-Solo downloads the latest version of WordPress from svn, creates a database and installs it. All the necessary cookbooks I collected in the git repository .
To run Chef-Solo, two configuration files, solo.rb and node.json, are required.
solo.rb:
node.json:
The preparations are finished, you can proceed. All that remains for us is to raise the instance with a command from the Amazon EC2 API Tools suite:
download cookbooks and configs, install and run chef-solo.
But! We agreed that we won’t go to the instance via ssh. How do we execute several commands without logging in to the instance? The very useful AWS function, user-data, will help us . Using it, you can transfer any data to the instance, including executing bash scripts.
chef-solo-inst.sh:
Now we are ready to raise an autoconfigured instance:
After a few minutes, you can run the ec2-describe-instances command, copy the dns name of the raised instance and open http: // {instance_dns_name} / wp in the browser, and the WordPress settings page should open:

If the page is unavailable, then something went wrong So. What exactly can be found by looking at the log file autoconf-log. {Date}, which will lie on the instance in the / root directory.
Thus, we got a fully tuned and ready to work instance. Using chef recipes in conjunction with user-data, you can configure systems of any complexity. Moreover, recipes can be cross-platform, and with their help you can configure instances with different OS.
The most interesting thing about this approach is that we work with infrastructure as a code (Infrastructure as a Code). Therefore, you can use the same methods as in software development (for example, TDD ).
This article shows one of the simplest ways to autoconfigure, but you can go further: make images with the chef client already installed, so that the instance, when launched, is configured by the chef server depending on the role. But this is the topic for the next article.
In this article I want to talk about autoconfiguration in the cloud. For example, we’ll run an ec2 instance on which WordPress will “get ready”.
By autoconfiguration, I understand the automatic installation and configuration of packages, the deployment of applications. The configuration process should go without ssh login to the configurable instance, literally with one command.

To get an instance with WordPress installed, we need Amazon EC2 API Tools and Chef-Solo , as well as a cookbook for it.
Cookbook is a collection of recipes according to which Chef-Solo will “prepare” the server (configure it). We will need several such "cookbooks", namely:
Everything except wp is a cookbook from the community repository . wp is a simple one-recipe cookbook with which Chef-Solo downloads the latest version of WordPress from svn, creates a database and installs it. All the necessary cookbooks I collected in the git repository .
To run Chef-Solo, two configuration files, solo.rb and node.json, are required.
solo.rb:
file_cache_path "/var/chef-solo"
cookbook_path "/var/chef-solo/cookbooks"
This sets the path to cookbooks. node.json:
{
"run_list": [
"recipe[php::package]",
"recipe[php::module_mysql]",
"recipe[apache2]",
"recipe[apache2::mod_php5]",
"recipe[subversion]",
"recipe[mysql::server]",
"recipe[wp]"
],
"php" : { "conf_dir" : "/etc/" },
"mysql" : { "server_root_password" : "xxxie0AiquaiX",
"service_name" : "mysqld",
"platform" : "amazon" }
}
In this file, specify which recipes to run, and set the parameters. The preparations are finished, you can proceed. All that remains for us is to raise the instance with a command from the Amazon EC2 API Tools suite:
ec2-run-instances {ami} -t {instance shape} -k {key_name},
download cookbooks and configs, install and run chef-solo.
But! We agreed that we won’t go to the instance via ssh. How do we execute several commands without logging in to the instance? The very useful AWS function, user-data, will help us . Using it, you can transfer any data to the instance, including executing bash scripts.
chef-solo-inst.sh:
#!/bin/bash -x
#write logs
LOGS="/root/autoconf-log.$(date -I)"
exec > $LOGS 2>&1
SOLODIR="/var/chef-solo"
CFGDIR="$SOLODIR/wp-aws-chef-solo"
#install Chef
rpm -ivh http://opscode-omnitruck-release.s3.amazonaws.com/el/6/x86_64/chef-10.14.4-2.el6.x86_64.rpm
#install git
yum -y install git
#create dir and download cookbooks
mkdir "$SOLODIR"
cd "$SOLODIR"
git clone https://github.com/morkot/wp-aws-chef-solo
git clone https://github.com/morkot/cookbooks
#run chef-solo
chef-solo -c "$CFGDIR"/solo.rb -j "$CFGDIR"/node.json
Now we are ready to raise an autoconfigured instance:
ec2-run-instances ami-1624987f -t t1.micro -k {your_key_name} --user-data-file chef-solo-inst.sh
where --user-data-file chef-solo-inst.sh is an option that says to use a locally located bash script as user-data. After a few minutes, you can run the ec2-describe-instances command, copy the dns name of the raised instance and open http: // {instance_dns_name} / wp in the browser, and the WordPress settings page should open:

If the page is unavailable, then something went wrong So. What exactly can be found by looking at the log file autoconf-log. {Date}, which will lie on the instance in the / root directory.
Thus, we got a fully tuned and ready to work instance. Using chef recipes in conjunction with user-data, you can configure systems of any complexity. Moreover, recipes can be cross-platform, and with their help you can configure instances with different OS.
The most interesting thing about this approach is that we work with infrastructure as a code (Infrastructure as a Code). Therefore, you can use the same methods as in software development (for example, TDD ).
This article shows one of the simplest ways to autoconfigure, but you can go further: make images with the chef client already installed, so that the instance, when launched, is configured by the chef server depending on the role. But this is the topic for the next article.