Implantar o Anthos em clusters bare metal na borda

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:

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:

Mostra um cluster do Anthos em implantação bare metal que usa o perfil de borda em uma loja de varejo
Um cluster do Anthos em implantação bare metal 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. 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.

A imagem mostra a arquitetura do aplicativo do ponto de venda e como ele é implantado em um cluster bare metal do Anthos em execução nas VMs do Compute Engine
Um aplicativo de amostra implantado em um cluster bare metal do Anthos

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

  1. Use as VMs do Compute Engine para emular uma infraestrutura bare metal executada em um local de borda.
  2. Criar um cluster bare metal do Anthos na infraestrutura de borda emulada.
  3. Conectar e registrar o cluster no Google Cloud.
  4. Implante uma carga de trabalho de aplicativo de ponto de venda de amostra no cluster do Anthos.
  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 Anthos Config Management para atualizar o aplicativo de ponto de venda que é executado no cluster do Anthos.

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

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

    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 Fork no canto superior direito da página.
    3. 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.
  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 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.

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

  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 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 e nomos.
  • 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:

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

  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.

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

    Anthos Config Management sincronizado com o repositório de origem.

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.

  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 de 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 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: ....
                ...
                ...
    
  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 do Anthos. 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 implantada.

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.

  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 Gerenciamento de configuração para verificar o status das especificações de configuração. Verifique se o status é Sincronizado.

    Acesse a página Gerenciamento de configurações

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

    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.

  • No Console do Google Cloud, acesse a página Gerenciar recursos.

    Acessar "Gerenciar recursos"

  • Na lista de projetos, selecione o projeto que você quer excluir e clique em Excluir .
  • Na caixa de diálogo, digite o ID do projeto e clique em Encerrar para excluí-lo.
  • 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 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.