Як створити та керувати кластером AWS EKS за допомогою AWS CICD конвеєра

pic

pic

Діаграма архітектури

Вступ

У сучасній розробці програмного забезпечення автоматизація процесу релізу є важливим етапом для ефективної та надійної доставки додатків. AWS CodePipeline, інтегрований з AWS DevTools, надає зручний спосіб керування CI/CD пайплайнами, адаптованими до робочих навантажень Kubernetes, що працюють на Amazon EKS (Elastic Kubernetes Service).

Цей посібник проведе вас через повний життєвий цикл налаштування AWS CodePipeline для EKS кластера: від конфігурації джерела за допомогою CodeCommit, побудови та тестування за допомогою CodeBuild, розгортання за допомогою Kubernetes манифестів та моніторингу застосунків за допомогою CloudWatch Container Insights. Зосереджуючись на автоматизації, масштабованості та безпеці, ви дізнаєтесь, як оптимізувати процес розгортання контейнеризованих застосунків.

Попереднє читання:

  1. CI-CD на AWS — Частина 1: Вступ до CI/CD

[

CI-CD на AWS — Частина 1

CI/CD — це методологія розробки програмного забезпечення, яка поєднує практики безперервної інтеграції та безперервного розгортання…

achinthabandaranaike.medium.com

](/ci-cd-on-aws-part-1-5549df051845?source=post_page-----e4999e55a37d--------------------------------)

  1. CI-CD на AWS — Частина 2: AWS CodeCommit

[

CI-CD на AWS — Частина 2: AWS CodeCommit

Концепція AWS CodeCommit, яку потрібно розглянути, це контроль версій. Це можливість розуміти різні зміни, які…

achinthabandaranaike.medium.com

](/ci-cd-on-aws-part-2-aws-codecommit-4baf59570ba5?source=post_page-----e4999e55a37d--------------------------------)

  1. CI-CD на AWS — Частина 3: AWS CodeBuild

[

CI-CD на AWS — Частина 3: AWS CodeBuild

Що таке AWS CodeBuild?

achinthabandaranaike.medium.com

](/ci-cd-on-aws-part-3-aws-codebuild-d95ac2251669?source=post_page-----e4999e55a37d--------------------------------)

  1. Як побудувати повний CI/CD пайплайн за допомогою AWS DevTools

[

Як побудувати повний CI/CD пайплайн за допомогою AWS DevTools

Вступ

achinthabandaranaike.medium.com

](/how-to-build-complete-ci-cd-pipeline-using-aws-devtools-33e7fcf87d29?source=post_page-----e4999e55a37d--------------------------------)

  1. Як автоматизувати розгортання Terraform за допомогою AWS CodePipeline

[

Як автоматизувати розгортання Terraform за допомогою AWS CodePipeline

Вступ:

achinthabandaranaike.medium.com

](/how-to-automate-terraform-deployments-with-aws-codepipeline-569044313b60?source=post_page-----e4999e55a37d--------------------------------)

  1. Як побудувати розгортання AWS Cross Account CI-CD за допомогою AWS Developer Tools

[

Як побудувати розгортання AWS Cross Account CI-CD за допомогою AWS Developer Tools

Дізнайтесь, як налаштувати CI/CD пайплайни між акаунтами за допомогою інструментів AWS. Розгортання через кілька акаунтів і середовищ…

community.aws

](https://community.aws/content/2cDGeLqlyASanVJO9qiFI87916i/aws-cross-account-ci-cd-deployment-using-aws-developer-tools?source=post_page-----e4999e55a37d--------------------------------)

Етапи процесу релізу

pic

Етапи процесу релізу

На етапі джерела ми перевіряємо вихідний код, переглядаємо новий код і обробляємо pull-запити. На етапі збірки ми компілюємо код і створюємо артефакти, такі як файли WAR, JAR, образи контейнерів або навіть маніфести Kubernetes, і потім тестуємо їх на одиничні тести, після чого переходимо до етапу тестування. На етапі тестування ми проводимо інтеграційні тести з іншими системами, навантажувальні тести, тести інтерфейсу, тести безпеки та перевірки в тестових середовищах, таких як dev, QA і staging. Все це охоплюється етапом тестування. Потім буде етап, званий виробничим етапом.
Так, розгорніть на виробничих середовищах, а потім моніторьте код у виробництві, щоб швидко виявляти помилки.

AWS DevTools для пайплайна

pic

AWS DevTools для пайплайна

AWS має інструмент під назвою CodePipeline, який інтегрується з різними інструментами AWS. Для вихідного коду використовується AWS CodeCommit, що подібне до репозиторіїв на GitHub, BitBucket тощо. Для збірки зазвичай використовують Jenkins, але в AWS можна використовувати CodeBuild, який дозволяє створювати артефакти та завантажувати їх у S3 бакети AWS. Для тестування можна використовувати CodeBuild разом з сторонніми інструментами для тестування. На етапі розгортання ми використовуємо Kubernetes разом з CodeBuild і Kubectl для розгортання у нашому випадку. Останній етап — моніторинг. Для моніторингу ми використовуємо Cloudwatch Container Insights. Завдяки цьому ми можемо здійснювати повний моніторинг контейнеризованих застосунків, що розгорнуті на кластері Kubernetes, а також компонентів самого кластера Kubernetes.

Перевірка перед налаштуванням

  • Ми будемо розгортати застосунок, який також має ALB Ingress Service і реєструватиме своє DNS-ім’я в Route53 за допомогою External DNS.
  • Це означає, що в нашому кластері повинні працювати обидва відповідні контейнери.
# Перевірити, чи працює alb-ingress-controller pod у просторі імен kube-system  
kubectl get pods -n kube-system  

# Перевірити, чи працює external-dns pod у просторі імен default  
kubectl get pods

Створення репозиторію ECR для наших Docker-образів застосунків

Кроки:

  • Перейдіть до Services -> Elastic Container Registry -> Create Repository

pic

AWS ECR

  • Назва: eks-devops

pic

Створення ECR репозиторію

  • Іммутабельність тегів: Включити
  • Сканування при пуші: Включити
  • Натисніть на Create Repository

pic

Сканування при пуші увімкнено

Створення репозиторію CodeCommit і генерація Git облікових даних

pic

Створення репозиторію CodeCommit

pic

Назва репозиторію

  • Створіть git-облікові дані через IAM Service (HTTPS Credentials)
  • Клонуйте git-репозиторій з CodeCommit до локального репозиторію, під час процесу введіть ваші облікові дані для входу в git-репозиторій
git clone https://git-codecommit.us-east-1.amazonaws.com/v1/repos/eks-devops

Необхідно додати наступні файли до новоствореного git-репозиторію.

buildspec.yml

version: 0.2  
phases:  
 install:  
 commands:  
 - echo "Install Phase - Нічого не потрібно робити, використовуючи останній образ Docker Amazon Linux для CodeBuild, що містить усі інструменти AWS - https://github.com/aws/aws-codebuild-docker-images/blob/master/al2/x86_64/standard/3.0/Dockerfile"  
 pre_build:  
 commands:  
 # Тег Docker-образу з Датою, Часом і Розв'язаним Вершином Коду  
 - TAG="$(date +%Y-%m-%d.%H.%M.%S).$(echo $CODEBUILD_RESOLVED_SOURCE_VERSION | head -c 8)"  
 # Оновлення тегу образу в нашому маніфесті Kubernetes   
 - echo "Оновлення тегу образу в kube-manifest..."  
 - sed -i 's@CONTAINER_IMAGE@'"$REPOSITORY_URI:$TAG"'@' kube-manifests/01-DEVOPS-Nginx-Deployment.yml  
 # Перевірка версії AWS CLI   
 - echo "Перевірка версії AWS CLI..."  
 - aws --version  
 # Логін до реєстру ECR для завантаження образу в репозиторій ECR  
 - echo "Логін до Amazon ECR..."  
 - $(aws ecr get-login --no-include-email)  
 # Оновлення конфігурації Kube для домашнього каталогу  
 - export KUBECONFIG=$HOME/.kube/config  
 build:  
 commands:  
 # Створення Docker-образу  
 - echo "Будівництво почалося на `date`"  
 - echo "Створення Docker-образу..."  
 - docker build --tag $REPOSITORY_URI:$TAG .
post_build:  
 commands:  
 # Завантаження Docker-образу в репозиторій ECR  
 - echo "Будівництво завершено на `date`"  
 - echo "Завантаження Docker-образу в репозиторій ECR"  
 - docker push $REPOSITORY_URI:$TAG  
 - echo "Завантаження Docker-образу в ECR завершено - $REPOSITORY_URI:$TAG"   
 # Отримання облікових даних AWS за допомогою STS Assume Role для kubectl  
 - echo "Налаштування змінних середовища, пов'язаних з AWS CLI для налаштування Kube Config"   
 - CREDENTIALS=$(aws sts assume-role --role-arn $EKS_KUBECTL_ROLE_ARN --role-session-name codebuild-kubectl --duration-seconds 900)  
 - export AWS_ACCESS_KEY_ID="$(echo ${CREDENTIALS} | jq -r '.Credentials.AccessKeyId')"  
 - export AWS_SECRET_ACCESS_KEY="$(echo ${CREDENTIALS} | jq -r '.Credentials.SecretAccessKey')"  
 - export AWS_SESSION_TOKEN="$(echo ${CREDENTIALS} | jq -r '.Credentials.SessionToken')"  
 - export AWS_EXPIRATION=$(echo ${CREDENTIALS} | jq -r '.Credentials.Expiration')  
 # Налаштування kubectl для нашого кластера EKS   
 - echo "Оновлення Kube Config"   
 - aws eks update-kubeconfig --name $EKS_CLUSTER_NAME  
 # Застосування змін до нашого застосунку за допомогою kubectl  
 - echo "Застосування змін до kube manіfest"   
 - kubectl apply -f kube-manifests/  
 - echo "Завершено застосування змін до об'єктів Kubernetes"   
 # Створення артефактів, які можна використовувати, якщо хочемо продовжити пайплайн для інших етапів  
 - printf '[{"name":"01-DEVOPS-Nginx-Deployment.yml","imageUri":"%s"}]' $REPOSITORY_URI:$TAG > build.json  
 # Додаткові команди для перегляду ваших облікових даних   
 echo "Значення облікових даних: ${CREDENTIALS}"   
 echo "AWS_ACCESS_KEY_ID... ${AWS_ACCESS_KEY_ID}"   
 echo "AWS_SECRET_ACCESS_KEY... ${AWS_SECRET_ACCESS_KEY}"   
 echo "AWS_SESSION_TOKEN... ${AWS_SESSION_TOKEN}"   
 echo "AWS_EXPIRATION... $AWS_EXPIRATION"   
 echo "EKS_CLUSTER_NAME..."
$EKS_CLUSTER_NAME"   
artifacts:  
 files:   
 - build.json   
 - kube-manifests/*

index.html





Ласкаво просимо до AWS DevTools з Ахінтою Бандарінаїке - V1 
Назва застосунку: App1
        ```  > Docker File:  ``` FROM nginx   COPY app1 /usr/share/nginx/html/app1 ```  ## kube-manifest файли:  > nginx-deployment.yml  ``` apiVersion: apps/v1   kind: Deployment   metadata:    name: eks-devops-deployment    labels:    app: eks-devops   spec:    replicas: 2    selector:    matchLabels:    app: eks-devops    template:    metadata:    labels:    app: eks-devops    spec:    containers:    - name: eks-devops    image: CONTAINER_IMAGE    ports:    - containerPort: 80 ```  > nginx-nodeportservice.yml  ``` apiVersion: v1   kind: Service   metadata:    name: eks-devops-nodeport-service    labels:    app: eks-devops    annotations:     alb.ingress.kubernetes.io/healthcheck-path: /app1/index.html    spec:    type: NodePort    selector:    app: eks-devops    ports:    - port: 80    targetPort: 80 ```  > nginx-alb-ingressservice.yml  ``` apiVersion: extensions/v1beta1   kind: Ingress   metadata:    name: eks-devops-ingress-service    labels:    app: eks-devops    annotations:    # Основні налаштування Ingress     kubernetes.io/ingress.class: "alb"    alb.ingress.kubernetes.io/scheme: internet-facing    # Налаштування перевірки стану    alb.ingress.kubernetes.io/healthcheck-protocol: HTTP     alb.ingress.kubernetes.io/healthcheck-port: traffic-port    alb.ingress.kubernetes.io/healthcheck-interval-seconds: '15'    alb.ingress.kubernetes.io/healthcheck-timeout-seconds: '5'    alb.ingress.kubernetes.io/success-codes: '200'    alb.ingress.kubernetes.io/healthy-threshold-count: '2'    alb.ingress.kubernetes.io/unhealthy-threshold-count: '2'    ## Налаштування SSL    alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS":443}, {"HTTP":80}]'    alb.ingress.kubernetes.io/certificate-arn:     #alb.ingress.kubernetes.io/ssl-policy: ELBSecurityPolicy-TLS-1-1-2017-01 #Опціонально (вибирається за замовчуванням, якщо не використано)     # Налаштування перенаправлення SSL    alb.ingress.kubernetes.io/actions.ssl-redirect: '{"Type": "redirect", "RedirectConfig": { "Protocol": "HTTPS", "Port": "443", "StatusCode": "HTTP_301"}}'     # External DNS - для створення запису в Route53    external-dns.alpha.kubernetes.io/hostname: cloudylk.com    spec:    ingressClassName: my-aws-ingress-class # Ingress Class    rules:    - http:    paths:    - path: /* # Налаштування перенаправлення SSL    backend:    serviceName: ssl-redirect    servicePort: use-annotation     - path: /*    backend:    serviceName: eks-devops-nodeport-service    servicePort: 80 ```  ## Ієрархія файлів:  ![pic](https://drive.javascript.org.ua/507e05dc9c1_brr0IR70YXsehKcakyVpIQ_png)  _Ієрархія файлів_  ## Створення STS Assume Role для CodeBuild для взаємодії з EKS кластером  
 CodeBuild — це сервіс, який виконує побудову Docker-образу та відповідне розгортання в нашому EKS кластері. Тому для цього нам потрібна додаткова інформація.  
 В AWS CodePipeline ми використовуємо CodeBuild для розгортання змін до наших Kubernetes маніфестів.
Отже, для цього потрібна роль AWS IAM, здатна взаємодіяти з EKS кластером.

На цьому етапі ми створимо роль IAM і додамо вбудовану політику `EKS:Describe`, яку ми використовуватимемо на етапі CodeBuild для взаємодії з EKS кластером через Kubectl.

Експортуємо ID вашого акаунта

export ACCOUNT_ID=

Встановимо політику довіри

TRUST="{ \"Version\": \"2012-10-17\", \"Statement\": [{ \"Effect\": \"Allow\", \"Principal\": { \"AWS\": \"arn:aws:iam::${ACCOUNT_ID}:root\" }, \"Action\": \"sts:AssumeRole\" }] }"

Перевіримо, чи замінилися ID вашого акаунта в політиці довіри

echo $TRUST

Створимо роль IAM для CodeBuild для взаємодії з EKS

aws iam create-role --role-name EksCodeBuildKubectlRole --assume-role-policy-document "$TRUST" --output text --query 'Role.Arn'

Визначимо вбудовану політику з дозволом eks Describe в файл iam-eks-describe-policy

echo '{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": "eks:Describe", "Resource": "" }] }' > /tmp/iam-eks-describe-policy

Призначимо вбудовану політику нашій щойно створеній ролі IAM

aws iam put-role-policy --role-name EksCodeBuildKubectlRole --policy-name eks-describe --policy-document file:///tmp/iam-eks-describe-policy
```

Перевірте в AWS Console.

Оновіть EKS Cluster aws-auth ConfigMap з новою роллю, створеною на попередньому етапі

В EKS кластері є конфігураційна карта, яку називають AWS auth.
Отже, все, що ми створили, потрібно оновити в EKS кластері.

Перевірте, що є в конфігураційній карті aws-auth перед змінами.

kubectl get configmap aws-auth -o yaml -n kube-system

pic

output

Встановіть значення ролі

ROLE=" - rolearn: arn:aws:iam::$ACCOUNT_ID:role/EksCodeBuildKubectlRole\n username: build\n groups:\n - system:masters"

Отримайте поточні дані конфігураційної карти aws-auth і додайте до них нову інформацію про роль

kubectl get -n kube-system configmap/aws-auth -o yaml | awk "/mapRoles: \|/{print;print \"$ROLE\";next}1" > /tmp/aws-auth-patch.yml

Застосуйте зміни до конфігураційної карти aws-auth з новою роллю

kubectl patch configmap/aws-auth -n kube-system --patch "$(cat /tmp/aws-auth-patch.yml)"

Перевірте, що оновлено в конфігураційній карті aws-auth після змін

kubectl get configmap aws-auth -o yaml -n kube-system

Створення Pipeline:

Кроки:

  • Перейдіть до Services -> CodePipeline -> Створити Pipeline

pic

Вкажіть ім'я Pipeline

  • Джерело – Codecommit

pic

Виберіть джерело Codecommit

  • Для стадії побудови виберіть Codebuild.

pic

Створити новий Build проект

  • Створіть новий проект

pic

Вкажіть ім'я проекту

Встановіть наступні налаштування в секції Environment

Environment Image: Managed Image

Операційна система: Amazon Linux 2

Рантайми: Standard

Образ: aws/codebuild/amazonlinux2-x86_64-standard:3.0

Версія образу: Завжди використовуйте останню версію для цього рантайму

Тип середовища: Linux

Привілейований доступ: Увімкнено

Ім'я ролі: Виберіть надану AWS роль

Додаткові налаштування: Залиште за замовчуванням

Додайте змінні середовища

REPOSITORY_URI =

EKSKUBECTLROLE_ARN = arn:aws:I am:::role/EksCodeBuildKubectlRole

EKSCLUSTERNAME =

Виберіть використати файл buildspec:

pic

Використовувати файл buildspec

Логи:

  • Ім'я групи: eks-deveops-cicd-logs

Натисніть Продовжити до CodePipeline

Натисніть Пропустити стадію Deploy

pic

Необхідно пропустити стадію Build

Перегляньте та натисніть Створити Pipeline

Доступ до ECR для ролі CodeBuild IAM:

Роль IAM CodeBuild не має доступу до ECR.

Перейдіть до ролі IAM CodeBuild та додайте нижче політику IAM.

Назва політики: AmazonEC2ContainerRegistryFullAccess

Оновіть роль CodeBuild, щоб мати доступ до STS Assume Role, яку ми створили, використовуючи політику STS Assume Role

  • Побудова має не вдатися через те, що CodeBuild не має доступу для виконання оновлень в EKS кластері.
  • Вона навіть не може виконати STS Assume Role, яку ми створили.
  • Створіть політику STS Assume та призначте її ролі CodeBuild

Створення політики STS Assume Role

  • Перейдіть до Services IAM -> Політики -> Створити політику
  • Вкладка Visual Editor
  • Сервіс: STS
  • Дії: Підрозділ Write — Виберіть AssumeRole
  • Ресурси: Specific
  • Додайте ARN
  • Вкажіть ARN для ролі: arn:aws:iam:::role/EksCodeBuildKubectlRole
  • Натисніть Додати
  • Натисніть на Переглянути політику
  • Назва: eks-codebuild-sts-assume-role
  • Опис: CodeBuild для взаємодії з EKS кластером для виконання змін
  • Натисніть Створити політику

Призначте політику ролі CodeBuild

Тепер ініціюйте Pipeline:

pic

Pipeline успішний

pic

output index.html

Висновок

Управління кластером AWS EKS за допомогою AWS CodePipeline спрощує і оптимізує процес CI/CD для робочих навантажень Kubernetes.
Використовуючи інструменти AWS, такі як CodeCommit, CodeBuild і CloudWatch, ви можете створити автоматизований, надійний і масштабований конвеєр для розгортання контейнеризованих додатків. Такий підхід забезпечує безперервну інтеграцію, ретельне тестування та ефективне розгортання, зменшуючи час і зусилля, необхідні для ручних втручань. Завдяки правильній конфігурації та моніторингу ви можете підтримувати безпечні та високо ефективні додатки в продуктивних середовищах.

Дякую за прочитане! Побачимося в наступній статті. Не забувайте підписатися на мене через Medium і залишити 👏. Залишайтеся на зв'язку через LinkedIn :

https://www.linkedin.com/in/achintha-bandaranaike-676a82163/

Перекладено з: How to Create and Manage AWS EKS Cluster with AWS CICD Pipeline

Вам також може сподобатися

Тренд на HypeHype — синхронізовані ігрові сесії
Майстерність у юніт-тестуванні з Jest: Всеосяжний посібник
Розгортання Docker-додатків на AWS Elastic Beanstalk

Leave a Reply

Your email address will not be published. Required fields are marked *