Implementa un plano de zona de destino

Puedes usar el controlador de configuración para implementar y administrar de forma declarativa una zona de destino en Google Cloud.

En este instructivo, se ayuda a los administradores de la organización a configurar Google Cloud para cargas de trabajo empresariales escalables y listas para la producción mediante la implementación de un plano de zona de destino que incluye prácticas recomendadas para la administración de redes, seguridad y recursos.

Objetivos

En el proceso de implementación de la zona de destino, harás lo siguiente:

  1. Configurarás el controlador de configuración para sincronizar recursos de un repositorio de Git con tu entorno de Google Cloud.
  2. Descubrirás planos que capturan patrones de diseño comunes para Google Cloud, como la implementación de una VPC compartida.
  3. Crearás una canalización de implementación revisada (basada en Cloud Build) que te permita personalizar planos, transformarlos con funciones de kpt y, además, implementar recursos mediante Config Connector.

Estos componentes se combinan en el flujo de trabajo que se muestra en el siguiente diagrama:

Un administrador de plataforma que implementa planos a través del controlador de configuración

Costos

Antes de comenzar

Antes de configurar tu zona de destino, debes preparar algunos detalles.

  1. Accede a tu cuenta de Google.

    Si todavía no tienes una cuenta, regístrate para obtener una nueva.

  2. En la página del selector de proyectos de Google Cloud Console, selecciona o crea un proyecto de Google Cloud.

    Ir al selector de proyectos

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

  4. Instala e inicializa el SDK de Cloud.
  5. Crea Grupos de Google, que se usarán para otorgar acceso a tu organización. En particular, debes tener un grupo para los administradores de la organización y un grupo para los administradores de facturación.
  6. Instala las herramientas de Kubernetes (nomos, kubectl y kpt){:.external} que se usan en este instructivo. (Si realizas la ejecución en Cloud Shell, estas herramientas ya están instaladas y puedes omitir este paso). También puedes instalar los componentes directamente desde sus páginas respectivas.
    gcloud components install pkg

Prepara el entorno

Antes de implementar el plano de la zona de destino, debes establecer algunas variables de entorno:

export PROJECT_ID=PROJECT_ID
export CONFIG_CONTROLLER_NAME=config-controller-1
export BILLING_ACCOUNT=$(gcloud alpha billing projects describe $PROJECT_ID \
  '--format=value(billingAccountName)' | sed 's/.*\///')
export ORG_ID=$(gcloud projects get-ancestors ${PROJECT_ID} --format='get(id)' | tail -1)
gcloud config set project ${PROJECT_ID}

Reemplaza lo siguiente:

  • PROJECT_ID: El ID del proyecto en el que se alojará el controlador de configuración

Configura el controlador de configuración

El controlador de configuración proporciona un plano de control administrado, basado en Kubernetes, para configurar los recursos en la nube. Viene preinstalado con el Controlador de políticas, el Sincronizador de configuración y Config Connector.

  1. En tu proyecto, habilita la API de Config Controller y la API de GKE de la que depende Config Controller:
     gcloud services enable krmapihosting.googleapis.com container.googleapis.com
    
  2. Crea el controlador de configuración. Esta operación puede demorar más de 15 minutos.
    gcloud alpha anthos config controller create ${CONFIG_CONTROLLER_NAME} \
      --location=us-central1
  3. Verifica que el controlador de configuración se haya creado correctamente:
    gcloud alpha anthos config controller list --location=us-central1
  4. Autentícate en el controlador de configuración para poder comenzar a aplicar la configuración:
    gcloud alpha anthos config controller get-credentials ${CONFIG_CONTROLLER_NAME} \
      --location us-central1
  5. Otorga permiso al controlador de configuración para administrar el recurso de Google Cloud en el proyecto de administración:
    export SA_EMAIL="$(kubectl get ConfigConnectorContext -n config-control \
      -o jsonpath='{.items[0].spec.googleServiceAccount}' 2> /dev/null)"
    gcloud projects add-iam-policy-binding "${PROJECT_ID}" \
      --member "serviceAccount:${SA_EMAIL}" \
      --role "roles/owner" \
      --project "${PROJECT_ID}"
  6. Otorga permisos al controlador de configuración para que administre recursos a nivel de la organización a fin de implementar el plano de tu zona de destino:
    gcloud organizations add-iam-policy-binding $ORG_ID \
      --role=roles/resourcemanager.organizationAdmin \
      --condition=None \
      --member="serviceAccount:${SA_EMAIL}"

Crea una canalización de GitOps

Si configuras el controlador de configuración para sincronizarlo con un repositorio de Git, puedes colaborar en los cambios en tu zona de destino y mantener un registro de auditoría sólido.

En este paso, implementarás tu primer plano. Este plano incluye lo siguiente:

  • Dos Cloud Source Repositories: uno de “origen”, en el que confirmarás los cambios, y otro de “implementación”, que contiene una copia de la configuración final aplicada al controlador de configuración.
  • Un activador de Cloud Build, que detecta cambios en tu repositorio de código fuente, ejecuta las funciones kpt incluidas y confirma el resultado final en tu repositorio de implementación.
  • Una configuración del Sincronizador de configuración, que conecta el controlador de configuración con tu repositorio de implementación.

Implementa el plano

  1. Habilita el servicio de Resource Manager en tu proyecto:
    gcloud services enable cloudresourcemanager.googleapis.com
  2. Descarga el plano de GitOps desde GitHub en tu máquina local mediante kpt:
    kpt pkg get https://github.com/GoogleCloudPlatform/blueprints.git/catalog/gitops@kpt-v1 gitops
  3. Este plano se puede personalizar con una cantidad de setters. Abre el archivo gitops/setters.yaml para modificarlos:
    # Copyright 2021 Google LLC
    #
    # Licensed under the Apache License, Version 2.0 (the "License");
    # you may not use this file except in compliance with the License.
    # You may obtain a copy of the License at
    #
    #      http://www.apache.org/licenses/LICENSE-2.0
    #
    # Unless required by applicable law or agreed to in writing, software
    # distributed under the License is distributed on an "AS IS" BASIS,
    # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    # See the License for the specific language governing permissions and
    # limitations under the License.
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: setters
      annotations:
        config.kubernetes.io/local-config: "true"
    data:
      # You can leave these defaults
      namespace: config-control
      # This should be the name of your Config Controller instance
      cluster-name: cluster-name
      deployment-repo: deployment-repo
      # This should be the project where you deployed Config Controller
      project-id: project-id
      project-number: "1234567890123"
      source-repo: source-repo
    
  4. Para personalizar este plano, reemplaza los siguientes métodos set en el archivo anterior:
    • cluster-name: es el nombre que elegiste para tu controlador de configuración
    • project-id: es el ID del proyecto en el que se implementa el controlador de configuración
    • project-number: es el número en el proyecto en el que se implementa el controlador de configuración Esto se puede recuperar con el siguiente comando:
      gcloud projects describe ${PROJECT_ID} --format='get(projectNumber)'
  5. Renderiza el plano para propagar tus personalizaciones en todos los recursos:
    kpt fn render gitops/
  6. Inicializa el plano a fin de prepararlo para el clúster del controlador de configuración:
    kubectl apply --wait -f gitops/ --recursive
  7. Espera a que el plano cree los repositorios:
    kubectl wait --for=condition=READY -f gitops/source-repositories.yaml

Guarda el plano en Git

Ahora, vuelve a guardar el plano en el repositorio de Git que se creó. Esto te permitirá guardar las personalizaciones y hacer un seguimiento de los cambios futuros.

  1. Consulta el repositorio de Git que creó el plano:
    gcloud source repos clone source-repo
  2. Mueve el plano de GitOps a tu repositorio de Git:
    mv gitops source-repo/
  3. Abre el repositorio de Git:
    cd source-repo/
  4. Confirma el plano en Git y envía tus cambios:
    git add gitops/
    git commit -m "Add GitOps blueprint"
    git push

Verifica el éxito

Puedes verificar que el proceso de inicialización se haya completado correctamente mediante las siguientes opciones:

  • Comprueba que Config Connector se instaló correctamente:
    kubectl wait -n cnrm-system --for=condition=Ready pod --all
  • Confirma que Cloud Source Repositories se creó correctamente:
    gcloud source repos list
  • Verifica que se hayan creado los recursos necesarios en el controlador de configuración:
    kubectl get gcp -n config-control -o yaml \
      | grep "^    name: \|message"
    El resultado debería ser similar al siguiente:
        name: source-repo-cicd-trigger
          message: The resource is up to date
        name: allow-configsync-sa-read-csr
          message: The resource is up to date
        name: configsync-sa-workload-identity-binding
          message: The resource is up to date
        name: deployment-repo-cloudbuild-write
          message: The resource is up to date
        name: source-repo-cloudbuild-read
          message: The resource is up to date
        name: config-sync-sa
          message: The resource is up to date
        name: cloudbuild.googleapis.com
          message: The resource is up to date
        name: sourcerepo.googleapis.com
          message: The resource is up to date
        name: deployment-repo
          message: The resource is up to date
        name: source-repo
          message: The resource is up to date
    

Inicializa tu zona de destino

Ahora que el controlador de configuración está conectado a Git, es el momento de inicializar el plano de tu zona de destino.

Este plano preparará la zona de destino mediante la configuración de la estructura general de tu organización, lo que incluye lo siguiente:

  • Crear espacios de nombres separados dentro del controlador de configuración para administrar hierarchy, logging, networking, projects y policies. A cada espacio de nombres se le asigna una cuenta de servicio de Google Cloud diferente con privilegios mínimos
  • Asignar la función de administrador de facturación a tu grupo de administradores de facturación y la función de administrador de la organización a ese grupo
  • Activar las políticas de la organización de prácticas recomendadas en tu organización

Implementa el plano

Implementa la zona de destino a partir del repositorio de código fuente que clonaste antes:

  1. Descarga el plano de la zona de destino base y agrégalo a tu repositorio.
    kpt pkg get https://github.com/GoogleCloudPlatform/blueprints.git/catalog/landing-zone@kpt-v1 ./landing-zone
    git add landing-zone/
    git commit -m "Add landing zone"
  2. En este plano, se incluye una serie de métodos set para configurar tu zona de destino. Abre el archivo landing-zone/setters.yaml para modificarlos:
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: setters
    data:
      # Organization ID and billing account
      org-id: "123456789012"
      billing-account-id: AAAAAA-BBBBBB-CCCCCC
      # Groups to use for org-level roles
      group-org-admins: gcp-organization-admins@example.com
      group-billing-admins: gcp-billing-admins@example.com
      # The project where Config Controller is deployed
      management-project-id: management-project-id
      # This default is safe to keep
      management-namespace: config-control
    
  3. Para personalizar este plano, reemplaza los siguientes métodos set en el archivo anterior:
    • org-id: es el ID de la organización de la zona de destino
    • billing-account-id: es la cuenta de facturación predeterminada que deseas usar para proyectos nuevos
    • management-project-id: es el ID del proyecto en el que se implementa el controlador de configuración
    • group-org-admins: es el correo electrónico del Grupo de Google del administrador de la organización, por ejemplo, gcp-organization-admins@example.com
    • group-billing-admins: es el correo electrónico del Grupo de Google de los administradores de facturación, por ejemplo, gcp-billing-admins@example.com
  4. Revisa las personalizaciones que realizaste al plano:
    git diff
  5. Envía tus cambios al repositorio, donde se sincronizarán automáticamente con el controlador de configuración y se aplicarán:
    git commit -a -m "Customize landing zone blueprint"
    git push
    

Administra las políticas de la organización

El plano de la zona de destino incluye una serie de restricciones de políticas de la organización que representan las prácticas recomendadas para mejorar la seguridad de tus entornos.

Restricción Descripción
compute.disableNestedVirtualization Inhabilita la virtualización anidada por aceleración de hardware para todas las VM de Compute Engine.
compute.disableSerialPortAccess Inhabilita el acceso del puerto en serie a las VM de Compute Engine.
compute.disableGuestAttributesAccess Inhabilita el acceso de la API de Compute Engine a los atributos de invitado de las VM.
compute.vmExternalIpAccess Limita el conjunto de instancias de VM de Compute Engine que pueden usar direcciones IP externas.
compute.skipDefaultNetworkCreation Hace que Google Cloud omita la creación de la red predeterminada y los recursos relacionados durante la creación del proyecto.
compute.restrictXpnProjectLienRemoval Restringe el conjunto de usuarios que pueden quitar una retención de proyecto de VPC compartida.
sql.restrictPublicIp Restringe las direcciones IP públicas en las instancias de Cloud SQL.
iam.disableServiceAccountKeyCreation Inhabilita la creación de claves de cuenta de servicio que se pueden descargar.
storage.uniformBucketLevelAccess Requiere que los buckets usen el acceso uniforme a nivel de bucket basado en IAM.

Quita restricciones

Si alguna de las restricciones predeterminadas genera problemas para tu organización, simplemente borra el archivo YAML asociado desde tu repositorio de código fuente para restablecer el comportamiento predeterminado.

Por ejemplo, para quitar la restricción que impide el acceso al puerto en serie, sigue estos pasos:

  1. Quita el archivo:
    git rm ./landing-zone/policies/disable-serial-port.yaml
  2. Confirma y envía el cambio:
    git commit -m "Remove serial port org policy"
    git push
    

Verifica el éxito

Para verificar que tu zona de destino se haya inicializado, haz lo siguiente:

  • Verifica el estado de la canalización de ejecución de Cloud Build.
  • Verifica que el repositorio de Git esté sincronizado con el controlador de configuración:
    nomos status
  • Confirma que existen los espacios de nombres hierarchy, projects, policies, logging y networking:
    kubectl get ns
  • Verifica que se hayan creado los recursos necesarios en el controlador de configuración:
    kubectl get gcp --all-namespaces -o yaml \
      | grep "^    name: |message"
  • Enumera las políticas de la organización a través de la CLI:
    gcloud resource-manager org-policies list --organization=$ORG_ID

Configura tu jerarquía de recursos

En Google Cloud, los recursos se organizan en carpetas y proyectos:

  • Los proyectos contienen los recursos de la nube, por ejemplo, máquinas virtuales, bases de datos y buckets de almacenamiento.
  • Las carpetas se usan para agrupar proyectos a fin de facilitar la administración de políticas, incluidas de IAM. Por ejemplo, pueden representar los departamentos principales en tu organización, como finanzas o venta minorista, o entornos, como producción frente a no producción. Las carpetas pueden anidarse entre sí para formar una jerarquía de recursos.

Proporcionamos cuatro planos distintos de la jerarquía de recursos, que se adaptan a las distintas estructuras organizativas:

  • Simple: Este es un plano sencillo con una sola capa de carpetas que representan environments.
  • Equipo: Este plano tiene dos capas de carpetas: teams -> environments.
  • Unidades de negocios: Este plano divide tu organización en tres niveles de carpetas, con un enfoque en unidades de negocios autónomas: divisions -> teams -> environments
  • Entornos: Este plano tiene tres niveles de carpetas, con un enfoque en las políticas centradas en el entorno: environments -> divisions -> teams

Implementa el plano

Una vez que hayas elegido la jerarquía de recursos preferida, sigue las instrucciones correspondientes para implementarla.

Simple

Este plano es adecuado para organizaciones planas en las que se requiere un conjunto de políticas sencillo para cada entorno a fin de administrar la nube, pero todos los equipos se tratan de manera uniforme.

  1. Descarga el plano:
    kpt pkg get https://github.com/GoogleCloudPlatform/blueprints.git/catalog/hierarchy/simple@kpt-v1 ./landing-zone/hierarchy/
  2. Edita el archivo landing-zone/hierarchy/hierarchy.yaml para que refleje la estructura de la organización deseada.
    spec:
      config:
        - shared
        - dev
        - prod
        - qa
      parentRef:
        # This should match your organization ID
        external: "123456789012"

    Estos valores deben actualizarse en hierarchy.yaml:

    • spec.config: los entornos deseados que se convertirán en carpetas de nivel superior
    • spec.parentRef.external: actualiza este valor para que coincida con el ID de tu organización
  3. Edita la restricción de la política de nombres que se incluye en landing-zone/hierarchy/policies/naming-constraint.yaml para reflejar tu esquema de nombres preferido para las carpetas. El esquema de nombres se define como una expresión regular. En particular, debes ajustar esta expresión para incluir cualquier entorno adicional que hayas definido.
    spec:
      parameters:
        naming_rules:
          - kind: Folder
            patterns:
              # Matches words like "dev", "prod" or "staging"
              - ^(dev|prod|staging|qa|shared)$
  4. Agrega tu jerarquía y envíala al repositorio de Git:
    git add ./landing-zone/hierarchy/
    git commit -m "Add resource hierarchy and update folder naming convention."
    git push

Equipo

Este plano es adecuado para organizaciones más sencillas en las que cada equipo es responsable de sus propias operaciones en la nube y está capacitado para establecer políticas personalizadas sobre la forma en la que usan la nube.

  1. Descarga el plano:
    kpt pkg get https://github.com/GoogleCloudPlatform/blueprints.git/catalog/hierarchy/team@kpt-v1 ./landing-zone/hierarchy/
  2. Edita el archivo landing-zone/hierarchy/hierarchy.yaml para que refleje la estructura de la organización deseada.
    spec:
      config:
        - retail:
            $subtree: environments
        - finance:
            $subtree: environments
      parentRef:
        # This should match your organization ID
        external: "123456789012"
      subtrees:
        environments:
          - dev
          - prod
          - qa

    Estos valores deben actualizarse en hierarchy.yaml:

    • spec.config: los equipos deseados que se convertirán en carpetas de nivel superior.
    • spec.subtrees.environments: los entornos deseados que se convertirán en subcarpetas en cada equipo
    • spec.parentRef.external: actualiza este valor para que coincida con el ID de tu organización
  3. Edita la restricción de la política de nombres que se incluye en landing-zone/hierarchy/policies/naming-constraint.yaml para reflejar tu esquema de nombres preferido para las carpetas. El esquema de nombres se define como una expresión regular. En particular, debes ajustar esta expresión para incluir cualquier entorno adicional que hayas definido.
    spec:
      parameters:
        naming_rules:
          - kind: Folder
            patterns:
              # Matches words like "dev", "prod" or "staging"
              - ^(dev|prod|staging|qa|shared)$
  4. Agrega tu jerarquía y envíala al repositorio de Git:
    git add ./landing-zone/hierarchy/
    git commit -m "Add resource hierarchy and update folder naming convention."
    git push

Unidades de negocios

Este plano es adecuado para organizaciones grandes y complejas en las que cada unidad de negocios o división es altamente responsable de sus propias operaciones en la nube. Permite que cada unidad de negocios establezca fácilmente políticas que se aplican a todos sus equipos, mientras que los equipos individuales son responsables de sus propios entornos (dentro de esas restricciones de nivel superior).

  1. Descarga el plano:
    kpt pkg get https://github.com/GoogleCloudPlatform/blueprints.git/catalog/hierarchy/bu@kpt-v1 ./landing-zone/hierarchy/
  2. Edita el archivo landing-zone/hierarchy/hierarchy.yaml para que refleje la estructura de la organización deseada.
    spec:
      config:
        - retail:
            - apps:
                $subtree: environments
            - data:
                $subtree: environments
        - finance:
            - commercial:
                $subtree: environments
      parentRef:
        # This should match your organization ID
        external: "123456789012"
      subtrees:
        environments:
          - dev
          - prod

    Estos valores deben actualizarse en hierarchy.yaml:

    • spec.config: la estructura de la organización deseada, que puede incluir equipos anidados en la división; por ejemplo, el plano comienza con una división de venta minorista que tiene apps y subcarpetas de datos
    • spec.subtrees.environments: los entornos deseados que se convertirán en subcarpetas en cada equipo
    • spec.parentRef.external: actualiza este valor para que coincida con el ID de tu organización
  3. Edita la restricción de la política de nombres que se incluye en landing-zone/hierarchy/policies/naming-constraint.yaml para reflejar tu esquema de nombres preferido para las carpetas. El esquema de nombres se define como una expresión regular. En particular, debes ajustar esta expresión para incluir cualquier entorno adicional que hayas definido.
    spec:
      parameters:
        naming_rules:
          - kind: Folder
            patterns:
              # Matches words like "dev", "prod" or "staging"
              - ^(dev|prod|staging|qa|shared)$
  4. Agrega tu jerarquía y envíala al repositorio de Git:
    git add ./landing-zone/hierarchy/
    git commit -m "Add resource hierarchy and update folder naming convention."
    git push

Entornos

Este plano es ideal para organizaciones más grandes que necesitan afirmar un control coherente y sólido sobre las políticas de entorno (por ejemplo, restringir el acceso a los recursos de producción) y, a la vez, proporcionar flexibilidad para la división detallada y las políticas específicas del equipo.

  1. Descarga el plano:
    kpt pkg get https://github.com/GoogleCloudPlatform/blueprints.git/catalog/hierarchy/env-bu@kpt-v1 ./landing-zone/hierarchy/
  2. Edita el archivo landing-zone/hierarchy/hierarchy.yaml para que refleje la estructura de la organización deseada.
    spec:
      config:
        - dev:
            $subtree: environment
        - prod:
            $subtree: environment
      parentRef:
        # This should match your organization ID
        external: "123456789012"
      subtrees:
        environment:
          - retail:
              - apps
              - data
          - finance:
              - commercial

    Estos valores deben actualizarse en hierarchy.yaml:

    • spec.config: las carpetas del entorno de nivel superior que desees, que incluirán una copia completa del subárbol del entorno
    • spec.subtrees.environment: la jerarquía de divisiones y equipos que deseas que se refleje en cada entorno, por ejemplo, el plano comienza con una división de venta minorista que tiene apps y subcarpetas de datos
    • spec.parentRef.external: actualiza este valor para que coincida con el ID de tu organización
  3. Agrega tu jerarquía y envíala al repositorio de Git:
    git add ./landing-zone/hierarchy/
    git commit -m "Add resource hierarchy and update folder naming convention."
    git push

Verifica el éxito

Puedes verificar que se haya creado correctamente tu jerarquía de recursos mediante las siguientes opciones:

  • Haz una lista de las carpetas dentro de tu organización:
    gcloud resource-manager folders list --organization=$ORG_ID
  • Recupera el estado de las carpetas directamente desde el espacio de nombres de la jerarquía en tu clúster:
    kubectl get folders -n hierarchy -o yaml \
      | grep "^    name: |message"

Establece una conectividad de red

Como parte de tu zona de destino, te recomendamos implementar una arquitectura de red de VPC compartida. El plano de red proporcionado configura una red y establece una VPN de Cloud para conectividad híbrida.

Crea un proyecto host

Antes de implementar una red, debes crear un proyecto para alojarla. Esto debe hacerse una vez para cada entorno, con el plano de fábrica del proyecto incluido.

  1. Descarga el plano del proyecto en tu zona de destino para crear un proyecto host.
    export NET_PROJECT_ID="NETWORK_PROJECT_ID"
    export ENVIRONMENT="ENVIRONMENT"
    
    kpt pkg get \
      https://github.com/GoogleCloudPlatform/blueprints.git/catalog/project@kpt-v1 \
      ./landing-zone/projects/${NET_PROJECT_ID}
    

    Reemplaza lo siguiente:

    • ENVIRONMENT: El entorno que configuras para una VPC compartida, por ejemplo, dev
    • NETWORK_PROJECT_ID: El ID que deseas asignar a tu proyecto de red
  2. Abre el archivo landing-zone/projects/NETWORK_PROJECT_ID/setters.yaml. Para personalizar este plano, reemplaza los siguientes métodos set en:
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: setters
    data:
      folder-name: name.of.folder
      project-id: project-id
      # These defaults can be kept
      folder-namespace: hierarchy
      networking-namespace: networking
    
    Configura los siguientes valores:
    • project-id: es el ID que elegiste
    • folder-name es el ID de la carpeta que debe contener tu proyecto de red. Ten en cuenta que las carpetas tienen el prefijo del nombre de su carpeta superior, por ejemplo, la carpeta shared dentro del entorno dev tendría el ID dev.shared.
  3. Para convertir tu proyecto en un proyecto host de VPC compartida, agrega un plano adicional:
    kpt pkg get \
      https://github.com/GoogleCloudPlatform/blueprints.git/catalog/networking/shared-vpc@kpt-v1 \
      ./landing-zone/projects/${NET_PROJECT_ID}/host-project
    
  4. Confirma los cambios para activar la creación del proyecto:
    git add ./landing-zone/projects/${NET_PROJECT_ID}/
    git commit -m "Add networking host project"
    git push
    

Crea la red

Ahora que tienes un proyecto host, puedes crear una VPC compartida mediante el plano de red:

  1. Agrega el plano de la red a tu zona de destino:
    kpt pkg get \
      https://github.com/GoogleCloudPlatform/blueprints.git/catalog/networking/network@kpt-v1 \
      ./landing-zone/network/${ENVIRONMENT}/
    
  2. Abre el archivo landing-zone/network/ENVIRONMENT/setters.yaml. Para personalizar este plano, reemplaza los siguientes métodos set:
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: setters
    data:
      # Required setters
      network-name: network-name
      project-id: project-id
      region: us-central1
      # Optional setters
      namespace: networking
      vpn-secret-key: vpn-shared-secret
      vpn-secret-name: vpn-shared-secret
      prefix: ""
    
    Configura los siguientes valores:
    • network-name: El nombre que deseas usar para tu red, por ejemplo, dev-network-shared
    • region: La región en la que se implementará tu primera subred, por ejemplo, us-east4
    • project-id: es el ID del proyecto en el que se alojará la red. (NETWORK_PROJECT_ID)
  3. Crea un secreto para la clave precompartida que usa Cloud VPN. Este valor es sensible y no se debe confirmar en tu repositorio de Git. En su lugar, envíalo directamente al controlador de configuración:
    kubectl create secret generic vpn-shared-secret \
      --from-literal=vpn-shared-secret="SECRET_VALUE" \
      -n networking
  4. Confirma el plano personalizado para implementar la red:
    git add ./landing-zone/network/
    git commit -m "Add network setup"
    git push
    

Verifica la implementación de redes

Para verificar que tu red se haya creado correctamente, sigue estos pasos:

  • Confirma que el proyecto se creó de forma correcta:
    kubectl describe project ${NET_PROJECT_ID} -n projects
  • Recupera el estado de las carpetas directamente desde el espacio de nombres de la jerarquía en tu clúster:
    kubectl get gcp \
      -n networking -o yaml \
      | grep "^    name: |message"
  • Inspecciona tu red a través de Cloud Console.

Exporta datos de registro

Una de las prácticas recomendadas de Google Cloud para las organizaciones empresariales es supervisar y retener los registros de auditoría.

Los planos de la zona de destino incluyen varias opciones para administrar la exportación y retención de registros.

Sigue los pasos que se muestran a continuación para implementar un plano que exportará todos los registros de tu organización a BigQuery para la retención y el análisis a largo plazo.

Crea un proyecto host

Si deseas exportar registros a BigQuery, necesitarás un proyecto para alojarlos. Dado que exportarás registros para toda tu organización, debes colocar este proyecto en el entorno de producción. Este se puede crear mediante un plano.

  1. Descarga el plano del proyecto en tu zona de destino para crear un proyecto host.
    export LOGGING_PROJECT_ID="LOGGING_PROJECT_ID"
    
    kpt pkg get \
      https://github.com/GoogleCloudPlatform/blueprints.git/catalog/project@kpt-v1 \
      ./landing-zone/projects/${LOGGING_PROJECT_ID}
    

    Reemplaza lo siguiente:

    • LOGGING_PROJECT_ID: El ID que deseas asignar a tu proyecto de red
  2. Abre el archivo landing-zone/projects/LOGGING_PROJECT_ID/setters.yaml. Para personalizar este plano, reemplaza los siguientes métodos set:
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: setters
    data:
      folder-name: name.of.folder
      project-id: project-id
      # These defaults can be kept
      folder-namespace: hierarchy
      networking-namespace: networking
    
    Configura los siguientes valores:
    • project-id: es el ID del proyecto que elegiste para almacenar las exportaciones de registros (LOGGING_PROJECT_ID)
    • folder-name es el ID de la carpeta que debe contener tu proyecto de registro. Ten en cuenta que las carpetas tienen el prefijo del nombre de su carpeta superior, por ejemplo, la carpeta shared dentro del entorno dev tendría el ID dev.shared.
  3. Confirma los cambios para activar la creación del proyecto:
    git add ./landing-zone/projects/${LOGGING_PROJECT_ID}/
    git commit -m "Add logging project"
    git push
    

Exportar registros a BigQuery

Si exportas los registros a BigQuery, puedes conservarlos para su análisis posterior. Este plano incluye la creación de un conjunto de datos de BigQuery para almacenar los registros y configurar la exportación a ese conjunto de datos.

  1. Agrega el plano de registro a tu zona de destino:
    kpt pkg get https://github.com/GoogleCloudPlatform/blueprints.git/catalog/log-export/org/bigquery-export@kpt-v1 ./landing-zone/logging/bigquery-export
  2. Abre el archivo landing-zone/logging/bigquery-export/setters.yaml. Para personalizar este plano, reemplaza el ID del proyecto:
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: setters
    data:
      # This is required
      project-id: my-project-id
      # These defaults can be left unchanged
      namespace: logging
      dataset-description: BigQuery audit logs for organization
      dataset-location: US
      dataset-name: audit-logs
      default-table-expiration-ms: "3600000"
      delete-contents-on-destroy: "false"
      filter: ""
    
    Configura los siguientes valores:
    • project-id: es el ID del proyecto que elegiste para almacenar tus registros (LOGGING_PROJECT_ID)
  3. Confirma el plano para crear la exportación de registros.
    git add ./landing-zone/logging/
    git commit -m "Add log export to BigQuery"
    git push

Verifica la exportación del registro

Para verificar que tu exportación de registros se haya configurado de forma correcta, haz lo siguiente:

  • Confirma que el proyecto se creó de forma correcta:
    kubectl describe project ${LOGGING_PROJECT} -n projects
    gcloud projects describe ${LOGGING_PROJECT_ID}
    
  • Recupera el estado de los recursos en el espacio de nombres logging:
    kubectl get bigquerydatasets,iampolicymembers,logginglogsinks -n logging -o yaml \
      | grep "^    name: |message"
  • Recupera el estado de la exportación de registros a través de la CLI de gcloud (el receptor nuevo debe aparecer en la lista):
    gcloud logging sinks list --organization=${ORG_ID}
  • Después de que el receptor se haya configurado por un tiempo, verifica que los registros fluyan a BigQuery:

    # List tables
    bq ls --project_id ${LOGGING_PROJECT_ID} bqlogexportdataset
    
    # Query a table
    # Change this to a result of "bq ls" above so that the name matches one of your tables
    TABLE_OF_INTEREST=git_sync_20201130
    bq query --project_id ${LOGGING_PROJECT_ID} "SELECT * FROM bqlogexportdataset.${TABLE_OF_INTEREST} LIMIT 2"
    

Soluciona problemas

Red predeterminada

Cuando creas el controlador de configuración, es posible que recibas un error que indica que la red predeterminada no está disponible:

Error 400: Project "" has no network named "default"., badRequest\n\n  on main.tf line 35, in resource "google_container_cluster" "acp_cluster"

Este error se produce porque el controlador de configuración depende de la red predeterminada. Para resolver esto, debes crear una red predeterminada nueva:

gcloud compute networks create default --subnet-mode=auto

Hidratación y Cloud Build

Como parte del plano de GitOps, creaste un activador de Cloud Build que supervisa el repositorio de código fuente para detectar cambios y realiza las siguientes acciones:

  1. Valida que el contenido de esos cambios use funciones kpt.
  2. Genera la configuración final “hidratada”, que se guarda en un repositorio de implementación y se aplica a tu clúster mediante el Sincronizador de configuración.

Esta canalización de Cloud Build se puede supervisar desde la consola o mediante gcloud. Este comando de gcloud se puede usar para recuperar el estado de compilación más reciente:

FILTER="source.repo_source.commit_sha=$(git rev-parse HEAD)"
# You can poll on this command until status is either SUCCESS or FAILURE
gcloud builds list --project=${PROJECT_ID} --filter=${FILTER}

BUILD_ID=$(gcloud builds list --project=${PROJECT_ID} --filter=${FILTER} --format='get(id)' | head -n 1)
# View logs for your run. You can use this to debug errors
gcloud builds log --project=${PROJECT_ID} $BUILD_ID

Ejecución local

Si deseas obtener comentarios sobre los problemas más rápido que los que proporciona la canalización de Cloud Build, también puedes usar kpt para ejecutar la canalización de forma local con este comando (se ejecuta desde la raíz del repositorio de código fuente):

kpt fn render ./landing-zone/

Campos inmutables y recursos

Algunos campos de los recursos subyacentes de Google Cloud son inmutables, como los de ID del proyecto o el nombre de tu red de VPC. Config Connector bloqueará las ediciones en esos campos y no podrá activar los cambios. Si deseas editar uno de estos campos inmutables, primero debes borrar el recurso original (mediante Git) antes de volver a agregarlo con los nuevos valores preferidos.

Implementación y Sincronizador de configuración

El repositorio “deployment” contiene recursos completamente hidratados que definen la zona de destino. Estos recursos se sincronizan con el controlador de configuración mediante el Sincronizador de configuración. Puedes verificar si hay errores en este proceso de sincronización mediante el nomos comando cli:

nomos status

Facturación

El plano de zona de destino configurará automáticamente los permisos de facturación correctos para administrar la facturación de tu organización. Si no se pueden conectar tus proyectos con tu cuenta de facturación, es posible que esta exista fuera de la organización. Por lo tanto, deberás otorgar permisos directamente a la cuenta de servicio projects para administrar la cuenta de facturación:

export PROJECTS_SA="$(kubectl get ConfigConnectorContext -n projects -o jsonpath='{.items[0].spec.googleServiceAccount}')"
gcloud alpha billing accounts add-iam-policy-binding $BILLING_ACCOUNT \
  --role=roles/billing.admin \
  --member="serviceAccount:${PROJECTS_SA}"

Realiza una limpieza

Si decides dejar de usar la zona de destino, debes limpiar todos los recursos creados. Debes quitar los recursos del controlador de configuración antes de borrarlo.

Como alternativa, si deseas conservar los recursos de la zona de destino mientras abandonan el flujo de trabajo declarativo, puedes optar por borrar el controlador de configuración (aunque no se recomienda).

Quita recursos

Los recursos se pueden borrar si quitas los archivos asociados del repositorio de Git de las zonas de destino. Esto funciona para recursos individuales o para paquetes completos.

Sin embargo, no puedes borrar toda tu zona de destino a la vez (para evitar eliminaciones accidentales). En cambio, deberás eliminar los recursos de zona de destino en unos pocos pasos:

# Delete downstream resources
git rm -rf ./landing-zone/logging/
git rm -rf ./landing-zone/network/
git commit -m "Delete downstream resources"
git push
# Confirm Config Sync successfully applies

# Delete projects
git rm -rf ./landing-zone/projects/
git commit -m "Delete projects"
git push
# Confirm Config Sync successfully applies

# Delete folders and organization policies, but leave the policy template (see below for why)
git rm -rf ./landing-zone/hierarchy/
find ./landing-zone/policies/ -type f -not \( -name 'folder-naming-constraint-template.yaml' \) -delete
git add ./landing-zone/
git commit -m "Delete hierarchy and organization policies"
git push
# Confirm Config Sync successfully applies

# Delete landing zone except for 1 cluster-scoped resource
# (folder-naming-constraint-template.yaml) and 1 empty namespace (projects.yaml).
# See /anthos-config-management/docs/reference/errors#knv2006
find ./landing-zone/ -type f -not \( -name 'folder-naming-constraint-template.yaml' -or -name 'projects.yaml' \) -delete
cat <<EOF > ./landing-zone/namespaces/projects.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: projects
EOF
git add ./landing-zone/
git commit -m "Delete all landing zone resources except 1 cluster-scoped resource and 1 namespace"
git push
# Confirm Config Sync successfully applies

# Delete remaining resources
git rm -rf ./landing-zone/
git commit -m "Delete remaining resources"
git push

Borra el controlador de configuración

gcloud alpha anthos config controller delete --location=us-central1 ${CONFIG_CONTROLLER_NAME}