AWS
Метою цього посту є налаштування CI/CD pipeline за допомогою 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. Кожен job має свою операційну систему. Крім того, кожен job має набір steps з властивістю імені. Ми використовуємо термін uses, щоб підключати допомогу відкритих джерел, таких як клонування репозиторію в крок або вхід у docker.
Для того, щоб Elastic Beanstalk успішно розгорнув контент git-коміту, перший крок — це налаштувати наш Github Action для побудови та пушу нових образів у DockerHub. Це означає, що нам потрібно увійти до Dockerhub у віртуальному середовищі Github. Ми можемо використовувати ще одну дію спільноти, docker/[email protected], для входу в наш Docker акаунт. {{secrets.DOCKERHUB_USERNAME}} витягує дані з зашифрованих секретів у нашому профілі Github — фактично це змінні середовища.
- name: Docker Login
uses: docker/[email protected]
with:
username: ${{secrets.DOCKERHUB_USERNAME}}
password: ${{secrets.DOCKERHUB_TOKEN}}
logout: true
Тепер, коли ми отримали доступ до нашого акаунту Dockerhub, все, що залишається — це побудувати і надіслати наші образи в їх репозиторії.
Коли ви відправляєте образи до Dockerhub, наступні команди побудують, тегуватимуть і надішлють образ, створений з файлу Dockerfile в директорії.
docker build -t keithkfield/blog-server .
docker tag keithkfield/blog-server keithkfield/blog-server:latest
docker push keithkfield/blog-server:latest
Ці три команди повинні бути єдиними, які вам знадобляться для того, щоб відправити образи, побудовані з нашого вихідного коду, на Dockerhub.
- name: Build Server image
run: docker build -t keithkfield/blog-server -f
./Server/Dockerfile ./Server
- name: Tag our Image
run: docker tag keithkfield/blog-server
keithkfield/blog-server:latest
- name: Push to dockerhub
run: docker push keithkfield/blog-server
Тепер просто повторіть ці три кроки для контейнерів client та nginx.
Використання AWS
Після того, як ми налаштуємо безперервне розгортання наших образів, нам знадобиться доступ до нашого облікового запису в Amazon Web Services. Знову ж, ми можемо використати ще одну дію з відкритим вихідним кодом — einaregilsson/beanstalk-seploy@v14.
- name: Deploy to EB
uses: einaregilsson/beanstalk-deploy@v14
with:
aws_access_key: ${{ secrets.AWS_ACCESS_KEY }}
aws_secret_key: ${{ secrets.AWS_ACCESS_SECRET_KEY }}
application_name: medium-compose-series
environment_name: Mediumblogseries-dev
version_label: "app-cbe0-210131_121135"
region: us-east-1
Ми витягуємо aws_access_key і aws_secret_key з наших зашифрованих секретів. application_name, environment_name і version_label будуть зібрані під час процесу створення програми в Elastic Beanstalk.
Створення програми Elastic Beanstalk
Для того, щоб цей процес працював, ми повинні заздалегідь створити ім’я програми та ім’я середовища. Для початку скористайтеся командою
eb init -r
щоб розпочати процес створення програми.
Процес створення програми
Єдине налаштування, яке потрібно змінити, це питання про платформу. Замість за замовчуванням 1, ця програма є Multi-container Docker, тому виберіть 2.
Select a platform branch.
1) Docker running on 64bit Amazon Linux 2
2) Multi-container Docker running on 64bit Amazon Linux
3) Docker running on 64bit Amazon Linux
Після виконання цієї команди init буде створено директорію .elasticbeanstalk з файлом config.yml. У AWS файл Dockerrun.aws.json визначає, як мають працювати кілька контейнерів в межах програми.
Файл Dockerrun.aws.json
Файл Dockerrun.aws.json нагадує файл Docker-compose. Його формат — .json, і він перелічує всі контейнери в ключі containerDefinitions. Головна ідея полягає в тому, що лише образ keithkfield/blog-nginx має відображення портів, і він зв’язує образи client і server.
Тепер, коли файл конфігурації Dockerrun готовий, ми можемо скористатися командою
eb create
щоб створити змінну середовища. Виконуючи цю команду, система шукає інструкції в Dockerrun.aws.json. Спочатку вона зазначає, що AWSEBDockerrunVersion встановлено на 3, що означає, що це багатоконтейнерна програма. Elastic Beanstalk витягує всі три образи з Dockerhub і з’єднує їх через конфігурацію навантажувача балансування nginx. Цей процес займає деякий час, але він створює базову програму, з якої можна працювати.
Збірка разом
Тепер, коли ми визначили ім’я програми та ім’я середовища, ми можемо вставити їх у останній крок нашого робочого процесу. Залишається лише отримати мітку версії. Для цього виконайте команду
eb appversion
щоб отримати список допустимих версій для використання.
Моя фінальна команда в робочому процесі виглядає ось так:
Активація потоку
Щоб активувати цей потік, просто відправте ці зміни в гілку master. Це ініціює дію з назвою коміту в вкладці actions.
Через кілька хвилин ми можемо перевірити консоль Elastic Beanstalk, щоб отримати згенероване посилання і відвідати сайт.
Початковий пуш
З успіхом наша програма працює! Тепер будь-які зміни в UI і їх пуш призведуть до розгортання тієї ж програми.
Успіх!!
Зазначте, що це довгий процес, і зазвичай займає кілька годин, щоб все налаштувати правильно.
Мені знадобилося 30 потоків, щоб налаштувати мою CI/CD pipeline і отримати її ідеальну роботу.
Перекладено з: CI/CD — Docker-Compose, Elastic Beanstalk, and Github Actions