GitOps — это одна из реализаций Pull-модели, в которой Git является хранилищем всех конфигураций. Источник правды — Git, все изменения в инфраструктуре проходят только через него. Все изменения по Pull-модели проводит специальный агент, который затем поддерживает заданное состояние. То есть если внести в инфраструктуру изменения вручную, агент увидит несоответствие с тем, что есть в Git, и вернёт все к нужному состоянию, идентичному источнику правды.
Argo CD — один из самых популярных GitOps-инструментов. Он живет внутри Kubernetes и там же развертывает сущности. Argo CD предоставляет удобный RBAC, то есть управление правами и доступами. В интерфейсе можно посмотреть свои действия, управлять приложениями и принудительно синхронизировать их. Argo CD входит в CNCF, что вызывает к нему большое доверие.
Argo CD может развертывать в кластер:
Эти манифесты можно взять из репозитория Git или Helm. Argo CD разворачивает манифесты только в кластеры Kubernetes, но не только в тот кластер, в котором находится сам: он умеет управлять большим количеством кластеров одновременно.
У вас должен быть запущен кластер K8s, потому что мы собираемся делать это внутри k8s.
kubectl create namespace argocd
kubectl apply -n argocd -f \
https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yamlОбратите внимание, что в развертывании по умолчанию сервис работает как тип Cluster IP, и ingress по умолчанию нет. Поэтому, если вы хотите получить доступ к сервису, вам нужно будет либо выполнить переадресацию портов, либо изменить тип сервиса на балансировщик нагрузки, либо создать ingress.
Ниже приведен способ доступа к сервису через Load Balancer:
kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "LoadBalancer"}}'После чего выведите пароль от учетной записи admin в Argo CD из секрета:
kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath='{.data.password}' | base64 -dСервис будет доступен на 80-443 портах.
Argo CD имеет свой CLI, правда его нужно будет установить.
При установке Argo CD в кластер, добавляются новые объекты:
Понятия:
Для yaml манифестов:
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: crispy-train
namespace: argocd
finalizers:
- resources-finalizer.argocd.argoproj.io
spec:
project: default
destination:
server: in-cluster
namespace: crispy-train
source:
path: Manifests/
targetRevision: HEAD
repoURL: git@github.com:firysksta/crispy-train.git
syncPolicy:
automated:
prune: true
selfHeal: true
syncOptions:
- CreateNamespace=trueДля Helm чартов:
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: crispy-train
namespace: argocd
finalizers:
- resources-finalizer.argocd.argoproj.io
spec:
project: default
destination:
server: in-cluster
namespace: crispy-train
source:
path: HelmCharts/MyChart1
targetRevision: HEAD
repoURL: git@github.com:firysksta/crispy-train.git
helm:
valueFiles:
- dev_values.yaml
parameters:
- name: container.image
value: user1/k8smysql:version1
syncPolicy:
automated:
prune: true
selfHeal: true
syncOptions:
- CreateNamespace=trueЗдесь представлен пример Git в котором есть 2 приложения описанных в Helm-чартах, каждое с values под prod и dev.
Для Argo CD используется App of Apps подход, написаны applications под prod и dev кластеры:
│
├── HelmCharts # All Helm Charts
│ ├── ChartTest1
│ │ ├── Chart.yaml
│ │ ├── templates
│ │ ├── values_dev.yaml # DEV Values
│ │ ├── values_prod.yaml # PROD Values
│ │ └── values.yaml # Default Values
│ └── ChartTest2
│ ├── Chart.yaml
│ ├── templates
│ ├── values_dev.yaml # DEV Values
│ ├── values_prod.yaml # PROD Values
│ └── values.yaml # Default Values
│
├── demo-dev # Develop Cluster
│ ├── applications
│ │ ├── app1.yaml
│ │ └── app2.yaml
│ └── root.yaml # Root ArgoCD Application (App of Apps)
└── demo-prod # Production Cluster
├── applications
│ ├── app1.yaml
│ └── app2.yaml
└── root.yaml # Root ArgoCD Application (App of Apps) Хороший пример проекта: https://github.com/adv4000/argocd/tree/main