Среда для выполнения
- Зарегистрированный аккаунт AWS
- Развернутый кластер EKS
- GitLab (проект приложения)
Задача:
Настроить CI/CD для подготовленного на GitLab проекта, который представляет собой RESTful микросервис Node.JS (framework nestJS). Микросервис в кластере ECS/EKS должен по умолчанию иметь 2 запущенные поды c равномерной балансировкой нагрузки.
В задачу входит:
- Ознакомиться с проектом
- Настроить авто CI/CD из ветки develop для одного окружения
- Объяснить что потребуется выполнить для настройки процесса для двух и более окружений (дев/стейдж/прод)
- Объяснить как сконфигурирован кластер EKS
- Объяснить как реализована балансировка нагрузки
Решение:
Для реализации поставленной задачи в EKS нужно запустить один deployment, и добавить сервис для балансировки нагрузки.
В начале для настройки деплоя в несколько окружений достаточно разделить их на уровне namespace кластера kubernetes. Доступ к этим окружениям можно разграничить на уровне RBAC.
Настройки деплоя из одной ветки: в правилах прописать условие, которое будет содержвать информацию зз каких веток, тегов делать деплой.
В тестовом EKS кластере установлен агент GitLab, которой позволяет реализовать прозрачную интеграцию кластера kubernetes и GitLab. Так же этот агент используется для запуска GitLab раннеров, на которых выполняется пайплайн.
- Для доступа к приложению из вне, в кластере установим nginx-ingress сервис.
- Для доступа в репозиторий гитлаба добавим токен.
- Балансировку нагрузки реализуем посредством LoadBalancer в AWS.
Поддержку SSL возможно реализовать на двух разных уровнях, это может быть балансировщик AWS или же nginx-ingress. Для реализации на уровне nginx-ingress можно использовать сервис cert-manager, для автоматического выпуска и обновления сертификатов Let’s Encrypt.
По окончанию получили результат.
Результат состоит из 2-х шагов:
- На первом этапе собирается контейнер из докер файла при помощи bind. После чего загружается в репозиторий на GitLab.
- На втором — меняем тег контейнера в кластере.
Если приблизить это задание к продакшену, мы еще можем добавить шаг с обновлением контекста в Kubernetes, также стоит использовать докер файл с уже заранее собраный с помощью build приложением, чтобы использовать среду production вместо dev. Так же рекомендовано добавить простые проверки, тесты приложения.
Если Вам нужна помощь в реализации подобных задач, обращайтесь [email protected]