Usa el Sincronizador de configuración en varios entornos

En este instructivo, se muestra cómo configurar el Sincronizador de configuración para Google Kubernetes Engine (GKE) en dos entornos, uno para desarrollo y otro para producción, con prácticas recomendadas para Anthos Config Management.

En esta situación, eres parte del equipo de administración de una plataforma en Foo Corp. Las aplicaciones de Foo Corp se implementan en GKE con los recursos divididos en dos proyectos, dev y prod. El proyecto dev contiene un clúster de GKE de desarrollo y el proyecto prod contiene el clúster de GKE de producción. Tu objetivo como administrador de la plataforma es garantizar que ambos entornos cumplan con las políticas de Foo Corp y que los recursos de nivel base, como los espacios de nombres y las cuentas de servicio de Kubernetes, permanezcan coherentes en ambos entornos.

En el siguiente diagrama, se muestra una descripción general de los entornos que configuraste en este instructivo:

Una descripción general de los entornos que configuraste en este instructivo.

Como se muestra en el diagrama anterior, en este instructivo, crearás los siguientes recursos:

  • Dos proyectos de Google Cloud que representan los entornos de desarrollo y producción.
  • Dos clústeres de GKE, dev y prod, en los proyectos separados.
  • Tres repositorios de GitHub, foo-config-source, foo-config-dev y foo-config-prod. Estos son repositorios no estructurados del Sincronizador de configuración que contiene archivos de configuración YAML para Foo Corp.
  • El sincronizador de configuración instalado en ambos clústeres. El clúster dev se sincroniza con el repositorio foo-config-dev, el clúster prod se sincroniza con el repositorio foo-config-prod.
  • Los secretos de Secret Manager con tu nombre de usuario de Git y un token de desarrollador. Cloud Build usa estos secretos para confirmar los repositorios de GitHub.
  • Una canalización de Cloud Build, enviada al repositorio foo-config-source. Esta canalización usa kustomize build para procesar los repositorios personalizados foo-config-dev y foo-config-prod con archivos de configuración YAML, mediante las “superposiciones” y “Base” en foo-config-source. Estas superposiciones de Kustomize se te proporcionaron en la carpeta config-source/.

Objetivos

  • Prepara tu entorno mediante la ejecución de secuencias de comandos para crear y configurar los clústeres y repositorios que usarás con el Sincronizador de configuración.
  • Crear un activador de Cloud Build para procesar de forma automática la configuración de dos entornos diferentes con Kustomize.
  • Establece el Sincronizador de configuración a fin de sincronizar la configuración procesada para los dos entornos separados.

Costos

En este instructivo, se usan los siguientes componentes facturables de Google Cloud:

Para generar una estimación de costos en función del uso previsto, usa la calculadora de precios. Es posible que los usuarios nuevos de Google Cloud califiquen para obtener una prueba gratuita.

Cuando finalices este instructivo, podrás borrar los recursos creados para evitar que se te siga facturando. Para obtener más información, consulta cómo hacer una limpieza.

Es posible que los usuarios nuevos de Google Cloud califiquen para obtener una prueba gratuita.

Antes de comenzar

Antes de comenzar con este instructivo, asegúrate de haber completado los pasos que se indican a continuación:

  1. En la página del selector de proyectos de Google Cloud Console, elige o crea dos proyectos de Google Cloud.

    Ir al selector de proyectos

  2. Asegúrate de que la facturación esté habilitada para tu proyecto de Cloud. Descubre cómo confirmar que tienes habilitada la facturación en un proyecto.

  3. Crea una cuenta de GitHub o accede a ella.

  4. En GitHub, crea un token de acceso personal con los permisos repo y delete_repo. Copia el valor del token en tu portapapeles. Lo necesitarás para los próximos pasos.

Prepara tu entorno

A fin de preparar tu entorno para este instructivo, completa los siguientes pasos:

  1. Abre Cloud Shell:

    1. Ve a Google Cloud Console:

      Google Cloud Console

    2. Desde la esquina superior derecha de la consola, haz clic en el botón Activar Cloud Shell:

    Cloud Shell ya tiene preinstaladas las herramientas de nomos y kubectl que necesitas para completar este instructivo.

  2. Clona el repositorio de muestra de Anthos Config Management:

    git clone https://github.com/GoogleCloudPlatform/anthos-config-management-samples.git
    
  3. Navega a la carpeta que contiene los recursos que necesitas para este instructivo:

    cd anthos-config-management-samples/multi-environments-kustomize/
    
  4. Para ejecutar las secuencias de comandos usadas en este instructivo, configura las siguientes variables:

    export DEV_PROJECT="DEV_PROJECT_ID"
    export PROD_PROJECT="PROD_PROJECT_ID"
    export DEV_CLUSTER_ZONE="DEV_CLUSTER_ZONE"
    export PROD_CLUSTER_ZONE="PROD_CLUSTER_ZONE"
    export GITHUB_USERNAME="GITHUB_USERNAME"
    export GITHUB_TOKEN="GITHUB_TOKEN"
    export GITHUB_EMAIL="GITHUB_EMAIL"
    

    Reemplaza lo siguiente:

    • DEV_PROJECT_ID: El ID del proyecto de Google Cloud que deseas usar como proyecto de desarrollo
    • PROD_PROJECT_ID: El ID del proyecto de Google Cloud que deseas usar como proyecto de producción
    • DEV_CLUSTER_ZONE: Es la zona de Compute Engine en la que deseas crear el clúster de desarrollo. Por ejemplo, us-central1-c.
    • PROD_CLUSTER_ZONE: Es la zona de Compute Engine en la que deseas crear tu clúster de producción.
    • GITHUB_USERNAME: es tu nombre de usuario de GitHub
    • GITHUB_TOKEN: Es el token de acceso personal que creaste en la sección Antes de comenzar.
    • GITHUB_EMAIL: Tu dirección de correo electrónico de GitHub
  5. Configura tu entorno de Git local para usar tu nombre de usuario y correo electrónico de GitHub:

    git config --global user.name $GITHUB_USERNAME
    git config --global user.email $GITHUB_EMAIL
    git config --global credential.helper store
    git config --global credential.helper cache
    

Crea tus recursos

A fin de enfocarte en el flujo de trabajo que necesitas usar cuando configuras el Controlador de jerarquía para varios entornos, el directorio multi-environments-kustomize contiene secuencias de comandos que puedes usar a fin de automatizar la configuración del Sincronizador de configuración.

Crea y registra tus clústeres

  1. Para crear dos clústeres, ejecuta la secuencia de comandos ./1-create-clusters.sh:

    ./1-create-clusters.sh
    

    Esta secuencia de comandos crea un clúster de GKE llamado dev en el proyecto de desarrollo y un clúster de GKE llamado prod en el proyecto de producción. Esta secuencia de comandos también habilita las API de GKE y Anthos, y se conecta a tus clústeres dev y prod para que puedas acceder a sus API con kubectl.

    Resultado de ejemplo:

    kubeconfig entry generated for dev.
    Fetching cluster endpoint and auth data.
    kubeconfig entry generated for prod.
    ⭐️ Done creating clusters.
    
  2. Para registrar tus clústeres en dos flotas de Anthos independientes, ejecuta la secuencia de comandos register-clusters.sh:

    ./2-register-clusters.sh
    

    Esta secuencia de comandos crea una cuenta de servicio de Google Cloud y una clave para el registro del clúster de Anthos; luego, usa el comando gcloud container hub memberships register a fin de registrar los clústeres dev y prod en Anthos en su propio proyectos.

    Resultado de ejemplo:

    Waiting for Feature Config Management to be created...done.
    ⭐️ Done registering clusters.
    

Crea tus repositorios de GitHub

  1. Para crear tres repositorios de GitHub, ejecuta la secuencia de comandos create-repos.sh:

    ./3-create-repos.sh
    

    Esta secuencia de comandos crea tres repositorios de GitHub: foo-config-source, foo-config-dev y foo-config-prod. Los usuarios confirman la configuración en el repositorio de origen, y una canalización de CI (que creas en unos pocos pasos) procesa los archivos de configuración en los otros dos repositorios mediante los valores específicos dev y prod. A partir de allí, el clúster dev se sincroniza desde foo-config-dev y el clúster prod se sincroniza desde foo-config-prod.

    Resultado de ejemplo:

    # Output omitted
    😸 Creating foo-config-prod repo...
    {
      "id": 364312792,
      "node_id": "MDEwOlJlcG9zaXRvcnkzNjQzMTI3OTI=",
      "name": "foo-config-prod",
     ...
    }
    Cloning into 'foo-config-prod'...
    warning: You appear to have cloned an empty repository.
    [main (root-commit) b681a3d] Initialize
     1 file changed, 0 insertions(+), 0 deletions(-)
     create mode 100644 README.md
    Enumerating objects: 3, done.
    Counting objects: 100% (3/3), done.
    Writing objects: 100% (3/3), 211 bytes | 211.00 KiB/s, done.
    Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
    To https://github.com/askmeegs/foo-config-prod.git
    * [new branch]      main -> main
    

Crea tus secretos

  1. Para crear secretos del Secret Manager en el proyecto de producción con tus credenciales de Git, ejecuta la secuencia de comandos secret-manager-git.sh:

    ./4-secret-manager-git.sh
    

    Si creas tus secretos de esta manera, Cloud Build se envía a GitHub en tu nombre. La canalización de Cloud Build que configurarás a continuación obtiene tu información de autenticación de GitHub directamente desde Secret Manager.

    Resultado esperado:

    🔐 Creating secret manager secrets in prod project...
    Created secret [github-username].
    Created version [1] of the secret [github-username].
    Created secret [github-email].
    Created version [1] of the secret [github-email].
    Created secret [github-token].
    Created version [1] of the secret [github-token].
    ✅ Granting Cloud Build secret manager access...
    Project number is: ########
    Updated IAM policy for project [project-id].
    # Output omitted
    

Crea un activador de Cloud Build

Ahora que ya configuraste el entorno, puedes explorar la canalización de Cloud Build.

Para ver la canalización de Cloud Build, ejecuta el siguiente comando:

cat foo-config-source/cloudbuild.yaml

Esta canalización usa Kustomize a fin de renderizar manifiestos para los repositorios de desarrollo y producción mediante el uso de los manifiestos en el directorio base/.

Resultado esperado:

steps:
- name: 'gcr.io/google-samples/cloudbuild-kustomize:latest'
  id: Render foo-config-dev
  entrypoint: 'bash'
  args:
  - '-eEuo'
  - 'pipefail'
  - '-c'
  - |-
    git clone https://github.com/$$GITHUB_USERNAME/foo-config-dev && \
    cd foo-config-dev
    git config user.email $$GITHUB_EMAIL
    git config user.name $$GITHUB_USERNAME
    git remote set-url origin https://$$GITHUB_USERNAME:$$GITHUB_TOKEN@github.com/$$GITHUB_USERNAME/foo-config-dev.git
    cd ..

    kustomize build overlays/dev --output foo-config-dev/
    cd foo-config-dev

    rm README.md
    echo "Update: ${SHORT_SHA}" > README.md

    git add . && \
    git commit -m "Rendered: ${SHORT_SHA}
    Built from commit ${COMMIT_SHA} of repository foo-config-source - main branch
    Author: $(git log --format='%an <%ae>' -n 1 HEAD)" && \
    git push origin main
  secretEnv: ['GITHUB_EMAIL', 'GITHUB_USERNAME', 'GITHUB_TOKEN']
- name: 'gcr.io/google-samples/cloudbuild-kustomize:latest'
  id: Render foo-config-prod
...

Si navegas a tu repositorio foo-config-source/ en GitHub, puedes ver los manifiestos base/ y las superposiciones de Kustomize dev/ y prod/ que usa esta canalización.

Cada directorio de este repositorio contiene un archivo kustomization.yaml, que enumera los archivos que Kustomize debe administrar y aplicar al clúster. En dev/kustomization.yaml y prod/kustomization.yaml, se definen una serie de parches. Estos parches manipulan los recursos base/ para ese entorno específico.

Por ejemplo, el objeto RoleBinding del repositorio foo-config-dev permite a todos los desarrolladores de Foo Corp implementar pods en el clúster de desarrollo, mientras que RoleBinding del repositorio foo- config-prod solo permite un agente de implementación continua, deploy-bot@foo-corp.com, para implementar pods en la producción:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
bases:
- ../../base
patches:
# ServiceAccount - make name unique per environ
- target:
    kind: ServiceAccount
    name: foo-ksa
  patch: |-
    - op: replace
      path: /metadata/name
      value: foo-ksa-dev
    - op: replace
      path: /metadata/namespace
      value: foo-dev
# Pod creators - give all Foo Corp developers access
- target:
    kind: RoleBinding
    name: pod-creators
  patch: |-
    - op: replace
      path: /subjects/0/name
      value: developers-all@foo-corp.com
commonLabels:
  environment: dev

Crea un activador

En esta sección, crearás un activador de Cloud Build que iniciará una compilación de forma automática cada vez que realices algún cambio en el código fuente:

  1. Mediante el proyecto de producción, en Google Cloud Console, ve a la página Activadores de Cloud Build:

    Activadores abiertos

  2. Haz clic en Conectar repositorios.

  3. En la ventana Conectar repositorios, completa lo siguiente:

    1. En el campo Seleccionar origen deja seleccionado GitHub y haz clic enContinuar.
    2. En el campo Cuenta de GitHub, asegúrate de que el GITHUB_USERNAME que definiste antes esté seleccionado.
    3. En la lista desplegable Repositorio, selecciona el repositorio foo-config-source y haz clic en Aceptar.
    4. Selecciona la casilla de verificación para aceptar los Términos y Condiciones.
    5. Haz clic en Conectar.
  4. Una vez que tu repositorio esté conectado, haz clic en Crear un activador.

  5. En la página Crear activador que aparece, completa los siguientes campos:

    1. En el campo Nombre, agrega: Foo-Config-Render.
    2. Configura los campos Descripción y Etiquetas como desees. No son necesarios para este instructivo.
    3. En el campo Evento, deja seleccionada la opción Enviar a una rama.
    4. En la lista desplegable Repositorio, selecciona foo-config-source.
    5. Deja el campo Rama como ^main$.
    6. En el campo Tipo, deja seleccionada la opción Detección automática.
    7. En el campo Ubicación, deja Repositorio seleccionado.
    8. Haz clic en Crear para volver a la página de descripción general de Activadores.

Ejecuta el activador

Debido a que ya enviaste el repositorio foo-config-source antes de crear este activador, puedes ejecutarlo de forma manual a fin de activar el procesamiento del repositorio de producción y desarrollo:

  1. En la lista de activadores, haz clic en Ejecutar en la fila Foo-Config-Render. Aparecerá la ventana Ejecutar activador.
  2. En la ventana Ejecutar activador, asegúrate de que el campo de la rama sea main y, luego, haz clic en Ejecutar activador.
  3. Aparecerá un mensaje que dice Comenzó la compilación en la rama principal. Haz clic en Mostrar en este mensaje para ver la página Detalles de compilación.

    La compilación se debe ejecutar de forma correcta y el resultado de la compilación de Kustomize se debe escribir en los repositorios foo-config-dev y foo-config-prod, respectivamente.

  4. Una vez que se complete la compilación, abre uno de tus repositorios de desarrollo o producción en GitHub. Deberías ver archivos YAML que propagan el repositorio y una actualización README que indica el SHA de confirmación del repositorio foo-config-source desde el que se compiló este repositorio por última vez.

Configura el Sincronizador de configuración

Ahora que agregaste archivos de configuración a tus repositorios, puedes instalar el Sincronizador de configuración y verificar la instalación.

Instala Sincronizador de configuración

Para instalar el Sincronizador de configuración, en el clúster de desarrollo y producción, ejecuta la secuencia de comandos install-config-sync.sh:

./5-install-config-sync.sh

Resultado esperado:

😺 Populating configmangement.yaml with your GitHub repo info...
🔁 Installing ConfigSync on the dev cluster...
Updated property [core/project].
Switched to context "DEV_CLUSTER".
Waiting for Feature Config Management to be updated...done.
🔁 Installing ConfigSync on the prod cluster...
Updated property [core/project].
Switched to context "PROD_CLUSTER".
Waiting for Feature Config Management to be updated...done.

El Sincronizador de configuración ahora se sincroniza con los archivos de configuración de tus repositorios.

Verifica la configuración

En esta sección, debes verificar si tus clústeres se sincronizan con los archivos de configuración de tu repositorio:

  1. Para verificar el estado de la instalación del Sincronizador de configuración, ejecuta el comando nomos status:

    nomos status
    

    Deberías ver que tus clústeres de desarrollo y producción ahora están sincronizados con sus respectivos repositorios:

    gke_DEV_PROJECT_ID_us-central1-c_dev
      --------------------
      <root>   https:/github.com/GITHUB_USERNAME/foo-config-dev@main
      SYNCED   8f2e196f
      Managed resources:
         NAMESPACE   NAME                                                 STATUS
                     clusterrole.rbac.authorization.k8s.io/pod-creator    Current
                     namespace/default                                    Current
                     namespace/foo                                        Current
         default     rolebinding.rbac.authorization.k8s.io/pod-creators   Current
         foo         serviceaccount/foo-ksa-dev                           Current
    
    *gke_PROD_PROJECT_ID_us-central1-c_prod
       --------------------
       <root>   https:/github.com/GITHUB_USERNAME/foo-config-prod@main
       SYNCED   c91502ee
       Managed resources:
          NAMESPACE   NAME                                                 STATUS
                      clusterrole.rbac.authorization.k8s.io/pod-creator    Current
                      namespace/default                                    Current
                      namespace/foo                                        Current
          default     rolebinding.rbac.authorization.k8s.io/pod-creators   Current
          foo         serviceaccount/foo-ksa-prod                          Current
    
      ```
    
  2. Usa kubectl para cambiar al clúster de desarrollo:

    kubectl config use-context "gke_${DEV_PROJECT}_${DEV_CLUSTER_ZONE}_dev"
    
  3. Para verificar que los recursos estén sincronizados, obtén espacios de nombres. Deberías ver que aparece el espacio de nombres foo, sincronizado desde el repositorio foo-config-dev.

    kubectl get namespace
    

    Resultado de ejemplo:

    NAME                           STATUS   AGE
    config-management-monitoring   Active   9m38s
    config-management-system       Active   9m38s
    default                        Active   47h
    foo                            Active   9m5s
    kube-node-lease                Active   47h
    kube-public                    Active   47h
    kube-system                    Active   47h
    resource-group-system          Active   9m30s
    

    Ya configuraste el procesamiento automatizado de la configuración para un entorno de desarrollo y producción en varios entornos y proyectos de Google Cloud.

Limpia

Para evitar que se apliquen cargos a tu cuenta de Google Cloud por los recursos usados en este instructivo, borra el proyecto que contiene los recursos o conserva el proyecto y borra los recursos individuales.

Borra todos los recursos

Para borrar los recursos que creaste en este instructivo, pero mantener los proyectos de desarrollo y producción intactos, ejecuta la secuencia de comandos de limpieza:

./cleanup.sh

Borra los proyectos

  1. En Cloud Console, ve a la página Administrar recursos.

    Ir a Administrar recursos

  2. En la lista de proyectos, elige el proyecto que quieres borrar y haz clic en Borrar.
  3. En el diálogo, escribe el ID del proyecto y, luego, haz clic en Cerrar para borrar el proyecto.

¿Qué sigue?