Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Configurer la synchronisation à partir de plusieurs dépôts

Lorsque vous installez Config Sync, vous pouvez configurer votre dépôt racine. Une fois que vous avez configuré un dépôt racine, vous avez la possibilité de configurer d'autres dépôts racines et d'espaces de noms. Les dépôts d'espaces de noms vous permettent de déléguer la configuration et le contrôle de dépôts à des utilisateurs non administrateurs. Pour en savoir plus sur ces types de dépôts, consultez la section Dépôts dans la présentation de Config Sync.

Les dépôts d'espaces de noms nécessitent l'API RepoSync. Si vous avez installé Config Sync à l'aide de Google Cloud Console ou de Google Cloud CLI et d'une version 1.7.0 ou ultérieure, cette API est déjà activée. Si vous avez installé Config Sync à l'aide de kubectl et que vous utilisez un objet ConfigManagement pour configurer votre dépôt Git, nous vous recommandons de migrer votre objet ConfigManagement pour activer l'API RepoSync.

Bien que Config Sync détecte automatiquement les modifications de la source fiable, vous pouvez ajouter une couche supplémentaire de détection de la dérive en ajoutant un webhook d'admission aux dépôts d'espaces de noms. Pour savoir comment procéder, consultez la section Prévenir la dérive de configuration.

Avant de commencer

  • Créez un dépôt Git non structuré pouvant contenir les configurations avec lesquelles Config Sync se synchronise, ou assurez-vous d'y avoir accès. Les dépôts d'espaces de noms doivent utiliser le format non structuré.
  • Créez un cluster résidant sur une plate-forme et une version compatibles d'Anthos, ou assurez-vous d'y avoir accès.
  • Créez un cluster GKE répondant aux exigences de Config Sync ou assurez-vous d'y avoir accès.

Limites

  • NamespaceSelectors (y compris les annotations pointant vers des sélecteurs) ne fonctionnent que dans les dépôts racines.

Choisir la méthode de configuration appropriée

Choisissez l'une des deux méthodes de configuration des dépôts :

Contrôler les dépôts dans un dépôt central

Contrôler les dépôts racines dans un dépôt racine

À partir de la version 1.11.0, Config Sync accepte la synchronisation à partir de plusieurs dépôts racines. L'administrateur central peut utiliser un dépôt racine central pour gérer plusieurs dépôts racines. Étant donné que Config Sync gère les objets RootSync, cette méthode empêche toute modification locale des configurations RootSync dans le cluster.

Pour utiliser cette méthode, effectuez les tâches suivantes :

  1. Dans le dépôt racine central, créez un objet RootSync avec un nom unique.

    apiVersion: configsync.gke.io/v1beta1
    kind: RootSync
    metadata:
      name: ROOT_SYNC_NAME
      namespace: config-management-system
    spec:
      sourceFormat: ROOT_FORMAT
      git:
       repo: ROOT_REPOSITORY
         revision: ROOT_REVISION
         branch: ROOT_BRANCH
         dir: "ROOT_DIRECTORY"
         auth: ROOT_AUTH_TYPE
         gcpServiceAccountEmail: ROOT_EMAIL
         secretRef:
           name: ROOT_SECRET_NAME
         noSSLVerify: ROOT_NO_SSL_VERIFY
         caCertSecretRef:
           name: ROOT_CA_CERT_SECRET_NAME
    

    Remplacez les éléments suivants :

    • ROOT_SYNC_NAME : ajoutez le nom de votre objet RootSync. Le nom doit être unique dans le cluster et ne pas dépasser 26 caractères.
    • ROOT_FORMAT : ajoutez unstructured pour utiliser un dépôt non structuré ou hierarchy pour utiliser un dépôt hiérarchique. Ces valeurs sont sensibles à la casse. Ce champ est facultatif et la valeur par défaut est hierarchy. Nous vous recommandons d'ajouter la valeur unstructured, car ce format vous permet d'organiser vos configurations de la manière la plus adaptée à vos besoins.
    • ROOT_REPOSITORY : ajoutez l'URL du dépôt Git à utiliser comme dépôt racine. Vous pouvez saisir des URL à l'aide du protocole HTTPS ou SSH. Par exemple, https://github.com/GoogleCloudPlatform/anthos-config-management-samples utilise le protocole HTTPS. Si vous ne saisissez pas de protocole, l'URL est traitée comme une URL HTTPS. Ce champ est obligatoire.
    • ROOT_REVISION : ajoutez la révision Git (tag ou hachage) à récupérer. Ce champ est facultatif et la valeur par défaut est HEAD.
    • ROOT_BRANCH : ajoutez la branche du dépôt à partir de laquelle la synchronisation doit être effectuée. Ce champ est facultatif et la valeur par défaut est master.
    • ROOT_DIRECTORY : ajoutez le chemin d'accès dans le dépôt Git au répertoire racine contenant la configuration que vous souhaitez synchroniser. Ce champ est facultatif et le paramètre par défaut est le répertoire racine (/) du dépôt.
    • ROOT_AUTH_TYPE : ajoutez l'un des types d'authentification suivants :

      • none : n'utiliser aucune authentification
      • ssh : utiliser une paire de clés SSH
      • cookiefile : utiliser un cookiefile
      • token : utiliser un jeton
      • gcpserviceaccount : utiliser un compte de service Google pour accéder à un dépôt dans Cloud Source Repositories
      • gcenode : utilisez un compte de service Google pour accéder à un dépôt dans Cloud Source Repositories. Ne sélectionnez cette option que si Workload Identity n'est pas activé dans votre cluster.

        Pour en savoir plus sur ces types d'authentification, consultez la page Accorder à Config Sync un accès en lecture seule à Git.

      Ce champ est obligatoire.

    • ROOT_EMAIL : si vous avez ajouté gcpserviceaccount comme ROOT_AUTH_TYPE, ajoutez l'adresse e-mail de votre compte de service Google. Par exemple, acm@PROJECT_ID.iam.gserviceaccount.com.

    • ROOT_SECRET_NAME : ajoutez le nom de votre secret. Si ce champ est défini, vous devez ajouter la clé publique du Secret au fournisseur Git. Ce champ est facultatif.

    • ROOT_NO_SSL_VERIFY : pour désactiver la validation du certificat SSL, définissez ce champ sur true. La valeur par défaut est false.

    • ROOT_CA_CERT_SECRET_NAME : ajoutez le nom de votre secret. Si ce champ est défini, votre fournisseur Git doit utiliser un certificat émis par cette autorité de certification. Le secret doit contenir le certificat CA sous une clé nommée cert. Ce champ est facultatif.

      Pour en savoir plus sur la configuration de l'objet Secret pour le certificat CA, consultez Configurer l'opérateur pour une autorité de certification.

    Pour obtenir une explication des champs et une liste complète des champs que vous pouvez ajouter au champ spec, consultez la section Champs RootSync.

  2. Effectuez un commit des modifications dans le dépôt racine :

     git add .
     git commit -m 'Setting up a new root repository.'
     git push
    
  3. Vous pouvez répéter les étapes ci-dessus si vous devez configurer plusieurs dépôts racines.

Contrôler les dépôts d'espaces de noms dans un dépôt racine

Les dépôts d'espaces de noms peuvent être gérés par un dépôt racine. Comme les objets d'un dépôt d'espaces de noms sont gérés par Config Sync, cette méthode empêche toute modification locale des définitions de ce dépôt.

Pour utiliser cette méthode, effectuez les tâches suivantes :

  1. Dans le dépôt racine, déclarez une configuration namespace :

    # ROOT_REPO/namespaces/NAMESPACE/namespace.yaml
    apiVersion: v1
    kind: Namespace
    metadata:
      name: NAMESPACE
    

    Remplacez NAMESPACE par le nom de votre espace de noms.

  2. Dans le dépôt racine, créez un objet RepoSync dans le même espace de noms :

    # ROOT_REPO/namespaces/NAMESPACE/repo-sync.yaml
     # If you are using a Config Sync version earlier than 1.8.0,
     # use: apiVersion: configsync.gke.io/v1alpha1
    apiVersion: configsync.gke.io/v1beta1
    kind: RepoSync
    metadata:
      name: REPO_SYNC_NAME
      namespace: NAMESPACE
    spec:
      # Since this is for a namespace repository, the format should be unstructured
      sourceFormat: unstructured
      git:
       repo: NAMESPACE_REPOSITORY
       revision: NAMESPACE_REVISION
       branch: NAMESPACE_BRANCH
       dir: "NAMESPACE_DIRECTORY"
       auth: NAMESPACE_AUTH_TYPE
       gcpServiceAccountEmail: NAMESPACE_EMAIL
       secretRef:
         name: NAMESPACE_SECRET_NAME
       # The `noSSLVerify` field is supported in Anthos Config Management version 1.8.2 and later.
       noSSLVerify: NAMESPACE_NO_SSL_VERIFY
       caCertSecretRef:
         name: NAMESPACE_CA_CERT_SECRET_NAME
    

    Remplacez les éléments suivants :

    • REPO_SYNC_NAME : ajoutez le nom de votre objet RepoSync. Pour les versions antérieures à 1.11.0, il doit s'agir de repo-sync. Pour les versions 1.11.0 ou ultérieures, le nom doit être unique dans l'espace de noms. REPO_SYNC_NAME et NAMESPACE ne doivent pas comporter plus de 24 caractères. Si NAMESPACE_AUTH_TYPE est utilisé, REPO_SYNC_NAME, NAMESPACE et NAMESPACE_AUTH_TYPE ne doivent pas comporter plus de 44 caractères.
    • NAMESPACE : ajoutez le nom de votre espace de noms.
    • NAMESPACE_REPOSITORY : ajoutez l'URL du dépôt Git à utiliser comme dépôt de l'espace de noms. Vous pouvez saisir des URL à l'aide du protocole HTTPS ou SSH. Par exemple, https://github.com/GoogleCloudPlatform/anthos-config-management-samples utilise le protocole HTTPS. Si vous ne saisissez pas de protocole, l'URL est traitée comme une URL HTTPS. Ce champ est obligatoire.
    • NAMESPACE_REVISION : ajoutez la révision Git (tag ou hachage) à récupérer. Ce champ est facultatif et la valeur par défaut est HEAD.
    • NAMESPACE_BRANCH : ajoutez la branche du dépôt à partir de laquelle la synchronisation doit être effectuée. Ce champ est facultatif et la valeur par défaut est master.
    • NAMESPACE_DIRECTORY : ajoutez le chemin d'accès dans le dépôt Git au répertoire racine contenant la configuration que vous souhaitez synchroniser. Ce champ est facultatif et le paramètre par défaut est le répertoire racine (/) du dépôt.
    • NAMESPACE_AUTH_TYPE : ajoutez l'un des types d'authentification suivants :

      • none : n'utiliser aucune authentification
      • ssh : utiliser une paire de clés SSH
      • cookiefile : utiliser un cookiefile
      • token : utiliser un jeton
      • gcpserviceaccount : utiliser un compte de service Google pour accéder à un dépôt dans Cloud Source Repositories
      • gcenode : utiliser un compte de service Google pour accéder à un dépôt dans Cloud Source Repositories. Ne sélectionnez cette option que si Workload Identity n'est pas activé dans votre cluster.

        Pour en savoir plus sur ces types d'authentification, consultez la page Accorder à Config Sync un accès en lecture seule à Git.

      Ce champ est obligatoire.

    • NAMESPACE_EMAIL : si vous avez ajouté gcpserviceaccount comme NAMESPACE_AUTH_TYPE, ajoutez l'adresse e-mail de votre compte de service Google. Par exemple, acm@PROJECT_ID.iam.gserviceaccount.com.

    • NAMESPACE_SECRET_NAME : ajoutez le nom que vous souhaitez donner à votre Secret. Ce champ est facultatif.

    • NAMESPACE_NO_SSL_VERIFY : pour désactiver la validation du certificat SSL, définissez ce champ sur true. La valeur par défaut est false.

    • NAMESPACE_CA_CERT_SECRET_NAME : ajoutez le nom de votre secret. Si ce champ est défini, votre fournisseur Git doit utiliser un certificat émis par cette autorité de certification. Le secret doit contenir le certificat CA sous une clé nommée cert. Ce champ est facultatif.

      Pour en savoir plus sur la configuration de l'objet Secret pour le certificat CA, consultez Configurer l'opérateur pour une autorité de certification.

    Pour obtenir une explication des champs et une liste complète des champs que vous pouvez ajouter au champ spec, consultez la section Champs RepoSync.

  3. Dans le dépôt racine, déclarez une configuration RoleBinding qui accorde au compte de service SERVICE_ACCOUNT_NAME l'autorisation de gérer des objets dans l'espace de noms. Config Sync crée automatiquement le compte de service SERVICE_ACCOUNT_NAME lorsque la configuration RepoSync est synchronisée avec le cluster.

    Pour déclarer RoleBinding, créez l'objet suivant :

    # ROOT_REPO/namespaces/NAMESPACE/sync-rolebinding.yaml
     kind: RoleBinding
     apiVersion: rbac.authorization.k8s.io/v1
     metadata:
       name: syncs-repo
       namespace: NAMESPACE
     subjects:
     - kind: ServiceAccount
       name: SERVICE_ACCOUNT_NAME
       namespace: config-management-system
     roleRef:
       kind: ClusterRole
       name: RECONCILER_ROLE
       apiGroup: rbac.authorization.k8s.io
    

    Remplacez les éléments suivants :

    • NAMESPACE : ajoutez le nom de votre espace de noms.
    • SERVICE_ACCOUNT_NAME : ajoutez le nom du compte de service du rapprochement. Si le nom RepoSync est repo-sync, SERVICE_ACCOUNT_NAME est ns-reconciler-NAMESPACE. Sinon, il est défini sur ns-reconciler-NAMESPACE-REPO_SYNC_NAME-REPO_SYNC_NAME_LENGTH. Par exemple, si le nom de votre objet RepoSync est prod, le champ SERVICE_ACCOUNT_NAME serait ns-reconciler-NAMESPACE-prod-4. L'entier 4 est utilisé, car prod contient quatre caractères.
    • RECONCILER_ROLE : en tant qu'administrateur central, vous pouvez définir RECONCILER_ROLE pour appliquer les types de configuration pouvant être synchronisés à partir du dépôt d'espaces de noms. Vous pouvez choisir l'un des rôles suivants :

      • Un ClusterRole par défaut :

        • admin
        • edit

        Pour en savoir plus, consultez la section Rôles pour les utilisateurs.

      • Un rôle ClusterRole ou Role défini par l'utilisateur et déclaré dans le dépôt racine. Ce rôle permet des autorisations précises.

  4. Effectuez un commit des modifications dans le dépôt racine :

     git add .
     git commit -m 'Setting up a new namespace repository.'
     git push
    
  5. Si nécessaire, créez un secret basé sur la méthode d'authentification de votre choix. Si vous avez utilisé none comme type d'authentification, vous pouvez ignorer cette étape.

    Le Secret doit répondre aux exigences suivantes :

    • Créez le Secret dans le même espace de noms que l'objet RepoSync.
    • Le nom du Secret doit correspondre au nom spec.git.secretRef que vous avez défini dans repo-sync.yaml.
    • Vous devez ajouter la clé publique du Secret au fournisseur Git.
  6. Pour vérifier la configuration, utilisez kubectl get sur l'un des objets du dépôt d'espaces de noms. Exemple :

    kubectl get rolebindings -n NAMESPACE
    
  7. Vous pouvez répéter les étapes ci-dessus si vous devez configurer plusieurs dépôts d'espaces de noms.

Contrôler les dépôts d'espaces de noms dans un dépôt d'espaces de noms

Config Sync accepte la synchronisation à partir de plusieurs dépôts d'espaces de noms par espace de noms dans les versions 1.11.0 et ultérieures. Les dépôts d'espaces de noms peuvent être gérés dans un dépôt d'espaces de noms, dans le même espace de noms.

Pour utiliser cette méthode, effectuez les tâches suivantes :

  1. Dans un dépôt d'espaces de noms, créez un objet RepoSync dans le même espace de noms :

    apiVersion: configsync.gke.io/v1beta1
    kind: RepoSync
    metadata:
      name: REPO_SYNC_NAME
      namespace: NAMESPACE
    spec:
      # Since this is for a namespace repository, the format should be unstructured
      sourceFormat: unstructured
      git:
       repo: NAMESPACE_REPOSITORY
       revision: NAMESPACE_REVISION
       branch: NAMESPACE_BRANCH
       dir: "NAMESPACE_DIRECTORY"
       auth: NAMESPACE_AUTH_TYPE
       gcpServiceAccountEmail: NAMESPACE_EMAIL
       secretRef:
         name: NAMESPACE_SECRET_NAME
       noSSLVerify: NAMESPACE_NO_SSL_VERIFY
       caCertSecretRef:
         name: NAMESPACE_CA_CERT_SECRET_NAME
    

    Remplacez les éléments suivants :

    • REPO_SYNC_NAME : ajoutez le nom de votre objet RepoSync. Le nom doit être unique dans l'espace de noms. REPO_SYNC_NAME et NAMESPACE ne doivent pas comporter plus de 24 caractères. Si NAMESPACE_AUTH_TYPE est utilisé, REPO_SYNC_NAME, NAMESPACE et NAMESPACE_AUTH_TYPE ne doivent pas comporter plus de 44 caractères.
    • NAMESPACE : ajoutez le nom de votre espace de noms.
    • NAMESPACE_REPOSITORY : ajoutez l'URL du dépôt Git à utiliser comme dépôt de l'espace de noms. Vous pouvez saisir des URL à l'aide du protocole HTTPS ou SSH. Par exemple, https://github.com/GoogleCloudPlatform/anthos-config-management-samples utilise le protocole HTTPS. Si vous ne saisissez pas de protocole, l'URL est traitée comme une URL HTTPS. Ce champ est obligatoire.
    • NAMESPACE_REVISION : ajoutez la révision Git (tag ou hachage) à récupérer. Ce champ est facultatif et la valeur par défaut est HEAD.
    • NAMESPACE_BRANCH : ajoutez la branche du dépôt à partir de laquelle la synchronisation doit être effectuée. Ce champ est facultatif et la valeur par défaut est master.
    • NAMESPACE_DIRECTORY : ajoutez le chemin d'accès dans le dépôt Git au répertoire racine contenant la configuration que vous souhaitez synchroniser. Ce champ est facultatif et le paramètre par défaut est le répertoire racine (/) du dépôt.
    • NAMESPACE_AUTH_TYPE : ajoutez l'un des types d'authentification suivants :

      • none : n'utiliser aucune authentification
      • ssh : utiliser une paire de clés SSH
      • cookiefile : utiliser un cookiefile
      • token : utiliser un jeton
      • gcpserviceaccount : utiliser un compte de service Google pour accéder à un dépôt dans Cloud Source Repositories
      • gcenode : utiliser un compte de service Google pour accéder à un dépôt dans Cloud Source Repositories. Ne sélectionnez cette option que si Workload Identity n'est pas activé dans votre cluster.

        Pour en savoir plus sur ces types d'authentification, consultez la page Accorder à Config Sync un accès en lecture seule à Git.

      Ce champ est obligatoire.

    • NAMESPACE_EMAIL : si vous avez ajouté gcpserviceaccount comme NAMESPACE_AUTH_TYPE, ajoutez l'adresse e-mail de votre compte de service Google. Par exemple, acm@PROJECT_ID.iam.gserviceaccount.com.

    • NAMESPACE_SECRET_NAME : ajoutez le nom que vous souhaitez donner à votre Secret. Ce champ est facultatif.

    • NAMESPACE_NO_SSL_VERIFY : pour désactiver la validation du certificat SSL, définissez ce champ sur true. La valeur par défaut est false.

    • NAMESPACE_CA_CERT_SECRET_NAME: ajoutez le nom de votre secret. Si ce champ est défini, votre fournisseur Git doit utiliser un certificat émis par cette autorité de certification. Le secret doit contenir le certificat CA sous une clé nommée cert. Ce champ est facultatif.

      Pour en savoir plus sur la configuration de l'objet Secret pour le certificat CA, consultez Configurer l'opérateur pour une autorité de certification.

    Pour obtenir une explication des champs et une liste complète des champs que vous pouvez ajouter au champ spec, consultez la section Champs RepoSync.

  2. Dans le dépôt racine, déclarez une configuration RoleBinding qui accorde au compte de service SERVICE_ACCOUNT_NAME l'autorisation de gérer des objets dans l'espace de noms. Config Sync crée automatiquement le compte de service SERVICE_ACCOUNT_NAME lorsque la configuration RepoSync est synchronisée avec le cluster.

    Pour déclarer RoleBinding, créez l'objet suivant :

    # ROOT_REPO/namespaces/NAMESPACE/sync-rolebinding.yaml
     kind: RoleBinding
     apiVersion: rbac.authorization.k8s.io/v1
     metadata:
       name: syncs-repo
       namespace: NAMESPACE
     subjects:
     - kind: ServiceAccount
       name: SERVICE_ACCOUNT_NAME
       namespace: config-management-system
     roleRef:
       kind: ClusterRole
       name: RECONCILER_ROLE
       apiGroup: rbac.authorization.k8s.io
    

    Remplacez les éléments suivants :

    • NAMESPACE : ajoutez le nom de votre espace de noms.
    • SERVICE_ACCOUNT_NAME : ajoutez le nom du compte de service du rapprochement. Si le nom RepoSync est repo-sync, SERVICE_ACCOUNT_NAME est ns-reconciler-NAMESPACE. Sinon, il est défini sur ns-reconciler-NAMESPACE-REPO_SYNC_NAME-REPO_SYNC_NAME_LENGTH. Par exemple, si le nom de votre objet RepoSync est prod, le champ SERVICE_ACCOUNT_NAME serait ns-reconciler-NAMESPACE-prod-4. L'entier 4 est utilisé, car prod contient quatre caractères.
    • RECONCILER_ROLE : en tant qu'administrateur central, vous pouvez définir RECONCILER_ROLE pour appliquer les types de configuration pouvant être synchronisés à partir du dépôt d'espaces de noms. Vous pouvez choisir l'un des rôles suivants :

      • Un ClusterRole par défaut :

        • admin
        • edit

        Pour en savoir plus, consultez la section Rôles pour les utilisateurs.

      • Un rôle ClusterRole ou Role défini par l'utilisateur et déclaré dans le dépôt racine. Ce rôle permet des autorisations précises.

  3. Effectuez un commit des modifications dans le dépôt racine :

     git add .
     git commit -m 'Setting up a new namespace repository.'
     git push
    
  4. Si nécessaire, créez un secret basé sur la méthode d'authentification de votre choix. Si vous avez utilisé none comme type d'authentification, vous pouvez ignorer cette étape.

    Le Secret doit répondre aux exigences suivantes :

    • Créez le Secret dans le même espace de noms que l'objet RepoSync.
    • Le nom du Secret doit correspondre au nom spec.git.secretRef que vous avez défini dans repo-sync.yaml.
    • Vous devez ajouter la clé publique du Secret au fournisseur Git.
  5. Pour vérifier la configuration, utilisez kubectl get sur l'un des objets du dépôt d'espaces de noms. Exemple :

    kubectl get rolebindings -n NAMESPACE
    
  6. Vous pouvez répéter les étapes ci-dessus si vous devez configurer plusieurs dépôts d'espaces de noms.

Contrôler les dépôts avec l'API Kubernetes

Dans cette méthode, l'administrateur central délègue la déclaration des autres objets RootSync à d'autres administrateurs. Pour les objets RepoSync, l'administrateur central ne déclare que l'espace de noms dans le dépôt racine et délègue la déclaration de l'objet RepoSync à l'opérateur d'application.

Contrôler les dépôts racines

Les autres administrateurs peuvent contrôler les dépôts racines en effectuant les tâches suivantes :

  1. Déclarez un objet RootSync :

    # root-sync.yaml
    apiVersion: configsync.gke.io/v1beta1
    kind: RootSync
    metadata:
      name: ROOT_SYNC_NAME
      namespace: config-management-system
    spec:
      sourceFormat: ROOT_FORMAT
      git:
        repo: ROOT_REPOSITORY
        revision: ROOT_REVISION
        branch: ROOT_BRANCH
        dir: "ROOT_DIRECTORY"
        auth: ROOT_AUTH_TYPE
        gcpServiceAccountEmail: ROOT_EMAIL
        secretRef:
          name: ROOT_SECRET_NAME
        noSSLVerify: ROOT_NO_SSL_VERIFY
        caCertSecretRef:
          name: ROOT_CA_CERT_SECRET_NAME
    

    Remplacez les éléments suivants :

    • ROOT_SYNC_NAME : ajoutez le nom de votre objet RootSync. Pour les versions antérieures à 1.11.0, il doit s'agir de root-sync. Pour les versions 1.11.0 ou ultérieures, le nom doit être unique dans le cluster et ne pas dépasser 26 caractères.
    • ROOT_FORMAT : ajoutez unstructured pour utiliser un dépôt non structuré ou hierarchy pour utiliser un dépôt hiérarchique. Ces valeurs sont sensibles à la casse. Ce champ est facultatif et la valeur par défaut est hierarchy. Nous vous recommandons d'ajouter la valeur unstructured, car ce format vous permet d'organiser vos configurations de la manière la plus adaptée à vos besoins.
    • ROOT_REPOSITORY : ajoutez l'URL du dépôt Git à utiliser comme dépôt racine. Vous pouvez saisir des URL à l'aide du protocole HTTPS ou SSH. Par exemple, https://github.com/GoogleCloudPlatform/anthos-config-management-samples utilise le protocole HTTPS. Si vous ne saisissez pas de protocole, l'URL est traitée comme une URL HTTPS. Ce champ est obligatoire.
    • ROOT_REVISION : ajoutez la révision Git (tag ou hachage) à récupérer. Ce champ est facultatif et la valeur par défaut est HEAD.
    • ROOT_BRANCH : ajoutez la branche du dépôt à partir de laquelle la synchronisation doit être effectuée. Ce champ est facultatif et la valeur par défaut est master.
    • ROOT_DIRECTORY : ajoutez le chemin d'accès dans le dépôt Git au répertoire racine contenant la configuration que vous souhaitez synchroniser. Ce champ est facultatif et le paramètre par défaut est le répertoire racine (/) du dépôt.
    • ROOT_AUTH_TYPE : ajoutez l'un des types d'authentification suivants :

      • none : n'utiliser aucune authentification
      • ssh : utiliser une paire de clés SSH
      • cookiefile : utiliser un cookiefile
      • token : utiliser un jeton
      • gcpserviceaccount : utiliser un compte de service Google pour accéder à un dépôt dans Cloud Source Repositories
      • gcenode : utiliser un compte de service Google pour accéder à un dépôt dans Cloud Source Repositories. Ne sélectionnez cette option que si Workload Identity n'est pas activé dans votre cluster.

        Pour en savoir plus sur ces types d'authentification, consultez la page Accorder à Config Sync un accès en lecture seule à Git.

      Ce champ est obligatoire.

    • ROOT_EMAIL : si vous avez ajouté gcpserviceaccount comme ROOT_AUTH_TYPE, ajoutez l'adresse e-mail de votre compte de service Google. Par exemple, acm@PROJECT_ID.iam.gserviceaccount.com.

    • ROOT_SECRET_NAME : ajoutez le nom de votre secret. Si vous utilisez un secret, vous devez ajouter la clé publique du secret au fournisseur Git. Ce champ est facultatif.

    • ROOT_NO_SSL_VERIFY : pour désactiver la validation du certificat SSL, définissez ce champ sur true. La valeur par défaut est false.

    • ROOT_CA_CERT_SECRET_NAME: ajoutez le nom de votre secret. Si ce champ est défini, votre fournisseur Git doit utiliser un certificat émis par cette autorité de certification. Le secret doit contenir le certificat CA sous une clé nommée cert. Ce champ est facultatif.

      Pour en savoir plus sur la configuration de l'objet Secret pour le certificat CA, consultez Configurer l'opérateur pour une autorité de certification.

    Pour obtenir une explication des champs et une liste complète des champs que vous pouvez ajouter au champ spec, consultez la section Champs RootSync.

  2. Appliquez les modifications :

    kubectl apply -f root-sync.yaml
    
  3. Vous pouvez répéter les étapes ci-dessus si vous devez configurer plusieurs dépôts racines.

Contrôler les dépôts d'espaces de noms

Tâches administratives centrales

L'administrateur central effectue les tâches suivantes :

  1. Dans le dépôt racine, déclarez une configuration namespace pour les dépôts d'espaces de noms.

    # ROOT_REPO/namespaces/NAMESPACE/namespace.yaml
     apiVersion: v1
     kind: Namespace
     metadata:
       name: NAMESPACE
    

    Remplacez NAMESPACE par le nom de votre espace de noms.

  2. Dans le dépôt racine, déclarez un RoleBinding pour accorder les autorisations aux opérateurs d'application. Utilisez la prévention de l'élévation RBAC pour vous assurer que l'opérateur d'application ne pourra pas appliquer ultérieurement une liaison de rôle avec des autorisations non accordées par cette liaison de rôle.

    Pour déclarer l'objet RoleBinding, créez le fichier manifeste suivant :

    # ROOT_REPO/namespaces/NAMESPACE/operator-rolebinding.yaml
     kind: RoleBinding
     # Add RBAC escalation prevention
     apiVersion: rbac.authorization.k8s.io/v1
     metadata:
       name: operator
       namespace: NAMESPACE
     subjects:
     - kind: User
       name: USERNAME
       apiGroup: rbac.authorization.k8s.io
     roleRef:
       kind: ClusterRole
       name: OPERATOR_ROLE
       apiGroup: rbac.authorization.k8s.io
    

    Remplacez les éléments suivants :

    • NAMESPACE : ajoutez l'espace de noms que vous avez créé dans le dépôt racine.
    • USERNAME : ajoutez le nom d'utilisateur de l'opérateur d'application.
    • OPERATOR_ROLE : en tant qu'administrateur central, vous pouvez définir OPERATOR_ROLE pour appliquer les types de configuration pouvant être synchronisés à partir du dépôt d'espaces de noms. Vous pouvez choisir l'un des rôles suivants :

      • Un ClusterRole par défaut :

        • admin
        • edit

        Pour en savoir plus, consultez la section Rôles pour les utilisateurs.

      • Un ClusterRole ou Role défini par l'utilisateur déclaré dans le dépôt racine. Ce rôle permet des autorisations précises.

  3. Effectuez un commit des modifications dans le dépôt racine :

     git add .
     git commit -m 'Setting up new namespace repository.'
     git push
    

Tâches de l'opérateur d'application

L'opérateur d'application peut contrôler les dépôts d'espaces de noms en effectuant les tâches suivantes :

  1. Déclarez une configuration RoleBinding qui accorde au compte de service SERVICE_ACCOUNT_NAME provisionné automatiquement l'autorisation de gérer les objets de l'espace de noms. Config Sync crée automatiquement le compte de service SERVICE_ACCOUNT_NAME lorsque la configuration RepoSync est synchronisée avec le cluster.

    Pour déclarer l'objet RoleBinding, créez le fichier manifeste suivant :

    # sync-rolebinding.yaml
    kind: RoleBinding
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: syncs-repo
      namespace: NAMESPACE
    subjects:
    - kind: ServiceAccount
      name: SERVICE_ACCOUNT_NAME
      namespace: config-management-system
    roleRef:
      kind: ClusterRole
      name: RECONCILER_ROLE
      apiGroup: rbac.authorization.k8s.io
    

    Remplacez les éléments suivants :

    • NAMESPACE : ajoutez l'espace de noms que vous avez créé dans le dépôt racine.
    • SERVICE_ACCOUNT_NAME : ajoutez le nom du compte de service du rapprochement. Si le nom RepoSync est repo-sync, SERVICE_ACCOUNT_NAME est ns-reconciler-NAMESPACE. Sinon, il est défini sur ns-reconciler-NAMESPACE-REPO_SYNC_NAME.
    • RECONCILER_ROLE : en tant qu'opérateur d'application, vous pouvez définir RECONCILER_ROLE pour appliquer les types de configuration pouvant être synchronisés à partir du dépôt d'espaces de noms. Vous ne pouvez restreindre davantage l'ensemble d'autorisations que l'administrateur central vous a accordées. Par conséquent, ce rôle ne peut pas être plus permissif que OPERATOR_ROLE que l'administrateur central a déclaré dans la section précédente.
  2. Appliquez la configuration RoleBinding :

    kubectl apply -f sync-rolebinding.yaml
    
  3. Si nécessaire, créez un secret basé sur la méthode d'authentification de votre choix. Si vous avez utilisé none comme type d'authentification, vous pouvez ignorer cette étape.

    Le Secret doit répondre aux exigences suivantes :

    • Créez le Secret dans le même espace de noms que l'objet RepoSync.
    • Le nom du Secret doit correspondre au nom spec.git.secretRef que vous avez défini dans root-sync.yaml.
    • Vous devez ajouter la clé publique du Secret au fournisseur Git.
  4. Déclarez une configuration RepoSync :

    # repo-sync.yaml
    # If you are using a Config Sync version earlier than 1.8.0,
    # use: apiVersion: configsync.gke.io/v1alpha1
    apiVersion: configsync.gke.io/v1beta1
    kind: RepoSync
    metadata:
      name: REPO_SYNC_NAME
      namespace: NAMESPACE
    spec:
      # Since this is for a namespace repository, the format should be unstructured
      sourceFormat: unstructured
      git:
       repo: NAMESPACE_REPOSITORY
       revision: NAMESPACE_REVISION
       branch: NAMESPACE_BRANCH
       dir: "NAMESPACE_DIRECTORY"
       auth: NAMESPACE_AUTH_TYPE
       gcpServiceAccountEmail: NAMESPACE_EMAIL
       secretRef:
         name: NAMESPACE_SECRET_NAME
       # The `noSSLVerify` field is supported in Anthos Config Management version 1.8.2 and later.
       noSSLVerify: REPO_SSL_VERIFY
       caCertSecretRef:
         name: NAMESPACE_CA_CERT_SECRET_NAME
    

    Remplacez les éléments suivants :

    • REPO_SYNC_NAME : ajoutez le nom de votre objet RepoSync. Pour les versions antérieures à 1.11.0, il doit s'agir de repo-sync. Pour les versions 1.11.0 ou ultérieures, spécifiez le nom de votre choix.
    • NAMESPACE_REPOSITORY : ajoutez l'URL du dépôt Git à utiliser comme dépôt de l'espace de noms. Vous pouvez saisir des URL à l'aide du protocole HTTPS ou SSH. Par exemple, https://github.com/GoogleCloudPlatform/anthos-config-management-samples utilise le protocole HTTPS. Si vous ne saisissez pas de protocole, l'URL est traitée comme une URL HTTPS. Ce champ est obligatoire.
    • NAMESPACE_REVISION : ajoutez la révision Git (tag ou hachage) à récupérer. Ce champ est facultatif et la valeur par défaut est HEAD.
    • NAMESPACE_BRANCH : ajoutez la branche du dépôt à partir de laquelle la synchronisation doit être effectuée. Ce champ est facultatif et la valeur par défaut est master.
    • NAMESPACE_DIRECTORY : ajoutez le chemin d'accès dans le dépôt Git au répertoire racine contenant la configuration que vous souhaitez synchroniser. Ce champ est facultatif et le paramètre par défaut est le répertoire racine (/) du dépôt.
    • NAMESPACE_AUTH_TYPE : ajoutez l'un des types d'authentification suivants :

      • none : n'utiliser aucune authentification
      • ssh : utiliser une paire de clés SSH
      • cookiefile : utiliser un cookiefile
      • token : utiliser un jeton
      • gcpserviceaccount : utiliser un compte de service Google pour accéder à un dépôt dans Cloud Source Repositories
      • gcenode : utiliser un compte de service Google pour accéder à un dépôt dans Cloud Source Repositories. Ne sélectionnez cette option que si Workload Identity n'est pas activé dans votre cluster.

        Pour en savoir plus sur ces types d'authentification, consultez la page Accorder à Config Sync un accès en lecture seule à Git.

      Ce champ est obligatoire.

    • NAMESPACE_EMAIL : si vous avez ajouté gcpserviceaccount comme NAMESPACE_AUTH_TYPE, ajoutez l'adresse e-mail de votre compte de service Google. Par exemple, acm@PROJECT_ID.iam.gserviceaccount.com.

    • NAMESPACE_SECRET_NAME : ajoutez le nom que vous souhaitez donner à votre Secret. Ce champ est facultatif.

    • NAMESPACE_NO_SSL_VERIFY : pour désactiver la validation du certificat SSL, définissez ce champ sur true. La valeur par défaut est false.

    • NAMESPACE_CA_CERT_SECRET_NAME: ajoutez le nom de votre secret. Si ce champ est défini, votre fournisseur Git doit utiliser un certificat émis par cette autorité de certification. Le secret doit contenir le certificat CA sous une clé nommée cert. Ce champ est facultatif.

      Pour en savoir plus sur la configuration de l'objet Secret pour le certificat CA, consultez Configurer l'opérateur pour une autorité de certification.

    Pour obtenir une explication des champs et une liste complète des champs que vous pouvez ajouter au champ spec, consultez la section Champs RepoSync.

    Il peut y avoir au maximum un objet RepoSync par espace de noms. Pour appliquer cette règle, le nom de l'objet name doit être repo-sync. Toutes les configurations contenues dans le répertoire référencé par RepoSync doivent également se trouver dans le même espace de noms que l'objet RepoSync.

  5. Appliquez la configuration RepoSync :

    kubectl apply -f repo-sync.yaml
    
  6. Pour vérifier la configuration, utilisez kubectl get sur l'un des objets du dépôt d'espaces de noms. Exemple :

    kubectl get rolebindings -n NAMESPACE
    
  7. Vous pouvez répéter les étapes ci-dessus si vous devez configurer plusieurs dépôts d'espaces de noms.

Vérifier l'état de synchronisation du dépôt

Vous pouvez exécuter la commande nomos status pour vérifier l'état de synchronisation du dépôt :

nomos status

Un résultat semblable aux lignes suivantes doit s'afficher :

my_managed_cluster-1
  --------------------
  <root>   git@github.com:foo-corp/acme/admin@main
  SYNCED   f52a11e4
  --------------------
  bookstore  git@github.com:foo-corp/acme/bookstore@v1
  SYNCED     34d1a8c8

Dans cet exemple de résultat, le dépôt d'espaces de noms est configuré pour l'espace de noms nommé bookstore.

Vérifier l'installation de RootSync

Lorsque vous créez un objet RootSync, Config Sync crée un rapprochement avec le préfixe root-reconciler. Un rapprochement est un pod qui est déployé en tant que déploiement. Il synchronise les fichiers manifestes d'un dépôt Git avec un cluster.

Vous pouvez vérifier que l'objet RootSync fonctionne correctement en vérifiant l'état du déploiement du rapprochement racine :

Pour Config Sync 1.11.0 et les versions antérieures :

kubectl get -n config-management-system deployment/root-reconciler

Pour Config Sync 1.11.0 et les versions ultérieures :

kubectl get -n config-management-system deployment -l configsync.gke.io/sync-name=ROOT_SYNC_NAME

Remplacez ROOT_SYNC_NAME par le nom de RootSync.

Un résultat semblable aux lignes suivantes doit s'afficher :

NAME              READY   UP-TO-DATE   AVAILABLE   AGE
root-reconciler   1/1     1            1           3h42m

Pour découvrir d'autres moyens d'explorer l'état de votre objet RootSync, consultez la page Surveiller les objets RootSync et RepoSync.

Vérifier l'installation de RepoSync

Lorsque vous créez un objet RepoSync, Config Sync crée un rapprochement avec le préfixe ns-reconciler-NAMESPACE, où NAMESPACE est l'espace de noms dans lequel vous avez créé votre objet RepoSync.

Vous pouvez vérifier que l'objet RepoSync fonctionne correctement en vérifiant l'état du déploiement du rapprochement de l'espace de noms :

Pour Config Sync 1.11.0 et les versions antérieures :

kubectl get -n config-management-system deployment/ns-reconciler-NAMESPACE

Remplacez NAMESPACE par l'espace de noms dans lequel vous avez créé votre dépôt d'espaces de noms.

Pour Config Sync 1.11.0 et les versions ultérieures :

kubectl get -n config-management-system deployment \
  -l configsync.gke.io/sync-name=REPO_SYNC_NAME \
  -l configsync.gke.io/sync-namespace=NAMESPACE

Remplacez REPO_SYNC_NAME par le nom de RepoSync et remplacez NAMESPACE par l'espace de noms dans lequel vous avez créé votre dépôt d'espaces de noms.

Pour analyser plus en détail l'état de votre objet RepoSync, consultez la section Explorer les objets RootSync et RepoSync.

Supprimer un dépôt

Sélectionnez l'onglet Méthode de contrôle centralisé ou Méthode de l'API Kubernetes pour afficher les instructions correspondantes.

Méthode de contrôle centralisé

Si vous avez utilisé la méthode Contrôler les dépôts dans un dépôt central, un administrateur central peut suivre les deux étapes suivantes pour supprimer un dépôt :

  1. Annulez la gestion ou supprimez les ressources gérées par l'objet RootSync ou RepoSync en suivant les instructions de dépannage.

  2. Supprimez l'objet RootSync ou RepoSync du dépôt Git.

Méthode de l'API Kubernetes

Si vous avez utilisé la méthode Contrôler les dépôts d'espace de noms avec l'API Kubernetes, les opérateurs d'application peuvent suivre les deux étapes suivantes pour supprimer un dépôt d'espaces de noms :

  1. Annulez la gestion ou supprimez les ressources gérées par l'objet RootSync ou RepoSync en suivant les instructions de dépannage.

  2. Supprimez l'objet RootSync ou RepoSync en exécutant la commande suivante :

    kubectl delete -f FILE_NAME
    

    Remplacez FILE_NAME par root-sync.yaml ou repo-sync.yaml.

Étapes suivantes