Imagem, container e configuração
Uma imagem é o artefato imutável usado para iniciar containers; o container é uma instância em execução. Evite embutir estado persistente, credenciais e configurações específicas de cada ambiente na imagem. Promova o mesmo artefato entre ambientes e injete configuração no deploy.
Dockerfile multi-stage
O estágio de SDK restaura e compila; o estágio final usa apenas o runtime necessário. Este exemplo supõe uma solução com projeto web em src/Web; ajuste caminhos e framework alvo ao seu repositório:
FROM mcr.microsoft.com/dotnet/sdk:10.0 AS build
WORKDIR /src
COPY . .
RUN dotnet restore src/Web/Web.csproj
RUN dotnet publish src/Web/Web.csproj -c Release -o /app/publish --no-restore
FROM mcr.microsoft.com/dotnet/aspnet:10.0 AS final
WORKDIR /app
COPY --from=build /app/publish .
ENV ASPNETCORE_HTTP_PORTS=8080
EXPOSE 8080
USER $APP_UID
ENTRYPOINT ["dotnet", "Web.dll"]Use tags compatíveis de SDK e runtime e mantenha-as alinhadas à versão suportada escolhida pelo projeto. Copiar a solução inteira antes de restaurar pode reduzir o reaproveitamento de cache; para otimizar builds, copie manifests primeiro, restaure, depois copie o restante. Não use tags flutuantes sem política de atualização e rastreabilidade.
Build context e .dockerignore
Exclua do contexto itens que não devem ser enviados ao daemon ou copiados para a imagem, como bin/, obj/, repositórios Git, arquivos locais e segredos. Um contexto pequeno melhora velocidade e reduz risco de incluir material acidentalmente. Revise também o que fica na camada final: multi-stage não remove arquivos que forem copiados explicitamente para ela.
Segredos e execução como usuário não root
Não passe senhas com ARG ou ENV no Dockerfile: elas podem ficar expostas em histórico ou metadados. Use os mecanismos de secrets do builder para necessidades de build e um cofre ou mecanismo seguro de configuração em runtime. Execute com usuário sem privilégios quando a imagem e a plataforma permitirem; valide permissões de arquivos e portas.
Desenvolvimento local com Compose
Compose pode iniciar API, banco e dependências locais com configuração reproduzível. Use volume para código somente no fluxo de desenvolvimento quando isso ajudar, mantenha dados de teste descartáveis e não confunda dependência iniciada com dependência pronta. Health checks e readiness devem testar a capacidade necessária, sem transformar startup lento em loop de reinício.
Containers também são úteis em testes de integração: veja ASP.NET Core e containers para testes. Para persistência, compare SQL Server e PostgreSQL.
Operação em produção
Configure limites de CPU e memória segundo medições, logs para stdout/stderr, encerramento gracioso e health endpoints apropriados. Um container não substitui monitoramento, backups, controle de acesso ou atualização de imagens. Acompanhe vulnerabilidades de dependências e imagens base.
Relacione essa prática com observabilidade, resiliência e autenticação de APIs.