Esta página foi traduzida pela API Cloud Translation.

Implemente clusters na periferia

Este tutorial apresenta uma solução pronta a usar que usa o Google Distributed Cloud (apenas software) em hardware não processado e o Config Sync para implementar clusters do Kubernetes na periferia em grande escala. Este tutorial destina-se a operadores e programadores de plataformas. Antes de ler este documento, certifique-se de que conhece as seguintes tecnologias e conceitos:

Guias interativos do Ansible.
Implementações de limite e os respetivos desafios.
Como trabalhar com um Google Cloud projeto.
Implementar uma aplicação Web contentorizada.
gcloud e kubectl.

Neste tutorial, vai usar máquinas virtuais (VMs) do Compute Engine para emular nós implementados na periferia e uma aplicação de ponto de venda de exemplo como carga de trabalho de periferia. O software apenas do Google Distributed Cloud e o Config Sync oferecem gestão e controlo centralizados para o seu cluster de periferia. O Config Sync extrai dinamicamente novas configurações do GitHub e aplica estas políticas e configurações aos seus clusters.

Arquitetura de implementação de proximidade

Uma implementação de limite de retalho é uma boa forma de ilustrar a arquitetura usada numa implementação de cluster de metal puro típica.

Uma loja de retalho física é o ponto de interação mais próximo entre uma unidade de negócio empresarial e o consumidor. Os sistemas de software nas lojas têm de executar as respetivas cargas de trabalho, receber atualizações atempadas e comunicar métricas críticas em isolamento do sistema de gestão central da empresa. Além disso, estes sistemas de software têm de ser concebidos de forma a poderem ser expandidos para mais localizações de lojas no futuro. Embora qualquer implementação de cluster bare metal satisfaça todos estes requisitos para sistemas de software de lojas, o perfil de limite permite um exemplo de utilização importante: implementações em ambientes com recursos de hardware limitados, como a montra de uma loja de retalho.

O diagrama seguinte mostra uma implementação de cluster bare metal que usa o perfil de limite numa loja de retalho:

Implementação que usa o perfil de limite numa loja de retalho

O diagrama anterior mostra uma loja de retalho física típica. A loja tem dispositivos inteligentes, como leitores de cartões, máquinas de ponto de venda, câmaras e impressoras. A loja também tem três dispositivos de hardware de computação físicos (etiquetados como Node 1, Node 2 e Node 3). Todos estes dispositivos estão ligados a um comutador de rede central. Assim, os três dispositivos informáticos estão ligados entre si através de uma rede de camada 2. Os dispositivos de computação interligados em rede constituem a infraestrutura de metal puro. O software Google Distributed Cloud está a ser executado em cada um dos três dispositivos de computação. Estes dispositivos também têm o seu próprio armazenamento em disco e estão configurados para a replicação de dados entre eles para uma elevada disponibilidade.

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

O componente marcado como MetalLB é o balanceador de carga integrado.
O componente Config Sync permite sincronizar o estado do cluster com repositórios de origem. É um suplemento 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 de raiz e o repositório de espaço de nomes apresentados na parte superior do diagrama fora da localização da loja representam dois repositórios de origem.

As alterações ao cluster são enviadas para estes repositórios de origem central. As implementações de clusters em várias localizações periféricas extraem atualizações dos repositórios de origem. Este comportamento é representado pelas setas que ligam os dois repositórios no diagrama aos componentes do Config Sync no cluster em execução nos dispositivos.
Outro componente essencial representado como parte do cluster é o tempo de execução da VM no GDC. O tempo de execução de VMs no GDC permite a execução de cargas de trabalho baseadas em VMs existentes no cluster sem necessidade de contentorização. A documentação do tempo de execução de VMs no GDC explica como ativá-lo e implementar as suas cargas de trabalho de VMs no cluster.
O componente marcado como Aplicação denota software implementado no cluster pela loja de retalho. A aplicação de ponto de venda vista nos quiosques de uma loja de retalho pode ser um exemplo de uma aplicação deste tipo.

As caixas na parte inferior do diagrama representam os vários dispositivos (como quiosques, tablets ou câmaras) numa loja de retalho, todos ligados a um comutador de rede central. A rede local no interior da loja permite que as aplicações em execução no cluster alcancem estes dispositivos.

Na secção seguinte, vê a emulação desta implementação de loja de retalho Google Cloud com VMs do Compute Engine. Esta emulação é o que usa no tutorial que se segue para experimentar um cluster bare metal.

Implementação de limites emulada em Google Cloud

O diagrama seguinte é uma representação de tudo o que configurou Google Cloud neste tutorial. Este diagrama está correlacionado com o diagrama da loja de retalho da secção anterior. Esta implementação representa uma localização de limite emulada na qual a aplicação de ponto de venda está implementada. A arquitetura também mostra uma carga de trabalho de exemplo de aplicação de ponto de venda que usa neste tutorial. Acede à aplicação de ponto de venda no cluster através de um navegador de Internet como um quiosque.

Arquitetura da aplicação de ponto de venda e como é implementada num cluster executado em VMs do Compute Engine

As três máquinas virtuais (VMs) do Compute Engine no diagrama anterior representam o hardware físico (ou os nós) numa localização periférica típica. Este hardware seria ligado a comutadores de rede para formar a infraestrutura de metal exposto. No nosso ambiente emulado, Google Cloud, estas VMs estão ligadas entre si através da rede nuvem virtual privada (VPC) predefinida no projeto Google Cloud .

Numa instalação típica de cluster bare metal, pode configurar os seus próprios balanceadores de carga. No entanto, para este tutorial, não configura um balanceador de carga externo. Em alternativa, use o balanceador de carga MetalLB incluído. O balanceador de carga MetalLB incluído requer conetividade de rede da camada 2 entre os nós. Assim, a conetividade da camada 2 entre as VMs do Compute Engine é ativada através da criação de uma rede de sobreposição VxLAN sobre a rede da nuvem virtual privada (VPC) predefinida.

Dentro do retângulo etiquetado como "Rede de sobreposição L2 (VxLAN)", são apresentados os componentes de software em execução nas três VMs do Compute Engine. Este retângulo VxLAN inclui a implementação do cluster, que contém um espaço de nomes do Kubernetes no interior do cluster. Todos os componentes neste espaço de nomes do Kubernetes constituem a aplicação de ponto de venda implementada no cluster. A aplicação de ponto de venda tem três microsserviços: servidor de API, inventário e pagamentos. Todos estes componentes representam em conjunto uma "aplicação" apresentada no diagrama de arquitetura de implementação do Edge anterior.

Não é possível aceder diretamente ao equilibrador de carga MetalLB incluído do cluster a partir do exterior das VMs. O diagrama mostra um proxy inverso do NGINX a ser configurado para ser executado nas VMs para encaminhar o tráfego que entra nas VMs do Compute Engine para o equilibrador de carga. Esta é apenas uma solução alternativa para os fins deste tutorial, em que os nós periféricos são emulados através de VMs do Compute Engine. Google CloudNuma localização periférica real, isto pode ser feito com a configuração de rede adequada.

Objetivos

Use VMs do Compute Engine para emular uma infraestrutura bare metal que é executada numa localização periférica.
Use o Google Distributed Cloud para criar um cluster na infraestrutura de limite emulada.
Associe e registe o cluster com o Google Cloud.
Implemente uma carga de trabalho de aplicação de ponto de venda de exemplo no cluster.
Use a Google Cloud consola para validar e monitorizar a aplicação de ponto de venda que opera na localização periférica.
Use a Sincronização de configuração para atualizar a aplicação de ponto de venda que é executada no cluster.

Antes de começar

Na Google Cloud consola, na página do seletor de projetos, selecione ou crie um Google Cloud projeto.

Nota: se não planeia manter os recursos que criar neste procedimento, crie um projeto em vez de selecionar um projeto existente. Depois de concluir estes passos, pode eliminar o projeto, removendo todos os recursos associados ao projeto.

Aceder à seleção de projetos
Certifique-se de que a faturação está ativada para o seu projeto do Google Cloud. Saiba como verificar se a faturação está ativada num projeto.
Instale e inicialize a CLI Google Cloud.

Crie um fork e clone o repositório anthos-samples

Todos os scripts usados neste tutorial estão armazenados no repositório anthos-samples. A estrutura de pastas em /anthos-bm-edge-deployment/acm-config-sink está organizada de acordo com o que é esperado pelo Config Sync. Clone este repositório para a sua conta do GitHub antes de continuar com os passos seguintes.

Se ainda não tiver uma, crie uma conta no GitHub.
Crie um token de acesso pessoal para usar na configuração do Config Sync. Isto é necessário para que os componentes do Config Sync no cluster sejam autenticados com a sua conta do GitHub quando tenta sincronizar novas alterações.
1. Selecione apenas o âmbito public_repo.
2. Guarde o token de acesso que criou num local seguro para usar mais tarde.
Crie um fork do repositório anthos-samples para a sua própria conta do GitHub:
1. Aceda ao repositório anthos-samples.
2. Clique no ícone Fork no canto superior direito da página.
3. Clique na conta de utilizador do GitHub para a qual quer criar um fork do repositório. O redirecionamento para a página com a versão ramificada do repositório anthos-samples é automático.
Abra um terminal no seu ambiente local.
Clone o repositório bifurcado executando o seguinte comando, em que GITHUB_USERNAME é o nome de utilizador da sua conta do GitHub:
```
git clone https://github.com/GITHUB_USERNAME/anthos-samples
cd anthos-samples/anthos-bm-edge-deployment
```
Nota: o repositório de origem desta solução e a sua ramificação desse repositório são repositórios públicos. Este documento mostra a utilização de um token de acesso para imitar um exemplo de utilização real com um repositório privado.

Configure o ambiente da estação de trabalho

Para concluir a implementação de limite descrita neste documento, precisa de uma estação de trabalho com acesso à Internet e as seguintes ferramentas instaladas:

Docker
Ferramenta de interface de linhas de comando envsubst (normalmente pré-instalada no Linux e noutros SOs do tipo Unix)

Execute todos os comandos no tutorial na estação de trabalho que configurar nesta secção.

Na estação de trabalho, inicialize as variáveis de ambiente numa nova instância da 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: o ID do seu Google Cloud projeto.
GITHUB_USERNAME: o seu nome de utilizador do GitHub.
ACCESS_TOKEN: o token de acesso pessoal que criou para o seu repositório do GitHub.

Mantenha os valores predefinidos para as outras variáveis de ambiente. São explicados nas secções que se seguem.

Na sua estação de trabalho, inicialize a CLI do Google Cloud:

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 Google Cloud conta de serviço para as instâncias do Compute Engine. Este script cria o ficheiro de chave JSON para a nova conta de serviço em <REPO_ROOT>/anthos-bm-edge-deployment/build-artifacts/consumer-edge-gsa.json. Também configura o conjunto de chaves e a chave do Cloud Key Management Service para a encriptação de chaves privadas de SSH.

./scripts/create-primary-gsa.sh

O exemplo seguinte é apenas uma parte do guião. Para ver o script completo, 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
# ...

Aprovisione as instâncias do Compute Engine

Nesta secção, cria as VMs do Compute Engine onde o software do Google Distributed Cloud será instalado. Também valida a conetividade a estas VMs antes de avançar para a secção de instalação.

Na sua estação de trabalho, crie chaves SSH que são usadas para a comunicação entre as instâncias do Compute Engine:
```
ssh-keygen -f ./build-artifacts/consumer-edge-machine
```

Encriptar a chave privada SSH com 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 ficheiro de configuração do ambiente .envrc e obtenha a respetiva origem. Depois de criar o ficheiro .envrc, inspecione-o para garantir que as variáveis de ambiente foram substituídas pelos valores corretos.

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

Segue-se um exemplo de um ficheiro .envrc gerado através da substituição das variáveis de ambiente no ficheiro templates/envrc-template.sh. Repare que as linhas que foram atualizadas estão realçadas:

# 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

Criar instâncias do Compute Engine:

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

Instale 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, define a variável de ambiente GCE_COUNT como 6 para criar dois clusters com 3 instâncias de VM cada. Por predefinição, a variável de ambiente GCE_COUNT está definida como 3. Assim, neste guia, é criado um cluster com instâncias do 3Compute Engine. As instâncias de VM têm um prefixo cnuc- seguido de um número. A primeira instância de VM de cada cluster atua como a estação de trabalho de administração a partir da qual a instalação é acionada. O cluster também recebe o mesmo nome que a VM da estação de trabalho de administração (por exemplo, cnuc-1, cnuc-4, cnuc-7).

O guia interativo 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 do Compute Engine configuradas.
Cria um cluster autónomo denominado cnuc-1.
Regista o cluster cnuc-1 com o Google Cloud.
Instala o Config Sync no cluster cnuc-1.
Configura o Config Sync para sincronizar com as configurações do cluster localizadas em anthos-bm-edge-deployment/acm-config-sink no seu repositório bifurcado.
Gera o Login token para o cluster.

Conclua os passos seguintes para configurar e iniciar o processo de instalação:

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

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

Quando a compilação é executada com êxito, produz uma saída semelhante à seguinte:

...
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 ficheiro de inventário do Ansible a partir do modelo:

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

Execute o script de instalação que inicia um contentor Docker a partir da imagem criada anteriormente. O script usa internamente o Docker para gerar o contentor com uma montagem de volume no diretório de trabalho atual. Após a conclusão bem-sucedida deste script, tem de estar no contentor Docker que foi criado. Aciona a instalação do Ansible a partir do interior deste contentor.

./install.sh

Quando o script é executado com êxito, produz uma saída semelhante à seguinte:

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

No contentor Docker, valide o acesso às instâncias do Compute Engine:

./scripts/health-check.sh

Quando o script é executado com êxito, produz uma saída semelhante à seguinte:

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

A partir do contentor Docker, execute o playbook do Ansible para instalar um cluster bare metal em instâncias do Compute Engine:

Após a conclusão, é apresentado o Login Token para o cluster impresso no ecrã.

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

Quando a instalação é executada com êxito, produz uma saída semelhante à seguinte:

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

Inicie sessão no cluster na Google Cloud consola

Depois de o playbook do Ansible ser executado até à conclusão, é instalado um cluster autónomo nas VMs do Compute Engine. Este cluster também está registado no Google Cloudatravés do agente Connect. No entanto, para ver detalhes sobre este cluster, tem de iniciar sessão no cluster a partir da Google Cloud consola.

Para iniciar sessão no cluster, conclua os seguintes passos:

Copie o token da saída do playbook do Ansible na secção anterior.

Nota: se já não tiver acesso ao resultado da consola, verifique o ficheiro de registo em ./build-artifacts/ansible-run.log para obter o seu token. Também pode executar o seguinte guia interativo do Ansible para obter novamente o token: ansible-playbook all-get-login-tokens.yaml -i inventory
Na Google Cloud consola, aceda à página Clusters Kubernetes e use o token copiado para iniciar sessão no cluster cnuc-1.

Aceda à página de clusters do Kubernetes
1. Na lista de clusters, clique em Ações junto ao cluster cnuc-1 e, de seguida, clique em Iniciar sessão.
2. Selecione Símbolo e cole o símbolo copiado.
3. Clique em Iniciar sessão.
Na Google Cloud consola, aceda à página Configuração na secção Funcionalidades.

Aceda à configuração

No separador Pacotes, verifique a coluna Estado da sincronização na tabela de clusters. Verifique se o estado é Sincronizado. O estado Sincronizado indica que o Config Sync sincronizou com êxito as suas configurações do GitHub com o cluster implementado, cnuc-1.

Configure um proxy para tráfego externo

O cluster instalado nos passos anteriores usa um equilibrador de carga integrado denominado MetalLB. Este serviço de balanceamento de carga só está acessível através de um endereço IP da nuvem privada virtual (VPC). Para encaminhar o tráfego recebido através do respetivo IP externo para o equilibrador de carga integrado, configure um serviço de proxy inverso no anfitrião de administração (cnuc-1). Este serviço de proxy inverso permite-lhe aceder ao servidor da API da aplicação de ponto de venda através do IP externo do anfitrião de administração (cnuc-1).

Os scripts de instalação nos passos anteriores instalaram o NGINX nos anfitriões de administração juntamente com um ficheiro de configuração de exemplo. Atualize este ficheiro para usar o endereço IP do serviço de balanceamento de carga e reinicie o NGINX.

Na sua estação de trabalho, use o SSH para iniciar sessão na estação de trabalho de administrador:
```
ssh -F ./build-artifacts/ssh-config abm-admin@cnuc-1
```
Na estação de trabalho de administração, configure o proxy reverso NGINX para encaminhar o tráfego para o serviço de balanceamento de carga do servidor da API. Obtenha o endereço IP do serviço Kubernetes do tipo LoadBalancer:
```
ABM_INTERNAL_IP=$(kubectl get services api-server-lb -n pos | awk '{print $4}' | tail -n 1)
```

Atualize o ficheiro de configuração do modelo com o endereço IP obtido:

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 se certificar de que a nova configuração é aplicada:
```
sudo systemctl restart nginx
```

Verifique e valide o estado dos relatórios do servidor NGINX "ativo (em execução)":

sudo systemctl status nginx

Quando o NGINX está a ser executado com êxito, produz uma saída como a do exemplo 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 na estação de trabalho de administração:
```
exit
```
Saia da sessão de shell para o contentor Docker. Depois de sair da instância de administrador, continua no contentor do Docker usado para a instalação:
```
exit
```

Aceda à aplicação de ponto de venda

Com a configuração do proxy externo, pode aceder à aplicação em execução no cluster. Para aceder à aplicação de ponto de venda de exemplo, conclua os seguintes passos.

Na sua estação de trabalho, obtenha o endereço IP externo da instância do Compute Engine do administrador e aceda à IU da aplicação de 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 êxito, produzem uma saída semelhante à seguinte:

Point the browser to: 34.134.194.84:8082

Abra o navegador de Internet e navegue para o endereço IP apresentado no resultado do comando anterior. Pode aceder e testar a aplicação de ponto de venda de amostra, conforme mostrado na seguinte captura de ecrã de exemplo:

Use a sincronização de configuração para atualizar o servidor da API

A aplicação de exemplo pode ser atualizada para uma versão mais recente atualizando os ficheiros de configuração no repositório de raiz. O Config Sync deteta as atualizações e faz automaticamente as alterações ao cluster. Neste exemplo, o repositório raiz é o repositório anthos-samples que clonou no início deste guia. Para ver como a aplicação de ponto de venda de exemplo pode passar por uma implementação de atualização para uma versão mais recente, conclua os seguintes passos.

Na sua estação de trabalho, atualize o campo image para alterar a versão do servidor da API de v1 para v2. A configuração YAML para a implementação está no ficheiro 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
```

Adicione, confirme e envie as alterações para o 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

Na Google Cloud consola, aceda à página Config Sync para verificar o estado da especificação de configuração. Verifique se o estado é Sincronizado.

Aceda à página Config Sync
Na Google Cloud consola, aceda à página Kubernetes Engine Workloads para verificar se a implementação está atualizada.

Aceda à página Cargas de trabalho do Kubernetes Engine
Quando o estado da Implementação for OK, direcione o navegador para o endereço IP da secção anterior para ver a aplicação de ponto de venda. Tenha em atenção que a versão no título mostra "V2", o que indica que a alteração da aplicação foi implementada, conforme mostrado na captura de ecrã de exemplo seguinte:

Pode ter de fazer uma atualização forçada do separador do navegador para ver as alterações.

Limpar

Para evitar Google Cloud cobranças desnecessárias, elimine os recursos usados para este guia quando terminar de o usar. Pode eliminar estes recursos manualmente ou eliminar o seu projeto Google Cloud , o que também elimina todos os recursos. Além disso, também pode querer limpar as alterações feitas na sua estação de trabalho local:

Estação de trabalho local

Os seguintes ficheiros têm de 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 ficheiro /etc/hosts.
Remova a configuração de SSH para cnuc-* no ficheiro ~/.ssh/config.
Remova as impressões digitais de VMs do Compute Engine do ficheiro ~/.ssh/known_hosts.

Eliminar projeto

Se criou um projeto dedicado para este procedimento, elimine o Google Cloud projeto da 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

Se usou um projeto existente para este procedimento, faça o seguinte:

Anule o registo de todos os clusters do Kubernetes com um nome com o prefixo cnuc-.
Elimine todas as VMs do Compute Engine com um nome com o prefixo cnuc-.
Elimine o contentor do Cloud Storage com um nome com o prefixo abm-edge-boot.
Elimine as regras de firewall allow-pod-ingress e allow-pod-egress.
Elimine o segredo do Secret Manager install-pub-key.

O que se segue?

Pode expandir este guia adicionando outra localização periférica. Definir a variável de ambiente GCE_COUNT como 6 e executar novamente os mesmos passos das secções anteriores cria três novas instâncias do Compute Engine (cnuc-4, cnuc-5 e cnuc-6) e um novo cluster autónomo denominado cnuc-4.

Também pode experimentar atualizar as configurações do cluster no seu repositório bifurcado para aplicar seletivamente diferentes versões da aplicação de ponto de venda aos dois clusters, cnuc-1 e cnuc-4, através de ClusterSelectors.

Para ver detalhes sobre os passos individuais neste guia e os scripts envolvidos, consulte o repositório anthos-samples.