В инфраструктуре заказчика имелся большой зоопарк систем, не объединенных единой логикой. Надо было навести порядок и наладить автоматизацию, особенно после того, как в этом уже поучаствовали сотрудники различных подразделений и сторонних компаний, не особо озабоченных единой концепцией.
Нам повезло, что заказчик сам не до конца представлял, что именно хочет, поэтому в проекте было много пространства для творчества и возможности применить методологию DevOps, в том числе к системам на AIX. Ну а началось все с одного болезненного инцидента.
Представьте себе огромную компанию примерно в 350 тыс. человек, где инженеры SAP управляют семью сотнями хостов. Хосты обрабатывают миллионы транзакций в день в основных подразделениях компании, на них же функционирует масштабная ERP-система, HR и несколько других им подобных.
Инфраструктура включает как физические сервера, так и виртуальные машины на разных архитектурах виртуализации x86 KVM, IBM POWER Hypervisor с операционными системами AIX, Suse, RedHat, RHEL, SLES, AIX и даже RHEL on Power.
Изначально весь этот «зоопарк» не был объединен общей логикой и разделялся по ландшафтам и регионам. В какой-то момент их собрали в одну общую инфраструктуру. Многие системы мигрировали из небольших ЦОД в централизованные, при этом произошло переключение на общий DNS.
Когда «Франкенштейн» стал нормой
До определенного момента все работало без сбоев, пока не случился фатальный эпизод. В деталях нам не рассказывали, но, похоже, что-то приключилось с центральным DNS-сервером. То ли он отказал, то ли возникли некие сетевые проблемы, из-за которых частично или полностью пропал к нему доступ. Возможно, это случилось во время обновления оборудования или в процессе очередного переезда. Как итог – пошла цепная реакция, вызвавшая серьезную деградацию в работе основных сервисов.
Простыми словами: в гигантской компании внезапно затормозились ключевые процессы.
Тогда инженеры компании, сопровождающие SAP, решили основательно подстраховаться и выбрали файл /etc/hosts в качестве резерва для централизованного DNS. Причем отнеслись к этому с максимальной скрупулезностью, превратив локальный файл hosts в некое подобие выделенного DNS-сервера, расположенного локально на каждом из узлов SAP-систем.
Спустя некоторое время эти системы были взяты нашей командой Unix-инженеров в поддержку. Тут то мы и столкнулись с тем самым “Франкенштейном”. Речь про файл hosts, который периодически редактировался вручную или с помощью рукописных bash-скриптов. В него добавлялись новые инстансы, удалялись старые, появлялись, исчезали, изменялись системы и целые ландшафты.
В какой-то момент hosts превратился в настоящего монстра – стал слишком громоздким, с труднопонимаемой структурой. Дошло до того, что инженеры сопровождения, работавшие с заказчиком до нашего подключения к проекту, просто стали добавлять новые записи в конец файла, не принимая во внимание логическое разбиение систем и ландшафтов. Это сделало файл максимально неструктурированным и непригодным к обслуживанию.
Первое время мы также редактировали записи в файле рукописным скриптом в полуавтоматизированном режиме. Но быстро поняли, что в текущем виде это обслуживать невозможно, и это точно не наш метод.
Логика вместе с официальными рекомендациями SAP подсказывали, что для повышения стабильности системы надо вносить локальные записи для каждого инстанса в файл /etc/hosts. Изначально мы планировали для каждого ландшафта создавать свой локальный файл hosts тех систем, которые там требуются. Вроде все понятно. Но наша картина мира немного отличалась от требований заказчика и суровой реальности.
Основной вызов состоял в том, что требовалось объединить все ландшафты в одном файле, тиражировать их на все системы, при этом соблюсти структуру, логику, последовательность, а также сохранить читаемость и надежность, при этом учесть различные исключения.
Кроме всего вышеперечисленного нужно было навести порядок и выстроить логику в списках хостов, применив системный подход. В итоге задача трансформировалась в выработку процедуры автоматизированного редактирования и контроля за файлами. Так началась история внедрения автоматизированного подхода к управлению инфраструктурой (Infrastructure as Code).
Тут стоит оговориться, что наша позиция – использовать правильные и эффективные инструменты (DNS), но в тот момент у нас не было выбора. Задача была жестко сформулирована заказчиком (hosts) – поэтому пришлось решать именно ее.
Infrastructure as Code, как она должна быть
Так как результат необходимо было предоставить в максимально сжатые сроки, приняли решение начать с доступа в Git и установки Ansible. Ansible был выбран как наиболее подходящий инструмент для управления разнородным составом серверов, поскольку для него не требуется установка агентов. Кроме того, в нашей команде инженеров поддержки Unix-систем имелась достаточная экспертиза, чтобы писать код в Ansible и поддерживать его работу, а также богатый набор уже написанных ролей и плейбуков.
Казалось, нет ничего сложного в том, чтобы написать плейбук, создающий из темплейта требуемые записи в файле hosts. Подобное упражнение дается на экзамене RHCE. Но в нашем случае задача усложнялась требованиями внести данные не только обо всех системах и их сетевых интерфейсах. Имена систем имели у заказчика разную логику формирования. Плюс дополнительные разнообразные вспомогательные внутренние и виртуальные адреса, соответствующие неким определенным названиям, также должны были быть описаны в /etc/hosts.
Особая головная боль – различные группы хостов с исключениями из правил, о которых упоминалось выше. Например, предполагается, что на всех узлах должна быть одинаковая копия файла. Но в одной из десятков групп хостов есть порядка восьми подгрупп, где одна определенная запись должна иметь отличный от других IP-адрес. Также есть определенные группы хостов, на которых требуется, например, добавить некоторые записи, не нужные на всех остальных системах.
В итоге возникла первая версия Ansible-роли с темплейтом, которая переупаковывала его в красивый и структурированный файл.
В роли была реализована сложная логика, способная обработать все варианты префиксов, постфиксов, исключений и вспомогательных IP-адресов, требуемых для полноценного файла hosts. Но, самое главное, теперь все было в одном месте: мы запротоколировали все системы в файле инвентори с их адресами и дополнительными атрибутами.
Логичное сопротивление заказчика
В процессе презентации решения заказчику наибольшие усилия пришлось приложить в преодолении непонимания работы темплейта Ansible, который создавал для каждой управляемой машины свой файл, а не тиражировал один единственный и неповторимый «золотой стандарт» в неизменном виде. Возврат к «золотому стандарту» означал бы продолжение хаотичного наполнения файла без унифицированной логики, повышенные риски сбоев и потеря времени на разбор.
Чтобы помочь заказчику побыстрее принять решение, мы добавили в Ansible-роль многочисленные вспомогательные функции, такие как: наборы предварительных проверок, генерация предустанавливаемого файла hosts перед процедурой тиражирования, его валидация и даже интеграции с системой SAP Landscape Management.
Часть этих функций и производимых действий была избыточна, зато мы показали возможности, да и вообще заказчику было приятно, когда у него автоматически все проверилось, забэкапилось и зедеплоилось по ландшафтам, а в интерфейсе их SAP Landscape Management загорелись зеленые индикаторы того, что все в порядке. Лишние хлопоты иногда стоят того, чтобы люди себя чувствовали спокойно и не сопротивлялись полезным изменениям.
Далее начался процесс внедрения.
Чем больше ролей, тем лучше
Разумеется, в процессе внедрения приходилось дорабатывать логику работы темплейта, вносить изменения в код для оптимизации и ускорения. Нам удалось запараметризовать максимальное количество вариантов для создания записей в файле hosts и вынести их в group_vars. Это упростило управление и сократило время работы скрипта.
На первой стадии внедрения мы ограничились запуском плейбуков с Ansible jump-хоста. В дальнейшем удобство использования Ansible и наш энтузиазм вылились в создание все большего числа инфраструктурных ролей, с помощью которых мы стали упрощать всевозможные типовые задачи, такие как настройка NTP (ntpd и chrony в зависимости от операционной системы), установка и конфигурация Splunk и Zabbix-агентов, сетевые настройки, установки различных пакетов, выполнение обновлений операционных систем, управление firewall (iptables на Linux и genfilt в AIX), управление параметрами ядра, пользователями, группами, паролями и многое другое.
Отдельное место в развитии проекта заняла адаптация ролей под AIX. Поскольку Ansible чаще используется с Linux, то в разных библиотеках модулей почти всегда можно найти тот, который бы отвечал заданным требованиям. Для IBM AIX, по сути, есть только одна поддерживаемая библиотека Ansible-модулей. И для многих, казалось бы простых функций, реализованных модулями Ansible для linux, в ней нет подходящих решений. Например, в процессе написания некоторых функциональных ролей нам пришлось писать свои модули для аналога locale_gen (Locale в Unix – набор параметров, определяющий региональные настройки пользовательского интерфейса, такие как язык, страна, часовой пояс, формат вывода даты и пр.) и для управления RPM пакетами.
В общем, под AIX тоже можно делать DevOps, если очень захотеть.
В итоге все это стало экономить нам большое число человеко-часов. Допустим тиражирование файла /etc/hosts занимало день, потому как нужно было подготовить скрипт, кастомизировать, дописать строчки, удалить строчки, протестировать (и помолиться, чтобы все прошло удачно на проде). Сейчас вся подготовка занимает порядка десяти минут.
В последствии, с увеличением вовлеченности инженеров техподдержки в использование Ansible-репозитория, одного jump-хоста стало недостаточно. Пришло время доработать проект и довести все до логичного завершения – полноценные пайплайны для автоматизированного развертывания.
В результате появился объединенный репозиторий с множеством Ansible-ролей наподобие локального ansible-galaxy, способных управлять инфраструктурой заказчика и конфигурировать системы в разных ландшафтах независимо от их специфики. Репозиторий хостится в корпоративном GitLab и работает по рельсам пайплайнов нажатием кнопки в веб-интерфейсе.
Все это максимально страхует от человеческого фактора, экономит кучу времени и позволяет вести нормальную совместную работу.
Что в итоге
Вся эта история скорее про то, что любые систематические трудности и специфические требования заказчика можно решить с помощью автоматизации. В описанном случае нам остается лишь добавлять в локальный galaxy новые роли, совершенствовать существующие плейбуки, оптимизировать и добавлять сценарии их выполнения.
Многие воспринимают системное администрирование как выполнение рутинных задач. А инфраструктуру на больших мейнфреймах с проприетарными операционными системами, как недостаточно гибкую и плохо поддающуюся автоматизации. Но даже с такой специфической инфраструктурой, как системы IBM Power Systems под управлением AIX, можно создать Devops-подход для автоматизации рутины по принципу Infrastructure as a Code.
