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

Configura la infraestructura como código

En esta página, se presentan las operaciones del día 2 del flujo de trabajo de infraestructura como código (IaC).

Requisitos previos

Completa la configuración de IaC.
Opcional: Descarga e instala la herramienta de línea de comandos de nomos para la depuración:
Visita https://cloud.google.com/anthos-config-management/docs/how-to/nomos-command cuando estés fuera del entorno aislado y puedas acceder a esta URL.

Accede a GitLab

Abre la consola web de GitLab en https://iac.GDC_URL.

Reemplaza GDC_URL por la URL base del proyecto de GDC.
En la IU de GitLab, haz clic en el botón SAML Login para que se te redireccione a la página de acceso de los Servicios de federación de Active Directory (ADFS) de TI del Centro de Operaciones (OC IT).
Accede con tus credenciales de OC IT ADFS para ver la página principal de GitLab.
El acceso a la CLI requiere un token de acceso personal (PAT). Crea un PAT para tu usuario con el nivel de acceso requerido siguiendo estos pasos del artículo de GitLab, Crea un token de acceso personal: https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#create-a-personal-access-token.

Una vez que creaste un PAT, puedes realizar la autenticación con la herramienta de CLI.

Nota: Se requiere un PAT para la autenticación de la CLI en lugar de una contraseña.

Flujo de trabajo de infraestructura como código

En general, un flujo de trabajo de IaC consta de los siguientes pasos:

Genera los cambios correspondientes en el repositorio iac de GitLab de la siguiente manera:
- Si el archivo no existe, selecciona el ícono Nuevo archivo en la barra lateral.
- En la ventana emergente Crear archivo nuevo, ingresa el nombre del archivo nuevo con la ruta completa y selecciona Crear archivo.
- Si el archivo existe, en la barra lateral, selecciónalo para abrirlo en un panel nuevo.
- Realiza los cambios necesarios en el archivo.
Sube el cambio como una confirmación de Git y envía la confirmación para una revisión de código obligatoria de la siguiente manera:
1. Selecciona la opción Commit en la barra lateral para expandir más opciones.
2. Escribe un mensaje de confirmación en el área de texto. Incluye información útil en el mensaje.
3. Selecciona la opción Crear una rama nueva.
4. Selecciona la casilla de verificación Iniciar una nueva solicitud de combinación.
5. Haz clic en Confirmar para abrir la vista previa del formulario de solicitud de combinación.
6. Crea una solicitud de combinación y realiza los cambios necesarios, como los siguientes:
  1. En el campo Título, ingresa un nombre para la solicitud de combinación.
  2. En el campo Descripción, ingresa una descripción.
  3. En la sección Opciones de combinación, selecciona la casilla de verificación Borrar la rama de origen cuando se acepte la combinación.
  4. Haz clic en Crear solicitud de combinación. La solicitud de combinación se envía automáticamente al revisor.
Pídele al propietario correspondiente que revise y apruebe la confirmación como parte del proceso de aprobación de múltiples partes.
Envía la confirmación.
Verifica el resultado en el clúster correspondiente.

Sugerencias para la depuración

En esta sección, se describen sugerencias opcionales para la depuración de IaC. Para verificar que tus configuraciones sean precisas, debes tener instalada la herramienta de línea de comandos de nomos.

Obtén una vista previa y valida los archivos de configuración renderizados

Antes de que el Sincronizador de configuración renderice los archivos de configuración y los sincronice con el clúster, asegúrate de que los archivos de configuración sean precisos. Para ello, ejecuta nomos hydrate para obtener una vista previa de la configuración renderizada y ejecuta nomos vet para validar que el formato sea correcto.

Cambia al directorio raíz de Git local.
Ejecuta el siguiente nomos hydrate con los siguientes marcadores:
```
nomos hydrate \
    --source-format=unstructured \
    --output=OUTPUT_DIRECTORY
```
Este comando incluye lo siguiente:
- --source-format=unstructured permite que nomos hydrate funcione en un repositorio no estructurado. Dado que usas archivos de configuración de Kustomize y gráficos de Helm, debes usar un repositorio no estructurado y agregar esta marca.
- --output=OUTPUT_DIRECTORY te permite definir una ruta de acceso a los archivos de configuración renderizados. Reemplaza OUTPUT_DIRECTORY por la ubicación en la que deseas que se guarde el resultado.
Para verificar la sintaxis y la validez de tus archivos de configuración, ejecuta nomos vet con las siguientes marcas:
```
nomos vet \
    --source-format=unstructured \
    --keep-output=true \
    --output=OUTPUT_DIRECTORY
```
Este comando incluye lo siguiente:
- --source-format=unstructured permite que nomos vet funcione en un repositorio no estructurado.
- --keep-output=true guarda los archivos de configuración renderizados.
- --output=OUTPUT_DIRECTORY es la ruta de acceso a los archivos de configuración renderizados.

Verifica el proceso

Para verificar el estado de la sincronización, sigue estos pasos:

Usa el alias de shell ka:
```
  $ alias ka='kubectl --kubeconfig $HOME/root-admin-kubeconfig'
```
El alias ka configura kubectl para que se comunique con el clúster root-admin.
Verifica que la sincronización funcione:
```
 $ ka get rootsync/root-sync -n config-management-system
```
Verás la confirmación que usa Sincronizador de configuración y cualquier error, si lo hay.

Una vez que hayas verificado el estado de sincronización, usa una de las siguientes opciones:

Comprueba si aplicaste correctamente la última confirmación en el repositorio de Git:
1. Verifica el campo .status.sync en el objeto RootSync o RepoSync. Puedes acceder al campo .status.sync con el siguiente comando:
```
# get .status.sync of a RootSync object
ka get rootsync ROOT_SYNC -n config-management-system -o jsonpath='{.status.sync}'

# get .status.sync of a RepoSync object
ka get reposync REPO_SYNC -n REPO_SYNC_NAMESPACE -o jsonpath='{.status.sync}'
```
  Reemplaza ROOT_SYNC por el nombre del objeto RootSync que deseas buscar.
  
  Reemplaza REPO_SYNC por el nombre del objeto RepoSync que deseas buscar.
  
  Reemplaza REPO_SYNC_NAMESPACE por el nombre del objeto RepoSync que deseas buscar.
  - El valor del campo .status.sync.commit debe ser igual a tu última confirmación.
  - El campo .status.sync no tiene ningún "error".
2. Verifica que todos los recursos de la confirmación más reciente estén conciliados. Para cada objeto RootSync o RepoSync, hay un objeto ResourceGroup único que captura el estado de conciliación de los recursos administrados declarados en el repositorio de Git. El objeto ResourceGroup tiene el mismo espacio de nombres y el mismo nombre que el objeto RootSync o RepoSync.
  
  Por ejemplo, para el objeto RootSync con el nombre root-sync en el espacio de nombres config-management- system, el objeto ResourceGroup correspondiente también es root-sync en el espacio de nombres config-management-system. Cuando aplicaste la última confirmación correctamente, el objeto ResourceGroup contiene el grupo, el tipo, el espacio de nombres y el nombre de los recursos administrados de la última confirmación.
  
  Ejecuta el siguiente comando para obtener un objeto ResourceGroup:
```
# get the ResourceGroup object for a RootSync object
ka get resourcegroup ROOT_SYNC -n config-management-system -o yaml

# get the ResourceGroup object for a RepoSync object
ka get resourcegroup REPO_SYNC -n REPO_SYNC_NAMESPACE -o yaml
```
  Reemplaza ROOT_SYNC por el nombre del objeto ResourceGroup que deseas buscar.
  
  Reemplaza REPO_SYNC por el nombre del objeto ResourceGroup que deseas buscar.
  
  Reemplaza REPO_SYNC_NAMESPACE por el nombre del objeto ResourceGroup que deseas buscar.
  - Comprueba que .status.observedGeneration sea igual al valor del campo .metadata.generation en el objeto ResourceGroup.
  - Verifica que la condición Stalled y la condición Reconciling tengan status como "False".
  - Verifica que cada elemento del campo .status.resourceStatuses tenga el estado Current.

Verifica si realizas una confirmación con un archivo YAML:

Opcional: Usa el comando nomos si configuras tus contextos de kubectl:

$ nomos status
Connecting to clusters...

*root-admin-admin@root-admin
  --------------------
  <root>:root-sync   https://iac.zone1.google.gdch.test/gdch/iac.git/infrastructure/zonal/zones/ZONE_NAME/root-admin@main
  SYNCED             4a276fb67d17471f1ba812c725b75a76a1715009
  Managed resources:
     NAMESPACE   NAME             STATUS
     default     service/hello    Unknown

Si confirmas un archivo YAML de ejemplo, ejecuta el siguiente comando:
```
$ ka get svc/hello
```
Verás un servicio creado a partir del ejemplo de YAML.

Ejecuta el siguiente comando:

ka describe svc/hello

Verás el siguiente objeto:

Name:         myrole
Labels:       app.kubernetes.io/managed-by=configmanagement.gke.io
              configsync.gke.io/declared-version=v1
Annotations:  config.k8s.io/owning-inventory: config-management-system_root-sync
              configmanagement.gke.io/cluster-name: my-cluster
              configmanagement.gke.io/managed: enabled
              configmanagement.gke.io/source-path: config-sync-quickstart/multirepo/root/gamestore-myrole.yaml
              configmanagement.gke.io/token: 747b843a7ddbd945c0616034a935cf648b58e7b5
              configsync.gke.io/declared-fields: {"f:rules":{}}
              configsync.gke.io/git-context: {"repo":"https://github.com/GoogleCloudPlatform/anthos-config-management-samples","branch":"main","rev":"HEAD"}
              configsync.gke.io/manager: :root
              configsync.gke.io/resource-id: rbac.authorization.k8s.io_role_gamestore_myrole
PolicyRule:
  Resources  Non-Resource URLs  Resource Names  Verbs
  ---------  -----------------  --------------  -----
  pods       []                 []              [get list]

Agrega una anotación nueva al servicio:
```
$ ka annotate --overwrite svc/hello google.com/test=aaa
```
Vuelve a ejecutar describe, confirma que existe la anotación y verifica que el Sincronizador de configuración no la haya reemplazado.

Anula una anotación que administra la IaC:

$ ka annotate --overwrite svc/hello google.com/annotation-in-iac=value-from-kubectl

Verás que se rechazó el cambio en el siguiente mensaje de error:

$ ka annotate --overwrite svc/hello google.com/annotation-in-iac=asfas
Error from server (Forbidden): admission webhook "v1.admission-webhook.configsync.gke.io" denied the request: kubernetes-admin cannot modify fields of object "_service_default_hello" managed by Config Sync: .metadata.annotations.google.com/annotation-in-iac

Soluciona problemas de instalación

Si recibes errores de renderización, como que Kustomize no renderiza las configuraciones, usa lo siguiente:

$ ka logs -n config-management-system deployment/root-reconciler -c hydration-controller -f

Los contenedores en root-reconciler son los siguientes:

git-sync: Clona el repositorio remoto de Git.
Hydration-controller:Renderiza las configuraciones de Kustomize y los gráficos de Helm si el archivo de configuración de Kustomization existe en el directorio raíz.
reconciler: Compacta la jerarquía del repositorio, la concilia a través del servidor de la API y verifica si hay errores.

Para obtener más información, sigue la guía oficial Soluciona problemas del Sincronizador de configuración de Config Management Google Cloud: https://cloud.google.com/anthos-config-management/docs/how-to/troubleshooting-config-sync.

Soluciona problemas

Para los fines de depuración, puede ser útil acceder como el usuario ioadmin inicial con el acceso con contraseña predeterminado. Para volver a agregar el acceso con contraseña a través de GitLab, ejecuta los siguientes comandos de kubectl.

  export TOOLBOX=$(kubectl get pods --no-headers=true -n gitlab-system -lapp=toolbox,release=gitlab -o name | cut -c 5-)
  # Wait for pod to be ready.
  kubectl wait pods -n gitlab-system -lapp=toolbox,release=gitlab --for condition=Ready
  kubectl exec $TOOLBOX -n gitlab-system -- /srv/gitlab/bin/rails runner "Gitlab::CurrentSettings.update!(password_authentication_enabled_for_web: true)"

Cuando termines de usar el usuario local, vuelve a habilitar la autenticación solo con ADFS con el siguiente comando:

export TOOLBOX=$(kubectl get pods --no-headers=true -n gitlab-system -lapp=toolbox,release=gitlab -o name | cut -c 5-)
# Wait for pod to be ready.
kubectl wait pods -n gitlab-system -lapp=toolbox,release=gitlab --for condition=Ready
kubectl exec $TOOLBOX -n gitlab-system -- /srv/gitlab/bin/rails runner "Gitlab::CurrentSettings.update!(password_authentication_enabled_for_web: false)"

Incorpora un usuario nuevo desde ADFS

Un usuario accede a Distributed Cloud con ADFS. Esto crea una cuenta de usuario dentro de GitLab con su cuenta de AD.

Como administrador, completa los siguientes pasos para agregar manualmente un usuario recién creado al grupo de GitLab:

Accede a GitLab como administrador de GitLab o administrador del grupo de Distributed Cloud en GitLab.
Navega al grupo de Distributed Cloud en GitLab o https://iac.GDC_URL/gdch.
Haz clic en Ver grupo en el Área de administración en https://iac.GDC_URL/admin/groups/gdch.
Agrega una cuenta de un usuario recién creado al grupo de Distributed Cloud como desarrollador.

Confirma el estado de conciliación

Para obtener pasos adicionales para solucionar problemas, verifica que el subcomponent haya terminado de conciliarse:

root@count-bootstrapper:~/adfs# kr get subcomponent -n root iac-gitlab
NAME         AGE   STATUS
iac-gitlab   10d   ReconciliationCompleted

Además, asegúrate de que el CR gitlab esté en el estado Running:

root@count-bootstrapper:~/adfs# kr get gitlab -n gitlab-system gitlab
NAME     STATUS    VERSION
gitlab   Running   7.11.10

Por último, si un trabajo de migración parece estar atascado, verifica el gráfico de Helm del subcomponente y asegúrate de que no falten secretos.