Pular para o conteúdo principal

3 publicações com a etiqueta "DevOps"

Ver todas as etiquetas

Alternativas ao LocalStack que você deveria conhecer

· 5 min para ler
Ludmila Silva
Cloud & DevOps Engineer

A partir do dia 31 de março de 2026, o LocalStack deixou de disponibilizar a versão Community, movendo diversos serviços core para planos pagos. Na prática, isso impacta diretamente aqueles que utilizavam a ferramenta para testes sem custo.

Mas se tem algo interessante na comunidade open source é que se uma porta fecha, outras várias são abertas. Por isso, resolvi reunir algumas opções open source para quem quer continuar desenvolvendo e testando localmente, com foco em AWS, mas sem estourar o orçamento no fim do mês.

Ah, além de falar brevemente dessas soluções, vamos fazer alguns testes rápidos. Por isso, certifique-se de ter o Docker e AWS CLI instalados.

Bora lá?

Floci

Eu encontrei o Floci em um post no LinkedIn escrito pelo Fabiano Moura, e achei a proposta muito válida: ser acessível e open source desde o início.

Atualmente, o Floci emula 22 serviços da AWS, desde o S3 ao CloudFormation. Ainda há serviços core da AWS não disponíveis, mas ele consegue cobrir diversos casos de estudo e testes.

Rodando em Docker com uma imagem bem leve, o Floci usa a mesma porta (a 4566) e mesmo protocolos e chamadas AWS SDK que o LocalStack, o que facilita a curva de aprendizado.

Instalando e testando o Floci

Para instalar o Floci, vamos usar o padrão com um container Docker. Para isso, execute o comando abaixo:

# Rodar o container em segundo plano
docker run --rm -d -p 4566:4566 hectorvent/floci:latest

Depois, vamos configurar a AWS CLI com o export das credenciais fake:

export AWS_ENDPOINT=http://localhost:4566
export AWS_DEFAULT_REGION=us-east-1
export AWS_ACCESS_KEY_ID=test
export AWS_SECRET_ACCESS_KEY=test

Por fim, fazer alguns testes criando um Bucket S3, subindo um arquivo .txt e listando os objetos do bucket:

# Criando um bucket S3
aws s3 mb s3://my-bucket --endpoint-url $AWS_ENDPOINT

# Subindo um arquivo .txt
echo "hello floci" | aws s3 cp - s3://my-bucket/hello.txt --endpoint-url $AWS_ENDPOINT

# Listando os objetos do bucket criado
aws s3 ls s3://my-bucket --endpoint-url $AWS_ENDPOINT

Resultado:

Imagem: Saída do terminal (CLI) exibindo o comando aws s3 ls mostrando o arquivo hello.txt dentro do bucket my-bucket, confirmando que o upload foi realizado com sucesso no Floci.

Ministack

O Ministack apareceu para mim após uma postagem do Thiago Augusto Ozores no LinkedIn, e já virou um dos meus favoritos.

Ele permite emular 33 serviços da AWS, e se diferencia por executar contêineres reais para serviços críticos, tais como RDS, ElastiCache, Docker via ECS e consultas SQL com DuckDB (Athena), em vez de apenas simular as chamadas de API.

O Ministack é leve e rápido, com uma imagem de cerca de 150MB. Assim como o Floci e o LocalStack, ele também usa a porta 4566, e isso facilita o uso porque basta apenas mudar o endpoint dos laboratórios e ambientes.

Instalando e testando o Ministack

Assim como fizemos com o Floci, vamos subir um container do Ministack com o comando:

# Rodar o container em segundo plano
docker run -d -p 4566:4566 nahuelnucera/ministack

Vamos criar um Bucket S3 de teste com o comando:

# Criando um bucket S3 no ministack
aws s3 mb s3://my-local-bucket \
--endpoint-url http://localhost:4566 \
--region us-east-1

Resultado:

Imagem: Saída do terminal (CLI) exibindo o comando aws s3 mb indicando “make_bucket: my-local-bucket”, confirmando que o bucket foi criado com sucesso no ambiente do Ministack.

kumo

Por último, mais não menos importante, temos o kumo, que conheci por uma postagem do Everton Marques (também no LinkedIn!).

Escrito em Go, ele suporta 71 serviços da AWS! O kumo oferece um conjunto enxuto de funcionalidades, incluindo: execução sem autenticação, suporte a Docker, baixo consumo de recursos e inicialização rápida.

Assim como os outros colegas, o kumo também utiliza a porta 4566. Então, basta apenas mudar o endpoint para utilizar nos seus projetos.

Sem mais delongas, vamos fazer um teste rápido do kumo também!

Instalando e testando o kumo

# Rodar o container em segundo plano
docker run -d -p 4566:4566 ghcr.io/sivchari/kumo:latest

E lá vamos nós para mais um teste de bucket S3 rsrs:

# Criando um bucket S3 no kumo
aws s3 mb s3://my-kumo-bucket \
--endpoint-url http://localhost:4566 \
--region us-east-1

Resultado:

Imagem: Saída do comando aws s3 mb, com o my-kumo-bucket criado

Imagem: Saída do terminal (CLI) exibindo o comando aws s3 mb indicando “make_bucket: my-kumo-bucket”, confirmando que o bucket foi criado com sucesso no Kumo.

Considerações finais

O fim da versão gratuita do LocalStack pode parecer um problema à primeira vista, mas hoje aprendemos que ele abriu espaço para novas ferramentas. Isso nos permite testar alternativas e repensar o fluxo de desenvolvimento local focado em AWS.

Mas me conta aí, você já testou alguma dessas opções? Usa outra alternativa? Ou ainda segue utilizando o LocalStack firme e forte?

Até mais e bons estudos!

Referências

AWS com LocalStack e Terraform

· 12 min para ler
Ludmila Silva
Cloud & DevOps Engineer

Uma das principais dores de quem está estudando Cloud AWS é não conseguir aplicar o conteúdo na prática. É fato que nem sempre podemos ter uma conta da AWS com um cartão de crédito disponível, ou mesmo ter recursos financeiros para subir uma infraestrutura com os serviços necessários. E a gente sabe que não há nada melhor do que aplicar o conteúdo, experimentar, "quebrar" as coisas e entender como tudo funciona. Porém, fica o dilema de não ter acesso ou de praticar correndo o risco de ter infelizes surpresas na fatura do cartão no fim do mês.

Para resolver esse problema, existe uma ferramenta muito legal e que tem sido muito útil nos meus labs, permitindo emular alguns dos principais serviços da AWS e interagir através da linha de comando (CLI), SDKs e IaC: o LocalStack.

O objetivo deste artigo é apresentar o LocalStack e como ele pode ser utilizado junto com o Terraform para ambientes de estudo mais próximos dos cenários reais, mas sem pesar no bolso.

Então, bora lá conhecer essa ferramenta sensacional?

O que é e como funciona o LocalStack?

O LocalStack é uma ferramenta gratuita que emula serviços da AWS de forma local, rodando em um container Docker. Isso permite interagir e testar serviços como EC2, S3, VPC, CloudWatch, SQS, Route 53, ACM, entre outros. Com ele, podemos criar ambientes de teste com a mesma estrutura (inclusive de código!) que faríamos caso estivéssemos usando a própria AWS.

Com ele, fazemos com que a API do LocalStack responda no lugar da API da AWS, permitindo realizar testes de Infraestrutura como Código (IaC), validar pipelines CI/CD, scripts de automação, etc. Não é massa?

Agora que já temos um overview sobre o LocalStack, vamos partir para a instalação.

Instalando o LocalStack

Para utilizar o LocalStack, você precisa ter instalado:

Para não deixar este artigo muito longo, optei por não detalhar a instalação dos pré-requisitos. Um ponto importante é que vamos usar a AWS CLI, e por isso precisamos configurar com as credenciais para o LocalStack.

Para isso, após instalar a AWS CLI, rode o comando aws configure e preencha com as seguintes informações:

  • AWS Access Key ID: test
  • AWS Secret Access Key: test
  • Default region name: us-east-1
  • Default output format: json

AWS configure - exemplo do comando preenchido com Key Id, secret acess key, default region e output format

Feito isso, vamos seguir com a instalação, porém, há um detalhe importante: a partir de março de 2026, o LocalStack vai deixar de manter uma versão Community realmente ativa e vai exigir autenticação (login/token) para usar a imagem principal (localstack/localstack:latest).

Portanto, antes de realmente instalar, é necessário:

  1. Criar uma conta usando e-mail ou autenticação via Google ou GitHub;

  2. Clicar no link de ativação, enviado por email

  3. Preencher os dados para iniciar uma versão de testes do Pro durante 15 dias (sem necessidade de cadastrar o cartão de crédito):

Tela de login do LocalStack para iniciar a versão trial - com campos para preencher o nome e botão "Start Trial"

Após preencher, seremos direcionados para as instruções de download, instalação e configuração do LocalStack:

Página com as instruções de instalação, configuração e deploy do Localstack

Nesse tutorial, vou seguir com o padrão Linux, então, copiei o link do binário e segui com os comandos:

## Baixando o binário

curl --output localstack-cli-4.13.1-linux-amd64-onefile.tar.gz \
--location https://github.com/localstack/localstack-cli/releases/download/v4.13.1/localstack-cli-4.13.1-linux-amd64-onefile.tar.gz

## Extrair o binário para /usr/local/bin
sudo tar xvzf localstack-cli-4.13.1-linux-*-onefile.tar.gz -C /usr/local/bin

## Validar a versão
localstack --version

## Configurar o token (está no passo 2 da página Getting Started)
localstack auth set-token `<use_seu_token_aqui>`

Com tudo ok, vamos dar um start no LocalStack com o comando:

## Rodar o LocalStack em segundo plano
localstack start -d

O comando acima vai iniciar uma instância do Localstack no localhost, utilizando a porta 4566, dessa forma aqui:

Exemplo do Localstack startado, com a informação de que está "running"

Para testar se tudo deu certo mesmo, vamos simular a criação de um Bucket S3:

## Setar LocalStack Endpoint URL:
export LOCALSTACK_ENDPOINT=http://localhost:4566

## Criar o Bucket
aws --endpoint-url=$LOCALSTACK_ENDPOINT s3 mb s3://meu-primeiro-bucket

## Listar o Bucket
aws --endpoint-url=$LOCALSTACK_ENDPOINT s3 ls

E veja ele aí, Bucker criado e listado:

Exemplo com a saída do comando para listar o Bucket, retornando o meu-primeiro-bucket como saída do comando

Acessando o dashboard

Além de verificar e interagir com os recursos via CLI, também podemos usar uma interface gráfica (GUI) que nos ajuda a ter uma percepção mais "real" do que estamos construindo.

Para acessar esse dashboard, vá para a mesma página em que criamos a conta e pegamos os dados do token, clique na aba lateral esquerda, em Instances... E voilá! Os recursos disponíveis estão todos aí:

Página principal do dashboard do LocalStack, com UI com mais de 20 serviços listados, desde serviços de App Integration (API Gateway, SQS, MQ, entre outros), Compute (EC2, Lambda, ECS, entre outros), Storage (S3, Backup, entre outros) e diversos outros serviços AWS.

Agora que fizemos e acontecemos no LocalStack, você acha que acabou? Segura aí, que ainda tem mais mão na massa: vamos subir um website estático usando o Terraform!

Criando a infra LocalStack com Terraform

Primeiro, é necessário ter o Terraform instalado. Então, vou deixar aqui a documentação do Terraform para seguirem com a instalação, conforme o seu sistema operacional. Após instalação, use o comando terraform --version para validar a versão instalada. Feito isso, indico criar um diretório a parte para começarmos com esse projeto.

Dentro do diretório, crie os arquivos index.html e error.html, que serão as páginas dos website. Caso você não tenha arquivos para subir, pode usar o conteúdo os arquivos a seguir:

index.html

`<!DOCTYPE html>`
`<html lang="pt-br">`
`<head>`
`<meta charset="UTF-8">`
`<title>`Site estático com Terraform + LocalStack`</title>`
`</head>`
`<body style="margin:0; font-family: Arial, Helvetica, sans-serif; background-color:#0f172a; color:#f1f5f9; display:flex; align-items:center; justify-content:center; height:100vh;">`

`<div style="text-align:center; background-color:#1e293b; padding:40px; border-radius:12px; box-shadow:0 10px 25px rgba(0,0,0,0.3); max-width:600px;">`
`<h1 style="color:#38bdf8; margin-bottom:20px;">`
Chegaaaa mais... Deploy realizado com sucesso!
`</h1>`

`<p style="font-size:18px; line-height:1.6;">`
Este site estático foi provisionado utilizando
`<strong>`Terraform`</strong>` para criar um bucket S3
e publicado localmente com `<strong>`LocalStack`</strong>`.
`</p>`

`<p style="margin-top:20px; font-size:16px; color:#94a3b8;">`
Infraestrutura como Código + Ambiente AWS Local =
desenvolvimento mais rápido, seguro e econômico. Show, né?
`</p>`

`<div style="margin-top:30px; padding:10px; background-color:#0ea5e9; border-radius:8px; font-weight:bold;">`
🌍 Ambiente: LocalStack (AWS Emulator)
`</div>`
`</div>`

`</body>`
`</html>`

error.html

`<!DOCTYPE html>`
`<html lang="pt-br">`
`<head>`
`<meta charset="utf-8">`
`<title>`404`</title>`
`</head>`
`<body style="margin:0; font-family: Arial, Helvetica, sans-serif; background: linear-gradient(135deg, #1e293b, #0f172a); color:#f1f5f9; display:flex; align-items:center; justify-content:center; height:100vh;">`

`<div style="text-align:center; background-color:#1e293b; padding:40px; border-radius:12px; box-shadow:0 10px 25px rgba(0,0,0,0.4); max-width:400px; width:90%;">`

`<h1 style="margin:0 0 20px 0; font-size:48px; color:#f86538;">`
Ops... Deu ruim!
`</h1>`

`<p style="font-size:18px; margin:0; color:#cbd5e1;">`
404. Algo de errado não está certo.
`</p>`

`</div>`

`</body>`
`</html>`

Em seguida, vamos criar um arquivo chamado providers.tf, com o seguinte conteúdo:

terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 5.0"
}
}
}

provider "aws" {
access_key = "test"
secret_key = "test"
region = "us-east-1"

s3_use_path_style = false
skip_credentials_validation = true
skip_metadata_api_check = true

endpoints {
s3 = "http://s3.localhost.localstack.cloud:4566"
iam = "http://localhost:4566"
sts = "http://localhost:4566"
}
}

Aqui, estamos informando ao Terraform qual versão do provider AWS que ele deve usar, setando a versão como 5.x.; e que ele deve se conectar com o LocalStack, e não para a AWS real. Setamos também credenciais fictícias para facilitar a conexão com o ambiente do simulador.

Em seguida, vamos criar as variáveis reutilizáveis que serão utilizadas no projeto, através do arquivo variables.tf, com o seguinte conteúdo:

variable "bucket_name" {
description = "Name of the s3 bucket"
type = string
default = "mywebsites3"
}

variable "tags" {
description = "Tags to set on the bucket"
type = map(string)
default = {}
}

Basicamente, definimos que podemos alterar tanto o nome do Bucket quanto as tags, tornando esse mini projeto mais organizado e flexível. No bucket_name, foi definido um parâmetro default para o nome do Bucket, apenas para facilitar o processo. O ideal

Agora, vamos criar um outro arquivo main.tf que vai ser responsável pela criação dos recursos, ou seja, do Bucket S3, das configurações de website estático, da policy e fazer o upload dos arquivos HTML.

## Criar o bucket
resource "aws_s3_bucket" "s3_bucket_tf" {
bucket = var.bucket_name
tags = merge(
var.tags, {
Name = "${var.bucket_name}-static-website"
}
)
}

## Configurar o bucket para hospedar um site estático
resource "aws_s3_bucket_website_configuration" "s3_static_website_config" {
bucket = aws_s3_bucket.s3_bucket_tf.id

index_document {
suffix = "index.html"
}

error_document {
key = "error.html"
}
}

## Bucket policy e ACL
resource "aws_s3_bucket_acl" "s3_bucket_acl" {
bucket = aws_s3_bucket.s3_bucket_tf.id
acl = "public-read"
}

resource "aws_s3_bucket_policy" "s3_bucket" {
bucket = aws_s3_bucket.s3_bucket_tf.id

policy = jsonencode({
Version = "2012-10-17"
Statement = [
{
Sid = "PublicReadGetObject"
Effect = "Allow"
Principal = "*"
Action = "s3:GetObject"
Resource = [
aws_s3_bucket.s3_bucket_tf.arn,
"${aws_s3_bucket.s3_bucket_tf.arn}/*",
]
},
]
})
}

## Upload dos arquivos para o bucket
resource "aws_s3_object" "object_www" {
depends_on = [aws_s3_bucket.s3_bucket_tf]
for_each = fileset("${path.root}", "*.html")
bucket = var.bucket_name
key = basename(each.value)
source = each.value
etag = filemd5("${each.value}")
content_type = "text/html"
acl = "public-read"
}

Sobre os blocos de recursos, o bloco aws_s3_object usa a função fileset para mapear os arquivos HTML que estiverem na pasta raiz do projeto. Por isso, lembre-se de mantê-los no mesmo diretório que os arquivos do Terraform. Além disso, o parâmetro etag garante que o Terraform detecte mudanças no conteúdo dos arquivos.

E por fim, vamos criar um arquivo chamado outputs.tf que vai conter informações de saída, tais como o ARN do Bucket e o endpoint do website.

output "arn" {
description = "ARN of the bucket"
value = aws_s3_bucket.s3_bucket_tf.arn
}

output "bucket_name" {
description = "Name (id) of the bucket"
value = aws_s3_bucket.s3_bucket_tf.id
}

output "website_endpoint" {
value = aws_s3_bucket_website_configuration.s3_static_website_config.website_endpoint
}

Agora, execute os comandos:

## Inicializar o projeto
terraform init

## Formatar os arquivos
terraform fmt

## Validar a sintaxe e configurações
terraform validate

## Mostar o plano de execução
terraform plan

## Aplicar as mudanças
terraform apply -- auto-approve

Após o apply, acesse o endpoint no navegador, usando esta URL: http://mywebsites3.s3-website.localhost.localstack.cloud:4566/

E olha ele aí!

Página principal com mensagem de sucesso. Fundo escuro, com título escrito "Chegaaaa mais... Deploy realizado com sucesso!"

Inclusive, com a página de erro também:

Página com erro 404. Fundo escuro, com título em vermelhor escrito "Ops.. Deu ruim!". Subtítulo em cor branca, escrito "404. Algo de errado não está certo."

Massa demais, não é? Para finalizar, vamos limpar o nosso ambiente, removendo os recursos usando o comando terraform destroy --auto-approve

Simples assim.

Extra: como usar o LocalStack for Students

Na versão free do LocalStack, há 30 serviços disponíveis para brincar à vontade. No entanto, a medida em que os estudos e projetos vão ficando cada vez mais complexos, isso pode não ser o bastante. A mão de subir um EKS chega até a arder...

Infelizmente, a questão financeira pode ser uma pequena barreira aqui, mas há uma luz no fim do túnel: o LocalStack for Students!

Caso você tenha uma conta do GitHub Student Developer Pack, você tem acesso a diversos recursos para além da licença free. Os recursos incluem: AWS Glue, EMR, Lake Formation, Amazon MQ, Cost Explorer, Elastic Beanstalk, ECS, EKS, entre outros. Tem muita coisa mesmo.!Além disso, você tem 1.000 créditos mensais em CI/CD para integrar e implantar continuamente desenvolvimentos locais.

Não é massa? Caso tenha alguma dúvida sobre como configurar o GitHub Student Developer Pack, escrevi aqui um artigo para auxiliar.

Palavras finais

Com este artigo, quis mostrar para vocês uma pequena parte do que é possível fazer com o LocalStack, aliado a outras ferramentas, tais como o Terraform.

Por motivos didáticos, resolvi não utilizar o tflocal e o awslocal, que são wrappers que automatizam apontamento dos endpoints para o ambiente local. Optei pela configuração manual para entendermos melhor como a comunicação entre as ferramentas funciona.

Espero que este pequeno guia ajude você a praticar Cloud sem medo e sem receio de custos inesperados.

Bons estudos e até a próxima!

Referências

Docker sem mistério: um guia para iniciar no mundo dos containers

· 13 min para ler
Ludmila Silva
Cloud & DevOps Engineer

Introdução

Se voltarmos alguns bons anos, quando queríamos rodar uma aplicação em uma máquina com um sistema operacional, era necessário realizar uma série de configurações no ambiente, instalar diversos componentes, além de ajustar o hardware para suportar a carga de trabalho.

Pouco depois, surgiu a virtualização, que adicionou uma camada de abstração e isolamento entre o sistema operacional e hardware, o que chamamos de hipervisor. Ela possibilitou um melhor aproveitamento do hardware e a execução de vários sistemas isolados em diferentes máquinas virtuais. Porém, ainda precisávamos instalar e configurar o ambiente, suas dependências e fazer demais ajustes. A portabilidade era um caso à parte, o que tornou muito comum a frase: "Na minha máquina funciona!".

A containerização veio como uma forma mais leve e prática de empacotar as aplicações junto com tudo aquilo que elas necessitam para rodar: bibliotecas, dependências e demais configurações. Isso facilitou não só a execução, mas também o versionamento e portabilidade das aplicações.

E se podemos falar de uma plataforma que "democratizou" a containerização, essa é o Docker. O querido esteve e ainda está presente desde o desenvolvimento local até pipelines de CI/CD e ambientes de produção - e iremos falar melhor sobre isso no decorrer deste artigo.

Então, para alinharmos: o objetivo aqui é trazer um overview sobre o Docker, focando apenas no básico para que você possa progredir no mundo dos containers, caso assim deseje.

Bora lá?

O que é o Docker e o que são containers

O Docker é uma plataforma open source que viabiliza o desenvolvimento, distribuição e execução de aplicações. Criado em 2013 e baseado no LXC (Linux
Containers), pela até então chamada dotCloud, o Docker buscava resolver uma das grandes dores de cabeça no desenvolvimento de aplicações.... Sim, o famoso: "na minha máquina funciona".

Isso acontece porque o Docker utiliza o conceito de containers, que garantem que os aplicativos e suas dependências sejam "empacotados". Ou seja, que eles possam funcionar de forma consistente em qualquer ambiente.

Falando sobre os famigerados containers, a palavra-chave aqui é: isolamento. Isto porque eles são uma forma de agrupar uma aplicação e suas dependências, utilizando o kernel do sistema operacional do host, ou seja, da máquina (virtual ou física) onde está rodando. Assim, eles possibilitam o isolamento lógico (de processos, rede, usuários, etc.) e o isolamento de recursos (CPU, RAM, I/O), garantindo que a aplicação funcione de forma consistente e segura.

From: docker.com

Toda essa mágica ocorre por causa de funcionalidades do kernel Linux, especificamente dos:

  • cgroups (Grupos de controle), que permitem o isolamento de recursos como CPU, memória, etc.;
  • e os Namespaces, que são responsáveis por fazer com que cada container possua seu próprio environment, ou seja, cada container terá a sua árvore de processos, pontos de montagens, isolamento de filesystem, network, usuários, e por ai vai.

Ah, e não podemos esquecer do Chroot, uma syscall do Linux que permite alterar o diretório raiz de um processo e seus filhos.

Embora o Docker seja a solução mais popular, ele não foi a primeira nem é a única forma de executar containers. Mas, sem dúvidas, foi a solução que mais se destacou e se consolidou como ferramenta de conteinerização.

Quando usar o Docker?

Há quem diga que "o Docker já era" ou que ele não faz mais sentido hoje em dia. Na verdade, temos um ponto a ser discutido aí: não é que o Docker tenha caído em desuso, mas sim que, quando começamos a trabalhar com muitos containers e a dividir as aplicações em diversos serviços menores (o que chamamos de arquitetura de microsserviços), o gerenciamento do ambiente pode se tornar extremamente caótico.

Em um ambiente de produção, apenas dividir tudo em microsserviços e rodar containers não é o bastante. Precisamos escalar de forma rápida, garantir a alta disponibilidade, monitorar recursos, entre outras tarefas. Fazer isso com 10 containers é moleza, mas imagine fazer o mesmo centenas ou milhares deles?

Para lidar com toda essa complexidade, existem as ferramentas de orquestração de containers, como o Kubernetes. Os orquestradores automatizam o ciclo de vida dos containers, cuidando de tarefas que seriam impossíveis de fazer "na mão" em larga escala.

Portanto, usar o Docker sozinho em cenários de produção não é mesmo o ideal. Porém, ele continua sendo uma excelente ferramenta a ser usada nos seus estudos, no processo de compreender o desenvolvimento e de realizar testes locais. Ele é a porta de entrada para o mundo dos containers.

Além disso, ele ainda está como pano de fundo por trás da mágica dos orquestradores, já que utilizam container runtimes (como o containerd, que veio do próprio Docker) para criar e executar os containers. No fim das contas, mesmo quando ele não aparece no palco principal, o padrão que o Docker criou é o que sustenta todo esse ecossistema.

💡

OBS: Não se engane! Sabemos que para grandes ambientes de produção o uso do Docker "puro" não é recomendável, maaaaas infelizmente ainda existem muitos negócios que o utilizam dessa forma. Então, pode ser que você se depare com um cenário sem um orquestrador e cheio de containers Docker para gerenciar.... Eu lhe desejo boa sorte! 👀

Agora que entendemos o que é e quando usar o Docker, vamos colocar a mão na massa!

Instalando o Docker

Por padrão, vamos considerar a instalação do Docker no Linux. Para o nosso exemplo, estou usando uma Vagrantbox com o Ubuntu Jammy 22.04 (LTS) e também meu Pop!_OS, mas você pode utilizar a distro que melhor lhe agradar ou que for mais acessível para o momento.

Para seguirmos, abra o terminal e rode o seguinte comando:

## Executar o script
curl -fsSL https://get.docker.com | bash

Não tem muito segredo aqui: estamos usando um script oficial para automatizar o processo de instalação do Docker Engine (daemon + CLI) e configurar os repositórios, pacotes e dependências.

A saída do script irá trazer a versão do Docker Engine instalado:

Agora, vamos facilitar a nossa vida e permitir executar os comandos do Docker sem a necessidade de usar o sudo toda hora, utilizando o modo rootless (outra forma comum seria adicionar o seu usuário ao grupo docker).

## Para rodar os comandos sem o sudo
dockerd-rootless-setuptool.sh install

########## BEGIN ##########
sudo sh -eux <<EOF
# Install newuidmap & newgidmap binaries
apt-get install -y uidmap
EOF
########## END ##########

Para testar se deu certo, você pode rodar os comandos:

## Ver a versão do Docker
docker version

## Rodar a imagem do hello-world
docker run hello-world

Perceba que, ao executar o docker run, o Docker vai baixar a imagem hello-world (pois não a temos localmente) e executar um container. Vamos falar sobre a execução de containers depois, mas a saída que você verá é mais ou menos esta:

Show, né? Para instalar o Docker no Windows ou Mac, você pode utilizar o Docker Desktop.

O que são imagens e como criar um Dockerfile

No Docker, as imagens são como moldes: uma abstração da infraestrutura em estado de leitura (read-only), a partir de onde será criado o container. Uma vez gerada a imagem, ela é imutável e não "roda" sozinha. Em resumo, ela apenas fornece as instruções a partir das quais um container é criado.

Já os containers são instâncias "vivas" de uma imagem. Eles podem ser criados, iniciados, parados, movidos ou excluídos. Em geral, um container nasce isolado dos demais containers e da máquina host. E ele só pode ser criado a partir de, e somente de, uma única imagem.

Para criarmos nossa primeira imagem, vamos utilizar um arquivo chamado Dockerfile e inserir nele o conteúdo abaixo:

### Imagem base
FROM ubuntu:22.04

## Executar comandos durante a criação da imagem
RUN apt-get update && apt-get install nginx -y

## Expor uma porta
EXPOSE 80

## Executar comandos quando o container for executado
CMD ["nginx", "-g", "daemon off;"]

Agora, vamos entender com calma cada etapa desse Dockerfile:

  • FROM - aqui nós informamos qual imagem usaremos como base (no nosso caso, é a Ubuntu 22.04). É o ponto de partida sobre o qual vamos construir nossa solução;
  • RUN - aqui nós informamos quais comandos serão executados no momento de criação (build) da imagem;
  • EXPOSE - serve para expor uma porta (a-ha!). Com ele, definimos qual porta o container vai "ouvir";
    • Aqui cabe uma ressalva: isso não abre a porta por si só, mas documenta e facilita quando rodarmos o container.
  • CMD - aqui informamos qual comando será executado por padrão quando o container iniciar a partir dessa imagem, ou seja, é o que vai rodar quando o container subir. Entendendo um pouquinho:
    • nginx - vai iniciar o Nginx server;
    • -g e daemon off - serve para impedir que o Nginx gere seus processos e depois os encerre. Dessa forma, ele vai rodar em primeiro plano e evitar que o container morra.

Salve o arquivo e bora seguir para os próximos passos.

Buildando a imagem e rodando o container

Agora é a hora de fazer a mágica e transformar esse Dockerfile em algo real. Para isso, usamos o comando de build:

## Buildar
docker image build -t meu-nginx:1.0 .

Onde:

  • docker image build: é a instrução básica para criar uma imagem;
  • -t meu-nginx:1.0: a flag -t se refere a tag, e serve para darmos um nome e uma versão para a imagem, que no caso vai ser meu-nginx:1.0. Caso não informemos a versão, o Docker vai colocar :latest como padrão;
  • .: o ponto no final indica o contexto de build, e aqui estamos informando ao Docker que o Dockerfile está no diretório atual.

Já temos uma imagem pronta, porém, ela ainda não está rodando. Precisamos executar a nossa imagem, ou seja, criar o container:

## Executar a imagem
docker run -d -p 8080:80 --name meu-nginx meu-nginx:1.0
  • docker run: comando que cria e executa um container a partir de uma imagem;
  • -d: essa flag permite que o container rode em segundo plano, liberando o terminal (chamado de modo detached);
  • -p 8080:80: mapeia portas no formato "porta_host:porta_container", permitindo que o que chegue na porta 8080 do host seja direcionado para a porta 80 do container;
  • --name meu-nginx: aqui definimos um nome ao container. Caso você não use, o Docker irá utilizar algum nome aleatório como focused_curie, nervous_hopper ou algo do tipo;
  • meu-nginx:1.0: aqui informamos qual imagem deve ser usada para subir o container.

Com o container em execução, vamos seguir para testar alguns comandos. Bora lá!

Comandos básicos

Já aprendemos a como criar, buildar e executar, vou deixar aqui os comandos básicos para usar no dia-a-dia. Considere-os como um mini kit de sobrevivência, então brinque à vontade com eles:

## Listar os containers em execução
docker container ls

## Listar os containers (incluindo os parados)
docker container ls -a

## Listar imagens
docker image ls

## Inspecionar um container
docker container inspect [ID ou nome do container]

## Ver os logs de um container
docker container logs [ID ou nome do container]

## Ver os logs em tempo real
docker container logs -f [ID ou nome do container]

## Iniciar um container parado
docker container start [ID ou nome do container]

## Parar um container
docker container stop [ID ou nome do container]

## Remover um container
docker container rm [ID ou nome do container]

Observação: para remover um container, ele precisa estar parado. Podemos até usar a flag -f, mas nunca é o ideal.

Acessando um Container

Com o seu kit de sobrevivência em mãos, eis o momento de acessar um container que está rodando. Para entender como funciona, vamos executar um container de forma interativa (com as flags -t para o terminal, e -i para interatividade):

## Criando um container de forma interativa
docker container run --name meu-ubuntu -ti ubuntu

O Docker irá fazer o pull da versão latest do Ubuntu, abrindo o terminal. Olha só que legal, estamos dentro do Ubuntu:

Para sair desse container, jamais use o comando exit ou Ctrl+D, pois isso irá matar o processo principal e encerrar o container.

Então, para sair de forma segura, use Ctrl + P + Q.

Usando o attach

Podemos nos conectar a um container em execução utilizando o comando docker container attach [ID ou nome do container]

Porém, cabe um adendo importante aqui: o attach conecta diretamente ao processo principal do container. Caso você use um Ctrl + C nesse container, ele vai interromper o processo principal e morrer.

Usando o exec

Com o exec podemos rodar um comando em um container em execução:

Isso possibilita também executar o bash como um novo processo com o docker container exec -it [ID ou nome] bash:

O exec tem uma vantagem bem interessante para este caso: se usarmos o exit ou Ctrl+D, o container continua rodando normalmente. Isto ocorre porque não encerramos o processo principal, sendo esse comando o mais indicado para alguns casos de troubleshooting e manutenção.

Publicando sua imagem no Docker Hub

Já criamos nossa imagem e testamos localmente, agora vamos disponibilizá-la em um repositório (registry) de imagens. Por quê? Bem, porque isso facilita a portabilidade da aplicação, permitindo também armazenar, versionar e compartilhar as imagens.

Existem várias opções de repositórios, tanto públicos quanto privados, mas utilizaremos o Docker Hub por ser o mais popular. Então, para seguirmos é necessário que você crie uma conta aqui.

Após criar sua conta, vamos fazer o login via terminal:

## Docker login
docker login -u nome_de_usuario

OBS: O comando vai pedir a senha, mas você pode usar também um token de acesso.

Em seguida, precisamos renomear a tag da imagem do Nginx que criamos anteriormente, acrescentando o seu nome de usuário, seguindo o padrão usuario/nome-da-imagem:versao):

## Renomear a imagem
docker image tag meu-nginx:1.0 nome_de_usuario/meu-nginx:1.0

Exemplo:

Por fim, vamos fazer o push para o Docker Hub:

## Fazer o push da imagem
docker push nome_de_usuario/meu-nginx:1.0

E voilá! Aqui está a minha querida no repositório e disponível publicamente:

Conclusão

Uau! Foi uma pequena jornada que passamos aqui com o Docker, hein? Mas tem muita coisa para aprender e, como o objetivo deste post era fazer uma introdução ao Docker, muita coisa ficou de fora: volumes, network, multi-stage build, docker compose e por aí vai.

Eu espero que este pequeno guia possa ajudar no seu aprendizado, mas é muito importante que você coloque a mão na massa para fixar melhor.

Por fim, deixo logo abaixo algumas recomendações para seguir seus estudos e se aprofundar no mundo dos containers.

Te vejo na próxima!

Recomendações de leituras e cursos