Прості контейнери CI / CD в AWS

Я використовую AWS Code Pipeline, Code Build, щоб створити новий контейнер Docker і надіслати його на ECR.

Моя заявка - це проста прямолінійна одноконтейнерна основа. Що може бути меншим підходом тертя, щоб знищити поточний запущений контейнер і запустити новий контейнер з реєстру ECS (вихід Code Build через Code Pipeline).

Я спробував CloudFormation з даними користувачів EC2, користувацькими скриптами з одного боку та CloudFormation з ECS з визначенням завдання з іншого (ще не вдається). Я сильно вважаю, що повинен бути більш очевидний і простіший підхід.

Я б зберігав екземпляри контейнерів ECS (я говорю про хостів Docker - тут мені не подобається терміналогія AWS) та розгортання як дві окремі речі.

Поставте свій стек ECS і працюйте. Ви можете керувати нею через групи CloudFormation та автоматичного масштабування, це добре. Просто подумайте про кластер в якості платформи , де буде розгорнуто на , а не те , що вам потрібно повторне розгортання .

Тоді для компакт-дисків найпростішим методом на сьогодні є оновлення визначення служби для використання нового визначення завдання та дозволити прослуховуванню ECS оновити контейнери для вас.

Кожен раз, коли він починає завдання, ECS запускатиме докерне зображення: тег, навіть якщо у нього є місцеве зображення, щоб переконатися, що в ньому є остання версія цього зображення: тег. Тому тег зображення, який ви використовуєте, насправді не має значення (не потрібно змінювати тег у кожній збірці).

Це означає, що ви можете створювати мімідж: останній раз і знову, щоб легко розгорнути його.

Вам потрібно визначити завдання, де зображення = myimage: найновіше. Створіть сервіс із цим визначенням завдання, і кожного разу, коли ECS запустить завдання (екземпляр вашої служби), це буде найсвіжіший "myimage: latest", який ви створили.

Звідси у головоломки вам не вистачає лише однієї частини, з CodeDeploy ви можете зателефонувати щось, можливо, лямбда-функція, щоб створити нову редакцію свого завдання та оновити службу. ECS автоматично створить нові завдання для цієї версії та видаліть старі завдання.

Приклад:

Припустимо, ви створили сервіс під назвою MyService. Що ви налаштували цю службу для виконання двох завдань для визначення завдання MyTaskDefinition: 1 (версія 1). У цьому визначенні завдання у вас є одне визначення контейнера, для якого зображення встановлено "myimage: latest".

1. Вчора ви створили myimage: останній, який мав ідентифікатор (SHA) 365d8f7bf565.
2. Ваш контейнер-екземпляр ABC виконує завдання з назвою MyTaskDefinition- 1 -containerName-someLongId. коли ви оглядаєте цей контейнер, він виконує зображення "sha256: 365d8f7bf565 .........."
3. Ваш інший екземпляр контейнера DEF виконує ще одне завдання. Він має схожу назву (відрізняються лише ідентифікатори), але він має те саме зображення.
4. Ви натискаєте зміну на репо.
5. CodePipeline підбирає цю зміну, створює та публікує зображення в ECR.
6. Цей новий образ Докера також мімідж: останній, але його ідентифікатор (SHA) - f7ec5e54ac96
7. Тепер вам потрібно додати крок до свого конвеєра, щоб використовувати функції Lambda та AWS NodeJS SDK, щоб зробити кілька дзвінків у ваш кластер:
   1. Створіть нове визначення завдання (яке буде точно таким же, як і раніше). Це буде MyTaskDefinition: 2
   2. Оновіть MyService, щоб використовувати MyTaskDefinition: 2 (замість 1)
8. ECS створить нові завдання. Імена контейнерів будуть MyTaskDefinition- 2 -containerName-someLongId. Перевіряючи ці контейнери, ви побачите, що вони працюватимуть "sha256: f7ec5e54ac96 .......". Можливо, у вас буде 2 завдання на екземпляр контейнера ABC, можливо, вони будуть розпорошені (це залежить від конфігурації вашої служби)
9. Через деякий час ECS видалить старе завдання MyTaskDefinition-1-containerName-someLongId з ABC та DEF.

Примітка. Насправді вам не потрібно створювати нове визначення завдання. Якщо ви хочете, ви можете замість цього отримати список завдань служби та вручну зупинити їх по черзі. Ви повинні зачекати, коли ECS перезапустить завдання перед тим, як зупинити новий (тобто: зупиніть перший контейнер, зачекайте, коли ECS замінить його, зупиніть другий контейнер). Коли ECS перезапустить контейнер, він захопить найсвіжіший мімідж: останній побудований, як було пояснено раніше. Я просто думаю, що створити нове визначення завдання простіше і менш схильним до помилок (не потрібно логіки чекати і перевіряти, ECS буде обробляти постійне оновлення для вас, якщо у вас є нове визначення завдання).

Для простого описаного випадку використання я б запропонував перевірити Elastic Beanstalk для Docker, це не мінімальне рішення, як, наприклад, використання ECS, але ви можете скористатися автоматичними керованими та налаштованими службами, такими як ELB, EC2 AutoScale, моніторинг стану здоров’я та багато іншого.

Підсумок на високому рівні:

1. Налаштуйте Elastic Beanstalk для використання конкретних міток зображення: тестовано
2. Використовуйте Code Pipeline / Build для створення, тестування та просування тегів "тестовано"
3. Тригер еластичного розгортання Beanstalk, який підтягуватиме рекламоване зображення: тестується для всіх примірників, доступні різні стратегії розгортання.

Цей підхід, заснований на повторному використанні того ж тегу, альтернативним підходом буде генерування тегу з ідентифікатором збірки, наприклад myimage: тестується-42, для цього потрібно буде оновлювати Elastic Beanstalk кожен раз новим тегом, але надавати більш детальний контроль при розгорнутій версії.

Я другий еластичний квасоля за своєю простотою; налаштувати та розгорнути це дуже просто.

Якщо ви знайомі з docker-compose, іншим підходом було б визначити docker-compose.yml і безпосередньо розгорнути на ECS з ecs-cli.