Быстрое начало работы с Gitlab CI/CD: пайплайн для веб-сайта на AWS S3 Bucket

Kate

Administrator
Команда форума
Перевели статью о создании пайплайна для развертывания статического веб-сайта на AWS S3 Bucket на примере Gitlab CI/CD, чтобы быстро вникнуть в основы технологии и начать применять ее в работе. В статье рассматриваются базовые концепции CI и CD, а также этапы CI/CD-пайплайна.

901e4585401e38081db3c6c1cca63682.png

От автора​

Мне повезло быть частью некоторых профессиональных команд, каждая из которых применяла несколько DevOps практик. И меня поразило то, как качество кода, скорость разработки и позитивный настрой команды коррелируют с CI/CD-пайплайном.

По моему мнению, зрелость пайплайна может служить прекрасным показателем опытности разработчика, качества кода и эффективности всей команды.

Во многих случаях, которые я наблюдал, пайплайны были выстроены либо DevOps-инженером, либо отдельной DevOps-командой. Да и последний отчет State of CD 2022 продемонстрировал, что только 22% разработчиков создают пайплайны.

Моя цель — увеличить это число: помочь разработчикам взять на себя ответственность за пайплайны, выстраивать непрерывный процесс доставки и создавать качественный код.

В статье рассматриваются фундаментальные концепции CI и CD.

Что такое CI/CD?​

Многие бизнесы применяют фреймворки Agile, так как они позволяют менять приоритеты и повышать скорость доставки. Кроме всего прочего, такой подход улучшает атмосферу в команде и помогает увеличить прибыль.

Если ваша компания следует по пути Agile, то принятие культуры, философии и практик DevOps станет ее большим преимуществом.

Модное словечко последних десятилетий, DevOps сегодня считается настоящим стандартом индустрии. CI/CD — это практика DevOps, которая помогает разработчикам ПО доставлять изменения в коде с высокой частотой и надежностью.

«Быстрый билд, быстрый тест, быстрый фейл»

При наличии автоматизированных тестов команды тяготеют к общей автоматизации задач и частым, надежным поставкам кода. Создание CI/CD-пайплайна в этом случае может привести к нескольким преимуществам.

Бизнес выигрывает от снижения затрат и повышения производительности, ускорения Time to Market и адаптации к изменяющимся требованиям рынка.

Команда выигрывает от быстрой обратной связи, улучшения эффективности разработки, уменьшения количества бутылочных горлышек и повышения уровня вовлеченности и удовлетворенности сотрудников.

Фазы CI и CD​

79efc6acf3595fbdfde4443ba3814736.jpg

CI — непрерывная интеграция. Непрерывная интеграция позволяет по много раз в день коммитить изменения в основную ветку вашей кодовой базы.

Учитывая ограниченные когнитивные способности человека, CI стимулирует разработчиков вносить в код небольшие изменения, которые легче рассмотреть, покрыть автоматическими тестами и часто релизить.

Это позволяет избежать напряженных и переполненных merge conflict-ами дней подготовки к релизу с тоннами ручного тестирования.

CD — непрерывная доставка. Следующий шаг после CI позволяет гарантировать, что кодовая база постоянно готова к деплою, а задеплоить ее можно одним нажатием кнопки.

При этом неважно, с чем вы работаете: с масштабной распределенной системой, сложной производственной средой и т. д. Ключевой момент — автоматизация.

CD — непрерывное развертывание. Последний этап зрелого CI/CD-пайплайна, где все изменения в коде автоматически развертываются в продакшн без ручного вмешательства.

Само собой, для этого требуется большое количество хорошо продуманных автоматических тестов. State of CD 2022 утверждает, что «47% разработчиков применяют CI или СD, но только один из пяти использует оба подхода для автоматизации сборки, тестирования и развертывания кода».

Книга Accelerate подводит итоги многолетнего исследования с использованием отчетов State of DevOps, основанных на 23 000 наборов данных компаний по всему миру. Как видите, высокопроизводительные команды могут деплоить по требованию (или несколько раз в день).

232da02b8c9194aad1305b64345ad88e.jpg

Этапы CI/CD-пайплайна​

7a18cc0c9b011b59f993070577049fe5.jpg

Стадия исходного кода — здесь запускается пайплайн. Обычно это происходит после изменений в Git-репозитории, которые проявляются в открытии нового Pull Request-а или в пуше в ветку. Другой способ заключается в настройке инструментария CI/CD для запуска пайплайна через автоматическое расписание или после запуска другого пайплайна.

Стадия сборки — этап, в процессе которого происходит проверка и сборка кода. Здесь особенно полезны такие инструменты, как Docker: они обеспечивают однородную среду.

Стадия тестирования — CI/CD невозможно представить без автоматизированных тестов. В конце концов, все хотят быть уверены, что изменения в коде не сломают продакшн.

Стадия развертывания — на последнем этапе (после успешного прохождения всех предыдущих стадий) код можно развернуть в выбранной среде.

Пример с Gitlab​

В этом примере будет использован Gitlab CI/CD, однако концепции аналогичны и для остальных инструментов, поэтому их можно применить к другим сервисам хостинга репозиториев.

Существует несколько инструментов CI/CD, например всемирно известный Jenkins. Этот инструмент требует некоторой настройки и конфигурации, в то время как другие поставляются сервисами хостинга репозиториев (такими как GitHub Actions и Bitbucket Pipelines) с предварительной настройкой.

Поэтому если ваш код размещен на Gitlab, то легче всего использовать Gitlab CI/CD, поскольку код и управление CI/CD находятся на одной платформе.

Как все это может работать без настроек?

Для ответа на этот вопрос стоит немного погрузиться в архитектуру Gitlab, а именно — в инстансы и раннеры. Инстансы хранят код приложения и конфигурации пайплайна. Раннеры выступают в качестве агентов, выполняющих операции в пайплайнах.

В Gitlab каждый инстанс может быть подключен к одному или нескольким раннерам.

e685f4b4d2943acbf42f4c6966f29a06.jpg

Gitlab.com — это управляемый инстанс с несколькими раннерами, которые сам Gitlab и поддерживает. Следовательно, если вы используете этот инстанс, то получаете все необходимое из коробки.

Приступим к работе​

Gitlab предлагает несколько шаблонов при создании нового проекта. Конфигурация пайплайна Gitlab CI/CD по умолчанию находится в файле .gitlab-ci.yml в корневом каталоге.

e47788b15fb1a1469b721e17536102a9.jpg

Предположим, мы хотим создать простой пайплайн, который проверяет: написан, протестирован и развернут ли код. Вот несколько концепций и терминов для ознакомления перед началом работы.

Пайплайн (Pipeline)​

Пайплайн — это набор заданий, разделенных на этапы. Gitlab предлагает различные типы пайплайнов, например parent-child или multi-project. Полный список см. здесь.

Этап (Stage)​

Этап — это шаг в пайплайне, предоставляющий информацию о том, какие задания запускать (сборка, тестирование и т. д.). Один этап может включать одно или несколько заданий.

Задание (Job)​

Задание — основной блок пайплайна (компиляция, линтинг и т. д.). Для каждого задания должны быть определены name и script. После выполнения всех заданий на этапе пайплайн переходит к следующему.

Теперь — к коду​

Выстраиваем пайплайн Gitlab CI/CD, который собирает, тестирует и разворачивает статический веб-сайт в AWS S3 Bucket.

Для начала создадим новый .gitlab-ci.yml

1. Определим переменные

variables: # variabiles definitions for easier reuse of values.
CI_NODE_IMAGE: "node:16.13.2"
2. Определим этапы

# Pipeline stages
stages:
- install
- build
- test
- deploy
3. Определим задания на каждом этапе

#install job definition
install:
stage: install
image: "$CI_NODE_IMAGE" # variable reference
script: # Shell script that is executed by the runner.
- npm ci
cache: # List of files that should be cached between subsequent runs.
key:
files:
- package.json
- package-lock.json
paths: # directories to cache
- node_modules

# Build Job definition
build:
stage: build
image: $CI_NODE_IMAGE
script:
- npm run build
artifacts: # list of files and directories that are attached to the job
paths:
- dist/
cache:
key:
files:
- package.json
- package-lock.json
paths:
- node_modules
policy: pull

# Test Job definition
test:
stage: test
image: $CI_NODE_IMAGE
script:
- npm run test


# Deploy Job definition
deploy:
stage: deploy
image: registry.gitlab.com/gitlab-org/cloud-deploy/aws-base:latest # a Docker provided by GitLab that includes the AWS CLI
script:
- aws s3 cp --recursive dist s3://bucket-name # copies the dist folder to an aws s3 bucket
На этом все, спасибо за внимание.
 
Сверху