January 29, 2015 at 01:34We automate and speed up the process of setting up cloud servers with Ansible. Part 1: Introduction
Ansible is a popular tool for automating the configuration and deployment of IT infrastructure.
The main tasks that Ansible solves:
Compared to other popular IT infrastructure automation tools, Ansible does not require client applications to be installed on serviced servers, which can reduce setup time before deploying the infrastructure. To work, Ansible connects to served servers via SSH.
The importance of such tools only increases in the cloud with the advent of the ability to quickly create the necessary servers, deploy the necessary software, use and delete when the need has disappeared, paying only for the resources used. In this article, we will look at the basic Ansible functionality in the context of practical use on cloud servers in InfoboxCloud .
We hope you already have an account with InfoboxCloud . If not yet, create one .
For Ansible to work, we need a management server. Create it (it is recommended to use Ubuntu 14.04 or CentOS 7). Also create at least a couple of Linux servers that will be configured using Ansible. Data to access the servers will be sent to your email.
Connect to the management server via SSH .
To install, on the management server, enter:
To install, on the management server, enter:
The main idea of Ansible is the presence of one or more control servers, from which you can send commands or sets of sequential instructions (playbooks) to remote servers, connecting to them via SSH.
The Host inventory file contains information about the servers served, where the commands will be executed. Ansible configuration file can be useful for specifying settings for your environment.
Instruction sets (playbooks)consist of one or more tasks that are described using the functionality of the Ansible kernel module or third-party modules that may be required in specific situations. By themselves, instruction sets are sequential sets of instructions that can contain condition checks: if the condition is not met, certain instructions can be skipped.
You can also use the Ansible API to run scripts. If the wrapper script may need to run the playbook, this can be done through the API. The playbooks themselves are described declaratively in YAML format . Ansible supports scenarios for deploying new cloud servers and configuring them based on roles. Part of the work can be done in local mode on the management server, and the rest on the created server after its first boot. Work is underway on a provisioning module for InfoboxCloud .
The configuration file is described in INI format . You can override part or all of the configuration in the playbook options or environment variables.
When executing commands, Ansible checks for the presence of a configuration file in the following locations:
Most configuration parameters can be set via environment variables using the prefix ANSIBLE_ before the name of the configuration parameter (in capital letters).
For example:
export ANSIBLE_SUDO_USER = root
After that, the variable ANSIBLE_SUDO_USER can be used in the playbook.
Ansible configuration options are numerous . Let's look at some of them:
Let's create our first Ansible configuration file in InfoboxCloud. Connect via SSH to the created management server with Ansible installed. Create a directory for our 'ansible' experiments and navigate to it:
Also create a folder for storing Ansible modules and a folder for storing logs:
Create ansible.cfg file with the following contents:
For experiments, we previously created a couple of servers, which we will configure. You need to tell Ansible their addresses and group them. To do this, create an inventory file in our ~ / ansible / inventory directory with the following contents:
Server ip_addresses can be viewed in the InfoboxCloud control panel .
Please note that to use the Ansible management server with servers in the same region, you can specify local IP addresses and work on the internal network.
It is necessary to generate a key on the management server that will be used to access custom servers.
This is done using the command:
For all questions you can just press Enter.
Now you need to copy the public key to the custom servers. This can be done using the ssh-copy-id utility from the Ansible management server for each custom server:
You can verify the correctness by logging into the custom server from the administrator via SSH. If the password is no longer requested - everything is in order.
In InfoboxCloud, you can create new servers with the public key already specified. To do this, create a clean server. Copy the public SSH key to it, as shown above. Next, create an OS image:
Now, in the “Server Images” section of the control panel, if necessary, click “Create Server” on our image and get a machine ready for configuration for Ansible.
Let's now verify that Ansible is fully configured.
You can ping the served servers:
or send to echo "Hello World":
Running Playbooks is one of Ansible’s core tasks. Playbooks contain task lists. Each task inside Ansible uses a piece of code module. Playbooks themselves are described in YAML format, but modules can be written in any programming language. It is important that the message format from the modules is in JSON.
Playbook is written in YAML. Let's look at the basic rules for writing YAML files.
For Ansible, almost every YAML file starts with a list. Each list item is a list of key-value pairs, often called a dictionary.
All YAML files must begin with "---". This is part of the YAML format and marks the beginning of the document.
All members of the list must be indented from the beginning of the line, and must begin with a space or "-". Comments begin with "#".
For instance:
The dictionary is presented in the form of "key:" (colon and space) "value":
If necessary, dictionaries can be presented in abbreviated form:
You can specify a logical value (true / false) like this:
Our entire example of a YAML file would look like this:
For variables, Ansible uses "{{var}}". If the value after the colon begins with "{", then YAML will think what to say.
To use variables, you must enclose the brackets in quotation marks:
This is enough to start writing playbooks.
Playbooks can consist of a list of servers served, user variables, tasks, handlers (handlers), etc. Most configuration settings can be overridden in the playbook. Each playbook consists of one or more actions (games) in the list.
The goal of the game is to associate a group of hosts with predefined roles, presented as a challenge to Ansible tasks.
As an example, let's look at the nginx installation process.
Create a directory where playbooks will be stored:
Create the setup_nginx.yml file in the playbooks directory with the following contents:
Let's look at the contents:
The main tasks that Ansible solves:
- Configuration management . The fastest and correct server configuration to the described configuration.
- Providence . Managing the deployment of new cloud servers (for example, through the API, using Docker or LXC).
- Deployment . Installing and updating your applications without downtime in the best way.
- Orchestration . Coordinate your infrastructure components for deployment. For example, checking that the web server is disconnected from the load balancer, before upgrading the software on the server.
- Monitoring and notifications .
- Logging . Centralized log collection.
Compared to other popular IT infrastructure automation tools, Ansible does not require client applications to be installed on serviced servers, which can reduce setup time before deploying the infrastructure. To work, Ansible connects to served servers via SSH.
The importance of such tools only increases in the cloud with the advent of the ability to quickly create the necessary servers, deploy the necessary software, use and delete when the need has disappeared, paying only for the resources used. In this article, we will look at the basic Ansible functionality in the context of practical use on cloud servers in InfoboxCloud .
What do we need to configure
We hope you already have an account with InfoboxCloud . If not yet, create one .
For Ansible to work, we need a management server. Create it (it is recommended to use Ubuntu 14.04 or CentOS 7). Also create at least a couple of Linux servers that will be configured using Ansible. Data to access the servers will be sent to your email.
Connect to the management server via SSH .
Install Ansible
Ubuntu 14.04 LTS
To install, on the management server, enter:
apt-key update && apt-get update && apt-get -y upgrade && apt-get -y install python-software-properties && apt-get -y install software-properties-common && apt-add-repository -y ppa:rquillo/ansible && apt-get update && apt-get -y install ansible
CentOS 7
To install, on the management server, enter:
yum -y update && yum -y install epel-release && yum -y install ansible
How Ansible Works
The main idea of Ansible is the presence of one or more control servers, from which you can send commands or sets of sequential instructions (playbooks) to remote servers, connecting to them via SSH.
The Host inventory file contains information about the servers served, where the commands will be executed. Ansible configuration file can be useful for specifying settings for your environment.
Instruction sets (playbooks)consist of one or more tasks that are described using the functionality of the Ansible kernel module or third-party modules that may be required in specific situations. By themselves, instruction sets are sequential sets of instructions that can contain condition checks: if the condition is not met, certain instructions can be skipped.
You can also use the Ansible API to run scripts. If the wrapper script may need to run the playbook, this can be done through the API. The playbooks themselves are described declaratively in YAML format . Ansible supports scenarios for deploying new cloud servers and configuring them based on roles. Part of the work can be done in local mode on the management server, and the rest on the created server after its first boot. Work is underway on a provisioning module for InfoboxCloud .
Ansible Setup
The configuration file is described in INI format . You can override part or all of the configuration in the playbook options or environment variables.
When executing commands, Ansible checks for the presence of a configuration file in the following locations:
- The environment variable ANSIBLE_CONFIG is checked, which can point to a configuration file.
- ./ansible.cfg - in the current directory
- ~ / .ansible.cfg - in the home directory
- /etc/ansible/ansible.cfg - in the directory generated during the installation of ansible through the package manager.
Setting through environment variables
Most configuration parameters can be set via environment variables using the prefix ANSIBLE_ before the name of the configuration parameter (in capital letters).
For example:
export ANSIBLE_SUDO_USER = root
After that, the variable ANSIBLE_SUDO_USER can be used in the playbook.
Setting in ansible.cfg
Ansible configuration options are numerous . Let's look at some of them:
- hostfile : This parameter points to the path to the inventory file , which contains a list of host addresses to which Ansible can connect.
For example: hostfile = / etc / ansible / hosts - library : The path to the directory where the Ansible modules are stored. For example: library = / usr / share / ansible
- forks : The number of processes that Ansible can spawn. By default, 5 processes are installed.
For example: forks = 5 - sudo_user : The default user from whom Ansible runs commands on remote servers.
For example: sudo_user = root - remote_port : Port for SSH connection (default is 22).
For example: remote_port = 22 - host_key_checking : This parameter allows you to disable the verification of the SSH key on the host. By default, verification is performed.
For example: host_key_checking = False - timeout : The timeout value of an attempt to connect via SSH.
For example: timeout = 60 - log_path : The path to store the log files. By default, Ansible does not store them at all, but by specifying this parameter you can activate logging.
For example: log_path = /var/log/ansible.log
We write the first Ansible configuration file
Let's create our first Ansible configuration file in InfoboxCloud. Connect via SSH to the created management server with Ansible installed. Create a directory for our 'ansible' experiments and navigate to it:
mkdir ~/ansible
cd ~/ansible
Also create a folder for storing Ansible modules and a folder for storing logs:
mkdir ~/ansible/modules
mkdir ~/ansible/logs
Create ansible.cfg file with the following contents:
[defaults]
hostfile = ~/ansible/inventory
sudo_user = root
log_path = ~/ansible/logs/ansible.log
We specify the served servers in host inventory
For experiments, we previously created a couple of servers, which we will configure. You need to tell Ansible their addresses and group them. To do this, create an inventory file in our ~ / ansible / inventory directory with the following contents:
[experiments]
ip_первой_машины
ip_второй_машины
Server ip_addresses can be viewed in the InfoboxCloud control panel .
Please note that to use the Ansible management server with servers in the same region, you can specify local IP addresses and work on the internal network.
It is necessary to generate a key on the management server that will be used to access custom servers.
This is done using the command:
ssh-keygen
For all questions you can just press Enter.
Now you need to copy the public key to the custom servers. This can be done using the ssh-copy-id utility from the Ansible management server for each custom server:
ssh-copy-id root@ip_адрес_настраиваемого_сервера
You can verify the correctness by logging into the custom server from the administrator via SSH. If the password is no longer requested - everything is in order.
In InfoboxCloud, you can create new servers with the public key already specified. To do this, create a clean server. Copy the public SSH key to it, as shown above. Next, create an OS image:
Now, in the “Server Images” section of the control panel, if necessary, click “Create Server” on our image and get a machine ready for configuration for Ansible.
Let's now verify that Ansible is fully configured.
You can ping the served servers:
ansible experiments -m ping
or send to echo "Hello World":
ansible experiments -a "/bin/echo Hello, World!"
Configuration management
Working with playbooks
Running Playbooks is one of Ansible’s core tasks. Playbooks contain task lists. Each task inside Ansible uses a piece of code module. Playbooks themselves are described in YAML format, but modules can be written in any programming language. It is important that the message format from the modules is in JSON.
Yaml
Playbook is written in YAML. Let's look at the basic rules for writing YAML files.
For Ansible, almost every YAML file starts with a list. Each list item is a list of key-value pairs, often called a dictionary.
All YAML files must begin with "---". This is part of the YAML format and marks the beginning of the document.
All members of the list must be indented from the beginning of the line, and must begin with a space or "-". Comments begin with "#".
For instance:
---
#Message
- Hosting
– Cloud
The dictionary is presented in the form of "key:" (colon and space) "value":
---
#Message
site: habr
blog: infobox
If necessary, dictionaries can be presented in abbreviated form:
---
#Comment
{site: habr, blog: infobox}
You can specify a logical value (true / false) like this:
---
need_access: no
use_service: yes
file_conf: TRUE
read_value: True
kill_process: false
Our entire example of a YAML file would look like this:
---
#About blog
site: habr
blog: infobox
must_read: True
themes:
- hosting
- cloud
- it
- geeks
brands:
- infobox
- infoboxcloud
For variables, Ansible uses "{{var}}". If the value after the colon begins with "{", then YAML will think what to say.
To use variables, you must enclose the brackets in quotation marks:
word: "{{ variable }}"
This is enough to start writing playbooks.
Writing our first playbook
Playbooks can consist of a list of servers served, user variables, tasks, handlers (handlers), etc. Most configuration settings can be overridden in the playbook. Each playbook consists of one or more actions (games) in the list.
The goal of the game is to associate a group of hosts with predefined roles, presented as a challenge to Ansible tasks.
As an example, let's look at the nginx installation process.
Create a directory where playbooks will be stored:
mkdir ~/ansible/playbooks
Create the setup_nginx.yml file in the playbooks directory with the following contents:
---
- hosts: experiments
tasks:
- name: Install nginx package
apt: name=nginx update_cache=yes
sudo: yes
- name: Starting nginx service
service: name=nginx state=started
sudo: yes
Let's look at the contents:
- hosts : The list of hosts or the group on which you run the task. This field is required and every playbook must have it, with the exception of roles. If a host group is specified, Ansible first looks for it in the playbook, and then in the inventory file. You can find out on which hosts the work will take place using the command: tasks : Tasks. All playbooks contain tasks. A task is a list of actions that you want to perform. The task field contains the name of the task (reference information about the task for the playbook user), the module to be executed, and the arguments required for the module. The "name" parameter is optional, but recommended.
ansible-playbook --list-host, где – путь к вашему playbook (playbooks/setup_nginx.yml).
Successful work!