Implementa Google Distributed Cloud Virtual para clústeres de Bare Metal en el perímetro

En este instructivo, se presenta una solución lista para usar que usa GKE en Bare Metal y Config Management a fin de implementar clústeres de Kubernetes en el perímetro a gran escala. Este instructivo es para desarrolladores y operadores de plataformas. Debes estar familiarizado con las siguientes tecnologías y conceptos:

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. GKE en Bare Metal y Config Management proporcionan administración y control centralizados para el clúster perimetral. Config Management extrae de forma dinámica los parámetros de configuración nuevos de GitHub y los aplica a tus clústeres.

Arquitectura de implementación perimetral

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 GKE en Bare Metal.

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 los almacenes deben ejecutar sus cargas de trabajo, recibir actualizaciones oportunas y, también, informar las métricas críticas de forma aislada desde el 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 GKE en Bare Metal satisface todos estos requisitos para los sistemas de software de tienda, el perfil perimetral habilita un caso de uso importante: implementaciones en entornos con recursos de hardware limitados, como una vidriera minorista.

En el siguiente diagrama, se muestra una implementación de GKE en Bare Metal que usa el perfil perimetral en una tienda minorista:

Se muestra una implementación de GKE en Bare Metal que usa el perfil perimetral en una tienda minorista
Una implementación de GKE en Bare Metal en una tienda minorista

En el diagrama anterior, se muestra una tienda física de venta minorista típica. La tienda tiene dispositivos inteligentes, como lectores de tarjetas, máquinas de punto de venta, impresoras y cámaras. La tienda también tiene tres dispositivos físicos de hardware de procesamiento (con las etiquetas 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 informáticos están conectados entre sí a través de una red de capa 2. Los dispositivos informáticos conectados en red conforman la infraestructura de Bare Metal. GKE en Bare Metal se ejecuta dentro de cada uno de los tres dispositivos informáticos. Estos dispositivos también tienen su propio almacenamiento en disco y están configurados para la replicación de datos entre ellos con una alta disponibilidad.

En el diagrama, también se muestran los siguientes componentes clave que forman parte de una implementación de GKE en Bare Metal:

  • El componente marcado como MetalLB es el balanceador de cargas en paquetes que se implementa con GKE en Bare Metal.
  • El componente de Config Management permite sincronizar el estado del clúster con los repositorios de origen. Es un complemento opcional muy recomendado que requiere una instalación y configuración independientes. Si deseas obtener más información para configurar Config Management y la nomenclatura diferente, consulta la documentación de Config Management.

  • 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 del clúster se envían a estos repositorios de origen centrales. Las implementaciones de GKE en Bare Metal en varias ubicaciones perimetrales extraen actualizaciones de los repositorios de origen. Este comportamiento se representa con las flechas que conectan los dos repositorios del diagrama a los componentes de Config Management dentro del clúster de Google Distributed Cloud Virtual para Bare Metal que se ejecuta en los dispositivos.

  • Otro componente clave que se representa como parte del clúster es el entorno de ejecución de VM en Google Distributed Cloud. El entorno de ejecución de VM en Google Distributed Cloud permite ejecutar cargas de trabajo basadas en VM existentes dentro del clúster sin la necesidad de crear contenedores. La documentación del entorno de ejecución de VM en Google Distributed Cloud Google explica cómo habilitarlo y, luego, implementar las cargas de trabajo de VM en el clúster.

  • El componente marcado como Aplicación (Application) denota el software que la tienda minorista implementó 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 una aplicación de este tipo.

Los cuadros en la parte inferior del diagrama representan los numerosos dispositivos (como kioscos, tablets o cámaras) dentro de una tienda minorista, los cuales están conectados a un switch de red central. Las herramientas de redes locales dentro del almacén permiten que las aplicaciones que se ejecutan dentro de la implementación de GKE en Bare Metal lleguen a estos dispositivos.

En la siguiente sección, verás la emulación de esta implementación de tienda minorista en Google Cloud mediante las VM de Compute Engine. Esta emulación es la que usarás en el instructivo que sigue para experimentar con GKE en Bare Metal.

Implementación perimetral emulada en Google Cloud

El siguiente diagrama es una representación de 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 perímetro emulada en la que se implementa la aplicación de punto de venta. La arquitectura también muestra una carga de trabajo simple de la aplicación de muestra de un punto de venta que usarás en este instructivo. Puedes acceder a la aplicación de punto de venta dentro del clúster mediante un navegador web como kiosco.

La imagen muestra la arquitectura de la aplicación de punto de venta y cómo se implementa dentro de un clúster de Google Distributed Cloud Virtual for Bare Metal que se ejecuta en VMs de Compute Engine.
Una aplicación de ejemplo implementada dentro de un clúster de Google Distributed Cloud Virtual for Bare Metal

Las tres máquinas virtuales (VMs) de Compute Engine del diagrama anterior representan el hardware físico (o nodos) en una ubicación perimetral típica. Este hardware estaría conectado con los conmutadores de red para constituir la infraestructura de Bare Metal. En nuestro entorno emulado en Google Cloud, estas VM están conectadas entre sí a través de la red de nube privada virtual (VPC) predeterminada en el proyecto de Google Cloud.

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

Dentro del rectángulo con la etiqueta "Red superpuesta L2 (VxLAN)", se muestran los componentes de software que se ejecutan dentro de las tres VM de Compute Engine. Este rectángulo incluye el clúster de Google Distributed Cloud Virtual for Bare Metal y un Proxy inverso. El clúster está representado por el rectángulo “GKE en Bare Metal”. Este rectángulo que representa el clúster incluye otro rectángulo marcado como “Espacio de nombres de Kubernetes (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 Anthos. La aplicación del punto de venta tiene tres microservicios: servidor de la 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 en paquete de MetalLB del clúster de Anthos desde fuera de las VM. En el diagrama, se muestra un proxy inverso de NGINX que se está configurando para ejecutarse dentro de las VM a fin de enrutar el tráfico que llega a las VM de Compute Engine al balanceador de cargas. Esta es solo una solución alternativa para los fines de este instructivo en la que los nodos perimetrales se emulan con las VM de Google Cloud Compute Engine. En una ubicación perimetral real, esto se puede hacer con una configuración de red adecuada.

Objetivos

  1. Usa VMs de Compute Engine para emular una infraestructura de equipos físicos que se ejecuta en una ubicación perimetral.
  2. Crea un clúster de Google Distributed Cloud Virtual for Bare Metal en la infraestructura perimetral emulada.
  3. Conectar y registrar el clúster con Google Cloud
  4. Implementar una carga de trabajo de muestra de la aplicación de punto de venta en el clúster de Anthos
  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 Config Management para actualizar la aplicación de punto de venta que se ejecuta en el clúster de Anthos.

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, initialize en 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 de acuerdo con lo que espera Config Management. 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 usar en la configuración de Config Management. Esto es necesario para que los componentes de Config Management 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 de anhos-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 anhos-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 descrita 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 configurarás 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 de tu proyecto de Google Cloud.
    • GITHUB_USERNAME: es tu nombre de usuario de GitHub.
    • ACCESS_TOKEN: Es el token de acceso personal que creaste para el repositorio de GitHub.

    Conserva los valores predeterminados de 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 clave privada SSH.

    ./scripts/create-primary-gsa.sh

    A continuación, se puede ver una parte de la secuencia de comandos. Haz clic en el vínculo View on GitHub para ver la secuencia de comandos completa.

    anthos-bm-edge-deployment/scripts/create-primary-gsa.sh 
    # ...
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 VM de Compute Engine en las que se instalará GKE en Bare Metal. También debes verificar la conectividad a estas VM antes de continuar con la sección de instalación.

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

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

  2. Encriptar 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 obtenlo como fuente. Después de crearlo, inspecciona el archivo .envrc para asegurarte de que las variables de entorno se hayan reemplazado con los valores correctos.

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

    El siguiente es un ejemplo de un archivo .envrc que se genera mediante el reemplazo de las variables de entorno en el archivo templates/envrc-template.sh. Observa que las líneas que se actualizaron se destacan:

    anthos-bm-edge-deployment/templates/envrc.example 
    # 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é instalado GKE en Bare Metal.

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

Instala GKE en Bare Metal con Ansible

La secuencia de comandos que se usa en esta guía crea clústeres de Google Distributed Cloud Virtual for Bare Metal en grupos de tres instancias de Compute Engine. La variable de entorno GCE_COUNT controla la cantidad de clústeres creados. Por ejemplo, configura la variable de entorno GCE_COUNT como 6 a fin de crear dos clústeres de Google Distributed Cloud Virtual para Bare Metal con 3 instancias de VM cada uno. De forma predeterminada, la variable de entorno GCE_COUNT se configura como 3. Por lo tanto, en esta guía, se creará un clúster con 3 instancias de Compute Engine. Las instancias de VM 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 GKE en Bare Metal en las instancias configuradas de Compute Engine.
  • Crea un clúster independiente de Google Distributed Cloud Virtual para Bare Metal llamado cnuc-1.
  • Registra el clúster cnuc-1 en Google Cloud.
  • Instala Config Management en el clúster cnuc-1.
  • Configura Config Management para que se sincronice con la configuración del clúster ubicada en anthos-bm-edge-deployment/acm-config-sink en el 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 usará 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, se 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 que se compiló anteriormente. La secuencia de comandos usa Docker de forma interna para generar el contenedor con una activación de volumen en el directorio de trabajo actual. Después de completar con éxito esta secuencia de comandos, debes estar dentro del contenedor de Docker que se creó. La instalación de Ansible se activa desde este contenedor.

    ./install.sh

    Cuando la secuencia de comandos se ejecuta de forma correcta, se 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 de forma correcta, se 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 GKE en Bare Metal en instancias de Compute Engine. Cuando finalice, 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 de forma correcta, 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 GKE en Bare Metal en la consola de Google Cloud

Una vez que se ejecuta la guía de Ansible hasta su finalización, se instala un clúster independiente de Google Distributed Cloud Virtual for Bare Metal dentro de las VM de Compute Engine. Este clúster también se registra en Google Cloud a través del agente de Connect. Sin embargo, para ver los detalles de este clúster, debes acceder a él desde la consola de Google Cloud. Para acceder al clúster de GKE, completa los siguientes pasos.

  1. Copia el token de la salida 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 Config Management para verificar el estado de las especificaciones de configuración. Verifica que el estado sea Sincronizado. El estado Sincronizado indica que Config Management sincronizó de forma correcta los archivos de configuración de GitHub con el clúster implementado, cnuc-1.

    Ir a la página Config Management

    Config Management sincronizado con el repositorio de código fuente.

Configura un proxy para el tráfico externo

El clúster de Google Distributed Cloud Virtual for Bare Metal instalado en los pasos anteriores usa un balanceador de cargas agrupado 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 entra por 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 acceder al servidor de la API de la aplicación del punto de venta a través de la IP externa del host de administrador (cnuc-1).

Las secuencias de comandos de instalación en 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 la 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 de 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 de balanceador de cargas:

    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 y verifica el estado del servidor de NGINX para informar "active (running)":

    sudo systemctl status nginx

    Cuando NGINX se ejecuta correctamente, produce un resultado como el del 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 de SSH a la estación de trabajo de administrador:

    exit

  7. Sal de la sesión de shell en el contenedor de Docker. Cuando sales de la instancia de administrador, 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 del proxy externo, puedes acceder a la aplicación que se ejecuta dentro del clúster de GKE. Para acceder a la aplicación de muestra de punto de venta, completa los siguientes pasos.

  1. En tu estación de trabajo, obtén la dirección IP externa de la instancia de administrador de Compute Engine y accede a la IU de la aplicación de 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 el navegador web y navega hasta 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 indica en la siguiente captura de pantalla de ejemplo:

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

Usa Config Management para actualizar el servidor de la API

La aplicación de muestra se puede actualizar a una versión más reciente si actualizas los archivos de configuración en el repositorio raíz. Config Management detecta las actualizaciones y realiza los cambios automáticamente en tu clúster. 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 muestra puede pasar por 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 para la implementación se encuentra en el archivo en anthos-bm-edge-deployment/acm-config-sink/namespaces/pos/api-server.yaml.

    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 al 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 Config Management para verificar el estado de las especificaciones de configuración. Verifica que el estado sea Sincronizado.

    Ir a la página Config Management

  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 en el título muestra “V2”, lo que indica que el cambio en la aplicación se implementó, 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 actualizar la pestaña del navegador para ver los cambios.

Limpia

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.

  • En la consola de Google Cloud, ve a la página Administrar recursos.

    Ir a Administrar recursos

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

    • 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 en 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 Virtual para Bare Metal 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.