Implantar clusters na borda

Neste tutorial, apresentamos uma solução pronta para uso que usa o Google Distributed Cloud (somente software) em bare metal e o Config Sync para implantar clusters do Kubernetes na borda em escala. Este tutorial é para operadores e desenvolvedores de plataformas. Antes de ler este documento, confira se você conhece as seguintes tecnologias e conceitos:

Neste tutorial, você usará máquinas virtuais (VMs) do Compute Engine para emular os nós implantados na borda e um aplicativo de ponto de venda de amostra como a carga de trabalho de borda. O software do Google Distributed Cloud e o Config Sync oferecem gerenciamento e controle centralizados para o cluster de borda. O Config Sync extrai novas configurações do GitHub de forma dinâmica e aplica essas políticas e configurações aos clusters.

Arquitetura de implantação na borda

Uma implantação de borda de varejo é uma boa maneira de ilustrar a arquitetura usada em uma implantação típica de cluster bare metal.

Uma loja física é o ponto de interação mais próximo entre uma unidade empresarial e o consumidor. Os sistemas de software das lojas precisam executar cargas de trabalho, receber atualizações oportunas e relatar métricas essenciais de isolamento do sistema de gerenciamento central da empresa. Além disso, esses sistemas de software precisam ser projetados para que possam ser expandidos para outros locais da loja no futuro. Embora qualquer implantação de cluster bare metal atenda a todos esses requisitos para sistemas de software de loja, o perfil de borda permite um caso de uso importante: implantações em ambientes com recursos de hardware limitados, como uma vitrine de loja de varejo.

O diagrama a seguir mostra uma implantação de cluster bare metal que usa o perfil de borda em uma loja de varejo:

Implantação que usa o perfil de borda em uma loja de varejo

O diagrama anterior mostra uma loja física típica de varejo. A loja tem dispositivos inteligentes como leitores de cartão, máquinas de ponto de venda, câmeras e impressoras. A loja também tem três dispositivos de hardware de computação física (com os rótulos Node 1, Node 2 e Node 3). Todos esses dispositivos estão conectados a um interruptor de rede central. Assim, os três dispositivos de computação estão conectados entre si por meio de uma rede da camada 2. Os dispositivos de computação conectados em rede formam a infraestrutura bare metal. O software do Google Distributed Cloud está sendo executado em cada um dos três dispositivos de computação. Esses dispositivos também têm armazenamento próprio em disco e são configurados para replicação de dados entre eles para alta disponibilidade.

O diagrama também mostra os seguintes componentes principais que fazem parte de uma implantação de cluster bare metal:

  • O componente marcado como MetalLB é o balanceador de carga em pacote.

  • O componente Config Sync permite sincronizar o estado do cluster com os repositórios de origem. É um complemento opcional altamente recomendado que requer instalação e configuração separadas. Para mais informações sobre como configurar o Config Sync e a nomenclatura diferente, consulte a documentação do Config Sync.

  • O repositório raiz e o repositório de namespace mostrados na parte superior do diagrama fora do local da loja representam dois repositórios de origem.

    As alterações no cluster são enviadas para esses repositórios de origem central. As implantações de cluster em vários locais de borda extraem atualizações dos repositórios de origem. Esse comportamento é representado pelas setas que conectam os dois repositórios no diagrama aos componentes do Config Sync dentro do cluster em execução nos dispositivos.

  • Outro componente importante representado como parte do cluster é o ambiente de execução de VM no GDC. O ambiente de execução de VM no GDC permite executar cargas de trabalho atuais baseadas em VM no cluster sem a necessidade de conteinerização. A documentação do ambiente de execução de VMs no GDC explica como ativar e implantar as cargas de trabalho da VM no cluster.

  • O componente marcado como Aplicativo indica um software implantado no cluster pela loja de varejo. O aplicativo de ponto de venda visto nos quiosques de uma loja pode ser um exemplo desse tipo de aplicativo.

As caixas na parte inferior do diagrama representam os vários dispositivos (como quiosques, tablets ou câmeras) dentro de uma loja de varejo e todos estão conectados a um chave de rede central. A rede local dentro da loja permite que os aplicativos em execução no cluster alcancem esses dispositivos.

Na próxima seção, você vai conferir a emulação dessa implantação de loja de varejo no Google Cloud usando VMs do Compute Engine. Essa emulação é a usada no tutorial a seguir para testar um cluster bare metal.

Implantação de borda emulada em Google Cloud

O diagrama a seguir é uma representação de tudo que você configurou no Google Cloud neste tutorial. Esse diagrama se relaciona com o diagrama da loja de varejo da seção anterior. Essa implantação representa um local de borda emulado em que o aplicativo de ponto de venda está implantado. A arquitetura também mostra um exemplo de carga de trabalho de aplicativo de ponto de venda que você usa neste tutorial. Você acessa o aplicativo do ponto de venda dentro do cluster usando um navegador da Web como um quiosque.

Arquitetura do aplicativo de ponto de venda e como ele é implantado em um cluster em execução nas VMs do Compute Engine

As três máquinas virtuais (VMs) do Compute Engine no diagrama anterior representam o hardware ou os nós físicos em um local de borda típico. Esse hardware seria conectado a interruptores de rede para compor a infraestrutura bare metal. No nosso ambiente emulado em Google Cloud, essas VMs são conectadas entre si pela rede padrão de nuvem privada virtual (VPC) no projeto do Google Cloud.

Em uma instalação típica de cluster bare metal, é possível configurar seus próprios balanceadores de carga. No entanto, neste tutorial, você não vai configurar um balanceador de carga externo. Em vez disso, use o balanceador de carga MetalLB em pacote. O balanceador de carga MetalLB empacotado exige conectividade de rede de camada 2 entre os nós. Portanto, a conectividade da camada 2 entre as VMs do Compute Engine é ativada criando uma rede de sobreposição VxLAN sobre a rede padrão de nuvem privada virtual (VPC).

No retângulo denominado "Rede L2 overlay (VxLAN)", os componentes do software em execução dentro das três VMs do Compute Engine são mostrados. Esse retângulo da VxLAN inclui o deployment do cluster, que contém um namespace do Kubernetes dentro do cluster. Todos os componentes dentro desse namespace do Kubernetes formam o aplicativo de ponto de venda implantado no cluster. O aplicativo de ponto de venda tem três microsserviços: servidor de API, inventário e pagamentos. Todos esses componentes representam um "application" mostrado no diagrama da arquitetura de lançamento anterior do Edge.

O balanceador de carga MetalLB agrupado do cluster não pode ser acessado diretamente de fora das VMs. O diagrama mostra um proxy reverso do NGINX sendo configurado para ser executado dentro das VMs, com o objetivo de encaminhar o tráfego que chega às VMs do Compute Engine para o balanceador de carga. Essa é apenas uma solução alternativa para os fins deste tutorial em que os nós de borda são emulados usando Google Cloud VMs do Compute Engine. Em um local de borda real, isso pode ser feito com a configuração adequada de rede.

Objetivos

  1. Use as VMs do Compute Engine para emular uma infraestrutura bare metal executada em um local de borda.
  2. Use o Google Distributed Cloud para criar um cluster na infraestrutura de borda emulada.
  3. Conecte e registre o cluster com Google Cloud.
  4. Implante uma carga de trabalho de aplicativo de ponto de venda de amostra no cluster.
  5. Use o console do Google Cloud para verificar e monitorar o aplicativo de ponto de venda que opera no local de borda.
  6. Use o Config Sync para atualizar o aplicativo de ponto de venda que é executado no cluster.

Antes de começar

  1. No Console do Google Cloud, na página do seletor de projetos, selecione ou crie um projeto do Google Cloud.

    Acesse a seleção de projetos

  2. Verifique se o faturamento está ativado para seu projeto do Cloud. Saiba como verificar se o faturamento está ativado em um projeto.

  3. Instale e inicialize a CLI do Google Cloud.

Copie e clone o repositório anthos-samples

Todos os scripts usados neste tutorial são armazenados no repositório anthos-samples. A estrutura de pastas em /anthos-bm-edge-deployment/acm-config-sink é organizada de acordo com o que é esperado pelo Config Sync. Clone esse repositório na sua própria conta do GitHub antes de continuar com as etapas a seguir.

  1. Caso ainda não tenha um, crie uma conta no GitHub.

  2. Crie um token de acesso pessoal para usar na configuração do Config Sync. Isso é necessário para que os componentes da sincronização de configuração no cluster sejam autenticados com sua conta do GitHub ao tentar sincronizar novas alterações.

    1. Selecione somente o escopo public_repo.
    2. Salve o token de acesso criado em um local seguro para uso posterior.

  3. Copie o repositório anthos-samples para sua própria conta do GitHub:

    1. Acesse o repositório anthos-samples.
    2. Clique no ícone Bifurcar no canto superior direito da página.
    3. Clique na conta de usuário do GitHub para a qual você quer bifurcar o repositório. Você será redirecionado automaticamente para a página com a versão bifurcada do repositório anthos-samples.

  4. Abra um terminal no ambiente local.

  5. Clone o repositório bifurcado executando o seguinte comando, em que GITHUB_USERNAME é o nome de usuário da sua conta do GitHub:

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

Configurar o ambiente da estação de trabalho

Para concluir a implantação de borda descrita neste documento, você precisa de uma estação de trabalho com acesso à Internet e às seguintes ferramentas instaladas:

Execute todos os comandos do tutorial na estação de trabalho configurada nesta seção.

  1. Na estação de trabalho, inicialize as variáveis de ambiente em uma nova instância do 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"

    Substitua os seguintes valores:

    • PROJECT_ID: é seu ID do projeto no Google Cloud.
    • GITHUB_USERNAME: seu nome de usuário do GitHub.
    • ACCESS_TOKEN: o token de acesso pessoal que você criou para o repositório do GitHub.

    Mantenha os valores padrão das outras variáveis de ambiente. Eles são explicados nas seções a seguir.

  2. Na estação de trabalho, inicialize a 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. Na estação de trabalho, crie a conta de serviço Google Cloud para as instâncias do Compute Engine. Esse script cria o arquivo de chave JSON para a nova conta de serviço em <REPO_ROOT>/anthos-bm-edge-deployment/build-artifacts/consumer-edge-gsa.json. Ele também configura o keyring e a chave do Cloud Key Management Service para a criptografia de chaves privadas SSH.

    ./scripts/create-primary-gsa.sh

    O exemplo a seguir é apenas uma parte do script. Para conferir o script inteiro, clique em Ver no 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
# ...

Provisionar as instâncias do Compute Engine

Nesta seção, você cria as VMs do Compute Engine em que o Google Distributed Cloud somente de software será instalado. Você também verifica a conectividade com essas VMs antes de prosseguir para a seção de instalação.

  1. Na estação de trabalho, crie chaves SSH usadas para comunicação entre as instâncias do Compute Engine:

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

  2. Criptografe a chave privada SSH usando o 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. Gere o arquivo de configuração do ambiente .envrc e use o comando source. Depois de criado, confira no arquivo .envrc se as variáveis de ambiente foram substituídas pelos valores corretos.

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

    Veja a seguir um exemplo de arquivo .envrc gerado pela substituição das variáveis de ambiente no arquivo templates/envrc-template.sh. As linhas atualizadas foram destacadas: 

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

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

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

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

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

  4. Crie instâncias do Compute Engine:

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

Instalar um cluster bare metal com o Ansible

O script usado neste guia cria clusters em grupos de três instâncias do Compute Engine. O número de clusters criados é controlado pela variável de ambiente GCE_COUNT. Por exemplo, você define a variável de ambiente GCE_COUNT como 6 para criar dois clusters com 3 instâncias de VM cada. Por padrão, a variável de ambiente GCE_COUNT é definida como 3. Portanto, neste guia, será criado um cluster com 3 instâncias do Compute Engine. As instâncias são nomeadas com um prefixo cnuc- seguido por um número. A primeira instância de VM de cada cluster funciona como a estação de trabalho do administrador a partir da qual a instalação é acionada. O cluster também recebe o mesmo nome da VM da estação de trabalho do administrador (por exemplo, cnuc-1, cnuc-4, cnuc-7).

O playbook do Ansible faz o seguinte:

  • Configura as instâncias do Compute Engine com as ferramentas necessárias, como docker, bmctl, gcloud e nomos.
  • Instala um cluster bare metal nas instâncias configuradas do Compute Engine.
  • Cria um cluster autônomo chamado cnuc-1.
  • Registra o cluster cnuc-1 com Google Cloud.
  • Instala o Config Sync no cluster cnuc-1.
  • Configura o Config Sync para sincronizar com as configurações de cluster localizadas em anthos-bm-edge-deployment/acm-config-sink no repositório bifurcado.
  • Gere o Login token do cluster.

Siga estas etapas para configurar e iniciar o processo de instalação:

  1. Na estação de trabalho, crie a imagem do Docker usada na instalação. Essa imagem tem todas as ferramentas necessárias para o processo de instalação, como Ansible, Python e Google Cloud CLI.

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

    Se executado com êxito, o build produz uma saída como esta:

    ...
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. Gere o arquivo de inventário do Ansible no modelo:

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

  3. Execute o script de instalação que inicia um contêiner do Docker a partir da imagem criada anteriormente. O script usa internamente o Docker para gerar o contêiner com uma montagem de volume para o diretório de trabalho atual. Após a conclusão desse script, você precisa estar dentro do contêiner do Docker que foi criado. Acione a instalação do Ansible de dentro desse contêiner.

    ./install.sh

    Se executado com sucesso, o script produz uma saída como esta:

    ...
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. No contêiner do Docker, verifique o acesso às instâncias do Compute Engine:

    ./scripts/health-check.sh

    Se executado com sucesso, o script produz uma saída como esta:

    ...
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. No contêiner do Docker, execute o playbook do Ansible para instalar um cluster bare metal em instâncias do Compute Engine:

    Após a conclusão, você vai ver o Login Token do cluster impresso na tela.

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

    Se executada corretamente, a instalação vai produzir uma saída como esta:

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

Fazer login no cluster no console do Google Cloud

Depois que o playbook Ansible for concluído, um cluster independente será instalado nas VMs do Compute Engine. Esse cluster também é registrado em Google Cloud, usando o agente do Connect. No entanto, para conferir detalhes sobre esse cluster, faça login nele pelo console do Google Cloud.

Para fazer login no cluster, siga estas etapas:

  1. Copie o token da saída do manual do Ansible na seção anterior.

  2. No console do Google Cloud, acesse a página Clusters do Kubernetes e use o token copiado para fazer login no cluster cnuc-1.

    Acessar a página de clusters do Kubernetes

    1. Na lista de clusters, clique em Ações ao lado do cluster cnuc-1 e, em seguida, clique em Fazer login.
    2. Selecione Token e cole o token copiado.
    3. Clique em Login.
  3. No console do Google Cloud, acesse a página Configuração na seção Recursos.

    Acessar a configuração

    4. Na guia Pacotes, verifique a coluna Status da sincronização na tabela de clusters. Verifique se o status é Sincronizado. Um status de Sincronizado indica que o Config Sync sincronizou suas configurações do GitHub com o cluster implantado, cnuc-1.

s

Configurar um proxy para tráfego externo

O cluster instalado nas etapas anteriores usa um balanceador de carga em pacote chamado MetalLB. Esse serviço do balanceador de carga só pode ser acessado por um endereço IP de nuvem privada virtual (VPC). Para rotear o tráfego que chega pelo IP externo para o balanceador de carga em pacote, configure um serviço de proxy reverso no host de administrador (cnuc-1). Esse serviço de proxy reverso permite acessar o servidor da API do aplicativo de ponto de venda pelo IP externo do host de administrador (cnuc-1).

Os scripts de instalação nas etapas anteriores instalaram o NGINX nos hosts de administrador com um arquivo de configuração de amostra. Atualizamos esse arquivo para usar o endereço IP do serviço do balanceador de carga e reiniciamos o NGINX.

  1. Na estação de trabalho, use o SSH para fazer login na estação de trabalho de administrador:

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

  2. Na estação de trabalho do administrador, configure o proxy reverso do NGINX para encaminhar o tráfego para o serviço do balanceador de carga do servidor de API. Consiga o endereço IP do serviço do tipo balanceador de carga do Kubernetes:

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

  3. Atualize o arquivo de configuração do modelo com o endereço IP buscado:

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

  4. Reinicie o NGINX para garantir que a nova configuração seja aplicada:

    sudo systemctl restart nginx

  5. Confira o status do servidor NGINX para informar "ativo (em execução)":

    sudo systemctl status nginx

    Quando o NGINX está em execução, ele produz uma saída como o exemplo a seguir:

    ● 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. Saia da sessão SSH para a instância de administrador.

    exit

  7. Saia da sessão do shell para o contêiner do Docker. Ao sair da instância de administrador, você ainda está dentro do contêiner do Docker usado para a instalação:

    exit

Acessar o aplicativo de ponto de venda

Com a configuração do proxy externo, é possível acessar o aplicativo em execução no cluster. Para acessar o aplicativo de ponto de venda de amostra, siga as etapas abaixo.

  1. Na estação de trabalho, acesse o endereço IP externo da instância do Compute Engine para administrador e acesse a IU do aplicativo do ponto de venda:

    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}"

    Quando os scripts são executados com sucesso, eles produzem uma saída como esta:

    Point the browser to: 34.134.194.84:8082

  2. Abra o navegador da Web e navegue até o endereço IP mostrado na saída do comando anterior. É possível acessar e testar o aplicativo de ponto de venda de amostra, conforme mostrado na captura de tela de exemplo a seguir:

    Versão 1 do aplicativo de ponto de venda implantado

Usar o Config Sync para atualizar o servidor da API

Para atualizar o aplicativo de amostra para uma versão mais recente, atualize os arquivos de configuração no repositório raiz. O Config Sync detecta as atualizações e faz as alterações automaticamente no cluster. Neste exemplo, o repositório raiz é o anthos-samples que você clonou no início deste guia. Para ver como o aplicativo de ponto de venda de amostra pode passar por uma implantação de upgrade para uma versão mais recente, conclua as etapas a seguir.

  1. Na estação de trabalho, atualize o campo image para alterar a versão do servidor de API de v1 para v2. A configuração YAML da implantação está no arquivo em 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. Adicione, confirme e envie as alterações para seu repositório bifurcado:

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

  3. No console do Google Cloud, acesse a página Config Sync para verificar o Status da especificação de configuração. Verifique se o status é Sincronizado.

    Acessar a página do Config Sync

  4. No console do Google Cloud, acesse a página Cargas de trabalho do Kubernetes Engine para verificar se a implantação está atualizada.

    Acessar a página Cargas de trabalho do Kubernetes Engine

  5. Quando o status da Implantação for OK, aponte o navegador para o endereço IP da seção anterior a fim de visualizar o aplicativo de ponto de venda. A versão no título mostra "V2", indicando que a mudança do aplicativo foi implantada, conforme mostrado no exemplo de captura de tela a seguir:

    Versão 2 do aplicativo de ponto de venda implantado

    Talvez seja necessário fazer uma atualização forçada da guia do navegador para ver as alterações.

Limpar

Para evitar cobranças Google Cloud desnecessárias, exclua os recursos usados neste guia quando terminar. É possível excluir esses recursos manualmente ou excluir o projeto do Google Cloud, o que também elimina todos os recursos. Além disso, convém limpar as alterações feitas na estação de trabalho local:

Estação de trabalho local

Os arquivos a seguir precisam ser atualizados para limpar as alterações feitas pelos scripts de instalação.

  • Remova os endereços IP da VM do Compute Engine adicionados ao arquivo /etc/hosts.
  • Remova a configuração SSH de cnuc-* no arquivo ~/.ssh/config.
  • Remova as impressões digitais da VM do Compute Engine do arquivo ~/.ssh/known_hosts.

Excluir projeto

Se você criou um projeto dedicado para este procedimento, exclua o projeto do Google Cloud pelo console do Google Cloud.

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

    Go to Manage resources

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

    • Manual

    Se você usou um projeto atual para este procedimento, faça o seguinte:

    • Cancele o registro de todos os clusters do Kubernetes cujos nomes tenham o prefixo cnuc-.
    • Exclua todas as VMs do Compute Engine cujos nomes tenham o prefixo cnuc-.
    • Exclua o bucket do Cloud Storage cujo nome tenha o prefixo abm-edge-boot.
    • Exclua as regras de firewall allow-pod-ingress e allow-pod-egress.
    • Exclua o secret do Secret Manager.install-pub-key

    A seguir

    É possível expandir ainda mais este guia adicionando outro local de borda. Definir a variável de ambiente GCE_COUNT como 6 e executar novamente as mesmas etapas das seções anteriores cria três novas instâncias do Compute Engine (cnuc-4, cnuc-5, cnuc-6) e um novo cluster independente chamado cnuc-4.

    Também é possível atualizar as configurações de cluster no repositório bifurcado para aplicar seletivamente versões diferentes do aplicativo de ponto de venda aos dois clusters, cnuc-1 e cnuc-4, usando ClusterSelectors.

    Para mais detalhes sobre as etapas individuais deste guia e os scripts envolvidos, consulte o repositório anthos-samples.