Налаштування конвеєра безперервного розгортання для AWS Elastic Beanstalk - javascript.org.ua

AWS

Метою цього посту є налаштування CI/CD пайплайна з використанням Github Actions, щоб кожен коміт до гілки master автоматично запускав набір дій для перевірки коду і розгортання на Elastic Beanstalk, якщо всі перевірки пройшли успішно. Кодова база буде наведена нижче. Спочатку зазначу, що Docker-compose був повністю пояснений у моєму попередньому пості. Крім того, концепції Elastic Beanstalk та eb cli були пояснені в попередньому пості.

[

Розуміння Docker-Compose

Якщо виникає потреба запускати кілька контейнерів для підтримки додатку, docker-compose у більшості випадків буде…

kirtfieldk.medium.com

](/understanding-docker-compose-71663472ecc4?source=post_page-----9d5572975269--------------------------------)

[

Посібник: Розгортання контейнера на AWS Elastic Beanstalk

Я б сказав, що успішне розгортання Docker контейнера на Elastic Beanstalk — це перший крок до чудового…

kirtfieldk.medium.com

](/guid-deploying-container-on-aws-elastic-beanstalk-f586f02c5de5?source=post_page-----9d5572975269--------------------------------)

[

kirtfieldk/BC_API

У цьому API користувач зможе додавати, видаляти, оновлювати та отримувати заявки на стажування від кандидатів.

github.com

](https://github.com/kirtfieldk/BCAPI?source=postpage-----9d5572975269--------------------------------)

Налаштування Github Actions

Github Actions дозволяє нам виконувати дії та команди щоразу, коли спрацьовує певна подія в нашій кодовій базі в віртуальному середовищі. Github Actions налаштовується у файлі .yml в директорії /.github/workflows/.

Перейдіть до особистого репозиторію на Github і натисніть Action. Github пропонує кілька шаблонів для налаштування workflow, що є корисним, якщо нам потрібно виконувати специфічні для мови команди (npm) для тестування або побудови. Однак у цьому випадку нам потрібно лише взаємодіяти з Docker і AWS.

Щоб створити кастомний flow, натисніть set up a workflow yourself і скористайтеся пошуковою панеллю для пошуку корисних дій. Дії на Marketplace є з відкритим кодом і значно зменшують складність. Усі workflow мають структуру з іменем, подією та завданнями.

#NAME  
name: Push images to Dockerhub and deploy on Elastic Beanstalk  
#EVENT  
on:  
 push:  
 branches:  
 - master  
#JOBS  
jobs:  
 build_docker_images:  
 name: build docker images  
 runs-on: [ubuntu-latest]  
 steps:  
 - name: checkout  
 uses: actions/checkout@v2  
 ...

Розділ події активується терміном on і може бути налаштований для запуску при різних подіях Github. Зокрема, цей workflow буде запускатися кожного разу, коли є пуш до гілки master. Далі розділ завдань сигналізується терміном jobs, де кожне job має своє ім’я, наприклад build_docker_images. Кожне завдання працює на певній операційній системі (OS). Крім того, кожне завдання має набір кроків з властивістю name. Ми використовуємо термін uses для підключення відкритих дій, таких як клонування репозиторію в крок або вхід в docker.

Щоб Elastic Beanstalk успішно розгорнув вміст коміту git, перший крок — налаштувати Github Action для побудови і пушу нових образів на DockerHub. Це означає, що нам потрібно увійти в Dockerhub в віртуальному середовищі Github. Ми можемо скористатися ще однією дією з відкритим кодом, docker/[email protected], щоб увійти в наш Docker акаунт. {{secrets.DOCKERHUB_USERNAME}} бере дані з зашифрованих секретів у нашому профілі Github — це фактично змінні середовища (env).

- name: Docker Login  
 uses: docker/[email protected]  
 with:  
 username: ${{secrets.DOCKERHUB_USERNAME}}  
 password: ${{secrets.DOCKERHUB_TOKEN}}  
 logout: true

Тепер, коли у нас є доступ до нашого акаунту на Dockerhub, залишилося лише побудувати і запушити наші образи до їхніх репозиторіїв.
Спробуйте виконати новий коміт в репозиторії з вихідним кодом, щоб ініціювати ще один тест пайплайна.

Сценарій 2: Використання GitHub Actions

З GitHub Actions набагато простіше, спочатку потрібно визначити робочий процес для розгортання у файлі .github/workflows/cd.yml, ось так:

З робочим процесом GitHub Actions, наданим вище, у налаштуваннях вашого репозиторію на GitHub потрібно вказати значення для цих секретів середовища та змінних.

Примітки: З вищенаведеними налаштуваннями, GitHub Actions використовує середовище production коли робочий процес запускається для гілки main, в іншому випадку використовуватиметься середовище staging. Тому необхідно налаштувати відповідне значення для кожного середовища.

Секрети середовища:

AWS_ACCESS_KEY_ID  
AWS_SECRET_ACCESS_KEY  
AWS_REGION

Змінні середовища:

EB_APP: crewcall-api  
EB_ENV: crewcall-api-production  
EB_BUCKET: elasticbeanstalk-[AWS_REGION]-[AWS_ACCOUNT_ID]  
ECR_REGISTRY: [AWS_ACCOUNT_ID].dkr.ecr.[AWS_REGION].amazonaws.com  
ECR_REPOSITORY: crewcall-api-production

Після додавання правильних значень для секретів середовища та змінних, зафіксуйте зміни з визначенням робочого процесу GitHub Actions, а потім пуште їх у цільову гілку (main або develop), щоб запустити робочий процес GitHub Actions.

Інший сценарій

Якщо ви використовуєте альтернативні методи CI/CD, такі як GitlabCI, Jenkins тощо, ви повинні мати можливість легко визначити робочий процес, дотримуючись цих кроків:

Викачати вихідний код.
Встановити awscli та налаштувати облікові дані AWS.
Побудувати Docker-образ і запушити його в AWS ECR.
Стиснути необхідні файли/каталоги додатку (.ebextensions, docker-compose.yml і файл nginx.conf) з унікальним міткою версії, а потім завантажити їх у S3 бакет Elastic Beanstalk.
Створити нову версію додатку з S3 ключем завантаженого файлу.
Ініціювати розгортання з новою створеною версією додатку.

Ось і все для другої частини цієї серії. У наступній частині ми поговоримо про налаштування SSL та DNS.

Перекладено з: Setup Continuous Deployment Pipeline For AWS Elastic Beanstalk