Neste tutorial, apresentamos uma solução pronta para uso que usa clusters do Anthos em Bare Metal e o Anthos Config Management para implantar clusters do Kubernetes na borda em escala. Este tutorial é para operadores e desenvolvedores de plataformas. Você precisa conhecer as seguintes tecnologias e conceitos:
- Manuais do Ansible.
- Implantações de borda e seus desafios.
- Como trabalhar com um projeto do Google Cloud.
- Como implantar um aplicativo da Web em contêiner.
- Interfaces de linha de comando
gcloud
ekubectl
.
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. Os clusters do Anthos em bare metal e o Anthos Config Management oferecem gerenciamento e controle centralizados para o cluster de borda. O Anthos Config Management extrai dinamicamente novas configurações do GitHub e aplica essas políticas e configurações aos seus clusters.
Arquitetura de implantação na borda
Uma implantação de borda de varejo é uma boa maneira de ilustrar a arquitetura usada em um cluster típico do Anthos na implantação 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 os clusters do Anthos em bare metal atendam 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.
O diagrama a seguir mostra um cluster do Anthos em implantação bare metal que usa o perfil de borda em um armazenamento 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.
Os clusters do Anthos em bare metal estão sendo executados dentro de 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 um cluster do Anthos em implantação bare metal:
- O componente marcado como MetalLB é o balanceador de carga em pacote implantado com clusters do Anthos em Bare Metal.
- O componente Anthos Config Management 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 Anthos Config Management e a diferente nomenclatura, consulte a documentação do Anthos Config Management.
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. Clusters do Anthos em implantações bare metal 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 Anthos Config Management dentro do cluster bare metal do Anthos em execução nos dispositivos.
Outro componente essencial representado como parte do cluster é o Anthos VM Runtime. Com o Anthos VM Runtime, é possível executar cargas de trabalho atuais baseadas em VM no cluster sem a necessidade de conteinerização. A documentação do Anthos VM Runtime explica como ativá-la 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 nos clusters do Anthos em implantação bare metal alcancem esses dispositivos.
Na próxima seção, você verá a emulação dessa implantação de loja de varejo no Google Cloud usando VMs do Compute Engine. Essa emulação é o que você usa no tutorial a seguir para testar os clusters do Anthos em Bare Metal.
Implantação de borda emulada no 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 simples de carga de trabalho de aplicativo de amostra para uso neste tutorial. Você acessa o aplicativo do ponto de venda dentro do cluster usando um navegador da Web como um quiosque.
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. Em nosso ambiente emulado no Google Cloud, essas VMs são conectadas entre si pela rede padrão de nuvem privada virtual (VPC) no projeto do Google Cloud.
Em um cluster típico do Anthos em instalação bare metal, é possível configurar seus próprios balanceadores de carga. No entanto, neste tutorial, você não configurou um balanceador de carga externo. Em vez disso, use o balanceador de carga MetalLB empacotado instalado com clusters do Anthos em Bare Metal. 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 inclui o Anthos no cluster bare metal e um proxy reverso. O cluster é representado pelo retângulo "clusters do Anthos em bare metal". Esse retângulo representando o cluster inclui outro retângulo marcado como "Kubernetes namespace (pos)". Isso representa 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 do Anthos. 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 do Anthos 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 as VMs do Google Cloud Compute Engine. Em um local de borda real, isso pode ser feito com a configuração adequada de rede.
Objetivos
- Use as VMs do Compute Engine para emular uma infraestrutura bare metal executada em um local de borda.
- Criar um cluster bare metal do Anthos na infraestrutura de borda emulada.
- Conectar e registrar o cluster no Google Cloud.
- Implante uma carga de trabalho de aplicativo de ponto de venda de amostra no cluster do Anthos.
- Use o console do Google Cloud para verificar e monitorar o aplicativo de ponto de venda que opera no local de borda.
- Use o Anthos Config Management para atualizar o aplicativo de ponto de venda que é executado no cluster do Anthos.
Antes de começar
No Console do Google Cloud, na página do seletor de projetos, selecione ou crie um projeto do Google Cloud.
Verifique se o faturamento está ativado para seu projeto do Cloud. Saiba como verificar se o faturamento está ativado em um projeto.
Instale e inicialize o Google Cloud CLI.
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 Anthos Config Management.
Clone esse repositório na sua própria conta do GitHub antes de continuar com as etapas a seguir.
Caso ainda não tenha um, crie uma conta no GitHub.
Crie um token de acesso pessoal para usar na configuração do Anthos Config Management. Isso é necessário para que os componentes do Anthos Config Management no cluster sejam autenticados com sua conta do GitHub ao tentar sincronizar novas alterações.
- Selecione somente o escopo
public_repo
. - Salve o token de acesso criado em um local seguro para uso posterior.
- Selecione somente o escopo
Copie o repositório
anthos-samples
para sua própria conta do GitHub:- Acesse o repositório anthos-samples.
- Clique no ícone Fork no canto superior direito da página.
- Clique na conta de usuário do GitHub para que você quer bifurcar o repositório. Você será redirecionado automaticamente para a página com sua versão bifurcada do repositório anthos-samples.
Abra um terminal no ambiente local.
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:
- Docker
- Ferramenta de interface de linha de comando envsubst (geralmente pré-instalada no Linux e em outros sistemas operacionais semelhantes ao Unix)
Execute todos os comandos do tutorial na estação de trabalho configurada nesta seção.
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.
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}"
Na estação de trabalho, crie a conta de serviço do Google Cloud para as instâncias do Compute Engine. Esse script cria o arquivo de chave JSON para a nova conta de serviço do Google 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
Uma parte do script está visível abaixo. Clique no link
View on GitHub
para ver o script completo.
Provisionar as instâncias do Compute Engine
Nesta seção, você cria as VMs do Compute Engine em que os clusters do Anthos em bare metal serão instalados. Você também verifica a conectividade com essas VMs antes de prosseguir para a seção de instalação.
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
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
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 arquivotemplates/envrc-template.sh
. As linhas atualizadas foram destacadas:Crie instâncias do Compute Engine em que o Anthos em bare metal está instalado.
./scripts/cloud/create-cloud-gce-baseline.sh -c "$GCE_COUNT" | \ tee ./build-artifacts/gce-info
Instale clusters do Anthos em bare metal com Ansible
O script usado neste guia cria clusters do Anthos em bare metal 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 do Anthos em bare metal com 3
instâncias 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
enomos
. - Instala o Anthos em bare metal nas instâncias configuradas do Compute Engine.
- Cria um cluster de usuário do Anthos em bare metal chamado
cnuc-1
. - Registra o cluster
cnuc-1
no Google Cloud. - Instala o Anthos Config Management no cluster
cnuc-1
. - Configura o Anthos Config Management para sincronizar com as configurações de cluster
localizadas em
anthos-bm-edge-deployment/acm-config-sink
no seu repositório bifurcado. - Gere o
Login token
do cluster.
Siga estas etapas para configurar e iniciar o processo de instalação:
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
Gere o arquivo de inventário do Ansible no modelo.
envsubst < templates/inventory-cloud-example.yaml > inventory/gcp.yaml
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)
De dentro do 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"}
No contêiner do Docker, execute o manual do Ansible para instalar clusters do Anthos em bare metal em instâncias do Compute Engine. Após a conclusão, você vai ver o
Login Token
do cluster 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 do Anthos em bare metal no console do Google Cloud
Depois que o playbook Ansible for concluído, um cluster independente do Anthos em bare metal será instalado nas VMs do Compute Engine. Esse cluster também é registrado no Google Cloud pelo agente do Connect. No entanto, para ver detalhes sobre esse cluster, faça login no cluster pelo Console do Google Cloud. Para fazer login no cluster do Anthos, siga as etapas a seguir.
Copie o token da saída do manual do Ansible na seção anterior.
No console do Google Cloud, acesse a página Clusters do Kubernetes e use o token copiado para fazer login no cluster
cnuc-1
.Acesse a página de clusters do Kubernetes.
- Na lista de clusters, clique em
cnuc-1
e, em seguida, clique em Fazer login.
Ações
ao lado do cluster - Selecione Token e cole o token copiado.
- Clique em Login.
- Na lista de clusters, clique em
No console do Google Cloud, acesse a página Gerenciamento de configuração para verificar o Status das especificações de configuração. Verifique se o status é Sincronizado. Um status de Sincronizado indica que o Anthos Config Management sincronizou suas configurações do GitHub com o cluster implantado,
cnuc-1
.Acesse a página Gerenciamento de configurações
Configurar um proxy para tráfego externo
O cluster bare metal do Anthos 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 meio de um endereço IP de nuvem privada
virtual (VPC). Para rotear o tráfego que chega por meio do 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 do ponto de venda por meio do IP externo do host do 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 reiniciar o nginx.
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
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 de balanceador de carga do Kubernetes:
ABM_INTERNAL_IP=$(kubectl get services api-server-lb -n pos | awk '{print $4}' | tail -n 1)
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"
Reinicie o NGINX para garantir que a nova configuração seja aplicada:
sudo systemctl restart nginx
Confira o status do servidor NGINX para informar "ativo (em execução)":
sudo systemctl status nginx
Quando o NGINX estiver em execução, ele produzirá uma saída como a seguinte:
● 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: .... ... ...
Saia da sessão SSH para a instância de administrador.
exit
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 do Anthos. Para acessar o aplicativo de ponto de venda de amostra, siga as etapas abaixo.
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
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:
Usar o Anthos Config Management 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 Anthos Config Management 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.
Na estação de trabalho, atualize o campo
image
para alterar a versão do servidor de API dev1
parav2
. A configuração YAML da implantação está no arquivo emanthos-bm-edge-deployment/acm-config-sink/namespaces/pos/api-server.yaml
.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
No console do Google Cloud, acesse a página Gerenciamento de configuração para verificar o status das especificações de configuração. Verifique se o status é Sincronizado.
No console do Google Cloud, acesse a página Cargas de trabalho do Kubernetes Engine para verificar se a implantação está atualizada.
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:
Talvez seja necessário fazer uma atualização forçada da guia do navegador para ver as alterações.
Limpar
Para evitar cobranças desnecessárias do Google Cloud, exclua os recursos usados neste guia ao 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.
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
eallow-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 de usuário do Anthos em bare metal 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.