Usa la herramienta de línea de comandos nomos

La herramienta de línea de comandos nomos es una herramienta opcional del Sincronizador de configuración. La herramienta de nomos te proporciona los siguientes comandos:

Comando	Uso
nomos status	Verifica el estado del Sincronizador de configuración
nomos vet	Comprueba si hay errores en el repositorio
nomos hydrate	Visualiza todas las configuraciones en el repositorio
nomos bugreport	Crea un informe de errores
nomos migrate	Migra de ConfigManagement a RootSync
nomos init	Inicializa un repositorio jerárquico

Requisitos previos

Antes de que puedas usar la herramienta nomos para interactuar con un clúster, el Sincronizador de configuración ya debe estar instalado en el clúster de destino. También debes configurar la herramienta de línea de comandos de kubectl para autenticarte en el clúster de destino mediante la generación de una entrada de kubeconfig.

La herramienta nomos admite la vista previa y la validación de los parámetros de configuración de Kustomize y los gráficos de Helm. Antes de poder usar esta función, instala Kustomize y Helm en tu estación de trabajo local. Si el repositorio solo contiene parámetros de configuración renderizadas por completo, Kustomize y Helm son opcionales.

Instala la herramienta nomos

La herramienta nomos es un objeto binario compilado a partir de código de Go y puedes instalarlo de forma local, por ejemplo, en una estación de trabajo o una laptop.

La herramienta nomos no se incluye cuando instalas el Sincronizador de configuración. Para instalar la herramienta nomos, puedes realizar la instalación de Google Cloud CLI. Si usas Cloud Shell, Google Cloud CLI viene preinstalada.

Si no tienes Google Cloud CLI, te recomendamos que uses gcloud components install nomos para instalar la herramienta nomos. Instalar la herramienta nomos con Google Cloud CLI te permite usar gcloud components update para actualizar la herramienta nomos a la versión más reciente.

Para obtener más información sobre las formas alternativas de instalar la herramienta nomos, consulta Descargas de Anthos Config Management.

Uso básico

Para la sintaxis del comando básico, usa el argumento --help:

nomos --help

La herramienta nomos lee desde la clonación local de tu repositorio. Usa la marca --path para especificar la ubicación del nivel superior del repositorio. De forma predeterminada, --path está configurado como . o el directorio actual. Por ejemplo:

nomos --path=PATH_TO_REPOSITORY vet

Verifica el estado del Sincronizador de configuración

Puedes supervisar el estado del Sincronizador de configuración en todos los clústeres inscritos con el comando nomos status. Para cada clúster, nomos status informa sobre el hash de la confirmación de Git que se aplicó por última vez al clúster, así como los errores que se produjeron cuando se intentó aplicar los cambios recientes.

También puedes usar nomos status para verificar si los recursos administrados por el Sincronizador de configuración están listos. nomos status informa el estado de cada recurso individual en la columna STATUS de la sección Managed resources del resultado.

En el siguiente ejemplo, se muestran algunas de las diferentes condiciones que podría informar el comando nomos status:

nomos status

Resultado de ejemplo:

MANAGED_CLUSTER_1
  --------------------
  <root>   [e-mail]:foo-corp/acme@main
  SYNCED   f52a11e4
  Managed resources:
   NAMESPACE   NAME                                                                   STATUS
               k8snoexternalservices.constraints.gatekeeper.sh/no-internet-services   Current
               namespace/hello                                                        Current

MANAGED_CLUSTER_2
  --------------------
  <root>   [e-mail]:foo-corp/acme@main
  PENDING  9edf8444

MANAGED_CLUSTER_3
  --------------------
  <root>   [e-mail]:foo-corp/acme@main
  ERROR    f52a11e4
  Error:   KNV1021: No CustomResourceDefinition is defined for the resource in the cluster.

MANGED_CLUSTER_4
  --------------------
  NOT INSTALLED

MANAGED_CLUSTER_5
  --------------------
  <root>   [e-mail]:foo-corp/acme/admin@main
  SYNCED   f52a11e4
  Managed resources:
   NAMESPACE   NAME                                                                   STATUS
                namespace/gamestore                                                   Current
                namespace/monitoring                                                  Current
   gamestore    reposync.configsync.gke.io/repo-sync                                  Current
   gamestore    rolebinding.rbac.authorization.k8s.io/gamestore-admin                 Current
   gamestore    rolebinding.rbac.authorization.k8s.io/gamestore-webstore-admin        Current
   monitoring   deployment.apps/prometheus-operator                                   Current
   monitoring   prometheus.monitoring.coreos.com/acm                                  Current
   monitoring   service/prometheus-acm                                                Current
   monitoring   service/prometheus-operator                                           Current
   monitoring   serviceaccount/prometheus-acm                                         Current
   monitoring   serviceaccount/prometheus-operator                                    Current
   monitoring   servicemonitor.monitoring.coreos.com/acm-service                      Current
  --------------------
  bookstore  [e-mail]:foo-corp/acme/bookstore@v1
  SYNCED     34d1a8c8
  Managed resources:
   NAMESPACE   NAME                                 STATUS
   gamestore   configmap/store-inventory            Current
   gamestore   webstore.marketplace.com/gameplace   Current

En este resultado, se ilustra lo siguiente:

• MANAGED_CLUSTER_1 sincronizó el cambio más reciente en el repositorio y todos los recursos administrados tienen el estado Current. Un estado de Current significa que el estado del recurso coincide con el estado que deseas.
• MANAGED_CLUSTER_2 todavía se está sincronizando.
• MANAGED_CLUSTER_3 tiene un error que impidió que se aplicara el cambio. En este ejemplo, MANAGED_CLUSTER_3 tiene el error KNV1021, ya que falta una CustomResourceDefinition (CRD) que los otros clústeres tienen instalada.
• MANAGED_CLUSTER_4 no tiene instalado el Sincronizador de configuración.
• MANAGED_CLUSTER_5 se sincroniza desde dos repositorios de Git. El repositorio <root> pertenece al administrador del clúster y el repositorio bookstore puede pertenecer a un equipo de desarrollo de aplicaciones.

Estados de recursos administrados

El estado de tus recursos administrados puede ser uno de los siguientes valores:

• InProgress: El estado real del recurso aún no alcanzó el estado que especificaste en el manifiesto del recurso. Esto significa que la conciliación del recurso aún no se ha completado. Los recursos recién creados suelen comenzar con este estado, aunque algunos recursos como ConfigMaps son Current de inmediato.

• Failed: El proceso de conciliar el estado real con el estado que deseas encontró un error o realizó un progreso insuficiente.

• Current: El estado real del recurso coincide con el estado que deseas. El proceso de conciliación se considera completo hasta que haya cambios en el estado deseado o el real.

• Terminating: La instancia está en proceso de eliminación.

• NotFound: El recurso no existe en el clúster.

• Unknown: El Sincronizador de configuración no puede determinar el estado del recurso.

Para desactivar la visualización del estado a nivel de recursos, agrega --resources=false al comando nomos status.

Información sobre la última confirmación sincronizada

El comando nomos status muestra el hash de confirmación de Git más reciente que se aplicó al clúster en la salida en status.sync.commit. Para obtener este valor, consulta el objeto RootSync o RepoSync y observa el campo status.sync.

Por ejemplo, para consultar un objeto RootSync, ejecuta el siguiente comando:

kubectl get rootsyncs.configsync.gke.io -n config-management-system root-sync -o yaml

Salida de ejemplo:

apiVersion: configsync.gke.io/v1beta1
kind: RootSync
status:
  sync:
    commit: f1739af550912034139aca51e382dc50c4036ae0
    lastUpdate: "2021-04-20T00:25:01Z"

Para consultar un objeto RepoSync, ejecuta el siguiente comando:

kubectl get reposync.configsync.gke.io -n NAMESPACE repo-sync -o yaml

Reemplaza NAMESPACE por el espacio de nombres en el que creaste el repositorio de espacio de nombres.

Salida de ejemplo:

apiVersion: configsync.gke.io/v1beta1
kind: RepoSync
status:
  sync:
    commit: ed95b50dd918cf65d8908f7561cb8d8d1f179c2f
    lastUpdate: "2021-04-20T00:25:20Z"

Esta confirmación representa la confirmación más reciente en el clúster. Sin embargo, no todos los recursos del clúster se ven afectados por cada confirmación. Para ver la confirmación más reciente de un recurso específico, consulta el recurso específico y observa metadata.annotations.configmanagement.gke.io/token. Por ejemplo:

kubectl get clusterroles CLUSTER_ROLE_NAME -o yaml

Reemplaza CLUSTER_ROLE_NAME por el nombre del rol del clúster que deseas consultar.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  annotations:
    configmanagement.gke.io/token: ed95b50dd918cf65d8908f7561cb8d8d1f179c2f

Marcas de estado de nomos

Para personalizar el comando nomos status, agrega las siguientes marcas:

Marca	Descripción
--contexts	Acepta una lista de contextos separados por comas para usar en comandos de varios clústeres. La configuración predeterminada es todos los contextos. Usa "" para no tener contextos.
-h o --help	Ayuda para el comando nomos status.
--namespace	Acepta una string. Usa la marca namespace para limitar el comando a un repositorio de espacio de nombres específico. Déjala sin configurar para obtener todos los repositorios. Esta marca solo está disponible si habilitaste la sincronización desde varios repositorios.
--poll	Usa la marca poll para ejecutar nomos status continuamente y hacer que vuelva a mostrar la tabla de estado a intervalos regulares. Por ejemplo 3s. Deja esta marca sin configurar para ejecutar nomos status una vez.
--resources	Se acepta true o false. Si es true, nomos status muestra el estado a nivel de recurso de tu repositorio raíz o de espacio de nombres cuando se sincroniza desde varios repositorios. El valor predeterminado es true.
--timeout	Tiempo de espera para conectarse a cada clúster. El valor predeterminado es 3s.
--name	Acepta una string. Usa esta marca para filtrar la sincronización de raíz y repositorio con el nombre proporcionado. Esta marca se puede usar junto con la marca namespace.

Permisos necesarios

Si eres propietario del proyecto, tienes el rol de RBAC cluster-admin y puedes usar el comando nomos status para cualquier clúster de tu proyecto sin agregar más permisos. Si no tienes el rol cluster-admin, puedes usar nomos status si creas el siguiente ClusterRole:

1. Crea un archivo llamado nomos-status-reader.yaml y copia el ClusterRole siguiente en él: Las reglas que necesitas difieren en función de si usas objetos RootSync y RepoSync.

   Usar objetos RootSync y RepoSync

   # nomos-status-reader.yaml
   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     name: nomos-status-reader
   rules:
   - apiGroups: ["configsync.gke.io"]
     resources: ["reposyncs", "rootsyncs"]
     verbs: ["get"]
   - nonResourceURLs: ["/"]
     verbs: ["get"]
   

   No usar objetos RootSync y RepoSync

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRole
   metadata:
     name: nomos-status-reader
   rules:
   - apiGroups: ["configmanagement.gke.io"]
     resources: ["configmanagements", "repos"]
     verbs: ["get", "list"]
   - nonResourceURLs: ["/"]
     verbs: ["get"]
   

2. Aplica el archivo nomos-status-reader.yaml:

   kubectl apply -f nomos-status-reader.yaml
   

Comprueba si hay errores en el repositorio

Antes de confirmar un archivo de configuración en el repositorio, usa el comando nomos vet para verificar la sintaxis y la validez de los archivos de configuración del repositorio:

nomos vet

Si se encuentran errores de sintaxis, el comando nomos vet se cierra con un estado distinto de cero y registra los mensajes de error en STDERR.

marcas de nomos vet

Para personalizar el comando nomos vet, agrega las siguientes marcas:

Marca	Descripción
--clusters	Acepta una lista de nombres de clúster separados por comas para usar en comandos de varios clústeres. Se aplica de forma predeterminada a todos los clústeres. Usa "" para no usar clústeres.
-h o --help	Ayuda para el comando nomos vet.
--namespace	Acepta una string. Si se configura, valida el repositorio como un repositorio de espacio de nombres con el nombre proporcionado. Establece --source-format=unstructured de forma automática.
--no-api-server-check	Acepta un valor booleano. Si es true, inhabilita la comunicación con el servidor de la API para la detección. Para obtener más información sobre esta marca, consulta la sección Validación del servidor.
--path	Acepta una string. La ruta al directorio raíz del repositorio del Sincronizador de configuración. El color predeterminado es ".".
--source-format	Se acepta hierarchy o unstructured. Si hierarchy o no se configura, valida el repositorio como un repositorio jerárquico. Si es unstructured, valida el repositorio como un repositorio no estructurado. Esta marca es obligatoria si usas un repositorio no estructurado.
--keep-output	Acepta un valor booleano. Si es true, el resultado procesado se guarda en la ubicación que puedes especificar con la marca --output.
--output	Acepta una string. La ruta de acceso al resultado procesado. La configuración predeterminada es el directorio compiled. Si --keep-output se configura como false, esta marca se ignora.
--format	Se acepta yaml o json. El formato del resultado. El valor predeterminado es yaml.

Validación del servidor

Si el comando nomos vet no puede determinar si el tipo tiene espacios de nombres, la herramienta nomos se conecta al servidor de la API. Debido a que la herramienta nomos comprende de forma predeterminada los tipos principales de Kubernetes y las CRD del Sincronizador de configuración, este solo intenta conectarse al servidor de la API si hay CR que no tengan una CRD correspondiente declarada. En este caso, si el servidor de la API no tiene una CRD aplicada, el comando nomos vet muestra el error KNV1021. Para inhabilitar esta comprobación y suprimir los errores de CRD faltantes, pasa la marca --no-api- server-check.

Almacena en caché los metadatos del servidor de la API

En lugar de suprimir las verificaciones del servidor de la API, puedes almacenar en caché los datos en el servidor de API para el comando nomos vet. Para almacenar en caché tu api-resources, completa los siguientes pasos:

1. Conéctate a un clúster que tenga todas las CRD que necesitas para tu repositorio. El clúster no necesita tener el Sincronizador de configuración habilitado.
2. Ve al policyDir de tu repositorio. Este es el mismo directorio que se especifica en tu recurso ConfigManagement o RootSync.
3. Ejecuta el siguiente comando: kubectl api-resources > api-resources.txt Este comando crea un archivo llamado api-resources.txt que contiene el resultado exacto de kubectl api-resources.

A partir de ahora, las ejecuciones de nomos vet dentro del repositorio conocen esas definiciones de tipos. Si se quita el archivo api-resources.txt o se le cambia el nombre, nomos vet no podrá encontrarlo. nomos vet seguirá intentando conectarse al clúster si encuentra manifiestos de tipos no declarados en api-resources.txt (a menos que se ingrese --no-api-server-check).

El archivo api-resources.txt solo afecta la forma en que funciona la herramienta nomos. No modifica el comportamiento del Sincronizador de configuración de ningún modo.

Es posible tener entradas adicionales en el archivo api-resources.txt, que son para tipos que no están en la validación del repositorio. nomos vet importa las definiciones, pero no realiza ninguna acción con ellas.

Precaución: Todos los tipos personalizados de un repositorio deben tener espacios de nombres o no tener ninguno. El comando nomos vet no admite tipos que tengan un alcance de espacio de nombres en algunos clústeres y un alcance de clústeres en otros.

Actualiza api-resources.txt

Después de asegurarte de que todas las CRD que deseas están en el clúster, ejecuta el siguiente comando:

kubectl api-resources > api-resources.txt

Precaución: No intentes modificar api-resources.txt de forma manual. Es fácil dejarlo con un formato incorrecto.

Comprueba de forma automática si hay errores de sintaxis durante la confirmación

Si confirmas un archivo con errores de JSON o YAML, el Sincronizador de configuración no aplica el cambio. Sin embargo, puedes evitar que estos tipos de errores ingresen al repositorio si usas hooks del cliente o del servidor.

Usa nomos vet en un hook de confirmación previa de Git

Puedes configurar un hook de confirmación previa que ejecute el comando nomos vet para verificar si hay errores de sintaxis cuando confirmas un cambio en la clonación local de Git de tu repositorio. Si un hook de confirmación previa sale con un estado distinto de cero, la operación git commit fallará.

Nota: Los hooks de confirmación previa se ejecutan en el cliente, no en el servidor. Deben agregarse de forma manual a cada cliente, y el usuario puede omitirlos o inhabilitarlos en cualquier momento.

Para ejecutar el comando nomos vet como un hook de confirmación previa, edita el archivo .git/hooks/pre-commit en tu repositorio (ten en cuenta que .git comienza con un carácter .). Es posible que debas crear el archivo de forma manual. Agrega el comando nomos vet a una línea nueva en la secuencia de comandos. El argumento --path es opcional.

nomos vet --path=/path/to/repo

Asegúrate de que el archivo pre-commit sea ejecutable:

chmod +x .git/hooks/pre-commit

Ahora, cuando ejecutes un comando git commit en la clonación de tu repositorio, nomos vet se ejecutará de manera automática.

El repositorio en sí no realiza un seguimiento del contenido del directorio .git/ del repositorio. Este contenido no puede confirmarse en el repositorio en la misma ubicación. Puedes crear un directorio en el repositorio para los hooks de Git, y las personas que usan el repositorio pueden copiar los hooks en el lugar apropiado en su clonación local.

Usa nomos vet en un hook del servidor

Git proporciona un mecanismo para ejecutar comprobaciones en el servidor, en lugar de en el cliente, durante una operación git push. Si la verificación falla, el git push también falla. El cliente no puede pasar por alto estos hooks del servidor. El método para configurar los hooks del servidor depende de cómo esté alojado tu servidor de Git. Consulta uno de los siguientes vínculos para obtener más información o consulta la documentación de tu servicio de hosting de Git.

• GitHub
• Cloud Source Repositories
• Bitbucket
• GitLab
• Servidor Git alojado por cuenta propia

Visualiza todas las configuraciones en el repositorio

Puedes usar el comando nomos hydrate para ver el contenido combinado de tu repositorio en cada clúster inscrito.

Nota: nomos hydrate reemplaza al comando nomos view, que dejó de estar disponible en el Sincronizador de configuración v1.1 y versiones posteriores. Para seguir usando nomos view, usa la v1.0 de la herramienta nomos.

Si ejecutas nomos hydrate sin opciones, se crea un directorio compiled/ en el directorio de trabajo actual. Dentro de ese directorio, se crea un subdirectorio para cada clúster inscrito, con los archivos de configuración completamente resueltos que el operador aplica al clúster.

Este comando también se puede usar para convertir un repositorio jerárquico en uno o más repositorios no estructurados mediante el contenido del directorio compiled/.

Marcas de nomos hydrate

Para personalizar el comando nomos hydrate, agrega las siguientes marcas:

Marca	Descripción
--clusters	Acepta una lista de nombres de clúster separados por comas. Usa esta marca para limitar la salida a un solo clúster o a una lista de clústeres. Se aplica de forma predeterminada a todos los clústeres. Usa "" para no usar clústeres.
--flat	Si está habilitada, imprime todos los resultados en un solo archivo. Usa esta marca si deseas emular el comportamiento de nomos view.
-h o --help	Ayuda para el comando nomos hydrate.
--format	Acepta yaml o json. El formato del resultado. El valor predeterminado es yaml.
--no-api-server-check	Acepta un valor booleano. Si es true, inhabilita la comunicación con el servidor de la API para la detección. Para obtener más información sobre esta marca, consulta la sección Validación del servidor.
--output	Acepta una string. La ubicación en la que se escribe la configuración hidratada. El valor predeterminado es el directorio compiled. Si --flat no está habilitado, se escribe cada manifiesto de recurso como un archivo independiente. Si --flat está habilitado, se escribe en un archivo único que contiene todos los manifiestos de recursos.
--path	Acepta una string. La ruta al directorio raíz del repositorio del Sincronizador de configuración. El color predeterminado es ".".
--source-format	Se acepta hierarchy o unstructured. Si hierarchy o no se configura, valida el repositorio como un repositorio jerárquico. Si es unstructured, valida el repositorio como un repositorio no estructurado. Esta marca es obligatoria si usas un repositorio no estructurado.

nomos view

Nota: Este comando está obsoleto en el Sincronizador de configuración v1.1 y versiones posteriores. Para seguir usando nomos view, usa la v1.0 de la herramienta nomos.

Cuando el Sincronizador de configuración importa archivos de configuración del repositorio, los convierte en CRD de tipo ClusterConfig o NamespaceConfig. El comando nomos view te permite ver las CRD resultantes del estado actual de tu repositorio en formato JSON. Esto puede ser útil antes de confirmar los cambios o para depurar problemas de los archivos de configuración que no son obvios mediante el comando nomos vet.

nomos view --path=PATH_TO_REPOSITORY

Nota: Para evitar que una configuración no válida se propague aún más mientras depuras un problema, puedes evitar que el operador sincronice los archivos de configuración de manera temporal.

Crea un informe de errores

Si tienes un problema con el Sincronizador de configuración que requiera la ayuda del equipo de asistencia de Google Cloud, puedes proporcionarles información de depuración valiosa mediante el comando nomos bugreport. Puedes usar este comando para un solo repositorio y varios.

nomos bugreport

Este comando genera un archivo ZIP con marca de tiempo que contiene información sobre el conjunto de clústeres de Kubernetes en tu contexto kubectl. El archivo contiene registros de los pods del Sincronizador de configuración. No contiene información sobre los recursos sincronizados con el Sincronizador de configuración. Para obtener más información sobre el contenido del archivo ZIP, consulta la referencia del informe de errores de nomos.

Migra de un objeto ConfigManagement a un objeto RootSync

Puedes ejecutar el comando nomos migrate para migrar de tu objeto ConfigManagement a un objeto RootSync a fin de habilitar las API RootSync y RepoSync. El comando está disponible en la herramienta nomos versión 1.10.0 y posteriores.

nomos migrate admite la ejecución de prueba para obtener una vista previa del proceso de migración.

nomos migrate modifica tu objeto ConfigManagement en el clúster directamente. Para evitar que se reviertan los cambios realizados a través de nomos migrate, asegúrate de que el objeto ConfigManagement no esté registrado en tu fuente de información.

Nota: Pasar la marca --contexts especifica los contextos para migrar. Esto solo es necesario si deseas migrar clústeres más allá del contexto actual.

nomos migrate --contexts=KUBECONFIG_CONTEXTS --dry-run

Si el resultado de la ejecución de prueba se ve bien, puedes migrar el objeto ConfigManagement mediante nomos migrate:

nomos migrate --contexts=KUBECONFIG_CONTEXTS

El resultado es similar a este:

--------------------
Enabling the multi-repo mode on cluster "my_managed_cluster-1" ...
- A RootSync object is generated and saved in "/tmp/nomos-migrate/my_managed_cluster-1/root-sync.yaml".
- The original ConfigManagement object is saved in "/tmp/nomos-migrate/my_managed_cluster-1/cm-original.yaml".
- The ConfigManagement object is updated and saved in "/tmp/nomos-migrate/my_managed_cluster-1/cm-multi.yaml".
- Resources for the multi-repo mode have been saved in a temp folder. If the migration process is terminated, it can be recovered manually by running the following commands:
  kubectl apply -f /tmp/nomos-migrate/my_managed_cluster-1/cm-multi.yaml && \
  kubectl wait --for condition=established crd rootsyncs.configsync.gke.io && \
  kubectl apply -f /tmp/nomos-migrate/my_managed_cluster-1/root-sync.yaml.
- Updating the ConfigManagement object ....
- Waiting for the RootSync CRD to be established ....
- The RootSync CRD has been established.
- Creating the RootSync object ....
- Waiting for the reconciler-manager Pod to be ready ....
-   Haven't detected running Pods with the label selector "app=reconciler-manager".
-   Haven't detected running Pods with the label selector "app=reconciler-manager".
-   Haven't detected running Pods with the label selector "app=reconciler-manager".
- The reconciler-manager Pod is running.
- Waiting for the root-reconciler Pod to be ready ....
-   Haven't detected running Pods with the label selector "configsync.gke.io/reconciler=root-reconciler".
-   Haven't detected running Pods with the label selector "configsync.gke.io/reconciler=root-reconciler".
-   Haven't detected running Pods with the label selector "configsync.gke.io/reconciler=root-reconciler".
- The root-reconciler Pod is running.
- The migration process is done. Please check the sync status with `nomos status`.

Finished migration on all the contexts. Please check the sync status with `nomos status`.

Nota: nomos migrate guarda el objeto ConfigManagement original, el objeto ConfigManagement actualizado y el objeto RootSync convertido en un directorio temporal. Si nomos migrate falla o finaliza de forma inesperada, puedes recuperar la migración de forma manual si ejecutas los comandos proporcionados en el resultado de nomos migrate.

Revierte a la configuración anterior

Si necesitas revertir después de realizar la migración con nomos migrate, aplica el objeto ConfigManagement original. nomos migrate guarda el objeto ConfigManagement original en un archivo y, luego, imprime el nombre en la terminal. El nombre del archivo tiene el formato /tmp/nomos-migrate/CURRENT_CONTEXT/cm-original.yaml.

Para revertir a la configuración anterior, copia la ruta de acceso del archivo cm-original.yaml y aplica el archivo a tu clúster:

kubectl apply -f CM_ORIGINAL_PATH

Marcas de migración de nomos

Para personalizar el comando nomos migrate, agrega las siguientes marcas:

Marca	Descripción
--connect-timeout	Acepta una duración. Tiempo de espera para conectarse a cada clúster. Margen aproximado predeterminado: 3s
--contexts	Acepta una lista de contextos separados por comas para usar en entornos de varios clústeres. La configuración predeterminada es el contexto actual. Usa "all" para todos los contextos.
--dry-run	Acepta un valor booleano. Si es true, solo se imprime el resultado de la migración.
-h o --help	Ayuda para el comando nomos migrate.
--wait-timeout	Acepta una duración. Tiempo de espera para esperar a que se cumplan las condiciones de los recursos de Kubernetes. La configuración predeterminada es 10m.

Inicializa un repositorio jerárquico

Puedes organizar tu repositorio de manera arbitraria si usas un repositorio no estructurado. Si usas un repositorio jerárquico, debes ejecutar el comando nomos init para inicializar un directorio jerárquico:

nomos init

Esto crea la estructura de directorios básica de un repositorio jerárquico, incluidos los directorios system/, cluster/ y namespaces/.

Marcas de nomos init

Para personalizar nomos init, agrega las siguientes marcas:

Flag	Descripción
--force	Escribe en el directorio incluso si no está vacío y reemplaza los archivos en conflicto.
-h o --help	Ayuda para el comando nomos init.
--path	Acepta una string. El directorio raíz para usar en el repositorio de Anthos Config Management. El valor predeterminado es ".".

Soluciona problemas

En Linux, es posible que veas el siguiente error cuando ejecutes un comando nomos:

failed to create client configs: while getting config path: failed to get current user: user: Current not implemented on linux/amd64

Para solucionar este problema, crea una variable de entorno USER:

export USER=$(whoami)

¿Qué sigue?

• Comienza a usar el Sincronizador de configuración