2. Что такое Ansible?
● Ansible — система управления конфигурацией
● Применима для ОС Linux/Unix и Windows
● Бесплатная и open source, лицензия GNU GPL
● “Консольно-ориентированная” (command-line interface)
● Модульная архитектура
● Поддержка сторонних модулей (Ansible Galaxy)
● Коммерческий вариант — Ansible Tower (WebUI, Dashboard etc.)
● Разработчик — Ansible Inc./Red Hat Inc.
2
4. Ansible и Puppet — сравнение
Ansible
Императивный стиль (задачи playbooks)
Push по команде контроллера
Централизованная
Центр: машина инженера (контроллер)
Язык: YAML
В основе: SSH и Python
Puppet
Декларативный стиль (описание в manifests)
Pull периодически (агенты)
Централизованная
Центр: выделенный сервер
Язык: Puppet DSL
В основе: HTTPS и Ruby
4
5. На контроллере:
● Установка Ansible: http://docs.ansible.com/ansible/intro_installation.html
● Текстовый редактор и командная строка :)
На серверах:
● установка Ansible не требуется
● должен быть установлен python2.7 (для Ubuntu 16: apt-get install
python-minimal)
● должен быть настроен доступ по SSH с контроллера
Установка
5
6. provision.sh
#!/bin/bash
for host in 192.168.56.211 192.168.56.212; do
ssh root@$host "apt-get update && -y install ntp nginx"
scp nginx_site.conf root@$host:/etc/nginx/sites-enabled/
ssh root@$host "service nginx reload"
rsync …
end
6
7. От shell scripting к Ansible
● Начнем с создания файла inventory (список хостов):
[webservers]
web1 ansible_host=192.168.56.201
web2 ansible_host=192.168.56.202
● Выполним ad-hoc задачу:
> ansible -i inventory -u root -m shell -a "apt-get install -y ntp" webservers
● Далее: организуем задачи в playbooks
7
8. Playbooks
● Последовательности команд организуются в playbooks (пьесы)
● Для описания используется нотация YAML
● Playbook содержит не только задачи (tasks), но также может содержать:
○ hosts — шаблон серверов, к которым применяется playbooks
○ vars — переменные
○ handlers — обработчики
○ и др. директивы
● Задачи в playbook выполняются строго последовательно
8
11. playbook-advanced.yml
- hosts: all
user: root
tasks:
- name: install packages update_cache=yes cache_valid_time=86400
apt: name={{item}}
with_items: [ntp, nginx, git]
tags: packages
- copy:
src: files/nginx_site.conf
dest: /etc/nginx/sites-enabled/
notify: restart nginx
- include: deploy-site.yml
tags: deploy
handlers:
- name: restart nginx
service: name=nginx state=restarted
11
Организуем цикл по with_items
Отдельный playbook для code reuse
nginx нужно перезапустить
Обработчик сообщения
12. Шаблоны
● Используется шаблонизатор Jinja2: http://jinja.pocoo.org/
● Разрабатывался как шаблонизатор для веб-страниц, поэтому
возможностей для создания файлов конфигурации более чем достаточно
● Ansible добавляет еще фильтры — выражения типа:
{{ var | default('5') }} {{ data | to_json }} {{ str | regex_replace('^a', 'b') }}
● Преобразование шаблонов в документы происходит на контроллере
● Большинство фильтров из Jinja2 доступно в playbooks!
12
15. Переменные и факты
● Переменные: определены вами на контроллере
● Факты: определены узлами (автоматически или вручную)
● Переменные/факты можно использовать в playbooks и шаблонах
● Более 20 (!) мест определения переменных/фактов
● Неопределенная переменная — ошибка выполнения (к счастью)
● Типичные места задания: inventory, playbooks, роли, параметры CLI
15
16. Пример: Multistage
● Три окружения: production, staging и dev
● Создаем отдельный inventory для каждого окружения
○ Переменные окружения задаются в inventory
○ Сервера также перечисляются в inventory
● Остальные переменные задаем в playbook
● Все файлы, кроме файлов inventory, общие для всех окружений
Такой подход позволяет получать идентичную конфигурацию на разных
группах серверов, при этом оставляя возможность вносить необходимые 16
17. Роли
● Удобная возможность группировать сервера по назначению/функциям
● Один сервер может иметь несколько ролей и такой подход позволяет:
○ Не порождать случайных кросс-зависимостей
○ Легко "расщеплять" или комбинировать сервер при
масштабировании
● Всем серверам может быть прописана "базовая" роль, которая реализует
ваши любимые настройки
● Роли легче повторно использовать (в других проектах и т.п.)
17
18. Некоторые практики
● Пишите все playbooks так, что их можно применить много раз подряд, и
это не приведет к ошибкам/побочным эффектам (идемпотентность)
● Используйте -C (--check) и -D (--diff) для проверки вносимых
изменений в файлы без реального применения этих изменений:
> ansible-playbook -C -D playbook.yml
● Используйте фильтры по тэгам и именам для выполнения конкретных
задач на конкретных серверах:
> ansible-playbook -t packages -l web1 playbook.yml
● Старайтесь не усложнять иерархию переменных без необходимости
● Используйте систему контроля версий для хранения конфигурации
18
19. Сильные стороны Ansible
● Простая "императивная" идеология
● Низкий порог входа для автоматизации массовых действий
● Provisioning (ввод в работу) серверов
● Выкатка кода
○ особенно если ваша "экосистема" не имеет готовых инструментов
или они относительно тяжелые
○ встроенная поддержка rolling updates
● Continuous Integration
○ легко вызвать ansible в git hook
19