Plataforma e entrega
Levar aplicações de servidor Windows com IIS para containers em Kubernetes, num parque que já tinha entrega automatizada e precisa manter os dois mundos vivos por anos.
Onde o parque está
| Modelo de hospedagem | Aplicações |
|---|---|
| Servidor Windows com IIS | 194 |
| Kubernetes | 33 |
| Não classificado | 92 |
Repositórios meus já no modelo novo: 11%.
O que muda, e o que não muda
Esta distinção importa porque é fácil descrever a migração como se ela fosse mais do que é.
O que já existia antes: pipeline no GitLab CI com build, teste e publicação automatizados; código versionado; ambientes separados de homologação e produção; e rollback por reexecução da pipeline anterior, que sobrescreve os arquivos com a versão antiga. O processo de entrega não era manual e não mudou com a migração.
O que muda de fato:
- Onde a aplicação roda. Servidores Windows com IIS para as APIs, e um servidor separado para robôs e workers, dão lugar a containers de homologação e produção no cluster
- Como o worker agenda. Windows Schedule sai, e a periodicidade passa a ser declarada como CronJob do cluster. A aplicação não precisa estar sempre no ar para o relógio funcionar, e escala independente do serviço web
- Quem enxerga a saúde da aplicação. Antes dependia inteiramente da infraestrutura; hoje o time tem acesso, ainda que o monitoramento continue sendo do DevOps
- Como uma aplicação nasce. Existe um IDP que cria a aplicação a partir do template e já abre os tickets de DNS e banco de dados
O ganho real é ambiente reproduzível e autonomia operacional, não automação de deploy — isso já estava resolvido.
O modelo novo
commit → pipeline de CI → imagem no registry privado
→ commit de tag em repositório GitOps
→ ArgoCD sincroniza → cluster KubernetesDecisões que sustentam o desenho:
- Template de CI compartilhado. A mecânica de build, imagem e deploy vive num lugar só, e cada aplicação declara variáveis e inclui o template. É o mesmo princípio de biblioteca compartilhada aplicado a entrega, e é por isso que a imagem de produção não depende de cada repositório carregar o próprio Dockerfile
- Tag de imagem imutável. Regravar conteúdo diferente na mesma tag quebraria a sincronização em silêncio, então o pipeline recusa em vez de sobrescrever
- Helm parametrizado por ambiente, promovendo homologação para produção
O que eu faço
- Levar aplicação para o modelo novo, incluindo legado que não nasceu para contêiner
- Empacotar aplicação .NET em imagem e trabalhar com registry privado, versionamento e imutabilidade de tag
- Declarar worker como tarefa agendada do cluster, com a periodicidade fora do código da aplicação
- Diagnosticar entrega que falhou lendo pipeline, registry e estado de sincronização
- Usar contêiner efêmero em teste de integração, para provar comportamento contra banco real
- Subir dependência de desenvolvimento local por compose
Onde apliquei
Do servidor Windows para o cluster · Monitoramento industrial · Assinaturas e recorrência · Atendimento
O que eu ainda não fiz
Não administro o cluster: não escrevi os charts base, não configuro rede, política de segurança nem autoescala, não montei a esteira de GitOps e não sou dono do IDP. Sou consumidor competente da plataforma e participo das decisões de como as aplicações a usam. Também não tenho experiência com service mesh nem com observabilidade distribuída por tracing.