Понимая Ansible

Понять и применить ansible на практике оказывается не такой уж тривиальной задачей, в интернете пистрит множество статей на тему того какие ухищрения можно применять дабы сделать это и не делать то. Именно этой проблеме и будет посвящеа данная статья. И прежде чем начать немного понимания про утилиты:

ansible - запускает произвольные команды модули

ansible-playbook - выполняет конретный сценарий

Поехали, согласно Best Practice:

inventory - файл с группами хостов (это сделано потому, что сервера обычно зеркалируются). Поэтому, любую из группу далее можно рассматривать как один сервер.

Пример файла inventory.ini

[servers_group]
server1
server2

и советую список stage-серверов, держать в отдельном inventory-файле. Благодаря этому Вам не придется копировать файл playbooks-а, чтобы исправить значение в поле hosts.

playbooks - файл который говорит о том, какие приложения (roles) нужно расскатать на серверах (hosts).

Пример файла playbooks.yml

---
- hosts: all
  pre_tasks:
    - name: upgrade packages
      apt: upgrade=yes update_cache=yes cache_valid_time=300

- hosts: servers_group
  roles:
    - { role: starsite.ru,
        tags: [
          "starsite.ru"
        ]
      }
    - { role: yapro.ru,
        tags: [
          "yapro.ru"
        ]
      }

* обратите внимание, в плейбуке указано 2 процесса конфигурации.

Значит, выкатить все приложения на все сервера, можно командой:

ansible-playbook -i inventory.ini playbooks.yml

Однако, мне не всегда нужно обновлять сервера перед выкаткой, в таких случаях используют аргумент --limit

ansible-playbook -i inventory.ini playbooks.yml --limit=servers_group

Но, бывают случаи, когда на сервер нужно выкатить/обновить только одно приложение и в таких случаях используют теги:

ansible-playbook -i inventory.ini playbooks.yml --limit=servers_group --tags "yapro.ru"

Но, что делать если нужно обновить приложение, в таких ситуациях в голове возникает мысль, что нужно используют дополнительный тег:

ansible-playbook -i inventory.ini playbooks.yml --limit=servers_group --tags "yapro.ru,update"

Однако, оказывается теги работают не на сужение поиска, а на расширение поиска необходимых к выполнению команд, и выходы из этой ситуации:

1. под каждое приложение создается отдельный playbooks.yml-файл, кстати это кажется является best practices
2. использовать опцию --skip-tags=some_tag
3. вместо тегов, использовать переменные

Мой совет - использовать переменные.

Как работают переменные

• Переменные из глобального файла переопределяют хост-переменные, групповые переменные и переменные в инвентарном файле.
• Групповые переменные переопределяют переменные из инвентарного файла,
• хост-переменные переопределяют групповые переменные.

Как работают роли

Зависимости ролей

Зависимости ролей позволяют автоматически исполнить зависимые роли при запуске конкретных ролей, у которых зависимости есть. Зависимости хранятся в roles/x/meta/main.yml. Вместе с зависимыми ролями могут быть переданы параметры. Путь к ролям может быть указан как в сокращенном виде, так и в полном. Также может быть использован репозиторий системы управления версиями.

dependencies:
- { role: common, some_parameter: 3 }
- { role: '/path/to/common/roles/foo', x: 1 }
- { role: 'git+http://git.example.com/repos/role-foo,v1.1,foo' }

Если в зависимостях указана одна и та же роль несколько раз — она запустится только однажды. Если нужно несколько раз, можно в файле зависимостей попросить об этом явно.

И не забывайте, что для каждой роли применяются следующие правила:

• если существует roles/.../tasks/main.yml, то задачи из этого файла будут добавлены в набор инструкций;
• если существует roles/.../handlers/main.yml, то обработчики из этого файла будут добавлены в набор инструкций;
• если существует roles/.../vars/main.yml, то переменные из этого файла будут добавлены в набор инструкций;
• если существует roles/.../meta/main.yml, то любые роли-зависимости будут добавлены в список ролей;
• задача копирования может ссылаться на файл в roles/.../files без указания абсолютного или относительного пути;
• скриптовая задача может ссылаться на скрипт в roles/.../files без указания абсолютного или относительного пути;
• задача шаблонизации может ссылаться на roles/.../templates без указания абсолютного или относительного пути;
• импортируемые задачи могут ссылаться на файлы в roles/.../tasks без указания абсолютного или относительного пути.

Порядок чтения конфигов ansible'ом:

1. Переменная ANSIBLE_CONFIG
2. ansible.cfg в текущей директории
3. .ansible.cfg в домашней директории
4. /etc/ansible/ansible.cfg

Приоритет переменных

Чаще всего, переменная с определенным именем только одна. Но иногда может понадобиться создать переменную в разных местах, и тогда нужно понимать, в каком порядке Ansible перезаписывает переменные.

Приоритет переменных (последние значения переписывают предыдущие):

• Значения переменных в ролях (задачи в ролях будут видеть собственные значения. Задачи, которые определены вне роли, будут видеть последние значения переменных роли)
• переменные в инвентарном файле
• переменные для группы хостов в инвентарном файле
• переменные для хостов в инвентарном файле
• переменные в каталоге group_vars
• переменные в каталоге host_vars
• факты хоста
• переменные сценария (play)
• переменные сценария, которые запрашиваются через vars_prompt
• переменные, которые передаются в сценарий через vars_files
• переменные, полученные через параметр register
• set_facts
• переменные из роли и помещенные через include
• переменные блока (переписывают другие значения только для блока)
• переменные задачи (task) (переписывают другие значения только для задачи)
• переменные, которые передаются при вызове playbook через параметр --extra-vars (всегда наиболее приоритетные)

Альтернативные best practices: 1

---