Usando contêineres de desenvolvimento
Depois de usar contêineres dev como parte de sua cadeia de ferramentas padrão, você pode criar uma biblioteca de recursos que podem ser rapidamente adicionados às suas definições de contêiner. Você pode personalizar contêineres prontos para uso ou criar rapidamente uma nova definição para um novo projeto, tratando os recursos como blocos de construção que ficam em cima de um contêiner base padrão que foi definido para uma pilha específica.
O processo básico de construção de um contêiner de desenvolvimento faz muito sentido. É uma abordagem de cima para baixo, que precisa começar com arquitetos e líderes de desenvolvimento concordando com uma pilha de projetos. Você pode então encontrar uma imagem de plataforma base, digamos .Net, na galeria de contêineres do VS Code. Depois de obtê-la, você a personaliza para seu projeto, adicionando novas ferramentas editando o devcontainer.json no VS Code e adicionando recursos predefinidos. Quando o contêiner estiver pronto para uso, implante-o e as ferramentas VS Code necessárias para sua equipe de desenvolvimento.
Seu host de contêiner local precisa estar executando o Docker ou pelo menos ter uma CLI compatível com o Docker em cima de seu mecanismo. A CLI é essencial aqui, pois o contêiner de desenvolvimento funciona por meio dela em vez de precisar de acesso direto ao seu host de contêiner. Isso é um benefício e uma desvantagem: não há dependência de APIs ou mesmo do próprio Docker. Contanto que um ambiente de contêiner suporte a CLI do Docker, você pode usá-la com seus contêineres de desenvolvimento. No entanto, se não oferecer, você não pode. Isso significa que há problemas com mecanismos de contêiner alternativos, como o Podman, que suporta apenas um subconjunto da CLI do Docker. Claro, como os contêineres de desenvolvimento são um projeto de código aberto, há um trabalho contínuo para oferecer suporte a outros mecanismos de contêiner, e você pode fazer solicitações ou enviar código via GitHub.
