Implementa clústeres de Google Distributed Cloud en el perímetro

En este instructivo, se presenta una solución lista para usar que usa Google Distributed Cloud y el Sincronizador de configuración para implementar clústeres de Kubernetes en la conexión de integración a gran escala. Este instructivo está dirigido a desarrolladores y operadores de plataformas. Antes de leer este documento, asegúrate de estar familiarizado con los siguientes conceptos y tecnologías:

En este instructivo, usarás máquinas virtuales (VMs) de Compute Engine para emular los nodos implementados en el perímetro y una aplicación de punto de venta de muestra como la carga de trabajo perimetral. Google Distributed Cloud y el Sincronizador de configuración proporcionan administración y control centralizados para tu clúster perimetral. El Sincronizador de configuración extrae configuraciones nuevas de forma dinámica de GitHub, y aplica estas políticas y configuraciones a tus clústeres.

Arquitectura de implementación de Edge

Una implementación perimetral de venta minorista es una buena manera de ilustrar la arquitectura que se usa en una implementación típica de Google Distributed Cloud.

Una tienda minorista física es el punto de interacción más cercano entre una unidad de negocios empresarial y el consumidor. Los sistemas de software dentro de las tiendas deben ejecutar sus cargas de trabajo, recibir actualizaciones oportunas y generar informes de métricas críticas de forma aislada del sistema de administración central de la empresa. Además, estos sistemas de software deben diseñarse para que se puedan expandir a más ubicaciones de tiendas en el futuro. Si bien Google Distributed Cloud satisface todos estos requisitos para los sistemas de software de la tienda, el perfil perimetral habilita un caso de uso importante: implementaciones en entornos con recursos de hardware limitados, como un frente de tienda minorista.

En el siguiente diagrama, se muestra una implementación de Google Distributed Cloud que usa el perfil perimetral en una tienda minorista:

Implementación de Google Distributed Cloud que usa el perfil perimetral en una tienda minorista

En el diagrama anterior, se muestra una tienda minorista física típica. La tienda tiene dispositivos inteligentes, como lectores de tarjetas, máquinas de punto de venta, cámaras e impresoras. La tienda también tiene tres dispositivos de hardware de procesamiento físico (etiquetados como Node 1, Node 2 y Node 3). Todos estos dispositivos están conectados a un switch de red central. Por lo tanto, los tres dispositivos de procesamiento están conectados entre sí a través de una red de capa 2. Los dispositivos de procesamiento en red conforman la infraestructura de bare metal. Google Distributed Cloud se ejecuta en cada uno de los tres dispositivos de procesamiento. Estos dispositivos también tienen su propio almacenamiento en disco y están configurados para la replicación de datos entre ellos para lograr la alta disponibilidad.

En el diagrama, también se muestran los siguientes componentes clave que forman parte de una implementación de Google Distributed Cloud:

  • El componente marcado como MetalLB es el balanceador de cargas en paquetes que se implementa con Google Distributed Cloud.
  • El componente del Sincronizador de configuración permite sincronizar el estado del clúster con los repositorios de origen. Es un complemento opcional muy recomendado que requiere instalación y configuración independientes. Para obtener más información sobre cómo configurar el Sincronizador de configuración y la nomenclatura diferente, consulta la documentación del Sincronizador de configuración.

  • El repositorio raíz y el repositorio de espacio de nombres que se muestran en la parte superior del diagrama fuera de la ubicación de la tienda representan dos repositorios de origen.

    Los cambios en el clúster se envían a estos repositorios de código fuente centrales. Las implementaciones de Google Distributed Cloud en varias ubicaciones de perímetro extraen actualizaciones de los repositorios de origen. Este comportamiento se representa con las flechas que conectan los dos repositorios del diagrama con los componentes del Sincronizador de configuración dentro del clúster de Google Distributed Cloud que se ejecuta en los dispositivos.

  • Otro componente clave que se muestra como parte del clúster es el entorno de ejecución de VM en GDC. El entorno de ejecución de VM en GDC permite ejecutar cargas de trabajo existentes basadas en VMs dentro del clúster sin necesidad de realizar la creación de contenedores. En la documentación del entorno de ejecución de VM en GDC, se explica cómo habilitarlo y, luego, implementar tus cargas de trabajo de VM en el clúster.

  • El componente marcado como Aplicación denota el software que la tienda minorista implementa en el clúster. La aplicación de punto de venta que se ve en los kioscos de una tienda minorista podría ser un ejemplo de este tipo de aplicación.

Los cuadros de la parte inferior del diagrama representan los muchos dispositivos (como kioscos, tabletas o cámaras) dentro de una tienda minorista, todos los cuales están conectados a un switch de red central. La red local dentro de la tienda permite que las aplicaciones que se ejecutan dentro de la implementación de Google Distributed Cloud lleguen a estos dispositivos.

En la siguiente sección, verás la emulación de esta implementación de tienda minorista en Google Cloud con VMs de Compute Engine. Esta emulación es la que usarás en el siguiente instructivo para experimentar con Google Distributed Cloud.

Implementación de borde emulada en Google Cloud

En el siguiente diagrama, se muestra todo lo que configuraste en Google Cloud en este instructivo. Este diagrama se correlaciona con el diagrama de la tienda minorista de la sección anterior. Esta implementación representa una ubicación de borde emulada en la que se implementa la aplicación de punto de venta. La arquitectura también muestra una carga de trabajo de aplicación de punto de venta de ejemplo simple que usas en este instructivo. Para acceder a la aplicación de punto de venta dentro del clúster, usa un navegador web como kiosco.

Arquitectura de la aplicación de punto de venta y cómo se implementa dentro de un clúster de Google Distributed Cloud que se ejecuta en VMs de Compute Engine

Las tres máquinas virtuales (VMs) de Compute Engine en el diagrama anterior representan el hardware físico (o nodos) en una ubicación perimetral típica. Este hardware se conectaría junto con interruptores de red para formar la infraestructura de bare metal. En nuestro entorno emulado en Google Cloud, estas VMs se conectan entre sí a través de la red predeterminada de nube privada virtual (VPC) en el proyecto de Google Cloud.

En una instalación típica de Google Distributed Cloud, puedes configurar tus propios balanceadores de cargas. Sin embargo, para este instructivo, no configurarás un balanceador de cargas externo. En su lugar, usa el balanceador de cargas de MetalLB incluido en el paquete que se instala con Google Distributed Cloud. El balanceador de cargas de MetalLB incluido requiere conectividad de red de capa 2 entre los nodos. Por lo tanto, la conectividad de capa 2 entre las VMs de Compute Engine se habilita mediante la creación de una red de superposición VxLAN sobre la red predeterminada de nube privada virtual (VPC).

Dentro del rectángulo etiquetado como "L2 overlay network (VxLAN)", se muestran los componentes de software que se ejecutan dentro de las tres VMs de Compute Engine. Este rectángulo incluye el clúster de Google Distributed Cloud y un proxy inverso. El clúster está representado por el rectángulo “Google Distributed Cloud”. Este rectángulo que representa el clúster incluye otro rectángulo marcado como "Kubernetes namespace (pos)". Esto representa un espacio de nombres de Kubernetes dentro del clúster. Todos los componentes dentro de este espacio de nombres de Kubernetes conforman la aplicación de punto de venta que se implementa en el clúster de Google Distributed Cloud. La aplicación de punto de venta tiene tres microservicios: servidor de API, inventario y pagos. Todos estos componentes juntos representan una "aplicación" que se muestra en el diagrama de arquitectura de lanzamiento de Edge anterior.

No se puede acceder directamente al balanceador de cargas de MetalLB incluido en el clúster de Google Distributed Cloud desde fuera de las VMs. En el diagrama, se muestra un proxy inverso de NGINX que se configura para ejecutarse dentro de las VMs y enrutar el tráfico que ingresa a las VMs de Compute Engine al balanceador de cargas. Esta es solo una solución alternativa para los fines de este instructivo, en el que los nodos de perímetro se emulan con VMs de Compute Engine de Google Cloud. En una ubicación de perímetro real, esto se puede hacer con la configuración de red adecuada.

Objetivos

  1. Usa VMs de Compute Engine para emular una infraestructura de bare metal que se ejecuta en una ubicación perimetral.
  2. Crea un clúster de Google Distributed Cloud en la infraestructura perimetral emulada.
  3. Conectar y registrar el clúster con Google Cloud
  4. Implementa una carga de trabajo de aplicación de punto de venta de muestra en el clúster de Google Distributed Cloud.
  5. Usa la consola de Google Cloud para verificar y supervisar la aplicación de punto de venta que opera en la ubicación perimetral.
  6. Usa el Sincronizador de configuración para actualizar la aplicación de punto de venta que se ejecuta en el clúster de Google Distributed Cloud.

Antes de comenzar

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

    Ir a la selección del proyecto

  2. Asegúrate de que la facturación esté habilitada para tu proyecto de Cloud. Obtén información sobre cómo verificar si la facturación está habilitada en un proyecto.

  3. Instala y, luego, inicializa Google Cloud CLI.

Bifurca y clona el repositorio anthos-samples

Todas las secuencias de comandos que se usan en este instructivo se almacenan en el repositorio anthos-samples. La estructura de carpetas en /anthos-bm-edge-deployment/acm-config-sink se organiza según lo que espera el Sincronizador de configuración. Clona este repositorio en tu propia cuenta de GitHub antes de continuar con los siguientes pasos.

  1. Si aún no tienes una cuenta de GitHub, crea una.

  2. Crea un token de acceso personal para usarlo en la configuración del Sincronizador de configuración. Esto es necesario para que los componentes del Sincronizador de configuración del clúster se autentiquen con tu cuenta de GitHub cuando intentes sincronizar cambios nuevos.

    1. Selecciona solo el permiso public_repo.
    2. Guarda el token de acceso que creaste en un lugar seguro para usarlo más adelante.

  3. Bifurca el repositorio anthos-samples en tu propia cuenta de GitHub:

    1. Ve al repositorio anthos-samples.
    2. Haz clic en el ícono Fork ubicado en la esquina superior derecha de la página.
    3. Haz clic en la cuenta de usuario de GitHub en la que deseas bifurcar el repositorio. Se te redireccionará automáticamente a la página con la versión bifurcada del repositorio anthos-samples.

  4. Abre una terminal en tu entorno local.

  5. Clona el repositorio bifurcado mediante la ejecución del siguiente comando, en el que GITHUB_USERNAME es el nombre de usuario de tu cuenta de GitHub:

    git clone https://github.com/GITHUB_USERNAME/anthos-samples
cd anthos-samples/anthos-bm-edge-deployment

Configura el entorno de la estación de trabajo

Para completar la implementación perimetral que se describe en este documento, necesitas una estación de trabajo con acceso a Internet y las siguientes herramientas instaladas:

Ejecuta todos los comandos del instructivo en la estación de trabajo que configures en esta sección.

  1. En tu estación de trabajo, inicializa las variables de entorno en una instancia de shell nueva:

    export PROJECT_ID="PROJECT_ID"
export REGION="us-central1"
export ZONE="us-central1-a"

# port on the admin Compute Engine instance you use to set up an nginx proxy
# this allows to reach the workloads inside the cluster via the VM IP
export PROXY_PORT="8082"

# should be a multiple of 3 since N/3 clusters are created with each having 3 nodes
export GCE_COUNT="3"

# url to the fork of: https://github.com/GoogleCloudPlatform/anthos-samples
export ROOT_REPO_URL="https://github.com/GITHUB_USERNAME/anthos-samples"

# this is the username used to authenticate to your fork of this repository
export SCM_TOKEN_USER="GITHUB_USERNAME"

# access token created in the earlier step
export SCM_TOKEN_TOKEN="ACCESS_TOKEN"

    Reemplaza los siguientes valores:

    • PROJECT_ID: Es el ID del proyecto de Google Cloud.
    • GITHUB_USERNAME: es tu nombre de usuario de GitHub.
    • ACCESS_TOKEN: el token de acceso personal que creaste para tu repositorio de GitHub.

    Mantén los valores predeterminados para las otras variables de entorno. Se explican en las siguientes secciones.

  2. En tu estación de trabajo, inicializa Google Cloud CLI:

    gcloud config set project "${PROJECT_ID}"
gcloud services enable compute.googleapis.com

gcloud config set compute/region "${REGION}"
gcloud config set compute/zone "${ZONE}"

  3. En tu estación de trabajo, crea la cuenta de servicio de Google Cloud para las instancias de Compute Engine. Esta secuencia de comandos crea el archivo de claves JSON para la cuenta de servicio nueva en <REPO_ROOT>/anthos-bm-edge-deployment/build-artifacts/consumer-edge-gsa.json. También configura el llavero de claves y la clave de Cloud Key Management Service para la encriptación de claves privadas SSH.

    ./scripts/create-primary-gsa.sh

    El siguiente ejemplo es solo una parte de la secuencia de comandos. Para ver la secuencia de comandos completa, haz clic en Ver en GitHub.

    # ...
EXISTS=$(gcloud iam service-accounts list \
  --filter="email=${GSA_EMAIL}" \
  --format="value(name, disabled)" \
  --project="${PROJECT_ID}")

if [[ -z "${EXISTS}" ]]; then
  echo "GSA [${GSA_EMAIL}]does not exist, creating it"

  # GSA does NOT exist, create
  gcloud iam service-accounts create ${GSA_NAME} \
    --description="GSA used on each Target machine to make gcloud commands" \
    --display-name="target-machine-gsa" \
    --project "${PROJECT_ID}"
else
  if [[ "${EXISTS}" =~ .*"disabled".* ]]; then
    # Found GSA is disabled, enable
    gcloud iam service-accounts enable "${GSA_EMAIL}" --project "${PROJECT_ID}"
  fi
  # otherwise, no need to do anything
fi
# ...

Aprovisiona las instancias de Compute Engine

En esta sección, crearás las VMs de Compute Engine en las que se instalará Google Distributed Cloud. También debes verificar la conectividad a estas VMs antes de continuar con la sección de instalación.

  1. En tu estación de trabajo, crea claves SSH que se usen para la comunicación entre las instancias de Compute Engine.

    ssh-keygen -f ./build-artifacts/consumer-edge-machine

  2. Encripta la clave privada SSH con Cloud Key Management Service.

    gcloud kms encrypt \
    --key gdc-ssh-key \
    --keyring gdc-ce-keyring \
    --location global \
    --plaintext-file build-artifacts/consumer-edge-machine \
    --ciphertext-file build-artifacts/consumer-edge-machine.encrypted

  3. Genera el archivo de configuración del entorno .envrc y crea su fuente. Después de crearlo, inspecciona el archivo .envrc para asegurarte de que las variables de entorno se hayan reemplazado por los valores correctos.

    envsubst < templates/envrc-template.sh > .envrc
source .envrc

    El siguiente es un ejemplo de un archivo .envrc generado reemplazando las variables de entorno en el archivo templates/envrc-template.sh. Observa que las líneas que se actualizaron están destacadas: 

    # GSA Key used for provisioning (result of running ./scripts/create-primary-gsa.sh)
LOCAL_GSA_FILE=$(pwd)/build-artifacts/consumer-edge-gsa.json
export LOCAL_GSA_FILE
# GCP Project ID
export PROJECT_ID="abm-edge-project"
# Bucket to store cluster snapshot information
export SNAPSHOT_GCS="abm-edge-project-cluster-snapshots"

# GCP Project Region (Adjust as desired)
export REGION="us-central1"
# GCP Project Zone (Adjust as desired)
export ZONE="us-central1-a"

# Gitlab Personal Access Token credentials (generated in Quick Start step 2)
export SCM_TOKEN_USER="LarryPage"
export SCM_TOKEN_TOKEN="oo901Sp-FHuzmz__dgl0393atkf69c8L"

# Default Root Repo setup for multiple locations
export ROOT_REPO_URL="https://github.com/LarryPage/anthos-samples"
export ROOT_REPO_BRANCH="main"
export ROOT_REPO_DIR="/anthos-bm-edge-deployment/acm-config-sink"

# OIDC Configuration (off by default)
export OIDC_CLIENT_ID="" # Optional, requires GCP API setup work
export OIDC_CLIENT_SECRET="" # Optional
export OIDC_USER="" # Optional
export OIDC_ENABLED="false" # Flip to true IF implementing OIDC on cluster

  4. Crea instancias de Compute Engine en las que esté instalada Google Distributed Cloud.

    ./scripts/cloud/create-cloud-gce-baseline.sh -c "$GCE_COUNT" | \
    tee ./build-artifacts/gce-info

Instala Google Distributed Cloud con Ansible

La secuencia de comandos que se usa en esta guía crea clústeres de Google Distributed Cloud en grupos de tres instancias de Compute Engine. La cantidad de clústeres creados se controla con la variable de entorno GCE_COUNT. Por ejemplo, puedes establecer la variable de entorno GCE_COUNT en 6 para crear dos clústeres de Google Distributed Cloud con 3 instancias de VM cada uno. De forma predeterminada, la variable de entorno GCE_COUNT se establece en 3. Por lo tanto, en esta guía, se creará un clúster con 3 instancias de Compute Engine. Las instancias se nombran con un prefijo cnuc- seguido de un número. La primera instancia de VM de cada clúster actúa como la estación de trabajo de administrador desde la que se activa la instalación. El clúster también recibe el mismo nombre que la VM de la estación de trabajo de administrador (por ejemplo, cnuc-1, cnuc-4, cnuc-7).

La guía de Ansible realiza las siguientes acciones:

  • Configura las instancias de Compute Engine con las herramientas necesarias, como docker, bmctl, gcloud y nomos.
  • Instala Google Distributed Cloud en las instancias de Compute Engine configuradas.
  • Crea un clúster independiente de Google Distributed Cloud llamado cnuc-1.
  • Registra el clúster cnuc-1 en Google Cloud.
  • Instala el Sincronizador de configuración en el clúster cnuc-1.
  • Configura el Sincronizador de configuración para que se sincronice con la configuración del clúster ubicada en anthos-bm-edge-deployment/acm-config-sink en tu repositorio bifurcado.
  • Genera el Login token para el clúster.

Completa los siguientes pasos para configurar y comenzar el proceso de instalación:

  1. En tu estación de trabajo, crea la imagen de Docker que se usa para la instalación. Esta imagen tiene todas las herramientas necesarias para el proceso de instalación, como Ansible, Python y Google Cloud CLI.

    gcloud builds submit --config docker-build/cloudbuild.yaml docker-build/

    Cuando la compilación se ejecuta correctamente, produce un resultado como el siguiente:

    ...
latest: digest: sha256:99ded20d221a0b2bcd8edf3372c8b1f85d6c1737988b240dd28ea1291f8b151a size: 4498
DONE
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
ID                                    CREATE_TIME                DURATION  SOURCE                                                                                         IMAGES                                                  STATUS
2238baa2-1f41-440e-a157-c65900b7666b  2022-08-17T19:28:57+00:00  6M53S     gs://my_project_cloudbuild/source/1660764535.808019-69238d8c870044f0b4b2bde77a16111d.tgz  gcr.io/my_project/consumer-edge-install (+1 more)  SUCCESS

  2. Genera el archivo de inventario de Ansible a partir de una plantilla.

    envsubst < templates/inventory-cloud-example.yaml > inventory/gcp.yaml

  3. Ejecuta la secuencia de comandos de instalación que inicia un contenedor de Docker a partir de la imagen compilada anteriormente. La secuencia de comandos usa Docker de forma interna para crear el contenedor con una activación de volumen en el directorio de trabajo actual. Cuando completes correctamente esta secuencia de comandos, debes estar dentro del contenedor de Docker que se creó. Activas la instalación de Ansible desde dentro de este contenedor.

    ./install.sh

    Cuando la secuencia de comandos se ejecuta correctamente, produce un resultado como el siguiente:

    ...
Check the values above and if correct, do you want to proceed? (y/N): y
Starting the installation
Pulling docker install image...

==============================
Starting the docker container. You will need to run the following 2 commands (cut-copy-paste)
==============================
1: ./scripts/health-check.sh
2: ansible-playbook all-full-install.yaml -i inventory
3: Type 'exit' to exit the Docker shell after installation
==============================
Thank you for using the quick helper script!
(you are now inside the Docker shell)

  4. Desde el contenedor de Docker, verifica el acceso a las instancias de Compute Engine.

    ./scripts/health-check.sh

    Cuando la secuencia de comandos se ejecuta correctamente, produce un resultado como el siguiente:

    ...
cnuc-2 | SUCCESS => {"ansible_facts": {"discovered_interpreter_python": "/usr/bin/python3"},"changed": false,"ping": "pong"}
cnuc-3 | SUCCESS => {"ansible_facts": {"discovered_interpreter_python": "/usr/bin/python3"},"changed": false,"ping": "pong"}
cnuc-1 | SUCCESS => {"ansible_facts": {"discovered_interpreter_python": "/usr/bin/python3"},"changed": false,"ping": "pong"}

  5. Desde el contenedor de Docker, ejecuta la guía de Ansible para instalar Google Distributed Cloud en instancias de Compute Engine. Cuando se complete, verás el Login Token del clúster impreso en la pantalla.

    ansible-playbook all-full-install.yaml -i inventory | tee ./build-artifacts/ansible-run.log

    Cuando la instalación se ejecuta correctamente, se produce un resultado como el siguiente:

    ...
TASK [abm-login-token : Display login token] **************************************************************************
ok: [cnuc-1] => {
    "msg": "eyJhbGciOiJSUzI1NiIsImtpZCI6Imk2X3duZ3BzckQyWmszb09sZHFMN0FoWU9mV1kzOWNGZzMyb0x2WlMyalkifQ.eymljZS1hY2NvdW
iZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6ImVkZ2Etc2EtdG9rZW4tc2R4MmQiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2Nvd
4CwanGlof6s-fbu8"
}
skipping: [cnuc-2]
skipping: [cnuc-3]

PLAY RECAP ***********************************************************************************************************
cnuc-1                     : ok=205  changed=156  unreachable=0    failed=0    skipped=48   rescued=0    ignored=12
cnuc-2                     : ok=128  changed=99   unreachable=0    failed=0    skipped=108  rescued=0    ignored=2
cnuc-3                     : ok=128  changed=99   unreachable=0    failed=0    skipped=108  rescued=0    ignored=2

Accede al clúster de Google Distributed Cloud en la consola de Google Cloud

Después de que se ejecute por completo la guía de Ansible, se instalará un clúster independiente de Google Distributed Cloud dentro de las VMs de Compute Engine. Este clúster también está registrado en Google Cloud con el agente de Connect. Sin embargo, para ver los detalles de este clúster, debes acceder al clúster desde la consola de Google Cloud. Para acceder al clúster de GKE, completa los siguientes pasos.

  1. Copia el token del resultado de la guía de Ansible en la sección anterior.

  2. En la consola de Google Cloud, ve a la página Clústeres de Kubernetes y usa el token copiado para acceder al clúster cnuc-1.

    Ir a la página Clústeres de Kubernetes

    1. En la lista de clústeres, haz clic en Acciones junto al clúster cnuc-1 y, luego, en Acceder.
    2. Selecciona Token y pega el token copiado.
    3. Haga clic en Acceder.
  3. En la consola de Google Cloud, ve a la página Configuración en la sección Funciones.

    Ir a Configuración

    4. En la pestaña Paquetes, verifica la columna Estado de sincronización en la tabla del clúster. Verifica que el estado sea Sincronizado. Un estado Sincronizado indica que el Sincronizador de configuración sincronizó correctamente tus archivos de configuración de GitHub con el clúster implementado, cnuc-1.

s

Configura un proxy para el tráfico externo

El clúster de Google Distributed Cloud instalado en los pasos anteriores usa un balanceador de cargas en paquetes llamado MetalLB. Solo se puede acceder a este servicio de balanceador de cargas a través de una dirección IP de nube privada virtual (VPC). Para enrutar el tráfico que llega a través de su IP externa al balanceador de cargas en paquetes, configura un servicio de proxy inverso en el host de administrador (cnuc-1). Este servicio de proxy inverso te permite llegar al servidor de la API de la aplicación de punto de venta a través de la IP externa del host de administrador (cnuc-1).

Las secuencias de comandos de instalación de los pasos anteriores instalaron NGINX en los hosts de administrador junto con un archivo de configuración de muestra. Actualiza este archivo para usar la dirección IP del servicio de balanceador de cargas y reinicia NGINX.

  1. En tu estación de trabajo, usa SSH para acceder a la estación de trabajo de administrador:

    ssh -F ./build-artifacts/ssh-config abm-admin@cnuc-1

  2. Desde la estación de trabajo del administrador, configura el proxy inverso de NGINX para enrutar el tráfico al servicio del balanceador de cargas del servidor de la API. Obtén la dirección IP del servicio de Kubernetes de tipo LoadBalancer:

    ABM_INTERNAL_IP=$(kubectl get services api-server-lb -n pos | awk '{print $4}' | tail -n 1)

  3. Actualiza el archivo de configuración de la plantilla con la dirección IP recuperada:

    sudo sh -c "sed 's/<K8_LB_IP>/${ABM_INTERNAL_IP}/g' \
    /etc/nginx/nginx.conf.template > /etc/nginx/nginx.conf"

  4. Reinicia NGINX para asegurarte de que se aplique la nueva configuración:

    sudo systemctl restart nginx

  5. Verifica el estado del servidor NGINX para que los informes muestren el estado "activo (en ejecución)":

    sudo systemctl status nginx

    Cuando NGINX se ejecuta de forma correcta, produce un resultado como el siguiente ejemplo:

    ● nginx.service - A high performance web server and a reverse proxy server
    Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
    Active: active (running) since Fri 2021-09-17 02:41:01 UTC; 2s ago
    Docs: man:nginx(8)
    Process: 92571 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
    Process: 92572 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
Main PID: 92573 (nginx)
    Tasks: 17 (limit: 72331)
    Memory: 13.2M
    CGroup: /system.slice/nginx.service
            ├─92573 nginx: master process /usr/sbin/nginx -g daemon on; master_process on;
            ├─92574 nginx: worker process
            ├─92575 nginx: worker process
            ├─92577 nginx: ....
            ...
            ...

  6. Sal de la sesión SSH a la instancia de administrador.

    exit

  7. Sal de la sesión de shell y entra al contenedor de Docker. Cuando sales de la instancia de admin, aún estás dentro del contenedor de Docker que se usó para la instalación:

    exit

Accede a la aplicación de punto de venta

Con la configuración de proxy externo, puedes acceder a la aplicación que se ejecuta dentro del clúster de GKE. Para acceder a la aplicación de punto de venta de ejemplo, completa los siguientes pasos.

  1. En tu estación de trabajo, obtén la dirección IP externa de la instancia de Compute Engine de administrador y accede a la IU de la aplicación del punto de venta:

    EXTERNAL_IP=$(gcloud compute instances list \
    --project ${PROJECT_ID} \
    --filter="name:cnuc-1" \
    --format="get(networkInterfaces[0].accessConfigs[0].natIP)")
echo "Point the browser to: ${EXTERNAL_IP}:${PROXY_PORT}"

    Cuando las secuencias de comandos se ejecutan de forma correcta, producen resultados como los siguientes:

    Point the browser to: 34.134.194.84:8082

  2. Abre tu navegador web y navega a la dirección IP que se muestra en el resultado del comando anterior. Puedes acceder a la aplicación de punto de venta de muestra y probarla, como se muestra en la siguiente captura de pantalla de ejemplo:

    Versión 1 de la aplicación de punto de venta implementada

Usa el Sincronizador de configuración para actualizar el servidor de API

Para actualizar la aplicación de ejemplo a una versión más reciente, actualiza los archivos de configuración en el repositorio raíz. El Sincronizador de configuración detecta las actualizaciones y realiza los cambios en el clúster automáticamente. En este ejemplo, el repositorio raíz es el repositorio anthos-samples que clonaste al comienzo de esta guía. Para ver cómo la aplicación de punto de venta de ejemplo puede realizar una implementación de actualización a una versión más reciente, completa los siguientes pasos.

  1. En tu estación de trabajo, actualiza el campo image para cambiar la versión del servidor de la API de v1 a v2. La configuración YAML de la implementación está en el archivo en anthos-bm-edge-deployment/acm-config-sink/namespaces/pos/api-server.yaml.

    containers:
- name: api-server
  image: us-docker.pkg.dev/anthos-dpe-abm-edge-pos/abm-edge-pos-images/api-server:v1

  2. Agrega, confirma y envía los cambios a tu repositorio bifurcado:

    git add acm-config-sink/namespaces/pos/api-server.yaml
git commit -m "chore: updated api-server version to v2"
git push

  3. En la consola de Google Cloud, ve a la página Sincronizador de configuración para verificar el estado de las especificaciones de configuración. Verifica que el estado sea Sincronizado.

    Ir a la página Sincronizador de configuración

  4. En la consola de Google Cloud, ve a la página Cargas de trabajo de Kubernetes Engine para verificar que la Implementación esté actualizada.

    Ir a la página Cargas de trabajo de Kubernetes Engine

  5. Cuando el estado de Implementación sea Correcto, apunta el navegador a la dirección IP de la sección anterior para ver la aplicación de punto de venta. Ten en cuenta que la versión del título muestra “V2”, lo que indica que se implementó el cambio en la aplicación, como se muestra en la siguiente captura de pantalla de ejemplo:

    Versión 2 de la aplicación de punto de venta implementada.

    Es posible que debas realizar una actualización forzada de la pestaña del navegador para ver los cambios.

Realiza una limpieza

A fin de evitar cargos innecesarios de Google Cloud, borra los recursos que se usaron para esta guía cuando termines. Puedes borrar estos recursos de forma manual o borrar el proyecto de Google Cloud, lo que también elimina todos los recursos. Además, también puedes limpiar los cambios realizados en tu estación de trabajo local:

Estación de trabajo local

Los siguientes archivos deben actualizarse para borrar los cambios que realizaron las secuencias de comandos de instalación.

  • Quita las direcciones IP de la VM de Compute Engine que se agregan al archivo /etc/hosts.
  • Quita la configuración SSH para cnuc-* en el archivo ~/.ssh/config.
  • Quita las huellas digitales de la VM de Compute Engine del archivo ~/.ssh/known_hosts.

Borrar proyecto

Si creaste un proyecto dedicado para este procedimiento, borra el proyecto de Google Cloud de la consola de Cloud.

  • In the Google Cloud console, go to the Manage resources page.

    Go to Manage resources

  • In the project list, select the project that you want to delete, and then click Delete.
  • In the dialog, type the project ID, and then click Shut down to delete the project.

    • Manual

    Si usaste un proyecto existente para este procedimiento, haz lo siguiente:

    • Cancela el registro de todos los clústeres de Kubernetes que tengan un nombre con el prefijo cnuc-.
    • Borra todas las VM de Compute Engine con un nombre con el prefijo cnuc-.
    • Borra el bucket de Cloud Storage con un nombre con el prefijo abm-edge-boot.
    • Borra las reglas de firewall allow-pod-ingress y allow-pod-egress.
    • Borra el secreto de Secret Manager install-pub-key.

    Próximos pasos

    Puedes expandir esta guía si agregas otra ubicación perimetral. Si configuras la variable de entorno GCE_COUNT como 6 y vuelves a ejecutar los mismos pasos de las secciones anteriores, se crean tres instancias nuevas de Compute Engine (cnuc-4, cnuc-5 y cnuc-6) y un nuevo clúster independiente de Google Distributed Cloud llamado cnuc-4.

    También puedes intentar actualizar las opciones de configuración de los clústeres en tu repositorio bifurcado para aplicar de forma selectiva diferentes versiones de la aplicación de punto de venta a los dos clústeres, cnuc-1 y cnuc-4, mediante ClusterSelectors.

    Para obtener detalles sobre los pasos individuales de esta guía, las secuencias de comandos involucradas, consulta el repositorio de anthos-samples.