Понимая 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

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

Оцени публикацию:
  • 0,0
Оценили человек: 0

Похожие статьи:


Предложения и пожелания:
Ваше имя:
Ваш E-mail:
Введите изображенные цифры:
Captcha
Главная
X

youtube.com/watch?v=7hFivbgIEqk

При полном или частичном использовании материалов данного сайта, ссылка на сайт "yapro.ru" обязательна как на источник информации.
Автоматический импорт материалов и информации с сайта запрещен.
Copyrights © 2007 - 2017 YaPro.Ru

Главная » Веб-мастеру » Unix »