В преддверии старта Экспресс-курса «IaC Ansible» делимся с вами переводом материала.
Ansible — это мощный инструмент ИТ-автоматизации и, аналогично другим подобным инструментам, его освоение требует времени.
Я использовал Ansible для автоматизации развертывания и управления корпоративными приложениями и извлек ряд уроков, с которыми хотел бы поделиться, чтобы помочь другим. В конце концов, это open source — принцип.
Корпоративным программным обеспечением я занимался задолго до появления Ansible и помню дни ежеквартальных деплоев, когда вся команда дежурила, чтобы выпустить релиз. Деплой был дорогим, сложным, непоследовательным и удручающим на каждом этапе.
Для того чтобы уйти от этого и научиться быстрым, регулярным и автоматизированным деплоям, требуются как технические, так и культурные изменения. О культурных аспектах я расскажу в другом посте, а здесь я хотел бы остановиться на некоторых практиках Ansible, которые использовал.
Стандарты
Для автоматизации важны три вещи:
стандарты
стандарты и …
ах да, стандарты!
Довольно просто написать небольшой плейбук для выполнения конкретной админской задачи. Но при разработке сотни плейбуков / ролей для автоматического развертывания целого программного стека в разных окружениях все становится довольно сложным. Кроме того, ваши плейбуки и роли будут усложняться, если вы не будете переиспользовать роли и не стандартизируете их. Начать изучение Ansible вы можете с этого туториала (англ.).
С самого первого дня стандартизируйте плейбуки и роли, чтобы команда могла повторно использовать как можно больше кода.
Далекая-далекая галактика
Ansible Galaxy, централизованный репозиторий ролей Ansible от сообщества — ваш друг. Вам обязательно стоит посмотреть — не решил ли уже кто-то другой вашу проблему.
Но будьте осторожны. Содержимое Galaxy использовать можно, но его следует внимательно изучить и разобраться, прежде чем размещать в своем окружении. Вы легко и быстро можете испортить себе жизнь, используя роль, которая делает что-то неожиданное.
Инвентори
Ansible может работать с машинами, используя как собственный механизм инвентори для поиска различных систем, так и определяя группы по рабочей нагрузке или другим характеристикам. Также можно работать с динамическим инвентори.
Например, у нас было много XML-файлов, содержащих информацию о конфигурации нашего программного обеспечения. Мы создали шаблоны Jinja и перенесли конфигурацию из XML-файлов в Ansible Inventory. XML-файлы стало гораздо проще генерировать и деплоить на серверы. Кроме того, для работы с разными окружениями мы использовали специально созданный Vars Plugin, написанный на Python, загружающий только нужные данные конфигурации в инвентори.
Обработчики
Обработчики (handlers) — это задачи, которые запускаются по событию. Только по событию и только один раз для плейбука. Например, вы можете настроить обработчики для такого события, как перезапуск сервиса или приложения. Использование обработчиков в роли, управляющей определенным сервисом, может быть отличным решением для создания ясных и понятных задач в файле handlers / main.yml, запускаемых при изменении сервиса.
Когда я начинал работать с Ansible, то обработчиков в нем еще не было. Так что я могу рассказать вам, какой была жизнь до и после этого — не позволяйте этой возможности пропадать впустую!
Идемпотентность — поймите ее, живите с ней, любите ее
Идемпотентность — это образ жизни ИТ-автоматизации. Вам нужно понять ее, а затем при написании кода автоматизации жить в соответствии с ней. Так что же это такое? Процитирую глоссарий Ansible, операция "идемпотентна, если результат однократного применения операции такой же, как результат ее многократного применения".
То есть вы можете запускать свои плейбуки несколько раз, а конечный результат будет оставаться неизменным — целевые серверы будут находится в "desired state". И если ваш плейбук не заработает, то вы можете устранить проблемы и запустить плейбук еще раз. Поскольку плейбук является идемпотентным, целевые серверы должны быть в "desired state", и никаких других изменений не произойдет.
Что в имени твоём?
Пожалуйста, пожалуйста, всегда давайте имена задачам. Это кажется глупым и похожим на просьбу комментировать код, но важно давать задачам ясные имена, чтобы всем было понятно, что она делает. Следуйте простым правилам:
Не пишите в плейбуках Ansible комментарии как при разработке программного обеспечения, например, "# это комментарий". Помните, Ansible — это не язык программирования, это инструмент автоматизации.
Вместо этого для описания Play и Task используйте "Name" с понятным названием. Опишите свои намерения, но постарайтесь воздержаться от технических деталей.
Самая большая польза от свойства "Name" заключается в том, что оно отображается при запуске плейбука. Это помогает при диагностике. А комментарии не отображаются.
Мой опыт показывает, что плейбуки / роли / задачи пишутся разными людьми в компании (по крайней мере, командами Dev и Ops), и все должны понимать, что делает задача.
Именование и приоритет переменных
Будьте осторожны при именовании переменных в инвентори, плейбуках и ролях Ansible. Помните, что Ansible присваивает каждую переменную определенному хосту (Host Variables). Поэтому с осторожностью используйте общие имена, такие как "java_path: /my path". Есть вероятность, что другое приложение на том же хосте использует Java, но по другому пути. Часто на одном хосте могут размещаться несколько приложений, использующих разные версии Java, расположенные по разным путям.
Указывайте в переменных префикс, используя название вашей компании. Например, переменные приложения AppOne, созданного компанией ABC и использующее Java 1.8, могут выглядеть следующим образом:
abc_appone_java_path: "/opt/appone/java"
abc_appone_java_version: "1.8"Не копипастите
Позвольте мне пояснить. Создавайте роли, которые можно использовать повторно и не копируйте куски кода из одного плейбука в другой. Таким образом, роль меняется в одном месте и зависимости автоматически используют последнюю версию. Не нужно будет искать устаревшие директивы и вы не увидите неожиданное поведение плейбука несколько месяцев спустя.
Используйте IDE
Используйте для Ansible какую-нибудь IDE. В конце концов, это просто YAML. IDE должна упрощать вам работу. Вот некоторые функции, которые я считаю критически важными для IDE при создании ролей и плейбуков Ansible:
Подсветка синтаксиса YAML и поддержка линтеров.
Подсветка синтаксиса Python и поддержка линтеров — Ansible написан на Python, и, поверьте мне, вам иногда придется смотреть исходный код.
Интеграция с системой контроля версий.
Интеграция с JIRA — возможность управлять изменениями сразу в нескольких тикетах.
Удобные поиск и замена — часто вам нужно будет изменять, удалять или перемещать какую-то переменную сразу в нескольких файлах.
Поддержка Ruby — если вы также собираетесь работать с Vagrant.
Поддержка Groovy — если вы собираетесь работать с заданиями Jenkins.
Эти советы помогут вам быть на шаг впереди и избежать тех ошибок, которые совершал я при использовании Ansible для развертывания и автоматизации корпоративного программного обеспечения. У вас будут свои новые и интересные ошибки! Для дополнительной информации о лучших практиках работы с Ansible смотрите раздел лучших в практик документации Ansible и скачайте чеклист по автоматизации, а также следите за блогами Red Hat и Ansible.
Узнать подробнее про Экспресс-курс «IaC Ansible».
