L'utilisation d'un dépôt non structuré vous permet d'organiser votre dépôt de la manière qui vous convient le mieux. Cette flexibilité vous permet de synchroniser votre configuration Kubernetes existante avec votre dépôt Config Sync. Par exemple, si vous souhaitez synchroniser un chart Helm avec votre cluster, vous pouvez exécuter la commande helm template
et effectuer un commit sur le fichier manifeste affiché dans votre dépôt. Pour en savoir plus, consultez le tutoriel Utiliser Config Sync avec Helm.
Les dépôts non structurés sont recommandés pour la plupart des utilisateurs. Toutefois, vous pouvez également créer un dépôt hiérarchique pour séparer les configurations en catégories distinctes. Si vous souhaitez créer des stratégies hiérarchiques sans respecter les règles du dépôt hiérarchique, envisagez d'utiliser Hierarchy Controller.
Limites
Les dépôts non structurés présentent les limites suivantes :
Vous ne pouvez pas utiliser les objets Kubernetes
Repo
etHierarchyConfig
dans un dépôt non structuré.Les espaces de noms abstraits ne sont pas compatibles avec les dépôts non structurés.
Si vous utilisez la commande
nomos vet
, ajoutez l'option--source-format=unstructured
. Exemple :nomos vet --source-format=unstructured
Objets à l'échelle d'un espace de noms
Vous pouvez déclarer des objets NamespaceSelector dans un dépôt non structuré. Pour déclarer un objet NamespaceSelector, ajoutez l'annotation metadata.namespace
ou NamespaceSelector
. Le fait de déclarer les deux annotations n'est pas valide. Si les ressources à l'échelle de l'espace de noms ne déclarent pas metadata.namespace
ou l'annotation NamespaceSelector
, Config Sync utilise l'espace de noms "par défaut" du cluster.
Pour en savoir plus, consultez la section Limiter les espaces de noms affectés par une configuration.
Objets à l'échelle d'un cluster
Dans un dépôt non structuré, ClusterSelectors
fonctionne normalement.
Configurer un dépôt non structuré
Pour configurer un dépôt non structuré, définissez la valeur de spec.sourceFormat
sur unstructured
dans votre objet RootSync :
# root-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
name: ROOT_SYNC_NAME
namespace: config-management-system
spec:
sourceFormat: unstructured
git:
repo: https://github.com/GoogleCloudPlatform/anthos-config-management-samples
branch: main
dir: config-sync-quickstart/multirepo/root
auth: ssh
secretRef:
name: 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.SECRET_NAME
par le nom du secret.
Convertir un dépôt hiérarchique en dépôt non structuré
Si vous utilisez un dépôt hiérarchique et souhaitez le convertir en dépôt non structuré, exécutez la commande suivante dans votre dépôt :
nomos hydrate PATH
Remplacez PATH
par le chemin d'accès au répertoire.
Cela crée un répertoire compiled/
dans le répertoire de travail actuel. Dans ce répertoire, un sous-répertoire est créé pour chaque cluster enregistré avec les configurations entièrement résolues. Chaque sous-répertoire peut être utilisé dans un dépôt non structuré.
Pour en savoir plus, consultez la section Commandes nomos
.
Si vous préférez convertir manuellement le dépôt, procédez comme suit :
Supprimez les configurations
Repo
du répertoiresystem/
de votre dépôt Git. La ressourceRepo
n'est pas nécessaire pour un dépôt non structuré.Le répertoire d'espace de noms abstrait n'est pas disponible dans un dépôt non structuré. Par conséquent, vous devez déclarer l'espace de noms de toutes les ressources initialement incluses dans le répertoire
namespaces/
et ses sous-répertoires.L'héritage des espaces de noms n'est pas disponible dans un dépôt non structuré. Par conséquent, vous devez déclarer toutes les ressources qui sont à l'origine héritées dans les espaces de noms descendants, à savoir celles qui se trouvent initialement dans le répertoire
namespaces/
.
Exemple de format pour un dépôt non structuré
L'exemple suivant montre comment organiser vos configurations (y compris les ressources Google Cloud) dans un dépôt non structuré :
├── manifests
│ ├── access-control
│ │ ├── ...
│ ├── change-control
│ │ ├── ...
│ ├── git-ops
│ │ └── ...
│ ├── logging-monitoring
│ │ └── ...
│ ├── networking
│ │ └── ...
│ ├── project-factory
│ │ └── ...
│ └── resource-hierarchy
│ │ └── ...
├── raw-configs
│ ├── access-control
│ │ └── ...
│ ├── change-control
│ │ └── ...
│ ├── git-ops
│ │ └── ...
│ ├── logging-monitoring
│ │ └── ...
│ ├── networking
│ │ └── ...
│ ├── project-factory
│ │ └── ...
│ └── resource-hierarchy
│ │ └── ...
└── scripts
└── render.sh
Dans cet exemple, les configurations brutes se trouvent dans un répertoire raw-configs
. Vous pouvez ensuite utiliser un script ou un pipeline automatisé pour afficher les configurations brutes et stocker le résultat dans le répertoire manifests
. Lorsque vous configurez Config Sync, vous devez également le configurer pour qu'il se synchronise à partir de votre répertoire manifests
.
Étape suivante
- Créer des objets à l'échelle d'un cluster
- Créer des objets à l'échelle d'un espace de noms
- Installer Config Sync
- Configurer la synchronisation à partir de plusieurs dépôts