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

В этом посте мы рассмотрим три примера автоматизации DevOps. Они используют Jira, Jenkins и Docker, но концепции рабочих процессов, запускаемых событиями, применимы к любым используемым вами инструментам.

Создавайте ресурсы (и прозрачность) из рабочих заданий

Прозрачность является ключом к открытому общению внутри команд DevOps. Представьте себе мир, в котором любой руководитель проекта может видеть и создавать информацию в удобном для бизнеса контексте. Например, если вы потратите некоторое время на синхронизацию ваших конвейеров Jenkins с JIRA, это даст PM представление в режиме реального времени о заданиях развертывания EC2 и предотвратит шквал проверок статуса. Следующие шаги превратят Jira из 2D-цифровой пробковой доски в интерфейс управления миссией, отдавая заказы и получая квитанции. Вы можете использовать аналогичный подход с вашими инструментами управления проектами и сборки.

Чтобы настроить автоматизацию, подготовьте свой проект Jira для обмена информацией с Jenkins через веб-перехватчик. Предположим, ваш проект представляет собой миграцию приложения, и вам необходимо повторно предоставлять набор сервисов AWS для тестирования. Вместо ручной загрузки скриптов CloudFormation добавьте настраиваемые поля в консоль конфигурации Issue, которые сообщат Jenkins, где найти эти скрипты и какие параметры для них предоставить. Затем создайте поле Build Status, которое будет контролироваться обновлениями от Jenkins. Убедитесь, что эти новые поля теперь отображаются в ваших заявках. Затем в меню «Дополнительная конфигурация» создайте соединение с Jenkins, подключив его сервер к форме конфигурации Webhooks. Выберите «Создано» и «Обновлено» в качестве триггеров событий.

Теперь очередь Дженкинса. Мы собираемся настроить его для получения параметров сборки и передачи статусов сборки. Мы предполагаем, что конвейеры уже построены, и нам просто нужно заставить их работать с веб-перехватчиком Jira. Для этого установите следующие плагины и настройте их для подключения к вашей учетной записи Jira, а точнее префикс проекта для доски миграции приложений:

  • Джира
  • Шаги пайплайна Jira
  • Плагин триггеров Jira
  • Плагин jira-ext

Это позволит Jenkins прослушивать соответствующие обновления от Jira, а также предоставлять функциональные возможности для связи с инициирующим билетом из сборки.

Теперь, когда оба приложения привязаны друг к другу, обновите конвейер, чтобы он обрабатывал полезную нагрузку Jira и передал ее в сборку. Напишите фильтр JQL в конфигурации конвейера, чтобы его можно было активировать только событиями веб-перехватчика «Создать» и «Обновить». Затем сопоставьте расположение шаблона CloudFormation и другие параметры как настраиваемые поля и убедитесь, что ключ заявки Jira также захвачен как поле пути атрибута задачи. Шаблон и параметр CloudFormation теперь доступны в качестве переменных среды для управления этой сборкой. Кроме того, значение ключа заявки доступно для новых функций, предоставляемых подключаемыми модулями Jira, для создания обновлений статуса и регистрации информации непосредственно в заявке для просмотра всеми заинтересованными сторонами.

Подобная автоматизация может помочь вам выполнять меньше повторяющейся работы. Требуются некоторые усилия, чтобы настроить и поддерживать соединения между вашими инструментами. Чтобы упростить утомительные рабочие процессы и найти примеры проектов, обязательно ознакомьтесь с инструментом автоматизации, управляемым событиями, который создает Puppet.

Оптимизируйте свои сборки Docker с помощью динамических переменных

Docker, как и CloudFormation, — это мощный инструмент для восстановления приложений и инфраструктуры по требованию. Здесь мы собираемся расширить возможности параметризации в конвейерных сборках на основе Docker. В идеале вы можете транспортировать контейнер Docker как есть в любую среду. Однако на практике будут отличия. Возможно, у вас есть разные конечные точки базы данных для разработки, тестирования и производства. Если интеграционные тесты вашего приложения полагаются на правильную конечную точку для каждой среды, мы можем использовать параметры сборки, чтобы ваши контейнеры Docker не зависели от среды.

Вот как вы можете маршрутизировать параметры для сборки тестовой среды:

pipeline {
    // ...
    agent {
        dockerfile {
            filename "my-dockerfile"
            label "my-docker-label"
            args "-v DB_URL= ${env.DB_URL}" // set to 'test_db.example.com'
        }
    }
    // ...
}

Предположим, мы передаем контролируемый набор параметров из триггерного действия в Jenkins, как в предыдущем примере. Мы запускаем тестовый конвейер, поэтому Jenkins получил конечные точки базы данных как DB_URL=test_db.example.com из триггерного действия. Мы можем получить доступ к этому значению в нашем Jenkinsfile из объекта env.

Теперь мы должны передать значение DB_URL в сборку Docker. Начнем с объявления агента сборки. Чтобы максимально эффективно использовать программу Docker вашей команды, подключите настраиваемый файл Dockerfile, объявив свой пользовательский файл Dockerfile своим агентом. Затем мы должны передать переменную окружения в виде интерполированной строки в аргументы: args “-v DB_URL= ${env.DB_URL}”. В своем пользовательском Dockerfile сопоставьте инструкцию DB_URL ARG с инструкцией ENV. Теперь этот URL-адрес будет доступен как переменная в ваших контейнерных тестовых сценариях без необходимости вообще изменять файл.

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

Сделайте тестирование рутиной внутри вашей контейнерной сборки

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

В этом примере давайте представим, что вы создаете небольшое приложение Node, которое читает и записывает в MongoDB. Будет легко представить стек в файле docker-compose. Файлы Docker-compose — это сценарии YAML, которые сообщают Docker, что вводить в сборку Dockerfile. В этом случае мы создадим образ Node.js в Dockerfile и объявим две службы в нашем docker-compose.yml: службу API и экземпляр MondoDB. Сохраните этот файл docker-compose и Dockerfile Node.js, чтобы встроить его в подкаталог integration-test в репозитории проекта.

Теперь вы можете выполнить некоторые проверки работоспособности, запустив docker-compose для каталога integration-test, запустив действия Postman для локального API и проверив MongoDB на любом порту, к которому вы его предоставили. Что еще более важно, мы всего в нескольких коротких файлах от автоматического тестирования полной интегрированной сборки. Создайте файл index.js со своими тестовыми сценариями. Направьте свои вызовы API и операции с базой данных на имена, которые вы дали своим службам в файле docker-compose, и верните результаты в контейнере. Наконец, создайте сценарий оболочки для управления контейнерами докеров и вывода результатов теста. Теперь вы можете автоматически запускать тесты в других конвейерах CI/CD, контролировать их версии и добавлять дополнительные сервисы или тесты по мере развития бизнес-логики.

Быстрое развертывание рабочих процессов, управляемых событиями

Как видите, ваши рабочие процессы более эффективны, когда вы создаете достаточно накладных расходов для масштабирования поведения, запускаемого событиями. Мы видели, как динамическая организация сборок Docker из Jira может запустить расширяемые программы тестирования в Jenkins. Хорошим принципом оптимизации, который следует рассмотреть сейчас, является итерация. Некоторые из этих интеграций могут работать или давать сбои для ваших нужд. Возможность замены и переназначения ваших сервисов без отключения конвейеров обеспечивает бесперебойную работу ваших рабочих процессов DevOps.

Relay by Puppet стремится управлять этим за вас, автоматизируя модульные рабочие процессы, управляемые событиями. Если одна из интеграций перестанет удовлетворять ваши потребности, вы можете поменять инструменты или перенаправить рабочий процесс и автоматизировать свою среду DevOps.