Учебное пособие по GitOps: как подготовить экземпляр EC2 с помощью Crossplane и Flux

В этой статье мы узнаем, как автоматизировать предоставление облачных ресурсов через Crossplane и совместить его с практиками GitOps.

Вы получите наибольшую пользу от этого блога, если вы являетесь инженером платформы или DevOps, архитектором инфраструктуры или специалистом по эксплуатации.

Если вы новичок в GitOps, узнайте больше об этом в моем блоге GitOps с Kubernetes

Давайте подготовим сцену, представив следующий контекст. Мы работаем как часть команды платформы в крупной организации. Наша цель — помочь командам разработчиков быстро освоить нашу облачную инфраструктуру.

Вот несколько базовых требований:

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

• Политика компании заключается в принятии принципа наименьших привилегий. Мы должны предоставлять облачные ресурсы только при необходимости с минимальными необходимыми разрешениями.

• Разработчики не заинтересованы в управлении облаком, они должны только потреблять облачные ресурсы , даже не входя в облачную консоль.

• Новые команды должны получить собственный набор облачных ресурсов для самоуправления при подключении к платформе.

• Должно быть легко предоставлять новые облачные ресурсы по запросу.

Исходная архитектура

Требования привели нас к первоначальному предложению по архитектуре со следующей стратегией решения высокого уровня.

• создавать репозитории шаблонов для различных типов рабочих нагрузок (используя Backstage Software Templates было бы полезно)

• как только новая команда будет подключена и создаст первый репозиторий из шаблона, она запустит конвейер CI и развернет общие компоненты инфраструктуры, добавив репозиторий в качестве источника в репозиторий инфраструктуры Flux.

• как только команда захочет создать дополнительную облачную инфраструктуру, она может поместить YAML-заявки Crossplane в указанную папку в своем репозитории.

• корректировки этого процесса легко реализуются с помощью Crossplane Compositions

В реальных условиях мы будем управлять Crossplane также с помощью Flux, но в демонстрационных целях мы сосредоточимся только на уровне приложения.

Опыт разработчика должен быть примерно таким:

Инструменты и реализация

Зная требования и начальную архитектуру, мы можем приступить к выбору инструментов. В нашем примере мы будем использовать инструменты Flux и Crossplane.

Мы собираемся использовать Flux в качестве движка GitOps, но того же можно добиться и с ArgoCD или Rancher Fleet.

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

Обзор архитектуры Flux

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

Основная роль контроллера исходного кода заключается в предоставлении стандартизированного API для управления источниками развертываний Kubernetes; Репозитории Git и Helm.

```javascript

apiVersion: source.toolkit.fluxcd.io/v1beta1

вид: GitRepository

метаданные:

имя: подинфо

пространство имен: по умолчанию

спецификация:

интервал: 1м

адрес: https://github.com/stefanprodan/podinfo

Kustomize Controller — это CD-часть рабочего процесса. Там, где исходные контроллеры указывают источники данных, этот контроллер указывает, какие артефакты запускать из репозитория.

``ямл

apiVersion: kustomize.toolkit.fluxcd.io/v1beta2

вид: Кастомизация

метаданные:

имя: веб-приложение

пространство имен: приложения

спецификация:

интервал: 5м

путь: "./развернуть"

источникСсылка:

вид: GitRepository

имя: веб-приложение

пространство имен: общее

Этот контроллер может работать с файлами настройки, а также с обычными манифестами Kubernetes

Контроллер Helm Этот оператор помогает управлять выпусками диаграммы Helm, содержащими манифесты Kubernetes, и развертывать их в кластере.

``ямл

Версия API: helm.toolkit.fluxcd.io/v2beta1

вид: HelmRelease

метаданные:

имя: бэкенд

пространство имен: по умолчанию

спецификация:

интервал: 5м

Диаграмма:

спецификация:

диаграмма: подинфо

версия: ">=4.0.0 <5.0.0"

источникСсылка:

вид: HelmRepository

имя: подинфо

пространство имен: по умолчанию

интервал: 1м

Обновить:

исправление:

remediateLastFailure: правда

тестовое задание:

включить: правда

значения:

оказание услуг:

grpcService: серверная часть

Ресурсы:

Запросы:

процессор: 100 м

память: 64Ми

Обзор кросспланной архитектуры

Давайте посмотрим, как выглядит компонентная модель Crossplane. Предупреждаю: если вы новичок в Kubernetes, это может быть ошеломляющим, но стоит попытаться понять это. На приведенной ниже диаграмме показана модель компонентов Crossplane и ее основные взаимодействия.

Источник: Автор на основе Crossplane.io

Узнайте больше о Crossplane в моем блоге «Инфраструктура как код: следующий большой сдвиг уже здесь ”

Демонстрация: Использование Flux и Crossplane

Если вы хотите следовать демоверсии, клонируйте этот репозиторий, он содержит все скрипты для запуска демо-кода.

Предпосылки

В этой демонстрации мы собираемся показать, как использовать Flux и Crossplane для предоставления экземпляра EC2 непосредственно из нового репозитория GitHub. Это имитирует присоединение новой команды к нашей платформе.

Чтобы продолжить, вам потребуется настроить интерфейс командной строки AWS на вашем локальном компьютере.

После получения учетных данных настройте профиль по умолчанию для интерфейса командной строки AWS, следуя этому руководству.

Для локальной установки вам понадобятся:

• Docker Desktop или другое время выполнения контейнера

• WSL2 при использовании Windows

• кубектл

Запустите `make в корневой папке проекта, это будет:

Если вы работаете на Mac, используйте * make setup_macвместо make.*

• Установите kind (Kubernetes IN Docker), если он еще не установлен.

• Создайте кластер KIND с именем crossplane-cluster и поменяйте контекст на него.

• Установите кроссплан с помощью руля

• Установите интерфейс командной строки crossplane, если он еще не установлен.

• Установите Flux CLI, если он еще не установлен

• Установите провайдера AWS в кластере

• Создайте временный файл с учетными данными AWS на основе профиля CLI по умолчанию.

• Создайте секрет с учетными данными AWS в пространстве имен crossplane-system.

• Настройте провайдера AWS для использования секрета для предоставления инфраструктуры.

• Удалите временный файл с учетными данными, чтобы случайно не проверить его в репозитории

Следующие инструменты необходимо установить вручную

• GitHub CLI gh

ВАЖНО: Демонстрационный код создаст небольшой экземпляр EC2 в регионе eu-centra-1. Экземпляр и базовая инфраструктура будут удалены во время демонстрации, но убедитесь, что все ресурсы были успешно удалены, и в случае каких-либо сбоев в процессе демонстрации будьте готовы удалить ресурсы вручную.

Настройка репозитория Flux

• создайте новый кластер KIND с помощью make, это установит Crossplane с поставщиком AWS и настроит секрет для доступа к выбранной учетной записи AWS.

• Flux CLI был установлен в составе скрипта Makefile, но при желании вы можете настроить завершение оболочки для CLI . <(завершение потока zsh)

• Дополнительные параметры установки см. на документации Flux .

• создайте токен доступа в GitHub с полными разрешениями репо.

• экспортировать переменные для вашего пользователя GitHub и только что созданный токен

export GITHUB_TOKEN=<токен, скопированный из GitHub>

экспорт GITHUB_USER=<ваше имя пользователя>

• использовать Flux для начальной загрузки нового репозитория GitHub, чтобы Flux мог управлять собой и базовой инфраструктурой

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

``` ударить

поток начальной загрузки github \

--owner=${GITHUB_USER} \

--repository=поток-инфра \

--path=кластеры/кроссплан-кластер \

--личный

Настройка кроссплана EC2 Состав

Теперь мы установим Crossplane Composition , которая определяет, какие облачные ресурсы создавать, когда кто-то запрашивает заявку EC2. .

• настроить состав и определение Crossplane для создания инстансов EC2

• kubectl crossplane install configuration piotrzan/crossplane-ec2-instance:v1

• разветвить репозиторий с заявками EC2 gh repo fork https://github.com/Piotr1215/crossplane-ec2 и ответить YES на запрос о клонировании репозитория

Клонировать инфраструктурный репозиторий Flux

• клонируйте репозиторий Flux Infra, созданный в ваших личных репозиториях

• git clone git@github.com:${GITHUB_USER}/flux-infra.git

• cd поток-инфра

Добавить источник

• добавить исходный репозиторий, чтобы указать Flux, что наблюдать и синхронизировать

• Flux зарегистрирует этот репозиторий и каждые 30 секунд будет проверять наличие изменений.

• выполните приведенную ниже команду в репозитории flux-infra, она добавит исходный код Git

``` ударить

поток создать исходный код git crossplane-demo \

--url=https://github.com/${GITHUB_USER}/crossplane-ec2.git \

--ветка=мастер \

--interval=30 с \

--export > clusters/crossplane-cluster/demo-source.yaml

• предыдущая команда создала файл в подпапке clusters/crossplane-cluster, зафиксируйте файл

git добавить .

git commit -m "Добавление исходного репозитория"

git push

• выполните kubectl get gitrepositories.source.toolkit.fluxcd.io -A, чтобы увидеть активные исходники репозиториев Git во Flux.

Создать настройку Flux

• настроить наблюдение за управляемыми ресурсами AWS, на данный момент их не должно быть

• смотрите, как kubectl управляется

• создать Flux Kustomization для отслеживания определенной папки в репозитории с претензией Crossplane EC2

``` ударить

поток создать настройку crossplane-demo \

--target-namespace=по умолчанию \

--source=crossplane-демо \

--path="./ec2-требование" \

--prune=истина \

--интервал=1м \

--export > кластеры/кроссплан-кластер/кроссплан-демо.yaml

git добавить .

git commit -m "Добавление экземпляра EC2"

git push

• примерно через минуту вы должны увидеть, как новый инстанс EC2 синхронизируется с Crossplane и ресурсами в AWS

Резюме: инициализация облачной инфраструктуры GitOps

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

Первый созданный нами репозиторий — это то, что Flux использует для управления собой в кластере, а также другими репозиториями. Чтобы сообщить Flux о репозитории с заявками Crossplane EC2, мы создали файл YAML GitSource, который указывает на HTTPS-адрес репозитория с заявками EC2.

Репозиторий утверждений EC2 содержит папку, в которой находятся простые файлы манифеста Kubernetes. Чтобы сообщить Flux, за какими файлами следует наблюдать, мы создали «Настройку» и связали ее с «GitSource» через ее имя. Kustomization указывает на папку, содержащую манифесты K8s.

Очистка

• чтобы очистить инстанс EC2 и базовую инфраструктуру, удалите демонстрационную версию Claim-aws.yaml из репозитория crossplane-ec2.

rm ec2-требование/требование-aws.yaml

git добавить .

git commit -m "Экземпляр EC2 удален"

• после коммита или истечения таймера Flux синхронизируется, а Crossplane подберет удаленный артефакт и удалит облачные ресурсы

папка ec2-claim должна присутствовать в репозитории после удаления yaml претензии, иначе Flux не сможет выполнить согласование

Ручная очистка

Если вы не можете использовать репозиторий, можно очистить ресурсы, удалив их из потока.

• удаление Flux kustomization flux delete kustomization crossplane-demo удалит все ресурсы из кластера и AWS.

• чтобы очистить экземпляр EC2 и базовую инфраструктуру, удалите утверждение ec2 из кластера kubectl delete VirtualMachineInstance sample-ec2

Очистка кластера

• подождите, пока наблюдайте за управлением kubectl, выходные данные не содержат никаких ресурсов AWS.

• удалить кластер с помощью make cleanup

• при желании удалить репозиторий flux-infra

Резюме: облачная инфраструктура GitOps

GitOps с Flux или Argo CD и Crossplane предлагает очень мощную и гибкую модель для разработчиков платформ. В этой демонстрации мы сосредоточились на стороне приложений с кластерами Kubernetes, развернутыми другим способом, либо с помощью Crossplane, либо Fleet, либо Cluster API и т. д.

Помимо использования модели ресурсов Crossplane, мы достигли того, что больше не взаимодействуем напрямую с kubectl для управления ресурсами, а делегируем эту деятельность Flux. Crossplane по-прежнему работает в кластере и согласовывает все ресурсы. Другими словами, мы переместили поверхность API из kubectl в Git.

Эта статья также была опубликована [здесь] (https://piotrzan.medium.com/gitopsify-cloud-infrastructure-with-crossplane-and-flux-d605d3043452)