Введение в GitOps для OpenShift

    Сегодня мы расскажем о принципах и моделях GitOps, а также о том, как эти модели реализуются на платформе OpenShift. Интерактивное руководство на эту тему доступно по ссылке.



    Если вкратце, то GitOps – это набор практических методов использования pull-запросов Git для управления конфигурациями инфраструктуры и приложений. Git-репозиторий в рамках GitOps рассматривается как один единственный источник сведений о состоянии системы, причем любые изменения этого состояния полностью отслеживаются и поддаются аудиту.

    Идея с отслеживаемостью изменений в GitOps отнюдь не нова, такой подход уже давно и практически повсеместно применяется при работе с исходным кодом приложений. GitOps просто реализует аналогичные функции (review-проверки, pull-запросы, теги и т. д.) при управлении конфигурациями инфраструктуры и приложений и дает аналогичные преимущества, как в случае управления исходным кодом.

    Для GitOps нет какого-то академического определения или утвержденного свода правил, лишь свод принципов, на которых строится эта практика:

    • Декларативное описание системы хранится в репозитории Git (конфиги, мониторинг и т. д).
    • Изменения состояния выполняются через pull-запросы.
    • Состояние работающих систем приводится в соответствие с данными в репозитории с помощью push-запросов Git.

    Принципы GitOps


    • Определения систем описываются как исходный код

    Конфигурация систем рассматривается как код, поэтому ее можно хранить и автоматически версионировать в репозитории Git, который служит единственным источником истины. Такой подход позволяет легко накатывать (rollout) и откатывать (rollback) изменения в системах.

    • Желаемое состояние и конфигурация систем задаются и версионируются в Git

    Храня и версионируя в Git желаемое состояние систем, мы получаем возможность легко накатывать и откатывать изменения в системах и приложениях. Также мы можем использовать Git'овские механизмы безопасности для контроля владения кодом и подтверждения его подлинности.

    • Изменения в конфигурациях могут автоматически применяться с помощью pull-запросов

    Используя Git’овские pull-запросы, мы можем легко управлять тем, как изменения применяются к конфигурациям в репозитории. Например, их можно отдать на проверку другим участникам команды или прогнать через тесты CI и пр.

    И при этом не нужно раздавать админские полномочия направо и налево. Чтобы выполнить commit изменений в конфигурации, пользователи достаточно соответствующих полномочий в репозитории Git, где хранятся эти конфигурации.

    • Устранение проблемы неконтролируемого дрифта конфигураций

    Когда желаемое состояние системы хранится в репозитории Git, нам остается только найти софт, который бы контролировал, что текущее состояние системы соответствует ее желаемому состоянию. Если это не так, то этот софт должен – в зависимости от настроек – либо самостоятельно устранить несоответствие, либо уведомить нас о дрифте конфигураций.

    Модели GitOps для OpenShift


    On-Cluster Resource Reconciller


    Согласно этой модели в кластере есть контроллер, который отвечает за сравнение Kubernetes-ресурсов (файлов YAML) в Git-репозитории с реальными ресурсами кластера. При выявлении расхождений контроллер рассылает уведомления и, возможно, принимает меры для устранения несоответствий. Эта модель GitOps используется в Anthos Config Management и Weaveworks Flux.



    External Resource Reconciler (Push)


    Эту модель можно рассматривать как разновидность предыдущей, когда у нас есть один или несколько контроллеров, отвечающих за синхронизацию ресурсов в парах «репозиторий Git – кластер Kubernetes». Отличие же здесь в том, что в каждом управляемом кластере необязательно должен быть свой отдельный контроллер. Пары «Git – кластер k8s» часто определяются как CRD-описания (custom resources definition), в которых можно описать, как контроллер должен выполнять синхронизацию. В рамках этой модели контроллеры сравнивают Git-репозиторий, заданный в CRD, с ресурсами кластера Kubernetes, которые тоже заданы в CRD, и выполняют соответствующие действия по результатам сравнения. В частности, такая модель GitOpsиспользуется в ArgoCD.



    GitOps на платформе OpenShift


    Администрирование мультикластерной Kubernetes-инфраструктуры


    С распространением Kubernetes и ростом популярности мультиоблачных стратегий и периферийных вычислений (edge computing) увеличивается и среднее количество кластеров OpenShift в расчете на одного заказчика.

    Например, при использовании периферийных вычислений кластеры одного заказчика могут развертываться сотнями и даже тысячами. В результате он вынужден управлять несколькими независимыми или согласованными кластерами OpenShift в публичном облаке и on-premise.

    При этом приходится решать массу проблем, в частности:

    • Контролировать, что кластеры находятся в идентичном состоянии (конфиги, мониторинг, хранилища и т. д.)
    • Повторно создавать (или восстанавливать) кластеры по известному состоянию.
    • Создавать новые кластеры по известному состоянию.
    • Накатывать изменения на нескольких кластерах OpenShift.
    • Откатывать изменений на нескольких кластерах OpenShift.
    • Увязывать шаблонизированные конфигураций с различными средами.

    Конфигурации приложения


    В ходе своего жизненного цикла приложения часто проходят через цепочку кластеров (dev, stage и т. д.), прежде чем попасть в продакшн-кластер. Кроме того, из-за требований доступности и масштабируемости заказчики часто развертывают приложения сразу на нескольких кластерах on-premise или в нескольких регионах публичной облачной платформы.

    При этом приходится решать следующие задачи:
    • Обеспечивать движение приложений (бинарники, конфиги и т. д) между кластерам (dev, stage и т. д.).
    • Накатывать изменения в приложениях (бинарники, конфиги и т. д) в нескольких кластерах OpenShift.
    • Откатывать изменения в приложениях до уровня предыдущей известного состояния.

    Сценарии использования OpenShift GitOps


    1. Применение изменений из Git-репозитория


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

    2. Синхронизация с Secret Manager


    Админу также пригодится возможность синхронизировать secret-объекты OpenShift с соответствующим ПО наподобие Vault, чтобы управлять ими с помощью специально созданных для этого инструментов.

    3. Контроль дрифта конфигураций


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

    4. Уведомления о дрифте конфигураций


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

    5. Ручная синхронизация конфигураций при дрифте


    Позволяет админу синхронизировать кластер OpenShift с репозиторием Git в случае дрифта конфигураций, чтобы быстро вернуть кластер к предыдущему известному состоянию.

    6.Автосихронизация конфигураций при дрифте


    Админ также может настроить кластер OpenShift на автоматическую синхронизацию с репозиторием при обнаружении дрифта, чтобы конфигурация кластера всегда соответствовала конфигами в Git’е.

    7. Несколько кластеров – один репозиторий


    Админ может хранить в одном репозитории Git конфигурации сразу нескольких различных кластеров OpenShift и выборочно применять их по мере надобности.

    8. Иерархия кластерных конфигураций (наследование)


    Админ может задать иерархию кластерных конфигураций в репозитории (stage, prod, app portfolio и т. д с наследованием). Иначе говоря, он может определять, как должны применяться конфигурации – к одному или к нескольким кластерам.

    Например, если админ задает в Git репозитории иерархию «Продакшн кластеры (prod) → Кластеры системы X → Продакшн кластеры системы X», то к продакшн-кластерам системы X применяется объединение следующих конфигов:

    • Конфиги, общие для всех продакшн-кластеров.
    • Конфиги для кластера системы X.
    • Конфиги для продакшн-кластера системы X.

    9. Шаблоны и переопределение конфигураций


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

    10. Избирательные include’ы и exclude’ы для конфигураций, конфигурации приложений


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

    11. Поддержка шаблонов


    Разработчикам пригодится возможность выбирать, как будут определяться ресурсы приложения (Helm Chart, чистый Kubernetes’овский yaml и т. д), чтобы использовать наиболее подходящий формат для каждого конкретного приложения.

    Инструменты GitOps на платфомре OpenShift


    ArgoCD


    ArgoCD реализует модель External Resource Reconcile и предлагает централизованный UI для оркестрации отношений между кластерами и Git-репозиториями по схеме «один ко многим». К недостаткам этой программы можно отнести невозможность управлять приложениями при неработающем ArgoCD.

    Официальный сайт

    Flux


    Flux реализует модель On-Cluster Resource Reconcile, и, как следствие, здесь нет централизованного управления репозиторием определений, что является слабым местом. С другой стороны, именно из-за отсутствия централизации возможность управлять приложениями сохраняется и при выходе из строя одного кластера.

    Официальный сайт

    Установка ArgoCD на OpenShift


    ArgoCD предлагает отличный интерфейс командной строки и веб-консоль, поэтому здесь мы не будем рассматривать Flux и другие альтернативы.

    Чтобы развернуть ArgoCD на платформе OpenShift 4, выполните следующие шаги в качестве администратора кластера:

    Развертывание компонентов ArgoCD на платформе OpenShift


    # Create a new namespace for ArgoCD components
    oc create namespace argocd
    # Apply the ArgoCD Install Manifest
    oc -n argocd apply -f https://raw.githubusercontent.com/argoproj/argo-cd/v1.2.2/manifests/install.yaml
    # Get the ArgoCD Server password
    ARGOCD_SERVER_PASSWORD=$(oc -n argocd get pod -l "app.kubernetes.io/name=argocd-server" -o jsonpath='{.items[*].metadata.name}')

    Доработка ArgoCD Server, чтобы его видел OpenShift Route


    # Patch ArgoCD Server so no TLS is configured on the server (--insecure)
    PATCH='{"spec":{"template":{"spec":{"$setElementOrder/containers":[{"name":"argocd-server"}],"containers":[{"command":["argocd-server","--insecure","--staticassets","/shared/app"],"name":"argocd-server"}]}}}}'
    oc -n argocd patch deployment argocd-server -p $PATCH
    # Expose the ArgoCD Server using an Edge OpenShift Route so TLS is used for incoming connections
    oc -n argocd create route edge argocd-server --service=argocd-server --port=http --insecure-policy=Redirect

    Развертывание ArgoCD Cli Tool


    # Download the argocd binary, place it under /usr/local/bin and give it execution permissions
    curl -L https://github.com/argoproj/argo-cd/releases/download/v1.2.2/argocd-linux-amd64 -o /usr/local/bin/argocd
    chmod +x /usr/local/bin/argocd

    Смена админского пароля ArgoCD Server


    # Get ArgoCD Server Route Hostname
    ARGOCD_ROUTE=$(oc -n argocd get route argocd-server -o jsonpath='{.spec.host}')
    # Login with the current admin password
    argocd --insecure --grpc-web login ${ARGOCD_ROUTE}:443 --username admin --password ${ARGOCD_SERVER_PASSWORD}
    # Update admin's password
    argocd --insecure --grpc-web --server ${ARGOCD_ROUTE}:443 account update-password --current-password ${ARGOCD_SERVER_PASSWORD} --new-password

    После выполнения этих шагов с ArgoCD Server можно работать через веб-консоль ArgoCD WebUI или инструментарий командной строки ArgoCD Cli.
    https://blog.openshift.com/is-it-too-late-to-integrate-gitops/

    GitOps – никогда не поздно


    «Поезд ушел» – так говорят о ситуации, когда возможность что-то сделать упущена. В случае с OpenShift желание тут же начать использовать эту новую классную платформу часто создает именно такую ситуацию с управлением и обслуживанием маршрутов, deployment’ов и других объектов OpenShift. Но всегда ли шанс окончательно упущен?

    Продолжая серию статей о GitOps, сегодня мы покажем, как преобразовать созданное вручную приложение и его ресурсы в некий процесс, где всем управляет инструментарий GitOps. Для этого мы сначала руками развернем приложение httpd. На скрине ниже показано, как мы создаем пространство имен, deployment и сервис, а потом делаем expose для этого сервиса, чтобы создать маршрут.

    oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/namespace.yaml
    oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/deployment.yaml
    oc create -f https://raw.githubusercontent.com/openshift/federation-dev/master/labs/lab-4-assets/service.yaml
    oc expose svc/httpd -n simple-app

    Итак, у нас есть созданное вручную приложение. Теперь его надо перевести под управление GitOps без потери доступности. Вкратце, это делает так:

    • Создаем Git-репозиторий для кода.
    • Экспортируем наши текущие объекты и загружаем их в репозиторий Git.
    • Выбираем и развертываем инструментарий GitOps.
    • Добавляем в этот инструментарий наш репозиторий.
    • Определяем приложение в нашем инструментарии GitOps.
    • Выполняем пробный запуск приложения, используя инструментарий GitOps.
    • Синхронизируем объекты с помощью инструментария GitOps.
    • Включаем очистку (pruning) и автосинхронизацию объектов.

    Как уже говорилось в предыдущей статье, в GitOps есть один и только один источник сведений обо всех объектах в кластере(ах) Kubernetes – репозиторий Git. Далее мы исходим из предпосылки, что у вас в организации уже используется Git-репозиторий. Он может быть публичным или частным, но он в обязательном порядке должен быть доступен кластерам Kubernetes. Это может быть тот же самый репозиторий, что и для кода приложений, или же отдельный репозиторий, созданный специально для deployment’ов. В репозитории рекомендуется иметь строгие разрешения, поскольку там будут храниться объекты secret, маршруты и другие чувствительные по безопасности вещи.

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

    Если YAML-файлы объектов не хранились локально или в Git'е, то придется воспользоваться бинарниками oc или kubectl. На скрине ниже мы запрашиваем YAML для нашего пространства имен, deployment’а, сервиса и маршрута. Перед этим мы клонировали только что созданный репозиторий и перешли в него командой cd.

    oc get namespace simple-app -o yaml --export > namespace.yaml
    oc get deployment httpd -o yaml -n simple-app --export > deployment.yaml
    oc get service httpd -o yaml -n simple-app --export > service.yaml
    oc get route httpd -o yaml -n simple-app --export > route.yaml

    Теперь поправим файл deployment.yaml, чтобы удалить из него поле, которое Argo CD не может синхронизировать.

    sed -i '/\sgeneration: .*/d' deployment.yaml

    Кроме того, надо изменить маршрут. Сначала мы зададим многострочную переменную, а затем заменим ingress: null на содержимое этой переменной.

    export ROUTE="  ingress:\\                                                            
        - conditions:\\
            - status: 'True'\\
              type: Admitted"
    
    sed -i "s/  ingress: null/$ROUTE/g" route.yaml

    Так, с файлами разобрались, осталось сохранить их в Git-репозиторий. После чего этот репозиторий становится одним-единственным источником сведений, и любые ручные изменения объектов должны быть строго запрещены.

    git commit -am ‘initial commit of objects’
    git push origin master

    Далее мы исходим из того, что ArgoCD у вас уже развернут (как это сделать – см. предыдущий пост). Поэтому добавим в Argo CD созданный нами репозиторий, содержащий код приложения из нашего примера. Только убедитесь, что указываете именно тот репозиторий, который создали ранее.

    argocd repo add https://github.com/cooktheryan/blogpost

    Теперь создаем приложение. Приложение задает значения, чтобы инструментарий GitOps понимал, какой репозиторий и пути использовать, какой OpenShift необходим для управления объектами, а также какая конкретная ветвь репозитория нужна, и должна ли выполняться автосихронизация ресурсов.

    argocd app create --project default \
    --name simple-app --repo https://github.com/cooktheryan/blogpost.git \
    --path . --dest-server https://kubernetes.default.svc \
    --dest-namespace simple-app --revision master --sync-policy none

    После того, как приложение задано в Argo CD, этот инструментарий начинает проверять уже развернутые объекты на соответствие определениям в репозитории. В нашем примере автосинхронизация и очистка отключены, поэтому элементы пока не меняются. Обратите внимание, что в интерфейсе Argo CD наше приложение будет иметь статус «Out of Sync» (Не синхронизировано), поскольку нет label-метки, которую проставляет ArgoCD.
    Именно поэтому, когда мы чуть позднее запустим синхронизацию, повторное развертывание объектов выполняться не будет.

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

    argocd app sync simple-app --dry-run

    Если ошибок нет, то можно переходить к синхронизации.

    argocd app sync simple-app

    После выполнения команды argocd get над нашим приложением, мы должны увидеть, что статус приложения изменился на Healthy (Исправно) или Synced (Синхронизировано). Это будет означать, что все ресурсы в репозитории Git теперь соответствует тем ресурсам, что уже развернуты.

    argocd app get simple-app
    Name:               simple-app
    Project:            default
    Server:             https://kubernetes.default.svc
    Namespace:          simple-app
    URL:                https://argocd-server-route-argocd.apps.example.com/applications/simple-app
    Repo:               https://github.com/cooktheryan/blogpost.git
    Target:             master
    Path:               .
    Sync Policy:        <none>
    Sync Status:        Synced to master (60e1678)
    Health Status:      Healthy
    ...   

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

    argocd app set simple-app --sync-policy automated --auto-prune

    Итак, мы успешно перевели под управление GitOps приложение, которое изначально никак не использовало GitOps.
    Red Hat
    42.71
    Программные решения с открытым исходным кодом
    Share post

    Comments 0

    Only users with full accounts can post comments. Log in, please.