Se usó la API de Cloud Translation para traducir esta página.

Migra tu objeto ConfigManagement

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

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

Migra tus opciones de configuración de ConfigManagement

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

Si tu objeto ConfigManagement usa spec.git, pero spec.enableMultiRepo está configurado como "false", sigue las instrucciones para migrar a RootSync.

Deja de usar campos heredados

A partir de la versión 1.19.0 y versiones posteriores, el campo spec.enableLegacyFields no es compatible y configurarlo generará errores. Para usar el Sincronizador de configuración versión 1.19.0 y posteriores, completa los siguientes pasos para quitar los campos heredados:

Abre el objeto ConfigManagement.

En el objeto ConfigManagement, quita los campos spec.enableLegacyFields y spec.git. Tu objeto ConfigManagement debería 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 heredados ahora se inhabilitan sin afectar el objeto RootSync generado a partir de los campos spec.git de tu objeto ConfigManagement. La migración se completó y ahora puedes usar los campos de git en el objeto RootSync directamente.

Cómo migrar a RootSync

Si tu objeto ConfigManagement usa spec.git, pero spec.enableMultiRepo está configurado como "false", sigue esta guía para habilitar las APIs de RootSync y RepoSync.

Utilizar `nomos migrate`

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

Si deseas obtener más detalles para ejecutar el comando, sigue Migra desde un objeto ConfigManagement a un objeto RootSync. Asegúrate de que tu objeto ConfigManagement no se marque en tu fuente de información ni sea administrado por el Sincronizador de configuración. Si es así, debes modificar tu objeto ConfigManagement en tu fuente de confianza siguiendo los pasos que se indican en Migración manual.

Migración manual

Si tu versión de nomos es anterior a 1.10.0, puedes migrar la configuración de forma manual. Debes configurar 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. Después de migrar para usar el objeto RootSync, puedes dividir un repositorio en varios repositorios y configurar la sincronización de varios repositorios.

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

Abre el objeto ConfigManagement.
Haz una copia de los valores en los campos spec.git. Usa estos valores cuando crees el objeto RootSync.
Quita todos los campos spec.git (incluido git:) del objeto ConfigManagement.

En el objeto ConfigManagement, establece el campo spec.enableMultiRepo en 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 la CRD de RootSync.

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

Con los valores que copiaste 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
```
Reemplaza lo siguiente:
- ROOT_FORMAT: agrega unstructured para usar un repositorio no estructurado o agrega hierarchy a fin de usar un repositorio jerárquico. Estos valores distinguen entre mayúsculas y minúsculas. Este campo es opcional y el valor predeterminado es hierarchy. Te recomendamos que agregues unstructured, ya que este formato te permite organizar la configuración de la manera que te resulte más conveniente.
- ROOT_REPOSITORY: agrega la URL del repositorio de Git para usarlo como repositorio raíz. Puedes ingresar las URL con el protocolo HTTPS o SSH. Por ejemplo, https://github.com/GoogleCloudPlatform/anthos-config-management-samples usa el protocolo HTTPS. Si no ingresas un protocolo, la URL se trata como una URL HTTPS. Este campo es obligatorio.
- ROOT_REVISION: Agrega la revisión de Git (etiqueta o hash) que deseas consultar. Este campo es opcional y el valor predeterminado es HEAD.
- ROOT_BRANCH: Agrega la rama del repositorio desde la que se realiza la sincronización. Este campo es opcional y el valor predeterminado es master.
- ROOT_DIRECTORY: agrega la ruta de acceso en el repositorio de Git al directorio raíz que contiene la configuración con la que deseas sincronizar. Este campo es opcional y el predeterminado es el directorio raíz (/) del repositorio.
- ROOT_AUTH_TYPE: agrega uno de los siguientes tipos de autenticación:
  - none: No usa autenticación
  - ssh: Usa un par de claves SSH
  - cookiefile: Usa un objeto cookiefile
  - token: Usa 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 la Workload Identity Federation for GKE no está habilitada en tu clúster.
    
    Para obtener más información sobre estos tipos de autenticación, consulta Otorga a Git acceso de solo lectura al Sincronizador de configuración.
  Este campo es obligatorio.
- ROOT_EMAIL: Si agregaste gcpserviceaccount como tu ROOT_AUTH_TYPE, agrega la dirección de correo electrónico de la cuenta de servicio de Google. Por ejemplo, acm@PROJECT_ID.iam.gserviceaccount.com
Aplica los cambios:
```
kubectl apply -f root-sync.yaml
```

Tabla de comparación ConfigManagement y RootSync

En la siguiente tabla, se proporciona una descripción general de cómo los campos en tu objeto ConfigMangent se asignan a los campos en 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 objetos ConfigManagement)	`spec.git.secretRef.name`
`spec.sourceFormat`	`spec.sourceFormat`
`spec.git.proxy.httpProxy` o `spec.git.proxy.httpsProxy`	`spec.git.proxy`

¿Qué sigue?

Configura la sincronización desde varios repositorios