Ao usar um repositório não estruturado, é possível organizar seu repositório da maneira que for mais
conveniente para você. Essa flexibilidade permite sincronizar a configuração atual
do Kubernetes com o repositório do Config Sync. Por exemplo, se você quiser sincronizar um gráfico
Helm com seu cluster, execute o
comando helm template
e confirme a manifesto renderizado no seu repositório. Para mais informações,
consulte o tutorial Como usar o Config Sync com o Helm.
Repositórios não estruturados são recomendados para a maioria dos usuários. No entanto, também é possível criar um repositório hierárquico para separar configurações em categorias distintas. Se você quiser criar políticas hierárquicas sem aderir às regras do repositório hierárquico, use o Hierarchy Controller.
Limitações
Os repositórios não estruturados têm as seguintes limitações:
Não é possível usar objetos do Kubernetes
Repo
ouHierarchyConfig
e em um repositório não estruturado.Os namespaces abstratos não são compatíveis em repositórios não estruturados.
Se você estiver usando o comando
nomos vet
, adicione a sinalização--source-format=unstructured
. Exemplo:nomos vet --source-format=unstructured
Objetos com escopo no namespace
É possível declarar NamespaceSelectors em um repositório não estruturado. Para declarar um NamespaceSelector, adicione a anotação metadata.namespace
ou NamespaceSelector
. Declarar as duas anotações é inválido. Se os recursos com escopo de namespace não declararem metadata.namespace
ou a anotação NamespaceSelector
, o Config Sync usará o namespace "padrão" do cluster.
Para saber mais, consulte Limitar quais namespaces uma configuração afeta.
Objetos com escopo no cluster
Em um repositório não estruturado, ClusterSelectors
funciona normalmente.
Configurar um repositório não estruturado
Para configurar um repositório não estruturado, defina o valor de spec.sourceFormat
como
unstructured
no objeto 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
Substitua:
ROOT_SYNC_NAME
: adicione o nome do objeto RootSync. O nome precisa ser exclusivo no cluster e ter no máximo 26 caracteres.SECRET_NAME
pelo nome do Secret.
Converter um repositório hierárquico em um repositório não estruturado
Se você estiver usando um repositório hierárquico e quiser convertê-lo em um repositório não estruturado, no seu repositório, execute:
nomos hydrate PATH
Substitua PATH
pelo caminho para o diretório.
Esse comando cria um diretório compiled/
no diretório de trabalho atual. Nesse
diretório, um subdiretório é criado para cada cluster registrado, com as
configurações totalmente resolvidas, e cada subdiretório pode ser usado em um repositório
não estruturado.
Para mais detalhes, consulte comandos nomos
.
Se você preferir converter o repositório manualmente, siga estas instruções:
Remova as configurações
Repo
do diretóriosystem/
do repositório do Git. O recursoRepo
não é necessário para o repositório não estruturado.O diretório de namespace abstrato não é compatível com o repositório não estruturado. Portanto, é necessário declarar o namespace de todos os recursos originalmente incluídos no diretório
namespaces/
e nos subdiretórios dele.A herança de namespaces não é compatível com o repositório não estruturado. Portanto, você precisa declarar todos os recursos herdados originalmente nos namespaces descendentes, ou seja, os recursos originalmente no diretório
namespaces/
.
Exemplo de formato para um repositório não estruturado
Veja no exemplo a seguir como organizar as configurações (incluindo recursos do Google Cloud) em um repositório não estruturado:
├── 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
Neste exemplo, as configurações brutas estão em um diretório raw-configs
. Em seguida, é possível
usar um script ou um pipeline automatizado para renderizar as configurações brutas e armazenar
a saída no diretório manifests
. Ao
configurar o Config Sync,
ele é configurado para ser sincronizado do seu diretório manifests
.
A seguir
- Criar objetos com escopo de cluster
- Criar objetos com escopo de namespace
- Instale o Config Sync
- Configurar a sincronização a partir de vários repositórios