ansible tower что это
Обрезаем нити: переход с Puppet Enterprise на Ansible Tower. Часть 1
Национальная информационная служба спутниковых данных об окружающей среде (NESDIS) на 35% снизила свои затраты на управление конфигурацией Red Hat Enterprise Linux (RHEL), перейдя с Puppet Enterprise на Ansible Tower. В этом видео категории «как мы это сделали» системный инженер Майкл Рау обосновывает выполнение этой миграции, делится полезными советами и опытом, полученным в результате перехода с одной SCM на другую.
Из этого видео вы узнаете:
Приветствую всех, меня зовут Майкл Рау, я старший системный инженер компании 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 без каких-либо дополнительных действий использует всю имеющуюся информацию о вашей инфраструктуре и оборудовании, виртуальных машинах, серверах и т.д. Она может общаться с вашими RH Satellite серверами, если таковые имеются, и предоставляет вам такую интеграцию, которую вы никогда не получите, работая с 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. При переходе вам не нужно запихивать все ваши задачи в один список, вместо этого подумайте о структуре новой системы: ролях, сценариях, тегах, группах и о том, что туда должно войти. Некоторые из автономных элементов сети следует объединить в группы, для которых можно создать сценарии. Более сложные элементы инфраструктуры, которые задействуют большое количество ресурсов, в том числе включают в себя автономные классы, можно объединить в ролях. Перед миграцией вам нужно с этим определиться. Если вы создаете объемные роли или сценарии, которые не помещаются на одном экране, вам следует использовать теги, чтобы иметь возможность захватывать отдельные части инфраструктуры.
Немного рекламы 🙂
От установки AWX до запуска первого плейбука — настройка централизованного управления Ansible
Количество серверов в нашей инфраструктуре уже перевалило за 800, хотя еще год назад их было около 500. Для работы с этим всем активно используются решения от Red Hat. Про FreeIPA — для организации и управления доступами для Linux-серверов — мы уже писали, сейчас же я хочу затронуть тему управления конфигурациями. Для этих целей у нас юзается Ansible, а с недавних пор к нему добавился AWX — представленное полгода назад решение для централизованного управления плейбуками, расписанием их запусков, управления инвентори, учетными данными для доступа к серверам, а также механизм callback’ов для запроса конфигураций со стороны сервера.
Из-за ряда вещей мы не сразу смогли интегрировать его для работы с нашим основным проектом War Robots, но полей для проверки AWX нашлось предостаточно. Во-первых, в компании ведутся разработки новых проектов, которым нужны dev/stage-окружения и, само собой, production-окружения в перспективе. А недавно к этому добавился еще и проект для внутренней аналитики, которому потребовался полностью новый кластер.
AWX был представлен в сентябре 2017 года — это бесплатный open source проект, распространяющийся под лицензией Apache-2.0 и являющийся апстримом для коммерческого проекта Ansible Tower. В целом, тут тот же принцип, что и у других проектов Red Hat: Red Hat Cloud Forms — ManageIQ; RHEV — Ovirt; Red Hat Identify Managment — FreeIPA и так далее.
Данная статья представляет из себя руководство — от установки AWX до запуска первого плейбука. Но сначала перечислим основные возможности AWX:
Установка
В данный момент поддерживается несколько вариантов установки:
Устанавливать всё будем на Centos 7. Установка Докера также описана в официальной документации, поэтому в статье ее трогать не будем.
Далее нам нужно установить ansible и модуль docker-py. Это можно сделать из pip:
Клонируем репозиторий AWX:
Правим файл inventory. В первую очередь, рекомендую поправить переменную postgres_data_dir. По умолчанию она равна /tmp/pgdocker, но если оставить в таком виде — через некоторое время можно потерять postgresql базу, которую использует AWX.
Если вы хотите использовать внешнюю базу, укажите переменные:
После этого запускаем:
Эта команда запустит выполнение плейбука, который загрузит нужные docker-образы и запустит контейнеры непосредственно с AWX и дополнительными компонентами: Postgres, MemCached, RabbitMQ.
После завершения выполнения плейбука мы должны увидеть следующие контейнеры:
Следить за процессом установки AWX можно следующим образом:
AWX будет доступен по адресу сервера на 80 порту (если вы не поменяли порт в файле inventory).
Логин и пароль по умолчанию:
Использование и примеры
Теперь перейдем непосредственно к AWX, но сначала немного разберемся с тем, как всё организовано.
В первую очередь нас интересует раздел Projects. Projects в терминологии AWX означает набор плейбуков, которые расположены локально на сервере с AWX или в репозитории.
Создадим наш первый Project:
— Name: имя проекта, пускай это будет firstproject.
— Organization: в AWX это сущность, которая используется для разграничения доступа. К Organization могут относиться инвентори, пользователи, группы пользователей, плейбуки. Выберем Default.
— SCM TYPE: тип репозитория, может быть либо локальная директория, либо одна из систем контроля версий на выбор: git, mercurial, subversion.
— SCM Url: урл для репозитория.
— SCM branch/tag/commit: опционально можно указать необходимый branch/tag/commit.
— В поле SCM credentials можно выбрать реквизиты, которые будут использоваться для доступа к репозиторию.
Также можно отметить галочками чекбоксы:
— Clean: удалить все локальные изменения перед обновлением.
— Delete on Update: при обновлении Project’а удалять локальную копию и заново загружать новую копию репозитория.
— Update on Launch: при каждом запуске плейбука из этого Project’а обновлять локальную копию репозитория до актуальной версии. Можно использовать в связке с Delete on Update, но это может привести к более долгому выполнению плейбука, так как каждый раз потребуется ждать окончания синхронизации с репозиторием.
Выберем Clean и Update on Launch. Нажимаем Save и после этого создание нашего первого Project’а завершено.
Перейдем в раздел Projects и для нашего Project’а нажмем на кнопку Start an scm update. Дождемся завершения первой загрузки нашего репозитория (следить за статусом обновления можно в разделе Jobs).
Посмотрим на плейбук, который находится в нашем репозитории. На Хабре есть множество статей, в которых рассказывается об Ансибле и структуре его плейбуков/ролей поэтому подробно расписывать этот момент не станем (вот несколько статей для примера: 1, 2, 3).
Содержимое файла run.yml:
То есть просто запускаем roleawx, предварительно собрав факты. Hosts указываем all, так как указать хосты и хост группы можно в самом AWX.
Дальше интересный момент — содержимое файла roles/requirements.yml:
При синхронизации Project’а AWX сам установит все роли в директорию roles в соответствии с файлом requirements.yml. В данном случае он установит роль roleawx из git репозитория.
Создадим роль с помощью команды:
Структура роли будет такой:
Содержимое файла tasks/main.yml:
Для начала просто выведем сообщение «AWX and Ansible».
Обратите внимание, для того чтобы AWX автоматически установил роли, указанные в файле requirements.yml, в самой роли должен быть корректно сформирован файл meta/main.yml (если вы создали шаблон для роли с помощью ansible-galaxy init, то с meta/main.yml всё хорошо и AWX сможет загрузить эту роль).
Итак, у нас есть репозиторий с плейбуком, есть репозиторий с ролью. А так же у нас есть несколько виртуальных машин с адресами 192.168.10.233, 192.168.10.234 и 192.168.10.239.
Перед тем, как запустить наш плейбук, нам надо сделать так, чтобы Ansible смог попасть с сервера AWX на наши хосты (в нашем случае по SSH). Мы можем указать пароли прямо в переменных внутри плейбука, но это неинтересно. AWX умеет управлять реквизитами для доступа к серверам и мы этим воспользуемся.
Перейдем во вкладку Credentials и нажмем кнопку Add:
— Name: укажем имя для наших реквизитов.
— Credential Type: здесь можно выбрать тип реквизитов. Нас интересует Machine, чтобы использовать их для доступа к нашим серверам. Помимо этого AWX предлагает множество разных типов реквизитов доступа, которые можно использовать для интеграции с различными сервисами, такими как scm (git, svn, mercurial), Red Hat Insight, AWS, Azure, Red Hat Satellite, RHEV, Vmware, OpenStack. А ещё можно создавать свои собственные типы credentials.
— Имя пользователя: выберем root.
— Пароль: оставляем пустым, так как мы будем использовать доступ по ключу.
— PRIVATE KEY PASSPHRASE: пароль для ключа, если ключ создан с паролем. В нашем случае ключ без пароля, поэтому поле оставляем пустым.
— PRIVILEGE ESCALATION METHOD: метод повышения привилегий. Например: sudo, su, pfexec и и т.д.
— PRIVILEGE ESCALATION USERNAME: пользователь, под которым Ansible должен получить привилегии.
— PRIVILEGE ESCALATION PASSWORD: пароль для повышения привилегий.
Поля, связанные с эскалацией привилегий, оставим пустыми, так как мы будем логиниться под root.
Обратите внимание: у ряда полей есть чекбокс Prompt on launch. При активации этого чекбокса соответствующее ему поле будет предложено заполнить вручную при каждом запуске плейбука, с которым ассоциированы данные реквизиты. Таким образом можно не сохранять пароль внутри AWX, а запрашивать его при каждом запуске плейбука.
Итак, мы создали Project и реквизиты для доступа к серверам. Теперь нам необходим Inventory.
Перейдем в раздел Inventory, нажимаем кнопку Add. На выбор будет предложено создать:
— Inventory: обычный Inventory.
— Smart Inventory: позволяет генерировать inventory на основе уже существующих хостов, основываясь на каких-либо параметрах, например, на типе операционной системы.
Создадим обычный Inventory:
— В поле Name указываем имя.
— Выбираем Default Organization.
— В поле Variables можно указать переменные, которые в дальнейшем будут доступны из плейбука.
Остальные вкладки неактивны, пока мы не сохраним наш Inventory.
Сохраняем и возвращаемся в раздел Inventory. Наш Inventory появился в списке. Перейдем в него: после создания верхние вкладки стали активны.
— Permissions: здесь контролируется, кто из пользователей или групп пользователей имеет доступ к Inventory.
— Groups: список хост-групп.
— Hosts: список хостов.
— Sources: список источников для Inventory. Можно выгружать инвентори из AWS/Azure/OpenStack/RHEV и ещё ряда сервисов, можно указать инвентори файл, который находится внутри нашего Project’а или же указать в качестве источника свой собственный скрипт, который генерирует Dynamic Inventory.
— Completed Jobs: список запущенных плейбуков, ассоциированных с хостами из текущего Inventory.
Наш Inventory заполняем руками, так как у нас мало хостов. Перейдем во вкладку Hosts и создадим несколько хостов:
— В поле Host Name можно указать IP-адрес сервера или его DNS-имя.
— В поле Variables попробуем переопределить переменную awxinvvar для одного из наших хостов:
После создания хостов перейдем во вкладку Groups и создадим группы для наших хостов:
Точно так же укажем имя группы и переопределим переменную awxinvvar для одной из групп.
Возвращаемся во вкладку Hosts, выбираем один из хостов из списка, переходим на вкладку Groups для этого хоста и нажмем Associate Group:
На кладке Hosts теперь можно увидеть, в каких группах состоит каждый из хостов:
Кстати, на вкладках Hosts и Groups также доступна кнопка Run command. Это аналог ad-hoc команд в Ansible, которые позволяют выполнить действия на удаленных хостах, без плейбука.
Давайте попробуем. Выберем наши хосты из списка, выберем ключ для доступа по SSH, который создали ранее и попробуем выполнить команду date c помощью модуля shell:
Нажимаем Launch. Нас должно перекинуть на страницу, на которой мы сможем в реальном времени следить за выполнением. Также все запуски плейбуков/ad-hoc команд видны в разделе Jobs.
Наша ad-hoc команда успешно выполнилась.
Давайте теперь попробуем запустить наш плейбук. Перейдем в раздел Templates, нажмем кнопку Add, выберем Job Template.
В терминологии AWX Template — это набор параметров, которые используются для запуска плейбука. В минимальном виде необходимо указать имя шаблона, выбрать project, выбрать playbook, выбрать inventory.
Выглядит создание шаблона так:
Сохраняем проект, возвращаемся в раздел Templates, и запускаем наш плейбук (кнопка в виде ракеты):
Ура, наш плейбук запустился, загрузил нужные роли и успешно отработал. Кстати, на этой же странице вы можете загрузить результат выполнения плейбука. Также имеется возможность поиска по выводу плейбука.
Помните, мы добавили переменную awxinvvar в нескольких местах? Давайте попробуем вывести её в и посмотреть, что получится.
Добавляем в нашу роль в файл tasks/main.yml следующее:
И снова запускаем наш template.
Плейбук видит нашу переменную, которую мы определили в Inventory и корректно её переопределяет в соответствии с приоритетом применения переменных.
Переменные, кстати, можно хранить и в репозитории в директориях host_vars group_vars, если вам так удобнее. Правда, в таком случае они не будут отображаться в Inventory в самом AWX.
Вместо заключения
AWX мы используем уже несколько месяцев и пока что нас всё устраивает. Конечно, так как это новый проект, мы периодически встречаемся с разного рода проблемами (в основном, мелкими багами в интерфейсе), но критичными они не являются и работе не мешают.
Примечание: новые релизы сейчас выходят часто и могут возникнуть проблемы при обновлении. Делайте бэкапы!
Данное руководство написано для ознакомления с базовыми функциями AWX, а если будет интересно — напишем про дополнительный полезный функционал, вроде интеграции с источниками для Dynamic Inventory, механизм Callback’ов и т.д.