5/5 - (2 голоса)

Среда для выполнения

  1. Зарегистрированный аккаунт AWS
  2. Развернутый кластер EKS 
  3. GitLab (проект приложения)

Задача:

Настроить CI/CD для подготовленного на GitLab проекта, который представляет собой RESTful микросервис Node.JS (framework nestJS). Микросервис в кластере ECS/EKS должен по умолчанию иметь 2 запущенные поды c равномерной балансировкой нагрузки.

В задачу входит:

  1. Ознакомиться с проектом
  2. Настроить авто CI/CD из ветки develop для одного окружения 
  3. Объяснить что потребуется выполнить для настройки процесса для двух и более окружений (дев/стейдж/прод)
  4. Объяснить как сконфигурирован кластер EKS
  5. Объяснить как реализована балансировка нагрузки

Решение:

Для реализации поставленной задачи в 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]