Configurar la infraestructura como código

En esta página se presenta el segundo día de operaciones del flujo de trabajo de infraestructura como código (IaC).

Requisitos previos

Iniciar sesión en GitLab

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

    Sustituye GDC_URL por la URL base del proyecto de GDC.

  2. En la interfaz de usuario de GitLab, haz clic en el botón Inicio de sesión con SAML para que se te redirija a la página de inicio de sesión de Servicios de federación de Active Directory (ADFS) del centro de operaciones de TI (OC IT).

  3. Inicia sesión con tus credenciales de ADFS de OC IT para ver la página principal de GitLab.

  4. Para acceder a la CLI, se necesita un token de acceso personal (PAT). Crea un token de acceso personal para tu usuario con el nivel de acceso necesario siguiendo estos pasos del artículo de GitLab Crear un token de acceso personal: https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html#create-a-personal-access-token.

    Una vez que hayas creado un PAT, podrás realizar la autenticación con la herramienta de la CLI.

Flujo de trabajo de infraestructura como código

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

  1. Genera los cambios de YAML correspondientes en el repositorio iac de GitLab de la siguiente manera:

    • Si el archivo no existe, selecciona el icono Nuevo archivo en la barra lateral.

    Menú de repositorio con la opción Nuevo archivo

    • En la ventana emergente Crear archivo, introduce el nombre del nuevo archivo con la ruta completa y selecciona Crear archivo.

    Ventana emergente para crear un archivo nuevo en la que se escribe la ruta del archivo en el cuadro de texto

    • Si el archivo existe, en la barra lateral, selecciónalo para abrirlo en un panel nuevo.

    • Haz los cambios necesarios en el archivo.

  2. Sube el cambio como una confirmación de Git y envía la confirmación para que se haga una revisión de código obligatoria de la siguiente manera:

    1. Selecciona la opción Confirmar en la barra lateral para ver más opciones.

    2. Escribe un mensaje de confirmación en el área de texto. Incluye toda la información útil en el mensaje.

    3. Selecciona la opción Crear una rama.

    4. Selecciona la casilla 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 haz los cambios necesarios, como los siguientes:

      1. En el campo Título, introduce un nombre para la solicitud de combinación.
      2. En el campo Descripción, introduce una descripción.
      3. En la sección Opciones de combinación, marca la casilla Eliminar rama de origen cuando se acepte la combinación de origen.
      4. Haz clic en Crear solicitud de combinación. La solicitud de combinación se envía automáticamente al revisor.

  3. Pide al propietario correspondiente que revise y apruebe la confirmación como parte del proceso de aprobación multiparte.

  4. Inserta la confirmación.

  5. Verifica el resultado en el clúster correspondiente.

Consejos de depuración

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

Previsualizar y validar las configuraciones renderizadas

Antes de que Config Sync renderice las configuraciones y las sincronice con el clúster, asegúrate de que las configuraciones sean precisas ejecutando nomos hydrate para previsualizar la configuración renderizada y nomos vet para validar que el formato sea correcto.

  1. Cambia al directorio raíz de Git local.

  2. Ejecuta el siguiente nomos hydrate con las siguientes marcas:

    nomos hydrate \
    --source-format=unstructured \
    --output=OUTPUT_DIRECTORY

    En este comando:

    • --source-format=unstructured permite que nomos hydrate funcione en un repositorio no estructurado. Como usas configuraciones de Kustomize y charts de Helm, debes usar un repositorio no estructurado y añadir esta marca.
    • --output=OUTPUT_DIRECTORY te permite definir una ruta a las configuraciones renderizadas. Sustituye OUTPUT_DIRECTORY por la ubicación en la que quieras guardar el resultado.

  3. Comprueba la sintaxis y la validez de tus configuraciones ejecutando nomos vet con las siguientes marcas:

    nomos vet \
    --source-format=unstructured \
    --keep-output=true \
    --output=OUTPUT_DIRECTORY

    En este comando:

    • --source-format=unstructured permite que nomos vet funcione en un repositorio sin estructurar.
    • --keep-output=true guarda las configuraciones renderizadas.
    • --output=OUTPUT_DIRECTORY es la ruta a las configuraciones renderizadas.

Verificar el proceso

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

  1. Usa el alias de shell ka:

      $ alias ka='kubectl --kubeconfig $HOME/root-admin-kubeconfig'

    El alias ka configura kubectl para comunicarse con el clúster root-admin.

  2. Verifica que la sincronización funciona:

     $ ka get rootsync/root-sync -n config-management-system

    Verás la confirmación que usa Config Sync y cualquier error, si lo hay.

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

  • Comprueba si has aplicado la última confirmación en el repositorio de Git correctamente:

    1. Consulta el campo .status.sync del 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}'

      Sustituye ROOT_SYNC por el nombre del objeto RootSync que quieras buscar.

      Sustituye REPO_SYNC por el nombre del objeto RepoSync que quieras buscar.

      Sustituye REPO_SYNC_NAMESPACE por el nombre del objeto RepoSync que quieras buscar.

      • El valor del campo .status.sync.commit debe ser igual a tu confirmación más reciente.
      • El campo .status.sync no tiene ningún error.

    2. Comprueba que todos los recursos de la última confirmación se hayan conciliado. Por cada objeto RootSync o RepoSync, hay un objeto ResourceGroup único que registra el estado de conciliación de los recursos gestionados declarados en el repositorio de Git. El objeto ResourceGroup tiene el mismo espacio de nombres y nombre que el objeto RootSync o RepoSync.

      Por ejemplo, en el caso del 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 hayas aplicado la última confirmación correctamente, el objeto ResourceGroup contendrá el grupo, el tipo, el espacio de nombres y el nombre de los recursos gestionados 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

      Sustituye ROOT_SYNC por el nombre del objeto ResourceGroup que quieras buscar.

      Sustituye REPO_SYNC por el nombre del objeto ResourceGroup que quieras buscar.

      Sustituye REPO_SYNC_NAMESPACE por el nombre del objeto ResourceGroup que quieras buscar.

      • Comprueba que .status.observedGeneration sea igual al valor del campo .metadata.generation del objeto ResourceGroup.
      • Verifica que la condición Stalled y la condición Reconciling tengan status como "False".
      • Comprueba que cada elemento del campo .status.resourceStatuses tiene el estado Current.

  • Comprueba si haces una confirmación con un archivo YAML:

    1. Opcional: Usa el comando nomos si configuras tus kubectlcontextos:

      $ 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

    2. Si confirmas un archivo YAML de ejemplo, ejecuta lo siguiente:

      $ ka get svc/hello

      Verás un servicio creado a partir del archivo YAML de ejemplo.

    3. 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]

    4. Añade una nueva anotación al servicio:

      $ ka annotate --overwrite svc/hello google.com/test=aaa

      Vuelve a ejecutar describe, confirma que la anotación existe y comprueba que Config Sync no la ha sobrescrito.

    5. Anular una anotación que gestiona IaC:

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

      El cambio se deniega y aparece 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

Solucionar problemas de instalación

Si recibe errores de renderizado, como que Kustomize no renderiza las configuraciones, utilice lo siguiente:

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

Los contenedores de root-reconciler son los siguientes:

  • git-sync: clona el repositorio de Git remoto.
  • Hydration-controller:renderiza las configuraciones de Kustomize y los gráficos de Helm si el archivo de configuración de Kustomization se encuentra en el directorio raíz.
  • reconciler: Aplana la jerarquía del repositorio, la reconcilia a través del servidor de la API y comprueba si hay errores.

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

Solución de problemas

Restaurar el inicio de sesión solo con ADFS

Para depurar, puede ser útil iniciar sesión como usuario inicial ioadmin con la contraseña predeterminada. Para volver a añadir el inicio de sesión con una contraseña en 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 hayas terminado de usar el usuario local, vuelve a habilitar la autenticación solo con ADFS mediante 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)"

Incorporar un nuevo usuario desde ADFS

Un usuario inicia sesión en Distributed Cloud con ADFS. De esta forma, se crea una cuenta de usuario en GitLab con su cuenta de AD.

Como administrador, sigue estos pasos para añadir manualmente a un usuario recién creado al grupo de GitLab:

  1. Inicia sesión en GitLab como administrador de GitLab o administrador del grupo Distributed Cloud en GitLab.

  2. Ve al grupo Distributed Cloud en GitLab o https://iac.GDC_URL/gdch.

  3. En el área de administración de https://iac.GDC_URL/admin/groups/gdch, haz clic en Ver grupo.

  4. Añade la cuenta de un usuario recién creado al grupo Distributed Cloud como desarrollador.

Confirmar el estado de la conciliación

Para seguir solucionando el problema, comprueba que se haya completado la conciliación de subcomponent:

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

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 una tarea de migración parece que se ha bloqueado, comprueba el gráfico de Helm del subcomponente y asegúrate de que no falte ningún secreto.