[Перевод] Обрезаем строки: переход с Puppet Enterprise на Ansible Tower. Часть 2
Национальная информационная служба спутниковых данных об окружающей среде (NESDIS) на 35% снизила свои затраты на управление конфигурацией Red Hat Enterprise Linux (RHEL), перейдя с Puppet Enterprise на Ansible Tower. В этом видео категории «как мы это сделали» системный инженер Майкл Рау обосновывает выполнение этой миграции, делится полезными советами и опытом, полученным в результате перехода с одной SCM на другую.
Из этого видео вы узнаете:
- как обосновать руководству целесообразность перехода с Puppet Enterprise на Ansible Tower;
- какие стратегии использовать для максимально плавного перехода;
- советы по транскодированию PE манифестов в Ansible Playbook;
- рекомендации по оптимальной установке Ansible Tower.
Обрезаем строки: переход с Puppet Enterprise на Ansible Tower. Часть 1
У меня есть теги для первоначального развертывания, которые все запускают. У меня есть теги, которые проверяют изменения 20% инфраструктуры, происходящие в 80% рабочего времени. Аналогичная ситуация с ролями. Есть один код, занимающийся техобслуживанием, второй код, организующий развертывание, третий, запускающий оборудование, скажем, раз в день. Роль проверяет изменения всего оборудования, подлежащего развертыванию, и проверки производятся раз в два часа для того оборудования, которое может подвергнуться изменениям. Это касается файрвола, некоторых административных вещей и тому подобного.
Используйте полезные привычки, приобретенные при написании кода для Puppet, потому что они пригодятся и для Ansible. Например, такая вещь, как идемпотентность — свойство объекта или операции при повторном применении операции к объекту давать тот же результат, что и при первом. В нашем случае это означает, что при повторном запуске одного и того сценария playbook ничего не меняется, и система сообщит вам, что ничего не поменялось. Если же изменения зафиксированы, это означает, что с вашим кодом что-то не так. То есть идемпотентность поможет вам обнаружить, когда что-то пойдет не так при запуске одних и тех же рутинных операций.
Используйте факты и шаблоны, избегайте жестко встроенных данных. Ansible позволяет проделать подобное с помощью сценариев, гибко оперируя набором данных и подхватывая изменения «на лету». В Puppet такого нет, вы должны разместить все важные данные внутри исходного кода. Поэтому используйте роли, это серьезно облегчит вашу задачу.
Используйте обработчики событий, которые вызваны изменением конфигурации. Хорошо то, что обработчики умеют работать с защищенными последовательностями. Документируйте все, что вы делаете. Я ненавижу, когда попадается код, который я написал полгода назад, ничего не документируя в тот момент, и я не могу вспомнить, зачем я его вообще писал. Поэтому любая задача должна иметь описание. Каждая написанная вами роль и сценарий должны иметь свой ReadMe, в котором будет записано, как ими пользоваться и что они делают. Поверьте, позже вам это очень пригодится.
Вы должны воспользоваться новыми свободами, которые предоставляет Ansible. Вы можете затрагивать один и тот же файл несколько раз, если это потребуется. Например, если вам понадобиться изменить несколько параметров файла sshd_config в одном сценарии, содержащем важные параметры для других сценариев, вы можете это сделать. Puppet такого не позволяет.
С Ansible вы получаете предсказуемое выполнение программ. Они работают именно так, как вы от них ожидаете, и вам не нужен мониторинг ошибок выполнения кода. Если вы работаете с EXEC, знайте, что обработчики Ansible «умнее» обработчиков Puppet. Пользуйтесь такими «трюками» Ansible, как моя любимая функция Delegation. Например, вы запустили playbook для сервера А, но часть этапов этого сценария должны выполняться независимо на сервере В. Я использовал функцию делегирования для миграции с puppet на Ansible. C этой функцией вы можете настроить выполнение задачи на другом хосте, а не на том, который был настроен с помощью ключа delegate_to. Модуль по-прежнему будет выполняться один раз для каждой машины, но вместо того, чтобы работать на целевой машине, он будет работать на делегированном хосте, причем все имеющиеся факты будут применимы к текущему хосту. Это существенно сократит объем ручных настроек системы.
Ваши данные библиотеки Puppet Hiera могут использоваться в качестве фактов Ansible, которые представляют собой информацию о подключенных узлах. Факты — это то, что собирает при выполнении модуль Gather facts: объем дискового пространства, версия и тип операционной системы, hostname, объем доступной памяти, архитектура процессора, IP-адреса, сетевые интерфейсы и их состояние. Я не имею в виду служебную информацию, спрятанную глубоко внутри данных — просто используйте скрипты вашего оборудования для формирования групп и переменных узлов. Мои скрипт оборудования говорит системе о том, какие физические сайты в ней содержатся. Долее я использую роли, например, одна из ролей содержит такие факты инфраструктуры для каждого физического сайта, как ресурсы NTP, DNS-серверы, IP-адреса модульного оборудования, сканера Nessus и тому подобное. Соберите распространенные переменные в одну роль, если вы размещаете их более чем в одном месте, и разместите на хосте в виде файла /etc/ansible/facts.d/.
Итак, рассмотрим собственно процесс миграции. Повторюсь — для меня это заняло много времени, но вы сможете его сократить. В первую очередь необходимо купить и развернуть Tower. Это очень понятный процесс, просто следуйте документации по установке.
После установки Tower вы сразу получите доступ к веб-интерфейсу. Далее вам нужно установить сценарий инвентаризации оборудования inventory script и создать список оборудования. Вы можете скопировать и вставить в Tower уже имеющиеся скрипты.
Далее установите полномочия и разрешения Git, предоставив Tower прямой доступ к репозиторию Git, в котором вы храните playbooks. Тем самым вы позволите Tower мгновенно получать из сценариев информацию об изменениях и тут же их осуществлять. Вам не нужно ничего сообщать Tower, он просто будет проверять состояние системы и запускать последнюю версию конфигурации.
Установите стандартный аккаунт Tower для SSH на ваши хосты. Я использую удаленный доступ, поэтому я пользуюсь стандартным аккаунтом и программой для системного администрирования SUDO для установки привилегий. Конечно, Tower имеет пароль, поэтому вы не рискуете безопасностью, используя пароль SUDO.
Выполните конфигурацию аутентификации Tower в соответствии со структурой доступов вашей организации. Определитесь с доступами для отделов, команд, с распределением доступов к ролям, разберитесь со специальными разрешениями. Это очень объемная задача, зависящая от размеров вашей организации, но помните, что с точки зрения администрирования Tower, благодаря гибкой настройке доступов, может серьезно облегчить вашу жизнь.
Теперь, когда у вас развернут репозиторий Git, займитесь установкой и настройкой рабочих шаблонов для сценариев playbooks. Тестируйте работоспособность всего, что вы делаете с Tower. После того, как убедитесь, что ваши сценарии в полном порядке, можете приступить к миграции хостов. Используйте Ansible для удаления агента Puppet и «вычистки» узла с Puppet-сервера с помощью специального сценария. Это очень просто.
Я создал группу под названием Tower, добавил ее в сценарий Ansible и отправил на все хосты. После этого данный playbook остановил службы Puppet, удалил все пакеты Puppet Enterprise, очистил каталоги. Он также удалил пользователей Puppet — раз мы удаляем PE, значит, удаляем и пользователей PE.
Мы видим функцию Delegation в действии. Теперь я могу зайти в Puppet Master и при помощи 2–3 команд очистить реестр, а затем сделать скриншот, показывающий, что эта SCM удалена. Он послужит документальным подтверждением того, что мы больше не используем PE.
Теперь давайте рассмотрим, чему следует уделить максимум внимания — мои ошибки, которых нужно избегать. В первую очередь это касается зависимости сценариев друг от друга. Возможно, что переменные одного playbook зависят от переменных другого playbook. Помните, что в каждый сценарий можно вставить требования, позволяющие использование другого сценария или роли. Я создал роли для переменных всех наших сайтов, и каждая из этих ролей содержала множество переменных. Поэтому я использовал файл requirements.yml для централизации общих переменных. Он позволяет устанавливать несколько коллекций контента Ansible одной командой.
Если у нас поменяется шлюз по умолчанию или NTP-сервер, эти изменения немедленно отразятся во всех элементах инфраструктуры.
Избегайте использования массивных, объемных ролей и сценариев. Короткие сценарии и роли для конкретных задач действуют более эффективно и надежно, ими легче управлять и их проще отслеживать.
Обратите внимание еще на одну вещь — когда вы запустите Tower и зайдете на его страницу, то увидите отображение множества параметров в красном цвете. Этот цвет — сигнал тревоги, но вот в чем дело. Вы запускаете процесс на сотне хостов, и если 99 из них работают успешно, а один — нет, Tower сообщит о сбое процесса. Он разместит яркий красный маркер на экране, иллюстрирующем данную работу. Не паникуйте, а постарайтесь выяснить, почему не работает этот единственный узел. Когда вы смотрите на экран Puppet Master и видите 99 зеленых огоньков и один красный, то думаете, что в целом все в порядке, система отлично работает. Tower более строго, но менее информативно относится к сообщениям о неполадках. Возможно, в следующих версиях Ansible этот недостаток будет устранен, но пока просто постарайтесь разобраться в причине тревоги, помня, что такая сигнализация может не нести в себе ничего критического — просто таким образом система сообщает об одном сбое на одном хосте.
Будьте осторожны, если у вас имеются временные хосты, которые не всегда находятся в онлайн-режиме. Например, в моей системе имеется несколько ноутбуков. Мы администрируем их с помощью Ansible Tower так же, как и постоянные хосты, но поскольку это мобильные устройства, то они не постоянно присутствуют в сети. Если вы используете временные хосты при выполнении стандартных процессов, но Tower не обнаруживает их в сети при инициации системы, на его экране тут же появится сигнал тревоги и сообщение о сбое процесса. Tower не знает о том, что эти ноутбуки в данный момент просто выключены. В этом нет никакой проблемы, просто имейте в виду, что подобная ситуация может вызвать тревожное сообщение.
Существует хороший способ использования Tower API. Когда ноутбук загружается как часть стандартной процедуры загрузки системы, он использует API, чтобы сообщить Tower: «эй, я здесь, нет ли для меня какой-то работы?», после чего Tower проверяет наличие задач для этой конкретной машины в настоящее время, поскольку знает, что она в сети.
Еще одна вещь, с которой у нас поначалу возникли проблемы, это выполнение параллельных операций. По умолчанию Ansible использует 5 параллельных хостов для выполнения одной работы. Поэтому запуск одинаковой работы по расписанию для 100 машин занимает до 20 минут на хост за счет проверки параметров основной конфигурации. Таким образом, сначала у нас запускается конфигурация на 5 хостах, потом еще на 5, еще на 5 и так далее. Вначале это обстоятельство заставило нас серьезно понервничать, потому что развертывание системы на 50 хостах происходило в течение 2 часов. Решение этой проблемы заключается в следующем.
Просто установите на сервере Ansible Tower количество параллельных хостов, отличное от 5. Поскольку у меня 150 одновременно запускаемых хостов, я установил это значение на 25. После этого 6 патчей, например, устанавливались достаточно быстро. При желании вы можете установить этот параметр равным 50 — все зависит от того, какими вычислительными мощностями и каким объемом RAM вы располагаете. Таким образом Tower позволяет настроить выполнение параллельных процессов в соответствии с вашими потребностями.
Если у вас возникли вопросы по теме доклада, не стесняйтесь обращаться по указанным контактам. Вы видите адрес электронной почты, куда можете отправить письмо с описанием проблемы, возникшей при переходе с Puppet на Ansible, и я постараюсь ответить вам как можно скорее. Благодарю вас за участие и желаю удачной миграции!
Немного рекламы :)
Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас, оформив заказ или порекомендовав знакомым, облачные VPS для разработчиков от $4.99, уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5–2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps от $19 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).
Dell R730xd в 2 раза дешевле в дата-центре Equinix Tier IV в Амстердаме? Только у нас 2 х Intel TetraDeca-Core Xeon 2x E5–2697v3 2.6GHz 14C 64GB DDR4 4×960GB SSD 1Gbps 100 ТВ от $199 в Нидерландах! Dell R420 — 2x E5–2430 2.2Ghz 6C 128GB DDR3 2×960GB SSD 1Gbps 100TB — от $99! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5–2650 v4 стоимостью 9000 евро за копейки?
