Esta página se ha traducido con Cloud Translation API.

Migrar el objeto ConfigManagement

En esta página se explica cómo migrar la configuración de Git de un objeto ConfigManagement a un objeto RootSync. La migración habilita las APIs RootSync y RepoSync, lo que te permite usar funciones adicionales:

Puedes habilitar estas APIs aunque solo quieras usar un repositorio raíz y no quieras usar ningún repositorio de espacio de nombres.

Migrar la configuración de ConfigManagement

Si usas RootSync con spec.enableLegacyFields, sigue las instrucciones para dejar de usar campos antiguos.

Si tu objeto ConfigManagement usa spec.git, pero spec.enableMultiRepo tiene el valor false, sigue las instrucciones para migrar a RootSync.

Dejar de usar campos antiguos

En la versión 1.19.0 y posteriores, el campo spec.enableLegacyFields no se admite y, si se define, se producirán errores. Para usar la versión 1.19.0 o posterior de Config Sync, sigue estos pasos para quitar los campos antiguos:

Abre el objeto ConfigManagement.

En el objeto ConfigManagement, elimina los campos spec.enableLegacyFields y spec.git. El objeto ConfigManagement debe ser similar al siguiente:

# config-management.yaml
apiVersion: configmanagement.gke.io/v1
kind: ConfigManagement
metadata:
  name: config-management
spec:
  enableMultiRepo: true

Aplica los cambios:

kubectl apply -f config-management.yaml

Los campos antiguos ahora están inhabilitados sin que afecte al objeto RootSync generado a partir de los campos spec.git de su objeto ConfigManagement. La migración se ha completado y ahora puedes usar los campos de Git directamente en el objeto RootSync.

Migrar a RootSync

Si tu objeto ConfigManagement usa spec.git, pero spec.enableMultiRepo tiene el valor false, sigue esta guía para habilitar las APIs RootSync y RepoSync.

Usar `nomos migrate`

A partir de la versión 1.10.0, nomos proporciona el comando nomos migrate para habilitar las APIs RootSync y RepoSync. Debes actualizar nomos a la versión 1.10.0 o una posterior.

Para obtener más información sobre cómo ejecutar el comando, consulta Migrar de un objeto ConfigManagement a un objeto RootSync. Asegúrate de que tu objeto ConfigManagement no se haya registrado en tu fuente de información veraz y de que no lo gestione Config Sync. Si es así, debes modificar el objeto ConfigManagement en tu fuente de información siguiendo los pasos que se indican en Migración manual.

Migración manual

Si tu versión de nomos es anterior a la 1.10.0, puedes migrar manualmente tu configuración. Debes definir spec.enableMultiRepo como true en tu objeto ConfigManagement y crear un objeto RootSync que sincronice tu repositorio raíz con el clúster. El repositorio raíz puede ser un repositorio no estructurado o un repositorio jerárquico. Una vez que hayas migrado para usar el objeto RootSync, podrás dividir un repositorio en varios repositorios y configurar la sincronización desde varios repositorios.

Para configurar el repositorio raíz migrando la configuración, completa las siguientes tareas:

Abre el objeto ConfigManagement.
Haz una copia de los valores de los campos spec.git. Estos valores se usan al crear el objeto RootSync.
Elimina todos los campos spec.git (incluido git:) del objeto ConfigManagement.

En el objeto ConfigManagement, asigna el valor spec.enableMultiRepo al campo true:

# config-management.yaml
apiVersion: configmanagement.gke.io/v1
kind: ConfigManagement
metadata:
  name: config-management
spec:
  enableMultiRepo: true

Aplica los cambios:

kubectl apply -f config-management.yaml

Espera a que se cree el CRD RootSync.

kubectl wait --for=condition=established crd rootsyncs.configsync.gke.io

Con los valores que has copiado del objeto ConfigManagement, crea el objeto RootSync. Por ejemplo:
```
# root-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: root-sync
  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 should be omitted if the auth type is none, gcenode, or gcpserviceaccount.
    secretRef:
      name: git-creds
```
Haz los cambios siguientes:
- ROOT_FORMAT: añade unstructured para usar un repositorio no estructurado o añade hierarchy para usar un repositorio jerárquico. En estos valores se distingue entre mayúsculas y minúsculas. Este campo es opcional y su valor predeterminado es hierarchy. Te recomendamos que añadas unstructured, ya que este formato te permite organizar tus configuraciones de la forma que te resulte más cómoda.
- ROOT_REPOSITORY: añade la URL del repositorio de Git que quieras usar como repositorio raíz. Puede introducir URLs con el protocolo HTTPS o SSH. Por ejemplo, https://github.com/GoogleCloudPlatform/anthos-config-management-samples usa el protocolo HTTPS. Si no introduces ningún protocolo, la URL se tratará como una URL HTTPS. Este campo es obligatorio.
- ROOT_REVISION: añade la revisión de Git (etiqueta o hash) que debe consultarse. Este campo es opcional y su valor predeterminado es HEAD.
- ROOT_BRANCH: añade la rama del repositorio desde la que se hará la sincronización. Este campo es opcional y su valor predeterminado es master.
- ROOT_DIRECTORY: añade la ruta del repositorio de Git al directorio raíz que contiene la configuración que quieres sincronizar. Este campo es opcional y el valor predeterminado es el directorio raíz (/) del repositorio.
- ROOT_AUTH_TYPE: añade uno de los siguientes tipos de autenticación:
  - none: no usar autenticación
  - ssh: usar un par de claves SSH
  - cookiefile: usa un cookiefile
  - token: usar un token
  - gcpserviceaccount: usa una cuenta de servicio de Google para acceder a un repositorio en Cloud Source Repositories.
  - gcenode: usa una cuenta de servicio de Google para acceder a un repositorio en Cloud Source Repositories. Selecciona esta opción solo si Workload Identity Federation para GKE no está habilitado en tu clúster.
    
    Para obtener más información sobre estos tipos de autenticación, consulta el artículo Conceder acceso de solo lectura a Git a Config Sync.
  Este campo es obligatorio.
- ROOT_EMAIL: Si has añadido gcpserviceaccount como tu ROOT_AUTH_TYPE, añade la dirección de correo de tu cuenta de servicio de Google. Por ejemplo, acm@PROJECT_ID.iam.gserviceaccount.com.
Aplica los cambios:
```
kubectl apply -f root-sync.yaml
```

Tabla comparativa de ConfigManagement y RootSync

En la siguiente tabla se ofrece un resumen de cómo se asignan los campos del objeto ConfigMangent a los campos de un objeto RootSync.

Campo ConfigManagement	Campo RootSync
`spec.git.gcpServiceAccountEmail`	`spec.git.gcpServiceAccountEmail`
`spec.git.syncRepo`	`spec.git.repo`
`spec.git.syncBranch`	`spec.git.branch`
`spec.git.policyDir`	`spec.git.dir`
`spec.git.syncWait`	`spec.git.period`
`spec.git.syncRev`	`spec.git.revision`
`spec.git.secretType`	`spec.git.auth`
`git-creds` (este es un valor fijo en los objetos ConfigManagement)	`spec.git.secretRef.name`
`spec.sourceFormat`	`spec.sourceFormat`
`spec.git.proxy.httpProxy` o `spec.git.proxy.httpsProxy`	`spec.git.proxy`

Siguientes pasos

Configurar la sincronización desde varios repositorios