Существует множество инструментов DevOps. Выбрать человека для работы не всегда просто. Используя его эффективно с самого начала, тем более.
Возможно, вы исследуете Ansible в связи с переходом на новую платформу, и вам необходимо управлять всеми ресурсами. Или у вас есть куча самодельных скриптов для управления вашей инфраструктурой, но поддерживать их становится мучительно. Первые шаги с новым инструментом также могут быть ошеломляющими, и все возможности могут показаться ошеломляющими.
Этот пост и следующий стремятся ответить на вопросы: «Когда я должен выбрать Ansible?» и «Как эффективно использовать Ansible?». Возможно также: «Почему Норвегия фальшивая?».
Contents
Что такое Анзибл?
Ansible — это инструмент автоматизации, используемый для управления конфигурацией и оркестровки инфраструктуры, систем и приложений.
Он начал свою жизнь как проект одного человека. Затем была расширена до компании и теперь спонсируется RedHat. Поддерживаемый сообществом открытого исходного кода, он является зрелым и широко используется.
Ansible, как и его известные товарищи: Chef , Puppet и SaltStack , используется для описания желаемого состояния системы в виде кода, что в данном случае означает YAML с вкраплениями шаблонов Jinja2 сверху. Все перечисленные инструменты стремятся к идемпотентности, что вкратце означает, что они вносят изменения только тогда, когда это необходимо. Есть некоторая разница в том, достигается ли это декларативно или императивно, но результат один и тот же.
Он имеет безагентную архитектуру, поэтому начать работу с ним несложно. Никаких зависимостей, кроме Python, для обработки управляемых хостов. Напишите сценарий в YAML, и готово. Направление толкать , а не тянуть . По умолчанию он подключается к целевым хостам с помощью SSH или WinRM в случае ящиков Windows. Если вы привыкли писать это install.shили install.ps1, вы почувствуете себя как дома, изменив это на install.yamlи получив все преимущества платформы автоматизации Ansible.
Ansible также можно использовать для подключения к различным API-интерфейсам для подготовки облачных серверов или для настройки кластеров Kubernetes. Таким образом, его можно использовать в качестве дополнительного инструмента или замены Terraform , и ничто не мешает вам создавать манифесты Kubernetes YAML, наполненные шаблонами Jinja2, и развертывать их с помощью Ansible , а не Helm .
Но поскольку ландшафт инструментов с открытым исходным кодом огромен, возникает вопрос: должны ли вы?
В чем он хорош?
Как было сказано ранее, начать работу с ним несложно. Распространяемый как единый пакет Python, Ansible поставляется со всем, кроме кухонной раковины .
До версии 2.10 , которая в настоящее время находится в разработке, это особенно верно, поскольку в ядре Ansible есть такие модули, как package и win_service , которые управляют обещанными ресурсами с их именами. Но есть и более специфические модули . Идите вперед и запускайте планы Terraform с помощью Ansible. Все это с помощью сингла pip install ansible. После выхода версии 2.10 пользовательский интерфейс может не сильно измениться, но в будущем модули будут жить вне ядра в коллекциях и ими можно будет управлять отдельно.
Ansible также широко используется для управления сетевым оборудованием. От маршрутизаторов до коммутаторов, безагентная архитектура делает Ansible хорошим выбором для автоматизации довольно утомительных задач по назначению VLAN в оборудовании Cisco или интерфейсах Juniper Junos. В этих случаях подключение к устройствам отличается от SSH по умолчанию. Благодаря архитектуре плагинов такие протоколы, как NETCONF, можно использовать для управления всеми вещами.
Написанный на Python, Ansible легко расширяется. Так что если в списке выше нет нужного вам модуля, вы можете написать какой-нибудь свой или расширить включенные фильтры Jinja2 с помощью плагина . Чаще всего достаточно готовых модулей и желаемое состояние системы достигается комбинацией задач.
Ansible также удобен для глаз. Задачи для запуска написаны на YAML, который де-факто становится языком конфигурации многих других современных инструментов. Он приносит с собой некоторые подводные камни, но в основном это список задач…
- hosts: localhost # Use sudo to become root. become: true tasks: - name: Install Apache package: name: apache2 state: present - name: Start and enable Apache service: name: apache2 state: started enabled: true
…легко понимается и не системным администратором.
С Ansible легко делать простые вещи, а более сложные задачи не слишком сложны, поскольку Ansible допускает циклы и другие конструкции , которые делают YAML шагом к реальному языку программирования, где возможно все. Синтаксис Ansible находится где-то между императивным и декларативным, в основном ближе к последнему по оси парадигм программирования. Вы сосредотачиваетесь на том, чего хотите, а не на том, как . Пуристы также определят императивные аспекты. Если ничего не помогает, добавьте немного кода Python в блок шаблонов Jinja2, чтобы выполнить даже самую сложную задачу.
Помимо написания плейбуков для выполнения задач, в Ansible есть концепция, называемая специальной командой , которую можно использовать для внесения изменений в работающие системы без написания какого-либо YAML. Например, чтобы перезапустить все экземпляры Apache на всех хостах в webserversгруппе. Это похоже на подключение по SSH ко всем хостам и запуск systemctl restart apache2. Это и синтаксис делают Ansible очень подходящим для ситуаций, когда оператор очень привык к управлению системами, но ему нужны руки робота, чтобы помочь с управлением парком.
Если вы стремитесь создать неизменяемую инфраструктуру, подобную той, которая обычно связана с запуском контейнеров, Ansible можно пометить вместе с Packer . При совместном использовании Ansible управляет состоянием развертываемых образов. Также доступен Ansible-ориентированный способ создания контейнеров, так как чистый синтаксис Dockerfile может начать вас раздражать в какой-то момент.
Кстати, короткий фрагмент выше полностью функционален! Вы можете поместить его в файл с именем playbook.ymlи запустить команду ansible-playbook -i localhost playbook.ymlпосле установки самого Ansible. Без каких-либо изменений он установит и запустит Apache в системе Linux на основе Debian. Просто для начала, не так ли?
Каковы недостатки?
Теперь вы могли бы вести со мной продолжительную дискуссию, и я мог бы убедить вас, что их нет. Но ради реализма… чтобы мои коллеги были счастливы , есть некоторые вещи, которые могут вас раздражать в Ansible.
У Jinja2 есть свои особенности, одна из которых — обработка всего как строки по умолчанию, так как по своей сути он предназначен для рендеринга текстовых файлов. Будьте готовы немного потанцевать с целыми числами. Некоторый прогресс был достигнут из темных дней, но вам все еще нужно включить его .
YAML. Что ж, YAML хорош и все такое, но обманчиво прост. На самом деле это довольно сложно , и вы можете, например, определить многострочную строку миллионом способов. Достаточно, чтобы гарантировать наличие специального веб-сайта: yaml-multiline.info . Логические значения также могут быть выражены разными способами, поэтому в некоторых местах вы можете увидеть yesвместо . trueОба варианта синтаксически правильны , но для ясности следует придерживаться одного из них. Просто помните, что Norway тоже ложнаNO , так как интерпретируется как логическое значение. Не забывайте также правильно делать отступ в каждой строке. Неправильный размер отступа в большинстве случаев приводит к ошибке или неправильному толкованию в остальных.
Выполнение задачи линейное, для каждой задачи одновременно выполняется пакет хостов, но задачи следуют друг за другом в строгом порядке. Это можно изменить, выбрав другую стратегию , но опять же, это параметр конфигурации, который, скорее всего, оставлен по умолчанию, и вам нужно знать последствия его включения.
Ansible также не имеет состояния по своей конструкции, поэтому по сравнению с обработкой состояния Terraform ему необходимо идти и проверять каждый ресурс, каждый раз, когда он сталкивается с задачей, которую вы создали для управления состоянием указанного ресурса. Получить хорошую разницу изменений за один раз невозможно, например, в Terraform или Helm. В сочетании с линейной стратегией по умолчанию будьте готовы ждать, пока ваша 1000-я задача внесет свои изменения после того, как 999 впервые будут отмечены знаком ok. Есть несколько способов ограничить это время ожидания, но у Ansible нет способа узнать , что модификация есть только у последней задачи, а у остальных нет, пока она не дойдет до конца.
Также нет реальных зависимостей между ресурсами, как в Puppet и Terraform. В то время как вы можете получать выходные данные задач registerи использовать их в качестве входных данных в другом месте, а также можете notifyиспользовать другие ресурсы handlersво время изменений. Вы не можете получить график всех ресурсов в ваших книгах и ролях.
Ansible отлично работает, когда у вас есть ограниченное количество администраторов, выполняющих команды. Все они имеют контроль доступа на стороне «корневого доступа» спектра разрешений. У него нет механизма блокировки, если только вы его не создадите, поэтому ничто не мешает вам запускать конфликтующие изменения из нескольких мест одновременно. Контроль версий настоятельно рекомендуется с плейбуками, но из-за этого обработка ветвей может потребовать некоторой работы со стороны пользователя. Вы можете начать мечтать о сервере, как в Chef или Puppet, когда достигнете определенного уровня. Для контроля доступа, централизованного управления или при наличии пользователей с разной степенью разрешений.
Можно также сказать, что безагентная push-архитектура имеет свои ограничения, но давайте согласимся, что у другого направления тоже есть проблемы, и они подходят для разных типов вариантов использования. Среди всех плюсов и минусов возникает еще один вопрос: когда следует выбирать Ansible в качестве предпочтительного инструмента?
Когда я должен выбрать Ansible вместо альтернатив?
Ansible отлично справляется с управлением серверами и инфраструктурой Unix-y. Написание ролей и управление установкой, настройкой и запуском таких сервисов, как Apache, Elasticsearch или MariaDB. Он также имеет множество модулей, связанных с сетью, поэтому Ansible чувствует себя как дома в центре обработки данных. Места, где среда немного более статична по сравнению с эфемерной природой контейнеров.
Специальные команды и простой синтаксис делают его хорошим инструментом для операторов. Чтобы быстро начать работу, старые скрипты и штуковины можно преобразовать в YAML с меньшими усилиями, чем научиться писать Ruby для Chef, терраформировать все или перейти на новый способ работы с контейнерами и Kubernetes.
У Ansible нет ни пользовательского интерфейса, ни сервера, если не считать Ansible Tower от RedHat. Таким образом, он обслуживает пользователей, разбирающихся в командной строке, лучше, чем люди, привыкшие нажимать кнопки. Говоря о Tower, он позволяет визуализировать и централизовать использование Ansible. Он также предоставляет вам API и контроль доступа. Это также идет с ценником. В качестве альтернативы AWX — это исходная версия Tower с открытым исходным кодом.
Хотя можно использовать Ansible для взаимодействия с API-интерфейсами облачной платформы для создания серверов, а затем с помощью модуля динамической инвентаризации для подключения к ним в качестве хостов, Ansible не в лучшем виде. В более широком масштабе вы можете начать ценить обработку состояния Terraform и сопоставление конфигурации с реальными ресурсами.
При работе с общедоступными облаками, такими как AWS, Azure или GCP, консенсус, похоже, заключается в том, чтобы использовать Terraform для подготовки. Вполне возможно, из-за указанной выше причины обработки состояния. Но Terraform не преуспевает в управлении содержимым серверов, поэтому, возможно, продолжайте управлять конфигурацией с помощью Ansible. Однако это плохо работает с автоматическим масштабированием и другими действиями по оркестровке. Поэтому лучшим вариантом было бы создать изображения с помощью Ansible, а затем отправить их в облако с помощью Terraform. После этого выполните любое автомасштабирование и восстановление после сбоя с неизменяемыми образами. Что касается операций, Ansible будет удобен благодаря специальным командам и быстрому написанию плейбуков.
Облачные провайдеры также имеют свои собственные способы ведения дел. Я слышал хорошие отзывы о CDK от Amazon, но никогда им не пользовался. Поскольку это фактически код-код , а не вид-кода Ansible , он зависит от вашего опыта и личных предпочтений, а также от возможностей программного обеспечения. И даже с CDK вы получаете промежуточный декларативный CloudFormation . У Azure есть свой Resource Manager , а Google назвал их Deployment Manager . Но облачные технологии — это именно облачные технологии . При выборе инструментов я вижу большую ценность в том, чтобы придерживаться более широкого круга задач.
Например, в OpenStack я лично предпочел бы Ansible писать шаблоны Heat при предоставлении основных ресурсов. Инструмент более общий, и я думаю, что лучше быть экспертом Ansible, чем экспертом OpenStack Heat. Шаблоны Heat, как правило, со временем становятся все более запутанными и чрезмерно сложными. Но существуют некоторые ограничения на то, что поддерживают текущие модули OpenStack, поэтому необходимость управления новейшими компонентами OpenStack может ограничить ваш выбор инструментов. Однако после перехода к collections разработка модуля, похоже, набирает обороты. Говоря об OpenStack, OpenStack-Ansible — хороший проект для развертывания самого OpenStack.
Поддерживается управление серверами Windows, но модули Windows хранятся отдельно от вариантов Linux. Их также гораздо меньше по количеству. Переход с Ubuntu на RedHat менее болезненный и требует меньше изменений в YAML, чем переход с Ubuntu на Windows. Контроллер Ansible также должен быть основан на Unix, и, хотя теоретически возможно использовать для этого WSL, он не поддерживается и не рекомендуется для использования в производстве.
Но дело в том, что вы не ограничены только одним инструментом! Ansible отлично работает в сочетании с Terraform. Вы можете использовать его для создания некоторых кластеров Kubernetes локально или в облаке , а затем использовать Helm для управления самими развертываниями. Вы также можете более глубоко подключить Ansible к Kubernetes с помощью Operator SDK . Вы можете использовать его для создания образов контейнеров, а также образов виртуальных машин для достижения неизменности в производственных средах. И, помимо различных альтернатив, он действительно превосходен в управлении сетевым оборудованием, поэтому вы можете подключить его к NetBox .
Я надеюсь, что это послужит хорошим введением в Ansible и пробудит ваш интерес. Если вы уже знакомы с этим или находитесь в процессе выбора инструментов, взгляните на следующую часть этой серии блогов, чтобы узнать об основных концепциях, некоторых фактах использования и передовых методах.
Статья является переводом medium.com
