[Перевод] Обрезаем строки: переход с Puppet Enterprise на Ansible Tower. Часть 1
Национальная информационная служба спутниковых данных об окружающей среде (NESDIS) на 35% снизила свои затраты на управление конфигурацией Red Hat Enterprise Linux (RHEL), перейдя с Puppet Enterprise на Ansible Tower. В этом видео категории «как мы это сделали» системный инженер Майкл Рау обосновывает выполнение этой миграции, делится полезными советами и опытом, полученным в результате перехода с одной SCM на другую.
Из этого видео вы узнаете:
- как обосновать руководству целесообразность перехода с Puppet Enterprise на Ansible Tower;
- какие стратегии использовать для максимально плавного перехода;
- советы по транскодированию PE манифестов в Ansible Playbook;
- рекомендации по оптимальной установке Ansible Tower.
Приветствую всех, меня зовут Майкл Рау, я старший системный инженер компании ActioNet, которая работает на Национальное управление океанических и атмосферных исследований (NOAA) службы NESDIS. Сегодня мы поговорим про обрезку строк — мой собственный опыт миграции с Puppet Enterprise на Ansible Tower. Тема этой презентации состоит в том, чтобы «взглянуть на мои шрамы», оставшиеся после того, как я совершил этот переход в начале года. Я хочу рассказать, что узнал в ходе этого процесса. Так что когда вы возьметесь за подобное, используя мой опыт, то сможете сделать переход без лишнего труда.
Вы видите слайды, аналогичные этому, в начале каждой презентации на Ansible Fest. На этом слайде изложена история автоматизации моей компании. Я не новичок в этом деле, потому что пользуюсь Puppet/Puppet Enterprise с 2007 года. Я начал работать с Ansible с 2016 года, и меня, как множество других пользователей этого продукта, привлекла возможность «трюков» с помощью командной строки и простые сценарии (playbooks). В конце 2017 года я обратился к своему руководству по поводу серьезных оснований для перехода на Ansible Tower. Через минуту я расскажу о причинах, побудивших меня на этот шаг. После получения согласия руководства потребовалось еще несколько месяцев, чтобы выполнить задуманное, и я осуществил переход в январе-феврале этого года. Итак, мы полностью отказались от Puppet в пользу Ansible, и это великое дело.
Больше всего в Ansible меня привлекает возможность писать и использовать роли (roles) и сценарии (playbooks). Роли отлично подходят для создания различных, но взаимосвязанных задач (tasks) и размещения всех данных, относящихся к этим задачам, в одном месте. Playbook — это синтаксис YAML, файл–сценарий, описывающий действия для одного или нескольких хостов. Я рассказываю об этих возможностях пользователям, в первую очередь разработчикам ПО. Ansible Tower дает возможность сказать: «нет, у вас не имеется доступа к оболочке shell access, но я предоставляю вам возможность запустить все процессы Tower и перезагрузить сервис, когда это вам потребуется». Я расскажу вам о рабочей среде и используемом нами оборудовании.
Это федеральная LAN, 7 физических сайтов, подключенных через облачное MPLS, 140 серверов RHEL, 99% которых виртуальные (vSphere), аппаратное обеспечение SuperMicro, сетевое хранилище NexentaStore, набор свитчей Cisco, Arista и Cumulus и средства унифицированного управления угрозами Fortinet UTM на каждом сайте.
Федеральная сеть означает, что я должен использовать все средства защиты информации, предусмотренные законодательными актами. Вы должны иметь в виду, что Puppet Enterprise не поддерживает большую часть используемого у нас оборудования. Мы вынуждены использовать бюджетное аппаратное обеспечение, поскольку государственные структуры испытывают проблемы с финансированием этой статьи расходов. Поэтому мы покупаем «железо» класса SuperMicro и собираем наше оборудование из отдельных частей, техническое обслуживание которых гарантировано правительственными контрактами. Мы используем Linux, и это одна из важных причин перехода на Ansible.
Наша история работы с Puppet такова.
В 2007 мы имели маленькую сеть из 20–25 узлов, в которой и развернули Puppet. В основном эти узлы представляли собой просто «коробки» RedHat. В 2010 мы начали использовать веб-интерфейс Puppet Dashboard для 45 узлов. Поскольку сеть продолжала расширяться, в 2014 мы перешли на PE 3.3, осуществив полный переход с переписыванием манифеста для 75 узлов. Это пришлось сделать, потому что Puppet любит менять правила игры, и в данном случае они полностью поменяли язык. Спустя год, когда прекратилась поддержка 3 –й версии Puppet Enterprise, мы вынуждены были мигрировать на PE 2015.2. Пришлось опять переписать манифест под новые сервера и приобрести лицензию с запасом на 100 узлов, хотя на тот момент у нас было всего 85 узлов.
Прошло всего 2 года, и нам опять пришлось провести большую работу по переходу на новую версию PE 2016.4. Мы купили лицензию на 300 узлов, имея всего 130. Нам снова пришлось вносить серьезные изменения в манифест, потому что новая версия языка имела синтаксис, отличный от языка версии 2015 года. В итоге наша SCM перешла с системы контроля версий SVN на Bitbucket (Git). Таковы были наши «взаимоотношения» с Puppet.
Итак, мне пришлось объяснить руководству, почему нам нужно переходить на другую SCM, используя следующие аргументы. Первый — высокая цена сервиса. Я разговаривал с ребятами из RedHat, и они сказали, что стоимость обслуживания сети из 300 узлов при помощи Ansible Tower составляет половину стоимости Puppet Enterprise. Если приобрести еще Ansible Engine, стоимость будет примерно одинакова, но при этом вы получите намного больше функций, чем у PE. Поскольку мы являемся государственной компанией, финансируемой из федерального бюджета, это довольно весомый аргумент.
Второй аргумент — это универсальность. Puppet поддерживает только то оборудование, на котором имеется агент Puppet. Это значит, что на все свитчи нужно установить агент, причем он должен быть последней версии. И если часть ваших свитчей поддерживает одну версию, а часть — другую, вам понадобиться установить на них новую версию агента PE, чтобы все они могли работать в одной системе SCM.
Система Ansible Tower работает по-другому, потому что у нее нет никаких агентов, но зато имеются модули, которые поддерживают свитчи Cisco и все остальные свитчи. Эта SCM поддерживает Qubes OS, Linux и 4.NET UTM. Ansible Tower также поддерживает контроллеры сетевых хранилищ NexentaStore, основанные на ядре Illumos — open-source операционной системе на основе Unix. Это очень небольшая поддержка, но Ansible Tower все равно ее осуществляет.
Третий аргумент, очень важный как для меня, так и для нашей администрации, это простота в освоении. Я в течение10 лет осваивал модули и код манифестов Puppet, но Ansible изучил в течение недели, потому что с этой SCM намного проще работать. Если вы запускаете исполняемые файлы, конечно, если вы не делаете этого без необходимости, то с ними работают разумные и отзывчивые обработчики. Сценарии playbooks, основанные на YAML, характеризуется легким изучением и быстротой использования. Те, кто никогда прежде не слыхал о YAML, могут просто прочитать сценарии и легко понять, как он работает.
Честно говоря, Puppet намного усложняет ваш труд как разработчика, потому что основан на использовании Puppet Master. Это единственная машина, имеющая право общаться с агентами Puppet. Если вы внесли какие-то изменения в манифест и хотите протестировать свой код, вы должны переписать код для Puppet Master, то есть настроить файл Puppet-мастера /etc/hosts для подключения всех клиентов и запустить службу Puppet Server. Только после этого вы сможете испытать работу сетевого оборудования на одном хосте. Это достаточно болезненная процедура.
В Ansible все намного проще. Все, что нужно сделать — это разработать код для машины, которая имеет возможность связаться по протоколу SSH с тестируемым хостом. С этим намного проще работать.
Следующий большой плюс Ansible Tower это возможность задействовать уже имеющуюся у вас систему поддержки и сохранить существующую конфигурацию оборудования. Эта SCM без каких-либо дополнительных действий использует всю имеющуюся информацию о вашей инфраструктуре и оборудовании, виртуальных машинах, серверах и т.д. Она может общаться с вашими спутниковыми серверами, если таковые имеются, и предоставляет вам такую интеграцию, которую вы никогда не получите, работая с Puppet.
Еще одной важной вещью является детальный контроль. Вы знаете, что Puppet является модульной системой, это клиент-серверное приложение, поэтому вы должны определить существующие аспекты работы всех ваших машин в одном длинном манифесте. При этом состояние каждого отдельного элемента системы нужно тестировать каждые полчаса — это период по умолчанию. Вот как работает Puppet.
Tower избавляет вас от этого. Вы можете без ограничений выполнять самые разные процессы на самом разном оборудовании, можете делать основную работу, запускать другие важные процессы, настраивать систему безопасности, работать с базами данных. Вы можете делать все то, что в Puppet Enterprise связано с определенными трудностями. Так, если вы провели настройку на одном хосте, потребуется время, чтобы изменения вступили в силу на остальных хостах. В Ansible все изменения вступают в силу одновременно.
Наконец, рассмотрим модуль безопасности. В Ansible Tower он реализован просто потрясающе, с большой точностью и тщательностью. Вы можете предоставлять пользователям доступ к конкретным службам или к конкретным хостам. Я поступаю так со своими сотрудниками, привыкшими работать на Windows, ограничивая им доступ к оболочке Linux. Я обеспечиваю им такой доступ к Tower, чтобы они могли выполнять только ту работу и запускать только те службы, которые относятся к их компетенции.
Давайте рассмотрим вещи, которые нужно проделать заранее, чтобы облегчить переход на Ansible Tower. В первую очередь необходимо подготовить ваше оборудование. Если какие-то элементы вашей инфраструктуры еще отсутствуют в базе данных, их нужно туда добавить. Существуют системы, которые не изменяют своих характеристик и поэтому отсутствуют в БД Puppet, но если вы не внесете их туда перед переходом на Tower, то лишитесь ряда преимуществ. Это может быть «грязная», предварительная БД, но она должна содержать в себе сведения обо всем имеющемся у вас оборудовании. Поэтому вам следует написать динамический скрипт оборудования, который автоматически будет вносить все изменения инфраструктуры в базу данных, тогда Ansible будет знать, какие хосты должны иметься в новой системе. Вам не нужно будет сообщать этой SCM, какие хосты вы добавили и каких хостов больше не существует, потому что все это она узнает автоматически. Чем больше данных будет в БД, тем более полезным и гибким будет Ansible. Он работает так, как будто бы просто считывает с базы данных штрих-код состояния оборудования.
Потратьте некоторое время на знакомство с работой командной строки в Ansible. Запустите какие-нибудь специальные команды, чтобы проверить работу скрипта оборудования, напишите и запустите какие-нибудь простые, но полезные сценарии playbook, используйте шаблоны Jinja2 там, где это уместно. Попробуйте написать роль и сценарий для комплексного многоэтапного процесса, используя стандартную, часто встречающуюся конфигурацию оборудования. Поиграйте с этими вещами, протестируйте, как это работает. Таким образом вы научитесь работать с инструментами для создания библиотек, используемых в Tower. Я уже говорил, что у меня подготовка к переходу заняла около 3-х месяцев. Думаю, что опираясь на мой опыт, вам удастся проделать это быстрее. Не считайте это время потерянным, поскольку позже вы ощутите все преимущества проделанной работы.
Далее необходимо решить, чего вы ждете от Ansible Tower, что конкретно эта система должна для вас сделать.
Нужно ли вам развертывание системы на пустом оборудовании, на пустых виртуальных машинах? Или вы хотите сохранить исходные условия работы и настройки существующего оборудования? Это очень важный аспект для работы государственных компаний, поэтому вы должны быть уверены, что вам удастся совершить миграцию и развернуть Ansible на существующей конфигурации. Определите рутинные административные процессы, которые хотите автоматизировать. Выясните, нужно ли вам развертывать на новой системе специфичные приложения и сервисы. Составьте список того, что вы хотите сделать, и расставьте приоритеты.
Затем приступайте к написанию кода сценариев и ролей, которые обеспечат выполнение запланированных вами задач. Объедините их в Projects, логическую коллекцию соответствующих сценариев playbooks. Каждый Project будет относиться к отдельному репозиторию Git или другому репозиторию в зависимости от того, какой менеджер кода вы используете. Вы можете управлять сценариями playbook и каталогами playbook, поместив их вручную в Project Base Path на сервере Tower, либо поместив playbook в любую систему управления исходным кодом (SCM), поддерживаемую Tower, включая Git, Subversion, Mercurial и Red Hat Insights. Внутри одного Project вы можете разместить столько сценариев, сколько захотите. Например, я создал один базовый Project, в котором разместил сценарий для основных элементов RedHat, сценарий для основы Linux, сценарии для остальных базовых показателей. Таким образом, в одном проекте присутствовали самые различные роли и сценарии, которые управлялись из одного Git-репозитория.
Запускайте все эти штуки через командную строку, это хороший способ проверки их работоспособности. Таким образом вы подготовитесь к установке Tower.
Давайте немного поговорим о транскодировании манифеста Puppet, потому что я потратил на это много времени, пока не сообразил, что действительно необходимо сделать.
Как я уже говорил, Puppet хранит все настройки и параметры оборудования в одном длинном манифесте, и в этом манифесте хранится все, что должна делать эта SCM. При переходе вам не нужно запихивать все ваши задачи в один список, вместо этого подумайте о структуре новой системы: ролях, сценариях, тегах, группах и о том, что туда должно войти. Некоторые из автономных элементов сети следует объединить в группы, для которых можно создать сценарии. Более сложные элементы инфраструктуры, которые задействуют большое количество ресурсов, в том числе включают в себя автономные классы, можно объединить в ролях. Перед миграцией вам нужно с этим определиться. Если вы создаете объемные роли или сценарии, которые не помещаются на одном экране, вам следует использовать теги, чтобы иметь возможность захватывать отдельные части инфраструктуры.
18:00
Продолжение будет совсем скоро…
Немного рекламы :)
Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас, оформив заказ или порекомендовав знакомым, облачные 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 евро за копейки?
