Argo#

Argo — это комплекс инструментов управления GitOps для DropApp.

Argo CD, Argo Workflows, Argo Rollouts и Argo Events - это отдельные инструменты, которые могут быть использованы вместе для создания полноценной системы управления и мониторинга рабочих процессов в DropApp:

  1. Argo CD (Continuous Delivery) - это инструмент для непрерывной доставки приложений в DropApp. Позволяет автоматически развертывать и обновлять приложения в кластере DropApp, основываясь на изменениях в исходном коде или конфигурации.

  2. Argo Workflows - это инструмент для управления рабочими процессами в DropApp. Позволяет создавать, запускать и отслеживать рабочие процессы, состоящие из нескольких контейнеров или задач.

  3. Argo Rollouts - это инструмент для управления обновлениями приложений в DropApp. Позволяет выполнять постепенные обновления приложений, отслеживать их состояние и откатывать изменения в случае необходимости.

  4. Argo Events - это инструмент для мониторинга и управления событиями в DropApp. Позволяет отслеживать события, происходящие в кластере, и автоматически реагировать на них, запуская определенные рабочие процессы или уведомляя администраторов.

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

Argo CD#

Argo CD - инструмент для непрерывной доставки приложений, который использует модель GitOps для управления настройками DropApp-кластера. Это означает, что репозиторий Git используется в качестве единственного истинного источника для системы управления доставкой приложений. Argo CD может автоматически обновлять приложения в DropApp-кластере при изменениях в репозитории Git.

Argo CD предоставляет функции:

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

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

  3. Поддержка различных инструментов управления конфигурациями: поддерживает различные инструменты, такие как Kustomize, Helm, Jsonnet, plain-YAML, что обеспечивает гибкость в выборе инструментов шаблонизации.

  4. Многокластерное развертывание: позволяет управлять приложениями в нескольких кластерах DropApp.

  5. Интеграция SSO: поддерживает интеграцию с различными протоколами единого входа, такими как OIDC, OAuth2, LDAP, SAML 2.0, а также интеграцию с популярными сервисами авторизации, такими как GitHub, GitLab.

  6. Многозадачность и управление доступом RBAC: обеспечивает возможность определения ролей и политик управления доступом для безопасной авторизации.

  7. Откат к предыдущим конфигурациям: позволяет легко откатываться к предыдущим версиям конфигураций приложений в случае неудачного развертывания.

  8. Мониторинг состояния приложения: предоставляет инструменты для анализа состояния здоровья ресурсов приложения.

  9. Обнаружение и визуализация изменений конфигурации: автоматически обнаруживает и визуализирует конфигурации для удобства отслеживания.

  10. Синхронизация приложений: обеспечивает возможность автоматической или ручной синхронизации приложений с их желаемым состоянием.

  11. Веб-интерфейс и CLI: предоставляет удобный веб-интерфейс и CLI для управления приложениями.

  12. Интеграция с webhook: поддерживает интеграцию с webhooks от популярных сервисов контроля версий, таких как GitHub, BitBucket, GitLab.

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

  14. Hooks для сложных развертываний: поддерживает hooks (PreSync, Sync, PostSync) для поддержки сложных сценариев развертывания (e.g.blue/green & canary upgrades).

  15. Журнал аудита: ведет журнал событий приложения и вызовов API для целей аудита и отладки.

  16. Метрики Prometheus: предоставляет метрики для мониторинга производительности Argo CD.

  17. Переопределение параметров Helm: поддерживает возможность переопределения параметров Helm непосредственно из репозитория Git. Это может быть полезным, если необходимо настроить значения Helm-чартов для различных окружений или специфических требований.

Установка Argo CD#

Для выполнения данного сценария необходимы права администратора.

  1. Установите Argo CD последовательностью команд:

    kubectl create namespace argocd
kubectl apply -n argocd -f https://<repoexample.ru>/argoproj/argo-cd/stable/manifests/install.yaml
# Укажите актуальный путь до локального репозитория
# Создайте новое namespace agrocd, в котором будут расположены сервисы Agro CD и ресурсы приложений.

  2. Загрузите интерфейс командной строки Argo CD:

    kubectl exec -it -n argo <argocdpod> --argo admin initial-password -n argocd

Сценарии использования Argo CD#

Получение доступа к Argo CD API-серверу#

По умолчанию Argo CD API-сервер не имеет внешнего IP-адреса. Чтобы получить доступ, выберите один из следующих способов предоставления доступа к Argo CD API-серверу:

  1. Измените тип службы argocd-server на LoadBalancer:

    kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "LoadBalancer"}}'

  2. Используйте Ingress, чтобы настроить сеть для Argo CD.

  3. Настройте переадресацию порта kubectl для подключения к API-серверу:

    kubectl port-forward svc/argocd-server -n argocd 8080:443

    Также доступ к API-серверу можно получить, используя https://localhost:8080.

Авторизация и изменение пароля в Argo CD для управления конфигурациями приложений в DropApp#

  1. Войдите с помощью интерфейса командной строки. Первоначальный пароль для учетной записи admin генерируется автоматически и сохраняется в открытом виде в поле password secret с именем argocd-initial-admin-secret. Получите этот пароль с помощью argocdCLI:

    argocd admin initial-password -n argocd

    Примечание

    Удалите argocd-initial-admin-secret из namespace Argo CD после изменения пароля. Secret хранит только первоначально сгенерированный пароль в открытом виде, и его можно безопасно удалить в любое время. Он будет воссоздан по запросу Argo CD, если потребуется повторно сгенерировать новый пароль администратора.

  2. Используя имя пользователя admin и пароль, указанный выше, войдите в систему по IP-адресу или имени хоста Argo CD:

    argocd login <ARGOCD_SERVER>

  3. Измените пароль с помощью команды:

     argocd account update-password

    Вышеприведенная команда используется для обновления пароля учетной записи в Argo CD. Argo CD - это инструмент для управления конфигурациями приложений и их развертываниями в DropApp. Эта команда позволяет обновить пароль учетной записи, используемой для аутентификации Argo CD с кластером DropApp.

Создание и развертывание приложения в Argo CD#

  1. Создайте приложение из репозитория. Установите текущее namespace в Argo CD, выполнив следующую команду:

    kubectl config set-context --current --namespace=argocd

  2. Создайте приложение с помощью следующей команды:

    argocd app create guestbook --repo https://<repoexample.ru>/argoproj/argocd-example-apps.git --path guestbook --dest-server https://kubernetes.default.svc --dest-namespace default
# Укажите актуальный путь до локального репозитория

    Эта команда создает новое приложение в Argo CD. Она использует синтаксис argocd <команда> <параметры>.

    Арго CD - это инструмент автоматизации, который упрощает развертывание и управление приложениями в DropApp. Он помогает управлять зависимостями между приложениями, а также обеспечивает безопасность и контроль версий.

    В данном случае команда argocd app создает новое приложение с именем guestbook и определяет следующие параметры:

    • repo: ссылка на репозиторий приложения, в данном случае https://<repoexample.ru>.com/argoproj/argocd-example-apps.git;

    • path: путь в репозитории, где находится приложение, в данном случае guestbook;

    • dest-server: URL сервера DropApp, на котором будет развернуто приложение;

    • dest-namespace: namespace, в котором будет развернут контейнер приложения.

    После выполнения команды Argo CD создаст новый ресурс для приложения и загрузит его в указанный репозиторий.

  3. Проверьте статус приложения:

    argocd app get guestbook
Name:               guestbook
Server:             https://kubernetes.default.svc
Namespace:          default
URL:                https://<IP-address>/applications/guestbook
Repo:               https://<repoexample.ru>.com/argoproj/argocd-example-apps.git
Target:
Path:               guestbook
Sync Policy:        <none>
Sync Status:        OutOfSync from  (1ff8a67)
Health Status:      Missing

GROUP  KIND        NAMESPACE  NAME          STATUS     HEALTH
apps   Deployment  default    guestbook-ui  OutOfSync  Missing
      Service     default    guestbook-ui  OutOfSync  Missing

    Состояние приложения изначально находится в статусе OutOfSync, так как приложение еще не развернуто, а ресурсы DropApp не созданы.

  4. Используйте команду для синхронизации приложения guestbook в Argo CD:

    argocd app sync guestbook

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

Argo Workflows#

Argo Workflows - контейнерно-нативный механизм рабочих процессов с открытым исходным кодом для оркестровки параллельных заданий на DropApp. Argo Workflows реализован как DropApp CRD (Custom Resource Definition). Также он может выполнять CI и CD pipeline.

Argo Workflows предоставляет набор инструментов и компонентов для создания, запуска и управления рабочими процессами:

  1. Argo CLI (Command Line Interface) - это интерфейс командной строки, который позволяет взаимодействовать с Argo Workflows. С его помощью можно создавать, запускать и управлять рабочими процессами.

  2. Argoexec - это инструмент, который позволяет выполнять команды в контейнерах DropApp. Используется для запуска задач внутри рабочих процессов Argo Workflows.

  3. Workflow-controller - это компонент, который управляет рабочими процессами в DropApp. Отслеживает состояние рабочих процессов, запускает задачи и обеспечивает их корректное выполнение.

Таким образом, Argo Workflows предоставляет удобный и мощный инструмент для управления рабочими процессами в DropApp, который может быть использован для автоматизации различных задач в кластере.

Установка Argo Workflows#

Для выполнения данного сценария необходимы права администратора.

  1. Создайте namespace в кластере DropApp под названием argo-workflows:

    kubectl create namespace argo-workflows

  2. Применяет манифест из указанного URL-адреса в namespace argo:

    kubectl apply -n argo -f https://<repoexample.ru>/argoproj/argo-workflows/releases/download/v<3.5.4>/quick-start-minimal.yaml
# Укажите актуальный путь до локального репозитория

  3. Загрузите интерфейс командной строки Argo Workflows:

     kubectl exec -it -n argo <argocdpod> --argo admin initial-password -n argo-workflows

Сценарии использования Argo Workflows#

Внедрение Argo Workflows: настройка и развертывание системы мониторинга и управления рабочими процессами в DropApp#

Для использования Argo Workflows выполните последовательность действий, указанную ниже.

  1. Установите патч аутентификации Argo Server:

    kubectl patch deployment \
  argo-server \
  --namespace argo \
  --type='json' \
  -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/args", "value": [
  "server",
  "--auth-mode=server"
]}]'

  2. Перенесите пользовательский интерфейс: откройте порт-forward для получения доступа к пользовательскому интерфейсу:

    kubectl -n argo port-forward deployment/argo-server 2746:2746

    Команда kubectl -n argo port-forward deployment/argo-server запускает пересылку порта 2746 на хост-машину для контейнера, который находится в deployment argo-server. В результате пользовательский интерфейс будет доступен по адресу: https://localhost:2746. Из-за самоподписанного сертификата, может возникнуть ошибка TLS 1.2, которую необходимо подтвердить.

    Команда kubectl -n argo port-forward deployment/argo-server 2746:2746 открывает локальный порт 2746 в машине и перенаправляет трафик на порт 2746 в pod, который соответствует развертыванию argo-server в namespace argo. Это позволяет получить доступ к сервису, предоставляемому argo-server, через локальный порт 2746 на машине.

  3. Отправьте пример рабочего процесса (CLI):

    argo submit -n argo --watch https://<repoexample.ru>/argoproj/argo-workflows/master/examples/hello-world.yaml
# Укажите актуальный путь до локального репозитория

    Флаг --watch использованный в синтаксисе команды позволит наблюдать за процессом во время выполнения и статусом его завершения.

  4. Перечислите все рабочие процессы, выполнив команду:

    argo list -n argo

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

  5. Просмотрите сведения о запуске рабочего процесса, выполнив команду:

    argo get -n argo @latest

    Аргумент @latest CLI — это ярлык для просмотра последнего выполненного рабочего процесса.

  6. Просмотрите журналы рабочего процесса, выполнив команду:

    argo logs -n argo @latest

Argo Rollouts#

Argo Rollouts - утилита расширения, которая обеспечивает функциональность управления различными типами событий в DropApp. Может автоматически управлять внедрением обновлений приложений, переключением между версиями приложений и откатом к предыдущим версиям приложений в кластере DropApp.

В данном разделе представлены концепции и функции Argo Rollouts: развертывание, обновление, продвижение и прекращение развертывания.

Сценарий использования Argo Rollouts#

Внедрение Argo Rollouts: настройка и развертывание системы мониторинга и управления обновлениями в DropApp#

Для использования Argo Rollouts выполните последовательность действий, указанную ниже.

  1. Разверните ресурс Argo Rollouts:

    spec:
  replicas: 5
  strategy:
    canary:
      steps:
      - setWeight: 20
      - pause: {}
      - setWeight: 40
      - pause: {duration: 10}
      - setWeight: 60
      - pause: {duration: 10}
      - setWeight: 80
      - pause: {duration: 10}

    Выше приведен пример развертывания, который использует постепенную стратегию обновления. Такая стратегия называется canary и состоит из следующих шагов:

    • установка веса на уровне 20% для нового развертывания. Пауза на 1 секунду;

    • установка веса на уровне 40% для развертывания. Пауза на 2 секунды;

    • установка веса на уровне 60% для развертывания. Пауза на 3 секунды;

    • установка веса на уровне 80% для развертывания. Пауза на 4 секунды.

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

  2. Выполните следующую команду для начального развертывания и службы:

    kubectl apply -f https://<repoexample.ru>/argoproj/argo-rollouts/master/docs/getting-started/basic/rollout.yaml
# Укажите актуальный путь до локального репозитория

    Создание любого развертывания увеличивает масштаб реплик до 100 % (пропуская все этапы постепенного обновления, анализ и т. д.), поскольку обновление не выполнялось.

  3. Выполните следующую команду, которая содержит информацию о создании сервиса в кластере DropApp:

    kubectl apply -f https://<repoexample.ru>/argoproj/argo-rollouts/master/docs/getting-started/basic/service.yaml
# Укажите актуальный путь до локального репозитория

  4. Чтобы визуализировать процесс развертывания во времени, запустите команду get rollout --watch:

    kubectl argo rollouts get rollout rollouts-demo --watch

  5. Выполните следующую команду, чтобы обновить rollouts-demo развертывание контейнера:

    kubectl argo rollouts set image rollouts-demo \
 rollouts-demo=argoproj/rollouts-demo:yellow

    В приведенном сценарии deployment имеет версию с именем «yellow».

    Как и в случае с развертываниями, любое изменение в поле шаблона pod (spec.template) приводит к развертыванию новой версии (то есть набора реплик). Обновление развертывания включает в себя изменение спецификации развертывания, обычно изменение поля изображения контейнера с новой версией, а затем применение нового манифеста kubectl apply. Для удобства подключаемый модуль развертывания предоставляет команду set image, которая выполняет эти действия на месте объекта динамического развертывания.

    Во время развертывания обновления контроллер будет выполнять шаги, определенные в стратегии обновления развертывания. Пример развертывания задает вес трафика 20% и приостанавливает развертывание на неопределенный срок, пока пользователь не предпримет действия для возобновления/продвижения развертывания.

  6. После обновления образа убедитесь, что статус обновления находится в состоянии паузы при помощи команды:

    kubectl argo rollouts get rollout rollouts-demo --watch

    Вывод будет следующим:

    Name:               rollouts demo
Namespace           default
Status:             Paused
Strategy:           Canary
    Step:           1/8
    SetWeight:      20
    ActualWeight    20
Images              argoj/rollouts-demo:blue (stable)
                    argoj/rollouts-demo:yellow (canary)
Replicas:
    Desired:        5
    Current:        5
    Updated:        1
    Ready:          5
    Avalible:       5
...

    Когда демонстрационный deployment достигает второго шага, deployment остается в состоянии паузы и имеет 1 из 5 реплик, на которых запущена новая версия шаблона модуля «yellow», и 4 из 5 реплик, на которых запущена старая версия «blue». Это соответствует 20% веса, как определено на setWeight: 20.

  7. Когда deployment достигает шага pause, deployment остается в состоянии паузы на неопределенный срок, пока не будет возобновлено/продвинуто. Чтобы вручную перевести deployment на следующий шаг, выполните команду плагина promote:

    kubectl argo rollouts promote rollouts-demo

  8. После продвижения Argo Rollouts продолжит выполнение оставшихся шагов. Остальные шаги развертывания в примере полностью автоматизированы, поэтому deployment в конечном итоге будет выполнять шаги до тех пор, пока полностью не перейдет на новую версию. Просмотрите deployment еще раз, пока не будут выполнены все шаги:

    kubectl argo rollouts get rollout rollouts-demo --watch

    Вывод команды будет следующим:

    Name:               rollouts demo
Namespace           default
Status:             Paused
Strategy:           Canary
    Step:           8/8
    SetWeight:      100
    ActualWeight    100
Images              argoj/rollouts-demo:yellow (canary)
Replicas:
    Desired:        5
    Current:        5
    Updated:        5
    Ready:          5
    Avalible:       5
...

    После успешного завершения всех шагов новый набор реплик помечается как «стабильный» (stable) набор реплик. Всякий раз, когда deployment прерывается во время обновления автоматически из-за неудачного анализа или вручную пользователем, deployment возвращается к «стабильной» версии.

  9. Для прерывания развертывания создайте новую версию контейнера с помощью команды set image команды и подождите, пока deployment снова не достигнет статуса Paused:

    kubectl argo rollouts set image rollouts-demo \
  rollouts-demo=argoproj/rollouts-demo:red

    В приведенном примере имя версии контейнера red.

  10. Для прерывания обновления введите следующую команду:

    kubectl argo rollouts abort rollouts-demo

    Когда deployment прерывается, масштабируется «стабильная» версия ReplicaSet (в приведенном примере «yellow» версия) и уменьшаются любые другие версии. Несмотря на то, что «стабильная» версия ReplicaSet может быть запущена и работоспособна, общее развертывание по-прежнему находится в статусе Degraded. Вывод команды будет следующим:

    Name:               rollouts demo
Namespace           default
Status:             Degraded
Strategy:           Canary
    Step:           0/8
    SetWeight:      0
    ActualWeight    0
Images              argoj/rollouts-demo:yellow (stable)
Replicas:
    Desired:        5
    Current:        5
    Updated:        0
    Ready:          5
    Avalible:       5
...

  11. Чтобы Rollout имел статус Healthy вместо Degraded, измените желаемое состояние обратно на предыдущую, «стабильную» версию. Обычно это связано с выполнением предыдущей спецификации развертывания kubectl apply. Запустите команду set image, используя предыдущую версию:

    kubectl argo rollouts set image rollouts-demo \
  rollouts-demo=argoproj/rollouts-demo:yellow

  12. Убедитесь в выводе, что развертывание работоспособно и отсутствуют действия в отношении создания новых наборов реплик:

    Name:               rollouts demo
Namespace           default
Status:             Healthy
Strategy:           Canary
    Step:           8/8
    SetWeight:      100
    ActualWeight    100
Images              argoj/rollouts-demo:yellow (stable)
Replicas:
    Desired:        5
    Current:        5
    Updated:        5
    Ready:          5
    Avalible:       5
...

    Если deployment не достигло желаемого состояния (например, было прервано или находится в середине обновления) и был повторно применен «стабильный» манифест, Argo Rollouts определяет это как откат, а не обновление, и осуществляет deployment «стабильного» набора реплик, пропуская шаг анализа.

Примечание

Deployment в этом базовом примере не использовало ingress controller или service mesh provider для маршрутизации трафика. Вместо этого был использован kube-proxy для достижения приблизительного веса обновления, основанного на ближайшем соотношении числа новых и старых реплик. В результате у этого развертывания было ограничение, заключавшееся в том, что оно могло достичь минимального веса обновления только в 20% путем масштабирования 1 из 5 модулей для запуска новой версии. Для большей детализации и дозирования веса обновлений используйте ingress controller.

Argo Events#

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

Сценарий использования Argo Events#

Внедрение Argo Events: настройка и развертывание системы мониторинга и управления событиями в DropApp#

Для выполнения данного сценария необходимы права администратора.

Для работы с Argo Events выполните следующую последовательность действий.

  1. Создайте namecpace argo-events:

    kubectl create namespace argo-events

  2. Разверните Argo Events SA, ClusterRoles и Controller для Sensor, EventBus и EventSource:

    kubectl apply -f https://<repoexample.ru>/argoproj/argo-events/stable/manifests/install.yaml
kubectl apply -f https://<repoexample.ru>/argoproj/argo-events/stable/manifests/install-validating-webhook.yaml
# Укажите актуальный путь до локального репозитория

  3. Разверните EventBus в DropApp:

    kubectl apply -n argo-events -f https://<repoexample.ru>/argoproj/argo-events/stable/examples/eventbus/native.yaml
# Укажите актуальный путь до локального репозитория

  4. Внесите следующее содержание в native.yaml файл:

    apiVersion: argoproj.io/v1alpha1
kind: EventBus
metadata:
  name: default
spec:
  nats:
    native:
      # Опционально, по умолчанию 3.
      replicas: 3
      # Опционально, стратегия аутентификации имеет статус "none" или "token", по умолчанию "none"
      auth: token
#      containerTemplate:
#        resources:
#          requests:
#            cpu: "10m"
#      metricsContainerTemplate:
#        resources:
#          requests:
#            cpu: "10m"
#      antiAffinity: false
#      persistence:
#        storageClassName: standard
#        accessMode: ReadWriteOnce
#        volumeSize: 10Gi

Выше представлена конфигурация EventBus в Argo CD. EventBus - это компонент DropApp, который позволяет отслеживать события и уведомления в кластере. Предоставляет возможность создавать подписки на события и получать уведомления о них.

В данном примере конфигурация EventBus определяет имя EventBus по умолчанию, а также настройки для подключения к NATS. NATS - это брокер сообщений, который используется для передачи событий между компонентами в кластере DropApp.

Настройки для NATS включают количество реплик брокера (3 по умолчанию), тип аутентификации (токен по умолчанию), настройки ресурсов для контейнеров, метрики и Anti-Affinity. Также указана возможность использования хранилища данных (persistence) для хранения логов и журналов событий.