Azure Linux 4: Microsoft Lança Distro Baseada em Fedora

A Microsoft acaba de lançar o Azure Linux 4 em preview público, e dessa vez a história é diferente: pela primeira vez, a distribuição server da empresa não nasce de um fork interno isolado — ela é construída diretamente sobre o Fedora. Brendan Burns, co-criador do Kubernetes e VP corporativo do Azure OSS, fez o anúncio no Open Source Summit North America, em 18 de maio de 2026, e o recado é claro: o CBL-Mariner ficou no passado.

TL;DR

• O Azure Linux 4 abandona o packaging independente do CBL-Mariner e passa a derivar pacotes do Fedora Linux via overlays TOML.
• Primeira versão da família pensada para VMs Azure, não só containers do AKS.
• Ainda em preview público; lançamento amplo previsto para o Microsoft Build de junho/2026.
• Anúncio por Brendan Burns (co-fundador do Kubernetes, CVP de Azure OSS).
• Janela de suporte de 2 anos por release.

Por que a Microsoft trocou o CBL-Mariner pelo Fedora

O CBL-Mariner — rebatizado de Azure Linux nas versões 2 e 3 — sempre carregou um problema estrutural: era um fork. Cada pacote precisava ser empacotado, revisado e mantido pela própria equipe da Microsoft, mesmo quando o trabalho equivalente já tinha sido feito upstream por Red Hat, IBM e a comunidade Fedora. Em escala de uma distribuição inteira, isso vira custo operacional e atraso no pipeline de patches de segurança.

A decisão de rebasear sobre o Fedora resolve esse problema na raiz. O Fedora é a base upstream do Red Hat Enterprise Linux, tem um ciclo de release agressivo (cerca de seis meses) e um processo de segurança maduro, com revisão por uma comunidade enorme. Ao se ancorar ali, a Microsoft transfere o peso do bring-up de pacotes para um time muito maior e ganha uma cadeia de suprimento de software mais auditável.

Estrategicamente, há outra leitura: a Microsoft está consumindo o trabalho do ecossistema IBM/Red Hat sem pagar pelo RHEL. É uma jogada elegante — entrega Linux server gratuito para o cliente Azure, mantém compatibilidade RPM próxima do RHEL e tira pressão da própria engenharia. Para quem opera frotas grandes de VM no Azure, é exatamente o tipo de simplificação que faz diferença no fim do ano fiscal.

O que é o Azure Linux 4.0 — resumo técnico

O Azure Linux 4 é uma distribuição RPM-based, mantida pela Microsoft, com fontes derivadas do Fedora upstream. O código vive no repositório oficial em github.com/microsoft/azurelinux, no branch 4.0.

Estes são os fatos confirmados nos materiais oficiais e nas reportagens de cobertura:

• Build pipeline: ferramentas-padrão de empacotamento RPM — mock, rpmbuild e Koji.
• Modelo de packaging: arquivos de configuração TOML que descrevem overlays mínimos aplicados sobre o Fedora.
• SPEC files: gerados automaticamente e versionados no repositório, em vez de mantidos à mão. Isso torna auditável o que a Microsoft mudou em relação ao Fedora.
• Targets de carga: VMs, containers e bare metal — uma expansão clara em relação às versões 1, 2 e 3, que existiam principalmente para servir o AKS.
• Suporte: janela de dois anos por release.

A escolha pelo TOML e pelos overlays restritos é deliberada: a Microsoft quer evitar repetir o erro do Mariner, onde a divergência da upstream foi se acumulando ao longo dos anos. Quanto menor o overlay, mais fácil rebasear quando o Fedora avança de versão.

CBL-Mariner ainda vai existir? O destino do Azure Linux 3

Sim, por enquanto. A própria Microsoft recomenda Azure Linux 3 (Mariner) para cargas de produção hoje, justamente porque o 4 ainda está em preview e não há downloads liberados. Não há, até a data deste post (25/05/2026), uma data oficial de end-of-life para o Mariner — mas o sinal de mercado é inequívoco: a partir do momento em que o Azure Linux 4 sair do preview, o Mariner entra em modo manutenção.

Para quem já tem workload em produção no Mariner, dois caminhos práticos:

1. Manter no Mariner até o suporte oficial encerrar e migrar em janela planejada.
2. Validar a v4 em ambiente de staging assim que o preview público virar GA — algo esperado para o Microsoft Build em junho de 2026.

Não recomendamos migração precoce. Distro em preview muda contrato de pacote sem aviso, e isso quebra automação de deploy e monitoramento. Quem opera infraestrutura há tempo já passou por isso e sabe o custo de virar coelho de teste.

Como o Azure Linux 4 é construído sobre o Fedora

Tecnicamente, a distro funciona como um conjunto de overlays direcionados sobre o Fedora. Cada overlay altera apenas o que precisa ser específico do Azure — patches de kernel para integração com o hypervisor, configurações default de cloud-init, hardening específico, integrações nativas com Azure Arc, Defender for Cloud e Azure Monitor.

Os pacotes vêm direto dos repositórios upstream do Fedora. Isso significa que o ciclo de atualização de segurança não depende mais da Microsoft re-empacotar nada: quando o Fedora libera uma correção, a distro herda quase imediato, com tempo de propagação muito menor que o do antigo Mariner.

A escolha do TOML como linguagem de descrição não é estética. TOML é estritamente declarativo e auditável — qualquer pessoa pode ler o repositório e entender exatamente quais pacotes vêm do Fedora intactos e quais foram alterados, sem precisar interpretar lógica de build complexa em shell ou Python.

Para quem mantém infraestrutura, isso reduz o tempo de "como esta distro foi feita?" de horas para minutos. E para auditorias de compliance — comuns em governo, financeiro e saúde — vira um diferencial real na hora de aprovar a stack.

Onde rodar: VMs, AKS e Azure Container Linux

A família Azure Linux ganhou duas pernas distintas em 2026:

• Azure Linux 4 — distro geral baseada em Fedora, indicada para VMs Azure, AKS e bare metal.
• Azure Container Linux — distro imutável, derivada do Flatcar Container Linux, indicada para hosts de container em cenários regulados ou de segurança alta. Já está em disponibilidade geral (GA).

A diferença é importante e separa dois mundos:

Característica	Azure Linux 4	Azure Container Linux
Base	Fedora	Flatcar
Modelo	Tradicional (mutável)	Imutável, read-only
Package manager	Sim (RPM)	Não
Caso de uso	VMs, AKS, bare metal	Hosts de container hardened
Status	Preview público	GA

Para a maioria dos clientes Azure que rodam aplicações tradicionais — Java, .NET, PHP, Node, Python — essa é a escolha certa. Para quem quer um host minimalista, sem package manager, com atualizações atômicas (clássico esquema de partição A/B), o Azure Container Linux é o casamento certo.

Quem está por trás: Brendan Burns e a estratégia open source da Microsoft

O anúncio foi feito por Brendan Burns — e isso não é detalhe. Burns é co-fundador do Kubernetes, ex-engenheiro do Google, e hoje Corporate Vice President de Azure Open Source na Microsoft. Quando ele assina, a comunidade Linux escuta.

Há uma leitura institucional aqui que vai além do produto. Há cinco anos, "Microsoft Linux server distro" soaria como contradição de termos. Em 2026, a empresa mantém uma das maiores frotas Linux do mundo no Azure, contribui pesado para o kernel mainline, sustenta o WSL e agora opera uma distro própria derivada do Fedora. A guerra "Microsoft vs Linux" acabou — e a Microsoft ganhou ao parar de lutá-la.

Para o cliente final, isso se traduz em algo concreto: a chance de rodar workloads Linux no Azure com um vendor único, sem licença extra, com integração nativa com Azure Arc, Defender, Monitor e Update Manager. Menos contratos, menos pontos de falha, menos negociação no fim de ano.

Como o Azure Linux 4 afeta clientes Azure no Brasil

Para quem opera infraestrutura no Brasil — incluindo clientes que hospedam plataformas Moodle, APIs e e-commerces no Azure — a chegada da nova distro abre três possibilidades práticas:

1. Redução de custo de licença. Hoje, muita VM Linux no Azure roda Ubuntu Pro ou RHEL, com taxa extra de licenciamento por hora-VM. O Azure Linux é gratuito e otimizado para a Azure.
2. Simplificação de fornecedor. SLA, patches, integração com Defender for Cloud, atualizações via Azure Update Manager — tudo num único pescoço para apertar.
3. Compliance e LGPD. A integração de logs com Azure Monitor já vem ajustada por padrão. Não muda o que você precisa fazer para LGPD, mas elimina horas de configuração de agente. Vale lembrar que infra é só uma parte: a personalização do Moodle e do ecossistema mobile que entrega valor real continua sendo o que diferencia o produto, independente da distro abaixo.

A região Brazil South (São Paulo) já recebe a maioria das ofertas Azure no mesmo dia do anúncio global. Quando a v4 sair do preview, deve aparecer no marketplace de imagens local sem atraso significativo em relação aos Estados Unidos.

Comparativo: Azure Linux 4, Ubuntu Pro for Azure e RHEL on Azure

Para decidir distro de VM no Azure em 2026, o quadro ficou assim:

Critério	Azure Linux 4	Ubuntu Pro for Azure	RHEL on Azure
Mantenedor	Microsoft	Canonical	Red Hat (IBM)
Base	Fedora upstream	Ubuntu LTS	RHEL upstream
Modelo de licença	Gratuito	Pago (por hora/VM)	Pago (por hora/VM)
Suporte declarado	2 anos por release	até 10 anos (LTS + ESM)	10 anos
Estabilidade de release	Recente (preview)	Maduro	Maduro
Integração com Azure	Nativa, primeira-classe	Profunda	Profunda
Comunidade	Em construção	Enorme	Enorme (empresarial)

Quando escolher cada um:

• Azure Linux 4: workloads novos, ambientes onde reduzir custo de licença importa, equipes que já operam stack RPM e querem alinhamento com o roadmap Azure.
• Ubuntu Pro for Azure: workloads que dependem de pacotes do universo Debian/Ubuntu (snap, PPAs específicos, repositórios de terceiros que só publicam .deb), equipes habituadas ao apt.
• RHEL on Azure: ambientes regulados onde o cliente exige um vendor com 25 anos de track record de enterprise Linux e janela de suporte de uma década inteira.

Como testar o Azure Linux 4 antes do Build 2026

Como não há ainda imagem oficial no marketplace, quem quer experimentar precisa construir localmente a partir do repositório. O fluxo é o tradicional do mundo Fedora:

1. Clone do repo: git clone https://github.com/microsoft/azurelinux.git --branch 4.0
2. Instale mock e rpmbuild numa máquina Fedora ou RHEL recente.
3. Aplique os overlays TOML do repositório seguindo o README do branch 4.0.
4. Rode o target de build documentado para gerar uma imagem VHD utilizável em ambiente Hyper-V ou Azure VM.

Para quem só quer rodar, e não construir, a recomendação é objetiva: aguarde o anúncio do Microsoft Build em junho de 2026. A imagem deve aparecer no Azure Marketplace logo após, com botão de "Create VM" direto. Não vale a pena automatizar build local de uma distro em preview para produção — é tempo perdido em algo que vai mudar.

O que vem no Microsoft Build (junho/2026) e próximos passos

O Microsoft Build 2026 vai ser o palco oficial do rollout completo. O que esperar, com base no padrão Microsoft de lançamentos anteriores:

• Imagens oficiais no Marketplace com suporte do vendor.
• Templates ARM/Bicep prontos para deploy.
• Integração documentada com Azure Arc, Defender for Cloud, Update Manager e Azure Monitor.
• Provavelmente algum tooling de migração assistida do Mariner para a v4.
• Possíveis SKUs específicos para workloads de IA/GPU — dado o investimento da Microsoft em infra para OpenAI, Copilot e modelos próprios. É justamente nesse ponto que a v4 vira peça estratégica: a base de OS por trás da infraestrutura de IA da empresa.

Para CTOs e times de plataforma, a recomendação é simples: acompanhe, mas não migre ainda. Use o intervalo entre maio e o Build para mapear quais cargas atuais fariam sentido migrar, validar custos comparados ao Ubuntu Pro e desenhar o piloto. Quando a GA chegar, a decisão de migrar fica baseada em fato, não em hype.

Conclusão

O Azure Linux 4 marca um ponto de virada raro: a Microsoft saiu do "ter uma distro pra dizer que tem" para "operar Linux server seriamente, no mesmo ecossistema do Red Hat". A base Fedora reduz custo de manutenção, melhora velocidade de patches e abre porta para a maior frota Linux do mundo — a do Azure — receber uma alternativa nativa, gratuita e bem integrada.

Para quem opera infraestrutura, o próximo movimento útil não é migrar agora, e sim medir: quanto da sua frota atual no Azure roda Ubuntu Pro pagando licença extra? Quanto custaria essa frota num Azure Linux 4 gratuito, integrado e mantido pelo mesmo vendor que opera o hypervisor? Esse número vai pautar a decisão em Q3 e Q4 deste ano. E se você opera plataformas como o Voyia, vale lembrar que a economia real costuma vir da arquitetura — não só da infra abaixo dela.