Непрерывная интеграция и Непрерывное развертывание создают среду с меньшим количеством ошибок, выполняя тест для всех коммитов в кодовой базе.
Цель этого поста — настроить конвейер CI/CD с помощью Github Actions, чтобы каждая фиксация, сделанная в основной ветке, запускала набор действий для запуска нашего кода и развертывания в Elastic Beanstalk, если все действия пройдены. кодовая база будет ниже. Во-первых, обратите внимание, что Docker-compose было полностью объяснено в моем предыдущем посте. Кроме того, концепции Elastic Beanstalk и eb cli были объяснены в предыдущем посте.
Настройка действий Github
Действия Github позволяют нам выполнять действия и команды каждый раз, когда какой-либо конкретный объект даже срабатывает против нашей кодовой базы в виртуальной среде. Действия Github настраиваются в <file_name>.yml в каталоге /.github/workflows/.
Перейдите в личный репозиторий Github и нажмите Action. Github предлагает несколько шаблонов того, как запустить workflow, это полезно, если нам нужны специфичные для языка команды (npm) для запуска таких событий, как test or builds. Однако в этом случае требуется только взаимодействие с Docker и AWS.
Чтобы создать пользовательскую настройку, flow нажмите set up a workflow yourself и воспользуйтесь строкой поиска для поиска полезных действий. Действия в Marketplace имеют открытый исходный код и значительно снижают сложность. Все рабочие процессы будут иметь структуру имени, события и задания.
#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, на котором оно выполняется. Кроме того, каждое задание имеет набор steps со свойством имени. Мы используем термин uses для извлечения из справки действий с открытым исходным кодом, таких как клонирование репо в шаг или вход в докер.
Чтобы Elastic Beanstalk успешно развернул содержимое коммита git, первым шагом будет настройка действия Github для сборки и отправки новых образов в 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, все, что осталось, — это создать и отправить наши образы в их репозитории. При отправке изображений в 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.
Использование АВС
После того, как наши образы будут постоянно развертываться, нам потребуется доступ к нашей учетной записи Amazon Web Service. Опять же, мы можем использовать другое действие с открытым исходным кодом — 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, enviorment_name, and version_label будет получен в процессе создания приложения Elastic Beanstalk.
Создание эластичного приложения Beanstalk
Чтобы этот процесс работал, нам нужно заранее создать имя приложения и среды. Для запуска используйте команду
eb init -r <region> <application_name>
начать процесс создания приложения.
Единственная конфигурация, которая должна отличаться от стандартной, — это вопрос о платформе. Вместо 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 напоминает файл Docker-compose. Его формат .json, и все его контейнеры перечислены в ключе containerDefinitions. Суть в том, что только образ keithkfield/blog-nginx имеет сопоставление портов и связывает образы client и server.
Теперь, когда файл конфигурации Dockerrun создан, мы можем использовать команду
eb create <enviorment-name>
для создания переменной окружения. Выполнение этой команды ищет инструкции в Dockerrun.aws.json. Во-первых, он отмечает, что AWSEBDockerrunVersion имеет значение 3,, это означает, что это мультиконтейнерное приложение. Elastic beanstalk извлекает все три образа из dockerhub и объединяет их вместе в соответствии с конфигурацией балансировщика нагрузки nginx. Этот процесс занимает некоторое время, но устанавливает базовое приложение, из которого мы можем построить.
Соединить
Теперь, когда мы определили имя приложения и среды, мы можем поместить их на последний шаг нашего рабочего процесса. Остается только получить метку версии. Чтобы получить это, выполните команду
eb appversion
чтобы получить список допустимых версий для использования.
Моя последняя команда в моем рабочем процессе ниже.
Активация потока
Чтобы просто активировать этот поток, отправьте эти изменения в основную ветку. Это запускает действие с именем коммита на вкладке actions. Через несколько минут мы можем проверить консоль Elastic Beanstalk, чтобы получить сгенерированный URL-адрес и посетить сайт.
Успешно, наше приложение здорово! Теперь внесение любых изменений в пользовательский интерфейс и их отправка приведут к развертыванию того же приложения.
Успех!!
Обратите внимание, что это длительный процесс, и обычно требуется несколько часов, чтобы все исправить.
Потребовалось 30 потоков, чтобы мой конвейер CI/CD заработал идеально.
