Рубрики
Uncategorized

ARGOCD: обзор, конфигурация SSL и развертывание приложения

ARGOCD помогает доставлять заявки в Кубернаны, используя подход к гитам, то есть, когда Git-Re … с меткой Git, Kubernetes, DevOps, Tutorial.

Argocd помогает доставлять заявки в Kubernetes, используя подход к гитам, то есть, когда Git-репозиторий используется в качестве источника доверия, таким образом, все проявления, конфиги и другие данные хранятся в репозитории.

Это может использоваться с манифестом Kubernetes, Kustomize , ksonnet , jsonnet И что мы используем в нашем проекте — Helm-диаграммы.

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

Некоторые дополнительные функции, которые действительно полезны, являются SSO с SAML, поэтому мы можем интегрировать его с нашими Окта , он может развернуть несколько кластеров, поддержку kubernetes RBAC, отличных вебюй и CLI, Github, Gitlab, ETC веб-каучуков, а также метрики PROMETHEUS из коробки, и потрясающие Документация Отказ

Я планирую нам EAUGOCD, чтобы заменить наш текущий процесс развертывания с Дженкинсом и Хелмом, см. Хелм: Пошаговое Создание Чара и деплоймента из Дженкинса пост ( рус ).

Содержание

Компоненты

ArgocD состоит из трех основных компонентов — API-сервера, сервера репозитория и контроллера приложений.

  • API Server (POD: ARGOCD-Server ): контролирует весь экземпляр ARGOCD, все его операции, аутентификацию и секреты, которые хранятся как секреты Kubernetes, и т. Д.
  • Сервер репозитория (POD: ARGOCD-REPO-SERVER ): Магазины и синхронизируют данные с настроенных GIT-репозиториев и генерирует манифесты Kubernetes
  • Контроллер приложений (POD: ARGOCD-Application-Controller ): Используется для мониторинга приложений в кластере Kubernetes, чтобы сделать их такими же, как они описаны в репозитории, а также контролирует Presync, Sync, Postsync.

Argocd CLI установка

В MacOS:

$ brew install argocd

В Linux — от репозитория GitHub:

$ VERSION=$(curl — silent "https://api.github.com/repos/argoproj/argo-cd/releases/latest" | grep '"tag_name"' | sed -E 's/.*"([^"]+)".*/\1/')

$ sudo curl -sSL -o /usr/local/bin/argocd [https://github.com/argoproj/argo-cd/releases/download/$VERSION/argocd-linux-amd64](https://github.com/argoproj/argo-cd/releases/download/%24VERSION/argocd-linux-amd64)

$ sudo chmod +x /usr/local/bin/argocd

Проверь это:

$ argocd version
argocd: v1.7.9+f6dc8c3
BuildDate: 2020–11–17T23:18:20Z
GitCommit: f6dc8c389a00d08254f66af78d0cae1fdecf7484
GitTreeState: clean
GoVersion: go1.14.12
Compiler: gc
Platform: linux/amd64

Бег аргоцда в Кубебене

И давайте раскрутим экземпляр ARGOCD. Мы можем использовать манифест из документации, которая создаст все необходимые ресурсы, такие как CRD, ServiceAccounts, RBAC роли и связывание, конфигурации, секреты, услуги и развертывание.

Я уверен, что есть существующая хелма-диаграмма для Argocd, но на этот раз давайте будем использовать манифест, как оно описано в Начало работы Отказ

Документация предлагает использовать Аргоцд пространство имен И это будет проще, но мы не ищем простоту, поэтому давайте создадим наше собственное пространство имен:

$ kubectl create namespace dev-1-devops-argocd-ns
namespace/dev-1-devops-argocd-ns created

Развертывание ресурсов:

$ kubectl apply -n dev-1-devops-argocd-ns -f [https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml](https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml)

Редактировать argcd-сервер Сервис — измените свой тип на LoadBalancer, чтобы получить доступ к Webui из мира:

$ kubectl -n dev-1-devops-argocd-ns patch svc argocd-server -p '{"spec": {"type": "LoadBalancer"}}'
service/argocd-server patched

Найти свой URL:

$ kubectl -n dev-1-devops-argocd-ns get svc argocd-server
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
argocd-server LoadBalancer 172.20.142.44 ada***585.us-east-2.elb.amazonaws.com 80:32397/TCP,443:31693/TCP 4m21s

Пароль для ARGOCD генерируется автоматически, установлен на имя имени своего POD, получите его с помощью следующей команды:

$ kubectl -n dev-1-devops-argocd-ns get pods -l app.kubernetes.io/name=argocd-server -o name | cut -d'/' -f 2
argocd-server-794857c8fb-xqgmv

Войдите через CLI, не обращайте внимания на ошибку сертификата:

$ argocd login ada***585.us-east-2.elb.amazonaws.com
WARNING: server certificate had error: x509: certificate is valid for localhost, argocd-server, argocd-server.dev-1-devops-argocd-ns, argocd-server.dev-1-devops-argocd-ns.svc, argocd-server.dev-1-devops-argocd-ns.svc.cluster.local, not ada***585.us-east-2.elb.amazonaws.com. Proceed insecurely (y/n)? y
Username: admin
Password:
'admin' logged in successfully
Context 'ada***585.us-east-2.elb.amazonaws.com' updated

Изменить пароль:

$ argocd account update-password
*** Enter current password:
*** Enter new password:
*** Confirm new password:
Password updated

Откройте Webui, снова игнорируйте предупреждение SSL, мы настроим его в данный момент и войти в систему:

LoadBalancer, SSL и DNS

Cool — у нас есть все услуги, теперь давайте настроим имя DNS и сертификат SSL.

AWS ALB и ELB не поддерживают GRPC, посмотреть Балансировщики нагрузки AWS (ALBS) и классический ELB (HTTP MODE) Таким образом, мы не можем использовать Alb Ingress Controller здесь.

Давайте оставим службу с типом LoadBalancer, как мы это сделали выше — это создает AWS Classic LazLancer.

Сертификат SSL может быть выдан с AWS сертификат менеджер В том же регионе, что и наш кластер и балансировщик нагрузки и сохраняют свой ARN.

Загрузите файл манифеста:

$ wget [https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml](https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml)

Найти argocd-сервер Оказание услуг:

--------
apiVersion: v1
kind: Service
metadata:
  labels:
    app.kubernetes.io/component: server
    app.kubernetes.io/name: argocd-server
    app.kubernetes.io/part-of: argocd
  name: argocd-server
spec:
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 8080
  - name: https
    port: 443
    protocol: TCP
    targetPort: 8080
  selector:
    app.kubernetes.io/name: argocd-server

К аннотациям добавить Service.beta.kubernetes.io/aws-load-lancer-ssl-cert , в SPEC.TYPE — Тип LoadBalancer и ограничить доступ с LoadBalancerourcercrecerences :

--------
apiVersion: v1
kind: Service
metadata:
  labels:
    app.kubernetes.io/component: server
    app.kubernetes.io/name: argocd-server
    app.kubernetes.io/part-of: argocd
  name: argocd-server
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-ssl-cert: "arn:aws:acm:us-east-1:534 ***385:certificate/ddaf55b0-*** -53d57c5ca706"
spec:
  type: LoadBalancer
  loadBalancerSourceRanges:
  - "31. ***.***.117/32"
  - "194. ***.***.24/29"
  ports:
  - name: http
    port: 80
    protocol: TCP
    targetPort: 8080
  - name: https
    port: 443
    protocol: TCP
    targetPort: 8080
  selector:
    app.kubernetes.io/name: argocd-server

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

$ kubectl -n dev-1-devops-argocd-ns apply -f install.yaml

Проверьте SSL ELB:

Создайте запись DNS:

Откройте URL-адрес — и получи Err_too_many_redirets ошибка_:_

Argocd ssl: err_too_many_redirets

Перейдите в Google и найдите эту тему — https://github.com/argoproj/argo-cd/issues/2953 Отказ

Вернитесь к install.yaml , в развертывании argocd-сервер Добавьте --insecure флаг:

--------
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app.kubernetes.io/component: server
    app.kubernetes.io/name: argocd-server
    app.kubernetes.io/part-of: argocd
  name: argocd-server
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: argocd-server
  template:
    metadata:
      labels:
        app.kubernetes.io/name: argocd-server
    spec:
      containers:
      - command:
        - argocd-server
        - --staticassets
        - /shared/app
        - --insecure
...

Разверните его и проверьте:

Хорошо — мы здесь сделали.

Argocd.: Развертывание из репозитория GitHub

И давайте продолжим примером от руководства по началу работы — развертывание HELM будет наблюдаться в следующей части.

Нажмите на Новое приложение , укажите имя, и установите Проект == по умолчанию :

В Гит Установите https://github.com/argoproj/argocd-example-apps.git URL и путь внутри репо — Гостевая книга :

В пункте назначения — https://kubernetes.default.svc и по умолчанию Пространство имен, нажмите на Создать :

Похоже, это было создано, но почему его синхронизация является Неизвестно ?

Что-то пошло не так:

$ argocd app get guestbook
Name: guestbook
Project: default
Server: [https://kubernetes.default.svc](https://kubernetes.default.svc)
Namespace: default
…
CONDITION MESSAGE LAST TRANSITION
ComparisonError failed to load initial state of resource PersistentVolumeClaim: persistentvolumeclaims is forbidden: User "system:serviceaccount:dev-1-devops-argocd-ns:argocd-application-controller" cannot list resource "persistentvolumeclaims" in API group "" at the cluster scope 2020–11–19 15:35:51 +0200 EET
ComparisonError failed to load initial state of resource PersistentVolumeClaim: persistentvolumeclaims is forbidden: User "system:serviceaccount:dev-1-devops-argocd-ns:argocd-application-controller" cannot list resource "persistentvolumeclaims" in API group "" at the cluster scope 2020–11–19 15:35:51 +0200 EET

Попробуйте Синхронизация Команда с CLI — также не работала:

$ argocd app sync guestbook
Name: guestbook
Project: default
Server: [https://kubernetes.default.svc](https://kubernetes.default.svc)
Namespace: default
…
Sync Status: Unknown
Health Status: Healthy
Operation: Sync
Sync Revision:
Phase: Error
Start: 2020–11–19 15:37:01 +0200 EET
Finished: 2020–11–19 15:37:01 +0200 EET
Duration: 0s
Message: ComparisonError: failed to load initial state of resource Pod: pods is forbidden: User "system:serviceaccount:dev-1-devops-argocd-ns:argocd-application-controller" cannot list resource "pods" in API group "" at the cluster scope;ComparisonError: failed to load initial state of resource Pod: pods is forbidden: User "system:serviceaccount:dev-1-devops-argocd-ns:argocd-application-controller" cannot list resource "pods" in API group "" at the cluster scope
FATA[0001] Operation has completed with phase: Error

ARGOCD: СравнениеФрор Не удалось загрузить начальное состояние ресурса

На самом деле, лучше рассмотреть систему « пользователь»: ServiceAccount: DEV-1-DEVOPS-ARGOCD-NS: ARGOCD-Application-Controller «Не удается перечислить ресурс« PODS »в группе API« »в кластере CAPOPE » ОШИБКА.

Проверьте Argocd-Application-контроллер ServiceAccount (действительно полезно здесь Kubernetes: ServiceAccounts, JWT-токены, аутентификация и авторизация RBAC Post):

$ kubectl -n dev-1-devops-argocd-ns get serviceaccount argocd-application-controller
NAME SECRETS AGE
argocd-application-controller 1 36m

Да, у нас есть Пользовательская система: serviceacccount: dev1-devops-argocd-ns: argocd-приложение-контроллер созданный.

И это имеет Argocd-Application-контроллер КЛУСТЕРЗОЛЬНОЕБИНГИНГ:

$ kubectl -n dev-1-devops-argocd-ns get clusterrolebinding argocd-application-controller
NAME AGE
argocd-application-controller 24h

Но он не может выполнить свой список PODS:

$ kubectl auth can-i list pods -n dev-1-devops-argocd-ns — as system:serviceaccount:dev-1-devops-argocd-ns:argocd-application-controller
no

Хотя его кластерроль дает все разрешения:

--------
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    app.kubernetes.io/component: application-controller
    app.kubernetes.io/name: argocd-application-controller
    app.kubernetes.io/part-of: argocd
  name: argocd-application-controller
rules:
- apiGroups:
  - '*'
  resources:
  - '*'
  verbs:
  - '*'
- nonResourceURLs:
  - '*'
  verbs:
  - '*'

Опять проверьте кластерроль, но на этот раз с - Ямл выход:

$ kubectl get clusterrolebinding argocd-application-controller -o yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
…
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: argocd-application-controller
subjects:
- kind: ServiceAccount
name: argocd-application-controller
namespace: argocd

пространство имен: Argocd — Ага, вот мы.

Найти два кластереолегии в install.yaml — Argocd-Application-контроллер и argocd-сервер, Обновите их пространства имен:

--------
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  labels:
    app.kubernetes.io/component: application-controller
    app.kubernetes.io/name: argocd-application-controller
    app.kubernetes.io/part-of: argocd
  name: argocd-application-controller
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: argocd-application-controller
subjects:
- kind: ServiceAccount
  name: argocd-application-controller
  namespace: dev-1-devops-argocd-ns
--------
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  labels:
    app.kubernetes.io/component: server
    app.kubernetes.io/name: argocd-server
    app.kubernetes.io/part-of: argocd
  name: argocd-server
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: argocd-server
subjects:
- kind: ServiceAccount
  name: argocd-server
  namespace: dev-1-devops-argocd-ns

Ну вот почему я рассказал о по умолчанию Аргоцд пространство имен И почему это проще, чтобы использовать его, как если бы вы использовали пользовательское пространство имен, то вам придется обновить эти привязки.

Итак, исправьте это, разверните еще раз:

$ kubectl auth can-i list pods -n dev-1-devops-argocd-ns — as system:serviceaccount:dev-1-devops-argocd-ns:argocd-application-controller
yes

Попробуйте выполнить синхронизацию еще раз:

$ argocd app sync guestbook
TIMESTAMP GROUP KIND NAMESPACE NAME STATUS HEALTH HOOK MESSAGE
2020–11–19T15:47:08+02:00 Service default guestbook-ui Running Synced service/guestbook-ui unchanged
2020–11–19T15:47:08+02:00 apps Deployment default guestbook-ui Running Synced deployment.apps/guestbook-ui unchanged
Name: guestbook
Project: default
Server: [https://kubernetes.default.svc](https://kubernetes.default.svc)
…
Sync Status: Synced to HEAD (6bed858)
Health Status: Healthy
Operation: Sync
Sync Revision: 6bed858de32a0e876ec49dad1a2e3c5840d3fb07
Phase: Succeeded
Start: 2020–11–19 15:47:06 +0200 EET
Finished: 2020–11–19 15:47:08 +0200 EET
Duration: 2s
Message: successfully synced (all tasks run)
GROUP KIND NAMESPACE NAME STATUS HEALTH HOOK MESSAGE
Service default guestbook-ui Synced Healthy service/guestbook-ui unchanged
apps Deployment default guestbook-ui Synced Healthy deployment.apps/guestbook-ui unchanged

И это работает:

Журналы POD:

Следующим шагом будет развернуть диаграмму HELM и выяснить, как работать с Секреты Helm Отказ

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

Оригинал: «https://dev.to/setevoy/argocd-an-overview-ssl-configuration-and-an-application-deploy-34lh»

Читайте ещё по теме: