Ansible. Roles

Описание

Ansible роли для установки/настройки сервисов

Общая предварительная настройка

Корневая директория проекта

mkdir ~/ansible

Файл инвентаризации в формате YAML

mkdir ~/ansible/inventory

nano ~/ansible/inventory/servers_test

servers_test:
  vars:
   ansible_python_interpreter: /usr/bin/python3
   ansible_connection: ssh
   ansible_ssh_port: 22
   ansible_user: root
   ansible_ssh_pass: PassWord
  hosts:
   server01:
     ansible_ssh_host: 192.168.199.189
     #ansible_user: root
     #ansible_ssh_pass: PassWord

Проверка списка хостов

ansible all --list-hosts -i ./inventory/servers_test.yml

   ...
     hosts (1):
       server01
   ...

Проверка доступности хостов по SSH

ansible -m ping servers_test -i ./inventory/servers_test.yml

  ...
  server01 | SUCCESS => {
      "changed": false,
      "ping": "pong"
  }
  ...

Директория для ролей

mkdir ~/ansible/roles

Каждую роль мы создаем с помощью команды ansible-galaxy. Синтаксис следующий:

ansible-galaxy init <Имя роли>

После ввода команды в текущем каталоге (в нашем примере, /etc/ansible/roles) будет создана папка с названием роли, а в ней следующая структура каталогов:

defaults — переменные по умолчанию. У них самый низкий приоритет и их могут легко переопределить переменные в каталоге vars (ниже по списку).

files — для файлов, которые могут быть скопированы на настраиваемый сервер.

handlers — обработчики, которые могут запускаться при определенных обстоятельствах. Например, перезапуск сервиса в случае обновления конфигурационного файла.

meta — добавление метаданных, например: автор, описание, среда и так далее.

tasks — папка с описанием выполняемых задач.

templates — файлы с шаблонами. Мы можем использовать переменные в данных шаблонах — тогда при копировании файлов, они будут заменяться значениями.

tests — скрипты для выполнения тестов — ansible покажет результаты выполнения команд, но не применит их.

vars — файлы с переменными. Имеют высокий приоритет.

После будем приступать к настройке роли, созданию и запуску плейбука.

Пример. Установка BIND с помощи роли    

Инициализируем новую роль

ansible-galaxy init Bind

nano ~/ansible/roles/Bind/tasks/main.yml

---
- name: Include vars for os family
  include_vars:
   file: "{{ ansible_os_family }}.yml"
- name: Install Bind on RedHat Family
  yum:
   name: bind
   state: present
  when:
   ansible_os_family == "RedHat"
  notify:
   - bind systemd
- name: Install Bind on Debian Family
  apt:
   name: "{{ item }}"
   state: present
  loop:
  - bind9
  - dnsutils
  when:
   ansible_os_family == "Debian"
  notify:
   - bind systemd

В зависимости от типа операционной системы мы подгрузим разные переменные (так как в разных системах имя для bind разное), после чего устанавливаем bind с помощью yum (для систем на базе Red Hat) или apt (Debian). Обратите внимание, что для систем Debian мы выполняем установку двух пакетов, для перечисления которых используем цикл. nano ~/ansible/roles/Bind/vars/Debian.yml

---
service_name : bind9

nano ~/ansible/roles/Bind/vars/RedHat.yml

---
service_name : named

После установки bind необходимо разрешить автозапуск сервиса и стартовать его. Имя сервиса подставляется из переменной и зависит от типа операционной системы Linux. nano ~/ansible/roles/Bind/handlers/main.yml

---
- name: bind systemd
  systemd:
   name: "{{ service_name }}"
   enabled: yes
   state: started

Создаем файл для плейбука установки Bind

* в данном примере мы запускаем выполнение роли Bind на серверы из группы test_servers.

nano ~/ansible/start_role_Bind.yml

---
- hosts: servers_test
  user: root
  become: true
  become_method: su
  become_user: root
  roles:
   - Bind

Запускаем плейбук установки Binds

ansible-playbook -v ~/ansible/start_role_Bind.yml -i ~/ansible/inventory/servers_test.yml

Проверяем

systemctl status named

    ...
    ● named.service - Berkeley Internet Name Domain (DNS)
    Loaded: loaded (/usr/lib/systemd/system/named.service; enabled; vendor preset: disabled)
    Active: active (running) since Sat 2023-03-18 12:33:08 MSK; 8s ago
    ...