Развертывание приложения на Kubernetes (Amazon EKS) с помощью AWS Serverless (Codebuild)

Привет, друзья,
Недавно я столкнулся с примером развертывания микросервиса на EKS с помощью CodeBuild с GitHub в качестве источника. Хотя я много раз использовал Jenkins для того же самого, но я не использовал AWS Serverless для развертывания на EKS.

Этот блог для вас, если вы хотите развернуть свой микросервис на Kubernetes, или хотите узнать, как настроить AWS CodePipeline с CodeBuild, или хотите интегрировать CodeBuild с EKS, или вам вообще интересно про Kubernetes и Serverless 🙂

Содержание

Вот как я начал путешествие:
Найдите вашу роль CodeBuild Service Role:
Обновите конфигурационную карту aws-auth:
Разверните ваше приложение, запустите конвейер:
Очистка

Вот как я начал путешествие:

Я поинтересовался исходным кодом и узнал, что он находится на GitHub. В этом блоге я собираюсь создать свой собственный GitHub Repo с базовым манифестом развертывания. Вы можете создать свое собственное репо и иметь полный стек манифестов, начиная с Ingress, заканчивая сервисом, развертыванием и т.д., необходимыми для вашего микросервиса.

Далее я настроил CodePipeline. Я покажу вам, как это сделать:

Перейдите в Developer Tools в консоли и выберите Code Pipeline. Дайте вашему конвейеру имя, выберите роль сервиса по умолчанию, чтобы CodePipeline мог создать роль от вашего имени, а расширенные настройки оставьте без изменений, если у вас нет собственного местоположения для вашего артефакта и вы не хотите использовать собственный KMS Key.

Далее вам нужно указать, где находится ваш SourceCode, который вы хотите собрать или развернуть.

Добавьте поставщика исходного кода: В нашем случае это будет GitHub (Version2).Connection: Выберите, есть ли у вас существующее соединение с вашим аккаунтом GitHub или создайте соединение для GitHub, это довольно просто. После того как вы аутентифицируете CodePipeline для соединения с вашим аккаунтом GitHub, вы получите URL соединения CodeStar, используйте его. После того как вы заполните все детали, это должно выглядеть примерно так.

Мой GitHub Repo

Далее мы добавим этап сборки.

В качестве провайдера сборки мы выберем AWS CodeBuild. Не стесняйтесь выбирать регион по своему усмотрению. Если у вас есть существующий проект, вы можете выбрать его или создать новый. Я собираюсь создать проект с нуля.
Чтобы создать проект CodeBuild, вам нужно указать название и описание проекта, вы также можете ограничить количество одновременных сборок и указать дополнительные теги, если хотите.
Создайте окружение CodeBuild, мы будем использовать последний образ Amazon Linux 2 и попросим CodeBuild создать новую служебную роль от нашего имени.
Дополнительная конфигурация среды
Выберите ваш VPC, выберите частную подсеть и SG с разрешением исходящих соединений, а затем проверьте настройки VPC. Именно здесь будет размещен ваш сервер codebuild ~ Нет, бессерверность не означает отсутствие серверов, просто вам не нужно ими управлять 😉
Предоставьте серверу соответствующие вычислительные ресурсы в соответствии с требованиями вашего кода, и все готово. При необходимости вы можете добавить переменные окружения и файловые системы для вашего сервера.
Вы можете оставить раздел buildspec пустым, если ваш файл buildspec — buildspec.yml, так как codebuild будет искать этот файл в вашем репозитории, если вы назвали свой файл иначе, вы можете указать это в разделе buildspec name. Также если у вас есть дополнительные требования к сборке кода, вы можете указать их в дополнительных командах сборки.
Мы проигнорируем пакетную конфигурацию, так как для этого поста она нам не нужна.
Лучше всего экспортировать журналы сборки в Cloudwatch, чтобы вам было проще устранять неполадки. Кроме того, вы можете экспортировать журналы CodeBuild в S3 для последующего анализа.

После того, как вы нажмете на кнопку continue to CodePipeline, проект CodeBuild будет создан, и вы сможете завершить настройку CodePipeline.

В переменных окружения вы можете ссылаться на значения окружения, сгенерированные CodePipeline, или добавить новые переменные окружения. В параметре Build Type мы будем выполнять одну сборку при выполнении.

Пропустите этап Deploy, поскольку codebuild позаботится о развертывании, и создайте свой CodePipeline 🙂

Кластер EKS: Я буду считать, что у вас есть запущенный кластер EKS, на котором мы будем выполнять развертывание, если нет, вы можете развернуть новый кластер EKS. Если вам нужна помощь, обратитесь к этому моему предыдущему блогу — Настройка кластера EKS с нуля

Чтобы позволить CodeBuild развертываться на кластере EKS, нам нужно изменить EKS RBAC, добавив роль CodeBuild Service Role с необходимыми разрешениями в конфигурационную карту aws-auth, которая используется для управления EKS RBAC.
Чтобы узнать больше о EKS RBAC

Найдите вашу роль CodeBuild Service Role:

Откройте проект сборки, который вы будете использовать. На вкладке Build details прокрутите вниз до Environment, где вы увидите гиперссылку Service Role.

Обновите конфигурационную карту aws-auth:

Для редактирования конфигурационной карты выполните команду — kubectl edit cm aws-auth -n kube-system.

В разделе mapRoles мы добавим новую запись:

- groups:
    - system:masters
  rolearn: arn:aws:iam::xxxaccidxxx:role/codebuild- microservice-deploy-to-eks-service-role 
  username: CodeBuild Role to Access EKS

Вход в полноэкранный режим Выйти из полноэкранного режима

Примечание Если вы напрямую вставите ARN CodeBuild Role из консоли в configmap, вы получите «ошибку: You must be logged in to the server (Unauthorized)», убедитесь, что вы удалили путь /servicerole из ARN.

Дополнительно к роли CodeBuild Service Role прикрепите политику с разрешенным действием eks:DescribeCluster. Это позволит codebuild загрузить файл kubeconfig на свой сервер.