Desplegar clústeres en el perímetro

En este tutorial se presenta una solución lista para usar que utiliza Google Distributed Cloud (solo software) en hardware desnudo y Config Sync para desplegar clústeres de Kubernetes en el perímetro a gran escala. Este tutorial está dirigido a operadores y desarrolladores de plataformas. Antes de leer este documento, asegúrate de que conoces las siguientes tecnologías y conceptos:

En este tutorial, usarás máquinas virtuales (VMs) de Compute Engine para emular nodos desplegados en el perímetro y una aplicación de punto de venta de ejemplo como carga de trabajo perimetral. El software de Google Distributed Cloud y Config Sync proporcionan gestión y control centralizados para tu clúster perimetral. Config Sync extrae dinámicamente nuevas configuraciones de GitHub y aplica estas políticas y configuraciones a tus clústeres.

Arquitectura de despliegue perimetral

Una implementación de edge de comercio es una buena forma de ilustrar la arquitectura que se usa en una implementación de clúster de hardware desnudo típica.

Una tienda física es el punto de interacción más cercano entre una unidad de negocio de una empresa y el consumidor. Los sistemas de software de las tiendas deben ejecutar sus cargas de trabajo, recibir actualizaciones oportunas y registrar métricas críticas de forma aislada del sistema de gestión central de la empresa. Además, estos sistemas de software deben diseñarse de forma que puedan ampliarse a más tiendas en el futuro. Aunque cualquier implementación de clúster de hardware desnudo cumple todos estos requisitos para los sistemas de software de las tiendas, el perfil de periferia permite un caso práctico importante: implementaciones en entornos con recursos de hardware limitados, como la fachada de una tienda.

En el siguiente diagrama se muestra una implementación de clúster de hardware desnudo que usa el perfil de edge en una tienda:

Despliegue que usa el perfil de perímetro en una tienda

El diagrama anterior muestra una tienda física típica. La tienda tiene dispositivos inteligentes, como lectores de tarjetas, terminales de punto de venta, cámaras e impresoras. La tienda también tiene tres dispositivos de hardware de computación física (etiquetados como Node 1, Node 2 y Node 3). Todos estos dispositivos están conectados a un conmutador 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 forman la infraestructura de hardware. El software de Google Distributed Cloud se ejecuta en cada uno de los tres dispositivos informáticos. Estos dispositivos también tienen su propio almacenamiento en disco y están configurados para replicar datos entre ellos y así conseguir una alta disponibilidad.

En el diagrama también se muestran los siguientes componentes clave que forman parte de una implementación de clúster bare metal:

  • El componente marcado como MetalLB es el balanceador de carga agrupado.

  • El componente Config Sync permite sincronizar el estado del clúster con los repositorios de origen. Es un complemento opcional muy recomendable que requiere una instalación y una configuración independientes. Para obtener más información sobre cómo configurar Config Sync y la nomenclatura, consulta la documentación de Config Sync.

  • 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 origen central. Las implementaciones de clústeres en varias ubicaciones perimetrales extraen actualizaciones de los repositorios de origen. Este comportamiento se representa mediante las flechas que conectan los dos repositorios del diagrama con los componentes de Config Sync del clúster que se ejecuta en los dispositivos.

  • Otro componente clave que se muestra como parte del clúster es el tiempo de ejecución de la máquina virtual en GDC. VM Runtime en GDC permite ejecutar cargas de trabajo basadas en máquinas virtuales dentro del clúster sin necesidad de usar contenedores. En la documentación sobre el tiempo de ejecución de máquinas virtuales en GDC se explica cómo habilitarlo y desplegar tus cargas de trabajo de máquinas virtuales en el clúster.

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

Los recuadros de la parte inferior del diagrama representan los numerosos dispositivos (como quioscos, tablets o cámaras) de una tienda, todos ellos conectados a un conmutador de red central. La red local de la tienda permite que las aplicaciones que se ejecutan en el clúster accedan a estos dispositivos.

En la siguiente sección, se muestra la emulación de esta implementación de tiendaGoogle Cloud con VMs de Compute Engine. Esta emulación es la que usarás en el tutorial que sigue para experimentar con un clúster Bare Metal.

Despliegue de perímetro emulado en Google Cloud

En el siguiente diagrama se muestra todo lo que has configurado enGoogle Cloud en este tutorial. Este diagrama se corresponde con el diagrama de la tienda de venta al público de la sección anterior. Este despliegue representa una ubicación perimetral emulada en la que se despliega la aplicación del punto de venta. La arquitectura también muestra una carga de trabajo de una aplicación de ejemplo de punto de venta que se usa en este tutorial. Accedes a la aplicación de punto de venta dentro del clúster mediante un navegador web como kiosco.

Arquitectura de la aplicación de punto de venta y cómo se despliega en un clúster que se ejecuta en máquinas virtuales de Compute Engine

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

En una instalación típica de un clúster de hardware desnudo, puedes configurar tus propios balanceadores de carga. Sin embargo, en este tutorial no se configura ningún balanceador de carga externo. En su lugar, utiliza el balanceador de carga MetalLB incluido. El balanceador de carga 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 creando una red de superposición VxLAN sobre la red de nube privada virtual (VPC) predeterminada.

Dentro del rectángulo etiquetado como "Red de superposición de nivel 2 (VxLAN)", se muestran los componentes de software que se ejecutan en las tres VMs de Compute Engine. Este rectángulo de VxLAN incluye el despliegue del clúster, que contiene un espacio de nombres de Kubernetes dentro del clúster. Todos los componentes de este espacio de nombres de Kubernetes forman la aplicación de punto de venta que se ha implementado en el clúster. La aplicación del punto de venta tiene tres microservicios: servidor de APIs, 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 carga MetalLB incluido del clúster desde fuera de las VMs. En el diagrama se muestra un proxy inverso de NGINX configurado para ejecutarse en las VMs y enrutar el tráfico que llega a las VMs de Compute Engine al balanceador de carga. Esta es solo una solución alternativa para los fines de este tutorial, en el que los nodos perimetrales se emulan mediante Google Cloud máquinas virtuales de 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 hardware desnudo que se ejecute en una ubicación perimetral.
  2. Usa Google Distributed Cloud para crear un clúster en la infraestructura perimetral emulada.
  3. Conecta y registra el clúster con Google Cloud.
  4. Despliega una carga de trabajo de aplicación de punto de venta de muestra en el clúster.
  5. Usa la consola Google Cloud para verificar y monitorizar la aplicación de punto de venta que opera en la ubicación perimetral.
  6. Usa Config Sync para actualizar la aplicación de punto de venta que se ejecuta en el clúster.

Antes de empezar

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

    Ir a la selección de proyectos

  2. Asegúrate de que la facturación esté habilitada en tu proyecto de Cloud. Consulta cómo comprobar si la facturación está habilitada en un proyecto.

  3. Instala y inicializa la CLI de Google Cloud.

Bifurca y clona el repositorio anthos-samples

Todas las secuencias de comandos que se usan en este tutorial se almacenan en el repositorio anthos-samples. La estructura de carpetas de /anthos-bm-edge-deployment/acm-config-sink se organiza de acuerdo con lo que espera Config Sync. Clona este repositorio en tu cuenta de GitHub antes de continuar con los pasos siguientes.

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

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

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

  3. Crea una bifurcación del repositorio anthos-samples en tu cuenta de GitHub:

    1. Ve al repositorio anthos-samples.
    2. En la esquina superior derecha de la página, haz clic en el icono Bifurcar.
    3. Haz clic en la cuenta de usuario de GitHub en la que quieras bifurcar el repositorio. Se te redirigirá automáticamente a la página con tu versión bifurcada del repositorio anthos-samples.

  4. Abre un terminal en tu entorno local.

  5. Clona el repositorio bifurcado ejecutando el siguiente comando, donde 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

Configurar 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 tutorial 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 nueva instancia de shell:

    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"

    Sustituye los siguientes valores:

    • PROJECT_ID: tu ID de proyecto Google Cloud .
    • GITHUB_USERNAME: tu nombre de usuario de GitHub.
    • ACCESS_TOKEN: el token de acceso personal que has creado para tu repositorio de GitHub.

    Mantenga los valores predeterminados de las demás variables de entorno. Se explican en las secciones que aparecen a continuación.

  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 Google Cloud para las instancias de Compute Engine. Esta secuencia de comandos crea el archivo de clave JSON de la nueva cuenta de servicio en <REPO_ROOT>/anthos-bm-edge-deployment/build-artifacts/consumer-edge-gsa.json. También configura el conjunto de claves y la clave de Cloud Key Management Service para el cifrado de la clave privada SSH.

    ./scripts/create-primary-gsa.sh

    La siguiente muestra 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
# ...

Aprovisionar las instancias de Compute Engine

En esta sección, creará las máquinas virtuales de Compute Engine en las que se instalará el software de Google Distributed Cloud. También debes verificar la conectividad a estas VMs antes de pasar a la sección de instalación.

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

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

  2. Cifra 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 aplícalo. Después de crear el archivo, inspecciona .envrc para asegurarte de que las variables de entorno se han sustituido por los valores correctos.

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

    A continuación, se muestra un ejemplo de archivo .envrc generado al sustituir las variables de entorno del archivo templates/envrc-template.sh. Observa que las líneas que se han actualizado están resaltadas: 

    # 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:

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

Instalar un clúster de bare metal con Ansible

La secuencia de comandos que se usa en esta guía crea clústeres en grupos de tres instancias de Compute Engine. El número de clústeres creados se controla mediante la variable de entorno GCE_COUNT. Por ejemplo, si asigna el valor 6 a la variable de entorno GCE_COUNT, se crearán dos clústeres con 3 instancias de VM cada uno. De forma predeterminada, la variable de entorno GCE_COUNT se define como 3. Por lo tanto, en esta guía se creará un clúster con 3 instancias de Compute Engine. Las instancias de VM tienen un prefijo cnuc- seguido de un número. La primera instancia de VM de cada clúster actúa como 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 y cnuc-7).

El playbook de Ansible hace lo siguiente:

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

Sigue estos pasos para configurar y empezar el proceso de instalación:

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

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

    Cuando la compilación se ejecuta correctamente, genera 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 la plantilla:

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

  3. Ejecuta la secuencia de comandos de instalación que inicia un contenedor Docker a partir de la imagen creada anteriormente. La secuencia de comandos usa Docker internamente para generar el contenedor con un montaje de volumen en el directorio de trabajo actual. Una vez que hayas completado correctamente esta secuencia de comandos, debes estar dentro del contenedor de Docker que se ha creado. La instalación de Ansible se activa desde este contenedor.

    ./install.sh

    Cuando la secuencia de comandos se ejecuta correctamente, genera 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 Docker, verifica el acceso a las instancias de Compute Engine:

    ./scripts/health-check.sh

    Cuando la secuencia de comandos se ejecuta correctamente, genera 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 interior del contenedor Docker, ejecuta el playbook de Ansible para instalar un clúster bare metal 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

    Si la instalación se realiza correctamente, se generará 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

Inicia sesión en el clúster en la Google Cloud consola

Una vez que se haya ejecutado el playbook de Ansible, se instalará un clúster independiente en las VMs de Compute Engine. Este clúster también está registrado enGoogle Cloudmediante el agente de Connect. Sin embargo, para ver los detalles de este clúster, debes iniciar sesión en él desde la consola de Google Cloud .

Para iniciar sesión en el clúster, sigue estos pasos:

  1. Copia el token de la salida del playbook de Ansible de la sección anterior.

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

    Ve a la página Clústeres de Kubernetes.

    1. En la lista de clústeres, haga clic en Acciones junto al clúster cnuc-1 y, a continuación, en Iniciar sesión.
    2. Selecciona Token y pega el token copiado.
    3. Haz clic en Login (Iniciar sesión).
  3. En la Google Cloud consola, ve a la página Configuración de la sección Funciones.

    Ve a Configuración

    4. En la pestaña Paquetes, consulte la columna Estado de sincronización de la tabla de clústeres. Comprueba que el estado sea Sincronizado. El estado Sincronizado indica que Config Sync ha sincronizado correctamente tus configuraciones de GitHub con el clúster cnuc-1 que has implementado.

s

Configurar un proxy para el tráfico externo

El clúster instalado en los pasos anteriores usa un balanceador de carga agrupado llamado MetalLB. Solo se puede acceder a este servicio de balanceador de carga a través de una dirección IP de nube privada virtual (VPC). Para enrutar el tráfico que entra a través de su IP externa al balanceador de carga incluido, 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).

Los scripts de instalación de los pasos anteriores han instalado NGINX en los hosts de administración junto con un archivo de configuración de ejemplo. Actualiza este archivo para usar la dirección IP del servicio del balanceador de carga y reinicia NGINX.

  1. En tu estación de trabajo, usa SSH para iniciar sesión en 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 NGINX para enrutar el tráfico al servicio de balanceador de carga del servidor de APIs. 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 obtenida:

    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 aplica la nueva configuración:

    sudo systemctl restart nginx

  5. Comprueba y verifica el estado del servidor NGINX. Debe indicar "active (running)":

    sudo systemctl status nginx

    Si NGINX se ejecuta correctamente, se generará un resultado como el siguiente:

    ● 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 y accede a la estación de trabajo de administrador:

    exit

  7. Salir de la sesión de shell al contenedor Docker. Cuando salgas de la instancia de administrador, seguirás dentro del contenedor de Docker que se ha usado para la instalación:

    exit

Acceder a la aplicación de punto de venta

Con la configuración de proxy externo, puedes acceder a la aplicación que se ejecuta en el clúster. Para acceder a la aplicación de punto de venta de ejemplo, sigue estos 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 interfaz de usuario 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 correctamente, generan un resultado como el siguiente:

    Point the browser to: 34.134.194.84:8082

  2. Abre tu navegador web y ve 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 ejemplo y probarla, tal como se muestra en la siguiente captura de pantalla:

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

Usar Config Sync para actualizar el servidor de la API

La aplicación de ejemplo se puede actualizar a una versión más reciente actualizando los archivos de configuración del repositorio raíz. Config Sync detecta las actualizaciones y aplica los cambios automáticamente en tu clúster. En este ejemplo, el repositorio raíz es el repositorio anthos-samples que has clonado al principio de esta guía. Para ver cómo se puede actualizar la aplicación de punto de venta de ejemplo a una versión más reciente, sigue estos 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 del despliegue se encuentra en el archivo 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. Añade, confirma e inserta los cambios en 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 Config Sync para comprobar el estado de la especificación de configuración. Comprueba que el estado sea Sincronizado.

    Ir a la página Config Sync

  4. En la Google Cloud consola, ve a la página Cargas de trabajo de Kubernetes Engine para comprobar que la implementación se ha actualizado.

    Ve a la página Cargas de trabajo de Kubernetes Engine.

  5. Cuando el estado de Deployment (Despliegue) sea OK (Correcto), dirija su navegador a la dirección IP de la sección anterior para ver la aplicación del punto de venta. Ten en cuenta que la versión del título muestra "V2", lo que indica que se ha implementado el cambio en tu aplicación, como se muestra en la siguiente captura de pantalla:

    Se ha implementado la versión 2 de la aplicación de punto de venta

    Es posible que tengas que hacer un restablecimiento completo de la pestaña del navegador para ver los cambios.

Limpieza

Para evitar cargos innecesarios de Google Cloud , elimina los recursos que hayas usado en esta guía cuando hayas terminado. Puedes eliminar estos recursos manualmente o eliminar tu proyecto de Google Cloud , lo que también eliminará 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 realizados por las secuencias de comandos de instalación.

  • Quita las direcciones IP de la máquina virtual de Compute Engine que se hayan añadido al archivo /etc/hosts.
  • Elimina la configuración de SSH de cnuc-* en el archivo ~/.ssh/config.
  • Elimina las huellas digitales de la máquina virtual de Compute Engine del archivo ~/.ssh/known_hosts.

Eliminar proyecto

Si has creado un proyecto específico para este procedimiento, elimina el Google Cloud proyecto de la Google Cloud consola.

  • 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 has usado un proyecto que ya tenías para llevar a cabo este procedimiento, haz lo siguiente:

    • Anula el registro de todos los clústeres de Kubernetes cuyo nombre empiece por cnuc-.
    • Elimina todas las VMs de Compute Engine cuyo nombre empiece por cnuc-.
    • Elimina el segmento de Cloud Storage cuyo nombre empiece por abm-edge-boot.
    • Elimina las reglas de cortafuegos allow-pod-ingress y allow-pod-egress.
    • Elimina el secreto install-pub-key de Secret Manager.

    Siguientes pasos

    Puedes ampliar esta guía añadiendo otra ubicación perimetral. Si asignas el valor 6 a la variable de entorno GCE_COUNT y vuelves a ejecutar los mismos pasos de las secciones anteriores, se crearán tres instancias de Compute Engine (cnuc-4, cnuc-5 y cnuc-6) y un clúster independiente llamado cnuc-4.

    También puedes probar a actualizar las configuraciones de clúster de 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 información detallada sobre los pasos de esta guía y las secuencias de comandos implicadas, consulta el repositorio anthos-samples.