Введение
В нашей среде много серверов. Не один-два, а более 100 серверов. И на этих серверах общим образом установлен Nexus. Когда мы получаем внешние библиотеки или пакеты, вместо того чтобы каждый раз загружать их из интернета, близкий Nexus скачивает их один раз и кэширует, выполняя роль «промежуточного хранилища», которое быстро отдает их. В условиях нестабильной внешней сети это оказалось довольно важным устройством.
Проблема в том, что каждую Nexus нужно настраивать с одинаковыми параметрами, а также часто добавляются хранилища или дополнительные настройки. Если серверов десятки, то необходимо многократно повторять настройки, чтобы указать, на какое внешнее хранилище смотреть и какие хранилища показывать вместе. Надо было зайти на один сервер, настроить его, выйти и переходить на следующий, и снова настраивать то же самое.
Первые пару серверов были вполне по силам. Но с ростом числа серверов некоторые из них забывались в настройках, на некоторых возникали опечатки, а некоторые настраивались неосознанно немного иначе. Я был уверен, что «все настроено одинаково», но на самом деле все было по-разному.
И вдруг мне пришла в голову такая мысль. Настройки этих серверов в конечном итоге должны быть одинаковыми. В таком случае, можно записать один раз, как «они должны быть настроены», и остальное пусть машина применяет одинаково ко всем серверам. Это и подтолкнуло меня к выбору Ansible.
Так что же такое Ansible?
Ansible — это, если говорить коротко, «инструмент автоматизации, который делает одно и то же за несколько серверов». Я пишу, что «эти серверы должны быть в таком состоянии», и Ansible подключается к каждому из них и делает так. Будь их десятки или сотни, для этого достаточно одной команды.
У меня было несколько причин, почему я заинтересовался Ansible. Оказалось, что характер этого инструмента действительно очень подходит к нашей ситуации.
Во-первых, не нужно было заранее устанавливать что-то на сервер.Среди инструментов автоматизации есть и такие, что требуют предварительной установки программы «агента» на каждом управляемом сервере. Но Ansible требует только подключения через SSH. В ситуации, как у нас, когда серверы разбросаны по десяткам, установка и управление чем-либо на всех этих серверах было бы само по себе работой, поэтому отсутствие этого бремени было важным.
Во-вторых, было безопасно, даже если выполнять несколько раз.Эта часть сначала не так воспринималась, но, попробовав, стала действительно важным качеством. Ansible не вмешивается, если «это уже так». Например, если какие-то настройки уже правильно выполнены, повторное выполнение на сервере не создаст снова то же самое, а просто определит, что «это уже правильно», и перейдет дальше. Таким образом, не нужно было постоянно помнить, «выполнены ли настройки на этом сервере или нет». Один раз выполнив для всей группы, можно узнать только о тех, что не были настроены.
В-третьих, можно было записывать настройки в виде текста.Конфигурационные файлы Ansible имеют удобочитаемый формат, так что даже не углубляясь в программирование, было понятно, «что нужно сделать». Это не было сложным кодом, а скорее объяснением, где написано «создай это хранилище так». Это было приятно, что даже спустя время можно было понять, глядя на это снова, или даже коллегам было понятно.
Основная структура Ansible
Представление работы Ansible на рисунке значительно упрощает понимание. Общая структура оказывается surprisingly простой. В центре находится «Автоматизированный движок», и когда информация о «том, что нужно сделать» поступает слева, она распространяется на несколько серверов (или устройств) справа.
Источник изображения: https://spacelift.io/blog/ansible-architecture
Если рассмотреть каждый элемент на рисунке по отдельности, получится следующее. Это может показаться сложной терминологией, но после понимания ролей становится просто.
• Автоматизированный движок (Automation Engine): Это центральный элемент, находящийся в центре рисунка. Он выполняет роль «мозга», обрабатывающего задачи, и обычно размещается на рабочем ПК или одном отдельном сервере управления. Это называется управляющим узлом (Control Node), и здесь начинается всё.
• Playbook (плейбук): Это инструкция, в которой написано «что и как делать». Она составлена в формате, удобном для чтения человеком (YAML), и описывает шаг за шагом задачи, такие как «создайте этот репозиторий таким образом». Здесь именно то место, где написан правильный ответ.
• Инвентарь (Inventory): Это список «к каким серверам применить». Это можно представить как адресную книгу для десятков серверов Nexus. Когда появляется новый сервер, достаточно добавить одну строку сюда. В моём случае при завершении работы адреса серверов автоматически комментировались, что позволило избежать повторных запусков во время работы.
• Модули (Modules): Это небольшие инструменты, выполняющие реальные задачи. Они служат компонентами для выполнения таких задач, как "копировать файл", "изменить настройки", которые Ansible временно отправляет на целевой сервер для выполнения и очищает после завершения.
• Плагины (Plugins) / API: Это части, используемые для расширения возможностей Ansible или подключения к другим системам. Вначале не обязательно глубоко разбираться, достаточно знать, что "это можно расширить".
• Хосты / Сети (Hosts / Networking): Это серверы или сетевые устройства, к которым фактически применяется работа, изображенные справа. В нашем случае это десятки серверов с установленным Nexus. Главное, что на этих устройствах не нужно ничего устанавливать заранее.
На этой картинке наиболее заметной частью является направление потока. Слева (созданная команда) → через центр (движок) → направо (десятки серверов) работа распространяется сразу на несколько серверов. Моя задача ограничивается написанием "ответа" слева, а обработка распределения этого ответа ко всем серверам осуществляется движком автоматически. Этот повторяющийся процесс, когда я вручную подключался к каждому серверу, теперь упорядочен на этой одной картинке.
Что изменилось
Первым, что я ощутил после внедрения автоматизации, было время. Ранее я тратил целый день на работу с десятками серверов, теперь это занимает всего одну команду. Даже если добавляется новый сервер, достаточно просто добавить одну строку в список и снова выполнить команду.
Но более существенное изменение заключалось в "последовательности". Теперь я стал уверен в том, что все серверы настроены одинаково. Тонкие различия, возникавшие при ручной настройке, исчезли.
И я стал гораздо спокойнее. Ранее меня постоянно беспокоила неопределенность, "не забыты ли некоторые серверы", теперь достаточно выполнить команду один раз для всех. Серверы, которые уже настроены правильно, остаются без изменений, а только те, что не соответствуют, настраиваются автоматически. Эта стабильность, когда "только неработающие заполняются", значительно снизила нагрузку, связанную с управлением десятками серверов.
Конечно, автоматизация не является всесильной. Наоборот, ее мощь в том, что "всё применяется сразу ко всем", также создает риски.
Когда вы делаете это вручную, ошибка в одном сервере затрагивает только его. Однако с автоматизацией все по-другому. Если вы неправильно укажете ответ, эта ошибка мгновенно распространяется на «все» серверы. Ошибка в одном месте становится причиной проблем у десятков машин. Поэтому перед тем, как применить настройки на всех серверах, обязательно нужно протестировать их сначала на одной-двух машинах.
Также желательно максимально ограничить все операции консервативными настройками. В конце концов, если возникнет проблема, о которой вы не знали, это может стать проблемой для всей системы.
С точки зрения безопасности есть также уроки. Этот инструмент работает, в конечном счете, подключаясь к нескольким серверам. Это означает, что учетные данные или такие чувствительные данные, как пароль администратора Nexus, должны храниться где-то. Сначала возникло желание просто записать их в файл настроек для удобства. Но это всё равно что передать пароль любому, кто видит этот файл.
К счастью, такие инструменты обычно имеют средства для шифрования чувствительных данных и их хранения. Пароли были изолированы от основного текста настроек и не загружались в хранилище. Один раз удержавсь от соблазна «записать это для удобства», вы предотвращаете крупные инциденты в будущем. Автоматизация подразумевает, что чувствительная информация будет обрабатываться в одном месте.
В заключение
Оглядываясь назад, я не внедрял Ansible ради технического обучения. Я просто был утомлён тем, что приходилось многократно выполнять одно и то же, и тем, что человеческие руки постоянно допускали ошибки.
Тем не менее, в процессе я получил нечто неожиданное. Это не только сэкономило время, но и изменило стиль работы. Я стал «человеком, который записывает желаемое состояние», а не «человеком, который запоминает процедуры». Ноу-хау, которое было только в моей голове, стало текстом, который могут читать и исправлять все. И я смог убедиться в том, что «наши серверы все одинаковые», не в виде неопределенного ожидания, а как факт.
Если кто-то сталкивается с подобными размышлениями перед десятками серверов, я рекомендую задуматься. Должно ли это повторение происходить вручную? Идея «записать ответ один раз и доверить остальное машине» изменяет гораздо больше, чем вы можете предположить. По крайней мере, это было так для меня. Спасибо за то, что прочитали этот недостаточный текст.
Bang