Como criar imagens de multiarquiteturas do Windows Server

Padrão

Neste tutorial, você verá como gerenciar a complexidade do controle de versões da criação de imagens direcionadas a várias versões do Windows Server. Os contêineres do Windows Server têm requisitos de compatibilidade de versão que impedem a execução de contêineres em mais de uma versão do host do Windows Server. No entanto, o Docker no Windows Server é compatível com imagens de contêiner de multiarquiteturas (ou várias plataformas) que podem ser executadas em várias versões do Windows Server.

Com imagens de multiarquiteturas, é possível atualizar os pools de nós do Windows Server do Google Kubernetes Engine (GKE) para a versão preferida do Windows Server sem recriar a imagem e alterar as especificações do pod. Por exemplo:

O GKE versão 1.15 é compatível com o Windows Server 1809
O GKE versão 1.16 é compatível com o Windows Server 1909

Para fazer upgrade automaticamente de uma versão do GKE para outra mais recente, crie imagens de multiarquiteturas para suas cargas de trabalho do Windows. A criação de uma imagem de multiarquiteturas envolve a criação de uma imagem para cada versão do Windows Server e a criação de um manifesto que referencia essas imagens para cada versão do Windows Server. Você pode criar as imagens manualmente se quiser ter controle total sobre a criação e o processo de criação da imagem. Se preferir, use o Cloud Build para criar automaticamente as imagens de multiarquiteturas do Windows Server.

Objetivos

Neste tutorial, você aprende a criar imagens de multiarquiteturas do Windows Server manualmente ou usando o Cloud Build.

Crie as imagens manualmente:
- Crie duas imagens do Docker com diferentes versões ou tipos do Windows Server, por exemplo, o canal de serviço de longo prazo (LTSC, na sigla em inglês) e o canal semi-anual (SAC).
- Crie uma VM do Windows Server.
- Crie um manifesto e envie-o para o registro.
Crie as imagens usando o Cloud Build:
- Prepare seu ambiente criando um projeto, ativando APIs e concedendo permissões.
- Crie um aplicativo, Dockerfiles e arquivos de build.
- Execute um comando para criar a imagem.

Custos

Neste documento, você usará os seguintes componentes faturáveis do Google Cloud:

Para gerar uma estimativa de custo baseada na projeção de uso deste tutorial, use a calculadora de preços. Novos usuários do Google Cloud podem estar qualificados para uma avaliação gratuita.

Ao concluir as tarefas descritas neste documento, é possível evitar o faturamento contínuo excluindo os recursos criados. Saiba mais em Limpeza.

Antes de começar

Antes de começar, verifique se você realizou as tarefas a seguir:

Instale a Google Cloud CLI para executar comandos gcloud.
Instale o Docker para criar contêineres.
Instale o Go para criar binários do Windows Server.
Este tutorial usa o Artifact Registry como repositório. Verifique se você criou seu repositório do Docker.

Como criar imagens de multiarquiteturas manualmente

A criação manual de imagens de multiarquiteturas oferece flexibilidade para criar uma imagem que inclua as versões necessárias do Windows Server. Para criar imagens de multiarquiteturas manulamente:

Crie uma imagem de arquitetura única do Docker LTSC 2019. Consulte os detalhes sobre como criar imagens do Docker em Como implantar um aplicativo do Windows Server. Por exemplo, us-docker.pkg.dev/my-project/docker-repo/foo:1.0-2019.
Crie uma imagem de arquitetura única do Docker LTSC 2022. Por exemplo, us-docker.pkg.dev/my-project/docker-repo/foo:1.0-2022.
Crie uma imagem de arquitetura única do Docker SAC 20H2. Por exemplo, us-docker.pkg.dev/my-project/docker-repo/foo:1.0-20h2
Crie uma VM do Windows Server, por exemplo, versão 20H2. Consulte o Guia de início rápido sobre como usar uma VM do Windows Server.
Use o RDP para se conectar à VM.
Abra uma janela do PowerShell para executar os comandos nas próximas etapas.
Ative o recurso experimental docker manifest. Um manifesto do Docker é uma lista de imagens para enviar para um registro:
```
PS C:\> $env:DOCKER_CLI_EXPERIMENTAL = 'enabled'
```

Crie o manifesto de multiarquiteturas.

docker manifest create `
  REGISTRY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/foo:1.0 `
  REGISTRY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/foo:1.0-2019 `
  REGISTRY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/foo:1.0-2022 `
  REGISTRY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/foo:1.0-20h2

Envie o manifesto de imagem de multiarquiteturas recém-criado ao repositório do Artifact Registry:
```
 docker manifest push `
   REGISTRY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/foo:1.0
```
Para garantir que a imagem de multiarquiteturas tenha sido criada e enviada com sucesso, navegue até REGISTRY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/foo e clique na imagem. Você verá as três imagens dentro:
- foo:1.0-2019
- foo:1.0-2022
- foo:1.0-20h2
- foo:1.0

Agora, você pode fazer referência à imagem de multiarquiteturas REGISTRY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/foo:1.0 nas especificações do pod. Isso permitirá que você use o upgrade automático com segurança para seus pools de nós do GKE no Windows.

Como criar imagens de multiarquiteturas usando o Cloud Build gke-windows-builder

Para facilitar o esforço das etapas de criação manuais, use o gke-windows-builder com base no OSS gke-windows-builder. É possível usar o gke-windows-builder com o Cloud Build para criar automaticamente as imagens de multiarquiteturas do Windows Server. O GKE atualiza o builder para incluir novas versões compatíveis do Windows SAC e LTSC quando elas forem lançadas. Outro benefício de usar o builder é que você não precisa criar sua própria VM do Windows com o PowerShell para criar as imagens. A VM do Windows é substituída por um contêiner do Docker que executa os comandos para você no Cloud Build.

Para ajudar você a entender como o builder funciona, siga este exemplo para criar a imagem de multiarquitetura "hello world". Essas etapas podem ser realizadas em servidores Linux ou Windows.

Como preparar o ambiente

Para preparar o ambiente, conclua as seguintes etapas:

Crie um diretório de espaço de trabalho na máquina de trabalho, por exemplo: ~/gke-windows-builder/hello-world.
Crie ou selecione um projeto para este tutorial.
verifique se o faturamento foi ativado no projeto.
Ative as APIs do Compute Engine, do Cloud Build e do Artifact Registry para o projeto. O gke-windows-builder é invocado usando o Cloud Build, e as imagens de contêiner de multiarquiteturas resultantes são enviadas para o Artifact Registry. O Compute Engine é necessário para que o builder crie e gerencie VMs do Windows Server.
```
gcloud services enable compute.googleapis.com cloudbuild.googleapis.com \
  artifactregistry.googleapis.com cloudbuild.googleapis.com
```

Conceda os seguintes papéis de gerenciamento de identidade e acesso (IAM) à sua conta de serviço do Cloud Build usando a Google Cloud CLI:

Defina variáveis:

export PROJECT=$(gcloud info --format='value(config.project)')
export MEMBER=$(gcloud projects describe $PROJECT --format 'value(projectNumber)')@cloudbuild.gserviceaccount.com

Atribuir papéis. Esses papéis são necessários para que o builder crie as VMs do Windows Server, copie o espaço de trabalho para um bucket do Cloud Storage, configure as redes para criar a imagem do Docker e envie a imagem resultante ao Artifact Registry:

gcloud projects add-iam-policy-binding $PROJECT --member=serviceAccount:$MEMBER --role='roles/compute.instanceAdmin'
gcloud projects add-iam-policy-binding $PROJECT --member=serviceAccount:$MEMBER --role='roles/iam.serviceAccountUser'
gcloud projects add-iam-policy-binding $PROJECT --member=serviceAccount:$MEMBER --role='roles/compute.networkViewer'
gcloud projects add-iam-policy-binding $PROJECT --member=serviceAccount:$MEMBER --role='roles/storage.admin'
gcloud projects add-iam-policy-binding $PROJECT --member=serviceAccount:$MEMBER --role='roles/artifactregistry.writer'

Adicione uma regra de firewall chamada allow-winrm-ingress para permitir que o WinRM se conecte às VMs do Windows Server para executar uma versão do Docker:

Observação: o nome da regra de firewall precisa ser allow-winrm-ingress, porque gke-windows-builder usa esse nome específico para verificar se esta regra de firewall existe.
```
gcloud compute firewall-rules create allow-winrm-ingress --allow=tcp:5986 --direction=INGRESS
```
Crie um repositório do Docker no Artifact Registry para o projeto. Se você nunca usou repositórios do Docker no Artifact Registry antes, conclua o Guia de início rápido do Docker primeiro. Execute este comando para criar o repositório:
```
gcloud artifacts repositories create REPOSITORY \
  --repository-format=docker --location=REGISTRY_REGION \
  --description="Docker repository"
```
Substitua:
- REPOSITORY: um nome, como windows-multi-arch-images.
- REGISTRY_REGION: um local válido do Artifact Registry;

Como criar o binário hello.exe no espaço de trabalho

Neste tutorial, crie um aplicativo "hello world" simples, escrito em Go. O código para o app de amostra está no GitHub.

Clone o repositório que contém o código de amostra deste tutorial na sua máquina local usando os seguintes comandos:

 git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples
 cd kubernetes-engine-samples/windows/windows-multi-arch

O arquivo hello.go imprime as palavras "Hello World":

package main

import "fmt"

func main() {
	fmt.Println("Hello World!")
}

Gere o binário hello.exe:
```
GOOS=windows go build hello.go
```

Você verá o binário hello.exe no seu espaço de trabalho.

Como criar um Dockerfile e criar arquivos no espaço de trabalho

Nesta seção, você usa um Dockerfile para criar cada imagem do Windows Server de arquitetura única e, em seguida, usa um arquivo de compilação para acionar o Cloud Build. A versão combina as imagens de arquitetura única em uma imagem de multiarquiteturas.

O Dockerfile é um documento de texto que contém instruções para o Docker criar uma imagem. O gke-windows-builder substitui o WINDOWS_VERSION por uma versão específica do Windows Server para que a imagem será criada. Por exemplo, o builder executará docker build -t multi-arch-helloworld:latest_20h2 --build-arg WINDOWS_VERSION=20H2 . no Windows Server 20H2.
```
ARG WINDOWS_VERSION=
FROM mcr.microsoft.com/windows/servercore:${WINDOWS_VERSION}
COPY hello.exe /hello.exe
USER ContainerUser
ENTRYPOINT ["hello.exe"]
```

No mesmo diretório que contém o Dockerfile, o arquivo cloudbuild.yaml é seu arquivo de configuração da versão. Substitua <REPOSITORY> e <REGISTRY_REGION> pelo nome e região do repositório do Artifact Registry que você criou na etapa anterior. No momento da criação, o Cloud Build substitui automaticamente $PROJECT_ID pelo ID do projeto.

timeout: 3600s
steps:
- name: 'us-docker.pkg.dev/gke-windows-tools/docker-repo/gke-windows-builder:latest'
  args:
  - --container-image-name
  # Replace <REGISTRY_REGION> and <REPOSITORY>.
  - '<REGISTRY_REGION>-docker.pkg.dev/$PROJECT_ID/<REPOSITORY>/multiarch-helloworld:latest'
  # Specify specific variants of images to be built. Or, remove the following 2 lines to default to all available variants.
  - --versions
  - '20H2,ltsc2019'

Como criar a imagem

Agora, crie a imagem e veja seus registros para verificar uma versão bem-sucedida.

Para criar a imagem, execute o seguinte comando:
```
gcloud builds submit --config=cloudbuild.yaml .
```
Observação: este comando leva vários minutos para ser concluído.

Você verá registros como o exemplo a seguir. A última linha no registro mostra que a criação foi bem-sucedida:

Creating temporary tarball archive of 2 file(s) totalling 492 bytes before compression.
Uploading tarball of [.] to [gs://PROJECT_ID_cloudbuild/source/1600082502.509759-b949721a922d462c94a75da9be9f1181.tgz]
Created [https://cloudbuild.googleapis.com/v1/projects/PROJECT_ID/builds/ec333452-1301-47e8-90e2-716aeb2f5650].
Logs are available at [https://console.cloud.google.com/cloud-build/builds/ec333452-1301-47e8-90e2-716aeb2f5650?project=840737568665].
------------------------ REMOTE BUILD OUTPUT---------------------------------------
...
...

Created manifest list REGISTRY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/multiarch-helloworld:latest
sha256:3ecbbc9f5144f358f81f7c7f1a7e28f069c98423d59c40eaff72bf184af0be02
2020/09/14 11:34:25 Instance: 35.184.178.49 shut down successfully
PUSH
DONE
-----------------------------------------------------------------------------------

ID                                    CREATE_TIME                DURATION  SOURCE                                                                                      IMAGES  STATUS
ec333452-1301-47e8-90e2-716aeb2f5650  2020-09-14T11:21:43+00:00  12M43S    gs://PROJECT_ID_cloudbuild/source/1600082502.509759-b949721a922d462c94a75da9be9f1181.tgz  -                 SUCCESS

Você acabou de criar a imagem usando o arquivo de configuração do build e enviá-la ao Artifact Registry em REGISTRY_REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/multiarch-helloworld:latest.

Com implantar a imagem

Para implantar a imagem de várias versões do Windows em um cluster, consulte Como implantar um aplicativo do Windows Server e saiba como implantar a imagem.

Uso avançado do gke-windows-builder

É possível personalizar o comportamento do gke-windows-builder adicionando sinalizações à seção args do arquivo de configuração da versão cloudbuild.yaml. Algumas sinalizações para comportamentos comuns são descritas nesta seção, mas esta não é uma lista completa. Para ver a lista completa de sinalizações compatíveis com o gke-windows-builder, execute o seguinte comando em um servidor Linux ou no Cloud Shell:

docker run -it us-docker.pkg.dev/gke-windows-tools/docker-repo/gke-windows-builder:latest --help

Para acelerar suas compilações, use um tipo de máquina maior para as instâncias do Windows:

  - --machineType
  - 'n1-standard-8'

Em vez de criar a imagem para todas as versões do Windows compatíveis com o GKE, é possível escolher versões específicas do Windows Server a serem criadas usando a sinalização --versions:

  - --versions
  - '20H2,ltsc2019'

Se o espaço de trabalho tiver muitos arquivos, a criação da imagem será mais confiável se você configurar o builder para copiar o espaço de trabalho pelo Cloud Storage em vez de pelo WinRM. Crie um bucket no projeto, como gs://{your project}_builder, e defina a sinalização --workspace-bucket:

  - --workspace-bucket
  - '{your project}_builder'

Para executar as instâncias do criador do Windows em um projeto de serviço de VPC compartilhada, use estas sinalizações que controlam a configuração de rede da instância:

  - --subnetwork-project
  - 'shared-vpc-host-project'
  - --subnetwork
  - 'host-project-subnet-shared-with-service-project'

Limpeza

Depois de concluir o tutorial, você pode limpar os recursos que criou para que eles parem de usar a cota e gerar cobranças. Nas seções a seguir, você aprenderá a excluir e desativar esses recursos.

Como excluir a imagem

Para excluir as imagens multiarch-helloworld no Artifact Registry, consulte Como excluir imagens.

Excluir o projeto

O jeito mais fácil de evitar cobranças é excluindo o projeto que você criou para o tutorial.

Para excluir o projeto:

Cuidado: excluir um projeto tem os seguintes efeitos:

Tudo no projeto é excluído. Se você tiver usado um projeto existente para as tarefas neste documento, a exclusão dele incluirá a exclusão de quaisquer outros trabalhos feitos no projeto.
Os IDs do projeto personalizados são perdidos. Ao criar o projeto, você pode ter criado um código do projeto personalizado para ser usado no futuro. Para preservar os URLs que usam o ID do projeto, como um URL appspot.com, exclua recursos específicos do projeto, em vez de excluir o projeto inteiro.

Se você planeja passar por várias arquiteturas, tutoriais ou guias de início rápido, a reutilização de projetos pode evitar que você exceda os limites da cota do projeto.

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.

A seguir

Explore outros tutoriais do Kubernetes Engine.
Confira arquiteturas de referência, diagramas, tutoriais e práticas recomendadas do Google Cloud. Confira o Centro de arquitetura do Cloud.