Ansible on a great Moscow DevOps CM battle

Опыт использования Ansible
для управления
конфигурацией
Место для смешного подзаголовка
Александр Чистяков,
главный инженер Git in Sky,
2014

Кто я?
§ Меня зовут Саша
§ Я главный инженер в компании Git in Sky
§ Ночью — разработчик ПО
§ Днем — инженер отдела эксплуатации
§ Или наоборот
Опыт использования Ansible для управления конфигурацией. 2014

Кто вы?
§ С вами все ясно

Доклад о том, как Ansible помогает мне
§ Объективное сравнение невозможно
§ Поэтому сравнения не будет вообще
§ Я расскажу о своих use cases
§ Начну с того, что расскажу о себе
§ Такой вот я эгоист

Феерическая расстановка точек над всеми
§ Набор навыков: “Разработчик”
§ Набор навыков: “Системный администратор”
§ Набор навыков: “Автоматизатор”
§ Все три абилки смешать нельзя, будет взрыв
§ “Ой, у меня засорилась труба!”
§ ^ Кого из трех обычно вызывают? (никого)

Пара слов обо мне
§ Я не автоматизатор
§ Скучно, нету драйва и челленджа
§ Не пытайтесь повторить дома =>
§ (если что — я на мотоцикле не езжу,
не люблю экстрим)
§ Меня вызывают! (это про прошлый слайд)

Как устроен Ansible
§ Это программа на языке Python
§ Она умеет применять playbooks к хостам
§ На хостах не нужны никакие агенты
§ Все, что нужно на хосте — Python
§ Коммуникация между управляющей
машиной и хостом идет по SSH

Мой типичный use case
§ Хочу на всех машинах пользователя chistyakov
§ Хочу, чтобы у него shell был zsh
§ Хочу oh-my-zsh с моей темой
§ ^ Промпт синенького цвета ОБЯЗАТЕЛЬНО!
§ Хочу UID 0 у chistyakov
§ atop с интервалом 30 сек, tmux, другие
приятные мелочи

Доп. условия
§ Кастомеров много, а я одна
§ ^ отлично, playbook храним у меня
§ На машинах везде Ubuntu 12.04/14.04
§ ^ отлично, сценарий будет один и тот же
§ Цели ясны, задачи определены

Инвентаризация
§ Inventory file — файл в формате INI, группы:хосты
§ Штатно - /etc/ansible/hosts, может быть где угодно

Необходимые приготовления на хостах
§ Завести везде пользователя (пусть он сразу будет chistyakov)
§ Добавить его в /etc/sudoers, разрешить sudo без пароля
§ Прописать ему в ~/.ssh/authorized_keys мой ключ
§ ^ Приготовления логичны, должен же я туда как-то попасть?

Анатомия playbook
§ Это YAML-файл, определяющий что и где запускать, от кого
запускать и в каком порядке

Анатомия задачи
§ У задачи есть имя (лучше делать его уникальным), название
модуля, который будет выполняться, параметры этого
модуля (у каждого — свои) и атрибуты самой задачи
§ После исполнения задача может нотифицировать хэндлеры,
если они указаны

Анатомия хэндлера
§ У хэндлера есть имя (оно точно должно быть уникальным), а
в остальном хэндлер это просто обычная задача,
объявленная в секции handlers
§ Не нотифицировали — не будет вызван

Порядок применения хэндлеров
§ Обычно хэндлеры запускаются в самом конце, после
выполнения всех задач
§ Бывает необходимым запустить уже нотифицированные
хэндлеры до какой-то задачи, иначе она не пройдет

Условное выполнение
§ Некоторые задачи нужно сделать только один раз
(Например — перестать писать на PHP)
§ Регистрируем результат выполнения задачи в переменной, и
в следующей задаче проверяем ее значение

Что не попало в этот use case?
§ Можно использовать переменные и связывать их с
конкретными хостами
§ Это делается через файлы вида host_vars/hostname, где
hostname — FQDN хоста
§ Выглядит так:

Что было хорошо?
§ Нет необходимости разворачивать и поддерживать сервер
§ Нет необходимости разворачивать на хостах клиент
§ И, кстати, клиент потребляет ровно 0 мегабайт RSS
§ Модуль service умеет обращаться с SMF-сервисами (это в
Solaris)
§ Местный DSL очень немногословен

Что еще было хорошо?
§ SmartOS — достаточно капризная система
§ Это не просто клон Solaris, а клон Solaris, работающий с USB-
устройства
§ Поэтому некоторые конфиги при рестартах он просто теряет (это
ожидаемое поведение)
§ Другие коллеги используют bash-скрипты, я использую Ansible,
запускаемый при старте хоста
“Взять файлы в git, натравить на них Ansible”

Это не все, не расходитесь!
§ Поменять UID у того же пользователя, под которым
открыта сессия - это не совсем просто
§ Особенно, если вы хотите потом залогинится еще раз
§ usermod так не умеет
§ Зато так умеет Augeas, для которого есть модуль для
Ansible! (Всего две CM системы из известных мне
знают про Augeas)

Что вызывало вопросы?
§ А достаточно ли быстр SSH для массового удаленного
выполнения команд?
§ Есть еще один файл — ansible.cfg и параметр в нем
(по умолчанию выключен, надо сначала убрать requiretty в
/etc/sudoers, иначе сломаете sudo):

Снимем показания счетчика
§ Без pipelining
§ С pipelining

Что было ужасно?
§ При выполнении playbook на одной из машин со SmartOS его
исполнение намертво зависло
§ Проблема в core library — модуль service разрешает и
запускает SMF-сервисы рекурсивно, что при определенном
стечении обстоятельств приводит к попыткам запустить на
выполнение в бесконечном цикле конфигурационный
файл

Что ужасно до сих пор?
§ Фреймворк юнит-тестирования плейбуков отсутствует
§ В документации вообще нет ни слова про юнит-тесты
§ Привычка присваивать ролям номера версий отсутствует
§ Да, роли — я о них не рассказал, так как не пользуюсь, но они
есть
§ “Роль” это просто переиспользуемый кусок плейбука
(ну почти)

Выводы:
§ Некоторые еще и лимонад добавляют
§ ^ Ничего не имею против
§ Больше систем, хороших и разных!
§ Ключевое слово: “хороших”, а не “разных”
§ ^ Не поваляешь — не поешь

С вами был Александр Чистяков,
главный инженер Git in Sky
alex@gitinsky.com
http://gitinsky.com
http://meetup.com/DevOps-40
Пожалуйста, ваши вопросы.
Спасибо за внимание!
http://devconf.ru/offers/ - ПРОГОЛОСУЙТЕ, ПОЖАЛУЙСТА,
ЗА МОИ ЗАЯВКИ!

Ansible on a great Moscow DevOps CM battle

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Ansible on a great Moscow DevOps CM battle

Similar to Ansible on a great Moscow DevOps CM battle (20)

More from Alex Chistyakov

More from Alex Chistyakov (20)

Ansible on a great Moscow DevOps CM battle