Что такое платформа автоматизации

Автоматизация из первых рук: что такое платформа ServiceNow и как мы ее используем

Привет, Хабр! Продолжаем рассказывать о собственных кейсах, задачах, проблемах и способах их решения. Сегодня поговорим о платформе ServiceNow и о том, как мы с ее помощью управляем инцидентами.

Немного о платформе

Servicenow предоставляет большое количество возможностей, которые можно кастомизировать под свои требования. В первую очередь это:

Мониторинг сервисов и управление запросами.

Управление изменениями и мониторинг изменений.

Почему мы ее выбрали? Причин несколько:

Управление не только ITSM-процессами, но и бизнес-процессами.

PaaS, т. е. нам не нужно поддерживать само решение.

Возможность кастомизации интерфейса и логики под наши требования,

Ориентирование на высокие нагрузки.

Надежность (uptime около 99,95%).

Наличие веб-интерфейса и мобильного приложения.

Интеграцию с большим количеством других платформ и сервисов.

Есть большой маркетплейс приложений.

Есть возможность использовать решения со встроенными нейронными сетями и AI (правда, до этого мы пока так и не дошли).

Зачем нам эта платформа

На момент выбора ServiceNow у нас уже было несколько подходов к реализации собственных продуктов, с помощью которых мы пытались решить вопросы CMDB, автоматизации управления инцидентами и других ITSM-процессов. Но все они требовали ресурсов на разработку и поддержку и все равно не успевали за нашими растущими потребностями. Также мы рассматривали другие решения, но все они не удовлетворяли нашим требованиям по:

минимуму собственных ресурсов на обслуживание инфраструктуры решения.

На одной из конференций мы заметили стенд ServiceNow. Пообщались, познакомились, попробовали, нам понравилось. ServiceNow позволял нам решать широкий спектр задач, привлекая минимум собственных ресурсов. Мы решили использовать его.

Что и как мы делали

Когда мы окончательно решились на внедрение ServiceNow, стало ясно, что интегрировать с платформой придется всю инфраструктуру Quadcode. Ну а чтобы не распылять усилия, действовали пошагово.

В первой итерации решили внедрять:

Процесс управления инцидентами (Incident Management).

Процесс управления событиями (Event Management).

Звучит просто, но «под капотом» было очень много работы.

Сперва нужно было организовать доступ к платформе для всех сотрудников (у нас в группе компаний больше 700 человек). Для удобства мы интегрировали ServiceNow с Google SSO и Active Directory, что упростило задачу идентификации пользователей.

Связь микросервиса с инфраструктурой

Далее мы взялись за CMDB, чтобы выстроить связи между элементами нашей инфраструктуры. Для этого мы интегрировали ServiceNow с внутренними системами инвентаризации, наполнили ее данными, выстроили связи, настроили регулярную синхронизацию. Да, в ServiceNow есть модуль Discovery, который самостоятельно находит новые элементы (железо, хосты и т. д.), определяет связи между ними, но мы пока его не используем из-за ограничений наших внутренних процессов по вводу в эксплуатацию нового оборудования.

Когда фундамент был готов, мы приступили к «реальной работе».

Начали с управления событиями. В этот модуль мы отправили практически все алерты, включая алерты от серверов, контейнеров и приложений. Почему алерты? Модуль управления событиями отлично с ними работает: группирует, схлопывает, привязывает к конкретным элементам CMDB для дальнейшей обработки в других процессах.

Затем мы добавили автоматизации, связав управление событиями с управлением инцидентами. Так нам удалось добиться того, что при поступлении критического алерта по нему автоматически заводится инцидент. Если приходит «нормальный» алерт, свидетельствующий о восстановлении, инцидент автоматически резолвится — участие человека не требуется. Хотя нет: человек может понадобиться для того, чтобы очистить место на сервере.

Хочу отметить важный нюанс. Мы брали функционал «из коробки» и адаптировали к собственным требованиям и текущим реалиям. В частности, поправили назначение приоритетов, добавили дополнительные интеграции с внешними системами, ввели новые сущности и т. д.

Немного про интеграции

В качестве первого примера можно взять Slack, где мы захотели получать уведомления об инцидентах. Но это не всё.

Мы все не любим, когда нас отвлекают от работы, не любим сложные интерфейсы и особенно не любим бюрократию. А ITSM — это все-таки про нее. Учитывая это, мы задумались, как нам сделать так, чтобы взаимодействие сотрудников с процессом не вызвало боль и отторжение и проходило в наиболее дружелюбной манере.

Проблема в том, что при получении уведомления, человеку нужно было переходить в интерфейс ServiceNow для изучения деталей или добавления комментариев. Что само по себе вызывало боль и было неудобно.

Мы решили сделать Slack интерфейсом к ServiceNow. К сожалению, существующие плагины из маркетплейса ServiceNow не позволяли нам решить эту задачу. Поэтому мы сделали свой.

Что мы там сделали:

Отправку уведомлений о новых инцидентах в канал Slack.

Отправку обновлений по инциденту в тред основного уведомления.

Подписку на обновления по инциденту.

Уведомления в каналы ответственных команд о назначении на инцидент.

Регистрацию нового инцидента из любого сообщения в Slack.

Добавление комментариев к инциденту через Slack.

Так мы связали мессенджер с ServiceNow.

Уведомление о новом инциденте

Теперь работать с инцидентами можно как через веб-интерфейс (он, кстати, в ServiceNow называется ServicePortal), так и через Slack. После регистрации нового инцидента в канал в Slack приходит нотификация с кнопкой подписки на обновление инцидента.

Форма заведения нового инцидента

После подписки, в случае если статус инцидента будет меняться или инцидент будет наполняться информацией, в личку в Slack будут приходить соответствующие уведомления от бота, которого мы написали сами. У каждого подобного сообщения есть кнопка для отписки от уведомлений. Для облегчения работы с инцидентами владельцу инцидента приходят специальные нотификации (например, уведомления о назначении владельцем инцидента). В таких сообщениях есть кнопки, например: «Подтверждение начала работы над инцидентом», «Разрешение (resolve) инцидента».

Для облегчения регистрации инцидента мы добавили возможность его заведения через Slack простым кликом по любому сообщению в любом канале. После заведения можно выставить приоритет, статус и добавить другие детали.

Дальше нам нужно было научиться трекать задачи, привязанные к инцидентам.

Бывают ситуации, когда для решения инцидента необходимо выполнить какую-либо большую задачу, а не просто передеплоить сервис. Чтобы меньше отвлекаться на оформление инцидента, мы интегрировались с нашим таск-трекером TargetProcess.

В итоге мы сделали следующее:

В ServiceNow появилась возможность привязать к инциденту задачу из таск-трекера.

ServiceNow сам регулярно проверяет, изменился ли статус у привязанной задачи, и когда задача переходит в статус Done — инцидент резолвится автоматически, без участия человека, с отправкой всех необходимых уведомлений.

Естественно, в ServiceNow существует возможность просмотреть список всех инцидентов, их статус, привязку к пользователям и другие отчеты в различных разрезах. Всё это доступно через ServicePortal.

Список инцидентов на ServicePortal

В целом управление инцидентами и событиями у нас автоматизировано, что, по нашему мнению, оказалось очень удобно для всех — и сотрудников, и компании.

Что дальше

Мы продолжаем автоматизировать наши IT-процессы. В следующих статьях расскажем, как мы автоматизировали в ServiceNow такой процесс, как контроль за изменениями в инфраструктуре (Change management).

Процесс контроля за изменениями — неотъемлемая часть ITSM, ведь подавляющему большинству компаний необходимо знать обо всех проводимых работах. Важно это и для нас, потому что у нас большая распределенная инфраструктура, много команд разработки и микросервисов. И каждый день в прод выкатывается большое количество фич. Поэтому, чтобы добавить прозрачности в этот процесс, мы интегрировали ServiceNow со всеми деплоями и пайплайнами команд, которые есть в нашей компании.

А еще мы собираемся прокачивать мониторинг, изучаем возможность отправки в ServiceNow не только алертов, но и «голых» метрик. Это поможет обнаруживать аномалии и паттерны, которые иначе обнаружить никак нельзя.

Вывод

Всё, что указано выше, — знакомство с платформой ServiceNow. В будущем мы хотим показать ее изнутри, рассказав о том, что она может и какую пользу от этого можно получить. Если у вас есть вопросы по теме первой статьи — задавайте, с удовольствием на них ответим. Ну а мы пока готовим вторую часть — более подробный рассказ о том, как мы делали интеграцию с Slack. Не переключайтесь.

Источник

Какие базовые элементы должна включать платформа автоматизации бизнеса

Большинство компаний из разных сфер бизнеса внедряют передовые IT-решения, понимая, что только так они смогут выжить в условиях жесткой конкуренции на рынке. МЛМ индустрия не стала исключением, учитывая, что многие сетевики активно переходят в онлайн-пространство.

Проблема в том, что далеко не все программные продукты для автоматизации работы заточены под сетевой бизнес. Какие же базовые инструменты должна включать современная CRM-система, призванная упростить жизнь ТОП-лидеров и обычных дистрибьюторов?

Если вам скажут, что автоматизированная система способна без вашего участия ежедневно привлекать сотни кандидатов и регистрировать их в структуру, не верьте. Это происки проектов, которые регистрируют по вашей реферальной ссылке ботов. Чтобы достичь реальных результатов, нужна тщательно продуманная маркетинговая стратегия и грамотное использование онлайн-инструментов.

Обычно в автоматизированный системах, например в Рекруте, есть возможность бесплатно создавать необходимое количество лендингов в простом графическом конструкторе.

Сама по себе посадочная страница бесполезна, если у нее не будет ни одного посетителя.

Привлечь трафик на лендинг можно несколькими проверенными способами. Это и раскрутка профилей в социальных сетях (личных и бизнес-аккаунтов), и продвижение с помощью контент-маркетинга.

Но самыми результативными в этом плане являются контекстная и таргетинговая реклама, с помощью которых можно привлечь первых посетителей уже через несколько дней после запуска кампании.

Процесс создания и развития структуры дистрибьюторов требует решения самых разных задач. Новичков необходимо ознакомить со спецификой МЛМ-бизнеса, дать исчерпывающую информацию о компании, продукте и маркетинг-плане. Затем качественно обучить будущих партнеров методам работы и постоянно мониторить деятельность структуры, помогая членам команды преодолевать трудности.

Функционал автоматизированных систем позволяет в разы упростить реализацию этих задач.

Рекрутинговая автоворонка. Сетевые компании давно взяли на вооружение инструменты, традиционно используемые для повышения конверсии продаж. В том числе маркетинговую воронку, благодаря которой клиенты выстраиваются в очередь.

Это достигается путем постепенного подогрева заинтересованности каждого лида и вовлечения его в бизнес с помощью различных маркетинговых взаимодействий. При этом вы можете контролировать степень “подогрева” кандидатов на каждом этапе и своевременно корректировать стратегию продвижения для повышения конверсии.

При грамотной настройке автоворонки в конечном итоге вы получаете в свою команду мотивированного и полностью готового к работе партнера.

Важно учитывать, что вебинар имеет небольшую масштабируемость: чем больше участников, тем меньше времени организатор может уделить каждому из них.

Видео. В отличие от вебинаров, видеозаписи доступны всем партнерам в любое время суток. К тому же они дают возможность изложить необходимую информацию емко, кратко и по существу, когда не требуется дискуссии.

Вы можете создать полноценный обучающий видео-курс, разделив его на короткие (менее 15 минут) ролики в формате “посмотрел-применил на практике”. В тандеме с домашними заданиями такой подход делает обучение максимально эффективным.

Кроме того, в личном кабинете собирается актуальная информация о деятельности всей структуры и каждого ее члена, включая данные о прохождении новичков по автоворонке, объемы заказанных товаров и продаж, списки должников по уплате комиссий, статистику посещений мероприятий, выполнения домашних заданий и т.д.

Получая необходимые статистические и аналитические данные в режиме реального времени, вы можете контролировать прогресс структурных веток, отслеживать успехи конкретных дистрибьюторов, своевременно помогать отстающим и стимулировать команду к активным действиям.

Источник

Как устроена платформа автоматизации процессов разработки MLOps Platform #CloudMTS

В прошлой статье я рассказывал, как мы строим сервисы для разработчиков ИИ и, в частности, коснулся истории появления нашей MLOps Platform. Сегодня мне хотелось бы показать ее изнутри — поделиться возможностями и показать инструменты под капотом.

Надеюсь, получилось достаточно подробно. А для всего остального есть комментарии: не стесняйтесь задавать вопросы, я обязательно отвечу всем интересующимся. Поехали!

Итак, когда мы построили наш GPU SuperCloud, мы поняли, что у некоторых заказчиков есть спрос на услугу «здесь и сейчас». У кого-то горят сроки реализации проекта. Другим не хватает «инженерных» рук. Поэтому мы решили сделать инструмент, который позволял бы прийти «на все готовое». И построили MLOps Platform.

Задачи и сценарии использования MLOps

По нашим наблюдениям, разработка занимает около 30% жизненного цикла модели. Но только 10% моделей доживает до выпуска на прод. 90% работы (экспериментов и ошибок) отправляется прямиком в garbage collector.

80% времени разработки модели требуют участия инженеров — настроить, автоматизировать и т.д. Это пул задач DevOps/MLOps. Они решаются на протяжении всего жизненного цикла модели вплоть до обслуживания у заказчика. А когда модель развертывается, необходимо версионировать ее, обновлять, следить, чтобы работала исправно и не падала. Платформа упрощает эту работу и берет на себя решение большинства задач.

Как и GPU SuperCloud, платформа работает на графических ускорителях, но в отличие от него, в MLOps Platform есть не только вычислительные ресурсы. Разработчик получает готовые инструменты для работы. Платформа оснащена бесплатными фреймворками, у заказчиков есть возможность подключать платные.

В следующей таблице я перечислил некоторые (но не все) утилиты, относящиеся к тому или иному этапу работы над проектом машинного обучения.

Помимо прочего, пользователь может расширять возможности платформы по своему усмотрению — подключать дополнительные инструменты и фреймворки, будь то библиотеки на любых языках программирования, инструменты консольной строки, контейнеризируемые приложения с web- интерфейсом, или PaaS/SaaS-решения. Кроме того, платформа поддерживает интеграции с рядом K8s-native инструментов, которые могут быть установлены рядом с платформой и настроены под клиента по специальному запросу.

Управление и взаимодействие

Работать с платформой можно разными способами.

Через веб-интерфейс:
В веб-интерфейсе доступны стандартные инструменты — Jupiter Notebook, Jupiter Lab. Вести разработку и следить за использованием ресурсов можно прямо из браузера. Для мониторинга есть Grafana, а за обучением модели можно следить, например, в TensorBoard, так же доступном в платформе. Есть возможность управлять проектами и предоставлять доступ к ним своим коллегам, делиться с ними исходным кодом или готовыми моделями.

С помощью CLI:
Особенно интересно возможности платформы раскрываются в командном интерфейсе. Он предназначен для более опытных разработчиков, которые предпочитают использовать IDE. Иными словами, в процессе написания кода вы можете использовать свою любимую среду разработки, а когда настанет потребность в вычислительных ресурсах (например, чтобы обучить или протестировать модель), одной командой отправить задачу в облако. Когда задача завершится, результат тестирования или работы модели вы увидите на своей рабочей машине.

Пример работы в VS Code

Это позволяет не выходить из зоны комфорта привычной среды разработки, которую вы уже настроили под себя, и при этом пользоваться «ускоренными» облачными ресурсами. Здесь присутствуют те же возможности, что в веб-интерфейсе, и даже больше.

Используя оркестратор пайплайнов:
Утилита интегрирована как в CLI, так и в веб-интерфейс для контроля и предоставления результатов выполнения задач. Она представляет из себя DSL в YAML файлах, в которых с использованием основных концептов платформы строятся как пайплайны, так и интеграции внешних утилит из таблицы выше.

Возможности и инструменты

Подробнее поговорим о том, какие возможности дает платформа. Как я уже говорил выше, она позволяет практически полностью автоматизировать процесс разработки, управление версиями, тестирование, выкатку в прод и другие задачи, с которыми сталкиваются разработчики ИИ-моделей.

Основным инструментом автоматизации является система управления пайплайнами, позволяющая охватить весь жизненный цикл проекта — от сбора данных до развертывания моделей.

Для того, чтобы узнать, как построена интеграция и как работать с конкретными инструментами, читайте нашу документацию.

Сервис позволяет разработчику не тратить время на настройку платформы. Сразу можно проверять гипотезы и решать типовые задачи: заливать датасеты для обучения моделей, подключать исходный код из Git, загружать его с ПК, писать его в веб-интерфейсе или привычной IDE.

Оба наших сервиса нашли своих пользователей

Источник

Представляем Ansible Automation Platform 2

На прошедшей в конце сентября конференции AnsibleFest 2021 мы анонсировали новую, вторую версию платформы автоматизации Ansible, над которой трудились два года. Сегодня мы дадим краткий обзор концептуальных новшеств и полезных ресурсов по Ansible Automation Platform 2, а также начнем чуть подробнее знакомиться с ее новыми функциями (и продолжим это делать в следующих статьях данной серии).

Что нового в Ansible Automation Platform 2

Прежде всего, в этой версии мы стремились улучшить фундаментальные компоненты Ansible Automation Platform и сделать так, чтобы разработчикам автоматизационного контента и администраторам платформ автоматизации было легче и проще вести автоматизацию в масштабе предприятия. Всё, что вы знаете и что вам нравится в сценариях Ansible Playbooks, по большому счету осталось неизменным. Изменилась фактическая реализация того фундамента, на основе которого сценарии автоматизации создаются, управляются и работают в больших комплексных ИТ-средах. Очевидно, что сегодня корпоративная платформа автоматизации должна строиться и поддерживаться с прицелом на контейнерные и гибридные облачные среды.

Итак, что же принципиально нового в Ansible Automation Platform 2?

Во-первых, в рамках СПО-проекта Ansible было проведено отделение контента Ansible от исполнительной части Ansible. Для этого были созданы так называемые Ansible Content Collections, в которых модули, плагины, роли и прочие Ansible-компоненты хранятся в дискретной атомарной форме.

В последнее время мы в основном были заняты тем, что переносили большую часть контента Ansible (модули, плагины) в коллекции, которые живут и поддерживаются отдельно от опенсорсного проекта Ansible. Главный плюс здесь в том, что контент теперь обновляется независимо от самого проекта Ansible. То есть, его можно выпускаться непрерывно и асинхронно, не трогая стабильную версию компонентов Ansible, которые отвечают за выполнение автоматизаций.

Во-вторых, в Ansible Tower плоскость управления (control plane) теперь отделена от плоскости исполнения (execution plane) с переименованием соответствующих компонентов в контроллер автоматизации (automation controller) и среды исполнения автоматизаций (automation execution environments).

Ansible Tower был разделен на два компонента: контроллер автоматизации (плоскость управления) и среды исполнения автоматизации (плоскость исполнения). Это сделано для большей масштабируемости и предсказуемости автоматизаций в масштабе предприятия. Разделив Tower на два компонента, мы получили возможность запускать компоненты исполнения не только на узле управления, но и в другом месте, что важно для автоматизаций в гибридных облачных и контейнерных средах, вроде Red Hat OpenShift. В следующей версии Ansible Automation Platform с номером 2.1 появится еще один важный базисный компонент – automation mesh (считай, та же сервисная mesh-сеть, но для Ansible), который заменит собой изолированные узлы в Ansible Tower. И это уже гораздо интереснее, поскольку открывает новые варианты автоматизации, например, вплоть до edge-систем или прямоних, либо автоматизация в облаке.

В-третьих, новые инструменты, расширяющие возможности тех, кто занимается автоматизацией на предприятии.

Раньше разработка Ansible-контента в значительной степени зависела от человека, который создавал и курировал контент. Новые же инструменты, такие как Навигатор автоматизационного контента (ansible-navigator) и Построитель среды исполнения (ansible-builder), предоставляют больше согласованности при работе с контентом, который разрабатывается на рабочей станции и при этом предназначается для определенного экземпляра контроллера автоматизации. Достигается это за счет применения сред исполнения автоматизации – они гораздо более предсказуемы, переносимы и масштабируемы по сравнению с виртуальными средами (virtualenv) Python, которые используются в старой версии Ansible.

Полезные ресурсы

Ansible Automation Platform 2 предлагает улучшенную архитектуру и ряд новых полезных инструментов для масштабирования автоматизации, сохраняя при этом привычный пользовательский опыт работы с Ansible. Мы хотим дать максимум информации, чтобы вы могли быстро освоить новые функции и начать прорабатывать стратегию миграции на новую платформу Ansible (если это применимо), первая общедоступная версия которой с номером 2.1 выйдет, как ожидается, в конце этого года. Так что следите за базой знаний на портале Red Hat Customer Portal, где будут появляться последние новости и статьи. Кроме того, уже сейчас доступны следующие полезные ресурсы:

Обновленная обзорная страница продукта на сайте ansible.com – поможет узнать больше о новых функциях и компонентах Ansible Automation Platform. Также мы подготовили новое интерактивное руководство по функциям продукта.

Если готовы опробовать новую версию Ansible на практике, то у нас есть для этого интерактивные лабы.

Также рекомендуем бесплатный вебинар «Red Hat Ansible Automation Platform предлагает новые способы автоматизации», который пройдет 2 ноября и затем будет выложен в записи.

При наличии действующей подписки Red Hat можно зайти на страницу раннего доступа на портале Red Hat Customer Portal, где собраны официальные ресурсы по новой версии Ansible, включая официальную документацию по продукту.

Среды исполнения автоматизаций

С распространением ИТ-автоматизации на предприятии растет число сред автоматизации, предназначенных для тех или иных команд и сценариев. И управлять этим средами становится все сложнее, особенно когда процесс начинает масштабироваться до уровня корпоративной ИТ-среды в целом. И поскольку автоматизация теперь является критически важной частью рабочих процессов, Ansible Automation Platform 2 помогает решить эту проблему следующим образом:

Администратор Ansible Automation Platform получает возможность предоставлять и управлять средами исполнения автоматизации (подробнее см. ниже) для различных групп ИТ-специалистов, например, для сетевиков и облачников. Для каждой из таких групп согласно её роли задается лишь соответствующий контент автоматизации, но используется один и тот же базовый образ, а не полноценная отдельная среда автоматизации.

Разработчику автоматизаций гарантируется, что у него на компьютере будет та же среда Ansible, что и в продакшн, чтобы он не волновался по поводу согласованности и зависимостей, а мог сосредоточиться на разработке автоматизационного контента.

Команды автоматизации получают возможность задавать, создавать и обновлять свои среды автоматизации без привлечения администратора платформы автоматизации для внесения в нее изменений.

Создание и распространение сред исполнения выполняется через частный хаб автоматизаций (Private Automation Hub), что обеспечивает согласованность и удобство использования таких сред различными командами.

Сторонние разработчики и партнеры получают возможность создавать свои собственные среды исполнения автоматизации для своих пользователей и заказчиков с помощью недавно выпущенного инструмента командной строки ansible-builder.

Что такое среды исполнения автоматизации

Для успеха ИТ-автоматизации она должна быть согласованной и надежной. У одного из наших заказчиков была отдельная группа администраторов Ansible Automation Platform, которые поддерживали более 40 виртуальных сред для различных команд внутри организации. Эти команды использовали разные версии Ansible, и, например, сетевикам требовались разные наборы контента автоматизации (и зависимости) под конкретные устройства, а разработчики создавали свои собственные среды для тестирования тех или иных приложений.

Для поддержки и сопровождения этих сред не существовало никаких инструментов уровня платформы, и вся надежда была только на документирование каждой конкретной виртуальной среды python. В результате, число сред начало выходить из-под контроля, возник дрейф между девелоперскими и продакшн-средами, и, как следствие, стали расти затраты и сложность автоматизации. При этом, администраторам платформы автоматизации надо было как-то следить за всем этим и поддерживать в рабочем состоянии.

Именно для таких кейсов в Ansible Automation Platform 2 и появились среды исполнения автоматизации. Это атомарные образы, на которых и исполняются все автоматизации. Среды исполнения автоматизации содержат следующие вещи:

Ansible 2.9 или Ansible Core 2.11

Необходимые коллекции Ansible Content Collections

Коллекции python или зависимости по бинарным компонентам

Такой подход позволяет стандартизировать то, как создаются и распространяются среды, в которых выполняется автоматизация. В двух словах, среды исполнения автоматизации – это контейнерные образы, упрощающие работу администраторов платформы Ansible.

Роль сред исполнения автоматизации в Ansible Automation Platform 2.0

Среды исполнения автоматизации – это одна из составляющих концепции Red Hat по разделению плоскости управления и плоскости исполнения с целью сделать платформу более масштабируемой для разработчиков и администраторов, которым нужно, чтобы автоматизации согласованно работали на разных платформах. Поэтому теперь все пользовательские зависимости задаются на этапе разработки автоматизации, а не при ее администрировании или развертывании. Разделение функций исполнения и функций управления позволяет ускорить циклы разработки, а также повысить масштабируемость, надежность и переносимость автоматизаций между вычислительными средами. Среды исполнения автоматизации – это то, благодаря чему Ansible Automation Platform теперь поддерживает распределенные архитектуры и позволяет выполнять автоматизацию в масштабе предприятия.

Что такое ansible-builder

Итак, теперь вы знаете, что такое среды исполнения автоматизации, в чем их преимущества и какова их роль в Ansible Automation Platform 2. Осталось научиться их создавать.

Чтобы разработчики контента и администраторы платформы Ansible могли воспользоваться преимущества этих сред, мы создали инструмент под названием ansible-builder, который создает среды исполнения на основе сведений о зависимостях, которые заданы в различных коллекциях Ansible Content Collection, а также задаются пользователем.

Вместе с Ansible Automation Platform 2 в реестре Red Hat Container Registry появился набор готовых и поддерживаемых сред исполнения автоматизации. Вы можете использовать эти образы в различных целях, они предоставляются в рамках подписки на Ansible Automation Platform. Поддерживаемые среды исполнения автоматизации хостятся в родительском репозитории под названием ansible-automation-platform-20-early-access на сайте registry.access.redhat.com. Сейчас там доступны следующие готовые среды:

Минимальная (ee-minimal-rhel8) – содержит Ansible-2.11 и собрана на базе Red Hat Universal Base Image 8 и python-3.8. Этот образ не содержит коллекций. Его можно использовать в качестве базового для создания сред исполнения автоматизации со своими собственными коллекциями или коллекциями Ansible Certified Content Collections, доступными на сайте Automation Hub.

Поддерживаемая (ee-supported-rhel8) – дефолтный образ, идущий с контроллером автоматизации. Представляет собой минимальный образ, плюс Ansible Content Collections, поддерживаемые Red Hat.

Ansible 2.9 (ee-29-rhel8) – содержит Ansible-2.9 и все необходимые зависимости Ansible. Лучше всего подходит для миграции на Ansible Automation Platform 2.0 с Ansible Automation Platform 1.2.

Для создания своих сред исполнения автоматизации поверх штатных образов Ansible Automation Platform 2 используется Построитель среды исполнения ansible-builder.

Подробнее о нем и о том, как с ним работать том, можно почитать в блоге проекта Ansible и в документации.

Для кого предназначен ansible-builder

Средами исполнения автоматизации пользуются как разработчики Ansible-контента, так и администраторы платформы автоматизации. Поэтому и те, и другие должны понимать, как создавать такие среды с помощью ansible-builder. Их могут создавать разработчики и предоставляться администраторам, или наоборот, но в любом случае, надо помнить, что конечная цель состоит в том, чтобы и на машине разработчика, и в продакшн использовалась одна и та же среда исполнения, чтобы больше не надо было вручную поддерживать много разных виртуальных сред python.

Подводим итоги

Ansible Automation Platform 2 включает множество новых функций, которые дополняют концепцию сред исполнения автоматизации и позволяют сделать, например, следующие вещи:

Создавать и распространять такие среды с использованием частного хаба автоматизации, чтобы обеспечить их согласованность и удобство использования для различных команд в вашей организации.

Предоставить сторонним разработчикам и партнерам возможность создавать собственные среды исполнения автоматизации для своих пользователей и заказчиков с помощью недавно выпущенного инструмента командной строки ansible-builder.

В следующих статьях этой серии мы подробнее расскажем о контроллере автоматизации, о частном хабе, о навигаторе по автоматизационному контенту, а также поделимся соображениями по миграции на Ansible Automation Platform 2.

Источник