Forem: Magalu Cloud

CI/CD na Magalu Cloud com GitHub Actions

Monica Hillman — Thu, 19 Mar 2026 20:50:35 +0000

Um dos problemas mais comuns em times de desenvolvimento não está no código em si, mas na forma como ele chega até produção.

Mesmo equipes organizadas enfrentam situações como:

diferenças entre ambientes (desenvolvimento, homologação, produção)
erros manuais durante o processo de publicação
dificuldade em rastrear qual versão está em execução
retrabalho após falhas em deploy

Esses problemas tendem a crescer à medida que o sistema evolui e o número de entregas aumenta.

A prática de CI/CD (Integração Contínua e Entrega Contínua) surge exatamente para resolver esse cenário, automatizando o fluxo de validação e entrega de software.

Neste artigo, vamos construir um fluxo completo utilizando:

GitHub Actions para automação
Container Registry da Magalu Cloud para armazenamento de imagens
Infraestrutura da Magalu Cloud como destino da aplicação

O objetivo é sair de um processo manual e sujeito a falhas para um pipeline automatizado, reprodutível e integrado com a nuvem.

Hands-on: construindo um pipeline de CI/CD

Visão geral do fluxo

O pipeline que vamos montar segue esta sequência:

Código é enviado para o repositório
GitHub Actions executa o pipeline
A aplicação é empacotada como imagem de container
A imagem é enviada para o Container Registry da Magalu Cloud
A imagem fica disponível para execução na infraestrutura

Pré-requisitos

Antes de começar, é necessário:

Conta na Magalu Cloud
Repositório no GitHub
Docker configurado no projeto

Obtendo informações da conta

Para integrações com a plataforma, você pode consultar o Tenant ID via CLI:

mgc auth tenant current

O retorno inclui o identificador da conta (UUID), utilizado em integrações com APIs como x-tenant-id

Estrutura do projeto

Exemplo mínimo de aplicação com Docker:

FROM nginx:alpine
COPY . /usr/share/nginx/html

Criando o pipeline no GitHub Actions

Crie o arquivo:

.github/workflows/ci-cd.yml

Conteúdo:

name: CI/CD Magalu Cloud

on:
  push:
    branches:
      - main

jobs:
  build-and-push:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout do código
        uses: actions/checkout@v3

      - name: Build da imagem
        run: docker build -t minha-app:latest .

      - name: Login no Container Registry
        run: |
          docker login ${{ secrets.REGISTRY_URL }} \
          -u ${{ secrets.REGISTRY_USER }} \
          -p ${{ secrets.REGISTRY_PASSWORD }}

      - name: Tag da imagem
        run: |
          docker tag minha-app:latest \
          ${{ secrets.REGISTRY_URL }}/minha-app:latest

      - name: Push da imagem
        run: |
          docker push \
          ${{ secrets.REGISTRY_URL }}/minha-app:latest

Configuração de credenciais

No GitHub, configure as seguintes variáveis seguras:

REGISTRY_URL
REGISTRY_USER
REGISTRY_PASSWORD

Essas informações devem ser obtidas no console da Magalu Cloud.

Resultado esperado

A cada alteração na branch main:

o pipeline será executado automaticamente
a imagem será construída
a imagem será enviada ao Container Registry
a versão ficará disponível para uso na infraestrutura

Conclusão

A implementação de CI/CD com GitHub Actions na Magalu Cloud resolve problemas reais do dia a dia de desenvolvimento, especialmente relacionados a consistência, automação e confiabilidade de entregas.

Com poucos componentes é possível construir um fluxo completo que:

automatiza build e publicação
padroniza a geração de artefatos
integra diretamente com a infraestrutura da nuvem

Além disso, a abordagem aberta da plataforma permite utilizar ferramentas amplamente adotadas, sem dependência de soluções proprietárias.

O resultado é um processo de entrega mais previsível, escalável e alinhado às práticas modernas de desenvolvimento.

Protegendo seus dados no Object Storage da Magalu Cloud com políticas de acesso

Monica Hillman — Mon, 16 Mar 2026 12:10:56 +0000

Em muitas aplicações modernas, o Object Storage é utilizado para armazenar arquivos estáticos, backups, logs, imagens de aplicações ou até dados analíticos. No entanto, à medida que o volume de dados cresce e diferentes aplicações ou usuários passam a consumir esses arquivos, surge um problema comum: como controlar quem pode acessar cada objeto armazenado.

Imagine, por exemplo:

Um bucket que armazena imagens públicas de um site, que devem ser acessíveis por qualquer usuário.
Outro bucket contendo backups de banco de dados, que devem ser acessados apenas por aplicações internas.
Ou ainda um cenário onde apenas determinadas contas ou serviços podem fazer upload ou download de objetos.

Sem um controle adequado de acesso, esses dados podem ficar expostos indevidamente ou bloquear acessos legítimos, causando falhas em aplicações.

É nesse ponto que entram as políticas de acesso do Object Storage.

Neste artigo, você vai entender:

O que são políticas no Object Storage
Como elas controlam o acesso aos dados
Como aplicar esse conceito em cenários reais
Boas práticas para evitar problemas de segurança

O objetivo é que, ao final, você consiga estruturar políticas de acesso de forma segura e previsível em seus buckets.

O que são políticas no Object Storage?

Políticas são regras que definem quem pode acessar um recurso e quais ações são permitidas.

No contexto de Object Storage, elas controlam operações como:

Listar objetos
Fazer upload de arquivos
Fazer download de objetos
Excluir dados

Essas políticas funcionam como uma camada de controle de acesso sobre os buckets e objetos armazenados.

Podemos pensar em uma política como um porteiro digital:

Ele verifica quem está tentando acessar
Analisa qual ação está sendo solicitada
Decide se o acesso será permitido ou negado

Esse mecanismo é essencial para proteger dados e garantir que apenas usuários ou aplicações autorizadas possam interagir com os objetos armazenados.

Quando usar políticas de Object Storage

As políticas são especialmente importantes em cenários como:

1. Distribuição de conteúdo público

Arquivos como:

imagens
vídeos
arquivos estáticos de aplicações web

podem ser configurados para leitura pública, permitindo acesso direto via internet.

2. Armazenamento de backups

Backups geralmente devem ser acessados apenas por:

pipelines automatizados
sistemas de recuperação
contas administrativas

Nesse caso, as políticas restringem o acesso para evitar exposição ou exclusão acidental.

3. Integração entre serviços

Aplicações executando em máquinas virtuais, contêineres ou pipelines de dados podem precisar:

enviar arquivos para um bucket
ler dados processados
gerar relatórios armazenados no Object Storage

As políticas garantem que cada serviço tenha apenas as permissões necessárias.

Como funciona o Object Storage na Magalu Cloud

O Object Storage da Magalu Cloud é projetado para armazenar grandes volumes de dados de forma escalável e resiliente. Os dados são replicados automaticamente entre zonas de disponibilidade, garantindo maior durabilidade e disponibilidade sem necessidade de intervenção do usuário.

Isso significa que, além de escalável, o serviço já oferece uma camada de proteção contra falhas de infraestrutura.

Nesse contexto, as políticas atuam como a camada de controle de acesso, garantindo que apenas os consumidores corretos possam interagir com os dados armazenados.

Controlando acesso a um bucket

Vamos imaginar um cenário simples.

Você possui um bucket chamado:

site-assets

Esse bucket armazena arquivos estáticos de um site, como:

imagens
CSS
JavaScript

Esses arquivos precisam ser acessíveis publicamente para leitura, mas apenas o time de desenvolvimento pode enviar novos arquivos.

Estrutura da política

Uma política geralmente define:

quem pode acessar
quais ações são permitidas
em qual recurso

Um exemplo simplificado de política poderia seguir uma estrutura semelhante a esta:

{
  "Version": "2023-01-01",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": [
        "storage:GetObject"
      ],
      "Resource": "bucket/site-assets/*"
    }
  ]
}

Nesse exemplo:

Principal: "*" indica que qualquer usuário pode acessar
Action: storage:GetObject permite apenas leitura
Resource define que a regra se aplica aos objetos do bucket

Com essa política, qualquer pessoa poderá baixar arquivos, mas não poderá:

enviar novos objetos
modificar arquivos
excluir dados

Outro exemplo: bucket privado para backups

Agora imagine um bucket chamado:

db-backups

Esse bucket contém backups sensíveis do banco de dados.

Aqui, a política poderia permitir acesso apenas para uma conta de serviço responsável pelos backups.

Exemplo conceitual:

{
  "Version": "2023-01-01",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "backup-service",
      "Action": [
        "storage:PutObject",
        "storage:GetObject"
      ],
      "Resource": "bucket/db-backups/*"
    }
  ]
}

Nesse caso:

Apenas a conta backup-service
pode enviar e recuperar backups
sem expor esses dados para outros usuários.

Boas práticas ao trabalhar com políticas

Ao definir políticas de acesso para Object Storage, algumas recomendações ajudam a evitar problemas de segurança.

Use o princípio do menor privilégio

Permita apenas o que for necessário.

Por exemplo:

aplicações que apenas leem arquivos não precisam de permissão de escrita
sistemas de upload não precisam listar todo o bucket

Evite exposição pública desnecessária

Muitos vazamentos de dados acontecem porque buckets foram configurados como públicos sem necessidade.

Sempre revise se:

o bucket realmente precisa ser público
apenas determinados objetos deveriam ser expostos

Separe buckets por tipo de uso

Uma prática comum é dividir dados em buckets diferentes:

Exemplo:

site-assets
logs
backups
uploads

Isso facilita a criação de políticas específicas para cada cenário.

Revise políticas periodicamente

Com o crescimento das aplicações, novas integrações surgem e antigas deixam de existir.

Revisar políticas regularmente ajuda a:

remover acessos obsoletos
reduzir riscos de segurança
manter o ambiente organizado

Conclusão

As políticas de acesso são um componente essencial para trabalhar com Object Storage de forma segura e escalável.

Elas permitem controlar com precisão:

quem pode acessar os dados
quais ações podem ser realizadas
em quais recursos essas regras se aplicam.

Na Magalu Cloud, o Object Storage oferece uma base robusta para armazenamento de dados, com replicação automática entre zonas de disponibilidade, garantindo alta disponibilidade e durabilidade.

Ao combinar essa infraestrutura resiliente com políticas bem definidas, é possível construir arquiteturas seguras para diversos cenários, desde distribuição de conteúdo até armazenamento de backups críticos.

Compreender e aplicar corretamente essas políticas é um passo importante para qualquer desenvolvedor ou profissional de infraestrutura que trabalha com armazenamento em nuvem.

IaC com Terraform na Magalu Cloud: do zero a um ambiente reproduzível

Monica Hillman — Thu, 05 Mar 2026 21:32:14 +0000

Infraestrutura em nuvem permite criar recursos rapidamente, mas também traz um desafio comum: como garantir que ambientes sejam consistentes e reproduzíveis?

Criar recursos manualmente pelo console funciona no início. Porém, conforme a infraestrutura cresce, manter ambientes idênticos entre desenvolvimento, homologação e produção se torna difícil.

É nesse cenário que entra Infraestrutura como Código (IaC).

Neste artigo vamos construir um exemplo prático usando Terraform na Magalu Cloud, criando um ambiente reproduzível com:

Compute (máquina virtual)
Storage persistente (Block Storage)
Object Storage
State remoto para colaboração entre equipes

Ao final, você terá um projeto capaz de recriar toda a infraestrutura em poucos comandos.

O que é Infraestrutura como Código (IaC)

Infraestrutura como Código é a prática de descrever a infraestrutura em arquivos de configuração versionáveis.

Em vez de criar recursos manualmente, você escreve definições declarativas que descrevem o estado desejado do ambiente.

O Terraform interpreta essas definições e executa as mudanças necessárias.

Esse modelo traz benefícios importantes:

Reprodutibilidade — qualquer pessoa pode recriar o ambiente
Versionamento — mudanças ficam registradas em Git
Previsibilidade — terraform plan mostra o que será alterado
Automação — integração simples com pipelines de CI/CD

Na Magalu Cloud, a infraestrutura pode ser gerenciada por Console, APIs, CLI ou Terraform, utilizando o provider oficial:


magalucloud/mgc

Arquitetura que vamos criar

Neste artigo vamos montar uma infraestrutura simples e reproduzível.


VM (Compute)
├─ IP público
└─ Volume Block Storage

Object Storage
└─ Bucket para dados e Terraform state

Esse ambiente já permite executar aplicações e armazenar dados persistentes.

Configurando o provider da Magalu Cloud

No arquivo main.tf:

terraform {
  required_providers {
    mgc = {
      source = "magalucloud/mgc"
    }
  }
}

provider "mgc" {
  region  = var.mgc_region
  api_key = var.mgc_api_key
}

A autenticação pode ser feita usando variáveis de ambiente como:

MGC_API_KEY
MGC_REGION
MGC_OBJ_KEY_ID
MGC_OBJ_KEY_SECRET
MGC_ENV

Isso evita expor credenciais diretamente no código.

Inicializando o Terraform

Depois de configurar o provider:

terraform init

Visualize o que será criado:

terraform plan

E aplique a infraestrutura:

terraform apply

Esses comandos fazem parte do fluxo básico de trabalho com Terraform.

Criando a máquina virtual

A criação de uma instância exige alguns parâmetros básicos:

Availability Zone
imagem do sistema operacional
tipo da máquina
chave SSH

Exemplo simplificado:

resource "mgc_virtual_machine_instances" "app" {
  name              = "app-1"
  availability_zone = var.az

  image_id        = var.image_id
  machine_type_id = var.machine_type_id

  ssh_key_name = var.ssh_key_name

  network {
    associate_public_ip = true
  }
}

Depois da execução do Terraform, a VM estará pronta para acesso via SSH.

Adicionando armazenamento persistente

Para aplicações que precisam armazenar dados de forma persistente, podemos anexar um volume de Block Storage à instância.

resource "mgc_block_storage_volume" "data" {
  name = "volume-via-terraform"
  size = 30

  type = {
    name = "cloud_nvme20k"
  }
}

resource "mgc_block_storage_attachment" "data_attach" {
  volume_id   = mgc_block_storage_volume.data.id
  instance_id = mgc_virtual_machine_instances.app.id
}

Esse volume pode ser utilizado para bancos de dados, arquivos de aplicação ou dados de usuário.

Um ponto importante: volumes precisam estar na mesma Availability Zone da VM para serem anexados.

Usando Object Storage para Terraform state

Quando várias pessoas trabalham no mesmo projeto Terraform, é importante armazenar o Terraform state remotamente.

Na Magalu Cloud, o Object Storage é compatível com S3, permitindo usar o backend s3 do Terraform.

Exemplo conceitual:

terraform {
  backend "s3" {
    bucket   = "terraform-state"
    key      = "iac/terraform.tfstate"
    region   = "br-ne1"
    endpoint = "https://br-ne1.magaluobjects.com"
  }
}

Isso evita conflitos quando múltiplos desenvolvedores executam o Terraform.

Conclusão

Infraestrutura como Código muda completamente a forma de gerenciar ambientes em nuvem.

Com Terraform na Magalu Cloud é possível:

automatizar provisionamento
reproduzir ambientes completos
reduzir erros manuais
integrar infraestrutura ao fluxo de desenvolvimento

Ao definir compute e storage em código, sua infraestrutura deixa de ser um conjunto de recursos criados manualmente e passa a ser um sistema previsível, versionável e automatizado.

Links interessantes:

Pare de Brincar com LLMs Locais: Leve a IAG Open Source para a Produção na Magalu Cloud

Gláucio — Thu, 05 Feb 2026 10:30:00 +0000

Nos últimos anos, tivemos um salto no processamento de linguagem natural (NLP). O surgimento da IA Generativa não apenas refinou tarefas antigas, mas abriu bastantes possibilidades em lidar com textos e dados não estruturados, melhorias em experiências de aplicações já existentes, classificações mais simples e demais tarefas. No entanto, para muitas organizações, trouxe um dilema crítico: como escalar o uso dessas tecnologias mantendo o controle absoluto sobre os dados?

Para setores que lidam com informações sensíveis ou que operam sob regulamentações rígidas de privacidade, submeter dados a LLMs públicos via APIs externas não é apenas um risco, mas muitas vezes uma impossibilidade jurídica. É aqui que a soberania de dados se torna o pilar central da estratégia de tecnologia. Rodar modelos abertos em uma infraestrutura nacional e controlada, como a Magalu Cloud, não é mais apenas uma alternativa de custo, é uma necessidade de segurança e conformidade.

Neste tutorial, vamos explorar como você pode unir o estado da arte dos modelos do Hugging Face com o vLLM, garantindo performance de nível de produção sem abrir mão da privacidade.

O que é vLLM?

O vLLM não é apenas uma biblioteca de inferência; é um sistema de gerenciamento de memória virtualizado para GPUs.

O problema central da inferência de LLMs não é computação (FLOPs), é I/O de memória. Engines tradicionais alocam VRAM contígua para o Key-Value (KV) Cache, resultando em fragmentação massiva (60-80% de desperdício) e impedindo o paralelismo.

O vLLM resolve isso com o PagedAttention: um algoritmo de atenção que permite armazenar o KV Cache em blocos de memória não contíguos. Isso desacopla a memória lógica (sequência de tokens) da memória física (VRAM), permitindo:

Desperdício Zero: Quase nenhuma fragmentação de memória (<4%).
Continuous Batching: A capacidade de injetar novas requisições na GPU token-a-token, sem esperar que o lote anterior termine.
Copy-on-Write: Mecanismo eficiente para decodificação paralela (como em Beam Search), onde múltiplos "caminhos" compartilham a mesma memória física até divergirem.

Você pode conhecer mais sobre o vLLM neste blog post

Passo a passo para configuração do ambiente

Para este tutorial, provisionamos uma máquina virtual equipada com a GPU NVIDIA L40S. A escolha é estratégica pois a L40S é baseada na arquitetura Ada Lovelace, possui o Transformer Engine com suporte nativo a precisão FP8. Isso garante que o modelo Qwen3-30B-A3B-FP8 rode muito bem tirando proveito dos 18.176 núcleos CUDA e da alta disponibilidade de memória. Com 48GB de VRAM GDDR6 (ECC) e uma largura de banda de 864 GB/s, eliminamos gargalos de transferência, assegurando estabilidade e alta vazão durante a inferência.

Então dado o contexto vamos iniciar a mão na massa.

Criação da máquina

Link para criação de máquinas virtuais

Etapas para criarmos a máquina

1 - Início e Seleção do Serviço
- No Console da Magalu Cloud, localize o card com o texto "Virtual Machine".
- Clique no botão azul "Criar instância".
2 - Configurações de região e sistema operacional
- Zona de Disponibilidade: Selecione a zona desejada (no meu caso, foi escolhida a br-se1-a mas escolha o que preferir).
- Escolha de Imagem: Selecione a distribuição Ubuntu.
- Versão: No menu suspenso que aparece, escolha a versão Ubuntu 24.04 LTS.
3 - Hardware
- Habilitar GPU (muito importante): Marque a caixa de seleção "Habilitar GPU" para visualizar as instâncias de alta performance.
- Tipo de Instância:
- Role até a seção de GPUs (GPU NVIDIA L40S, indicada para IA generativa e LLMs).
- Selecione a configuração desejada. Neste caso escolha a instância L40S-1x-DP8-64-100 (que oferece 8 vCPUs, 64 GB de RAM e 100 GB de disco).
4 - Conectividade e Acesso
- Acesso Público: Mantenha marcada a opção "Atribuir IPv4 público para essa instância" (padrão).
- Chave SSH (muito importante para poder acessar sua máquina):
- Selecione a opção "Selecionar chave já utilizada anteriormente" caso tenha uma ou cadastre uma nova clicando em " Inserir uma chave própria nova".
- Caso esteja inserindo uma nova chave, consulte-a com o seguinte comando Linux/macos cat ~/.ssh/id_ed25519.pub(o nome da sua chave deve ser diferente de id_ed25519.pub, mas ela deve finalizar com .pub), copie o valor que aparecer no seu terminal e cole no campo "Insira sua chave SSH" e depois dê um nome para essa chave ssh ser utilizada.
5 - Nomeando a máquina
- Nome da Instância: Defina um nome identificável para o servidor. No meu caso, usei o nome llm_server-vllm.
- Clique no botão "Criar instância" no canto inferior direito.
- Você será redirecionado para a lista de instâncias, onde poderá ver seu novo servidor com o status "Criando".

Acessando nossa máquina virtual para efetuarmos nossas configurações

Depois de criarmos nossa máquina virtual, agora precisaremos acessar ela para fazermos as instalações necessárias para rodarmos nossa LLM em produção com proxy reverso e SSL.

Requisito obrigatório:
Para nosso proxy reverso funcionar corretamente, será preciso configurar seu domínio apontando o IP da sua máquina que poderá pegar essa informação acessando a página de detalhes da nossa VM.

No meu caso utilizo a Cloudflare para gerir meu DNS, e você pode seguir a documentação deles para configurar seu DNS, mas caso use outro local para gerenciar seu DNS busque e faça a configuração, para este tutorial eu vou utilizar o seguinte domínio vllm-mgc.glaucio.tec.br , dito isto vamos seguir para acesso.

Primeiro acesso a nossa VM via SSH

Na página da nossa máquina virtual como no print acima, há um ícone azul para copiar o seu IPv4 Público e seu usuário.

e execute o comando ssh ubuntu@201.23.79.32 no seu terminal como no print abaixo

No primeiro acesso irá aparecer esta mensagem da imagem acima no seu terminal, apenas digite yes e aperte enter e agora com acesso ao servidor podemos iniciar a instalação das dependências.

Instalação do Docker

Para instalar o Docker rapidamente vamos automatizar esta parte, para isso abra algum editor pelo terminal como VIM ou nano, no meu caso para ser mais fácil irei utilizar o nano para criar o script de instalação do nosso Docker com o comando:

nano install_docker.sh

e você irá ver a seguinte tela, com o nosso editor nano aberto com um arquivo de texto em memória sem conteúdo algum

Para facilitar esta etapa de instalação do Docker, copie e cole o shell script abaixo.

#!/bin/bash
set -e

# 0. Antes de rodar o script lembre de executar `chmod +x install_docker.sh`

# 1. Limpeza de tentativas anteriores (Resolve o erro 'Malformed entry')
echo "🧹 Limpando configurações antigas..."
sudo rm -f /etc/apt/sources.list.d/docker.list
sudo apt-get update

# 2. Instalar dependências essenciais
echo "📦 Instalando dependências..."
sudo apt-get install -y ca-certificates curl gnupg lsb-release

# 3. Baixar Chave GPG
echo "🔑 Configurando chave GPG..."
sudo install -m 0755 -d /etc/apt/keyrings
# Se a chave já existir, removemos para baixar a mais nova
sudo rm -f /etc/apt/keyrings/docker.asc
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

# 4. Adicionar Repositório (Fixo para 'noble' - Ubuntu 24.04)
echo "📂 Adicionando repositório 'noble'..."
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu noble stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# 5. Instalar Docker
echo "⬇️  Instalando pacotes do Docker..."
sudo apt-get update
sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

# 6. Configurar permissão de usuário
echo "👤 Adicionando usuário '$USER' ao grupo docker..."
sudo usermod -aG docker $USER

echo "---"
echo "✅ Instalação concluída"
echo "⚠️  Para usar imediatamente, rode: newgrp docker"
echo "Valide instalação com docker run hello-world"

e deve ficar da seguinte forma

Agora aperte as teclas Ctrl e x para salvar e confirme para salvar o conteúdo que adicionamos ao nosso arquivo.

Feito isso, confirme se o nosso script foi salvo com sucesso e deve ter o mesmo texto do script acima, rode o comando:

cat install_docker.sh

e confira se está tudo ok. Feito isso precisamos fazer nosso script ser executável, para isso vamos precisar rodar o seguinte comando:

chmod +x install_docker.sh

Feito isso, podemos rodar nosso script de instalação do Docker com o comando:

./install_docker.sh

e correndo tudo bem irá aparecer no seu terminal as seguintes mensagens:

e então siga as instruções que foram exibidas para alterar o GID (Group ID) da sua sessão do terminal para o grupo "docker", sem que você precise deslogar e logar e rodar um container de hello-world para dar sorte haha e validar se a instalação correu bem.

Ao rodar os comandos sugeridos, você deve ter o seguinte resultado no seu terminal:

Se você teve os mesmos resultados dos prints acima, estamos prontos para instalar as dependências para que o Docker consiga se comunicar com a nossa GPU.

Instalação de drivers e nvidia-container-toolkit

Assim como a etapa de instalação do Docker criaremos um script para agilizar nossa instalação e facilitar a reprodutibilidade.

Crie nosso arquivo de setup da nossa máquina com o seguinte comando:

nano setup_nvidia.sh

cole o script abaixo como fizemos na etapa do Docker:

#!/bin/bash
set -e

# Configuração - Altere conforme necessário
NVIDIA_DRIVER_VERSION="${NVIDIA_DRIVER_VERSION:-570}"

# Cores para output
RED='\033[0;31m'
GREEN='\033[0;32m'
YELLOW='\033[1;33m'
NC='\033[0m' # No Color

echo -e "${GREEN}╔════════════════════════════════════════════════════════╗${NC}"
echo -e "${GREEN}║  Instalação NVIDIA Driver + Container Toolkit          ║${NC}"
echo -e "${GREEN}║  Driver versão: ${NVIDIA_DRIVER_VERSION}                                       ║${NC}"
echo -e "${GREEN}╚════════════════════════════════════════════════════════╝${NC}"
echo ""

# 0. Verificar se está rodando como root ou com sudo
if [ "$EUID" -eq 0 ]; then
    echo -e "${RED}❌ Não execute este script como root. Use seu usuário normal.${NC}"
    exit 1
fi

# 1. Verificar se driver já está instalado
echo "🔍 Verificando instalação existente..."
if command -v nvidia-smi &> /dev/null; then
    echo -e "${YELLOW}⚠️  Driver NVIDIA já está instalado:${NC}"
    nvidia-smi --query-gpu=driver_version,name --format=csv,noheader
    read -p "Deseja continuar mesmo assim? (s/N): " -n 1 -r
    echo
    if [[ ! $REPLY =~ ^[Ss]$ ]]; then
        echo "Instalação cancelada."
        exit 0
    fi
fi

# 2. Verificar se Docker está instalado
echo "🐳 Verificando Docker..."
if ! command -v docker &> /dev/null; then
    echo -e "${RED}❌ Docker não encontrado. Execute primeiro o script 01-docker_install_script.sh${NC}"
    exit 1
fi
echo -e "${GREEN}✓ Docker encontrado${NC}"

# 3. Atualizar sistema
echo ""
echo "📦 Atualizando lista de pacotes..."
sudo apt-get update

# 4. Instalar Driver NVIDIA
echo ""
echo "🎮 Instalando driver NVIDIA versão ${NVIDIA_DRIVER_VERSION}..."
sudo apt-get install -y nvidia-driver-${NVIDIA_DRIVER_VERSION}

# 5. Instalar NVIDIA Container Toolkit
echo ""
echo "📦 Configurando repositório NVIDIA Container Toolkit..."

# Adicionar chave GPG
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | \
    sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg --yes

# Adicionar repositório
curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | \
    sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \
    sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list > /dev/null

# Instalar toolkit
echo "⬇️  Instalando nvidia-container-toolkit..."
sudo apt-get update
sudo apt-get install -y nvidia-container-toolkit

# 6. Configurar Docker para usar runtime NVIDIA
echo ""
echo "🔧 Configurando Docker para usar GPU NVIDIA..."
sudo nvidia-ctk runtime configure --runtime=docker

# 7. Reiniciar Docker
echo "🔄 Reiniciando serviço Docker..."
sudo systemctl restart docker

# 8. Resumo final
echo ""
echo -e "${GREEN}╔════════════════════════════════════════════════════════╗${NC}"
echo -e "${GREEN}║  ✅ Instalação concluída!                              ║${NC}"
echo -e "${GREEN}╚════════════════════════════════════════════════════════╝${NC}"
echo ""
echo -e "${YELLOW}⚠️  IMPORTANTE: Reinicie a máquina para carregar o driver:${NC}"
echo ""
echo "    sudo reboot"
echo ""
echo -e "${GREEN}Após reiniciar, valide a instalação com:${NC}"
echo ""
echo "    # Verificar driver no host"
echo "    nvidia-smi"
echo ""
echo "    # Testar GPU no Docker"
echo "    docker run --rm --gpus all nvidia/cuda:12.3.1-base-ubuntu22.04 nvidia-smi"
echo ""

salve com as teclas Ctrl e x e siga os caminhos para salvar e agora dê permissão para que ele também seja executável com o comando:

chmod +x setup_nvidia.sh

e agora vamos rodar com o comando:

./setup_nvidia.sh

e correndo tudo bem na instalação, você verá o seguinte resultado no seu terminal

e seguindo as instruções, vamos reiniciar a máquina para aplicar as novas configurações de driver.
com o comando:

sudo reboot

aguarde alguns segundos para a máquina reiniciar, aproveite para pegar um café, um chá ou uma água.

Agora vamos precisar acessar nossa máquina via SSH novamente, com o seguinte comando:

ssh ubuntu@ip-da-sua-maquina

Antes de seguirmos para a mão na massa para subir o nosso servidor e LLM, vamos validar se nossos passos anteriores funcionaram e tudo foi instalado corretamente com o comando:

docker run --rm --gpus all nvidia/cuda:12.3.1-base-ubuntu22.04 nvidia-smi

e caso tenha o seguinte resultado, suas instalações estão corretas e podemos ir para a etapa de subir o nosso servidor de LLM. 🎉

Subindo aplicação

Agora antes de partirmos para configurações e deploy, vale passarmos pela forma que foi pensada e arquitetada a essa nossa aplicação, passando por como ela vai ser servida, protegendo rotas do vLLM que não validam nosso token de autenticação e podem ser alvo de exploração por entidades mal-intencionadas.

Arquitetura da aplicação

Como podemos observar na imagem acima, a porta de entrada para o modelo é o servidor Caddy, pois quando expomos um servidor de LLM à internet, não basta configurar uma API Key e achar que está tudo protegido. O vLLM, por padrão, expõe endpoints como /health , /metrics e /docs que não validam autenticação, criando uma superfície de ataque significativa para scanners automatizados e potenciais explorações. Seguindo as recomendações oficiais de segurança do vLLM, implementamos uma arquitetura de "defense in depth": o vLLM roda em uma rede interna do Docker, completamente isolado da internet, enquanto o Caddy atua como nosso portão de entrada único. No Caddyfile, configuramos um allowlist restrita apenas com as rotas /v1/chat/completions , /v1/completions , /v1/models (opcional e pode ser removida) e /v1/embeddings (opcional e pode ser removida) que são encaminhadas para o vLLM. Todo o resto, incluindo os endpoints críticos /metrics e o /health interno do vLLM, é bloqueado com abort, retornando 403 Forbidden. Isso significa que mesmo que alguém descubra o IP do servidor, não consegue extrair métricas de performance, status detalhados do modelo ou acessar documentação sensível. Complementamos com TLS 1.2/1.3 forçado via Caddy e a API Key do vLLM protegendo os endpoints OpenAI e com isto temos um servidor que segue as recomendações de segurança da documentação oficial do vLLM, minimizamos os endpoints expostos, colocamos tudo atrás de um proxy reverso confiável, e mantemos o motor de inferência completamente inacessível diretamente e sua LLM roda segura, privada e pronta para produção.

Não cheguei a configurar o rate limit, mas deixo como dever de casa caso tenha interesse.
- caddy-ratelimit

Agora contextualizados, vamos à mão na massa.

Configurações importantes

Para subirmos a aplicação, vamos precisar criar os seguintes arquivos:

.env: Onde incluiremos as nossas variáveis de ambiente usadas pelo Caddy e pelo vLLM.
Caddyfile: Configurações do nosso servidor de aplicação para fazer proxy reverso para o vLLM.
compose.yml: Docker compose para orquestrarmos nossa aplicação de forma fácil.

e para termos uma organização, vamos criar uma pasta para envolver os arquivos que vamos precisar criar, e para criar a pasta e os arquivos rode o seguinte comando no seu terminal:

mkdir llm-server; cd llm-server; touch .env Caddyfile compose.yml

e depois valide se tudo correu bem, se sim terá um resultado como o seguinte:

Feito isto, vamos configurar nosso .env com as variáveis necessárias para rodar nossos containers, e para isso vamos utilizar o nano, o conteúdo que vamos precisar inserir no nosso arquivo são:

O que é cada variável?

vLLM
- VLLM_API_KEY: Será o token que a API do vLLM vai validar a presença para permitir a inferência, pode gerar um para nosso teste com o comando openssl passwd -6 "uma chave bem segura aqui"
- HF_TOKEN: Token para baixar modelos privados, caso você tenha algum fine tuning e deseja servir ele, para conseguir este token pode seguir a documentação oficial. Neste caso como vamos utilizar um modelo aberto, pode deixar qualquer valor.
- MODEL_NAME: Nome do modelo do Hugging Face que iremos utilizar
- Fica até como desafio, servir outro modelo como o gpt-oss-20b.
Caddy
- DOMAIN: O domínio em que vamos servir nossa aplicação.
- EMAIL_SSL: O email que o caddy utiliza para que o CertMagic renove seus certificados.

# vLLM Configuration
VLLM_API_KEY=sua-chave-api-segura 
HF_TOKEN=hf_seu_token_huggingface
MODEL_NAME=Qwen/Qwen3-30B-A3B-FP8

# Caddy/SSL Configuration
DOMAIN=vllm-mgc.glaucio.tec.br
EMAIL_SSL=meuemail+vllm-server@lorem.com

Agora contextualizados vamos preencher nosso .env , abra o arquivo com o comando:

nano .env

e cole suas variáveis preenchidas com seus dados, use Ctrl + x e quando aparecer "Save modified buffer?" confirme apertando a tecla y e depois quando aparecer "File Name to Write: .env", aperte Enter .

Vamos para o nosso arquivo Caddyfile , abra ele com o nano como já descrito no passo do .env e cole nele o seguinte conteúdo:

{$DOMAIN} {
    # Habilita compressão Gzip/Zstd para performance
    encode gzip zstd

    # Configuração de Log (Opcional, bom para auditoria)
    log {
        output file /var/log/caddy/access.log
    }

    # REGRAS DE SEGURANÇA E ROTEAMENTO
    # Bloqueia tudo por padrão, exceto o bloco 'handle' abaixo

    # Página de status para verificar se o Caddy está online
    handle /health {
        respond "OK - Caddy is running on {$DOMAIN}" 200
    }

    # Página inicial com informações básicas
    handle / {
        header Content-Type text/html
        respond `<!DOCTYPE html>
<html>
<head>
    <title>vLLM API Server</title>
    <style>
        body { font-family: system-ui, sans-serif; max-width: 600px; margin: 50px auto; padding: 20px; background: #1a1a2e; color: #eee; }
        h1 { color: #00d9ff; }
        .status { background: #16213e; padding: 20px; border-radius: 8px; margin: 20px 0; }
        .ok { color: #00ff88; }
        code { background: #0f3460; padding: 2px 6px; border-radius: 4px; }
    </style>
</head>
<body>
    <h1>vLLM API Server</h1>
    <div class="status">
        <p class="ok">Proxy: Online</p>
        <p>Domain: {$DOMAIN}</p>
    </div>
    <h3>API Endpoints:</h3>
    <ul>
        <li><code>/v1/chat/completions</code></li>
        <li><code>/v1/completions</code></li>
        <li><code>/v1/models</code></li>
        <li><code>/v1/embeddings</code></li>
    </ul>
    <p><small>Health check: <a href="/health">/health</a></small></p>
</body>
</html>` 200
    }

    # Define o matcher para rotas OpenAI (Chat, Completions, Models, Embeddings)
    @openai_routes {
        path /v1/chat/completions
        path /v1/completions
        path /v1/models # pode remover caso não queria expor
        path /v1/embeddings # como vamos servir apenas LLM não é muito útil aqui no nosso caso
    }

    # Processa apenas as rotas permitidas
    handle @openai_routes {
        reverse_proxy vllm:8000 {
            # Configurações de timeout para streaming longo (LLMs)
            flush_interval -1
            transport http {
                response_header_timeout 300s
            }
        }
    }

    # Captura qualquer outra rota (metrics, health, root) e retorna 403 Forbidden
    handle {
        abort
    }

    # TLS Configuration (Automático, mas forçando protocolos seguros)
    tls {$EMAIL_SSL} {
        protocols tls1.2 tls1.3
    }
}

E por último nosso arquivo compose.yml para subirmos a aplicação, abra ele com nano compose.yml e cole o seguinte conteúdo:

services:
  vllm:
    image: vllm/vllm-openai:latest
    container_name: vllm_inference
    restart: unless-stopped
    oom_score_adj: -500
    environment:
      - VLLM_API_KEY=${VLLM_API_KEY}
      - HUGGING_FACE_HUB_TOKEN=${HF_TOKEN}
    volumes:
      - ./vllm_cache:/root/.cache/huggingface
    deploy:
      resources:
        limits:
          cpus: '6.0'
          memory: 56G
        reservations:
          cpus: '4.0'
          memory: 32G
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]
    ipc: host
    shm_size: '16gb'
    command: >
      --model ${MODEL_NAME}
      --served-model-name "qwen3-30b-a3b-fp8"
      --host 0.0.0.0
      --port 8000
      --max-model-len 16384
      --gpu-memory-utilization 0.95
      --kv-cache-dtype fp8
      --enable-prefix-caching
      --max-num-seqs 8
      --disable-log-requests
      --reasoning-parser deepseek_r1
    healthcheck:
      test: ["CMD-SHELL", "curl -f http://localhost:8000/health || exit 1"]
      interval: 15s
      timeout: 10s
      retries: 5
      start_period: 300s  # 5 minutos para carregar o modelo

  proxy:
    image: caddy:alpine
    container_name: caddy_secure_proxy
    restart: unless-stopped
    deploy:
      resources:
        limits:
          cpus: '1.0'
          memory: 512M
        reservations:
          cpus: '0.5'
          memory: 64M
    extra_hosts:
      - "host.docker.internal:host-gateway"
    ports:
      - "80:80"
      - "443:443"
      - "443:443/udp"
    environment:
      - DOMAIN=${DOMAIN}
      - EMAIL=${EMAIL_SSL}
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile
      - ./caddy_data:/data
      - ./caddy_config:/config
    depends_on:
      vllm:
        condition: service_healthy

Com nossos arquivos preenchidos, podemos executar o comando para subir nosso docker compose:

docker compose --env-file .env up

e com isso começará a baixar as imagens que vamos utilizar:

Depois de ter baixado as imagens dos nossos containers, vai aparecer na sua tela a inicialização do vLLM

e após o vLLM baixar os pesos do modelo ele irá iniciar o caddy e aguarde um tempo para configurações de SSL sejam feitas

Aí agora para deixar os containers rodando em background, aperte a tecla d como sugerido na parte inferior do terminal

e para não ter de passar por isso na próxima, suba os containers com -d no comando para subir os containers e já liberar o terminal

docker compose --env-file .env up -d

Agora feito tudo isso, nossa aplicação está rodando lindamente, mas ainda não está respondendo pois precisaremos fazer as configurações de rede para liberar as portas 80 e 443 do nosso servidor.

No próximo passo irei explicar como resolver o erro do servidor não responder

Configuração de rede para liberar acessos externos pelo nosso DNS

Agora vamos para a última etapa de configuração antes de podermos usar nossa LLM, e fazer nossas tão desejadas chamadas à API.

Acesse novamente seu console do Magalu Cloud, estando na tela inicial, clique no menu sanduíche no lado superior direito e com isto irá abrir o menu lateral.

depois clique na opção com o texto "Network", ele irá abrir um submenu flutuante à esquerda dele e então clique na opção "Grupo de Segurança" e você será redirecionado para a tela de Grupo de Segurança.

Chegando na tela Grupo de Segurança, clique no botão "Criar grupo de segurança" e irá abrir uma tela para nomear e dar uma descrição para seu novo grupo de segurança, e preencha com um nome que vá lembrar, no meu caso coloquei "tutorial-vllm-l40s" como pode ser visto na imagem abaixo.

e confirmando a criação do nosso grupo, voltaremos para a página inicial de Grupo de Segurança, agora vamos precisar clicar no novo grupo que criamos, no meu caso foi "tutorial-vllm-l40s".

Clicando nele, iremos para a página do nosso Grupo de Segurança e nela iremos clicar no botão "Adicionar regra", preencha o formulário para que nosso servidor possa responder às requisições que faremos para ele. Devemos liberar a porta 443 para entrada, aceitando requisições de qualquer origem; ou, caso você tenha um IP fixo que sempre chamará a API, pode incluí-lo no preenchimento. O meu ficou da seguinte forma:

Clique em "Adicionar regra", e após fechar a tabela onde lista as regras deve conter agora a regra de entrada para a porta 443:

agora vá até a página da nossa máquina virtual e clique na "Tabzinha" (Contornada na imagem em vermelho) de rede e verá uma tela como a do print abaixo.

Estando nesta página, clique no botão azul com o texto "Adicionar grupo de segurança", na modal que irá abrir, busque o Grupo de segurança que criamos e configuramos.

Após adicionar, podemos validar se o nosso domínio está respondendo às requisições

Caso suas configurações estiverem corretas, você verá uma tela como acima, mas com o seu domínio.

Agora podemos fazer chamadas para nosso modelo com o seguinte comando:

curl -X POST 'https://vllm-mgc.glaucio.tec.br/v1/chat/completions' \
  --header 'Content-Type: application/json' \
  --header 'Authorization: Bearer sua-chave-api-segura' \
  --data '{
  "model": "qwen3-30b-a3b-fp8",
  "messages": [
    {
      "role": "system",
      "content": "Você é um assistente muito inteligente, que pensa antes de qualquer resposta, que segue a ciência, e deve ser muito dedicado a acertar."
    },
    {
      "role": "user",
      "content": "você conhece o acre? /no_think"
    }
  ]
}'

Como estamos servindo um modelo com capacidade de "raciocínio", para habilitar enviamos na mensagem o texto /think e para desabilitar envie /no_think e configuramos o parser --reasoning-parser deepseek_r1 , então quando o "raciocínio" for ativado ele virá em choices[0].message.reasoning e caso esteja desativado, essa chave terá o valor nulo.

Exemplo de resposta com /think :

{
  "id": "chatcmpl-871a1a570fd3a0d9",
  "object": "chat.completion",
  "created": 1769888901,
  "model": "qwen3-30b-a3b-fp8",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "\n\nSim, conheço o **acre**! Ele pode se referir a **dois conceitos principais**:\n\n---\n\n### 1. **Unidade de área (acre)**  \nO **acre** é uma unidade de medida de área do sistema imperial, amplamente usada em países como os Estados Unidos, Reino Unido e outros.  \n- **Definição**: 1 acre = **4.046,86 metros quadrados** (m²).  \n- **Equivalência**:  \n  - 1 acre ≈ 0,4047 hectares (ha).  \n  - 1 hectare ≈ 2,471 acres.  \n- **Uso comum**: Medição de terrenos, campos de futebol, fazendas, etc.  \n  - Por exemplo, um campo de futebol oficial tem cerca de **0,71 acre**.\n\n---\n\n### 2. **Estado do Acre (Brasil)**  \nO **Acre** também é um **estado da Amazônia brasileira**, localizado no **norte do Brasil**, na região da **Amazônia Ocidental**.  \n- **Capital**: **Rio Branco**.  \n- **Características**:  \n  - Faz parte da **Bacia do Rio Amazonas**.  \n  - Conhecido por sua **floresta tropical**, riqueza em biodiversidade e culturas indígenas.  \n  - Tem uma economia baseada em **extrativismo (como a seringueira)** e **agricultura**.  \n  - O **Parque Nacional do Acre** e a **Reserva da Biosfera do Acre** são áreas protegidas.  \n- **População**: Cerca de **900.000 habitantes** (estatísticas de 2023).  \n\n---\n\nSe você se referia a algo específico (como uma empresa, termo técnico ou outro contexto), me avise que posso aprofundar! 😊",
        "refusal": null,
        "annotations": null,
        "audio": null,
        "function_call": null,
        "tool_calls": [],
        "reasoning": "\nOkay, the user is asking if I know about Acre. First, I need to confirm what exactly they're referring to. Acre can mean a few things. The most common is the unit of area, which is 4,046.86 square meters. But there's also Acre as a place, like the Acre state in Brazil, or maybe even a company or a term in another context.\n\nI should start by acknowledging that Acre can refer to multiple things. Let me break it down. First, the unit of area. Explain that it's a unit used in the imperial system, commonly used in countries like the US, UK, and others. Mention its conversion to square meters and other units. Then, mention the Brazilian state, Acre, located in the northwest of Brazil, part of the Amazon region. Highlight its geography, maybe the capital, Rio Branco, and some key points about the state, like its natural resources or cultural aspects.\n\nWait, the user might be asking about the state, but I should cover both possibilities. Also, check if there's another context, like a company or a term in a different field. But I think the two main ones are the unit and the state. Make sure to present both clearly. Avoid any confusion by structuring the answer with headings or bullet points. Also, verify the accuracy of the information, like the exact area of an acre, the location of Acre state, and its capital. Maybe mention that the state is known for its rainforests and biodiversity. Double-check the conversion factors to ensure they're correct. Alright, that should cover the main points.\n",
        "reasoning_content": "\nOkay, the user is asking if I know about Acre. First, I need to confirm what exactly they're referring to. Acre can mean a few things. The most common is the unit of area, which is 4,046.86 square meters. But there's also Acre as a place, like the Acre state in Brazil, or maybe even a company or a term in another context.\n\nI should start by acknowledging that Acre can refer to multiple things. Let me break it down. First, the unit of area. Explain that it's a unit used in the imperial system, commonly used in countries like the US, UK, and others. Mention its conversion to square meters and other units. Then, mention the Brazilian state, Acre, located in the northwest of Brazil, part of the Amazon region. Highlight its geography, maybe the capital, Rio Branco, and some key points about the state, like its natural resources or cultural aspects.\n\nWait, the user might be asking about the state, but I should cover both possibilities. Also, check if there's another context, like a company or a term in a different field. But I think the two main ones are the unit and the state. Make sure to present both clearly. Avoid any confusion by structuring the answer with headings or bullet points. Also, verify the accuracy of the information, like the exact area of an acre, the location of Acre state, and its capital. Maybe mention that the state is known for its rainforests and biodiversity. Double-check the conversion factors to ensure they're correct. Alright, that should cover the main points.\n"
      },
      "logprobs": null,
      "finish_reason": "stop",
      "stop_reason": null,
      "token_ids": null
    }
  ],
  "service_tier": null,
  "system_fingerprint": null,
  "usage": {
    "prompt_tokens": 58,
    "total_tokens": 836,
    "completion_tokens": 778,
    "prompt_tokens_details": null
  },
  "prompt_logprobs": null,
  "prompt_token_ids": null,
  "kv_transfer_params": null
}

Exemplo de resposta com /no_think :

{
  "id": "chatcmpl-a0710ba10d25e658",
  "object": "chat.completion",
  "created": 1769889464,
  "model": "qwen3-30b-a3b-fp8",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "\n\nClaro, eu conheço o Acre! O Acre é um estado da Amazônia brasileira, localizado no extremo oeste do Brasil, fazendo fronteira com a Bolívia e o Peru. É um dos estados mais extensos do Brasil e é conhecido por sua vasta floresta tropical, rica em biodiversidade e por ser um dos últimos grandes territórios preservados da Amazônia.\n\nAlguns pontos interessantes sobre o Acre:\n\n- **Capital**: Rio Branco\n- **População**: Cerca de 900 mil habitantes (dados aproximados)\n- **Cultura**: Mistura de influências indígenas, brasileiras e bolivianas.\n- **Economia**: Baseada principalmente na agricultura (como a seringueira, o cauim, o açaí), na pecuária e na exploração de recursos naturais.\n- **Ecologia**: É uma das regiões mais preservadas da Amazônia, com muitas áreas de proteção ambiental.\n- **História**: Foi cedido ao Brasil pela Bolívia em 1903, através do Tratado de Petrópolis.\n\nO Acre também é famoso por sua paisagem única, com rios, florestas e uma cultura rica e diversificada. Se quiser, posso te contar mais sobre algum aspecto específico do Acre!",
        "refusal": null,
        "annotations": null,
        "audio": null,
        "function_call": null,
        "tool_calls": [],
        "reasoning": "\n\n",
        "reasoning_content": "\n\n"
      },
      "logprobs": null,
      "finish_reason": "stop",
      "stop_reason": null,
      "token_ids": null
    }
  ],
  "service_tier": null,
  "system_fingerprint": null,
  "usage": {
    "prompt_tokens": 60,
    "total_tokens": 380,
    "completion_tokens": 320,
    "prompt_tokens_details": null
  },
  "prompt_logprobs": null,
  "prompt_token_ids": null,
  "kv_transfer_params": null
}

Então a partir de agora é só ser feliz.

Em breve trarei mais um post fazendo múltiplas requisições para nosso modelo, trazendo números de tempo de resposta e qualidade das respostas do modelo.

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 criar e escalar workloads Kubernetes com Container Registry na Magalu Cloud

Monica Hillman — Thu, 18 Dec 2025 21:22:08 +0000

Imagine um cenário bem comum: seu time mantém uma API (por exemplo, checkout-api) e um worker de processamento assíncrono (por exemplo, order-worker). Em dias normais, 2 réplicas da API dão conta. Mas em promoções, campanhas ou picos sazonais, o tráfego sobe rápido, e você precisa:

publicar uma nova versão da aplicação com segurança (sem subir binário em VM na mão),
garantir que o cluster puxe a imagem correta (privada) com controle de acesso,
aumentar réplicas rapidamente para absorver carga,
e manter um fluxo simples para repetir isso toda semana (ou todo dia).

É exatamente aí que entram Container Registry + Kubernetes:

o Container Registry vira o “repositório oficial” de imagens da sua aplicação (com versionamento e permissão),
o Kubernetes executa essas imagens como workloads (Deployments/Pods) e permite escalar o número de réplicas de forma controlada.

Neste artigo, você vai aprender:

Como criar e usar o Container Registry da Magalu Cloud
Como autenticar Docker e Kubernetes no registry
Como criar workloads Kubernetes usando imagens privadas
Como escalar workloads Kubernetes de forma simples

Pré-requisitos

Ter uma conta ativa na Magalu Cloud
Ter a CLI mgc instalada e configurada com suas credenciais
Ter um cluster Kubernetes criado na Magalu Cloud
Ter acesso ao kubectl configurado para o cluster
Ter o Docker (ou ferramenta compatível) instalado localmente

Visão geral da arquitetura

O fluxo básico é o seguinte:

Criar um Container Registry
Construir e publicar imagens no registry
Executar workloads no Kubernetes usando essas imagens
Escalar a aplicação conforme a necessidade

Esse modelo separa claramente:

build e versionamento (Container Registry)
execução e escalabilidade (Kubernetes)

O que é o Container Registry

O Container Registry da Magalu Cloud é o serviço responsável por armazenar e distribuir imagens de container utilizadas pelas aplicações. Ele funciona como um repositório central, compatível com o padrão OCI/Docker, onde o time publica as imagens geradas durante o processo de build e a partir do qual outros serviços, como o Kubernetes, conseguem consumi-las.

Na prática, o registry passa a ser a fonte oficial das imagens da aplicação. Cada versão gerada pode ser identificada por uma tag, permitindo controlar exatamente qual versão será executada em cada ambiente. Isso facilita o versionamento, o rollback e a padronização do processo de entrega.

Além disso, o Container Registry permite manter imagens privadas, garantindo que apenas usuários e serviços autorizados consigam acessá-las. Essa característica é essencial em ambientes de produção, onde o código da aplicação não deve ficar exposto em registries públicos.

Por fim, o serviço é integrado de forma direta ao Kubernetes da Magalu Cloud, possibilitando que os clusters façam o pull das imagens privadas de maneira segura e automatizada, sem a necessidade de soluções externas ou configurações complexas.

Criando um Container Registry

Antes de autenticar o Docker ou publicar imagens, é necessário criar um registry.

Esse recurso funciona como um namespace para organização das imagens.

Criar o registry via CLI

mgc container-registry registries create --name="meu-registry"

Esse comando cria o registry e o associa à sua conta e região.

Listar registries existentes

mgc container-registry registries list

Se já existir um registry, ele pode ser reutilizado.

Endpoints do Container Registry

O endpoint depende da região:

Brasil – Sudeste (br-se1)

container-registry.br-se1.magalu.cloud

Brasil – Nordeste (br-ne1)

container-registry.br-ne1.magalu.cloud

Esse endpoint será usado em:

docker login
docker push
manifests do Kubernetes

Autenticação no Container Registry

A autenticação utiliza credenciais específicas do serviço, distintas da conta principal da Magalu Cloud.

1. Listar credenciais do registry

mgc container-registry credentials list

Esse comando retorna o usuário e a senha/token do Container Registry.

2. Autenticar o Docker localmente

Exemplo para br-se1:

docker login https://container-registry.br-se1.magalu.cloud

Informe:

Usuário → retornado pela CLI
Senha → token retornado pela CLI

Após isso, o Docker estará autenticado para push e pull.

Publicando uma imagem no Registry

Fluxo típico de publicação:

# Construir a imagem
docker build -t meu-app:1.0.0 .
# Marcar a imagem com o registry
docker tag meu-app:1.0.0 \
container-registry.br-se1.magalu.cloud/meu-registry/meu-app:1.0.0
# Enviar a imagem
docker push container-registry.br-se1.magalu.cloud/meu-registry/meu-app:1.0.0

Boas práticas:

use tags versionadas
evite sobrescrever latest em produção

Kubernetes na Magalu Cloud

O que é o Kubernetes gerenciado

O Kubernetes da Magalu Cloud é um serviço gerenciado que fornece um cluster pronto para execução de workloads containerizados, eliminando grande parte da complexidade operacional envolvida na administração de um ambiente Kubernetes.

Em vez de lidar diretamente com servidores, sistemas operacionais e componentes internos do cluster, o desenvolvedor passa a interagir com o Kubernetes de forma declarativa, por meio de manifests que descrevem como a aplicação deve ser executada.

A Magalu Cloud é responsável por gerenciar os principais componentes da plataforma, incluindo:

Plano de controle, que engloba serviços como API Server, agendador e controladores do Kubernetes
Infraestrutura subjacente, como nós de trabalho, capacidade computacional e disponibilidade do cluster
Integração com rede, permitindo que pods e serviços se comuniquem de forma padronizada dentro do ambiente

Com isso, o time não precisa se preocupar com tarefas como instalação do Kubernetes, atualizações de componentes, configuração inicial de rede ou manutenção do plano de controle.

O foco do desenvolvedor fica restrito ao que realmente importa no dia a dia:

definir Deployments, Services e outros recursos via YAML
versionar e atualizar aplicações com segurança
escalar workloads conforme a demanda
integrar o cluster com serviços da própria plataforma, como o Container Registry

Esse modelo reduz o esforço operacional e torna o uso do Kubernetes mais acessível, especialmente para times que querem adotar containers e orquestração sem assumir a complexidade completa de operar um cluster por conta própria.

Autenticação do Kubernetes no Container Registry

Para que o Kubernetes consiga baixar imagens privadas, é necessário criar um Secret do tipo docker-registry.

Criando o Secret

kubectl create secret docker-registry magalu-registry-secret \--docker-server=container-registry.br-se1.magalu.cloud \ --docker-username=<USUARIO_DO_REGISTRY> \ --docker-password=<SENHA_DO_REGISTRY> \ --docker-email=<SEU_EMAIL>

Criando um workload Kubernetes

Exemplo de Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: meu-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: meu-app
  template:
    metadata:
      labels:
        app: meu-app
    spec:
      imagePullSecrets:
        - name: magalu-registry-secret
      containers:
        - name: app
          image: container-registry.br-se1.magalu.cloud/meu-registry/meu-app:1.0.0
          ports:
            - containerPort: 8080

Aplicando o manifesto:

kubectl apply -f deployment.yaml

Escalando workloads Kubernetes

Escalonamento manual via CLI:

kubectl scale deployment meu-app --replicas=4

O Kubernetes cria ou remove pods automaticamente.

Atualizando versões da aplicação

Para atualizar a aplicação:

Gere uma nova imagem
Envie ao registry
Atualize a tag no Deployment

image: container-registry.br-se1.magalu.cloud/meu-registry/meu-app:1.1.0

Ao aplicar o manifesto, o Kubernetes executa um rolling update.

Conclusão

A integração entre Container Registry e Kubernetes na Magalu Cloud permite criar aplicações containerizadas de forma segura, escalável e padronizada.

Com esse modelo, você consegue:

Criar e organizar registries privados
Publicar imagens versionadas
Executar workloads Kubernetes
Escalar aplicações conforme a demanda

Tudo isso utilizando serviços gerenciados, integrados e operando sobre infraestrutura no Brasil.

Como provisionar um cluster PostgreSQL no DBaaS da Magalu Cloud com failover automático

Monica Hillman — Tue, 16 Dec 2025 21:32:38 +0000

Bancos de dados relacionais continuam sendo componentes centrais em aplicações modernas. Quando o banco é crítico para o negócio, alta disponibilidade deixa de ser diferencial e passa a ser requisito.

A Magalu Cloud oferece o Database as a Service (DBaaS), que abstrai a complexidade operacional de bancos de dados gerenciados, incluindo replicação e failover automático.

Neste artigo, você vai aprender:

O que é um cluster PostgreSQL no DBaaS da Magalu Cloud
Quando faz sentido usar alta disponibilidade
Como provisionar um cluster PostgreSQL com failover automático usando a CLI mgc

O que é um cluster PostgreSQL

Um cluster PostgreSQL no DBaaS da Magalu Cloud é uma configuração de alta disponibilidade, formada por múltiplos nós do banco de dados:

1 nó primário, responsável por leitura e escrita
Réplicas em espera (standby), distribuídas em Zonas de Disponibilidade diferentes
Failover automático, que promove uma réplica a primária em caso de falha

As alterações realizadas no nó primário são replicadas continuamente para as réplicas, reduzindo o tempo de indisponibilidade e o risco de perda de dados.

A distribuição entre Zonas de Disponibilidade (AZs) garante maior resiliência dentro de uma mesma região.

Quando usar um cluster PostgreSQL

Clusters PostgreSQL com failover automático são indicados quando a aplicação:

Não pode tolerar indisponibilidade prolongada
Precisa de replicação contínua de dados
Depende de alta disponibilidade para o negócio
Quer reduzir esforço operacional com gerenciamento de banco

Provisionamento via CLI (`mgc`)

Pré-requisitos

Antes de começar, você precisa:

Ter a CLI mgc instalada e configurada
Ter acesso à região desejada
Identificar a engine PostgreSQL e o tipo de instância adequado

1. Listar engines disponíveis

Primeiro, identifique a engine PostgreSQL disponível:

mgc dbaas engines list --status=ACTIVE

Anote o id correspondente ao PostgreSQL (por exemplo, PostgreSQL 16).

2. Listar tipos de instância compatíveis

Em seguida, liste os tipos de instância disponíveis para essa engine:

mgc dbaas instance-types list \
  --engine-id="SEU_ENGINE_ID" \
  --status=ACTIVE

Cada tipo de instância define CPU e memória de cada nó do banco.

Entendendo o `compatible_product`

No resultado, observe o campo:

SINGLE_INSTANCE - pode ser usado apenas para instâncias simples
CLUSTER - pode ser usado apenas para clusters com alta disponibilidade

Esse campo é informativo e serve para orientar a escolha correta do instance-type-id.

3. Criar um cluster PostgreSQL com failover automático

A criação do cluster é feita com o comando mgc dbaas clusters create.

Diferente de uma instância simples, o cluster já nasce com múltiplos nós e com alta disponibilidade configurada desde o início.

Apenas tipos de instância com compatible_product: CLUSTER podem ser utilizados neste comando.

Exemplo de criação de cluster

mgc dbaas clusters create \
  --name="meu-postgres-cluster" \
  --user="admin" \
  --password="SenhaSegura!" \
  --engine-id="ID_DA_ENGINE_POSTGRESQL" \
  --instance-type-id="ID_DO_INSTANCE_TYPE_CLUSTER" \
  --volume.size=100 \
  --volume.type="CLOUD_NVME20K"

Principais parâmetros

--name
Nome do cluster PostgreSQL
--user
Usuário administrador do banco
--password
Senha do usuário administrador
--engine-id
Identificador da engine PostgreSQL
--instance-type-id
Tipo de instância compatível com CLUSTER, que define CPU e memória de cada nó
--volume.size
Tamanho do volume de dados em GiB
--volume.type
Tipo de armazenamento gerenciado do DBaaS - Você pode verificar os valores na documentação.

Após a execução, o cluster entra em processo de provisionamento, o que pode levar alguns minutos.

4. Acompanhar o status do cluster e das instâncias

Para acompanhar o status do cluster:

mgc dbaas clusters get "ID_DO_CLUSTER"

Após a criação, você pode listar os nós do cluster:

mgc dbaas instances list

E obter detalhes de um nó específico:

mgc dbaas instances get "ID_DA_INSTANCIA"

Failover automático na prática

Quando o cluster está ativo, o DBaaS da Magalu Cloud monitora continuamente o nó primário. Em caso de falha:

Uma réplica é promovida automaticamente a primária
O endpoint do cluster permanece o mesmo
A aplicação precisa apenas lidar com reconexões

Todo o processo ocorre sem intervenção manual.

Boas práticas

Utilize senhas fortes para usuários do banco
Escolha tipos de instância compatíveis com a carga da aplicação
Monitore o status das instâncias via CLI
Garanta que a aplicação lide bem com reconexões

Conclusão

Provisionar um cluster PostgreSQL com failover automático no DBaaS da Magalu Cloud permite unir simplicidade operacional e alta disponibilidade.

Com a CLI mgc, você consegue:

Identificar engines e tipos de instância
Criar clusters PostgreSQL com alta disponibilidade desde a criação
Contar com failover automático gerenciado pela plataforma
Monitorar o estado do banco de dados de forma centralizada

Isso reduz a complexidade operacional e permite que o time foque no desenvolvimento da aplicação, aproveitando a infraestrutura gerenciada da Magalu Cloud.

Como anexar um volume de Block Storage à sua VM Linux na Magalu Cloud (via CLI)

Monica Hillman — Tue, 09 Dec 2025 18:53:01 +0000

Quando a gente começa a usar nuvem, é comum pensar na máquina virtual como “o computador inteiro”: CPU, memória e aquele disco onde o sistema operacional está instalado. Só que esse disco de sistema, em muitos provedores, é efêmero: se você recriar a VM, trocar o tipo, apagar a instância ou tiver um incidente, aquele armazenamento pode ir embora junto. Para ambientes de teste isso pode até ser tolerável. Para qualquer coisa que envolva dado importante, não.

É justamente nesse ponto que entra o Block Storage.

De forma conceitual, Block Storage é um tipo de armazenamento em que a nuvem entrega para você um disco em blocos, exposto à VM como se fosse um segundo HD ou SSD. Esse disco não depende da “vida” da máquina virtual: ele é um recurso separado, com identidade própria, que pode ser criado, anexado, desanexado e reaproveitado em outras instâncias. Você continua administrando o sistema de arquivos (ext4, XFS, etc.) dentro do sistema operacional, mas a infraestrutura de desempenho, replicação e disponibilidade é responsabilidade da nuvem.

Na Magalu Cloud, esses volumes são oferecidos em perfis pensados para diferentes cargas, com base em NVMe e latência baixa, o que os torna apropriados para bancos de dados, sistemas de arquivos compartilhados, aplicações que fazem muitas leituras e escritas e até para separar melhor responsabilidades: um volume só para banco, outro para uploads de usuários, outro para logs de auditoria, e assim por diante.

Os casos de uso aparecem rápido:

um banco de dados que não pode sumir se você precisar recriar a VM;
um diretório de uploads de um e-commerce que precisa crescer sem que você mude toda a máquina;
um conjunto de logs de aplicação que você conserva em disco resiliente para análise posterior;
volumes dedicados a ambientes de homologação, criados a partir de snapshots de produção.

O desafio prático que este artigo resolve é simples e muito real:

“Tenho uma VM Linux na Magalu Cloud e quero adicionar um disco persistente, separado do sistema, usando a CLI.”

A ideia é caminhar desde o conceito até o comando real, mostrando como criar o volume, anexar à VM e prepará-lo no Linux para uso cotidiano.

Criando e usando um volume de Block Storage na Magalu Cloud

Vamos supor o seguinte cenário: você já criou uma VM Linux na Magalu Cloud, instalou a CLI mgc, autenticou na sua conta e agora quer um novo disco de 10 GiB para armazenar dados da aplicação em produção ou em teste.

Antes de escrever qualquer comando, vale reforçar uma regra de arquitetura: volume e VM precisam estar na mesma região e na mesma Zona de Disponibilidade (AZ). Isso existe porque o volume é fisicamente associado a uma infraestrutura específica; tentar anexar a uma VM em outra zona simplesmente não faz sentido do ponto de vista de rede e desempenho.

Com isso em mente, o fluxo natural é:

criar o volume de Block Storage na região/AZ correta;
anexar esse volume à VM;
entrar na VM, formatar o dispositivo e montar em um diretório;
tornar a montagem persistente entre reboots.

Criando o volume pela CLI

A criação do volume pela CLI é direta. Você descreve o tamanho, o nome e o tipo de desempenho desejado. Um exemplo típico seria:

mgc block-storage volumes create   --name volume-app-prod   --size 10   --type.name cloud_nvme1k

O --name identifica o volume dentro da região; é um rótulo lógico, útil para saber, por exemplo, que esse é o volume de dados da aplicação de produção. O --size define o tamanho em gibibytes (GiB) podendo ser 10, 20, 50, 100, e assim por diante, dentro dos limites que a Magalu Cloud impõe para aquele tipo de volume. Já --type.name aponta para o perfil de IOPS/latência. Perfis baseados em NVMe costumam ser adequados para cargas que fazem muito I/O, como bancos de dados e aplicações mais intensas.

Depois da criação, o volume nasce em um estado equivalente a “livre”, pronto para ser anexado. Você pode conferir isso com um simples:

mgc block-storage volumes list

Na listagem, o volume recém-criado aparece geralmente com o status available. Enquanto ele estiver assim, nenhuma VM está usando esse recurso.

Anexando o volume à máquina virtual

O passo seguinte é anexar à máquina virtual. Conceitualmente, é como plugar um SSD extra em um servidor físico: a VM passa a “enxergar” um novo disco. Para que isso funcione, a VM precisa estar em um estado válido (ligada ou desligada) e compartilhar a mesma AZ do volume. Em muitas arquiteturas, é mais seguro realizar esse tipo de operação com a instância desligada, principalmente se você estiver mexendo em ambientes sensíveis, ainda que a plataforma permita anexar com a VM em execução.

Com o ID da VM e do volume em mãos, o comando é semelhante a:

mgc block-storage volumes attach   --id vol-1234567890abcdef   --virtual-machine-id vm-abcdef1234567890

Depois de alguns instantes, o volume deixa o estado available e passa para algo como in-use, indicando que agora existe uma relação concreta com uma máquina virtual.

Preparando o volume dentro da VM

A partir desse ponto, a “bola” passa para o sistema operacional. Dentro da VM, esse volume aparece como um novo dispositivo de bloco, por exemplo /dev/vdb. Para enxergar isso, você pode usar:

lsblk

A saída costuma mostrar o disco de sistema como vda com partições e pontos de montagem já preenchidos, e o novo volume como vdb, ainda sem partição e sem sistema de arquivos. É aqui que entra a parte de teoria de armazenamento que desenvolvedores às vezes pulam: um volume de Block Storage é só um conjunto de blocos; cabe a você criar o sistema de arquivos por cima dele.

Se o volume é novo e não contém dados, faz sentido criar um sistema de arquivos moderno como ext4:

sudo mkfs.ext4 /dev/vdb

Esse comando grava estruturas internas no volume, preparando-o para guardar arquivos, diretórios, permissões e tudo mais que o kernel vai gerenciar. Caso o volume tenha sido criado a partir de um snapshot, a situação é outra: nesses casos, ele já traz um sistema de arquivos e dados, então não se deve formatar novamente.

Montando o volume em um diretório

Com o sistema de arquivos pronto, o próximo passo é escolher um ponto de montagem. Um caminho clássico para dados de aplicação é algo como /mnt/data:

sudo mkdir -p /mnt/data
sudo mount /dev/vdb /mnt/data
df -h | grep /mnt/data

A partir desse momento, qualquer escrita em /mnt/data é uma escrita no volume de Block Storage. É aqui que você pode configurar o banco de dados para usar um diretório dentro desse caminho, apontar uploads de usuário, logs de auditoria ou o que fizer sentido para a sua arquitetura.

Tornando a montagem persistente com `/etc/fstab`

No entanto, essa montagem ainda é temporária: se você reiniciar a VM, o Linux não vai remontar automaticamente o volume. Para que isso aconteça, entra em cena o arquivo /etc/fstab, onde ficam descritas as montagens permanentes.

Uma prática recomendada é montar não pelo nome /dev/vdb, mas pelo UUID do sistema de arquivos, que é estável mesmo se a ordem de dispositivos mudar. Você descobre o UUID com:

sudo blkid /dev/vdb

Com a informação em mãos, edita o /etc/fstab com:

sudo nano /etc/fstab

E adiciona uma linha descrevendo a montagem, algo nesta linha:

UUID=abcd-1234-...   /mnt/data   ext4   defaults   0   0

Antes de reiniciar, é sempre prudente testar a configuração desmontando e pedindo para o sistema montar tudo de novo:

sudo umount /mnt/data
sudo mount -a

Se não houver mensagens de erro, o Linux aceitou a sintaxe e vai remontar o volume automaticamente na próxima inicialização. Assim, você garante que o diretório de dados da sua aplicação volta exatamente ao mesmo lugar, mesmo que a VM seja restartada diversas vezes.

Do ponto de vista conceitual, a partir daqui você já está usufruindo das propriedades do Block Storage: o disco de sistema continua efêmero (caso deseje), mas os dados críticos residem em um volume persistente, que pode ser dimensionado, copiado via snapshot ou até reaproveitado em outra VM, dependendo da necessidade.

Gerenciando o ciclo de vida: resize, retype e snapshots

Além dessa trilha básica, a CLI também oferece operações de ciclo de vida interessantes. É possível, por exemplo, aumentar o tamanho do volume (sempre para cima) quando o espaço se aproximar do limite, ou alterar o tipo de desempenho (“retype”) para um perfil com mais IOPS conforme a carga evolui. Outra operação comum é a criação de snapshots, que são cópias pontuais do volume: a partir de um snapshot, você consegue gerar um novo volume idêntico para testes, homologação ou recuperação de desastre, reduzindo impacto na produção.

Conclusão

Block Storage é um daqueles conceitos que parecem meramente “infra” à primeira vista, mas que definem a diferença entre um ambiente frágil e uma arquitetura preparada para crescer. Ao separar o disco de dados da vida da máquina virtual, você passa a tratar armazenamento como um recurso de primeira classe: com identidade própria, políticas de backup, perfis de desempenho e possibilidades de migração.

Ao longo do texto, vimos como esse modelo funciona na prática na Magalu Cloud: um volume NVMe criado via CLI, anexado a uma VM, formatado e montado em um diretório específico, pronto para receber dados de aplicação. Esse caminho, embora simples, libera algumas boas práticas importantes: não guardar banco de dados no disco de sistema, isolar uploads de usuários, manter logs críticos em armazenamento persistente e poder, se necessário, recriar a VM sem derrubar o estado da aplicação.

Na Magalu Cloud, a ideia é justamente oferecer essa base de infraestrutura com cara de nuvem moderna, mas com vantagens muito concretas para o dia a dia de quem desenvolve no Brasil: cobrança em reais, foco em soberania de dados, documentação em português e integração com o ecossistema Magalu. Se você ainda não experimentou, vale criar uma VM de laboratório, seguir o passo a passo deste artigo e começar a construir suas próprias combinações de volumes, snapshots e ambientes.

Como criar e gerenciar seu primeiro banco PostgreSQL na Magalu Cloud

Monica Hillman — Wed, 26 Nov 2025 16:09:42 +0000

No desenvolvimento de aplicações modernas, a escolha da infraestrutura de dados é tão crítica quanto a escolha da linguagem de programação. Este artigo explora o uso do PostgreSQL no ambiente gerenciado (DBaaS) da Magalu Cloud, detalhando os benefícios do modelo "as a Service", o que é o PostgreSQL e um tutorial prático de implementação.

1. Por que adotar Database as a Service (DBaaS)?

Antes de entrarmos em comandos e configurações, é essencial entender a mudança de paradigma. Antigamente, gerenciar um banco de dados significava comprar hardware, instalar o sistema operacional, configurar o banco, gerenciar patches de segurança e configurar backups manuais.

O modelo DBaaS (Database as a Service) remove o "trabalho pesado". Ao optar pelo DBaaS da Magalu Cloud, você transfere a responsabilidade da infraestrutura física e da manutenção básica para o provedor.

Principais vantagens:

Sua equipe foca em otimizar queries e modelagem de dados, não em atualizar o sistema operacional do servidor.
Aumentar recursos (CPU, RAM, Disco) é feito com poucos cliques ou comandos, sem necessidade de migrações físicas complexas.
Recursos nativos de backup (snapshots) e proteção de rede simplificam a conformidade e a recuperação de desastres.

2. Por que PostgreSQL?

O PostgreSQL é amplamente considerado o banco de dados relacional open-source mais avançado do mundo. Ele não é apenas um depósito de dados, mas uma plataforma robusta de processamento.

3. PostgreSQL na Magalu Cloud

Fase 1: Planejamento e Criação

Selecione a versão do banco de dados desejada:

Ao criar sua instância, você deve tomar decisões de arquitetura baseadas no custo e performance.

Escolha do Tipo de Instância:
- Balanced Value (BV): Ideal para ambientes de desenvolvimento, testes ou aplicações com tráfego moderado. Custo reduzido.
- Dedicated Performance (DP): CPUs dedicadas para ambientes de produção que exigem consistência e alto rendimento.

Armazenamento: Escolha entre 10 GiB e 10 TiB (SSD), definindo o IOPS necessário para sua carga de trabalho.

Escolha um ID e senha de acesso.

Determine o horário que deseja para acontecer a sua cópia de segurança.

Atenção: O banco é criado com um IP Privado. Ele só é acessível dentro da rede da Magalu Cloud. Você não conseguirá acessá-lo diretamente do seu computador local sem uma "ponte".

Fase 2: Conexão (O padrão Jump Host)

Como o banco reside em uma rede privada para segurança, você precisa de uma Máquina Virtual (VM) na mesma região (ex: br-se1) para atuar como intermediário.

Passo a passo:

Acesse sua VM (Ubuntu/Debian) via SSH.

Instale o cliente PostgreSQL:

sudo apt update && sudo apt install postgresql-client

Conecte-se à instância gerenciada usando as credenciais fornecidas na criação:
```
psql -h "IP_PRIVADO_DO_BANCO" -U "usuario_admin" -d "postgres"
```

Uma vez logado, crie seu banco de produção:

CREATE DATABASE minha_loja;
\c minha_loja

Fase 3: Gerenciamento via CLI (`mgc`)

A Magalu Cloud oferece uma ferramenta de linha de comando poderosa (mgc). Aqui estão os comandos essenciais para o dia a dia.

Listar e Verificar Status:
Para ver o IP, versão e se o banco está "Ligado":

mgc dbaas instances list
# ou para detalhes específicos
mgc dbaas instances get "instance-id"

Escalar Recursos (Resize):
Precisa de mais poder? Você pode aumentar a máquina ou o disco (o disco só pode ser aumentado, nunca diminuído).

# Alterar tipo de instância
mgc dbaas instances resize --instance-type-id="novo-id-dp"

# Aumentar disco para 50GB
mgc dbaas instances resize --volume.size=50

Gerenciamento de Energia:
Vai fazer manutenção ou quer economizar em ambiente de teste durante a noite?

mgc dbaas instances stop "instance-id"  # Desligar
mgc dbaas instances start "instance-id" # Ligar

Fase 4: Segurança e monitoramento

Snapshots e Backups:
Configure snapshots automáticos na criação (retenção de 1 a 30 dias). Para criar um manual antes de uma grande mudança:

mgc dbaas snapshots instances-snapshots create \
  --instance-id="id" \
  --name="snapshot-pre-deploy"

Logs em Tempo Real:
A Magalu Cloud faz o streaming de logs na porta 5140. De dentro da sua VM, você pode monitorar o que está acontecendo no banco:

ncat IP_DO_DBAAS 5140

Monitoramento Visual:
Para métricas avançadas, o ambiente suporta integração com Prometheus (porta 9090) e Grafana (porta 3000). Certifique-se de liberar essas portas no Security Group da sua VM de monitoramento para visualizar consumo de CPU, memória e conexões ativas.

Conclusão

Utilizar o PostgreSQL na Magalu Cloud une a flexibilidade do melhor banco relacional do mercado com a segurança e facilidade de uma infraestrutura gerenciada brasileira. Seja para iniciar um MVP ou migrar um legado, o ambiente oferece as ferramentas de CLI e Console necessárias para escalar com confiança.