Forem: Magalu Cloud

Regiões e Zonas de Disponibilidade na Magalu Cloud: como pensar resiliência desde o início

Magalu Cloud — Fri, 30 Jan 2026 16:30:39 +0000

Ao criar uma aplicação na nuvem, é comum focar primeiro no código, no sistema operacional ou no tipo de máquina virtual. No entanto, muitas indisponibilidades em produção não estão ligadas à aplicação em si, mas à forma como a infraestrutura foi planejada.

Pensar em resiliência desde o início significa entender onde seus recursos estão rodando fisicamente e como eles se comportam diante de falhas. Na Magalu Cloud, esse planejamento começa com dois conceitos fundamentais: Regiões e Zonas de Disponibilidade (Availability Zones).

Neste artigo, você vai entender como esses conceitos funcionam na prática e, ao final, aplicar esse conhecimento em um hands-on técnico, criando uma VM já preparada para cenários de falha e recuperação.

Conceito

Uma Região é uma área geográfica que concentra um ou mais datacenters. Na Magalu Cloud, as regiões estão localizadas no Brasil, o que garante menor latência, conformidade com a legislação nacional e maior previsibilidade operacional.

Dentro de cada região existem as Zonas de Disponibilidade (AZs). Cada AZ é um ambiente físico independente, com energia, refrigeração e conectividade próprias. Mesmo estando na mesma região, as zonas são isoladas entre si para reduzir o impacto de falhas físicas ou operacionais.

De forma simples, a região define onde sua aplicação está localizada, enquanto as zonas definem como ela pode se manter disponível mesmo quando algo não sai como esperado.

Quando pensar em Zonas de Disponibilidade

A escolha correta de região e zona é especialmente importante quando:

Sua aplicação não pode ficar indisponível por longos períodos
Você quer reduzir o impacto de falhas de infraestrutura
O ambiente tende a crescer com o tempo
Existe necessidade de recuperação rápida após erros ou manutenções

Mesmo em projetos pequenos ou ambientes de teste, entender essas decisões desde o início evita retrabalho e limitações futuras.

Como funciona na Magalu Cloud

Na Magalu Cloud, cada recurso é criado dentro de uma Zona de Disponibilidade específica. Máquinas virtuais, por exemplo, pertencem a uma única AZ, assim como seus volumes de Block Storage, que precisam estar obrigatoriamente na mesma zona da VM.

Isso significa que, se uma aplicação estiver concentrada em apenas uma AZ, ela ficará indisponível caso aquela zona enfrente problemas. Por outro lado, serviços como Object Storage já contam com replicação automática entre zonas, oferecendo maior durabilidade sem configuração adicional.

Essa diferença de comportamento entre os serviços é o que orienta as estratégias de resiliência.

Hands-on: criando uma VM resiliente desde o início

Para tornar esse conceito mais prático, vamos construir um cenário simples, mas extremamente comum: uma VM única, criada de forma consciente, com um plano claro de recuperação.

Passo 1: identificar as Zonas de Disponibilidade disponíveis

Antes de criar qualquer recurso, é importante saber quais AZs estão disponíveis para sua conta. Isso pode ser feito via CLI:

mgc profile availability-zones list

O resultado mostrará as zonas disponíveis na região, como br-se1-a, br-se1-b e br-se1-c. Esse passo é essencial, pois nem todos os serviços estão disponíveis em todas as zonas.

Passo 2: criar a VM em uma Zona de Disponibilidade específica

Ao criar a VM pelo Console da Magalu Cloud, selecione explicitamente:

A região desejada
Uma Zona de Disponibilidade específica
Uma imagem Linux oficial
Uma chave SSH para acesso

Nesse momento, a VM passa a existir fisicamente dentro daquela AZ. Essa decisão é importante porque define o nível inicial de resiliência da aplicação.

Passo 3: acessar a VM e validar o ambiente

Após a criação, acesse a VM via SSH:

ssh usuario@ip-publico-da-vm

Dentro da VM, crie um arquivo simples para representar o estado da aplicação:

echo "VM criada na AZ br-se1-a" > ambiente.txt

Esse arquivo servirá como referência para validar a recuperação posteriormente.

Passo 4: criar um snapshot como ponto de recuperação

Com a VM funcionando corretamente, crie um snapshot do disco.

Esse snapshot representa um estado conhecido e seguro da aplicação. Mais do que um backup, ele se torna um ponto estratégico de recuperação, permitindo recriar a VM rapidamente em caso de falhas, erros de configuração ou indisponibilidade da zona original.

Passo 5: recriar a VM a partir do snapshot em outra AZ

Agora vem o ponto-chave do hands-on. A partir do snapshot criado, crie uma nova VM escolhendo outra Zona de Disponibilidade da mesma região e utilize o snapshot como base do disco.

Após acessar a nova VM via SSH, valide o conteúdo:

cat ambiente.txt

Se o arquivo estiver presente, você confirmou na prática que o ambiente pôde ser recriado com sucesso em outra AZ, reduzindo a dependência de um único ponto físico.

O que esse hands-on demonstra

Ao final desse exercício, fica claro que:

Zonas de Disponibilidade impactam diretamente a arquitetura
Uma VM em uma única AZ é funcional, mas vulnerável
Snapshots são fundamentais para recuperação e continuidade
Resiliência pode ser pensada desde o primeiro recurso criado

Tudo isso sem exigir arquiteturas complexas ou serviços adicionais.

Boas práticas e cuidados

Ao planejar sua infraestrutura, sempre verifique previamente as AZs disponíveis e a compatibilidade dos serviços. Para máquinas virtuais, trate snapshots como parte do desenho da arquitetura, e não como um recurso opcional.

Lembre-se também de que volumes de Block Storage precisam estar na mesma AZ da VM, enquanto dados que exigem maior durabilidade podem se beneficiar do uso de Object Storage, que já possui replicação automática entre zonas.

Essas decisões simples, quando tomadas desde o início, aumentam significativamente a confiabilidade do ambiente.

Conclusão

Regiões e Zonas de Disponibilidade são pilares fundamentais para construir aplicações resilientes na Magalu Cloud. Entender como esses conceitos funcionam e aplicá-los desde o primeiro recurso criado permite reduzir riscos, facilitar a recuperação e preparar o ambiente para crescer com segurança.

Pensar resiliência desde o início não significa complicar a arquitetura, mas sim fazer escolhas conscientes que farão diferença quando sua aplicação realmente precisar.

Acessando e protegendo sua VM: SSH, snapshots e boas práticas iniciais

Magalu Cloud — Fri, 23 Jan 2026 18:44:54 +0000

Criar uma máquina virtual é apenas o primeiro passo para rodar aplicações na nuvem. Logo após o provisionamento, surgem duas necessidades fundamentais: acessar a VM com segurança e garantir proteção contra falhas, erros ou perdas de dados.

Na Magalu Cloud, esses dois pontos são atendidos de forma nativa por meio do uso de chaves SSH para acesso seguro e snapshots para recuperação rápida. Combinados a algumas boas práticas iniciais, esses recursos ajudam a criar um ambiente mais confiável desde o primeiro dia.

Neste artigo, você vai entender como acessar sua VM via SSH, como e por que usar snapshots e quais cuidados iniciais adotar para proteger seu ambiente.

Acesso seguro a VMs

Em ambientes Linux, o acesso remoto a uma máquina virtual é feito via SSH (Secure Shell). Diferente do uso de senhas, o SSH utiliza criptografia por chave pública e privada, reduzindo drasticamente o risco de acessos não autorizados.

Na Magalu Cloud, o acesso inicial às VMs Linux é realizado exclusivamente por chaves SSH, sem senhas padrão embutidas no sistema.

Proteção do estado da máquina

Já os snapshots funcionam como uma “fotografia” do estado atual de uma VM ou de um volume de armazenamento. Eles permitem restaurar o ambiente exatamente como estava em um determinado momento, sendo fundamentais para:

Recuperação após falhas
Reversão de alterações problemáticas
Criação de ambientes clonados

Acesso via SSH

Durante a criação de uma VM Linux na Magalu Cloud, você define uma chave SSH, que pode ser:

Gerada no próprio processo de criação da instância
Reutilizada a partir de uma chave já existente na sua conta

Essa chave pública é automaticamente configurada na VM por meio do cloud-init, permitindo que apenas quem possui a chave privada correspondente consiga acessar o servidor.

Após a VM estar em execução, o acesso é feito diretamente pelo terminal:

ssh usuario@ip-publico-da-vm

O nome do usuário depende da imagem escolhida (por exemplo, ubuntu em imagens Ubuntu).

Snapshots de máquinas virtuais

Os snapshots podem ser criados a partir do disco da VM ou de volumes de Block Storage associados. Eles capturam o estado do disco no momento da criação e ficam disponíveis para restauração posterior.

Na prática, os snapshots permitem:

Restaurar uma VM após falha ou erro humano
Criar uma nova VM baseada em um estado conhecido
Preservar um ponto seguro antes de mudanças importantes

Os snapshots são especialmente importantes em ambientes criados em uma única Zona de Disponibilidade, pois facilitam a recuperação rápida em caso de problemas.

Exemplo prático

Fluxo recomendado após criar uma VM

Criar a VM definindo uma chave SSH
Acessar a VM via SSH a partir do seu computador
Aplicar atualizações básicas do sistema operacional
Criar um snapshot inicial da VM
Prosseguir com a instalação de aplicações e serviços

Esse snapshot inicial funciona como um “ponto de retorno” limpo e confiável.

Boas práticas e cuidados

Acesso e autenticação

Utilize sempre chaves SSH fortes e protegidas
Nunca compartilhe sua chave privada
Evite conceder acesso desnecessário a usuários da conta
Revise periodicamente as permissões de acesso

Snapshots e recuperação

Crie snapshots antes de qualquer atualização crítica
Mantenha snapshots periódicos em ambientes importantes
Não dependa de um único snapshot antigo
Combine snapshots com uma estratégia de organização e limpeza

Segurança inicial da VM

Atualize o sistema logo após o primeiro acesso
Remova serviços que não serão utilizados
Limite a exposição de portas de rede apenas ao necessário
Utilize VPC e regras de segurança para isolar o ambiente

Essas práticas reduzem a superfície de ataque e aumentam a estabilidade do ambiente.

Conclusão

A segurança e a confiabilidade de uma máquina virtual começam nos primeiros minutos após sua criação. Ao utilizar chaves SSH para acesso seguro, snapshots para proteção do estado da VM e boas práticas iniciais, você constrói uma base sólida para suas aplicações na Magalu Cloud.

Esses recursos, aliados à infraestrutura local no Brasil, preços em reais e suporte em português, permitem que desenvolvedores tenham controle, previsibilidade e tranquilidade desde o início do projeto.

Antes de avançar para configurações mais complexas, garantir esse básico bem feito faz toda a diferença no dia a dia.

Máquinas virtuais na Magalu Cloud: conceitos essenciais e criação

Magalu Cloud — Thu, 15 Jan 2026 19:23:18 +0000

Máquinas virtuais (VMs) são a base da computação em nuvem para execução de aplicações, serviços e ambientes de desenvolvimento com isolamento, previsibilidade e controle total do sistema operacional.

Na Magalu Cloud, a criação de VMs é feita por meio de uma interface gráfica simples e objetiva no Console, permitindo que desenvolvedores configurem todos os aspectos essenciais da instância como sistema operacional, capacidade de processamento, rede e acesso em poucos passos.

Neste artigo, você vai entender os conceitos fundamentais por trás das VMs e acompanhar, passo a passo, como criar uma VM Linux usando a interface de criação de instâncias.

O que são máquinas virtuais?

Uma máquina virtual é um servidor definido por software que executa sobre a infraestrutura física da nuvem. Ela funciona como um computador completo, com recursos dedicados e isolamento garantido, mesmo compartilhando o mesmo datacenter com outras VMs.

Cada VM possui:

Sistema operacional próprio (Linux ou Windows)
vCPUs (processadores virtuais)
Memória RAM dedicada
Disco de armazenamento

Esse modelo permite criar e remover servidores sob demanda, ajustando recursos conforme a necessidade da aplicação.

Na Magalu Cloud, a criação de uma VM é feita a partir de imagens, que são modelos prontos de sistemas operacionais mantidos pela plataforma. Essas imagens já vêm preparadas para inicialização automática e configuração inicial.

Quando usar máquinas virtuais?

As máquinas virtuais são indicadas quando é necessário controle total sobre o sistema operacional e previsibilidade de recursos, sendo adequadas para executar aplicações web, APIs, serviços de back-end e sistemas legados.

Elas também são uma boa escolha para ambientes de desenvolvimento, teste e homologação, além de cenários que exigem isolamento entre aplicações e integração direta com recursos de computação, armazenamento e conectividade da nuvem.

Criando uma VM Linux no Console

A seguir, vamos percorrer cada seção da tela Criar instância, considerando a interface apresentada no Console da Magalu Cloud.

1. Escolha da zona de disponibilidade

O primeiro passo é selecionar a Zona de Disponibilidade (AZ), como:

br-se1-a
br-se1-b
br-se1-c

A zona representa uma unidade física independente dentro da região. Para ambientes simples, qualquer zona disponível atende bem. Em arquiteturas mais avançadas, a distribuição de VMs entre zonas ajuda a aumentar a resiliência.

2. Escolha da imagem

Na seção Escolha uma imagem, você define o sistema operacional da VM. A Magalu Cloud oferece imagens oficiais, prontas para uso, como:

Ubuntu
Oracle Linux
Rocky Linux
Debian
Fedora
openSUSE
Windows Server

Para este exemplo, selecione uma distribuição Linux, como Ubuntu. As imagens Linux utilizam cloud-init para aplicar automaticamente configurações iniciais, como a chave SSH.

3. GPU (opcional)

Caso a aplicação exija aceleração gráfica ou processamento para IA, é possível marcar a opção Habilitar GPU, sujeita à disponibilidade na zona selecionada.

Se não houver essa necessidade, essa opção pode ser mantida desabilitada.

4. Escolha do tipo de instância

Na seção Escolha um tipo de instância, as VMs são organizadas por perfil de memória e classe de performance:

Low Memory
Standard Memory
High Memory

Cada opção exibe claramente:

Quantidade de vCPUs
Memória RAM
Valor por hora
Estimativa mensal

Por exemplo, um perfil equilibrado pode ser indicado para:

Aplicações gerais
Servidores web
Ambientes de desenvolvimento e teste

Também é possível ajustar o tamanho do disco local, como 10 GB, diretamente nessa etapa.

5. Conectividade e acesso público

Na seção Conectividade, você define como a VM será acessada pela rede:

O IPv6 público é gerado automaticamente após a criação
É possível marcar a opção Atribuir IPv4 público para essa instância, caso seja necessário acesso direto via internet

Essa escolha depende do cenário da aplicação e dos requisitos de conectividade.

6. Chave SSH

Para VMs Linux, o acesso é feito exclusivamente por chave SSH.

Na seção Chave SSH, você pode:

Selecionar uma chave já utilizada anteriormente
Inserir uma nova chave pública SSH

Essa chave será configurada automaticamente no sistema operacional durante a inicialização da VM. Não há senha padrão para acesso.

7. Nome da instância

Por fim, informe o Nome da instância, seguindo as regras indicadas no Console:

Entre 3 e 50 caracteres
Letras minúsculas, números, hífen (-) e underline (_)

Esse nome ajuda na organização e identificação das VMs no ambiente.

Após preencher todos os campos obrigatórios, clique em Criar instância. A Magalu Cloud inicia automaticamente o provisionamento da VM, que em poucos minutos estará pronta para uso.

Boas práticas e cuidados

Ao trabalhar com VMs na Magalu Cloud, priorize o uso de chaves SSH seguras, escolha tipos de instância compatíveis com a carga da aplicação e utilize snapshots antes de alterações relevantes no sistema.

Também é importante limitar o acesso de rede ao mínimo necessário e revisar periodicamente as instâncias em execução, removendo recursos ociosos para manter o ambiente seguro, organizado e com custos sob controle.

As VMs da Magalu Cloud oferecem uma base sólida para executar aplicações com controle, simplicidade e previsibilidade. A interface de criação de instâncias foi pensada para guiar o desenvolvedor por todas as decisões técnicas essenciais, sem complexidade desnecessária.

Ao entender cada etapa da criação de uma VM Linux, você ganha autonomia para montar ambientes confiáveis, escaláveis e alinhados às necessidades reais da sua aplicação, aproveitando uma infraestrutura local, com preços em reais e suporte próximo do ecossistema brasileiro.

O que é a Magalu Cloud e como usar o Console e a CLI no dia a dia

Magalu Cloud — Thu, 08 Jan 2026 19:01:16 +0000

A computação em nuvem deixou de ser um tema restrito a grandes empresas e passou a fazer parte do cotidiano de desenvolvedores, startups e times técnicos de todos os tamanhos. Nesse contexto, não basta saber o que é nuvem: é fundamental entender como uma plataforma funciona na prática e como interagir com ela no dia a dia.

Neste artigo, você vai conhecer a Magalu Cloud, entender seu posicionamento como nuvem pública brasileira e aprender, de forma prática, como trabalhar com a plataforma usando o Console e a CLI. Ao final, a ideia é simples: você deve saber onde está, como navegar e como executar ações básicas com segurança e previsibilidade.

Entendendo o que é a Magalu Cloud

A Magalu Cloud é uma nuvem pública desenvolvida para oferecer serviços de computação, armazenamento, rede e governança com foco direto no mercado brasileiro. A plataforma foi pensada desde o início para operar com infraestrutura localizada no Brasil, preços em reais e total aderência à legislação nacional.

Na prática, isso se reflete em alguns pontos importantes para quem desenvolve e opera sistemas. A proximidade física dos datacenters reduz a latência de aplicações voltadas ao público brasileiro. A cobrança em moeda local traz previsibilidade financeira e facilita o planejamento de custos. O suporte técnico acontece em português e a plataforma adota uma abordagem aberta, com APIs, CLI e integração com ferramentas de automação amplamente utilizadas no mercado.

Mais do que abstrair a complexidade da nuvem, a proposta da Magalu Cloud é torná-la compreensível e controlável, permitindo que o desenvolvedor entenda claramente o que está criando, como os recursos se relacionam e quais impactos técnicos e operacionais isso traz.

Console e CLI: duas formas de usar a plataforma

Toda interação com a Magalu Cloud acontece, basicamente, de duas maneiras: pelo Console, que é a interface web gráfica, e pela CLI, que é a interface de linha de comando. Essas duas abordagens não competem entre si. Elas atendem a momentos diferentes da jornada técnica e, na prática, costumam ser usadas de forma complementar.

O Console é o caminho mais natural para o primeiro contato. Ele facilita a exploração da plataforma, ajuda a entender como os serviços estão organizados e permite criar recursos manualmente com mais segurança visual. Já a CLI entra em cena quando surge a necessidade de repetição, automação ou maior controle sobre o fluxo de operações.

Usando o Console da Magalu Cloud no dia a dia

O Console é a interface gráfica da Magalu Cloud, acessada pelo navegador. É por ele que muitos desenvolvedores têm o primeiro contato com a plataforma e começam a entender como os serviços se organizam.

Ao acessar o Console, você encontra um painel central que agrupa os serviços. Antes de criar qualquer recurso, vale dedicar alguns minutos apenas para navegar. Explore os menus, leia as descrições dos serviços e observe como eles se relacionam.

O Console é especialmente útil para esse momento de aprendizado e para criações pontuais, quando você quer validar opções, entender campos de configuração e visualizar o impacto das escolhas que está fazendo.

Trabalhando com a CLI da Magalu Cloud de forma prática

A CLI da Magalu Cloud é a ferramenta que permite interagir com a plataforma diretamente pelo terminal. Ela é essencial para quem busca produtividade, automação e consistência nos ambientes.

Para instalar a CLI, você pode seguir os passos da documentação. Após a instalação, o primeiro passo é autenticar sua conta, com o comando mgc auth login.

Esse processo cria uma sessão local vinculada à sua identidade na Magalu Cloud e permite que os comandos executados no terminal tenham efeito real sobre os recursos da sua conta.

Um bom ponto de partida é confirmar qual conta (tenant) está ativa no seu ambiente local. Para isso, você pode executar:

mgc auth tenant current

Esse comando retorna informações sobre o tenant autenticado, incluindo um identificador único. Conferir esse dado antes de criar ou alterar recursos é uma boa prática, especialmente se você trabalha com mais de uma conta ou ambiente.

A partir daí, a CLI passa a ser uma forma objetiva de consultar e operar recursos. Por exemplo, listar zonas de disponibilidade disponíveis ajuda a entender onde seus recursos podem ser criados:

mgc profile availability-zones list

A saída desses comandos geralmente vem em formato estruturado, o que facilita tanto a leitura quanto o uso em scripts. Com o tempo, é comum combinar a CLI com ferramentas de automação, mas mesmo em uso manual ela já traz ganhos importantes: menos cliques, mais previsibilidade e facilidade para repetir operações.

Mesmo que você ainda prefira o Console, usar a CLI desde cedo para consultas simples e validações ajuda a criar familiaridade com a ferramenta e prepara o terreno para cenários mais avançados, como automação e infraestrutura como código.

Como escolher entre Console e CLI

Na prática, a escolha entre Console e CLI não é uma questão de certo ou errado. O Console costuma ser mais indicado para exploração, aprendizado inicial e criações manuais pontuais. A CLI, por outro lado, se destaca quando você precisa repetir tarefas, automatizar fluxos ou garantir que operações sejam executadas sempre da mesma forma.

No dia a dia, muitos times usam o Console para entender e validar configurações e recorrem à CLI para executar e manter ambientes. Essa combinação oferece equilíbrio entre clareza visual e eficiência operacional.

Conclusão

Antes de pensar em arquiteturas complexas, é essencial compreender a plataforma, as ferramentas disponíveis e a forma correta de interagir com elas. A Magalu Cloud oferece uma interface gráfica acessível e uma CLI poderosa, permitindo que desenvolvedores escolham a abordagem mais adequada para cada momento.

Dominar essas duas formas de uso desde o início torna a experiência em nuvem mais segura, previsível e eficiente, além de preparar o caminho para soluções mais robustas no futuro.

Como ter um modelo de IA utilizando GPU na Magalu Cloud

Magalu Cloud — Thu, 16 Oct 2025 17:14:03 +0000

Autor: Cleverson Gallego - Sr. Technical Product Manager

Os modelos de linguagem (LLMs e SLMs) estão cada vez mais acessíveis, mas configurá-los em ambientes otimizados de GPU e armazenamento ainda pode ser um desafio.

Com a Magalu Cloud, é possível criar em poucos minutos uma instância com GPU, anexar volumes NVMe via Block Storage e executar inferência com alta performance e baixa latência, tudo isso com privacidade e previsibilidade de custos.

Neste guia, vamos demonstrar passo a passo como configurar um ambiente para inferência com modelos como Gemma 3 27B, Mistral 7B, dentre outros.

Pré-requisitos

Antes de iniciar, será necessário:

Um tenant ativo na Magalu Cloud;
CLI instalada e autenticada;
Conhecimento básico em Linux, Ansible e Ollama.

Escolhendo o modelo certo

Entender essa relação é essencial para dimensionar corretamente o ambiente, evitando custos desnecessários e garantindo o máximo desempenho por GPU.

Antes de selecionarmos a Virtual Machine e a GPU que iremos utilizar é importante termos em mente alguns pontos:

Qual será o caso de uso para o modelo?
Qual modelo irei utilizar?
Qual a quantidade ideal de parâmetros para meu caso de uso?

Os parâmetros de um modelo (por exemplo, 27 bilhões do Gemma 3, da Google) são os valores numéricos aprendidos durante o treinamento do modelo e definem o comportamento interno da rede neural do modelo.

Eles incluem:

Pesos (weights): coeficientes que determinam a força entre neurônios artificiais;
Biases: ajustes adicionais usados para deslocar as ativações das camadas.

Para simplificar: “Parâmetros são o ‘conhecimento condensado’ que o modelo aprendeu ao ser treinado sobre grandes volumes de dados.”

Um modelo com mais parâmetros é, em geral, mais expressivo e capaz de lidar com contextos complexos, mas isso não o torna automaticamente o melhor para todos os tipos de tarefas; portanto, é necessário escolher o modelo com sabedoria, de acordo com o hardware e o caso de uso.

Modelos de linguagem como o Gemma 3 27B, Mistral 7B ou Llama 3 70B são redes neurais massivas compostas por bilhões de parâmetros, e cada parâmetro ocupa espaço em memória da GPU durante a inferência.

Essa relação é direta!

Quanto maior o modelo, maior a memória VRAM necessária, maior a GPU (ou o número de GPUs) exigida(s).

Para estimar corretamente o consumo de memória vamos utilizar uma prática da comunidade:

memória VRAM necessária = [ N Parâmetros ] x [ 2 bytes ] x [ fator de otimização ]

O fator de otimização depende da quantização utilizada no modelo.

Quantização é o processo de reduzir a precisão numérica dos parâmetros, normalmente convertendo números em ponto flutuante (FP) de 16 ou 32 bits que ocupam mais memória em versões compactadas como 8, 4 ou até 2 bits.

Tipo de quantização	Descrição	Fator aproximado
FP16	2 bytes por parâmetro	2,0
INT8	1 byte por parâmetro	1,0
Q4_K_M	4 bits ( ~0,5 bytes por parâmetro )	0,5

A quantização é o que permite rodar modelos grandes em GPUs menores — sem sacrificar qualidade de forma perceptível.

Por exemplo, um modelo de 27 bilhões de parâmetros ( Gemma 3 27B ) quantizado em Q4_K_M exigirá: 27 B x 0,5 = ~ 13.5 GB de VRAM

Em resumo, utilizando uma NVIDIA L40 ou L40S, que são as GPUs disponíveis nesta data na Magalu Cloud é seguro dizer que são confortáveis:

FP16: modelos de 14-19B;
INT8: modelos de 29-38B;
Q4: modelos de 58-76B (70B fica no limite com 1 GPU somente (batch=1 e contexto curto)). Para uso confortável prefira 2xL40/L40S.

Recomendações práticas:

Modelos de até 7B: uma GPU L40 ou L40S é suficiente mesmo em FP16;
Modelos de 20-30B: use quantização (Q4 ou INT8) em uma GPU L40 ou L40S;
Modelos acima de 40B: prefira usar 2 GPUs L40S.

Criando a Virtual Machine com GPU e Block Storage

A criação da VM com GPU é o ponto de partida do nosso ambiente de inferência.

Neste exemplo, vamos provisionar uma instância com GPU L40 (flavor L40x1-DP8-64-100) e anexar um volume de Block Storage NVMe 20K IOPS de 500 GB para armazenar os modelos.

Para maiores detalhes dos passos necessários para a criação da VM, consulte nossa documentação oficial.

Agora, para a criação do volume, é importante levar em consideração a quantidade de modelos e, conforme já comentamos, a quantidade de parâmetros. Quanto mais parâmetros, mais espaço o modelo irá ocupar no volume, então maior precisará ser o mesmo. Para o exemplo vamos criar um volume de 500GB com 20K IOPS:

mgc block-storage volumes create --type.name="cloud_nvme20k" --name="modelos" --size=500 --availability-zone br-se1-c

O próximo passo é anexar o volume criado a VM:

mgc block-storage volumes attach --id b74d1968-dd43-4136-ab63-193fcc1111111 --virtual-machine-id 278e412d-af9a-4348-ab76-bfc111111111

Comandos úteis

Para verificar o id da instância desejada:

mgc vm instances list

Para verificar o id do volume desejado:

mgc block-storage volumes list

Pronto, agora você já tem sua VM criada com GPU e armazenamento. Agora é hora de instalarmos e configurarmos o modelo.

Configurando o ambiente com Ansible

Serão executados os seguintes passos na VM, com auxílio do Ansible:

Instalação e configuração de pacotes de sistema;
Instalação de CUDA e NVIDIA Drivers;
Instalação e configuração Ollama;
Deploy do modelo Gemma 3 7B;

Observação: deve-se realizar a instalação do Ansible em uma máquina com acesso à internet antes da execução dos passos.

Dica de segurança: para ambientes de produção, recomenda-se usar chaves SSH com acesso restrito e limitar as portas abertas.

Consulte a documentação oficial da Magalu Cloud para boas práticas de segurança.

Após a instalação do ansible alterar o arquivo inventory.ini:

[inference]
[ip da vm] ansible_user=ubuntu ansible_ssh_private_key_file=[~/.ssh/id_rsa.pem]

Onde:

[ip da vm] deve ser substituído pelo ip público da sua VM;
[~/.ssh/id_rsa.pem] deve ser substituído pelo arquivo que contém a chave privada configurada para acessoa a sua VM.

Você pode conferir o Ansible necessário para a instalação clicando aqui.

Logo após, executar no terminal:

ansible-playbook -i [inventory.ini] [playbook_gemma_3_27b_ollama_GPU.yaml]

Onde inventory.ini é o arquivo modificado com o ip e chave privada ssh e playbook_gemma_3_27b_ollama_GPU.yaml é o arquivo Ansible com o conteúdo acima.

Após a execução a saída do terminal deve ser algo parecido com o texto abaixo:

magalu@WNLEC-GSLR6Q3 ~/i/ansible> ansible-playbook -i inventory.ini playbook_gemma_3_27b_ollama_GPU.yaml

PLAY [Setup llama.cpp CPU inference environment with external access] ************************************************************************************************************************

TASK [Gathering Facts] ***********************************************************************************************************************************************************************
The authenticity of host 'ip (ip)' can't be established.
ED25519 key fingerprint is SHA256:.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
ok: [ip]

TASK [Install system packages] ***************************************************************************************************************************************************************
changed: [ip]

TASK [Clone llama.cpp repository] ************************************************************************************************************************************************************
changed: [ip]

...

Testando a inferência

Após finalizado, testar com http://[ip]:8000. O resultado deve ser algo parecido com:

Ollama is running

Para confirmar vamos invocar usando curl o modelo:

curl http://[IP_VM]:8000/v1/chat/completions     -H "Content-Type: application/json"     -d '{
                                    "model": "gemma3",
                                    "messages": [
                                        {
                                            "role": "system",
                                            "content": "You are a helpful assistant."
                                        },
                                        {
                                            "role": "user",
                                            "content": "Hello!"
                                        }
                                    ]
                                }'

O resultado deve ser:

{"id":"chatcmpl-640","object":"chat.completion","created":1760036029,"model":"gemma3:27b","system_fingerprint":"fp_ollama","choices":[{"index":0,"message":{"role":"assistant","content":"Hello there! 👋 \n\nIt's nice to meet you! I'm here to help in any way I can. Just let me know what you need – whether it's answering a question, brainstorming ideas, writing something, or just having a conversation. \n\nWhat can I do for you today?\n\n\n\n"},"finish_reason":"stop"}],"usage":{"prompt_tokens":22,"completion_tokens":66,"total_tokens":88}}

Conclusão

Agora você tem um ambiente completo de inferência com GPU, Block Storage NVMe e Ollama configurado automaticamente via Ansible.

Acesse o console da Magalu Cloud e teste seu primeiro modelo Gemma ou Mistral com aceleração total.

Queremos saber o que você vai criar com seu modelo! Compartilhe seu projeto conosco.

Como fazer deploy com Dokku na Magalu Cloud

Magalu Cloud — Wed, 08 Oct 2025 17:43:27 +0000

Autor: Junior Carvalho (LinkedIn, Dev.to)
Repositório: python-django-example

Se você trabalha com Python/Django, já deve ter sentido o atrito que pode ser levar sua aplicação do ambiente de desenvolvimento para um servidor de produção. Você quer focar no código, mas se vê preso em um mar de configurações de servidor.

É aqui que o Dokku entra em ação, transformando um processo complicado em algo rápido e eficiente. Dokku é uma PaaS (Platform as a Service) minimalista que permite que você faça o deploy de suas aplicações via Git Push, de forma semelhante ao Heroku, mas em sua própria máquina virtual.

Este artigo apresenta um tutorial passo a passo para que você possa fazer o deploy de seu projeto Python/Django em uma máquina virtual da Magalu Cloud utilizando o Dokku. Você aprenderá a configurar o ambiente, instalar o Dokku, gerenciar chaves SSH, configurar o banco de dados PostgreSQL e as variáveis de ambiente necessárias para ter sua aplicação rodando em produção de forma elegante e descomplicada.

Pré-requisitos

Conta ativa na Magalu Cloud com acesso ao painel de criação de máquinas virtuais.
Máquina virtual criada (exemplo: BV2-2-10 com Ubuntu 24.04 LTS, 2vCPU, 2GB RAM e 10GB disco local).
Acesso ao terminal com SSH configurado.
Git instalado na máquina de desenvolvimento.
Projeto de exemplo em Python/Django disponível: python-django-example.

Preparando o ambiente

Nesse tutorial vamos utilizar uma máquina virtual na Magalu Cloud. Uma máquina BV2-2-10, 2vCpu, 2GB de ram e 10GB de tamanho de disco local com Ubuntu 24.04 LTS.

A documentação completa de uso na Magalu Cloud pode ser visualizada aqui: Documentação Magalu Cloud. E aqui um vídeo que mostra como criar uma máquina virtual: Como criar uma máquina virtual.

Para exemplificar, vou utilizar um projeto simples em Python, Django e django-rest-framework. Esse projeto provê apenas um endpoint ‘status’ retornando uma resposta json.

Projeto disponível aqui: python-django-example

1. Instalando o Dokku

Após criar a máquina virtual na Magalu Cloud vamos realizar o acesso via SSH pelo terminal. Vou utilizar ssh padrão de terminal, mas é possível utilizar outros clientes ssh como o Putty.

ssh ubuntu@201.23.72.173

No primeiro acesso confirme o questionamento sobre a autenticidade digitando ‘yes’.

ED25519 key fingerprint is SHA256:tbnvJ/WRO/vbi95X7D+M0mHAZq3pIo1wI39VprSnx5Y.This key is not known by any other names.Are you sure you want to continue connecting (yes/no/[fingerprint])?

Conforme a documentação do Dokku, use os seguintes comandos para realizar a instalação:

wget -NP . https://dokku.com/bootstrap.sh  
sudo DOKKU_TAG=v0.36.7 bash bootstrap.sh

2. Configurando a chave SSH

Precisamos configurar no Dokku a chave pública para que seja possível executar o deploy.

Na nossa máquina de desenvolvimento, vamos checar se nosso usuário tem uma chave pública:

ls -al ~/.ssh

Caso não tenha nenhum arquivo .pub , pode gerar com o comando:

ssh-keygen -t rsa

No meu caso eu tenho um id_rsa.pub. Vou ler o conteúdo, selecioná-lo e copiar:

cat ~/.ssh/id_rsa.pub

Com o conteúdo do arquivo copiado, vamos executar o comando na máquina remota:

echo 'CONTENTS_OF_ID_RSA_PUB_FILE' | sudo dokku ssh-keys:add admin

Aqui, CONTENTS_OF_ID_RSA_PUB_FILE é igual a chave copiada da máquina de desenvolvimento.

Confirme se a chave foi criada com o comando:

dokku ssh-keys:list

3. Criando a aplicação

No terminal, conectado na nossa máquina virtual:

dokku apps:create python-django-example

Para listar os apps existentes:

dokku apps

Quando criamos um novo aplicativo, por padrão o Dokku não fornece nenhum banco de dados como MySQL ou PostgreSQL. É preciso instalar plugins. Existem plugins oficiais para banco de dados. Nesse exemplo vou utilizar o PostgreSQL.

PostgreSQL

Instale o plugin Postgres:

sudo dokku plugin:install https://github.com/dokku/dokku-postgres.git

Crie o serviço postgres:

dokku postgres:create database

Agora, vamos criar o link entre os serviços de banco de dados e nossa app.

dokku postgres:link database python-django-example

Após esse comando vai ser criado automaticamente a variável DATABASE_URL em nosso app.

4. Configurando variáveis de ambiente

Temos que configurar algumas variáveis de ambiente em nosso app. Como estamos usando Django, vamos criar SECRET_KEY e DEBUG. Acesse a documentação environment-variables para mais informações.

dokku config:set python-django-example DEBUG='False'  
dokku config:set python-django-example SECRET_KEY='sua secret_key'  
dokku config:set python-django-example ALLOWED_HOSTS='127.0.0.1, .localhost,201.23.72.173'

Observação: Precisamos adicionar o IP do servidor em ALLOWED_HOSTS, no caso do exemplo o IP é o 201.23.72.173`.

Para listar as variáveis de ambiente de nossa app: dokku config python-django-example

5. Executando o primeiro deploy

Na nossa máquina de desenvolvimento vamos configurar o git para fazer o primeiro deploy. Vamos adicionar nosso repositório remoto Dokku da seguinte forma:

git remote add dokku dokku@[IP-do-servidor]:[nome-app]

No contexto do nosso projeto de exemplo, o comando fica:

git remote add dokku dokku@201.23.72.173:python-django-example

Em seguida, execute o deploy: git push dokku main

6. Criando as tabelas do banco de dados

Nossa aplicação está no ar, mas ainda não tem as tabelas de nossa base de dados. Na máquina virtual execute:

dokku run python-django-example python manage.py migrate

Para criar um super usuário admin do Django:

dokku run python-django-example python manage.py createsuperuser

7. Configurando o domínio

Precisamos configurar o domínio para conseguir acessar o servidor. No nosso exemplo não temos URL então vamos configurar o acesso pelo IP mesmo.

Onde 201.23.72.173 é o ip do servidor.

dokku domains:add python-django-example 201.23.72.173
dokku ps:restart python-django-example

Caso tenha uma URL, por exemplo: django-example.com.br:

dokku domains:add python-django-example django-example.com.br
dokku config:set python-django-example ALLOWED_HOSTS="django-example.com.br,127.0.0.1, .localhost"
dokku ps:restart python-django-example

8. Acessando a aplicação

Com todas as etapas de deploy, migração do banco de dados e configuração de domínio concluídas, sua aplicação Python/Django está no ar na Magalu Cloud!

Agora, você pode acessar as diferentes partes da sua aplicação diretamente pelo navegador. Utilize o endereço IP do seu servidor (neste exemplo, 201.23.72.173) para acessar tanto a interface administrativa do Django quanto o endpoint da sua API de exemplo:

Admin Django: http://201.23.72.173/admin

API: http://201.23.72.173/api/status/

9. Considerações finais

Já utilizo o Dokku em projetos pessoais e testes. Sempre funcionou muito bem para pequenas aplicações. Vale a pena estudar mais pois as possibilidades de integrações são grandes.

Qualquer dúvida ou sugestão me envie um email: joseadolfojr@gmail.com

Acelerando workloads de IA com VMs e GPUs na Magalu Cloud

Magalu Cloud — Mon, 15 Sep 2025 19:43:28 +0000

Autor: Cleverson Gallego - Sr. Technical Product Manager

Olá amantes da boa inferência e de bons embeddings!

Sabemos que hoje, a infraestrutura é parte fundamental de qualquer negócio baseado em IA, seja ela direta ou indireta. Nós, da Magalu Cloud, estamos trabalhando para entregar uma infraestrutura robusta e acessível, projetada para impulsionar suas ideias e negócios desde a concepção até a escala em produção.

Hoje, queremos demonstrar como nossas máquinas virtuais (VMs) e Unidades de Processamento Gráfico (GPUs) podem acelerar seus workloads e trazer resultados mais rápidos.

Desempenho e flexibilidade: Nossos flavors de VMs para IA

Para atender a diversas necessidades, oferecemos uma variedade de flavors de VMs, permitindo que você escolha a combinação perfeita para seus workloads. Nossas VMs são confiáveis, flexíveis e você só paga pelo tempo de uptime ou seja, se a VM estiver desligada nada é cobrado. Abaixo exemplos de flavors e suas aplicações pós-processamento para workloads de IA:

Perfil da VM	vCPU	RAM	Casos de uso de pós-processamento IA	Exemplos de tarefas
Pequena	4	16 GB	Pós-processamento leve / batchs pequenos	Agregação de resultados de inferência de imagens, análise simples de logs de NLP, pequenas pipelines de métricas de áudio
Média	16	64 GB	Processamento moderado / pipelines paralelos	Pós-processamento de visão computacional (segmentação + feature extraction), análise de embeddings de NLP em batchs maiores, TTS batch médio com pré e pós-processamento
Grande	32–64	256–512 GB	Processamento pesado / pipelines complexos	Processamento de vídeos de alta resolução pós-inferência, pós-processamento de grandes datasets multimodais, agregação de outputs de múltiplos modelos, análises estatísticas complexas pós IA

Oferecemos acesso às GPUs NVIDIA L40, permitindo que você acelere seus modelos de machine learning, deep learning e outras cargas de trabalho computacionais intensivas, com performance e eficiência.

Com as nossas GPUs você pode:

Nº de GPUs	Casos de uso	Tipo de modelo	Observações
1 GPU	Inferência de LLMs grandes quantizados	Até 30B+ parâmetros (ex: Gemma 3 27B Q4KM)	Quantização permite rodar modelos maiores em 1 GPU;
1 GPU	Inferência multimodal, visão, áudio	CLIP, BLIP, Stable Diffusion XL, Whisper large	1 GPU lida com produção contínua;
1 GPU	Fine-tuning / treinamento leve	Modelos até ~1B parâmetros	Adequado para experimentos ou protótipos de LLM ou CV
2 GPUs	Treinamento / fine-tuning pesado	Modelos 1B–30B+	Treinamento distribuído, batch grande ou LLMs não quantizados
2 GPUs	Inferência massiva / pipelines paralelos	LLMs 30B+, diffusion ou multimodal batch grande	Multi-GPU reduz latency ou aumenta throughput para produção

Além da performance de nossas GPUs, nossas máquinas virtuais oferecem flexibilidade para que você crie o seu laboratório de IA sob medida, não dependendo de plataformas gerenciadas. É possível configurar o ambiente aproveitando ferramentas já consolidadas no ecossistema da comunidade de IA.

Na prática, em poucos minutos você consegue ter uma máquina virtual pronta para desenvolver, treinar, executar inferência ou prototipar serviços de IA. Confira alguns exemplos de como nossos clientes e desenvolvedores já tem usado nossas VMs com GPU:

Caso de uso	Ferramentas / Stack	Descrição / Benefício
Ambiente de desenvolvimento interativo	Jupyter Notebook, VS Code Server	Permite escrever e testar código de IA diretamente na VM, acessar datasets, treinar modelos pequenos, visualizar resultados em tempo real
Inferência local de LLMs	No-code/low-code tools Ollama, vLLM	Rodar modelos grandes ou quantizados diretamente na VM, sem depender de serviços externos, controle total do ambiente e recursos
Testes e experimentação com modelos multimodais	backends (texto, imagem, áudio), Stable Diffusion, Whisper	Criar pipelines de teste de modelos multimodais (texto → imagem, texto → áudio, multimodal) para protótipos rápidos
Treinamento ou fine-tuning leve	PyTorch, TensorFlow, vLLM	Treinar ou ajustar modelos menores, fine-tuning de LLMs ou CV, usando a GPU da VM sem necessidade de cluster
Execução de pipelines de IA customizadas	Python scripts, Dask, Prefect	Processar dados pós-inferência, agregação de resultados, pré-processamento de imagens/vídeos, execução de batchs paralelos
Integração e prototipagem de serviços de IA	FastAPI, Flask, Gradio	Criar APIs ou interfaces para testar modelos em produção ou demonstrar resultados para stakeholders
Experimentação com quantização e performance	BitsAndBytes, QLoRA	Testar diferentes técnicas de quantização, medir throughput e latency, otimizar modelos grandes para inferência em 1 GPU
Armazenamento e manipulação de datasets	Object Storage, MYSQL, SQL Server, pandas, NumPy	Gerenciar dados locais ou externos para treinos e inferência, realizar análises, preparar datasets para pipelines

Estes são apenas alguns exemplos de ambientes que podemos criar com a nossa infraestrutura de IA, lembrando ainda que seus dados estarão no Brasil em infraestrutura nacional fora da linha de ação de big techs internacionais (cloud act) e com cobrança em reais, livres de oscilação cambial. Para mais detalhes referente a valores, confira o nosso site oficial.

Protegendo segredos com HashiCorp Vault em um cluster Kubernetes da Magalu Cloud

Magalu Cloud — Tue, 09 Sep 2025 15:00:00 +0000

Autor: Sandro Savelli, Herospark

A gestão de segredos é um dos maiores desafios em ambientes modernos de desenvolvimento e operações. Deixar senhas hardcoded em repositórios, compartilhar tokens em chats ou até configurar manualmente acessos sensíveis pode abrir brechas de segurança sérias.

Neste cenário, ferramentas como o HashiCorp Vault surgem como solução robusta para armazenar, acessar e controlar segredos de forma segura, auditável e automatizada. Neste artigo, vamos entender como funciona o Vault, como configurá-lo em um cluster Kubernetes provisionado na Magalu Cloud, e como integrá-lo com ferramentas como o ArgoCD.

O Vault é uma ferramenta para gerenciamento seguro de segredos, certificados, tokens e outros dados sensíveis. Ele permite controlar acesso a segredos com controle baseado em políticas e autenticação pluggable.

Dependências Necessárias

Acesso ao Cluster MGC

Para interagir com um cluster Kubernetes provisionado na Magalu Cloud (MGC), é necessário utilizar o arquivo de configuração de acesso (kubeconfig). Esse arquivo contém as credenciais, o endpoint da API e as definições de contexto que permitem executar comandos com ferramentas como kubectl ou kubie.

O primeiro passo é acessar o console da MGC. No painel de Kubernetes, localize o cluster desejado e utilize a opção “Download Config” disponível no menu lateral.

Com o arquivo .yaml salvo localmente, o acesso ao cluster pode ser configurado no terminal com o seguinte comando:

kubie ctx -f /caminho/para/config.yaml

Esse comando define o contexto correto, garantindo que todas as operações subsequentes sejam executadas diretamente no cluster selecionado. Caso o kubie ainda não esteja instalado, consulte a seção de dependências para realizar a instalação.

Instalação via Helm como aplicação do ArgoCD

A instalação do Vault em um cluster Kubernetes pode ser feita utilizando Helm, com gerenciamento via ArgoCD. Para isso, é necessário salvar o arquivo values.yaml disponível no repositório oficial do Vault Helm Chart (link direto) em um diretório que já contenha outras aplicações gerenciadas pelo ArgoCD.

Após realizar os ajustes necessários no arquivo values.yaml, uma aplicação deve ser criada referenciando esse arquivo no Helm chart. O manifesto dessa aplicação deve seguir a estrutura padrão do ArgoCD, definindo nome, namespace de destino, fontes de repositório (tanto do repositório Git da infraestrutura quanto do Helm chart), e a configuração de sincronização automática. Dessa maneira:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: vault
  namespace: argocd
spec:
  destination:
    namespace: ns-vault
    name: in-cluster
  project: default
  sources:
  - repoURL: git@github.com:Edools/mgc-infra.git
    targetRevision: main
    ref: values
  - repoURL: https://helm.releases.hashicorp.com
    chart: vault
    targetRevision: 0.29.1(versão do chart aqui)
    helm:
      valueFiles:
      - $values/caminho/para/values.yaml
  syncPolicy:
    automated:
      prune: true
      selfHeal: true 
    syncOptions:
    - CreateNamespace=true
    - ApplyOutOfSyncOnly=true
    - ServerSideApply=true

Com o manifesto pronto, a aplicação pode ser instalada executando o comando:

kubectl apply -f caminho/para/application.yaml

É importante lembrar que o arquivo application.yaml deve estar versionado no repositório monitorado pelo ArgoCD, para que a sincronização ocorra corretamente.

Acesso à interface web

Caso você deseje utilizar a interface web do Vault para gerenciar segredos ou realizar a configuração inicial, será necessário expor o serviço localmente, já que a instalação via ArgoCD com Helm não configura um recurso de Ingress por padrão.

Para isso, execute um redirecionamento de porta com o seguinte comando, substituindo pelo namespace e nome do serviço correspondente:

kubectl port-forward -n <namespace> svc/<servico-do-vault> 8200:8200

Com o túnel criado, o acesso ficará disponível em http://localhost:8200. No primeiro acesso, o Vault solicitará o processo de inicialização, durante o qual serão geradas as Unseal Keys e o Root Token. Certifique-se de salvar essas informações com segurança, pois serão necessárias para desbloquear e administrar a instância.

Seal, Unseal e Root Token

O Vault opera em estado seguro por padrão, utilizando um mecanismo chamado Seal, que impede qualquer leitura ou escrita de dados até que o serviço seja desbloqueado.

Seal

O Vault entra em modo selado automaticamente nas seguintes situações:

Após a inicialização;
Após reinício do serviço;
Após comando manual (vault operator seal);
Após falhas críticas ou perda de quorum em modo HA.

Unseal

Para desbloquear o Vault, é necessário realizar o processo de Unseal. Durante a inicialização, o Vault gera várias Unseal Keys. Um número mínimo delas (chamado de quorum) precisa ser fornecido para o Vault entrar em modo operacional. Essas chaves podem ser inseridas tanto pela interface web quanto pela CLI:

Web UI

Ao acessar a interface web as chaves de unseal serão solicitadas.!

CLI

Forneça as chaves geradas uma a uma:

vault operator unseal <Unseal-Key-1>
vault operator unseal <Unseal-Key-2>
vault operator unseal <Unseal-Key-3>

Após atingir o quorum de keys necessário, o Vault será desbloqueado.

Root Token

Junto das chaves de Unseal, o Vault também gera um Root Token, que concede acesso administrativo completo. Esse token deve ser guardado com extremo cuidado.

Com o Vault inicializado e desbloqueado, podemos agora armazenar e recuperar segredos de forma segura.

Como armazenar e recuperar segredos?

O Vault utiliza engines de armazenamento para guardar informações de forma segura. A engine mais comum é a KV (Key/Value), que permite registrar segredos simples no formato de pares chave:valor. Esses segredos podem ser escritos tanto pela interface web quanto pela CLI.

Web UI

Na interface web do Vault, acesse a engine KV configurada (normalmente no caminho secret/) e clique em "Create secret".

Uma nova tela será exibida para preenchimento dos dados. Você pode inserir os pares chave:valor diretamente ou colar um objeto JSON.

CLI

O armazenamento pela linha de comando é feito com o comando vault kv put, seguido do caminho e dos pares de dados. Por exemplo:

vault kv put secret/db password=supersecret

Neste exemplo:

vault é o binário da CLI do Vault.
kv indica que estamos utilizando a engine KV.
put é a operação para gravar dados.
secret/db é o caminho onde o segredo será armazenado.
password=supersecret define a chave password com o valor supersecret.

Esse comando criará (ou sobrescreverá) um segredo no caminho especificado, criptografando automaticamente os dados.

Agora, se você quiser visualizar um segredo já armazenado, também é possível fazer isso tanto pela interface web quanto pela CLI.

Web UI

Na Web UI, basta navegar até o caminho desejado dentro da engine e clicar sobre o item correspondente. Os valores armazenados serão exibidos em tela, junto com metadados como a versão e a data de modificação.

CLI

Pela CLI, a leitura é feita com o comando:

vault kv get secret/db

Esse comando retorna os dados do segredo, incluindo todas as chaves e seus respectivos valores. O acesso será permitido apenas se a identidade ou token em uso tiver as permissões adequadas configuradas por meio de políticas.

Como habilitar um engine de segredos?

O Vault é modular e permite habilitar diferentes tipos de engines de segredo conforme a necessidade do seu ambiente. A engine KV (Key/Value), usada nos exemplos anteriores, é apenas uma entre várias disponíveis. Você pode, por exemplo, habilitar engines para geração dinâmica de credenciais de banco de dados, certificados TLS via PKI, ou integração com provedores de nuvem.

A habilitação de um engine define o caminho (prefixo) onde os segredos serão armazenados ou gerados, e pode ser feita tanto via Web UI quanto pela linha de comando.

Web UI

Na interface web, acesse a seção “Secrets Engines” e clique em “Enable new engine”. Será exibido um painel para escolha do tipo de engine, onde você pode selecionar “Key/Value” (caso ainda não tenha sido habilitada) e definir o caminho onde os segredos serão armazenados, como secret/.

CLI

O comando abaixo habilita uma engine KV no caminho secret/:

vault secrets enable -path=secret kv

Neste comando:

secrets enable ativa uma nova engine.
-path=secret define o prefixo pelo qual a engine será acessada.
kv especifica o tipo da engine.

Com a engine habilitada e configurada, já é possível definir políticas de acesso que controlam quem pode visualizar, escrever ou gerenciar os segredos armazenados.

Como criar políticas de acesso?

O controle de acesso no Vault é feito por meio de políticas que definem, de forma precisa, quais ações um usuário ou aplicação pode realizar em determinados caminhos. Essas políticas são escritas em HCL (HashiCorp Configuration Language) e podem ser aplicadas via CLI ou criadas diretamente pela interface web.

Web UI

Na Web UI, o processo começa acessando a seção “Policies” no menu lateral. Lá, clique em “Create ACL Policy” para abrir o editor de políticas.

Você poderá dar um nome à política e inserir as regras em HCL. Por exemplo, uma política que permite leitura em um segredo específico pode ser definida da seguinte forma:

CLI

Esse mesmo resultado pode ser alcançado pela CLI. Primeiro, crie um arquivo chamado policy.hcl com o conteúdo desejado:

path "secret/data/db" {
  capabilities = ["read"]
}

Depois, aplique a política no Vault com o seguinte comando:

vault policy write read-db policy.hcl

Isso registrará a política no Vault com o nome read-db. Posteriormente, essa política poderá ser associada a tokens, usuários, grupos ou entidades autenticadas, garantindo que apenas quem possui a permissão adequada possa acessar os segredos.

Com as políticas criadas e aplicadas, já é possível avançar para a integração com outras ferramentas do ecossistema, como o ArgoCD, usando o ArgoCD Vault Plugin.

Integração com ArgoCD (via AVP)

Para integrar o Vault com aplicações gerenciadas via ArgoCD, é possível utilizar o ArgoCD Vault Plugin (AVP). Esse plugin permite que os manifests sejam declarados com referências a segredos armazenados no Vault, evitando que informações sensíveis fiquem versionadas em repositórios Git.

A configuração do AVP no ArgoCD exige a instalação do plugin na imagem usada pelo repositório do ArgoCD. Após isso, o plugin fica responsável por interceptar os manifests antes de serem aplicados, substituindo as expressões com valores reais extraídos do Vault.

Uma vez que o plugin esteja configurado, o uso nos manifests é bastante simples. Em vez de declarar diretamente um valor sensível, você pode referenciar o segredo armazenado no Vault utilizando a seguinte sintaxe:

apiVersion: v1
kind: Secret
metadata:
  name: exemplo-secret
stringData:
  PASSWORD: <path:secret/data/db#password>

Nesse exemplo, o valor da chave PASSWORD será extraído do caminho secret/data/db, buscando especificamente o campo password.

Alterei um segredo, e agora?

Após qualquer alteração nos segredos, é necessário realizar um Hard Refresh da aplicação no ArgoCD para que os valores sejam reaplicados corretamente no cluster. Essa abordagem torna o processo mais seguro e dinâmico, eliminando a necessidade de manter cópias locais de senhas ou tokens sensíveis.

Para saber mais:

Integração do ArgoCD com clusters Kubernetes da Magalu Cloud

Magalu Cloud — Tue, 02 Sep 2025 19:04:00 +0000

Autor: Sandro Savelli, Herospark

Em times que trabalham com Kubernetes, é comum enfrentar desafios para garantir que o ambiente de produção esteja sempre sincronizado com os manifestos versionados no Git. Atualizações manuais, falta de rastreabilidade nas mudanças e divergências entre ambientes são apenas alguns dos problemas que colocam em risco a estabilidade das aplicações.

Esse cenário se torna ainda mais complexo quando múltiplos clusters e equipes estão envolvidos, exigindo uma abordagem mais automatizada, segura e auditável para o processo de deploy.

Neste artigo, mostraremos como o ArgoCD pode ser a solução para esses desafios, automatizando a entrega contínua em clusters Kubernetes com base em uma fonte de verdade única: o repositório Git. Você vai aprender como configurar o ArgoCD na Magalu Cloud utilizando Helm, integrar repositórios Git (via HTTPS ou SSH), criar aplicações tanto pela interface quanto por linha de comando, e até utilizar plugins como o ArgoCD Vault Plugin para lidar com segredos de forma segura.

Dependências necessárias

Acesso ao cluster MGC

Para interagir com o cluster Kubernetes provisionado na Magalu Cloud (MGC), é necessário obter o arquivo de configuração de acesso (kubeconfig). Esse arquivo define as credenciais, o endpoint e o contexto necessário para executar comandos kubectl ou gerenciar o cluster com ferramentas como kubie.

O processo começa acessando o console da MGC. No painel de Kubernetes, selecione o cluster desejado e utilize a opção “Download Config” disponível no menu lateral.

Com o arquivo .yaml em mãos, o acesso ao cluster pode ser ativado via terminal usando o seguinte comando:

$ kubie ctx -f /caminho/para/config.yaml

Esse comando define o contexto adequado para que todas as operações subsequentes sejam executadas diretamente no cluster correto. Caso não tenha o kubie instalado, verifique os pré-requisitos mencionados na seção de dependências.

Instalação do ArgoCD com Helm

O ArgoCD é uma ferramenta declarativa de entrega contínua (CD) para Kubernetes. Ele sincroniza o estado do cluster com os manifestos armazenados em repositórios Git, garantindo consistência e controle de versões para os recursos implantados.

A instalação do ArgoCD em um cluster Kubernetes da Magalu Cloud pode ser feita de forma prática utilizando o Helm, uma das abordagens mais recomendadas para esse tipo de setup. Caso prefira outro método de instalação, consulte a documentação oficial do ArgoCD.

Para iniciar, salve o seguinte arquivo em um diretório local e ajuste conforme necessário: https://github.com/argoproj/argo-helm/blob/main/charts/argo-cd/values.yaml

Na maioria dos casos, os valores padrão já são suficientes. Basta configurar o Ingress e o domínio para refletirem o endereço onde o servidor do ArgoCD será exposto. O próprio README do repositório traz informações úteis sobre essas configurações e opções de escalabilidade com suporte à AWS.

Com o arquivo values.yaml ajustado, execute os comandos abaixo no terminal para instalar o ArgoCD no cluster:

$ helm repo add argo https://argoproj.github.io/argo-helm
$ helm install -f /caminho/para/values.yaml argocd argo/argo-cd

Observação: Ao utilizar as configurações padrão do ArgoCD, é criado automaticamente um usuário admin, cuja senha inicial fica armazenada em um Secret no namespace argocd. Essa senha pode ser recuperada com o comando abaixo:

$ kubectl get secret argocd-initial-admin-secret -n argocd -o jsonpath='{.data.password}' | base64 -d

Esse usuário deve ser utilizado apenas para o setup inicial. A documentação oficial recomenda configurar outros usuários, com suporte a diferentes métodos de autenticação, como integração com Google, LDAP e SSO.

Caso seja necessário atualizar a instalação do ArgoCD, basta modificar o arquivo values.yaml e executar o comando:

$ helm upgrade -f /caminho/para/values.yaml argocd argo/argo-cd

Como adicionar um repositório Git no ArgoCD? (SSH e HTTPS)

Para que o ArgoCD possa monitorar e sincronizar aplicações a partir de um repositório Git, é necessário configurar esse repositório como fonte de verdade. Essa conexão pode ser feita utilizando HTTPS ou SSH, a depender do controle de acesso e da política de autenticação adotada pelo time.

HTTPS

A autenticação por HTTPS pode ser feita diretamente pela interface do ArgoCD. Basta acessar o painel, navegar até Settings Repositories e utilizar a opção Connect Repo.

Ao informar a URL do repositório (por exemplo, https://github.com/usuario/repositorio.git), o ArgoCD aceitará autenticação anônima ou credenciais via usuário e senha ou token pessoal (PAT), caso o repositório seja privado.

A interface exibe os campos: tipo do repositório (git), nome (example), projeto (default), URL (https://github.com/example/repo.git), além de opções para usuário e senha. No topo, há botões para conectar, salvar como template de credenciais e cancelar.

Esse método é especialmente útil para times que utilizam autenticação centralizada por tokens e desejam evitar a gestão de chaves SSH no ambiente.

SSH

Para conexões mais seguras e controladas, recomenda-se utilizar chaves SSH. Nesse caso, é necessário gerar um par de chaves (ou utilizar um já existente) e registrar a chave pública como Deploy Key no repositório desejado, seja no GitHub, GitLab ou Bitbucket.

No ArgoCD, também via Settings Repositories, selecione a opção Connect Repo using SSH e informe a URL no formato git@github.com:usuario/repositorio.git, além da chave privada correspondente.

A interface mostra os campos: Nome obrigatório (example), Projeto (default), URL do repositório (git@github.com:example/repo.git) e chave privada SSH (<PRIVATE_KEY>). No topo, estão os botões Connect, Save as Credentials Template e Cancel.

O uso de SSH é uma prática comum em ambientes com maior exigência de segurança, já que permite revogação granular de acesso por chave e separação clara entre ambientes.

Com o repositório Git devidamente configurado no ArgoCD, o próximo passo é definir o que será implantado e como essa sincronização acontecerá. É aqui que entra o conceito de Application.

O que é um Application e como criar um?

Um Application no ArgoCD é a representação de um conjunto de recursos Kubernetes que serão sincronizados a partir de um repositório Git. Ele define o destino (cluster e namespace), a origem (repo e caminho) e o método de sincronização.

Nos exemplos abaixo estamos considerando essa estrutura de arquivos com mgc sendo a pasta repositório (importante dizer que é possível combinar estrutura de manifestos com helm charts):

Manifesto

mgc
├── applications # Deploy das aplicações
│   ├── airflow
│   │   ├── manifestos
│   │   │   ├── airflow.yaml
│   │   │   ├── secret.yaml   
│   │   ├── application.yaml
├── initial-addons # Helm charts aplicados manualmente
│   ├── argocd_values.yaml

Helm chart

mgc
├── apps # Deploy das aplicações
│   ├── airflow
│   │   ├── airflow-values.yaml 
│   │   ├── application.yaml
├── initial-addons # Helm charts aplicados manualmente
│   ├── argocd_values.yaml

Via Interface Web (UI)

A maneira mais acessível de criar um Application no ArgoCD é pela interface web, ideal para times em fase inicial de adoção do GitOps. Ao criar uma nova aplicação, você define os parâmetros que o ArgoCD usará para monitorar, sincronizar e aplicar os recursos no cluster:

Application Name: nome da aplicação.
- Project: default (ou outro).
- Sync Policy: Automatic (recomendado para CD).
- Repository URL: Git HTTPS ou SSH.
- Revision: ex: main.
- Path: apps/airflow/
- Cluster URL: geralmente https://kubernetes.default.svc.
- Namespace: default

Após preencher essas informações, a aplicação pode ser criada com um clique no botão Create, e o ArgoCD iniciará o processo de sincronização conforme as configurações definidas.

A interface exibe os botões CREATE e CANCEL no topo.

Na seção GENERAL, aparecem os campos Application Name (preenchido com example-application) e Project Name (default), além da política de sincronização (SYNC POLICY) configurada como Manual.

Entre as opções adicionais estão checkboxes como Set Deletion Finalizer, Skip Schema Validation, Prune Last, Respect Ignore Differences, Replace e Retry, além de configurações à direita como Auto-create Namespace, Apply Out of Sync Only e Server Side Apply. A política de propagação de prune está definida como foreground.

Na seção SOURCE, os campos exibidos são: Repository URL (git@github.com:example/repo.git), Revision (HEAD) e Path (/).

Via CLI (argocd)

Para quem já tem o ArgoCD instalado e deseja automatizar a criação de aplicações ou integrá-la em pipelines, a CLI do ArgoCD é uma ferramenta poderosa. Ela permite registrar novos Applications diretamente via terminal, sem necessidade de interação com a interface web.

Após autenticar-se no servidor do ArgoCD com o comando:

argocd login argocd.example.com

É possível criar uma nova aplicação com o seguinte comando:

argocd app create app-demo \
  --repo https://github.com/user/repository.git \
  --path apps/airflow/ \
  --dest-server https://kubernetes.default.svc \
  --dest-namespace default \
  --sync-policy automated

Esse comando define o nome da aplicação (app-demo), o repositório e caminho onde estão os manifestos ou Helm charts, o cluster e namespace de destino, além de ativar a sincronização automática.

Se for necessário aplicar os recursos imediatamente após a criação, basta rodar:

argocd app sync app-demo

Esse fluxo via CLI é especialmente útil em ambientes automatizados, como scripts de provisionamento, pipelines CI/CD ou setup de novos ambientes.

Via Terminal (kubectl + YAML)

A forma mais declarativa de criar aplicações no ArgoCD é utilizando arquivos YAML com o recurso Application. Essa abordagem se alinha totalmente à filosofia GitOps, permitindo que a definição das aplicações seja versionada e aplicada via kubectl, como qualquer outro recurso do Kubernetes.

Essa prática é útil tanto para ambientes automatizados quanto para times que mantêm o controle total da infraestrutura como código.

Abaixo, dois exemplos de Application - um utilizando manifestos Kubernetes e outro com Helm Charts como fonte:

application.yaml usando source GitHub e aplicando manifestos Kubernetes

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
 name: app-demo
spec:
 destination:
   server: https://kubernetes.default.svc
   namespace: default
 source:
   repoURL: git@github.com:usuario/repositorio.git
   path: apps/airflow/manifestos
   targetRevision: main
 project: default
 syncPolicy:
   automated:
     prune: true
     selfHeal: true

application.yaml usando source GitHub e aplicando Helm Charts

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
 name: app-demo
spec:
 destination:
   server: https://kubernetes.default.svc
   namespace: default
 source:
   repoURL: git@github.com:usuario/repositorio.git
   path: charts/minha-app
   targetRevision: main
   helm:
     valueFiles:
       - $values/apps/airflow/airflow-values.yaml
 project: default
 syncPolicy:
   automated:
     prune: true
     selfHeal: true

Após salvar o conteúdo em um arquivo (por exemplo, application.yaml), aplique-o no cluster com o comando:

kubectl apply -f application.yaml

Depois de definir uma aplicação no ArgoCD, apontando origem, destino e regras de sincronização, é comum que os manifestos incluam valores sensíveis, como senhas, tokens ou chaves de API. Manter esses dados seguros e, ao mesmo tempo, alinhados à prática de versionamento, é um dos principais desafios em ambientes Kubernetes.

Para lidar com esse cenário de forma segura e escalável, o ArgoCD oferece suporte ao Vault Plugin (AVP), que permite a injeção dinâmica de segredos diretamente nos manifestos, sem expor essas informações no repositório Git.

AVP Plugin e como utilizar nos manifestos que serão aplicados?

O Vault Plugin (AVP) é uma extensão que permite injetar segredos diretamente nos manifestos a partir de provedores, sem que esses dados fiquem explícitos nos arquivos versionados.

Exemplo de uso nos manifestos

apiVersion: v1
kind: ConfigMap
metadata:
 name: exemplo-configmap
data:
 DB_PASSWORD: <path:secret/data/postgres#password>

Sempre que houver alterações nos segredos utilizados nos manifestos, especialmente quando gerenciados por meio do ArgoCD Vault Plugin, é necessário realizar um Hard Refresh na aplicação correspondente dentro do ArgoCD. Isso garante que os novos valores sejam buscados e aplicados corretamente no cluster, já que o ArgoCD não detecta mudanças em dados externos por padrão.

A interface exibe botões de controle como Details, Diff, Sync, Sync Status, History and Rollback, Delete e Refresh (com opção de Hard Refresh).

O estado da aplicação mostra Healthy, com sincronização marcada como Synced to main (13d61ad) e modo automático habilitado.

A última sincronização foi bem-sucedida para o commit 84ab096, realizada há 7 dias, acompanhada do comentário "feat: nodopaol affinity".