Рубрики
Uncategorized

ArgoCD: декларативные проекты, приложения и ArgoCD развернуты из Jenkins

Приложение, кластер или репозиторий может быть создано в ArgoCD из его WebUI, CLI или писать … С тегами DevOps, Kubernetes, Tulciory, сегодня.

Приложение, кластер или репозиторий может быть создано в ArgoCD из его Webui, CLI или, написав манифест Kubernetes, который затем можно передать в kubectl создать ресурсы.

Например, приложения являются Cubernetes CustomResources и описаны в Kubernetes CRD applications.argoproj.io :

$ kubectl get crd applications.argoproj.io
NAME CREATED AT
applications.argoproj.io 2020–11–27T15:55:29Z

И доступны в пространствах имен argocd как обычные ресурсы Kubernetes:

$ kubectl -n dev-1–18-devops-argocd-ns get applications
NAME SYNC STATUS HEALTH STATUS
backend-app OutOfSync Missing
dev-1–18-web-payment-service-ns Synced Healthy
web-fe-github-actions Synced Healthy

Такой подход даст возможность создавать все необходимые приложения при создании нового экземпляра ArgoCD. Например, когда мы обновляем версию Kubernetes в нашей службе AWS Elastic Kubernetes, мы создаем новый кластер с Jenkins, Ansible и Helm (Check AWS Elastic Kubernetes Service: автоматизация создания кластера, часть 1 — Облачноеформование и AWS Elastic Kubernetes Service: автоматизация создания кластера, часть 2 — Ansible, eksctl Для получения более подробной информации). где у нас есть все необходимые контроллеры и операторы, включая argocd.

Используя декларативный подход для ArgoCD, мы также можем создавать все приложения и другие настройки, настроенные во время нового обеспечения кластера EKS.

Итак, наша задача, пока — создать:

  • Проекты с ролями и разрешениями на бэкэнд и веб -команды.
  • Приложения — для наших бэкэнд и веб -проектов
  • Репозитории — Настройка аутентификации для репозитории GitHub

Сначала давайте посмотрим, как это работает в целом, создавая манифест и ресурсы вручную, а затем применим это к Ansible Rode и создаст работу Jenkins.

Проекты

Документация — Проекты .

Нам нужно иметь два проекта для двух наших команд — Backend и WB, и каждый должен иметь ограничения для используемых имен -пространств, и она должна иметь роль, настроенную для доступа к приложениям в этих проектах.

Создайте новый файл с помощью проекта бэкэнда:

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: backend
  namespace: dev-1-18-devops-argocd-ns
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  description: "Backend project"
  sourceRepos:
  - '*'
  destinations:
  - namespace: 'dev-1-18-backend-*'
    server: [https://kubernetes.default.svc](https://kubernetes.default.svc)
  clusterResourceWhitelist:
  - group: ''
    kind: Namespace
  namespaceResourceWhitelist:
  - group: "*"
    kind: "*"
  roles:
  - name: "backend-app-admin"
    description: "Backend team's deployment role"
    policies:
    - p, proj:backend:backend-app-admin, applications, *, backend/*, allow
    groups:
    - "Backend"
  orphanedResources:
    warn: true

Здесь:

  • Sourcerepos : разрешить развертывание в проекте из любых репозиториев
  • направления : кластер и пространства имен в нем, которые могут развернуть. В приведенном выше примере мы используем dev-1-18-backend-* Маска, поэтому бэкэнд -команде будет разрешено развернуть в любом пространстве имен, запущенном из маски, а для веб -проекта мы будем использовать аналогичную маску dev-1-18-web-*
  • ClusterResourceWhiteList : на уровне кластера разрешайте только пространства имен.
  • namespacerSourceWhiteList : на уровне пространств имен позволяет создавать любые ресурсы
  • Роли : Создать Бэкэнд-Ап-Админ Роль с полным доступом к приложениям в этом проекте. Смотрите больше в Argocd: пользователи, доступ и RBAC и Argocd: Интеграция Окта и группы пользователей
  • Orphanedresources : Включить уведомления о устаревших ресурсах, проверьте Мониторинг ресурсов осиротежных ресурсов

Развернуть это:

$ kubectl apply -f project.yaml
appproject.argoproj.io/backend created

И проверить:

$ argocd proj get backend
Name: backend
Description: Backend project
Destinations: 
Repositories: *
Whitelisted Cluster Resources: /Namespace
Blacklisted Namespaced Resources: 
Signature keys: 
Orphaned Resources: enabled (warn=true)

Приложения

Документация — Приложения Анкет

Далее, давайте добавим манифест для тестового приложения в бэкэнд -проекте:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: backend-app
  namespace: dev-1-18-devops-argocd-ns
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  project: "backend"
  source:
    repoURL: [https://github.com/projectname/devops-kubernetes.git](https://github.com/projectname/devops-kubernetes.git)
    targetRevision: DVPS-967-ArgoCD-declarative-bootstrap
    path: tests/test-svc
    helm:
      parameters:
      - name: serviceType
        value: LoadBalancer
  destination:
    server: [https://kubernetes.default.svc](https://kubernetes.default.svc)
    namespace: dev-1-18-backend-argocdapp-test-ns
  syncPolicy:
    automated:
      prune: false
      selfHeal: false
      allowEmpty: false
    syncOptions:
    - Validate=true
    - CreateNamespace=true
    - PrunePropagationPolicy=foreground
    - PruneLast=true
    retry:
      limit: 5
      backoff:
        duration: 5s
        factor: 2
        maxDuration: 3m

Здесь:

  • финализаторы : Установить для удаления всех ресурсов Kubernetes при удалении приложения из ArgoCD ( Cascade Deletion , см. Удаление приложения )
  • Проект : Проект по добавлению приложения и который установит ограничения для приложения (пространства имен, ресурсы и т. Д.)
  • Источник : Установите хранилище для развертывания и филиала
  • в Helm.parameters -установленные значения для диаграммы руля ( helm -set )
  • пункт назначения : Кластер и пространство имен для развертывания. Пространство имен здесь должно быть разрешено в проекте, которому принадлежит приложение
  • Syncpolicy : Настройки синхронизации, проверка Автоматизированная политика синхронизации и Параметры синхронизации

Кроме того, ArgoCD поддерживает так называемое приложение приложений, когда вы создаете манифест для приложения, которое создаст набор других приложений. Мы не будем использовать это 9 лет), но выглядят интересно, см. Кластерная начальная загрузка Анкет

Развернуть приложение:

$ kubectl apply -f application.yaml
application.argoproj.io/backend-app created

Проверь это:

$ kubectl -n dev-1–18-devops-argocd-ns get application backend-app
NAME SYNC STATUS HEALTH STATUS
backend-app Unknown Healthy

И его статус:

$ argocd app get backend-app
Name: backend-app
Project: backend
Server: [https://kubernetes.default.svc](https://kubernetes.default.svc)
Namespace: dev-1–18-backend-argocdapp-test-ns
URL: https://dev-1–18.argocd.example.com/applications/backend-app
Repo: [https://github.com/projectname/devops-kubernetes.git](https://github.com/projectname/devops-kubernetes.git)
Target: DVPS-967-ArgoCD-declarative-bootstrap
Path: tests/test-svc
SyncWindow: Sync Allowed
Sync Policy: Automated
Sync Status: Unknown
Health Status: Healthy

CONDITION MESSAGE LAST TRANSITION

ComparisonError rpc error: code = Unknown desc = authentication required 2021–05–18 09:11:13 +0300 EEST
OrphanedResourceWarning Application has 1 orphaned resources 2021–05–18 09:11:13 +0300 EEST

Здесь у нас есть « ComparressionError, необходимый », поскольку argoCD не может подключиться к репозиторию, потому что он личный.

Давайте перейдем к аутентификации репозитория.

Репозитории

Документация — Репозитории Анкет

Внезапно репозитории добавляются в argocd-cm Configmap, вместо того, чтобы быть выделенным ресурсом, таким как приложения или проекты.

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

Кроме того, аутентификация для сервера GIT использует секреты Kubernetes, хранящиеся в пространстве имен ArgoCD, поэтому разработчик также должен иметь доступ туда.

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

Идея заключается в том, что мы можем установить «маску» для репозиториев, то есть https://github.com/projectname , и прикрепите вход и пароль или закрытый ключ SSK. Затем разработчик может установить репозиторий, как https://github.com/orgname/reponame , и argocd будет использовать github.com/projectname Маска и будет выполнять аутентификацию на сервере для github.com/projectname/reponame репозиторий.

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

Репозиторий секрет

Здесь мы будем использовать https и GitHub Access Token Анкет

Перейдите в профиль GitHub и создайте токен (лучше всего создать специализированного пользователя для ArgoCD):

Дайте репозитории разрешения:

Кодировать токен с Base64 в терминале или с помощью https://www.base64encode.org :

$ echo -n ghp_GE***Vx911 | base64
Z2h***xMQo=

И имя пользователя:

$ echo -n username | base64
c2V***eTI=

Добавьте секрет Kubernetes в пространство имен argocd:

apiVersion: v1
kind: Secret
metadata:
  name: github-access
  namespace: dev-1-18-devops-argocd-ns
data:
  username: c2V***eTI=
  password: Z2h***xMQ==

Создать это:

$ kubectl apply -f secret.yaml
secret/github-access created

Добавьте его использование в argocd-cm Configmap:

...
  repository.credentials: |
    - url: [https://github.com/orgname](https://github.com/orgname)
      passwordSecret:
        name: github-access
        key: password
      usernameSecret:
        name: github-access
        key: username
...

Проверять:

$ argocd repocreds list
URL PATTERN USERNAME SSH_CREDS TLS_CREDS
[https://github.com/projectname](https://github.com/projectname) username false false

И попытаться синхронизировать приложение:

$ argocd app sync backend-app
…
Message: successfully synced (all tasks run)
GROUP KIND NAMESPACE NAME STATUS HEALTH HOOK MESSAGE
Service dev-1–18-backend-argocdapp-test-ns test-svc Synced Progressing service/test-svc created

Jenkins, Ansible и Argocd

Теперь пришло время подумать об автоматизации.

Мы установили наш ArgoCD с его диаграммы Helm с Ansible Roliday, используя модуль Community.kubernetes, аналогичный ANSIBLE: MMODUOLAH Community.kubernetes и ustanovaka helm-чarta s externaldns ( rus ).

Что нам нужно создать:

  • к роли Ansible добавить секрет для GitHub
  • В настройках argoCD необходимо добавить репозиторию.
  • Создание каталогов для проектов и приложений проявляется, и в роли Ansible Add Community.kubernetes.k8s Это будет использовать эти манифесты. Таким образом, приложения будут созданы автоматически во время нового подготовки экземпляра ARGCD, и разработчики смогут добавить новое приложение самостоятельно.

Ansible Kubernetes Secret

В файле переменных, в нашем случае, это будет group_vars/all.yaml , добавьте две новые переменные и зашифруйте их с помощью ansible-vault Анкет Не забудьте кодировать их в Base64 перед шифрованием:

...
argocd_github_access_username: !vault |
          $ANSIBLE_VAULT;1.1;AES256
          63623436326661333236383064636431333532303436323735363063333264306535313934373464
          ...
          3132663634633764360a666162616233663034366536333765666364643363336130323137613333
          3636
argocd_github_access_password: !vault |
          $ANSIBLE_VAULT;1.1;AES256
          61393931663234653839326232383435653562333435353435333962363361643634626664643062
          ...
          6239623265306462343031653834353562613264336230613466
...

В ролевых задачах, в этом случае роли/argocd/tasks/main.yml , добавьте секретное творение:

...
- name: "Create github-access Secret"
  community.kubernetes.k8s:
    definition:
      kind: Secret
      apiVersion: v1
      metadata:
        name: "github-access"
        namespace: "{{ eks_env }}-devops-argocd-2-0-ns"
      data:
        username: "{{ argocd_github_access_username }}"
        password : "{{ argocd_github_access_password }}"
...

В значениях диаграммы Helm добавить Repository.credentials , см. Значения.yaml :

...
- name: "Deploy ArgoCD chart to the {{ eks_env }}-devops-argocd-2-0-ns namespace"
  community.kubernetes.helm:
    kubeconfig: "{{ kube_config_path }}"
    name: "argocd20"
    chart_ref: "argo/argo-cd"
    release_namespace: "{{ eks_env }}-devops-argocd-2-0-ns"
    create_namespace: true
    values:
      ...
      server:
        service:
          type: "LoadBalancer"
          loadBalancerSourceRanges:
            ...
        config:
          url: "https://{{ eks_env }}.argocd-2-0.example.com"
          repository.credentials: |
            - url: "https://github.com/projectname/"
              passwordSecret:
                name: github-access
                key: password
              usernameSecret:
                name: github-access
                key: username
...

Ansible Argocd Projects and Applications

Создайте каталоги для хранения манифестных файлов:

$ mkdir -p roles/argocd/templates/{projects,applications/{backend,web}}

В роли/argocd/шаблоны/проекты/ каталог Создайте два файла для двух проектов:

$ vim -p roles/argocd/templates/projects/backend-project.yaml.j2 roles/argocd/templates/projects/web-project.yaml.j2

Опишите бэкэнд -проект:

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: "backend"
  namespace: "{{ eks_env }}-devops-argocd-2-0-ns"
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  description: "Backend project"
  sourceRepos:
  - '*'
  destinations:
  - namespace: "{{ eks_env }}-backend-*"
    server: "https://kubernetes.default.svc"
  clusterResourceWhitelist:
  - group: ''
    kind: Namespace
  namespaceResourceWhitelist:
  - group: "*"
    kind: "*"
  roles:  
  - name: "backend-app-admin"
    description: "Backend team's deployment role"
    policies:
    - p, proj:backend:backend-app-admin, applications, *, backend/*, allow
    groups:
    - "Backend" 
  orphanedResources:
    warn: true

Повторите для Интернета

И создать приложения.

Добавить Роли/Аргокд/Шаблоны/Приложения/Бэкэнд/Бэкэнд-Тест-Апп.yaml.J2 файл:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: "backend-app-1"
  namespace: "{{ eks_env }}-devops-argocd-2-0-ns"
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  project: "backend"
  source:
    repoURL: "https://github.com/projectname/devops-kubernetes.git"
    targetRevision: "DVPS-967-ArgoCD-declarative-bootstrap"
    path: "tests/test-svc"
    helm:
      parameters:
      - name: serviceType
        value: LoadBalancer
  destination:
    server: "https://kubernetes.default.svc"
    namespace: "{{ eks_env }}-backend-argocdapp-test-ns"
  syncPolicy:
    automated:
      prune: true
      selfHeal: false
    syncOptions:
    - Validate=true
    - CreateNamespace=true
    - PrunePropagationPolicy=foreground
    - PruneLast=true
    retry:
      limit: 2

В конце задач добавьте эти манифесты — сначала проекты, затем приложения:

...
- name: "Create a Backend project"
  community.kubernetes.k8s:
    kubeconfig: "{{ kube_config_path }}"
    state: present
    template: roles/argocd/templates/projects/backend-project.yaml.j2

- name: "Create a Web project"
  community.kubernetes.k8s: 
    kubeconfig: "{{ kube_config_path }}"
    state: present
    template: roles/argocd/templates/projects/web-project.yaml.j2

- name: "Create Backend applications"
  community.kubernetes.k8s:
    kubeconfig: "{{ kube_config_path }}"
    state: present
    template: "{{ item }}"
  with_fileglob:
    - roles/argocd/templates/applications/backend/*.yaml.j2

- name: "Create Web applications"
  community.kubernetes.k8s:
    kubeconfig: "{{ kube_config_path }}"
    state: present
    template: "{{ item }}"
  with_fileglob:
    - roles/argocd/templates/applications/web/*.yaml.j2

Для приложений используйте with_fileglob Чтобы получить все файлы из роли/argocd/шаблоны/приложения/ , поскольку планируется иметь выделенные файлы на каждое приложение, чтобы разработчикам было легче управлять ими.

Дженкинс

См. Примеры в Дженкинс: МИГРАЙХИЯ РТФМ 2.6 — Дженкинс Трубопровод Лод Альбус и Хелм: Показ -днани и джони и дженкинс (оба в Русе, к сожалению).

Я не буду описать это в деталях, но короче говоря, мы используем сценарий с надписью с provision.ansibleapply () Функциональный вызов:

...
            stage("Applly") {
                // ansibleApply((playbookFile='1', tags='2', passfile_id='3', limit='4')
                provision.ansibleApply( "${PLAYBOOK}", "${env.TAGS}", "${PASSFILE_ID}", "${EKS_ENV}")
            }
...

Функция следующая:

...
def ansibleApply(playbookFile='1', tags='2', passfile_id='3', limit='4') {

    withCredentials([file(credentialsId: "${passfile_id}", variable: 'passfile')]) {

        docker.image('projectname/kubectl-aws:4.5').inside('-v /var/run/docker.sock:/var/run/docker.sock --net=host') {

            sh """
                aws sts get-caller-identity
                ansible-playbook ${playbookFile} --tags ${tags} --vault-password-file ${passfile} --limit ${limit}
            """ 
        }   
    }
}.
...

Здесь, с Docker, мы раскручиваем контейнер для нашего изображения с AWS CLI и Ansible, который управляет Ansible Playbook, проходит тег и выполняет необходимую роль.

В пьесе у нас есть теги для каждой роли, поэтому легко выполнить только одну роль:

...
    - role: argocd
      tags: argocd, create-cluster
...

В результате у нас есть работа Дженкинса с такими параметрами:

Запустить его:

Войдите в новый экземпляр argocd:

$ argocd login dev-1–18.argocd-2–0.example.com --name admin@dev-1–18.argocd-2–0.example.com

Проверьте приложения:

Сделанный.

Первоначально опубликовано в RTFM: Linux, DevOps и системное администрирование Анкет

Оригинал: «https://dev.to/setevoy/argocd-declarative-projects-applications-and-argocd-deploy-from-jenkins-3kkh»