Esta aplicação Docker funcionará na arquitetura de CPU do seu servidor? Uma lista de verificação de compatibilidade

Porque é que a compatibilidade com a arquitetura de CPU é importante numa implementação Docker

Um contêiner Docker não é uma máquina virtual com o seu próprio kernel independente. Os contêineres partilham o kernel do anfitrião, pelo que o código dentro de uma imagem tem de ser compatível com o ambiente do anfitrião. O Docker descreve variantes de imagens específicas de cada plataforma, como linux/amd64 e linux/arm64; quando uma imagem disponibiliza variantes adequadas, o runtime pode selecionar uma para o anfitrião. Consulte a [documentação do Docker sobre compilações multiplataforma](https://docs.docker.com/build/building/multi-platform/).

A questão principal não é simplesmente saber se uma aplicação tem uma imagem Docker. É saber se todas as imagens e todos os componentes sensíveis à arquitetura na implementação são compatíveis com a plataforma de destino e se a aplicação funciona nessa plataforma para o uso pretendido.

Uma incompatibilidade de arquitetura pode manifestar-se em diferentes fases: uma imagem pode não estar disponível para a plataforma, um executável nativo pode não iniciar ou um componente de suporte pode não funcionar como esperado. O facto de conseguir descarregar uma imagem não prova, por si só, que a aplicação será implementada com êxito.

• Verifique a plataforma do servidor onde a carga de trabalho será efetivamente executada; não a deduza pelo nome de um fornecedor ou pela categoria do produto.
• Analise a imagem principal da aplicação e todas as imagens dos serviços de que depende.
• Considere a disponibilidade no manifesto, o suporte do fornecedor e os testes bem-sucedidos da aplicação como elementos de evidência distintos.

Identifique a arquitetura do servidor e as plataformas necessárias à aplicação

Comece por perguntar ao operador do servidor qual é a plataforma do servidor ou da instância específica que está a considerar. Se tiver acesso ao Docker Engine, execute `docker info` e verifique o campo Architecture na saída. A [referência da CLI do Docker](https://docs.docker.com/reference/cli/docker/system/info/) mostra este campo e apresenta `aarch64` como um exemplo.

Registe o sistema operativo, além da arquitetura da CPU. As plataformas das imagens são normalmente indicadas num formato como `linux/arm64` ou `linux/amd64`; os metadados de imagens OCI também podem incluir uma variante de arquitetura. Os nomes e as variantes são importantes ao comparar o anfitrião com uma imagem ou uma tabela de suporte do fornecedor.

Em seguida, faça uma lista das plataformas necessárias ou suportadas pela aplicação. Consulte a documentação da imagem e da versão exatas que pretende implementar, em vez de presumir que a etiqueta mais recente, a descrição de um repositório ou uma imagem compilada para outra plataforma representam a sua implementação.

• Sistema operativo e arquitetura do anfitrião de destino: registe os valores confirmados pelo operador.
• Imagem da aplicação: registe a referência exata da imagem e a respetiva versão ou etiqueta.
• Plataforma necessária: anote o sistema operativo, a arquitetura e qualquer variante documentada.
• Evidências: guarde a saída relevante do comando ou a referência à documentação do fornecedor.

Verifique os manifestos das imagens e a documentação oficial das plataformas suportadas

Uma referência de imagem pode apontar para um índice de imagens OCI que contém manifestos separados para diferentes plataformas. Os descritores de plataforma do índice incluem campos como o sistema operativo e a arquitetura e podem incluir uma variante. Consulte a [especificação do índice de imagens OCI](https://github.com/opencontainers/image-spec/blob/main/image-index.md). A configuração de uma imagem também identifica o sistema operativo e a arquitetura de CPU para os quais os respetivos binários foram compilados; este aspeto é descrito na [especificação de configuração de imagens OCI](https://github.com/opencontainers/image-spec/blob/main/config.md).

Para uma imagem num registo, o Docker documenta [`docker buildx imagetools inspect`](https://docs.docker.com/reference/cli/docker/buildx/imagetools/inspect/) como forma de consultar os detalhes da imagem e as plataformas indicadas nos respetivos manifestos. Por exemplo, inspecione uma referência específica com `docker buildx imagetools inspect IMAGE:TAG`, substituindo o marcador pela imagem e etiqueta que pretende utilizar. Compare as plataformas indicadas com as do servidor de destino, em vez de confiar na descrição geral do repositório.

Em seguida, consulte a documentação oficial do editor da imagem para conhecer as plataformas suportadas, os requisitos de implementação e eventuais limitações específicas da plataforma. Uma entrada no manifesto é uma evidência útil de que existe uma variante da imagem; por si só, não garante que todas as funcionalidades da aplicação, os componentes opcionais ou as cargas de trabalho sejam suportados em produção.

• A referência de imagem inspecionada indica o sistema operativo e a arquitetura de destino?
• O fornecedor documenta o suporte dessa plataforma para a versão da aplicação que pretende implementar?
• Existem notas sobre variantes, opções de compilação necessárias ou funcionalidades excluídas?
• A referência da imagem e a documentação descrevem a mesma versão?

Inclua bases de dados, plug-ins, sidecars e outros contêineres de suporte na análise

Uma aplicação empresarial é muitas vezes implementada com mais do que um contêiner. Analise o suporte da plataforma para a base de dados, a cache, a fila, o proxy, o worker, o sidecar e qualquer serviço opcional definido na configuração da implementação. A compatibilidade da imagem principal não resolve a compatibilidade do resto da pilha.

Inspecione o ficheiro Compose ou as instruções de implementação efetivamente utilizados, incluindo imagens referenciadas indiretamente através de perfis, substituições ou funcionalidades opcionais. O Docker Compose define um atributo `platform` por serviço, utilizando `os[/arch[/variant]]`; este atributo pode influenciar a versão da imagem descarregada ou a plataforma utilizada numa compilação. Consulte a [referência dos serviços do Compose](https://docs.docker.com/reference/compose-file/services/). Considere esta definição uma instrução de seleção ou compilação, não uma prova de que o conteúdo da imagem selecionada é compatível.

Consulte a documentação do fornecedor de cada imagem de suporte, sobretudo quando um componente for mantido por outro projeto ou fornecedor. Mantenha um registo componente a componente para que uma lacuna de plataforma numa dependência não fique escondida numa declaração geral de que a aplicação é suportada.

• Faça uma lista de todos os serviços da implementação, incluindo os opcionais e os específicos de cada perfil.
• Para cada serviço, registe a referência da imagem, a plataforma de destino e a fonte que confirma o suporte.
• Assinale os serviços cuja plataforma seja desconhecida ou cuja documentação não corresponda à versão prevista.
• Reveja as definições `platform` do Compose e confirme que correspondem ao anfitrião e à imagem pretendidos.

Procure binários, controladores e dependências de disponibilização de modelos específicos da arquitetura

Algumas limitações de compatibilidade estão dentro de uma imagem ou associadas a uma funcionalidade, em vez de serem evidentes pelo nome da aplicação. Procure executáveis nativos incluídos, extensões compiladas, plug-ins, ferramentas de linha de comandos e controladores ou toolkits fornecidos por fornecedores. O campo de arquitetura da configuração de uma imagem OCI descreve a arquitetura para a qual os binários da imagem foram compilados, mas não descreve todas as dependências opcionais ou integrações externas.

Leia a documentação oficial de instalação e hardware da aplicação para identificar requisitos associados a funções opcionais. Se a implementação utilizar suporte de GPU ou outro toolkit de hardware, verifique separadamente o suporte da plataforma desse fornecedor. Por exemplo, a NVIDIA publica uma [tabela de suporte do Container Toolkit por distribuição Linux e arquitetura](https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/latest/supported-platforms.html); essa documentação é independente do manifesto da imagem da carga de trabalho.

No caso de software de IA ou de disponibilização de modelos, verifique o suporte da plataforma para cada camada relevante: a imagem da aplicação, o runtime de disponibilização de modelos, qualquer toolkit de hardware e a funcionalidade ou o fluxo de trabalho específico com modelos que pretende testar. Não considere que uma interface de utilizador ou um contêiner de API compatível prova que todos os caminhos de inferência são suportados.

• Pesquise na documentação oficial termos como plataforma, arquitetura, nativo, binário, controlador, GPU e requisitos de hardware.
• Identifique as funcionalidades opcionais que introduzem os seus próprios binários ou dependências de hardware.
• Verifique cada ferramenta ou controlador com base na documentação de suporte do respetivo fornecedor.
• Assinale como não verificadas as combinações que não estejam documentadas, em vez de presumir que funcionam.

Compreenda a diferença entre execução nativa e emulação

Uma variante de imagem específica da plataforma que corresponde ao anfitrião é diferente da execução, por emulação, de uma imagem compilada para outra arquitetura. A emulação pode estar disponível em alguns ambientes, mas não constitui uma evidência equivalente ao suporte nativo e não se deve presumir que se comporta da mesma forma.

O Docker documenta a emulação QEMU para executar contêineres baseados em Intel em computadores Apple Silicon e alerta que esta pode ser mais lenta, utilizar mais memória ou encontrar falhas. Consulte a [documentação de problemas conhecidos do Docker](https://docs.docker.com/desktop/troubleshoot-and-support/troubleshoot/known-issues/). Isto lembra-nos que devemos avaliar o anfitrião, o runtime, a imagem e a carga de trabalho concretos, em vez de generalizar a partir de um teste bem-sucedido noutra máquina.

Se estiver a considerar a emulação, confirme que o ambiente do servidor suporta a configuração necessária e que o fornecedor da aplicação suporta essa utilização para o seu caso. Teste as cargas de trabalho que lhe interessam e registe que a configuração recorre a emulação, em vez de ser nativa.

• Correspondência nativa: o anfitrião e a imagem têm como destino a mesma plataforma.
• Execução emulada: a imagem tem como destino uma arquitetura diferente e depende de um mecanismo de emulação.
• Desconhecida: a implementação é executada, mas o modo de execução ou o suporte do fornecedor não foram confirmados.
• Não utilize apenas uma definição de plataforma no Compose como prova de que a emulação está disponível ou de que a carga de trabalho é suportada.

Teste uma implementação representativa e defina o que conta como um teste bem-sucedido

Depois de verificar a documentação e os manifestos, execute um teste num ambiente que corresponda, tanto quanto possível, à plataforma do servidor pretendido. Utilize as mesmas referências de imagem, a configuração Compose e os principais serviços de suporte previstos para a implementação. Um teste noutra arquitetura pode fornecer informações úteis, mas não verifica a plataforma de destino.

O Docker Compose suporta [`docker compose up --wait`](https://docs.docker.com/reference/cli/docker/compose/up/), que aguarda que os serviços estejam em execução ou saudáveis. Um estado de saúde é uma verificação útil, mas não constitui um teste de aceitação completo. Confirme que a aplicação inicia, que as dependências estabelecem ligação e que as tarefas essenciais para o seu caso de utilização funcionam. Se a configuração Compose definir verificações de estado, analise o que essas verificações testam efetivamente.

Defina o que é considerado sucesso antes de testar. Inclua os fluxos de trabalho de que a sua equipa precisa, não apenas o arranque dos contêineres. Por exemplo, numa aplicação de IA, especifique se precisa de iniciar a interface, obter uma resposta de um serviço de modelos configurado ou concluir um fluxo de inferência específico; teste apenas os requisitos aplicáveis à sua implementação.

• Inicie a pilha representativa e registe os erros de arranque e o estado dos serviços.
• Verifique se os serviços necessários atingem o estado de execução ou de saúde esperado.
• Execute os fluxos de trabalho e as integrações essenciais da aplicação.
• Registe a plataforma do anfitrião, as referências das imagens, a configuração, a data do teste e os resultados observados.
• Repita um teste falhado ou inconclusivo depois de alterar uma única variável identificada, para facilitar o isolamento da causa.

Documente lacunas, alternativas e motivos para voltar a validar

Quando as evidências forem incompletas, registe explicitamente a incerteza. Distinga uma correspondência de plataforma confirmada, uma configuração documentada pelo fornecedor mas não testada, uma configuração testada e uma configuração que depende de emulação. Isto proporciona a quem toma decisões técnicas e de compra uma base mais clara para comparar ambientes de alojamento.

Para cada questão por resolver, registe o impacto, quem pode verificá-la e a ação seguinte: pedir confirmação ao fornecedor da aplicação ou ao operador do servidor, testar na plataforma de destino, escolher uma imagem alternativa documentada ou selecionar uma plataforma de servidor que cumpra os requisitos da aplicação. Se não existir uma via suportada para uma carga de trabalho necessária, não trate uma solução alternativa como uma solução de compatibilidade confirmada.

Volte a verificar as evidências quando ocorrer uma alteração relevante numa parte da implementação. Entre os motivos úteis para o fazer estão a alteração da versão da aplicação ou da referência da imagem, a substituição de um serviço de suporte, a mudança da plataforma do servidor de destino, a ativação de uma funcionalidade opcional dependente de hardware ou a revisão da configuração da implementação.

O alojamento gerido pode reduzir o trabalho de infraestrutura, mas não elimina a necessidade de verificar os requisitos da aplicação ou de tomar decisões sobre dados, acesso e governação. A Airbip executa instâncias de aplicações como cargas de trabalho Docker em servidores na nuvem; se estiver a avaliar uma implementação gerida, confirme a plataforma de destino e a compatibilidade da pilha de aplicações específica, em vez de as deduzir pelo modelo de alojamento.

• Componente e referência da imagem
• Plataforma necessária e observada
• Fonte das evidências e data da verificação
• Modo de execução: nativo, emulado ou desconhecido
• Resultado do teste e limitações por resolver
• Responsável, ação seguinte e motivo para voltar a validar