Приложение, кластер или репозиторий может быть создано в 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.
- Проекты
- Приложения
- Репозитории
- Репозиторий секрет
- Jenkins, Ansible и Argocd
- Ansible Kubernetes Secret
- Ansible Argocd Projects and Applications
- Дженкинс
Проекты
Документация — Проекты .
Нам нужно иметь два проекта для двух наших команд — 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»