HashiCorp показала новый проект Waypoint на HashiCorp Digital. Он использует файл на основе HCL для описания сборки, поставки и выпуска приложений для различных облачных платформ, начиная от Kubernetes и заканчивая AWS и Google Cloud Run. Можно представить, что Waypoint — это сложенные вместе Terraform и Vagrant для описания процесса сборки, поставки и выпуска ваших приложений.
Не изменяя себе, HashiCorp выпустила Waypoint с открытым исходным кодом, также к нему прилагается множество примеров. Уровень оркестратора остается за вами, Waypoint поставляется в виде исполняемого файла, который вы можете запустить прямиком на вашем ноутбуке или из выбранного вами инструмента оркестрации CI/CD. Цель для развертывания приложений также выбирается вами, поскольку Waypoint поддерживает Kubernetes, Docker, Google Cloud Run, AWS ECS и другие.
Почитав улетную документацию и шикарнейшие примеры приложений, предоставленные HashiCorp, мы решили взглянуть поближе на оркестровку Waypoint с помощью GitLab CI/CD. Чтобы это сделать, мы возьмем простое приложение Node.js, запускаемое на AWS ECS, из репозитория примеров.
После клонирования репозитория посмотрим структуру приложения, отображающего одну страницу:
Как вы могли заметить, в этом проекте нет Dockerfile. Они не добавлены в примере, поскольку они в принципе и не нужны нам, ведь Waypoint позаботится о них за нас. Давайте рассмотрим детальнее файл waypoint.hcl
, чтобы понять, что он будет делать:
project = "example-nodejs"
app "example-nodejs" {
labels = {
"service" = "example-nodejs",
"env" = "dev"
}
build {
use "pack" {}
registry {
use "aws-ecr" {
region = "us-east-1"
repository = "waypoint-gitlab"
tag = "latest"
}
}
}
deploy {
use "aws-ecs" {
region = "us-east-1"
memory = "512"
}
}
}
На этапе сборки Waypoint использует Cloud Native Buildpacks (CNB), чтобы определить язык программирования проекта и создать образ для Docker без использования Dockerfile. В принципе, это та же самая технология, которая используется GitLab в части Auto DevOps на шаге Auto Build. Приятно видеть, что CNB от CNCF получает все большее распространение у пользователей из отрасли.
Как только образ собран, Waypoint автоматически выгрузит его в нашу AWS ECR registry, чтобы он был готов к поставке. По окончанию сборки шаг поставки использует дополнение AWS ECS для развертывания нашего приложения в нашу учетную запись AWS.
С моего ноутбука — все просто. Я ставлю Waypoint, который уже аутентифицирован в моей учетной записи AWS, и оно «просто работает». Но что будет, если я захочу выйти за пределы моего ноутбука? Или вдруг я хочу автоматизировать это развертывание в виде части моего общего конвейера CI/CD, где запускаются мои текущие интеграционные тесты, тесты безопасности и прочие? Это та часть рассказа, где появляется GitLab CI/CD!
N.B. Если вы еще только планируете внедрение CI/CD или хотите начать применять лучшие практики построения пайплайнов, обратите внимание на новый курс Слёрма «CI/CD на примере Gitlab CI». Сейчас он доступен по цене предзаказа.
Waypoint в GitLab CI/CD
Для оркестровки всего этого в GitLab CI/CD давайте посмотри, что нам понадобится в нашем файле .gitlab-ci.yml
:
- В первую очередь, нужен базовый образ для запуска внутри него. Waypoint работает на любом дистрибутиве Linux, ему нужен только Docker, так что мы может запускаться с generic образа Docker.
- Далее надо установить Waypoint в этот образ. В будущем мы можем собрать образ meta build и контейнеризировать этот процесс для себя.
- Наконец мы запустим команды Waypoint
Выше расписано все, что понадобится нашему конвейеру для запуска нужных для выполнения развертывания скриптов, но для развертывания в AWS нам понадобится еще одна вещь: мы должны авторизоваться в нашей учетной записи AWS. В описании Waypoint есть планы об аутентификации и авторизации. HashiCorp на этой неделе также выпустила впечатляющий проект Boundary. Но на данный момент мы можем просто взять и самостоятельно обработать аутентификацию и авторизацию.
Для аутентификации GitLab CI\CD в AWS есть несколько вариантов. Первый вариант — использование встроенного HashiCorp Vault. Он подойдет, если ваша команда уже пользуется Vault для управления учетными данными. Еще один способ, который подходит, если ваша команда управляет авторизацией с помощью AWS IAM — проверьте, что задачи поставки запускаются через GitLab Runner, авторизованный для запуска развертывания через IAM. Но если вы просто хотите ознакомиться с Waypoint и хотите это сделать побыстрее, есть последний вариант — добавить ваши ключи AWS API и Secret в переменные окружения GitLab CI/CD AWS_ACCESS_KEY_ID
и AWS_SECRET_ACCESS_KEY
.
Собираем все вместе
Как только мы разобрались с аутентификацией, можно начинать! Наш окончательный .gitlab-ci.yml
выглядит так:
waypoint:
image: docker:latest
stage: build
services:
- docker:dind
# Define environment variables, e.g. `WAYPOINT_VERSION: '0.1.1'`
variables:
WAYPOINT_VERSION: ''
WAYPOINT_SERVER_ADDR: ''
WAYPOINT_SERVER_TOKEN: ''
WAYPOINT_SERVER_TLS: '1'
WAYPOINT_SERVER_TLS_SKIP_VERIFY: '1'
script:
- wget -q -O /tmp/waypoint.zip https://releases.hashicorp.com/waypoint/${WAYPOINT_VERSION}/waypoint_${WAYPOINT_VERSION}_linux_amd64.zip
- unzip -d /usr/local/bin /tmp/waypoint.zip
- rm -rf /tmp/waypoint*
- waypoint init
- waypoint build
- waypoint deploy
- waypoint release
Вы видите, что мы начинаем с образа docker:latest
и устанавливаем несколько переменных окружения, требуемых для Waypoint. В разделе script
мы скачиваем последнюю версию исполняемого файла Waypoint и ставим его в /usr/local/bin
. Поскольку наш runner уже авторизован в AWS, далее мы просто запускаем waypoint init
, build
, deploy
и release
.
Вывод задачи по сборке покажет нам endpoint, куда мы раскатили приложение:
Waypoint одно из многочисленных решений HashiCorp, отлично работающих с GitLab. Например, в дополнение к поставке приложения мы можем оркестрировать нижележащую инфраструктуру с помощью Terraform в GitLab. Для стандартизации безопасности SDLC, мы можем также внедрить GitLab с Vault для управления секретами и токенами в конвейерах CI/CD, предоставляя целостное решение для разработчиков и администраторов, полагающихся на управление секретами при разработке, тестировании, а также промышленном использовании.
Совместные решения, разработанные HashiCorp и GitLab, помогают компаниям найти лучший способ разработки приложений, обеспечивая согласованное управление потоками поставки и инфраструктурой. Waypoint сделали еще один шаг в верном направлении, и мы с нетерпением ожидаем дальнейшего развития проекта. Вы можете узнать больше о Waypoint здесь, также стоит изучить документацию и план развития проекта. Мы добавили полученные нами знания в документацию GitLab CI\CD. Если вы хотите попробовать все в работе самостоятельно, можете взять полный работоспособный пример в этом репозитории.
Понять принципы CI/CD, освоить все тонкости работы с Gitlab CI и начать применять лучшие практики можно, пройдя видеокурс «CI/CD на примере Gitlab CI». Присоединяйтесь!
Neyury
А что по поводу разных окружений? (prod/dev/staging) К примеру в
.hcl
файле указана меткаenv=dev
, как этим можно управлять? Что если в разных окружениях должны быть разные значения? (таймауты, подключения к базам, сервисам и т.д.)?Finnix Автор
Как я понял из описания — на данный момент надо сделать несколько app, т.е. настройки для каждого окружения будут задаваться отдельным app, после чего запускать
waypoint up -app <appname>
. Предполагаю, что с выпуском версии 1.0 ситуация может улучшиться.Neyury
Спасибо, вроде то что нужно. Получается, что несколько секций app + workspaces неплохо покрывают все потребности по развертыванию в разных окружениях