Эксплуатация Ansible

Материал из Rosalab Wiki
Версия от 14:52, 26 августа 2021; Pechkinlav (обсуждение | вклад) (Новая страница: «Категория:Документация Asible Итак, Ansible – это система управления программным обеспечен…»)

(разн.) ← Предыдущая | Текущая версия (разн.) | Следующая → (разн.)
Это снимок страницы. Он включает старые, но не удалённые версии шаблонов и изображений.
Перейти к: навигация, поиск

Asible Итак, Ansible – это система управления программным обеспечением на удаленных серверах. Есть ряд аналогичных систем (Chief, Puppet) с другими принципами работы, требующих установки клиента и пр. В чём плюс Ansible – для работы на клиенте достаточно ssh соединения с ним. Задача Ansible – выполнить ряд операций на удаленной машине. При этом машин может быть сразу несколько. Playbook Все операции вы записываете в некий Ansible-скрипт. Действия выполняются последовательно. Логика работы похожа на обычный bash-скрипт, только на своих командах. Это позволяет отвязаться от дистрибутива, описав задачи на промежуточном языке. Такой Ansible-скрипт называется playbook (сценарий) Синтаксис Ansible Все операции, выполняемые Ansible записываются в playbook в простом формате и построены на yaml-разметке. Рассмотрим пример записи сценария: - name: "First step"

 hosts: localhost
 tasks:
 - taskA
 - taskB

Где параметр name: «First step» – имя группы задач; hosts: localhost – хосты, на которых будут выполнены задачи; параметры, перечисленные после команды tasks – перечень задач, которые необходимо выполнить. В одном playbook может быть несколько блоков с задачами, для чего необходимо добавить дополнительные параметры name, после завершения описания предыдущей группы задач. Далее рассмотрим непосредственно команды программы - tasks. Команды являются модулями Ansible. Таким образом задавая параметры task, вызывается модуль Ansible с его параметрами. Записать task можно в двух видах: кратком, и полном. Вот пример команды установки curl при помощи dnf модуля в кратком виде: - dnf: name=curl state=latest Тогда play с этим task будет выглядеть как отражено ниже, где модуль dnf устанавливает пакет curl:

- name: "First step"
  hosts: localhost
  tasks:
- dnf: name=curl state=latest

где параметры

name: - имя задачи;
hosts: - хост, на котором будет применяться playbook;
tasks: - блок задачи.

Существует возможность более полно описать команду task, присвоить ей имя (name). Совсем как в блоках задач (play). Тогда получившийся текст выглядит как подзадача основного блока задач. - name: "First step"

 hosts: localhost
 tasks:
   - name: "Add curl packege"
 dnf: name=curl state=latest

В этому случае сразу видно, что есть блок задач «First step», в нем существует 1 задача - установка пакета curl.

Запуск программы Текстовый файл, содержащий сценарии, необходимо сохранить в файл “first.yml” и запустить его, придерживаясь нижеописанной инструкции. 1. Предварительно установим сам пакет Ansible командой

dnf install –y ansible

2. Для запуска playbook, необходимо разархивировать архив и зайти в папку из архива:

ansible-playbook ./dnf_user_install.yml --ask-pass -b -K
--ask-pass ssh пароль от пользователя (администратора)
- b повышение до пользователя sudo
- K пароль sudo

Запуск playbook с помощью команды ansible-playbook при помощи написанного playbook dnf_user_install.yml. 3. После реализации данной команды получиться следующий вывод:

[WARNING]: provided hosts list is empty, only localhost is available. Note that the implicit localhost does not match 'all'
PLAY [First step] **********************************************************************************************************************************************************
TASK [Gathering Facts] *****************************************************************************************************************************************************
ok: [localhost]
TASK [Add curl packege] ****************************************************************************************************************************************************
ok: [localhost]
TASK [Add user rosa] *******************************************************************************************************************************************************
ok: [localhost]
PLAY RECAP ****************************************************************************************************************************************************************
localhost                 : ok=3    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Где блок задач PLAY, называемый First step, а также команды (TASK) по установке программы curl и добавление пользователя rosa. Все задачи завершились успешно (ok=3, failed=0) (changed=2), а именно: выполнено три действия (ok=3), завершилось с ошибкой 0 действий (filed=0) и на хосте произошло 2 изменения. Gathering Facts (Дополнительная задача) – получение информации о хосте (такой как имя хоста и пр.), вызвалась автоматически. Она необходима для использования данных о хосте в своих сценариях, это своеобразный мониторинг о системе, который собирает такую информацию имя машины, ip-адресацию и другие параметры. Можно запретить эту задачу, указав gather_facts : false

- name: "First step"
  hosts: localhost
  gather_facts: false

Файл инвентаризации Так называемый файл инвентаризации (файл hosts) – это файл, в котором хранится перечень машин, с которыми будет работать Ansible. Располагаться он может в вашей директории и иметь примерно такой вид:

[mail]
192.168.1.1
192.168.1.2
[web]
192.168.1.3

Где параметры [mail] и [web] – имена групп хостов; 192.168.1.1, 192.168.1.2, 192.168.1.3 - ip адрес второго хоста. Тут, как видно, указываются группы, в них имена хостов, можно с указанием переменных для хоста. Структура inventory-файла очень гибкая, в нем допустимо комбинировать группы, включать одну в другую, задавать переменные для групп, глобальные значения:

[all:vars]
ansible_user=pupkin
hosts: web

Где параметры [all:vars] – переменные для всех хостов; ansible_user=pupkin – пользователь, от которого будет работать ansible на удаленных машинах; hosts: web – группа хостов, на которых будут выполняться playbook. А затем вызвать наш playbook, указав параметром файл инвентаризации (предварительно этот файл нужно заполнить, так как инфраструктура у всех разная): ansible-playbook ./dnf_user_install.yml –i ./hosts С помощью данной команды запускается ansible-playbook, запускаем playbook /dnf_user_install.yml который применится на хостах из файла ./hosts где мы описывает инфенторизацию нашей сетевой инфраструктуру ip адреса до хостов. Примеры использования: Рассмотрим пример доверенной установки, удаления и централизованной настройки средств защиты данных. 1. Для установки используем playbook install.yml его содержимое выглядит так:

- name: "install rosa-removable-drive-manager 
  hosts: localhost
  tasks: 
    - name: "install rosa-removable-drive-manager
      dnf: name=rosa-removable-drive-manager state=latest 

Где параметры name – имя выполняемого таска; hosts – имя хоста, на котором будет выполняться таск; tasks - блок выполнения задания. Запускаем playbook:

ansible-playbook install.yml --ask-pass -b -K
--ask-pass ssh пароль от пользователя (администратора)
- b повышение до пользователя sudo
- K пароль sudo

2. Для удаления, используем playbook remove.yml его содержимое выглядит так:

- name: "remove rosa-removable-drive-manager" 
  hosts: localhost
  tasks:
    - name: "Remove rosa-removable-drive-manager 
      dnf: name=rosa-removable-drive-manager state=absent

Запускаем playbook:

ansible-playbook remove.yml --ask-pass -b -K
--ask-pass ssh пароль от пользователя (администратора)
- b повышение до пользователя sudo
- K пароль sudo

3. Для централизованной настройки используем playbook provision.yml его содержимое выглядит следующим образом:

- name: "insert template rosa-removable-drive-manager" 
  hosts: localhost
  tasks:
    - name: "putt template rosa-removable-drive-manager"
      template: src=00-rosa-removable-drive-manager.rules.j2 dest=/etc/polkit-1/rules.d/src=00-rosa-removable-drive-manager.rules

В данном блоке берется конфигурационный файл из папки templates(00-rosa-removable-drive-manager.rules.j2 и распространяется по пути /etc/polkit-1/rules.d/ тем самым мы осуществляем централизованную настройку приложений) 4. Запускаем playbook:

ansible-playbook provision.yml --ask-pass -b -K
--ask-pass ssh пароль от пользователя (администратора)
- b повышение до пользователя sudo
- K пароль sudo

Ansible — Роли Роли обеспечивают основу для полностью независимых или взаимозависимых наборов переменных, задач, файлов, шаблонов и модулей. В Ansible эта роль является основным механизмом разбиения playbook на несколько файлов. Это упрощает написание сложных сценариев и облегчает их повторное использование. Роли позволяет вам логически разбить playbook на компоненты многократного использования. Каждая роль в основном ограничена определенной функциональностью или желаемым результатом со всеми необходимыми шагами для обеспечения этого результата либо внутри самой роли, либо в других ролях, перечисленных как зависимости. Создание новой роли Структура каталогов для ролей необходима для создания новой роли. Ролевая структура Роли имеют структурированный дерево файловой в системе. Структура по умолчанию может быть изменена, но пока давайте придерживаться значений по умолчанию. Каждая роль представляет собой дерево каталогов само по себе. Имя роли — это имя каталога в каталоге / role. Создание каталога ролей Приведенная выше команда описывает структуру каталога роли.

$ tree role/ 
rosa_install_tcpdump/ 
├── task                  # Папка где хранятся таски и playbook    
│   └── main.yml          # Файл с playbook где описываются действия
├── files                 # Папка где хранятся файлы или скрипты
├── templates             # Папка где хранятся файлы шаблонов программ
└── vars                  # Папка где хранятся переменные
    └── main.yml          # Файл где хранятся переменные для инфраструктуры