SlideShare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.
SlideShare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.
Successfully reported this slideshow.
Activate your 14 day free trial to unlock unlimited reading.
1.
Применяем Ansible
Александр Светкин
alex.svetkin@gmail.com
Revision 2017-04-27
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
20.
Материалы по теме
http://docs.ansible.com/ansible/
Отличная документация, написанная с большой любовью к продукту
https://galaxy.ansible.com/
Галактика модулей
https://github.com/whisk/ansible-tutorial
Материалы этой презентации
20