Использование Flux для реализации GitOps в AWS

Введение

Хотя многие корпоративные компании внедрили Kubernetes в свою производственную среду, они часто не понимают, как обеспечить непрерывное развертывание, высокий уровень безопасности, изоляцию разрешений и аудит, одновременно обеспечивая гибкость бизнеса благодаря нескольким кластерам Kubernetes, работающим одновременно на разных этапах. Использование GitOps позволяет обеспечить такое непрерывное развертывание на основе кластеров Kubernetes, одновременно отвечая таким требованиям корпоративного уровня, как безопасность и изоляция разрешений.

В этой статье мы рассмотрим реализацию GitOps в среде Amazon EKS с использованием AWS CodeCommit, AWS CodePipeline и Flux. Мы подробно покажем, как настроить рабочий процесс GitOps, отвечающий производственным требованиям в этой среде Amazon EKS, и продемонстрируем, как приложения микросервисов обеспечивают непрерывную интеграцию и непрерывную доставку в конвейере CI/CD в стиле GitOps.

Предпосылки

Опыт AWS
аккаунт AWS

Что такое GitOps?

GitOps — это способ непрерывного развертывания облачных приложений. Он ориентирован на разработчика и использует инфраструктуру, используя инструменты, с которыми разработчики уже знакомы, включая Git и инструменты непрерывного развертывания.

Основная идея GitOps заключается в наличии Git-репозитория, который всегда содержит подробное описание инфраструктуры в продакшене, и автоматизированного процесса приведения продакшен-среды в соответствие с состоянием, описанным в репозитории. Если вы хотите развернуть новое приложение или обновить существующее, вам просто нужно обновить репозиторий. Автоматизированный процесс позаботится обо всём. Это своего рода круиз-контроль для управления приложениями в продакшене.

Зачем использовать GitOps?

Git — единственный истинный источник данных о состоянии системы. Он поддерживает повторяемое и автоматизированное развертывание, управление кластерами и мониторинг. Разработчики повторно используют рабочие процессы Git, хорошо зарекомендовавшие себя в организации, для сборки, тестирования, сканирования и других этапов непрерывной интеграции. После того, как последнее состояние системы зафиксировано в основной ветке репозитория Git, для проверки развертывания, просмотра оповещений и исправления ошибок используется набор инструментов GitOps. Основываясь на основных принципах GitOps, мы считаем, что GitOps — лучший способ непрерывного развертывания кластеров Kubernetes. Процесс выглядит следующим образом:

Лучшие практики на основе Amazon EKS для GitOps

Общий конвейер CI/CD, соответствующий лучшим практикам, показан на рисунке ниже.

В репозитории AWS CodeCommit есть три репозитория кода. Один flux-repo является репозиторием конфигурации для Flux CD, который используется для определения ресурсов, связанных с Флюс Второй — microservices-repo, в котором хранятся конфигурации и файлы развертывания приложений микросервисов. Третий — приложение-репозиторий исходного кода для бизнес-сервисов. В этой публикации в качестве примера используется проект frontend. Для непрерывной интеграции в конвейере мы используем AWS CodePipeline. CI/CD Мы использовали образ Docker в Amazon ECR Мы сохранили, сохранили и развернули движок Flux CD как модуль в среде Amazon EKS.

Основной рабочий процесс:

Инженеры-кодировщики пишут код и помещают окончательный код в репозиторий приложений.
Изменения кода в app-repo запускают AWS CodePipeline.
AWS CodePipeline редактирует и упаковывает код, генерирует образы контейнеров и отправляет их в репозиторий образов контейнеров/Amazon ECR.
Движок Flux CD, работающий в среде EKS, регулярно сканирует репозиторий образов контейнеров ECR и извлекает метаданные образов контейнеров для приложений.
URL-адрес нового образа контейнера автоматически синхронизируется с файлом развертывания приложения, хранящимся в репозитории microservices, с помощью git commit/push при обнаружении новой версии образа контейнера.
Flux регулярно извлекает конфигурации приложений и файлы развертывания из Flux-repo. Поскольку репозиторий Flux-repo ссылается на microservices-repo, Flux проверяет соответствие состояния выполнения рабочей нагрузки кластера ожиданиям, описанным в файлах microservices-repo. При наличии каких-либо различий Flux автоматически синхронизирует эти различия с кластером EKS, чтобы гарантировать выполнение рабочих нагрузок в ожидаемом состоянии.

Поскольку мы объяснили концепцию GitOps и архитектуру конвейера CI/CD, мы воспользуемся примером для завершения этого упражнения, рассмотрев следующие четыре модуля:

Развертывание облачной инфраструктуры с использованием инфраструктуры как кода (IaC)
Развертывание Flux CD в кластере AWS EKS
Реализация рабочих процессов GitOps с использованием Flux CD
Автоматизированное развертывание на основе образов с использованием рабочих процессов GitOps

1- Развертывание облачной инфраструктуры с помощью IaC

Фундаментальный принцип DevOps заключается в том, что инфраструктура тождественна коду. Инфраструктура как код (IaC) использует код для развертывания облачной инфраструктуры и управления облачной средой. Инженеры-программисты используют файлы конфигурации или код для определения инфраструктуры и её реализации с помощью кода для обеспечения согласованности и повторяемости. Используя IaC, инженеры-программисты также управляют жизненным циклом ресурсов, например, размещают определения инфраструктуры в репозиториях с контролем версий и используют непрерывную интеграцию/развертывание (CI/CD), согласованную с программированием, для изменения определения IaC, синхронизируя среды (например, разработки, тестирования, производства) с изменениями кода IaC. Кроме того, возможен автоматический откат в случае сбоя, а обнаружение отклонений помогает выявлять отклонения от ожидаемого состояния.

В облаке инженеры-программисты могут использовать AWS Cloud Development Kit (CDK) для создания модели инфраструктуры на Python, Java и TypeScript. CDK предоставляет расширенные компоненты, называемые Constructs, которые предварительно настраивают облачные ресурсы с использованием допустимых значений по умолчанию. Он также позволяет инженерам создавать и совместно использовать собственные конструкты, соответствующие потребностям их организации. Всё это ускоряет выполнение проектов.

1.1 Создание проекта с помощью CDK CLI

Проект TypeScript CDK с cdk init Создать, который создает структуру папок и устанавливает модули, необходимые для проекта TypeScript CDK.

cdk init -- язык машинописи

1.2 Создание кластера EKS с помощью EKS Blueprints

Схемы EKS помогают создавать полноценные кластеры EKS, полностью укомплектованные операционным программным обеспечением, необходимым для развертывания и запуска рабочих нагрузок. С помощью EKS Blueprints вы описываете конфигурацию желаемого состояния вашей среды EKS, такую как панель управления, рабочие узлы и надстройки Kubernetes, в виде схемы IaC. После настройки схемы вы можете использовать её для развертывания согласованных сред в нескольких аккаунтах и регионах AWS с помощью непрерывной автоматизации.

С помощью EKS Blueprints можно легко настроить кластер EKS с плагинами Amazon EKS, а также с широким спектром популярных плагинов с открытым исходным кодом, включая Prometheus, Karpenter, Nginx, Traefik, AWS Load Balancer Controller, Fluent Bit, Keda, ArgoCD и другие. EKS Blueprints также помогает реализовать соответствующие элементы управления безопасностью, необходимые для запуска рабочих нагрузок из нескольких команд в кластере.

Каталог Быстрый старт Создайте и запустите следующие коды для установки зависимостей проекта.

mkdir quickstart cd quickstart npm install @aws-quickstart/eks-blueprints

lib/quickstart-stack.ts Откройте и введите код. Чертежи EKS Добавьте следующее.

import * as cdk from 'aws-cdk-lib'; import { Construct } from 'constructs'; import * as blueprints from '@aws-quickstart/eks-blueprints'; import { KubernetesVersion } from 'aws-cdk-lib/aws-eks'; export class QuickstartStack extends cdk.Stack { constructor(scope: Construct, id: string, props?: cdk.StackProps) { super(scope, id, props); const account = props?.env?.account!; const region = props?.env?.region!; const clusterProvider = new blueprints.GenericClusterProvider({ version: KubernetesVersion.V1_23, manageNodeGroups: [ { id: "default-ng", desiredSize: 2, minSize: 1, maxSize: 2, } ] }); const cluster = blueprints.EksBlueprint.builder() .clusterProvider(clusterProvider) .account(account) .region(region) .addOns( new blueprints.AwsLoadBalancerControllerAddOn, ) .teams(); } }

На предыдущем этапе мы создали кластер EKS, определили его NodeGroup и добавили плагин AwsLoadBalancerController.

Хотя развёртывание стека с помощью инструмента командной строки CDK удобно, мы рекомендуем настроить автоматизированный конвейер для развёртывания и обновления инфраструктуры EKS. Это упростит развёртывание процессов разработки, тестирования и производства в разных регионах.

CodePipelineStack — это фреймворк для непрерывной поставки приложений AWS CDK. При загрузке исходного кода приложения AWS CDK в Git стек автоматически собирает, тестирует и запускает новые версии. При добавлении каждого этапа или стека приложения оно автоматически перенастраивается для развертывания этих новых этапов или стеков.

Далее мы запускаем команду cdk deploy для развертывания стека.

Наконец, мы использовали команду для проверки того, что балансировщик нагрузки приложения был успешно установлен.

$ kubectl get pod -n kube-system ИМЯ ГОТОВ СОСТОЯНИЕ ПЕРЕЗАПУСКАЕТ ВОЗРАСТ aws-load-balancer-controller-6bd49cfb7-2cvlk 1/1 Работает 0 5 мин 31 с aws-load-balancer-controller-6bd49cfb7-7lcwd 1/1 Работает 0 5 мин 31 с aws-node-9hsvz 1/1 Работает 0 99 мин coredns-66cb55d4f4-gdcqg 1/1 Работает 0 106 мин coredns-66cb55d4f4-gmzjt 1/1 Работает 0 106 мин kube-proxy-wr5jn 1/1 Работает 0 99 мин

1.3 Резюме

В этом разделе мы представили концепцию IaC, создали собственный кластер EKS с CDK и установили плагин AWS Application Load Balancer. Это обеспечивает необходимое условие для доступа к веб-страницам микросервисов в будущем. Ниже приведено краткое содержание этого раздела:

Запустил проект CDK с использованием cdk init.
Быстро определил кластер EKS с помощью EKS Blueprint, добавив плагин AWS Application Load Balancer.

2. Развертывание Fluxcd в кластере Amazon EKS

Flux CD — это инструмент непрерывной поставки, разработанный Weaveworks и имеющий открытый исходный код для CNCF. Он широко используется сегодня благодаря простоте настройки и способности понимать изменения Kubernetes. Одна из важных особенностей заключается в том, что он позволяет командам управлять своими развертываниями Kubernetes декларативным образом. Flux CD синхронизирует файлы манифеста Kubernetes, хранящиеся в исходном репозитории, с кластером Kubernetes, регулярно опрашивая его. Flux CD гарантирует постоянную синхронизацию кластера Kubernetes с конфигурацией, заданной в исходном репозитории, избавляя от необходимости беспокоиться о рабочем состоянии kube ctl или отслеживать рабочие нагрузки с помощью дополнительных инструментов и сервисов. Итак, установим Flux.

2.1 Установка Flux CLI

Flux CLI — это исполняемый двоичный файл для всех платформ, который можно загрузить со страницы релиза GitHub.

curl -s https://fluxcd.io/install.sh | sudo bash

2.2 Подготовка учетных данных AWS CodeCommit

Нам необходимо создать пользователя и использовать CodeCommit в качестве источника Git, а также доступ, требуемый AWS CodeCommit через учетные данные HTTPS Git.

2.3 Установка Flux на кластер

Клонируем подготовленный код GitOps. Структура проекта следующая:

. ├── apps // Определение приложения │ ├── base // Уровень инфраструктуры приложений │ └── overlays // Уровень наложений приложений ├── clusters // Портал конфигурации кластера │ └── dev-cluster ├── infrastructure // Общие компоненты инфраструктуры │ ├── base // Уровень инфраструктуры инфраструктуры │ └── overlays // Уровень наложений инфраструктуры └── README.md

Установите Flux на кластер Kubernetes и настройте его для управления из репозитория Git с помощью начальной загрузки Flux. Если в кластере присутствуют компоненты Flux, команда начальной загрузки выполнит необходимые обновления. Начальная загрузка не имеет силы, и команду можно безопасно запускать несколько раз. Замените имя пользователя и пароль в следующей команде на ваши учётные данные HTTPS Git для AWS CodeCommit.

flux bootstrap git \ --url=https://git-codecommit.us-west-2.amazonaws.com/v1/repos/gitops \ --username=__replace_with_your_Git_credential_username__ \ --password=__replace_with_your_Git_credential_password__ \ --token-auth=true \ --path="./clusters/dev-cluster" \ --components-extra=image-reflector-controller,image-automation-controller

Используйте команду git pull для проверки обновлений, внесенных загрузчиком. В каталоге clusters/dev-cluster/flux-system репозитория Git появятся три новых файла:

gotk-components.yaml: определяет шесть контроллеров Flux: helm, Kustomize, source, notification, image automation и image reflector.
gotk-sync.yaml: исходный код Git Flux, Source Controller изменяет код мониторинга кластера в репозитории GitOps и фиксирует соответствующие изменения.
kustomization.yaml: Многокластерная конфигурация.

Проверьте, успешно ли установлен Flux, с помощью команды flux get kustomizations --watch. Вывод будет примерно таким:

$ flux get kustomizations --watch ИМЯ РЕВИЗИЯ ПРИОСТАНОВЛЕНО ГОТОВО СООБЩЕНИЕ flux-system master/83b7e66 Ложь Истина Примененная редакция: master/83b7e66 infrastructure master/83b7e66 Ложь Истина Примененная редакция: master/83b7e66

Проверьте компоненты, развёрнутые Flux-system, с помощью команды kubectl -n flux-system get pod,services . Вывод будет следующим:

$ kubectl -n flux-system get pod,services ИМЯ ГОТОВ СОСТОЯНИЕ ПЕРЕЗАПУСКАЕТ ВОЗРАСТ pod/helm-controller-88f6889c6-sblvd 1/1 Работает 0 11 м pod/image-automation-controller-6c5f7bbbd9-8xskk 1/1 Работает 0 11 м pod/image-reflector-controller-78949bb4b4-bqn4m 1/1 Работает 0 11 м pod/kustomize-controller-784bd54978-s82dq 1/1 Работает 0 11 м pod/notification-controller-648bbb9db7-627zs 1/1 Работает 0 11 м pod/source-controller-79f7866bc7-gdt95 1/1 Работает 0 11m ИМЯ ТИП CLUSTER-IP ВНЕШНИЙ-IP ПОРТ(Ы) ВОЗРАСТ service/notification-controller ClusterIP 172.20.60.72 80/TCP 11m service/source-controller ClusterIP 172.20.133.44 80/TCP 11m service/webhook-receiver ClusterIP 172.20.196.178 80/TCP 11м

2.4 Резюме

В этом разделе мы использовали команду flux bootstrap для установки Flux в кластер Kubernetes и представили три важных файла конфигурации: gotk-components.yaml, gotk-sync.yaml и kustomization.yaml. Ниже приведено краткое содержание этого раздела:

Установка клиента Flux
Создание пользователя IAM и учетных данных CodeCommit
Установите Flux на кластер Amazon EKS и включите функцию автоматического обновления образов.

3. Реализуйте рабочие процессы GitOps с помощью Flux CD

В конвейерах CI/CD GitOps изменения конфигурации и состояния кластеров EKS и рабочих нагрузок, работающих в них, инициируются изменениями кода в Git (генерируемыми запросами git push или pull. GitOps рекомендует использовать pull запросы). Традиционный конвейер CI/CD работает с движком CI и запускает команду create/apply или install/upgrade kubectl для развёртывания кластера. Таким образом, GitOps создаёт более эффективный и компактный конвейер CI/CD.

Мы продемонстрируем конкретное приложение — “Sock Shop” — и практические упражнения, чтобы продемонстрировать, как добиться непрерывной интеграции и доставки в конвейере GitOps CI/CD.

3.1 О магазине носков

В качестве примера мы возьмём пользовательскую часть интернет-магазина носков. Она разработана с использованием Spring Boot, Go Kit и Node и упакована в контейнеры Docker. Как показано в “Microservice Standard Demo”:

Лучшие практики развертывания микросервисов (включая примеры ошибок)
Возможности кроссплатформенного развертывания
Преимущества непрерывной интеграции/развертывания
Взаимодополняющая природа DevOps и микросервисов
Тестируемое “реальное” приложение для различных платформ оркестровки

Проект Socks Store состоит из 8 микросервисов front-end и back-end, которые представляют собой front-end веб-страницы, созданной на NodeJS. Название проекта: front-end. Он обращается к нескольким back-end сервисам через HTTP-запросы, включая: оформление заказов, оплату, управление пользователями, управление товарами, корзину покупок и т. д. Данные back-end сервисов хранятся в MongoDB и MySQL.

Референтная архитектура выглядит следующим образом:

3.2 О Kustomize

Помимо настройки рабочих процессов GitOps, нам также необходимо знать, как настроить Kubernetes. По мере роста сложности систем и среды становится всё сложнее поддерживать традиционное управление ресурсами на основе YAML. Необходимо поддерживать и управлять сложными бизнес-кейсами, различными средами (разработка, тестирование, предварительный выпуск, производство) и большим количеством YAML-ресурсов. Хотя Helm может решить некоторые проблемы, такие как унифицированное управление разрозненными файлами ресурсов, распространение приложений, обновление, откат и т. д., Helm затрудняет работу с небольшими различиями между средами. Кроме того, требуется освоить сложный синтаксис DSL (синтаксис шаблонов), что является серьёзным препятствием для входа. Так появился инструмент декларативного управления конфигурацией Kustomize. Kustomize помогает командам управлять большими объёмами ресурсов Kubernetes на основе YAML в разных средах и командах. Это помогает командам легко управлять небольшими различиями в средах, делает конфигурации ресурсов пригодными для повторного использования, сокращает объёмы копирования и изменения, а также значительно снижает количество ошибок конфигурации. Весь процесс настройки приложения не требует дополнительного изучения синтаксиса шаблонов.

Kustomize решает вышеуказанные проблемы следующими способами:

Kustomize поддерживает конфигурацию приложения в различных средах с помощью Base & Overlays.
Kustomize использует Patch для повторного использования базовой конфигурации и реализации, а повторное использование исходного кода достигается за счет раздела различий между описанием наложения и базовой конфигурацией приложения.
Kustomize управляет собственными файлами Kubernetes YAML без необходимости изучения синтаксиса DSL.

Согласно официальному сайту, Kustomize стал встроенным инструментом управления конфигурацией для Kubernetes, позволяющим пользователям настраивать параметры приложений без шаблонов. Kustomize использует встроенные концепции K8s для создания и повторного использования исходных конфигураций (YAML), позволяя пользователям использовать файл описания приложения (YAML) в качестве основы (Base YAML), а затем генерировать необходимый файл описания для готового развёрнутого приложения с помощью Overlays.

3.3 Многокластерная конфигурация

Понимая инструмент управления конфигурацией Kustomize, мы используем Kustomization (базу, наложения) для обеспечения возможности преобразования многокластерного развертывания.

Мы создали два каталога в проекте микросервиса: базовый каталог для хранения полных исходных файлов конфигурации (YAML) и каталог наложений для хранения различных сред или дифференциальных конфигураций кластера.

Например, в этом случае полный файл конфигурации для микросервиса — full-demo.yaml, и мы копируем его в основную папку.

cp deploy/kubernetes/complete-demo.yaml deploy/kubernetes/base/complete-demo.yaml

Затем мы ссылаемся на файл через kustomization.yaml:

# deploy/kubernetes/base/kustomization.yaml apiVersion: kustomize.config.k8s.io/v1beta1 kind: Ресурсы кастомизации: - ./complete-demo.yaml

Для среды разработки, если имеются дифференциальные требования, такие как изменение количества портов служб и копий, просто настройте дифференциальные параметры в файле overlays/development/kustomization.yaml, не копируя и не изменяя существующий full-demo.yaml.

3.4 Развертывание микросервисов с помощью рабочего процесса GitOps

После завершения поддержки нескольких кластеров для микросервисов Flux необходимо знать, что конфигурация микросервисов изменилась, поэтому мы регистрируем URL-адрес CodeCommit репозитория микросервисов (microservices-repo) в репозитории Flux (flux-repo).

3.4.1 Добавление адреса репозитория микросервисов

Возвращаемся в репозиторий Flux в папку application layer/applications:

. База

Откройте файл tenant.yaml в apps/base/sock-shop/ и замените MICRO_SERVICES_REPO на URL-адрес микросервисов: https://git-codecommit.xxx.amazonaws.com/v1/repos/microservices-repo.

apiVersion: source.toolkit.fluxcd.io/v1beta1 тип: GitRepository метаданные: имя: sock-shop-tenant пространство имен: sock-shop спецификация: интервал: 1 м url: __MICRO_SERVICES_REPO__ ссылка: ветвь: main secretRef: имя: microservices-basic-access-auth ......

3.4.2 Добавление учетных данных CodeCommit

Найдите учётную запись и пароль для команды «Подготовка учётных данных AWS CodeCommit». Перед выполнением команды преобразуйте данные в кодировку base64.

Затем откройте файл base/sock-shop/basic-access-auth.yaml и замените BASE64_USERNAME и BASE64_PASSWORD сгенерированной кодировкой base64:

--- apiVersion: v1 тип: Секретные метаданные: имя: microservices-basic-access-auth пространство имен: sock-shop тип: Непрозрачные данные: имя пользователя: __BASE64_USERNAME__ пароль: __BASE64_PASSWORD__

3.4.3 Развертывание

Добавляя URL-адрес Git микросервиса в репозиторий конфигурации Flux, Flux автоматически сканирует изменения в его конфигурации. После коммита кода Flux проверяет, развернуты ли какие-либо микросервисы в кластере, и соответствуют ли они определению в репозитории Git. В противном случае Flux автоматически развертывает микросервисы в кластере.

После выполнения кода выполните команду flux get kustomizations -watch и дождитесь обновления Flux. Развёртывание будет завершено, когда статус READY всех настроек станет True.

Поиск модулей и служб в пространстве имен хранилища носков, как показано ниже:

$ kubectl get pod,service -n sock-shop ИМЯ ГОТОВ СТАТУС ПЕРЕЗАПУСКАЕТ ВОЗРАСТ pod/carts-b4d4ffb5c-z4jrj 1/1 Работает 0 5m28s pod/carts-db-6c6c68b747-jl5pd 1/1 Работает 0 5m28s pod/catalogue-759cc6b86-qdmvc 1/1 Работает 0 5m28s pod/catalogue-db-96f6f6b4c-zgp5z 1/1 Работает 0 5m28s pod/front-end-5c89db9f57-cvbdl 1/1 Работает 0 5m28s pod/orders-7664c64d75-lqwbm 1/1 Работает 0 5m28s pod/orders-db-659949975f-qv7pl 1/1 Работает 0 5m28s pod/payment-7bcdbf45c9-szrfq 1/1 Работает 0 5m28s pod/queue-master-5f6d6d4796-nkktx 1/1 Работает 0 5m28s pod/rabbitmq-5bcbb547d7-gzhn4 2/2 Работает 0 5m28s pod/session-db-7cf97f8d4f-9mz6v 1/1 Работает 0 5m28s pod/shipping-7f7999ffb7-95rlc 1/1 Работает 0 5m27s pod/user-68df64db9c-kh247 1/1 Работает 0 5m27s pod/user-db-6df7444fc-jlkp9 1/1 Работает 0 5m27s ИМЯ ТИП CLUSTER-IP EXTERNAL-IP ПОРТ(Ы) ВОЗРАСТ service/carts ClusterIP 172.20.33.124 80/TCP 5m29s service/carts-db ClusterIP 172.20.75.163 27017/TCP 5m29s service/catalogue ClusterIP 172.20.92.254 80/TCP 5m29s service/catalogue-db ClusterIP 172.20.242.255 3306/TCP 5m29s service/front-end LoadBalancer 172.20.55.188 k8s-sockshop-frontend-12345678910-012345678910abc.elb.us-east-1.amazonaws.com 80:30001/TCP 5m29s service/orders ClusterIP 172.20.8.252 80/TCP 5m29s service/orders-db ClusterIP 172.20.40.212 27017/TCP 5m29s сервис/платеж ClusterIP 172.20.6.218 80/TCP 5m29s service/queue-master ClusterIP 172.20.153.80 80/TCP 5m29s service/rabbitmq ClusterIP 172.20.99.37 5672/TCP,9090/TCP 5m29s service/session-db ClusterIP 172.20.37.111 6379/TCP 5m29s сервис/доставка кластерный IP 172.20.43.252 80/TCP 5m29s служба/пользователь ClusterIP 172.20.220.174 80/TCP 5m29s service/user-db ClusterIP 172.20.70.57 27017/TCP 5м29с

Получите доступ к DNS-имени AWS Load Balancer.

3.5 Резюме

В этом разделе мы представили микросервисное бизнес-приложение — интернет-магазин Sock Shop — и завершили его многокластерную настройку. Мы также создали стандартный рабочий процесс GitOps на основе Flux, который автоматически синхронизирует целевой кластер с изменениями в файлах конфигурации для завершения развертывания микросервиса в кластере EKS. Кроме того, мы представили практичный инструмент управления конфигурацией K8s-Kustomize и рассказали о том, как управлять файлами ресурсов приложения. Краткое содержание этого раздела:

Представляем магазин носков
Изучите инструмент управления конфигурацией – Kustomize (базовый, наложения) и способы изменения развертываний микросервисов в нескольких кластерах.
Создайте рабочий процесс GitOps и разверните микросервисы

4. Автоматизированное развертывание на основе образов с использованием рабочих процессов GitOps

В качестве примера мы выбрали фронтенд-микросервис Sock Shop, чтобы продемонстрировать подробный процесс изменения кода, сборки образа и пользовательского выпуска с помощью рабочего процесса GitOps.

4.1 Определение CodePipeline CI

Фронтенд представляет собой чистый сервис на Node.js для поддержки упаковки образов Docker (подробнее см. в разделе «Архитектура Sock Shop» в главе 3.1). Чтобы определить процесс непрерывной интеграции (CI), выполняемый в CodePipeline, добавьте файл buildspec.yml в исходный код проекта фронтенда:

версия: 0.2 фазы: pre_build: команды: - echo Вход в Amazon ECR... - aws --version - AWS_ACCOUNT_ID=`echo $REPOSITORY_URI|cut -d"." -f1` - AWS_DEFAULT_REGION=`echo $REPOSITORY_URI|cut -d"." -f4` - echo $AWS_ACCOUNT_ID $AWS_DEFAULT_REGION - aws ecr get-login-password --region $AWS_DEFAULT_REGION | docker login --username AWS --password-stdin $REPOSITORY_HOST - COMMIT_HASH=$(echo $CODEBUILD_RESOLVED_SOURCE_VERSION | cut -c 1-7) - IMAGE_TAG=main-$COMMIT_HASH-$CODEBUILD_BUILD_NUMBER - echo $IMAGE_TAG build: команды: - echo Сборка началась `date` - echo Сборка образа Docker... - docker build -t $REPOSITORY_URI:latest. - docker tag $REPOSITORY_URI:latest $REPOSITORY_URI:$IMAGE_TAG post_build: команды: - echo Сборка завершена `date` - echo Отправка образов Docker... - docker push $REPOSITORY_URI:latest - docker push $REPOSITORY_URI:$IMAGE_TAG

Этот процесс непрерывной интеграции автоматически создаёт образ и загружает его в репозиторий ECR weaveworksdemos/front-end при изменении кода front-end. Формат тега образа: [ветка]-[коммит]-[номер сборки].

4.2 Автоматическое обновление изображений

При работе в гибкой среде с непрерывной интеграцией, например, при тестировании разработки, обновление репозитория GitOps или использование скриптов для управления новыми образами сервисов может стать настоящей проблемой. К счастью, во Flux есть отличная функция автоматического обновления образов, которая решает эту проблему. Чтобы использовать её, достаточно включить компонент обновления образов в конфигурации. Если вы ещё этого не сделали, не беспокойтесь: просто добавьте параметры --components-extra=image-reflector-controller,image-automation-controller при итерации по файлу начальной загрузки Flux для его включения.

Чтобы реализовать автоматическое обновление на основе изображений, нам необходимо выполнить следующие шаги:

Зарегистрируйте репозиторий образов микросервиса front-end, чтобы позволить Flux периодически сканировать репортер репозитория образов ECR в проекте front-end.
Настройте учётные данные для доступа к хранилищу изображений. Flux требует учётных данных для доступа к хранилищу изображений ECR и чтения информации об изображениях.
Настройте политику обновления образов. В большинстве случаев мы не хотим, чтобы все изменения в версиях образов каждый раз запускали CD. Вместо этого мы хотим, чтобы CD запускался только для указанного кода ветви (корневой ветки). Для выполнения этого требования требуется специальная политика обновления.

Далее последовательно выполним вышеперечисленные операции.

4.2.1 Добавление политики образов в интерфейс репозитория Git

В проекте microservices-repo мы будем использовать оверлеи Kustomization в среде DEV для замены интерфейса микросервиса на его модифицированную и обновлённую версию. Измените файл deploy/kubernetes/overlays/development/kustomization.yaml. (Примечание: замените ACCOUNT_ID на свой ACCOUNT_ID).

apiVersion: kustomize.config.k8s.io/v1beta1 kind: Ресурсы настройки: - ../../base images: - name: weaveworksdemos/front-end newName: __ACCOUNT_ID__.dkr.ecr.us-west-2.amazonaws.com/weaveworksdemos/front-end # {"$imagepolicy": "sock-shop:sock-shop-front-end:name"} newTag: latest # {"$imagepolicy": "sock-shop:sock-shop-front-end:tag"}

4.2.2 Регистрация front-end микросервиса в Flux-repo

В проекте flux-repo создайте новый файл apps/overlays/development/sock-shop/registry.yaml и замените ACCOUNT_ID на свой ACCOUNT_ID.

--- apiVersion: image.toolkit.fluxcd.io/v1beta1 тип: ImageRepository метаданные: имя: sock-shop-front-end пространство имен: sock-shop спецификация: изображение: __ACCOUNT_ID__.dkr.ecr.xxxx.amazonaws.com/weaveworksdemos/front-end интервал: 1m0s

4.2.3 Настройка учетных данных доступа для Amazon ECR

В Flux есть два метода получения учетных данных Amazon ECR.

Механизм автоматической аутентификации (Image Reflector Controller самостоятельно извлекает учетные данные, только для: Amazon ECR, GCP GCR, Azure ACR)
Регулярно извлекайте учетные данные (хранящиеся в кластере через Secret) с помощью CronJob.

apiVersion: kustomize.config.k8s.io/v1beta1 тип: Ресурсы настройки: - gotk-components.yaml - gotk-sync.yaml патчи: - патч: |- - операция: добавить путь: /spec/template/spec/containers/0/args/- значение: --aws-autologin-for-ecr цель: версия: v1 группа: приложения тип: Имя развертывания: image-reflector-controller пространство имен: flux-system

4.2.4 Настройка политики обновления изображений

Добавьте файл gitops/apps/overlays/development/sock-shop/policy.yaml. Следующие правила соответствуют версиям образа, таким как master-d480788-1, master-d480788-2 и master-d480788-3.

--- apiVersion: image.toolkit.fluxcd.io/v1beta1 тип: ImagePolicy метаданные: имя: sock-shop-front-end спецификация: imageRepositoryRef: имя: sock-shop-front-end фильтрТеги: шаблон: '^main-[a-fA-F0-9]+-(?P .*)' извлечение: '$buidnumber' политика: числовой: порядок: по возрастанию

Добавьте файл gitops/apps/overlays/development/sock-shop/image-automation.yaml. Автоматизация образов Flux определяет Git-репозиторий для конфигурации приложения, включая ветку, путь и другую информацию.

--- apiVersion: image.toolkit.fluxcd.io/v1beta1 вид: ImageUpdateAutomation метаданные: имя: sock-shop-front-end спецификация: git: проверка: ссылка: ветвь: основная фиксация: автор: эл. почта: [email protected] имя: fluxcdbot messageTemplate: '{{range .Updated.Images}}{{println .}}{{end}}' push: ветвь: основная интервал: 5m0s sourceRef: вид: GitRepository имя: sock-shop-tenant пространство имен: sock-shop обновление: путь: ./deploy/kubernetes/overlays/development стратегия: Сеттеры

4.3 Публикация и утверждение

Мы проверяем весь процесс автоматического обновления изображений, изменяя исходный код интерфейса.

4.3.1 Обновление кода интерфейса

Измените нижний колонтитул интерфейса и отредактируйте файл: front-end/public/footer.html.

4.3.2 Проверка CodePipeline

Изменения кода на внешнем интерфейсе автоматически запускают выполнение CodePipeline.

4.3.3 Подтверждение изменения версии образа ECR

После завершения CodePipeline войдите в консоль Amazon ECR, чтобы проверить версию образа weaveworksdemos/front-end:

4.3.4 Проверка информации об изображении потока

С помощью Flux CLI проверьте, успешно ли ImageRepository и ImagePolicy получили последнюю версию.

$ flux получить изображения все --all-namespaces ИМЯ ПРОСТРАНСТВА ИМЕН ПОСЛЕДНЕЕ СКАНИРОВАНИЕ ПРИОСТАНОВЛЕНО СООБЩЕНИЕ О ГОТОВНОСТИ sock-shop imagerepository/sock-shop-front-end 2022-09-18T14:46:45Z Ложь Истина успешное сканирование, найдено 20 тегов ИМЯ ПРОСТРАНСТВА ИМЕН ПОСЛЕДНЕЕ ИЗОБРАЖЕНИЕ СООБЩЕНИЕ О ГОТОВНОСТИ sock-shop imagepolicy/sock-shop-front-end 267314483271.dkr.ecr.us-west-2.amazonaws.com/weaveworksdemos/front-end:master-1f49071-24 Истина Последний тег изображения для '267314483271.dkr.ecr.us-west-2.amazonaws.com/weaveworksdemos/front-end' разрешен как: master-1f49071-24 ИМЯ ПРОСТРАНСТВА ИМЕН ПОСЛЕДНИЙ ЗАПУСК ПРИОСТАНОВЛЕНО СООБЩЕНИЕ О ГОТОВНОСТИ sock-shop imageupdateautomation/sock-shop-front-end 2022-09-18T14:43:51Z Ложь Истина обновления не производились; последняя фиксация 1ff6d91 в 2022-09-18T14:34:40Z

4.3.5 Исходный код микросервиса автоматически обновляется

Flux автоматически обновил версию изображения на фронтенде. Последний коммит был сделан fluxcdbot, и тег изображения был успешно изменён до последней версии: master-1f49071-24.

4.3.6 Проверка версии образа Pod

Проверьте имя пода с помощью команды kubectl get pod -n sock-shop | grep front-end. Проверьте сведения о поде с помощью команды kubectl describe pod/front-end-759476784b-9r2rt -n sock-shop | grep. Образ: для проверки версии образа выполните обновление. Результат будет выглядеть следующим образом:

$ kubectl describe pod/front-end-759476784b-9r2rt -n sock-shop | grep Изображение: Изображение: 267314483271.dkr.ecr.us-west-2.amazonaws.com/weaveworksdemos/front-end:master-1f49071-24

4.3.7 Убедитесь, что статическая страница актуальна

4.4 Резюме

В этом разделе мы подробно описали весь процесс автоматизированного развёртывания на основе образов. Вкратце, мы используем функцию непрерывного мониторинга Flux для репозиториев образов. При обнаружении изменений в версии образа система автоматически изменяет конфигурацию образа в репозитории Git и завершает автоматическое развёртывание, подключаясь к стандартному рабочему процессу GitOps, описанному в предыдущем разделе. Подводя итоги этого раздела:

Запустите процесс CI через CodePipeline, чтобы добиться непрерывной интеграции кода front-end.
Найдите и измените файл бизнес-конфигурации с помощью аннотаций Flux.
Настройте политику обновления образов Flux, чтобы Flux мог отслеживать определенные версии образов и полностью автоматизировать развертывание.

Результат

В этой статье мы рассмотрим, как использовать FluxCD для автоматизации развертывания микросервисов в кластере Amazon EKS в облаке, а также рассмотрим рекомендации по конвейерам GitOps. GitOps — это методология непрерывной поставки, включающая в себя набор рекомендаций. Жестких ограничений на создание инструментов CI/CD нет, если они соответствуют принципам GitOps.

[Общий: 1 Средний: 5/5]

Использование Flux для реализации GitOps на AWS