Автоматическое развертывание приложения из ветки git на s3

Этот пост был первоначально опубликовано на

Непрерывное развертывание (CD) — это подход к разработке программного обеспечения, при котором функциональные возможности программного обеспечения часто предоставляются посредством автоматизированного развертывания.

Одна из «последних» тенденций в мире ИТ (точнее, в DevOps часть) есть непрерывное развертывание а также непрерывная поставка. Google Тренды хорошо это иллюстрирует:

http://snoozy.ninja/images/cd/google_trends.png

Процесс адаптации проекта к этой методологии требует изменений, связанных как с самим кодом, так и с организацией работы. Автоматизация и упрощение этапов поставки ПО — очень важный этап. Сегодня я хотел бы показать вам, как легко настроить и запустить автоматический развертывание приложения, написанного с использованием Посмотреть интерфейс командной строки.

Одним из этапов процесса разработки программного обеспечения является код обзор. На этом этапе человек, не являющийся автором кода, просматривает его и проверяет, нет ли в коде ошибок. Во время этого процесса, особенно при создании веб-приложения, может быть очень полезно запустить новую версию приложения, чтобы увидеть, как оно работает и выглядит.

Конечно, вы можете скачать код, который был добавлен в запрос на вытягивание и запустить его самостоятельно, но очень часто запуск приложения не относится к тривиальным процессам (может оказаться, например, что нам нужно запустить какие-то другие сервисы). Поэтому лучше полностью автоматизировать этот процесс. Благодаря этому каждый ответвляться будет адрес, по которому будет доступна его собранная и рабочая версия.

изображение

Процесс автоматизации очень тесно связан с инструментами, которые мы используем для тестирования и создания нашего приложения. В приведенном ниже примере я решил использовать пойти к раковине а также Амазонка s3. Конечно, вы можете заменить эти элементы другими сервисами. Любой КИ инструмент как Трэвис, Дженкинс может заменить gitlab. Вместо S3 можно использовать любой хостинг (рекомендую гитхаб-страницы которым можно пользоваться бесплатно).

Наш процесс будет выглядеть так:

  • Разработчик создает новую ветку локально и вносит изменения в код.
  • Когда новая ветка «проталкивается» в наш репозиторий, наш конвейер начинает работать. Pipeline соберет и развернет текущую версию на s3.
  • В процессе проверки после каждого обновления нашей ветки (или пулреквеста) новая версия будет добавляться автоматически. Старая версия останется.
  • Когда ветвь удаляется или перенаправляется на мастер, наш конвейер удалит ненужную пробную версию.
Создание нового ведра

Первым шагом будет создание места, куда мы будем «загружать» новые версии нашего приложения. Поскольку мое приложение — простое приложение, созданное с помощью VueCli, мы можем использовать s3. Если вы не знаете, что такое Amazon S3 (Amazon Simple Storage Service), вам достаточно знать, что это простой сервис, позволяющий хранить файлы в облаке. Он имеет очень простой в использовании веб-интерфейс, который позволяет хранить и управлять своими данными. Объем хранимых данных теоретически неограничен. Однако вы должны знать, что все файлы будут общедоступны. Вы сможете просмотреть любой файл, добавленный в S3. Если у вас есть какие-то «секреты» в вашем коде, не используйте s3 для размещения вашего приложения!

Начнем с создания нового «ковша». Ведро — это не что иное, как место, где будет храниться наше приложение. Имя корзины будет определять адрес, по которому будет доступно наше приложение. Помните, что если вы хотите использовать другой домен, вам нужно будет назвать свою корзину точно так же, как имя вашего домена. В противном случае у вас возникнут проблемы, если вы захотите использовать Маршрут53 (Это еще один сервис aws, который отвечает за dns). Создание ведра мы можем сделать по этой ссылке. Просто нажмите «Создать новый сегмент» и введите его имя. Имя корзины должно быть доступно глобально (это связано с тем, как работает S3).

http://snoozy.ninja/images/cd/new_bucket.png

Окончательная версия нашего ведра должна выглядеть так:

http://snoozy.ninja/images/cd/final_bucket.png

Теперь нам нужно сделать еще одну вещь — мы должны включить опцию, которая позволит нам размещать наши файлы. Это очень просто и сводится только к указанию файла, который будет отображаться по умолчанию (index.html). Параметры можно найти на вкладке «Свойства».

http://snoozy.ninja/images/cd/static_web.png

Сейчас самое время добавить политику для нашего ведра. Мы хотели бы, чтобы он был доступен только для чтения для всех людей.
Наша политика должна быть следующей:

Гит

Добавление нового пользователя

Второй шаг — создание пользователя. Это будет пользователь, который будет использоваться для выполнения операций на s3. Мы установим права доступа пользователя, что позволит ему управлять нашим ведром. Он будет добавлять файлы и удалять их, когда они станут ненужными. У нового пользователя должна быть политика, которая выглядит следующим образом:

Гит

Обратите внимание на строку 9. Измените ее, чтобы она соответствовала имени, которое вы использовали в качестве имени корзины.

Последнее, что нужно сделать, это загрузить ключи доступа. Они доступны на вкладке «Учетные данные безопасности». Помните, что вы можете увидеть их только один раз. Они понадобятся нам при настройке нашего gitlab.

http://snoozy.ninja/images/cd/credentials.png

Процесс подготовки нашего пайплайна проще. Единственное, что нам нужно сделать, это скопировать этот файл и сохранить его как .gitlab-ci.yml.

Гит

Мы должны не забыть добавить наш security credentials к настройкам CI/CD в настройках gitlab.

http://snoozy.ninja/images/cd/aws_credentials.png

Давайте теперь обсудим наиболее важные элементы этого файла.

Докер

Конвейеры Gitlab используют образ докера, который помогает нам настроить среду, необходимую в процессе тестирования/сборки приложения. Стоит отметить, что на каждом этапе у них может быть своя версия докера (строка 31). Это полезно, потому что в процессе сборки приложения нам понадобятся элементы, связанные с узлом, но во время развертывания нам понадобится образ с установленным python. Нам это нужно, потому что мы будем использовать awscli, который мы будем использовать для копирования наших файлов. к удаленной службе s3. Благодаря этой одной строчке уже через несколько минут после добавления наших изменений в репозиторий мы можем протестировать их в рабочей среде.

Проверка этапа развертывания

Основная магия начинается в deploy_review раздел. На этом этапе наше приложение (которое было построено в build шаг) будет добавлен в s3. Давайте посмотрим на команду, которая копирует файлы.

aws s3 cp dist s3://${BUCKET_NAME}/${CI_COMMIT_REF_SLUG}/${CI_COMMIT_SHA} —рекурсивный

Наши переменные соответственно:

  • ${BUCKET_NAME} это имя ведра.

  • ${CI_COMMIT_REF_SLUG} имя текущей ветки.

  • ${CI_COMMIT_SHA} это хеш текущего заголовка.

Адрес, по которому будет находиться наше приложение, будет примерно таким:

Для ветки master у нас очень похожее поведение. Только то, что вместо имени ветки файлы будут копироваться под основным адресом (например

После процесса обзора, когда ветка будет объединена или отклонена, мы бы хотели, чтобы наше приложение также было удалено из s3. За это отвечает код между строками 48-59.

Конфигурация приложения

Есть еще одна вещь, которую нужно помнить. Поскольку наше приложение будет доступно по разным адресам, это следует учитывать в процессе сборки. Переменная VUE_APP_ROUTER_BASE используется для этой цели. Он определяет адрес
где наше приложение будет доступно. При создании версий из ветки установите для него имя ветки.

Как мы могли видеть, настройка автоматического развертывания нашей тестовой версии очень проста и сводится к правильной настройке хостинга и добавлению .gitlab-ci в наш проект. Такие пробные версии могут использоваться для проверки приложения во время обзора, но вполне могут быть первым шагом для создания интеграционных тестов, которые будут выполняться на нашем коде.

Похожие записи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *