Unterstützung für die Verbesserung dieser Seite beitragen

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Um zu diesem Benutzerhandbuch beizutragen, wählen Sie den GitHub Link Diese Seite bearbeiten auf, der sich im rechten Bereich jeder Seite befindet.

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Zusammenarbeit mit Argo CD Projects

Argo CD Projects (AppProject) bieten logische Gruppierung und Zugriffskontrolle für Anwendungen. Projekte definieren, welche Git-Repositorys, Zielcluster und Namespaces Anwendungen verwenden können, wodurch Mehrmandantenfähigkeit und Sicherheitsgrenzen in gemeinsam genutzten Argo-CD-Instanzen aktiviert werden.

Wann sollten Projekte verwendet werden

Verwenden Sie Projekte, um:

Standardprojekt

Jede Argo-CD-Funktion beinhaltet ein default Projekt, das den Zugriff auf alle Repositorys, Cluster und Namespaces ermöglicht. Das ist zwar für erste Tests nützlich, aber Sie können spezielle Projekte mit ausdrücklichen Einschränkungen für den produktiven Einsatz erstellen.

Einzelheiten zur Standard-Projektkonfiguration und wie man sie einschränkt, finden Sie unter Das Standardprojekt in der Argo-CD-Dokumentation.

Erstellen eines Projekts

Erstellen Sie ein Projekt, indem Sie eine AppProject Ressource auf Ihren Cluster anwenden.

Beispiel: Teamspezifisches Projekt

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: team-a
  namespace: argocd
spec:
  description: Applications for Team A

  # Source repositories this project can deploy from
  sourceRepos:
    - 'https://github.com/my-org/team-a-*'
    - 'https://github.com/my-org/shared-libs'

  # Destination clusters and namespaces
  destinations:
    - name: dev-cluster
      namespace: team-a-dev
    - name: prod-cluster
      namespace: team-a-prod

  # Allowed resource types
  clusterResourceWhitelist:
    - group: ''
      kind: Namespace

  namespaceResourceWhitelist:
    - group: 'apps'
      kind: Deployment
    - group: ''
      kind: Service
    - group: ''
      kind: ConfigMap

Wenden Sie das Projekt an:

kubectl apply -f team-a-project.yaml

Konfiguration des Projekts

Quell-Repositorien

Steuern Sie, welche Git-Repositorys Anwendungen in diesem Projekt verwenden können:

spec:
  sourceRepos:
    - 'https://github.com/my-org/app-*'  # Wildcard pattern
    - 'https://github.com/my-org/infra'  # Specific repo

Du kannst Platzhalter und Negationsmuster (!Präfix) verwenden, um bestimmte Repositorys zuzulassen oder abzulehnen. Einzelheiten finden Sie unter Projekte verwalten in der Argo-CD-Dokumentation.

Einschränkungen im Hinblick auf Ziele

Schränken Sie ein, wo Anwendungen bereitgestellt werden können:

spec:
  destinations:
    - name: prod-cluster  # Specific cluster by name
      namespace: production
    - name: '*'  # Any cluster
      namespace: team-a-*  # Namespace pattern

Sie können Platzhalter und Negationsmuster verwenden, um Ziele zu steuern. Einzelheiten finden Sie unter Projekte verwalten in der Argo-CD-Dokumentation.

Einschränkungen bei den Ressourcen

Steuern Sie, welche Kubernetes-Ressourcentypen bereitgestellt werden können:

Ressourcen im Clusterbereich:

spec:
  clusterResourceWhitelist:
    - group: ''
      kind: Namespace
    - group: 'rbac.authorization.k8s.io'
      kind: Role

Ressourcen im Namespace-Bereich:

spec:
  namespaceResourceWhitelist:
    - group: 'apps'
      kind: Deployment
    - group: ''
      kind: Service
    - group: ''
      kind: ConfigMap
    - group: 's3.services.k8s.aws'
      kind: Bucket

Verwenden Sie schwarze Listen, um bestimmte Ressourcen abzulehnen:

spec:
  namespaceResourceBlacklist:
    - group: ''
      kind: Secret  # Prevent direct Secret creation

Ordnen Sie Anwendungen Projekten zu

Wenn Sie eine Anwendung erstellen, geben Sie das Projekt im spec.project Feld an:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
  namespace: argocd
spec:
  project: team-a  # Assign to team-a project
  source:
    repoURL: https://github.com/my-org/my-app
    path: manifests
  destination:
    name: prod-cluster
    namespace: team-a-prod

Anwendungen ohne ein bestimmtes Projekt verwenden das default Projekt.

Projektrollen und RBAC

Projekte können benutzerdefinierte Rollen für eine differenzierte Zugriffskontrolle definieren. Ordnen Sie in Ihrer Funktionskonfiguration Projektrollen AWS Identity Center-Benutzern und -Gruppen zu, um zu kontrollieren, wer Anwendungen synchronisieren, aktualisieren oder löschen kann.

Beispiel: Projekt mit Entwickler- und Administratorrollen

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: team-a
  namespace: argocd
spec:
  sourceRepos:
    - '*'
  destinations:
    - name: '*'
      namespace: 'team-a-*'

  roles:
    - name: developer
      description: Developers can sync applications
      policies:
        - p, proj:team-a:developer, applications, sync, team-a/*, allow
        - p, proj:team-a:developer, applications, get, team-a/*, allow
      groups:
        - team-a-developers

    - name: admin
      description: Admins have full access
      policies:
        - p, proj:team-a:admin, applications, *, team-a/*, allow
      groups:
        - team-a-admins

Einzelheiten zu Projektrollen, JWT-Token für CI/CD Pipelines und der RBAC-Konfiguration finden Sie unter Projektrollen in der Argo-CD-Dokumentation.

Allgemeine Muster

Umweltbezogene Projekte

Erstellen Sie separate Projekte für jede Umgebung:

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: production
  namespace: argocd
spec:
  sourceRepos:
    - 'https://github.com/my-org/*'
  destinations:
    - name: prod-cluster
      namespace: '*'
  # Strict resource controls for production
  clusterResourceWhitelist: []
  namespaceResourceWhitelist:
    - group: 'apps'
      kind: Deployment
    - group: ''
      kind: Service

Teambasierte Projekte

Isolieren Sie Teams mit speziellen Projekten:

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: platform-team
  namespace: argocd
spec:
  sourceRepos:
    - 'https://github.com/my-org/platform-*'
  destinations:
    - name: '*'
      namespace: 'platform-*'
  # Platform team can manage cluster resources
  clusterResourceWhitelist:
    - group: '*'
      kind: '*'

Projekte mit mehreren Clustern

Stellen Sie die Lösung auf mehreren Clustern mit konsistenten Richtlinien bereit:

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: global-app
  namespace: argocd
spec:
  sourceRepos:
    - 'https://github.com/my-org/global-app'
  destinations:
    - name: us-west-cluster
      namespace: app
    - name: eu-west-cluster
      namespace: app
    - name: ap-south-cluster
      namespace: app

Best Practices

Beginnen Sie mit restriktiven Projekten: Beginnen Sie mit engen Berechtigungen und erweitern Sie diese nach Bedarf, anstatt mit einem breiten Zugriff zu beginnen.

Verwenden Sie Namespace-Muster: Nutzen Sie Platzhalter in Namespace-Einschränkungen (wieteam-a-*), um Flexibilität zu gewährleisten und gleichzeitig die Grenzen beizubehalten.

Separate Produktionsprojekte: Verwenden Sie spezielle Projekte für die Produktion mit strengeren Kontrollen und manuellen Synchronisierungsrichtlinien.

Projektzwecke dokumentieren: Verwenden Sie das description Feld, um zu erklären, wofür jedes Projekt gedacht ist und wer es verwenden sollte.

Überprüfen Sie die Projektberechtigungen regelmäßig: Prüfen Sie Projekte regelmäßig, um sicherzustellen, dass die Einschränkungen weiterhin den Teamanforderungen und Sicherheitsanforderungen entsprechen.

Weitere Ressourcen