En este instructivo, se presenta una solución lista para usar que usa clústeres de Anthos alojados en Bare Metal y Anthos Config Management a fin de implementar clústeres de Kubernetes en el perímetro a gran escala. Este instructivo es para operadores de plataformas y desarrolladores. Debes estar familiarizado con las siguientes tecnologías y conceptos:
- Guías de Ansible.
- Implementaciones perimetrales y sus desafíos
- Cómo trabajar con un proyecto de Google Cloud.
- Implementa una aplicación web en contenedor
- Interfaces de líneas de comandos de
gcloud
ykubectl
En este instructivo, usarás máquinas virtuales (VM) 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. Clústeres de Anthos alojados en Bare Metal y Anthos Config Management proporcionan administración y control centralizados para tu clúster perimetral. Anthos Config Management extrae configuraciones nuevas de forma dinámica de GitHub, y aplica estas políticas y configuraciones a tus clústeres.
Arquitectura de implementación perimetral
Una implementación perimetral de venta minorista es una buena forma de ilustrar la arquitectura que se usa en un clúster de Anthos típico en la implementación de equipos físicos.
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 e informar las métricas críticas por aislamiento 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 los clústeres de Anthos alojados en Bare Metal cumplen con 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 una vidriera minorista.
En el siguiente diagrama, se muestra un clúster de Anthos en una implementación de equipos físicos que usa el perfil perimetral de una tienda minorista:
En el diagrama anterior, se muestra una tienda 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 de hardware de procesamiento físico (etiquetados Node 1
, Node 2
y Node 3
). Todos estos dispositivos están conectados a un interruptor 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 conectados en red conforman la infraestructura de equipos físicos.
Los clústeres de Anthos alojados en Bare Metal se ejecutan dentro de cada uno de los tres dispositivos de computación. Estos dispositivos también tienen su propio almacenamiento en disco y están configurados para la replicación de datos entre ellos a fin de tener alta disponibilidad.
En el diagrama, también se muestran los siguientes componentes clave que forman parte de la implementación de clústeres de Anthos alojados en Bare Metal:
- El componente marcado como MetalLB es el balanceador de cargas en paquetes que se implementa con clústeres de Anthos alojados en Bare Metal.
- El componente de Anthos 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 quieres obtener más información para configurar Anthos Config Management y conocer las diferentes nomenclaturas, consulta la documentación de Anthos 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 en el clúster se envían a estos repositorios de origen central. Los clústeres de Anthos alojados en implementaciones de equipos físicos en varias ubicaciones perimetrales obtienen actualizaciones de los repositorios de origen. Este comportamiento se representa mediante las flechas que conectan los dos repositorios del diagrama con los componentes de Anthos Config Management dentro del clúster de Anthos alojado en Bare Metal que se ejecuta en los dispositivos.
Otro componente clave que se muestra como parte del clúster es Anthos VM Runtime. El entorno de ejecución de VM de Anthos permite ejecutar cargas de trabajo existentes basadas en VM dentro del clúster sin necesidad de crear contenedores. En la documentación del entorno de ejecución de VM de Anthos, se explica cómo habilitarlo y, luego, implementar tus cargas de trabajo de VM en el clúster.
El componente marcado como Application denota software implementado en el clúster por la tienda minorista. La aplicación del punto de venta que se ve en los kioscos de una tienda minorista puede ser un ejemplo de esta aplicación.
Los cuadros en la parte inferior del diagrama representan la gran cantidad de dispositivos (como kioscos, tablets o cámaras) dentro de una tienda minorista, que están conectados a un interruptor de red central. La red local dentro de la tienda permite que las aplicaciones que se ejecutan dentro de los clústeres de Anthos alojados 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 VM de Compute Engine. Esta emulación es lo que usarás en el instructivo siguiente para experimentar con clústeres de Anthos alojados en Bare Metal.
Implementación perimetral emulada en Google Cloud
En el siguiente diagrama, se describe todo lo que configuraste en Google Cloud en este instructivo. Este diagrama se correlaciona con el diagrama de tienda minorista de la sección anterior. Esta implementación representa una ubicación perimetral emulada en la que se implementa la aplicación del punto de venta. En la arquitectura, también se muestra un ejemplo de una carga de trabajo de aplicación de punto de venta simple en este instructivo. Puedes acceder a la aplicación del punto de venta dentro del clúster mediante un navegador web como kiosco.
Las tres máquinas virtuales (VM) 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 con los interruptores de red para conformar la infraestructura de equipos físicos. En nuestro entorno emulado en Google Cloud, estas VM están conectadas 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 clústeres de Anthos alojados en Bare Metal, puedes configurar tus propios balanceadores de cargas. Sin embargo, en este instructivo, no configurarás un balanceador de cargas externo. En su lugar, usa el balanceador de cargas de MetalLB empaquetado que se instala con clústeres de Anthos alojados en Bare Metal. El balanceador de cargas de MetalLB empaquetado requiere una 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 de superposición de VxLAN sobre la red predeterminada de nube privada virtual (VPC).
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 Anthos alojado en Bare Metal y un proxy inverso. El clúster está representado por el rectángulo de “clústeres de Anthos alojados 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 del 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 al balanceador de cargas de MetalLB empaquetado del clúster de forma directa desde fuera de las VM. En el diagrama, se muestra un proxy inverso de NGINX que se configura 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 se emulan los nodos perimetrales mediante 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
- Usa las VMs de Compute Engine para emular una infraestructura de equipos físicos que se ejecuta en una ubicación perimetral.
- Crea un clúster de Anthos alojado en Bare Metal en la infraestructura perimetral emulada.
- Conectar y registrar el clúster en Google Cloud
- Implementar una carga de trabajo de aplicación de muestra en el clúster de Anthos
- Usa Google Cloud Console para verificar y supervisar la aplicación de punto de venta que opera en la ubicación perimetral.
- Usa Anthos Config Management para actualizar la aplicación de punto de venta que se ejecuta en el clúster de Anthos.
Antes de comenzar
En la página del selector de proyectos de la consola de Google Cloud, selecciona o crea un proyecto de Google Cloud.
Asegúrate de que la facturación esté habilitada para tu proyecto de Cloud. Aprende a verificar si la facturación está habilitada en un proyecto.
Instala e inicializa Google Cloud CLI.
Bifurcar y clonar 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 Anthos Config Management.
Clona este repositorio en tu propia cuenta de GitHub antes de continuar con los
siguientes pasos.
Si aún no tienes una cuenta de GitHub, crea una.
Crea un token de acceso personal para usarlo en la configuración de Anthos Config Management. Esto es necesario para que los componentes de Anthos Config Management en el clúster se autentiquen con tu cuenta de GitHub cuando intentes sincronizar cambios nuevos.
- Selecciona solo el permiso
public_repo
. - Guarda el token de acceso que creaste en un lugar seguro para usarlo más adelante.
- Selecciona solo el permiso
Bifurca el repositorio
anthos-samples
en tu propia cuenta de GitHub:- Ve al repositorio anthos-samples.
- Haga clic en el ícono Fork ubicado en la esquina superior derecha de la página.
- 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.
Abre una terminal en tu entorno local.
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:
- Docker
- Herramienta de interfaz de línea de comandos de Envsubst (por lo general, preinstalada en Linux y otros SO similares a Unix)
Ejecuta todos los comandos del instructivo en la estación de trabajo que configures en esta sección.
En su estación de trabajo, inicialice 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"
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.
Mantén los valores predeterminados para las otras variables de entorno. Se explican en las siguientes secciones.
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}"
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
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.
Aprovisiona las instancias de Compute Engine
En esta sección, crearás las VM de Compute Engine en las que se instalarán los clústeres de Anthos alojados en Bare Metal. También verifica la conectividad a estas VM antes de continuar con la sección de instalación.
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
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
Genera el archivo de configuración del entorno
.envrc
y conócelo. Después de crearlo, inspecciona el archivo.envrc
para asegurarte de que las variables de entorno se reemplazaron por los valores correctos.envsubst < templates/envrc-template.sh > .envrc source .envrc
El siguiente es un ejemplo de un archivo
.envrc
que se genera cuando se reemplazan las variables de entorno en el archivotemplates/envrc-template.sh
. Ten en cuenta que se destacan las líneas que se actualizaron:Crea instancias de Compute Engine en las que estén instalados los clústeres de Anthos alojados en Bare Metal.
./scripts/cloud/create-cloud-gce-baseline.sh -c "$GCE_COUNT" | \ tee ./build-artifacts/gce-info
Instala clústeres de Anthos alojados en Bare Metal con Ansible
La secuencia de comandos que se usa en esta guía crea clústeres de Anthos en equipos físicos en grupos de tres instancias de Compute Engine. La variable de entorno GCE_COUNT
controla la cantidad de clústeres creados. Por ejemplo, debes establecer la variable de entorno GCE_COUNT
en 6
para crear dos clústeres de Anthos alojado en Bare Metal con instancias de VM de 3
cada una. 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 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
ynomos
. - Instala clústeres de Anthos alojados en Bare Metal en las instancias configuradas de Compute Engine.
- Crea un clúster independiente de Anthos alojado en Bare Metal llamado
cnuc-1
. - Registra el clúster
cnuc-1
en Google Cloud. - Instala Anthos Config Management en el clúster
cnuc-1
. - Configura Anthos Config Management 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
del clúster.
Completa los siguientes pasos para configurar e iniciar el proceso de instalación:
En tu estación de trabajo, crea la imagen de Docker que se usó 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 de forma correcta, 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
Genera el archivo de inventario de Ansible a partir de una plantilla.
envsubst < templates/inventory-cloud-example.yaml > inventory/gcp.yaml
Ejecuta la secuencia de comandos de instalación que inicia un contenedor de Docker a partir de la imagen compilada antes. La secuencia de comandos usa de forma interna Docker para generar el contenedor con una activación de volumen en el directorio de trabajo actual. Una vez que se complete con éxito esta secuencia de comandos, debes estar dentro del contenedor de Docker que se creó. Activarás la instalación de Ansible desde el interior de este contenedor.
./install.sh
Cuando la secuencia de comandos se ejecuta correctamente, 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)
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, 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"}
Desde el contenedor de Docker, ejecuta la guía de Ansible para instalar clústeres de Anthos alojados en Bare Metal en las instancias de Compute Engine. Cuando termines, 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 a los clústeres de Anthos alojados en Bare Metal en la consola de Google Cloud
Una vez que la guía de Ansible se ejecuta por completo, se instala un clúster de Anthos alojado en Bare Metal dentro de las VM de Compute Engine. Este clúster también está registrado 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 Google Cloud Console. Para acceder al clúster de Anthos, completa los siguientes pasos.
Copia el token del resultado de la guía de Ansible en la sección anterior.
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
- En la lista de clústeres, haz clic en
cnuc-1
y, luego, en Acceder.
Acciones junto al clúster - Selecciona Token y pega el token copiado.
- Haga clic en Acceder.
- En la lista de clústeres, haz clic en
En Google Cloud Console, ve a la página Administración de configuración para verificar el estado de la especificación de configuración. Verifica que el estado sea Sincronizado. Un estado Sincronizado indica que Anthos Config Management sincronizó correctamente tus archivos de configuración de GitHub con el clúster implementado,
cnuc-1
.Ir a la página Config Management
Configura un proxy para el tráfico externo
El clúster de Anthos alojado en Bare Metal 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 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 llegar 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 de los pasos anteriores instalaron NGINX en los hosts de administrador junto con un archivo de configuración de muestra. Actualiza este archivo para que use la dirección IP del servicio del balanceador de cargas y reinicia NGINX.
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
Desde el interior de la estación de trabajo de administrador, configura el proxy inverso de NGINX para enrutar el tráfico al servicio de balanceador de cargas del servidor de la API. Obtén la dirección IP del servicio de Kubernetes del tipo de balanceador de cargas:
ABM_INTERNAL_IP=$(kubectl get services api-server-lb -n pos | awk '{print $4}' | tail -n 1)
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"
Reinicia NGINX para asegurarte de que se aplique la configuración nueva:
sudo systemctl restart nginx
Revise y verifique el estado del servidor NGINX para informar "active (running)":
sudo systemctl status nginx
Cuando NGINX se ejecuta correctamente, produce 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: .... ... ...
Sal de la sesión de SSH a la estación de trabajo de administrador:
exit
Salga de la sesión de shell en el contenedor de Docker. Cuando sales de la instancia de administrador, sigues 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 Anthos. Para acceder a la aplicación de punto de venta de muestra, completa los siguientes pasos.
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
Abre el navegador web y navega a la dirección IP que se muestra en el resultado del comando anterior. Puedes acceder a la aplicación del ejemplo del punto de venta y probarla, como se muestra en la siguiente captura de pantalla de ejemplo:
Usa Anthos Config Management para actualizar el servidor de la API
La aplicación de ejemplo se puede actualizar a una versión más reciente mediante la actualización de los archivos de configuración en el repositorio raíz. Anthos 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 ejemplo puede pasar por una implementación de actualización a una versión más reciente, completa los siguientes pasos.
En tu estación de trabajo, actualiza el campo
image
para cambiar la versión del servidor de la API dev1
av2
. La configuración YAML de la implementación se encuentra en el archivo enanthos-bm-edge-deployment/acm-config-sink/namespaces/pos/api-server.yaml
.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
En la consola de Google Cloud, ve a la página Config Management para verificar el estado de las especificaciones de la configuración. Verifica que el estado sea Sincronizado.
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.
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 tu cambio de aplicación se implementó, como se muestra en la siguiente captura de pantalla de ejemplo:
Es posible que tenga que 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.
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
yallow-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
, cnuc-6
) y un clúster independiente nuevo de Anthos alojado en 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.