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 installation of client applications on serviced servers, which can reduce setup time before infrastructure deployment. To work Ansible connects to serviced 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 our article we will consider the main Ansible functionality in the context of practical use on cloud servers in InfoboxCloud .
')
We hope that you already have an account on InfoboxCloud . If not yet, create it .
For Ansible, we need a control server. Create it (it is recommended to use Ubuntu 14.04 or CentOS 7). Also create at least a couple of servers with Linux, which will be configured using Ansible. Data for access to 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 several control servers from which you can send commands or sets of consecutive instructions (playbooks) to remote servers by connecting to them via SSH.
The Host inventory file contains information about the serviced servers where the commands will be executed. The Ansible configuration file can be useful for specifying the settings for your environment.
Instructions (playbooks) consist of one or more tasks, which are described using the functionality of the Ansible kernel module or third-party modules that may be required in specific situations. In itself, instruction sets are sequential sets of instructions in which conditions can be checked: if a 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 launch a playbook, this can be done through the API. The playbooks themselves are described declaratively in the YAML format. Ansible supports deployment of new cloud servers and configuration based on roles . Part of the work can be carried out in local mode on the management server, and the rest on the created server after its first boot. Work is underway on the provisioning module for InfoboxCloud .
The configuration file is described in the INI format . You can override some or all of the configuration in the playbook parameters 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 ANSIBLE_ prefix before the configuration parameter name (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 set . 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 experiments 'ansible' and go into it:
Also create a folder for storing the Ansible modules and a folder for storing the logs:
Create a file, ansible.cfg with the following contents:
For experiments, we created a couple of servers earlier, which we will configure. It is necessary to inform Ansible of their addresses and group them. To do this, create an inventory file in our ~ / ansible / inventory directory with the following contents:
ip_address of servers can be viewed in the InfoboxCloud control panel .
Please note that to use the Ansible control server with servers in the same region, you can specify local IP addresses and work on the internal network.
You need 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 simply press Enter.
Now you need to copy the public key to custom servers. This can be done using the ssh-copy-id utility from the Ansible managing server for each configured server:
You can verify the correctness by logging into a custom server with a manager via SSH. If the password is no longer asked - 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, you can, if necessary, click “Create server” on our image and get the machine ready for configuration for Ansible.
Let's now check the correctness of Ansible settings completely.
You can ping serviced servers:
or send to echo "Hello World":
Playbooks execution is one of the Ansible main tasks. Playbooks contain task lists. Each task inside Ansible uses a piece of module code. The Playbooks themselves are described in YAML format, but the modules can be written in any programming language. It is important that the format of the messages from the modules be 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 item in the list 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 list members must be equally spaced from the beginning of the line, and must begin with a space or "-". Comments begin with "#".
For example:
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 YAML file will look like this:
For variables, Ansible uses "{{var}}". If the value after the colon begins with "{", then YAML will think it is to say.
To use variables, you must enclose the brackets in quotes:
This is enough to start writing playbooks.
Playbooks can consist of a list of serviced servers, 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, represented as the Ansible task call.
As an example, let's take a look at the nginx installation process.
Create a directory where the playbooks will be stored:
Create a file setup_nginx.yml 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 setup of servers to the described configuration.
- Provisioning . Managing the deployment of new cloud servers (for example, through an API, using Docker or LXC).
- Deploy . Installing and updating your applications without downtime.
- Orchestration . Coordinating components of your infrastructure for deployment. For example, checking that the web server is disconnected from the load balancer before the software upgrade on the server.
- Monitoring and notifications .
- Logging Centralized collection of logs.
Compared to other popular IT infrastructure automation tools, Ansible does not require installation of client applications on serviced servers, which can reduce setup time before infrastructure deployment. To work Ansible connects to serviced 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 our article we will consider the main Ansible functionality in the context of practical use on cloud servers in InfoboxCloud .
')
What we need to configure
We hope that you already have an account on InfoboxCloud . If not yet, create it .
For Ansible, we need a control server. Create it (it is recommended to use Ubuntu 14.04 or CentOS 7). Also create at least a couple of servers with Linux, which will be configured using Ansible. Data for access to the servers will be sent to your email.
Connect to the management server via SSH .
Ansible installation
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 several control servers from which you can send commands or sets of consecutive instructions (playbooks) to remote servers by connecting to them via SSH.
The Host inventory file contains information about the serviced servers where the commands will be executed. The Ansible configuration file can be useful for specifying the settings for your environment.
Instructions (playbooks) consist of one or more tasks, which are described using the functionality of the Ansible kernel module or third-party modules that may be required in specific situations. In itself, instruction sets are sequential sets of instructions in which conditions can be checked: if a 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 launch a playbook, this can be done through the API. The playbooks themselves are described declaratively in the YAML format. Ansible supports deployment of new cloud servers and configuration based on roles . Part of the work can be carried out in local mode on the management server, and the rest on the created server after its first boot. Work is underway on the provisioning module for InfoboxCloud .
Ansible setting
The configuration file is described in the INI format . You can override some or all of the configuration in the playbook parameters 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 may point to a configuration file.
- ./ansible.cfg - in the current directory
- ~ / .ansible.cfg - in your home directory
- /etc/ansible/ansible.cfg - in the directory generated during the installation of ansible via the package manager.
Setting through variable environments
Most configuration parameters can be set via environment variables using the ANSIBLE_ prefix before the configuration parameter name (in capital letters).
For example:
export ANSIBLE_SUDO_USER = root
After that, the variable ANSIBLE_SUDO_USER can be used in the playbook.
Setup in ansible.cfg
Ansible configuration options set . Let's look at some of them:
- hostfile : The 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 : 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. The default is 5 processes.
For example: forks = 5 - sudo_user : The default user from which Ansible runs commands on remote servers.
For example: sudo_user = root - remote_port : Port for an SSH connection (default is 22).
For example: remote_port = 22 - host_key_checking : This parameter allows you to disable the SSH – key check on the host. By default, the check is performed.
For example: host_key_checking = False - timeout : The timeout value of the SSH connection attempt.
For example: timeout = 60 - log_path : Path to store log files. By default, Ansible does not store them at all, but by specifying this option, you can activate logging.
For example: log_path = /var/log/ansible.log
Writing 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 experiments 'ansible' and go into it:
mkdir ~/ansible cd ~/ansible Also create a folder for storing the Ansible modules and a folder for storing the logs:
mkdir ~/ansible/modules mkdir ~/ansible/logs Create a file, ansible.cfg with the following contents:
[defaults] hostfile = ~/ansible/inventory sudo_user = root log_path = ~/ansible/logs/ansible.log We specify serviced servers in host inventory
For experiments, we created a couple of servers earlier, which we will configure. It is necessary to inform Ansible of their addresses and group them. To do this, create an inventory file in our ~ / ansible / inventory directory with the following contents:
[experiments] ip__ ip__ ip_address of servers can be viewed in the InfoboxCloud control panel .
Please note that to use the Ansible control server with servers in the same region, you can specify local IP addresses and work on the internal network.
You need 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 simply press Enter.
Now you need to copy the public key to custom servers. This can be done using the ssh-copy-id utility from the Ansible managing server for each configured server:
ssh-copy-id root@ip___ You can verify the correctness by logging into a custom server with a manager via SSH. If the password is no longer asked - 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, you can, if necessary, click “Create server” on our image and get the machine ready for configuration for Ansible.
Let's now check the correctness of Ansible settings completely.
You can ping serviced servers:
ansible experiments -m ping or send to echo "Hello World":
ansible experiments -a "/bin/echo Hello, World!" Configuration Management
We work with playbooks
Playbooks execution is one of the Ansible main tasks. Playbooks contain task lists. Each task inside Ansible uses a piece of module code. The Playbooks themselves are described in YAML format, but the modules can be written in any programming language. It is important that the format of the messages from the modules be 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 item in the list 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 list members must be equally spaced from the beginning of the line, and must begin with a space or "-". Comments begin with "#".
For example:
--- #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 YAML file will 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 it is to say.
To use variables, you must enclose the brackets in quotes:
word: "{{ variable }}" This is enough to start writing playbooks.
Writing our first playbook
Playbooks can consist of a list of serviced servers, 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, represented as the Ansible task call.
As an example, let's take a look at the nginx installation process.
Create a directory where the playbooks will be stored:
mkdir ~/ansible/playbooks Create a file setup_nginx.yml 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 group on which you run the task. This field is required and every playbook must have one, with the exception of roles. If a host group is specified, Ansible first searches for it in the playbook, and then in the inventory file. You can find out which hosts will work on with the command:
ansible-playbook --list-host, – playbook (playbooks/setup_nginx.yml).ansible-playbook --list-host, – playbook (playbooks/setup_nginx.yml).
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 (task reference information for the playbook user), the module to be executed and the arguments required for the module. The "name" parameter is optional, but recommended.
Successful work!
Source: https://habr.com/ru/post/249143/
All Articles