Deploy de aplicações.NET Core com Docker e problemas de dependências

Recentemente, ao tentar rodar uma aplicação console .NET Core dentro de um container Docker, me deparei com um erro clássico: "Unable to load shared library 'kernel32.dll'". Isso costuma acontecer porque estamos tentando executar um binário que depende de DLLs específicas do Windows, em um ambiente Linux, o que não funciona.

No meu caso, a solução foi ajustar a imagem base do Docker para uma que seja compatível com o runtime do .NET Core, como a mcr.microsoft.com/dotnet/core/runtime. Além disso, verificar se o build está gerando uma versão compatível com o sistema de destino também ajuda bastante.

Essa questão evidencia como o ownership do deploy precisa ser mais consciente das dependências de ambiente, especialmente quando usamos containers. A automação do build e a escolha correta da imagem base evitam que problemas assim se tornem gargalos ou surpresas na hora do deploy. Sem esse critério, a solução pode parecer simples no começo e cara no suporte. O valor aparece melhor quando operação, produto e engenharia olham para o mesmo risco.

Na sua experiência, qual é o maior desafio ao fazer deploy de aplicações .NET em containers? Talvez o que mais pesa seja entender as dependências específicas ou o gerenciamento de configurações de ambiente. O valor aparece melhor quando operação, produto e engenharia olham para o mesmo risco. Por isso, o recorte precisa considerar manutenção, validação e caminho de volta. Esse contexto ajuda a separar ganho real de novidade difícil de sustentar. A decisão fica mais saudável quando o time consegue medir o impacto depois.