1. Conceitos Básicos

No Domain Mode, múltiplos servidores compartilham:

• Domain Controller (DC): centraliza configuração, deploys e monitoramento.
• Host Controller (HC): aplica a configuração do DC e gerencia servidores locais.
• Autenticação Elytron: garante que hosts se comuniquem de forma segura.

No lab, usamos:

ComponenteHost/ContainerFunçãoDomain Controllerdomain-controllerGerencia o domínioHost1host1Host gerenciadoHost2host2Host gerenciadoLoad Balancernginx-lbDistribui tráfego entre hosts

2. Estrutura do Lab

O lab utiliza Docker e Docker Compose para orquestrar os containers:

JbossDomain/
├─ domain-controller/
│  ├─ app/
│  │  └─ hello-world-war-1.0.0/
│  │     ├─ WEB-INF/
│  │     └─ index.jsp
│  ├─ config/
│  │  └─ host-master.xml
│  ├─ domain/
│  │  └─ configuration/
│  │     ├─ mgmt-users.properties
│  │     └─ mgmt-groups.properties
│  └─ Dockerfile
├─ host1/
│  └─ config/
│     └─ host1.xml
├─ host2/
│  └─ config/
│     └─ host2.xml
├─ nginx/
│  └─ nginx.conf
└─ docker-compose.yml

3. Dockerfile do Domain Controller

No domain-controller/Dockerfile, criamos os usuários necessários:

FROM quay.io/wildfly/wildfly:latest
USER root
# Admin do console (opcional)
RUN /opt/jboss/wildfly/bin/add-user.sh admin Admin#123 --silent
# User usado pelo Host Controller para conectar no Domain Controller
RUN /opt/jboss/wildfly/bin/add-user.sh jboss Jboss@123 --silent
USER jboss

⚠️ O usuário jboss será usado pelos Hosts para autenticação no Domain Controller.

4. Docker Compose: Configuração do Lab

O docker-compose.yml define todos os containers e redes:

services:
  domain-controller:
    build:
      context: ./domain-controller
    container_name: domain-controller
    command: >
      /opt/jboss/wildfly/bin/domain.sh
      --host-config=host-master.xml -b 0.0.0.0
      -bmanagement 0.0.0.0
    ports:
      - "9990:9990"
      - "9999:9999"
    environment:
      - NODE_NAME=domain-controller
    volumes:
      - ./domain-controller/config/host-master.xml:/opt/jboss/wildfly/domain/configuration/host-master.xml:ro
      - ./domain-controller/domain/configuration/mgmt-users.properties:/opt/jboss/wildfly/domain/configuration/mgmt-users.properties
      - ./domain-controller/domain/configuration/mgmt-groups.properties:/opt/jboss/wildfly/domain/configuration/mgmt-groups.properties
    networks:
      - wildfly-net

  host1:
    image: quay.io/wildfly/wildfly:latest
    container_name: host1
    command: >
      /opt/jboss/wildfly/bin/domain.sh
      --host-config=host1.xml
      -Djboss.domain.master.address=domain-controller
      -b 0.0.0.0
      -bmanagement 0.0.0.0
    volumes:
      - ./host1/config/host1.xml:/opt/jboss/wildfly/domain/configuration/host1.xml:ro
      - ./domain-controller/domain/configuration/mgmt-users.properties:/opt/jboss/wildfly/domain/configuration/mgmt-users.properties
      - ./domain-controller/domain/configuration/mgmt-groups.properties:/opt/jboss/wildfly/domain/configuration/mgmt-groups.properties
    environment:
      - NODE_NAME=host1
    depends_on:
      - domain-controller
    networks:
      - wildfly-net

  host2:
    image: quay.io/wildfly/wildfly:latest
    container_name: host2
    command: >
      /opt/jboss/wildfly/bin/domain.sh
      --host-config=host2.xml
      -Djboss.domain.master.address=domain-controller
      -b 0.0.0.0
      -bmanagement 0.0.0.0
    volumes:
      - ./host2/config/host2.xml:/opt/jboss/wildfly/domain/configuration/host2.xml:ro
    environment:
      - NODE_NAME=host2
    depends_on:
      - domain-controller
    networks:
      - wildfly-net

  nginx:
    image: nginx:alpine
    container_name: nginx-lb
    ports:
      - "80:80"
    volumes:
      - ./nginx/nginx.conf:/etc/nginx/nginx.conf:ro
    depends_on:
      - host1
      - host2
    networks:
      - wildfly-net

networks:
  wildfly-net:
    driver: bridge

5. Configuração do Domain Controller (host-master.xml)

O host-master.xml define:

• <local/> → este host é o Domain Controller
• Interfaces de management (9990 HTTP e 9999 Native)
• Usuário para autenticação dos hosts

Exemplo resumido:

<domain-controller>
    <local/>
</domain-controller>

<interfaces>
    <interface name="management">
        <inet-address value="0.0.0.0"/>
    </interface>
</interfaces>

<management>
    <management-interfaces>
        <http-interface http-authentication-factory="management-http-authentication">
            <socket interface="management" port="9990"/>
        </http-interface>
    </management-interfaces>
</management>

6. Configuração dos Hosts (host1.xml / host2.xml)

Cada host precisa de:

1. Nome único (<host name="host1">)
2. Informações do Domain Controller (<domain-controller><remote .../></domain-controller>)
3. Configuração Elytron para autenticação:

<subsystem xmlns="urn:wildfly:elytron:15.0">
    <authentication-client>
        <authentication-configuration name="hostAuthConfig"
                                      authentication-name="jboss"
                                      realm="ManagementRealm">
            <credential-reference clear-text="Jboss@123"/>
        </authentication-configuration>
        <authentication-context name="hcAuthContext">
            <match-rule authentication-configuration="hostAuthConfig"/>
        </authentication-context>
    </authentication-client>
</subsystem>

<domain-controller>
    <remote protocol="remote"
            host="domain-controller"
            port="9999"
            authentication-context="hcAuthContext"/>
</domain-controller>

7. Deploy de Aplicações

Após iniciar todos os containers:

docker-compose up -d

Acesse o Admin Console no browser:

http://localhost:9990

Deploy via CLI no Domain Controller:

/opt/jboss/wildfly/bin/jboss-cli.sh --connect
deploy /opt/jboss/wildfly/domain/deployments/app.war --server-groups=main-server-group

Teste nos hosts:

curl http://localhost/app/

Você verá a resposta indicando qual host respondeu:

Hello World!
Node: host1

8. Observabilidade

• Verifique status dos hosts e deploys:

/host=*/server=*/:read-attribute(name=status)

• Verifique boot errors:

/host=host1/server=server-one:read-boot-errors()

9. Próximos Passos

• Experimente failover entre hosts
• Adicione NGINX para load balancing (/app/)
• Automatize deploys com Ansible ou scripts CLI
• Explore autenticação Elytron avançada e SSL

💡 Resumo:
Com este laboratório, você aprende a configurar Domain Controller, Hosts Gerenciados, autenticação segura e deploy de aplicações centralizado no WildFly/JBoss Domain Mode usando Docker.

Mesmo com o avanço de Kubernetes e plataformas gerenciadas, ainda é muito comum encontrar aplicações Java rodando em WildFly/JBoss em modo standalone, com múltiplas instâncias atrás de um load balancer.

Para estudar esse cenário de forma prática, montei um laboratório local usando Docker Compose, simulando uma arquitetura clássica e bastante realista.

🎯 Objetivo

Criar um ambiente com:

• 3 instâncias WildFly standalone
• 1 NGINX atuando como Load Balancer
• Deploy de uma aplicação .war em todas as instâncias
• Acesso individual ao management console de cada nó
• Operação via JBoss CLI (deploy/undeploy) dentro dos containers

🧱 Arquitetura do laboratório

O fluxo fica assim:

Cliente -> http://localhost:8080/app/ -> NGINX -> wildfly1/wildfly2/wildfly3

Cada instância WildFly expõe duas portas:

• 8080 → aplicação
• 9990 → management console

No host, as portas foram mapeadas assim:

Instância | App | Management
 — — — — — — | — — | — — — — — 
wildfly1 | 8081 | 9991
wildfly2 | 8082 | 9992
wildfly3 | 8083 | 9993
nginx-lb | 8080 | -

Dentro da pasta do projeto:

docker compose up -d --build

Verificando os containers:

docker ps

🌍 Acessos

Aplicação via Load Balancer

http://localhost:8080/app/

Acesso direto a cada instância

• http://localhost:8081/app/
• http://localhost:8082/app/
• http://localhost:8083/app/

Management Console por instância

• http://localhost:9991/console
• http://localhost:9992/console
• http://localhost:9993/console

📦 Deploy e Undeploy via JBoss CLI (usando Docker)

Um dos pontos mais importantes do laboratório é operar o WildFly sem depender da UI, usando o CLI diretamente dentro do container.

1) Entrar no container

docker exec -it wildfly1 bash

2) Acessar o JBoss CLI

/opt/jboss/wildfly/bin/jboss-cli.sh --connect

3) Listar deployments

deployment-info

4) Undeploy

undeploy app.war

5) Deploy

Se o WAR estiver dentro do container:

deploy /opt/jboss/wildfly/standalone/deployments/app.war --force

🧪 O que esse laboratório simula na prática?

Esse lab reproduz muito bem ambientes tradicionais onde existem:

• múltiplas instâncias standalone
• reverse proxy / load balancer na frente
• deploys controlados por CLI
• operação por nó (management isolado)

É um cenário extremamente útil para aprender conceitos de:

• escalabilidade horizontal
• troubleshooting de proxy
• deploy e rollback
• arquitetura clássica Java EE

✅ Conclusão

Esse laboratório é simples, mas extremamente efetivo para estudar WildFly/JBoss em um cenário realista, com múltiplas instâncias e balanceamento via NGINX — tudo de forma reproduzível e portátil com Docker.

“Se você ainda copia e cola YAMLs, está na hora de repensar sua estratégia.”

📌 TL;DR

• Repetir manifestos Kubernetes é uma armadilha comum.
• Helm resolve isso com templates reutilizáveis.
• Aplicar o princípio DRY (Don’t Repeat Yourself) à infraestrutura traz ganhos de escala, clareza e automação.
• Menos erro humano, mais padronização e tempo ganho em deploys.

🧱 A dor da repetição: quando o YAML vira dívida técnica

Começa com um deployment.yaml. Depois um service.yaml. Em pouco tempo, dezenas de aplicações, cada uma com sua cópia dos mesmos arquivos. Só mudam alguns nomes.

E aí você se pergunta:

“Por que estou repetindo tanta coisa se só o nome do container muda?”

É o que chamo de síndrome do copy/paste no DevOps — e sim, ela tem cura.

💡 DRY: Don’t Repeat Yourself, especialmente na infraestrutura

O princípio DRY foi criado para o desenvolvimento de software, mas cabe perfeitamente na infraestrutura:

“Cada peça de conhecimento deve ter uma representação única, inequívoca e definitiva dentro do sistema.”

No Kubernetes, isso significa parar de repetir lógica em vários arquivos YAML. Centralize, templateze, padronize.

🎯 A resposta: Helm

Helm é o que falta quando você percebe que está repetindo tudo em cada aplicação.

Ele transforma seu amontoado de YAMLs em um pacote versionável e parametrizável, chamado Chart.

📦 Estrutura típica de um Helm Chart

my-app-chart/
├── Chart.yaml
├── values.yaml
└── templates/
    ├── deployment.yaml
    ├── service.yaml
    └── ingress.yaml

Você substitui duplicações com placeholders, como:

# templates/deployment.yaml
spec:
  replicas: {{ .Values.replicaCount }}
  containers:
    - image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"

E no values.yaml, define:

replicaCount: 3
image:
  repository: minha-imagem
  tag: "1.0.0"

✅ Pronto. Agora você só precisa mudar valores, não a estrutura inteira.

🔁 DRY em ação: menos esforço, mais escala

Vantagens reais do Helm:

• ✅ Reutilização total: um chart, vários apps
• ✅ Padronização: todos seguem o mesmo formato
• ✅ Segurança: menos erro humano
• ✅ Escalabilidade: times diferentes, mesmas boas práticas
• ✅ Rollback facilitado: helm rollback resolve

⚙️ Helm + CI/CD = Deploy de verdade

Integre o Helm à sua pipeline e simplifique o deploy com:

helm upgrade --install myapp ./my-chart -f values-prod.yaml

E se algo der ruim:

helm rollback myapp 1

Mais simples, mais seguro.

✅ Conclusão

Usar Helm é aplicar DRY na infraestrutura.
Você ganha agilidade, reduz erros e entrega com mais confiança. É o tipo de prática que eleva seu time de Kubernetes para um nível profissional.

💬 Curtiu o conteúdo?

Deixe um comentário contando se você já está usando Helm ou se ainda está no modo manual. Bora trocar ideia!

📲 Me encontra no LinkedIn também.

🎯 Por que Automatizar Impressões?

Se você já se viu precisando imprimir vários arquivos de uma só vez, sabe como o processo pode ser tedioso e repetitivo. Ter que abrir cada arquivo individualmente, selecionar a impressora e clicar em “Imprimir” consome um tempo valioso que poderia ser melhor aproveitado em outras tarefas.

A solução? Automatização com Powershell!

Este script permite:
✅ Imprimir arquivos PDF e TXT de um diretório específico;
✅ Selecionar uma impressora padrão ou específica;
✅ Imprimir um arquivo único, um intervalo de arquivos ou todos os arquivos disponíveis;
✅ Registrar os detalhes da execução em um arquivo de log;

🛠️ O Script em Powershell

A seguir, o código completo do script que desenvolvi. Ele foi estruturado para oferecer uma experiência clara e simples, com mensagens de erro amigáveis e registro detalhado no log.

# Diretório onde estão os arquivos para imprimir
$diretorio = "C:\Users\Pichau\Documents"

# Arquivo de log
$logFile = "C:\Users\Pichau\Documents\log_impressao.txt"

# Criar (ou sobrescrever) o arquivo de log
"===== INÍCIO DO LOG - $(Get-Date) =====" | Out-File -FilePath $logFile -Encoding UTF8

# ======================== ASCII DE BOAS-VINDAS ========================
Clear-Host
Write-Host @"
░██████╗██████╗░██╗░░░██╗  
██╔════╝██╔══██╗██║░░░██║  
╚█████╗░██████╔╝██║░░░██║  
░╚═══██╗██╔═══╝░██║░░░██║  
██████╔╝██║░░░░░╚██████╔╝  
╚═════╝░╚═╝░░░░░░╚═════╝░  

"@ -ForegroundColor Green

Write-Host ">>> Bem-vindo ao script de impressão automatizada!" -ForegroundColor Cyan
Write-Host ">>> Desenvolvido por Bruno Lucio da Silva" -ForegroundColor White
Write-Host ">>> GitHub: https://github.com/blcsilva" -ForegroundColor Yellow
Write-Host "===================================================" -ForegroundColor DarkGray

# ======================== SELECIONAR IMPRESSORA ========================
$impressoras = Get-Printer | Select-Object -ExpandProperty Name
$usarImpressoraPadrao = Read-Host "Usar impressora padrão? (S/N)"

if ($usarImpressoraPadrao -eq 'S' -or $usarImpressoraPadrao -eq 's') {
    $impressora = (Get-Printer | Where-Object { $_.Default -eq $true }).Name
} else {
    Write-Host "`n=== Impressoras Disponíveis ==="
    for ($i = 0; $i -lt $impressoras.Count; $i++) {
        Write-Host "$($i + 1) - $($impressoras[$i])"
    }

    $indice = [int](Read-Host "Digite o número da impressora desejada")
    $impressora = $impressoras[$indice - 1]
}

# ======================== OBTER ARQUIVOS ========================
$arquivos = Get-ChildItem -Path $diretorio | Where-Object { 
    $_.Extension -eq ".pdf" -or $_.Extension -eq ".txt"
} | Sort-Object Name

if ($arquivos.Count -eq 0) {
    Write-Host "`nNenhum arquivo encontrado para impressão."
    exit
}

Write-Host "`n=== Arquivos Disponíveis ==="
for ($i = 0; $i -lt $arquivos.Count; $i++) {
    Write-Host "$($i + 1) - $($arquivos[$i].Name)"
}

# ======================== SELECIONAR ARQUIVOS ========================
$selecao = Read-Host "Deseja imprimir: [T]udo, [I]ntervalo ou [U]m arquivo específico?"

if ($selecao -eq 'T') {
    $arquivosParaImprimir = $arquivos
} elseif ($selecao -eq 'I') {
    $inicio = [int](Read-Host "Informe o número inicial")
    $fim = [int](Read-Host "Informe o número final")
    $arquivosParaImprimir = $arquivos[($inicio - 1)..($fim - 1)]
} elseif ($selecao -eq 'U') {
    $indice = [int](Read-Host "Informe o número do arquivo desejado")
    $arquivosParaImprimir = @($arquivos[$indice - 1])
}

# ======================== IMPRIMIR ARQUIVOS ========================
foreach ($arquivo in $arquivosParaImprimir) {
    Write-Host "`n🖨️ Imprimindo: $($arquivo.FullName)"
    Start-Process -FilePath "print.exe" -ArgumentList "`"$($arquivo.FullName)`"" -NoNewWindow -Wait
}

Write-Host "`n✅ Impressão concluída!"

🖱️ Adicionando ao Menu de Contexto (Botão Direito)

Agora que o script está pronto, vamos adicionar a opção de “Imprimir” diretamente no menu de contexto (botão direito) do Windows.

🔥 Passo a Passo

1. Abra o Powershell como Administrador;
2. Execute o seguinte código para criar a entrada no menu de contexto:

# Definindo o caminho da chave de registro
$path = "Registry::HKEY_CLASSES_ROOT\*\shell\Print"
$commandPath = "$path\command"

# Cria a chave 'Print' e define o nome exibido no menu de contexto
New-Item -Path $path -Force | Out-Null
Set-ItemProperty -Path $path -Name "(Default)" -Value "Imprimir"

# Cria o comando associado à ação de impressão usando print.exe
New-Item -Path $commandPath -Force | Out-Null
Set-ItemProperty -Path $commandPath -Name "(Default)" -Value "C:\Windows\System32\print.exe /d:\\%PRINTER% \"%1\""

Write-Host "Opção 'Imprimir' adicionada ao menu de contexto com sucesso!" -ForegroundColor Green

1. Feche o Powershell.
2. Agora, ao clicar com o botão direito em um arquivo PDF ou TXT, você verá a opção “Imprimir” diretamente no menu de contexto!

✅ Por que essa abordagem funciona bem

💡 O script aproveita o suporte nativo do Windows ao PowerShell para manipulação de arquivos e impressoras;
💡 A integração com o menu de contexto simplifica o uso sem a necessidade de abrir o terminal;
💡 Os logs detalhados permitem fácil diagnóstico em caso de falha;
💡 A interface amigável e as opções de seleção tornam o processo prático para qualquer tipo de usuário.

🔥 Conclusão

Esse script é uma maneira eficiente de automatizar o processo de impressão em lote no Windows, economizando tempo e esforço. Com a integração ao menu de contexto, a tarefa fica ainda mais simples e rápida.

👉 O código completo está disponível no meu GitHub:
🔗 https://github.com/blcsilva

Se você gostou desse artigo, curta, comente e compartilhe! 🚀

#Powershell #Automação #Windows #DevOps #Produtividade #ImpressãoAutomática

Para este hands-on, vamos trabalhar com o provisionamento de uma VPC (Virtual Private Cloud) e uma instância EC2 na AWS como caso de uso.

✅ Pré-requisitos:

• Conta na AWS com permissões suficientes para criar recursos.
• Terraform instalado na máquina local.
• AWS CLI configurado com credenciais válidas.

🏗️ 1. Criando módulos reutilizáveis

Para manter o código organizado e reutilizável, vamos criar um módulo para provisionar uma VPC.

🗂️ Estrutura de pastas:

├── modules
│   └── vpc
│       ├── main.tf
│       ├── outputs.tf
│       └── variables.tf
├── environments
│   └── dev
│       ├── main.tf
│       └── terraform.tfvars
└── backend.tf

🔹 Arquivo modules/vpc/main.tf

Crie o módulo para provisionar uma VPC:

resource "aws_vpc" "main" {
  cidr_block = var.cidr_block

  tags = {
    Name = var.vpc_name
  }
}

🔹 Arquivo modules/vpc/variables.tf

Defina as variáveis esperadas:

variable "cidr_block" {
  type = string
}

variable "vpc_name" {
  type = string
}

🔹 Arquivo modules/vpc/outputs.tf

Defina as saídas para reutilizar os valores posteriormente:

output "vpc_id" {
  value = aws_vpc.main.id
}

🔹 Arquivo environments/dev/main.tf

Agora, utilize o módulo no código principal:

module "vpc" {
  source     = "../../modules/vpc"
  cidr_block = "10.0.0.0/16"
  vpc_name   = "dev-vpc"
}

✅ Resultado:

• O código agora está organizado e reutilizável.
• É possível replicar o mesmo módulo para diferentes ambientes, alterando apenas os valores das variáveis.

🌍 2. Separando ambientes por arquivos e estados diferentes

Para separar ambientes, vamos criar arquivos distintos para cada um e configurar o backend remoto (S3 + DynamoDB).

🔹 Arquivo backend.tf

Configure o backend remoto para armazenar o estado no S3:

terraform {
  backend "s3" {
    bucket         = "terraform-state-bucket"
    key            = "dev/terraform.tfstate"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "terraform-lock"
  }
}

⚠️ Dica: Crie o bucket S3 e a tabela DynamoDB manualmente antes de rodar o código:

aws s3 mb s3://terraform-state-bucket
aws dynamodb create-table --table-name terraform-lock \
  --attribute-definitions AttributeName=LockID,AttributeType=S \
  --key-schema AttributeName=LockID,KeyType=HASH \
  --billing-mode PAY_PER_REQUEST

✅ Resultado:

• Os estados serão armazenados de forma isolada para cada ambiente.
• Para criar ambientes diferentes, basta criar novos arquivos terraform.tfvars.

🔄 3. Executando terraform plan antes de apply

Agora, vamos validar as mudanças com terraform plan antes de aplicar:

terraform init
terraform plan -out=tfplan
terraform apply tfplan

✅ Resultado:

• terraform plan mostra as mudanças sem aplicá-las.
• terraform apply só será executado após validação manual.

🛡️ 4. Configurando controle de acesso e permissões

Para proteger os recursos, crie uma política de IAM que conceda apenas as permissões necessárias para o Terraform.

🔹 Exemplo de política IAM:

Crie um arquivo iam_policy.json:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:*",
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "*"
    }
  ]
}

Crie a política usando AWS CLI:

aws iam create-policy --policy-name TerraformPolicy --policy-document file://iam_policy.json

✅ Resultado:

• Apenas o Terraform terá acesso aos recursos provisionados.
• O princípio de menor privilégio será aplicado.

🏆 5. Gerenciando o estado com cuidado

Para proteger o estado:
✅ Habilite versionamento no bucket S3:

aws s3api put-bucket-versioning --bucket terraform-state-bucket --versioning-configuration Status=Enabled

✅ Bloqueie acesso não autorizado com política S3:

{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:*",
  "Resource": "arn:aws:s3:::terraform-state-bucket/*",
  "Condition": {
    "Bool": {
      "aws:SecureTransport": "false"
    }
  }
}

✅ Resultado:

• O estado estará protegido contra alterações acidentais.
• Versionamento permitirá rollback em caso de falha.

✅ 6. Automatizando deploy com CI/CD

Vamos criar um pipeline simples com GitHub Actions para automatizar o deploy:

🔹 Arquivo .github/workflows/terraform.yml:

name: Terraform Deploy

on:
  push:
    branches:
      - main

jobs:
  terraform:
    name: Terraform Plan and Apply
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Code
        uses: actions/checkout@v2

      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v2

      - name: Terraform Init
        run: terraform init

      - name: Terraform Plan
        run: terraform plan

      - name: Terraform Apply
        run: terraform apply -auto-approve

✅ Resultado:

• O código será provisionado automaticamente após o merge na branch main.
• Permite revisão manual antes de aplicar o deploy.

📊 7. Monitorando e auditando o ambiente

Para monitorar os recursos provisionados, configure o CloudWatch e o CloudTrail na AWS.

✅ CloudTrail:

aws cloudtrail create-trail --name terraform-trail --s3-bucket-name terraform-state-bucket

✅ CloudWatch:
Configure um alarme de exemplo:

aws cloudwatch put-metric-alarm \
  --alarm-name "CPU-High-Usage" \
  --metric-name "CPUUtilization" \
  --namespace "AWS/EC2" \
  --statistic "Average" \
  --period 300 \
  --threshold 80 \
  --comparison-operator "GreaterThanThreshold" \
  --dimensions Name=InstanceId,Value=i-1234567890abcdef0 \
  --evaluation-periods 2 \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:my-sns-topic

✅ Resultado:

• O CloudTrail audita alterações na infraestrutura.
• O CloudWatch alerta em tempo real sobre problemas.

🎯 Conclusão

Este hands-on cobriu as melhores práticas para deploy com Terraform, incluindo:
✅ Módulos reutilizáveis
✅ Separação de ambientes
✅ Automação com CI/CD
✅ Monitoramento contínuo

Agora você está pronto para implementar essas práticas em produção! 👊

Porém, para garantir que os deploys sejam seguros, previsíveis e eficientes, é essencial adotar estratégias bem definidas. Neste artigo, vou compartilhar as melhores práticas para realizar deploys com Terraform, cobrindo desde a organização do código até a automação e monitoramento.

🚀 1. Organize o código em módulos reutilizáveis

Manter o código organizado é fundamental para facilitar a manutenção e garantir escalabilidade. Os módulos no Terraform permitem que você defina componentes reutilizáveis, promovendo consistência e evitando repetição de código.

💡 Como aplicar:

✅ Crie um repositório separado para módulos reutilizáveis.
✅ Nomeie os módulos de forma clara e adote um padrão de versionamento.
✅ Use o princípio DRY (Don’t Repeat Yourself) para evitar código duplicado.

Exemplo de módulo:

module "vpc" {
  source = "./modules/vpc"
  cidr_block = "10.0.0.0/16"
}

Dividir o código em módulos facilita a escalabilidade e simplifica futuras mudanças na infraestrutura.

🌍 2. Separe ambientes por arquivos e estados diferentes

Misturar configurações de diferentes ambientes (como dev, staging e produção) no mesmo estado pode levar a erros catastróficos. Separar ambientes por arquivos e estados distintos ajuda a evitar esse problema e garante maior controle sobre os recursos provisionados.

💡 Como aplicar:

✅ Crie um diretório separado para cada ambiente.
✅ Use workspaces diferentes com o comando terraform workspace.
✅ Armazene os estados em um backend remoto (como S3 + DynamoDB).

Exemplo de estrutura de pastas:

├── environments
│   ├── dev
│   │   ├── main.tf
│   ├── staging
│   │   ├── main.tf
│   └── prod
│       ├── main.tf

Exemplo de configuração de backend remoto:

terraform {
  backend "s3" {
    bucket         = "meu-terraform-state"
    key            = "prod/terraform.tfstate"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "terraform-lock"
  }
}

Essa estratégia evita que alterações acidentais em um ambiente afetem outro.

🔄 3. Sempre execute terraform plan antes de apply

O comando terraform plan permite que você visualize exatamente quais mudanças serão aplicadas na infraestrutura antes de executá-las, reduzindo o risco de erros.

💡 Como aplicar:

✅ Use terraform plan em pipelines de CI/CD para validação automática.
✅ Defina aprovações manuais para ambientes críticos (como produção).
✅ Execute terraform apply apenas após revisar o plano de execução.

Exemplo:

terraform plan -out=tfplan
terraform apply tfplan

Essa abordagem garante que você só aplique mudanças após revisar e validar as modificações.

🛡️ 4. Controle de acesso e permissões

Gerenciar acesso de forma cuidadosa é essencial para evitar alterações não autorizadas e manter a segurança da infraestrutura.

💡 Como aplicar:

✅ Use IAM (ou equivalente) para definir permissões específicas por ambiente e recurso.
✅ Siga o princípio de menor privilégio (conceda apenas as permissões necessárias).
✅ Atribua diferentes níveis de acesso para ambientes de desenvolvimento e produção.

Exemplo de política IAM:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::meu-terraform-state/*"
    }
  ]
}

Restringir o acesso ao estado é essencial para proteger informações sensíveis.

🏆 5. Use o terraform state com cuidado

O arquivo de estado (terraform.tfstate) é o coração do Terraform. Ele contém detalhes sensíveis sobre a infraestrutura, então qualquer corrupção ou perda pode causar sérios problemas.

💡 Como aplicar:

✅ Armazene o estado em um backend remoto seguro (como S3).
✅ Configure controle de acesso rigoroso ao arquivo de estado.
✅ Habilite versionamento para permitir rollback em caso de falha.

Evite manipular o estado diretamente, a menos que seja absolutamente necessário.

✅ 6. Automatize o deploy com CI/CD

Automatizar o deploy com pipelines de CI/CD garante consistência, reduz erros humanos e acelera o tempo de entrega.

💡 Como aplicar:

✅ Configure pipelines para executar terraform plan e terraform apply automaticamente após um merge na branch principal.
✅ Use ferramentas como Jenkins, GitLab CI/CD ou GitHub Actions.
✅ Defina revisões manuais para ambientes críticos.

Exemplo de pipeline com GitHub Actions:

name: Terraform Deploy

on:
  push:
    branches:
      - main

jobs:
  terraform:
    name: Terraform Plan and Apply
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Code
        uses: actions/checkout@v2

      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v2

      - name: Terraform Init
        run: terraform init

      - name: Terraform Plan
        run: terraform plan

      - name: Terraform Apply
        run: terraform apply -auto-approve

Com pipelines bem configurados, o deploy se torna rápido e previsível.

📊 7. Monitore e audite o ambiente

Monitorar o ambiente em tempo real é essencial para garantir que o estado real da infraestrutura esteja sempre alinhado ao código do Terraform.

💡 Como aplicar:

✅ Configure o Prometheus e o Grafana para monitoramento em tempo real.
✅ Use o CloudTrail (AWS) para registrar todas as ações sobre a infraestrutura.
✅ Configure alertas automáticos para modificações não autorizadas ou falhas de deploy.

Essa prática ajuda a reagir rapidamente em caso de falha ou comportamento inesperado.

🔥 Resumo das melhores práticas

Estratégia Benefício Módulos reutilizáveis Código organizado e reutilizável Separação de ambientes Maior controle e isolamento Uso de terraform plan Maior segurança nas mudanças Controle de acesso Menor risco de alterações não autorizadas Gerenciamento de estado Evitar perda ou corrupção de dados Automação com CI/CD Deploys rápidos e consistentes Monitoramento e auditoria Resposta rápida a falhas

🎯 Conclusão

Seguir essas estratégias ao trabalhar com Terraform ajudará você a garantir uma infraestrutura escalável, segura e resiliente. Ao modularizar o código, separar ambientes, automatizar processos e monitorar continuamente, você terá um ciclo de deploy robusto, capaz de enfrentar os desafios dos ambientes modernos em nuvem.

Aplique essas práticas no seu fluxo de trabalho e eleve o nível dos seus deploys com Terraform! 👊

Kubernetes (ou K8s) é uma plataforma de orquestração de containers que permite automatizar a implantação, o dimensionamento e a administração de aplicativos em containers. Ele é amplamente utilizado em ambientes de produção devido à sua capacidade de gerenciar cargas de trabalho complexas e oferecer alta disponibilidade e escalabilidade.

Se você trabalha com DevOps ou está começando a explorar Kubernetes, dominar o kubectl é fundamental para gerenciar recursos e interagir com o cluster Kubernetes de maneira eficiente.

Este guia tem como objetivo apresentar os comandos kubectl mais importantes, explicando suas funções e oferecendo exemplos práticos de aplicação para ajudar você a gerenciar Pods, Deployments, Services, ConfigMaps, Secrets, Nodes, Namespaces e Volumes Persistentes (PV e PVC).

🔥 O que é Kubectl?

O kubectl é a ferramenta de linha de comando oficial para interagir com o Kubernetes. Ele permite que você gerencie recursos do cluster, consulte o status de aplicações, implante novas versões e automatize processos complexos com scripts e pipelines de CI/CD.

👉 Para verificar se o kubectl está instalado corretamente, use o comando:

kubectl version --client

👉 Para configurar o acesso a um cluster Kubernetes, utilize o arquivo kubeconfig:

kubectl config view

Se tudo estiver correto, você verá as informações de configuração do cluster. Agora, vamos explorar os principais comandos!

💠 1. Gerenciamento de Pods

Pods são a menor unidade de execução em Kubernetes. Um Pod contém um ou mais containers que compartilham armazenamento, rede e especificações de inicialização.

➡️ Criar um Pod a partir de um arquivo YAML

Exemplo de arquivo pod.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: meu-pod
spec:
  containers:
  - name: nginx
    image: nginx:latest
    ports:
    - containerPort: 80

👉 Para criar o Pod:

kubectl apply -f pod.yaml

➡️ Listar Pods em execução

kubectl get pods

➡️ Ver detalhes sobre um Pod específico

kubectl describe pod meu-pod

➡️ Ver logs de um Pod

kubectl logs meu-pod

➡️ Acessar um Pod e executar comandos diretamente

kubectl exec -it meu-pod -- bash

➡️ Excluir um Pod

kubectl delete pod meu-pod

💠 2. Gerenciamento de Deployments

Deployments permitem controlar a implantação e a atualização de aplicativos de forma declarativa, garantindo alta disponibilidade.

➡️ Exemplo de arquivo de Deployment

Exemplo de deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: meu-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

👉 Para criar o Deployment:

kubectl apply -f deployment.yaml

➡️ Ver status dos Deployments

kubectl get deployments

➡️ Detalhar um Deployment específico

kubectl describe deployment meu-deployment

➡️ Escalar réplicas de um Deployment

kubectl scale --replicas=5 deployment/meu-deployment

➡️ Verificar o status de rollout de um Deployment

kubectl rollout status deployment/meu-deployment

➡️ Excluir um Deployment

kubectl delete deployment meu-deployment

💠 3. Gerenciamento de Services

Services expõem aplicativos em execução para redes internas ou externas, permitindo que diferentes partes do sistema se comuniquem.

➡️ Exemplo de arquivo de Service

Exemplo de service.yaml:

apiVersion: v1
kind: Service
metadata:
  name: meu-service
spec:
  selector:
    app: nginx
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80

👉 Para criar um Service:

kubectl apply -f service.yaml

➡️ Verificar os Services ativos

kubectl get services

➡️ Ver detalhes de um Service específico

kubectl describe service meu-service

➡️ Excluir um Service

kubectl delete service meu-service

💠 4. ConfigMaps

ConfigMaps armazenam dados de configuração em formato texto para serem utilizados nos Pods.

👉 Criar um ConfigMap diretamente:

kubectl create configmap meu-configmap --from-literal=MEU_VALOR=1234

👉 Listar ConfigMaps:

kubectl get configmaps

👉 Exibir detalhes de um ConfigMap:

kubectl describe configmap meu-configmap

👉 Remover um ConfigMap:

kubectl delete configmap meu-configmap

💠 5. Secrets

Secrets armazenam informações sensíveis como senhas e chaves de API.

👉 Criar um Secret diretamente:

kubectl create secret generic meu-secret --from-literal=password=1234

👉 Listar Secrets:

kubectl get secrets

👉 Exibir detalhes de um Secret:

kubectl describe secret meu-secret

👉 Remover um Secret:

kubectl delete secret meu-secret

💠 6. Nodes

Nodes são os servidores físicos ou virtuais que executam os Pods.

👉 Listar Nodes:

kubectl get nodes

👉 Ver detalhes de um Node:

kubectl describe node meu-node

💠 7. Namespaces

Namespaces permitem a separação de ambientes e recursos dentro de um cluster Kubernetes.

👉 Criar um Namespace:

kubectl create namespace meu-namespace

👉 Listar Namespaces:

kubectl get namespaces

👉 Remover um Namespace:

kubectl delete namespace meu-namespace

💠 8. Persistent Volumes (PVs) e Persistent Volume Claims (PVCs)

PVs e PVCs armazenam dados persistentes para contêineres.

👉 Listar PVs e PVCs:

kubectl get pv
kubectl get pvc

👉 Exibir detalhes de um PV ou PVC:

kubectl describe pv meu-pv
kubectl describe pvc meu-pvc

👉 Remover um PV ou PVC:

kubectl delete pv meu-pv
kubectl delete pvc meu-pvc

✅ Conclusão

Dominar o kubectl é essencial para qualquer profissional DevOps que trabalha com Kubernetes. Este guia fornece um resumo detalhado dos principais comandos para administrar com eficiência os componentes essenciais de um cluster Kubernetes. 🚀

💬 Gostou do conteúdo? Deixe seu comentário e compartilhe com sua rede! 😎🔥

Desafios e Solução

Imagine um ambiente onde cada licença de usuário corresponde a um pod individual, e o número de licenças pode chegar a 700 simultaneamente. Para atender a esse cenário, precisamos:

✔ Isolamento de sessão e segurança — Cada acesso deve ser único e protegido.
✔ Escalabilidade — O cluster precisa suportar até 700 pods sem desperdício de recursos.
✔ Otimização de custos — Utilizando MLOps para prever picos de acesso e alocar recursos dinamicamente.

Como o Istio Resolve Esse Problema

O Istio permite implementar autenticação, autorização e roteamento inteligente para garantir segurança e eficiência. Com ele, podemos:

🔹 Configurar políticas de autenticação com JWT para validar usuários.
🔹 Definir Authorization Policies para isolar tenants e impedir acesso indevido.
🔹 Gerenciar tráfego com VirtualServices, garantindo que cada tenant tenha uma rota dedicada.

MLOps e Autoescalonamento

Além do Istio, usamos MLOps para prever picos de demanda e escalar os pods de forma automática. Com Kubeflow e KServe, podemos treinar modelos de machine learning para analisar padrões de acesso e ajustar os recursos dinamicamente.

Ferramentas Utilizadas

✅ Istio — Controle de tráfego, segurança e multitenancy.
✅ Kubernetes HPA — Autoescalonamento com base na demanda de CPU.
✅ Kubeflow — Machine learning para prever picos de carga.
✅ Prometheus & Grafana — Monitoramento e análise de métricas.

Conclusão

Com essa solução, garantimos segurança, escalabilidade e eficiência para aplicações Kubernetes que exigem multitenancy. O Istio protege cada sessão de usuário, enquanto MLOps reduz custos ajustando os recursos automaticamente.

Quer entender o passo a passo dessa implementação? Confira o hands-on completo abaixo!

Hands-on: Implementando uma Solução com Istio para Multitenancy e Autoescalonamento MLOps

1. Introdução

Este guia aborda a implementação de uma solução utilizando Istio para garantir acesso único e protegido em um cluster Kubernetes, suportando até 700 pods (um por licença). Além disso, serão exploradas práticas de MLOps para otimizar a alocação de recursos e reduzir custos.

2. Arquitetura da Solução

2.1 Configuração do Cluster Kubernetes

• Crie um cluster Kubernetes com suporte a autoescalonamento.
• Utilize ferramentas como kubectl e istioctl para gerenciar os recursos.
• Defina ResourceQuota e LimitRange para controlar o consumo de CPU e memória.

2.2 Implementação do Istio

• Instale o Istio no cluster:
• istioctl install --set profile=demo -y
• Habilite o sidecar para todos os pods:
• kubectl label namespace default istio-injection=enabled

2.3 Autenticação e Autorização

• Configure Istio Authentication Policy para autenticação JWT:
• apiVersion: security.istio.io/v1beta1 kind: RequestAuthentication metadata: name: jwt-auth namespace: default spec: selector: matchLabels: app: my-app jwtRules: - issuer: "https://auth.mycompany.com" jwksUri: "https://auth.mycompany.com/.well-known/jwks.json"
• Defina políticas de AuthorizationPolicy para multitenancy:
• apiVersion: security.istio.io/v1beta1 kind: AuthorizationPolicy metadata: name: tenant-access namespace: default spec: rules: - from: - source: requestPrincipals: ["tenantA", "tenantB"]

2.4 Gerenciamento de Tráfego

• Utilize o Istio Gateway para controlar o tráfego externo:
• apiVersion: networking.istio.io/v1beta1 kind: Gateway metadata: name: my-gateway spec: selector: istio: ingressgateway servers: - port: number: 443 name: https protocol: HTTPS tls: mode: SIMPLE credentialName: my-cert hosts: - "*.mycompany.com"
• Configure VirtualService para direcionar o tráfego baseado no tenant:
• apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: tenant-routing spec: hosts: - "*.mycompany.com" http: - match: - headers: tenant: exact: "tenantA" route: - destination: host: tenant-a-service port: number: 80

3. Uso de MLOps para Otimização de Recursos

3.1 Provisionamento Automático com Autoescalonamento

• Configure o HPA para escalar os pods com base na demanda:
• apiVersion: autoscaling/v2beta2 kind: HorizontalPodAutoscaler metadata: name: my-app-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: my-app minReplicas: 1 maxReplicas: 700 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70

3.2 Uso de Machine Learning para Predição de Picos

• Utilize o Kubeflow para treinar modelos que prevejam a demanda e ajustem os recursos automaticamente.
• Integre um modelo de machine learning para prever carga de trabalho e ajustar o número de pods com KServe.

3.3 Monitoramento e Observabilidade

• Utilize Prometheus e Grafana para visualizar métricas de uso e comportamento do cluster.
• Configure Kiali para visualizar o tráfego do Istio e depurar possíveis problemas.

4. Ferramentas Utilizadas

• Istio: Gerenciamento de tráfego, segurança e observabilidade.
• Kubeflow: Gerenciamento do ciclo de vida dos modelos de machine learning.
• Prometheus e Grafana: Monitoramento e visualização de métricas.
• Kubernetes: Orquestração de contêineres e autoescalonamento.

5. Conclusão

Essa solução garante que cada pod tenha um acesso único e protegido, suportando até 700 pods. O uso de Istio proporciona segurança e isolamento necessários para multitenancy, enquanto práticas de MLOps ajudam a otimizar o uso de recursos, reduzindo custos de infraestrutura.

É nesse cenário que surge o Service Mesh, uma camada de infraestrutura que gerencia a comunicação entre os serviços de forma transparente, trazendo benefícios como:

Principais Benefícios do Service Mesh

1. Observabilidade

Com o Service Mesh, é possível obter métricas detalhadas, logs estruturados e tracing distribuído da comunicação entre microserviços. Ferramentas como Jaeger e Prometheus podem ser integradas para um monitoramento mais eficiente.

2. Segurança

O uso de TLS mútuo (mTLS) garante que toda a comunicação entre serviços seja criptografada, aumentando a segurança e protegendo contra ataques man-in-the-middle. Além disso, políticas de autenticação e autorização são facilmente gerenciadas.

3. Controle de Tráfego

Com funcionalidades como balanceamento de carga, circuit breakers e retries automáticos, o Service Mesh melhora a confiabilidade dos microserviços e permite estratégias avançadas como deploys canários e blue/green deployments.

4. Gestão Simplificada

O Service Mesh abstrai a complexidade da comunicação entre serviços, permitindo que os desenvolvedores foquem na lógica de negócio em vez de lidar com desafios de infraestrutura.

Principais Ferramentas de Service Mesh

Várias ferramentas implementam Service Mesh, sendo as mais conhecidas:

• Istio: Uma das soluções mais robustas e amplamente adotadas, integrando segurança, observabilidade e controle de tráfego.
• Linkerd: Leve e focado na simplicidade, sendo ideal para equipes que querem uma solução mais fácil de configurar.
• Consul: Desenvolvido pela HashiCorp, combina Service Mesh com descoberta de serviços e configuração distribuída.
• AWS App Mesh: Solução nativa da AWS que integra bem com o ecossistema da AWS.

Hands-on: Implementando Istio com um Microserviço

Agora, vamos colocar a teoria em prática e configurar o Istio em um cluster Kubernetes, além de criar um microserviço que fará uso dos recursos do Service Mesh.

1. Pré-requisitos

Antes de começar, certifique-se de ter:

• Um cluster Kubernetes (Minikube, Kind ou AKS/EKS/GKE)
• kubectl instalado
• Istio CLI instalado

2. Instalando o Istio

Primeiro, baixe e instale o Istio:

curl -L https://istio.io/downloadIstio | sh -
cd istio-*/
export PATH=$PWD/bin:$PATH

Agora, instale o Istio no cluster Kubernetes:

istioctl install --set profile=demo -y
kubectl label namespace default istio-injection=enabled

Isso ativa a injeção automática de sidecar no namespace default.

3. Criando um Microserviço

Vamos criar um simples serviço em Python para testar o Istio:

app.py

from flask import Flask

app = Flask(__name__)

@app.route('/hello')
def hello():
    return 'Hello from Service Mesh!'

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=5000)

Criamos um Dockerfile para empacotar a aplicação:

FROM python:3.9
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
CMD ["python", "app.py"]

Crie um arquivo requirements.txt:

flask

Construa e publique a imagem:

docker build -t <seu_usuario>/service-mesh-app .
docker push <seu_usuario>/service-mesh-app

4. Implantando no Kubernetes

Criamos o manifesto de deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: service-mesh-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: service-mesh-app
  template:
    metadata:
      labels:
        app: service-mesh-app
    spec:
      containers:
      - name: service-mesh-app
        image: <seu_usuario>/service-mesh-app
        ports:
        - containerPort: 5000

E o serviço para expô-lo:

apiVersion: v1
kind: Service
metadata:
  name: service-mesh-app
spec:
  selector:
    app: service-mesh-app
  ports:
  - protocol: TCP
    port: 80
    targetPort: 5000

Aplique os recursos:

kubectl apply -f deployment.yaml
kubectl apply -f service.yaml

5. Testando a Integração com Istio

Agora vamos criar um Gateway para expor o serviço via Istio:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: service-mesh-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"

Criamos um VirtualService:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: service-mesh-app
spec:
  hosts:
  - "*"
  gateways:
  - service-mesh-gateway
  http:
  - match:
    - uri:
        prefix: "/hello"
    route:
    - destination:
        host: service-mesh-app
        port:
          number: 80

Aplique os manifests:

kubectl apply -f gateway.yaml
kubectl apply -f virtualservice.yaml

Agora, descubra o IP do Istio Gateway:

kubectl get svc istio-ingressgateway -n istio-system

E teste a API:

curl http://<EXTERNAL-IP>/hello

Conclusão

O Service Mesh com Istio simplifica a observabilidade, segurança e controle de tráfego em arquiteturas de microserviços. Com essa implementação, conseguimos demonstrar como criar um microserviço em Python, expô-lo via Istio e monitorá-lo.

Se você quer levar sua infraestrutura para um novo nível de resiliência e gestão, vale a pena considerar o uso de Service Mesh no seu ambiente!

Nos dias atuais, a automação da infraestrutura na nuvem é uma prática essencial para garantir agilidade, consistência e escalabilidade. Se você está interessado em aprender como automatizar a criação e o gerenciamento de recursos na AWS utilizando Terraform, Slack, Kubernetes, além de integrar com Argo CD e GitHub Actions para controle de versão, este tutorial é para você!

Neste artigo, mostro como orquestrar um fluxo completo de infraestrutura com EC2, Load Balancer, Grupos de Segurança, Certificados SSL, Subnets e Domínios. Tudo isso é configurado de maneira interativa, permitindo a personalização de cada componente através do Slack. E o melhor: toda a infraestrutura é gerenciada em tempo real com integração ao Argo CD ou GitHub Actions.

Através desse processo, podemos garantir que todas as mudanças na infraestrutura sejam controladas e versionadas, promovendo um ciclo contínuo de integração e entrega (CI/CD) para nossas configurações de infraestrutura, além de garantir uma gestão mais eficiente e segura.

Principais pontos abordados:

• Terraform para definir e provisionar recursos na AWS.
• Integração com Slack para coletar entradas interativas (como subnets, tipo de instância e domínio).
• Argo CD ou GitHub Actions para controle de versão e automação de deploy contínuo.
• Implementação de recursos como EC2, Load Balancer, Grupos de Segurança e SSL.
• Como vincular todos esses componentes, criando uma infraestrutura AWS completamente integrada.

Se você quer aprimorar suas habilidades de DevOps e se aprofundar nas práticas de automação em nuvem, este tutorial é uma excelente oportunidade para colocar em prática conceitos importantes que facilitarão sua jornada na AWS!

Leia o artigo completo e experimente por conta própria!

Hands-On: Automação de Infraestrutura AWS com Terraform, Slack, Kubernetes, Argo CD e GitHub Actions — Controle de Versão de Infraestrutura

Este tutorial amplia a infraestrutura AWS automatizada com Terraform, Slack, EC2, Load Balancer, Grupo de Segurança, Certificado SSL e Registro de Domínio, adicionando a integração com ferramentas de controle de versão de infraestrutura como Argo CD e GitHub Actions. Você verá como essas ferramentas podem ser usadas para garantir que sua infraestrutura esteja versionada e gerenciável através de práticas de CI/CD.

Objetivo

1. Criar uma infraestrutura AWS integrada com Terraform e Slack.
2. Implementar Argo CD ou GitHub Actions para o controle de versão da infraestrutura, proporcionando práticas de CI/CD para gerenciar mudanças de forma contínua.
3. Garantir que a infraestrutura gerenciada seja automática e facilmente replicável com versionamento adequado.

Pré-Requisitos

• Conta na AWS com permissões adequadas.
• AWS CLI configurada.
• Terraform instalado.
• Slack com integração de bots.
• Argo CD ou GitHub Actions configurados.
• AWS ACM para gerenciamento de certificados SSL.

Passo 1: Configuração Básica da Infraestrutura com Terraform

1.1. Definir o Provedor da AWS

Em nosso arquivo main.tf, começamos configurando o provedor AWS, especificando a região.

provider "aws" {
  region = "us-east-1"  # Região pode ser interativa ou definida via Slack
}

1.2. Registro de Domínio e Configuração de DNS

A configuração do domínio e DNS com Route 53 será automatizada.

resource "aws_route53_zone" "example" {
  name = var.domain_name  # Valor obtido interativamente pelo Slack
}

resource "aws_route53_record" "www" {
  zone_id = aws_route53_zone.example.zone_id
  name    = "www"
  type    = "A"
  ttl     = 300
  records = [aws_lb.example.dns_name]
}

1.3. Certificado SSL (ACM)

O certificado SSL será gerado com base na entrada do Slack.

resource "aws_acm_certificate" "example" {
  domain_name       = var.domain_name
  validation_method = "DNS"
  
  validation_option {
    domain_name               = var.domain_name
    validation_record_fqdns   = [aws_route53_record.certificate_validation.fqdn]
  }
}

1.4. Instância EC2

A configuração do EC2 irá permitir que o usuário forneça informações sobre tipo de instância, AMI, key pair, e subnet via Slack.

resource "aws_instance" "example" {
  ami           = var.ami_id  # Obtido do Slack
  instance_type = var.instance_type  # Obtido do Slack
  key_name      = var.key_name  # Obtido do Slack
  subnet_id     = var.subnet_id  # Obtido do Slack

  security_group = aws_security_group.example_sg.id

  tags = {
    Name = "EC2 Example"
  }
}

1.5. Load Balancer

A configuração do Load Balancer também será interativa, solicitando subnets e grupo de segurança.

resource "aws_lb" "example" {
  name               = "example-lb"
  internal           = false
  load_balancer_type = "application"
  security_groups    = [aws_security_group.example_sg.id]
  subnets            = var.subnets  # Obtido interativamente pelo Slack

  enable_deletion_protection = false
  idle_timeout              = 60
}

resource "aws_lb_listener" "https" {
  load_balancer_arn = aws_lb.example.arn
  port              = 443
  protocol          = "HTTPS"
  ssl_policy        = "ELBSecurityPolicy-2016-08"

  certificate {
    certificate_arn = aws_acm_certificate.example.arn
  }

  default_action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.example.arn
  }
}

1.6. Grupo de Segurança

O grupo de segurança será configurado para permitir o tráfego HTTPS para as instâncias EC2.

resource "aws_security_group" "example_sg" {
  name        = "example_sg"
  description = "Security group for EC2 and Load Balancer"

  ingress {
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  # Permitir tráfego de Load Balancer para o EC2
  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

Passo 2: Integração com Slack para Coleta de Dados Interativos

Utilizando o Slack como interface, o bot coleta dados para gerar a infraestrutura de forma interativa, perguntando sobre o domínio, subnets, AMI, tipo de instância, etc.

Passo 3: Integração com Argo CD para Controle de Versão da Infraestrutura

3.1. O que é o Argo CD?

Argo CD é uma ferramenta de entrega contínua (CD) baseada em Kubernetes que facilita a gestão de aplicações Kubernetes. Usando Argo CD, podemos versionar a infraestrutura Terraform em um repositório Git e implantar essas mudanças automaticamente.

3.2. Criando o Repositório Git para o Terraform

Crie um repositório Git onde todos os arquivos de configuração do Terraform serão armazenados. Este repositório será usado para controle de versão e integração contínua com o Argo CD.

• Passo 1: Crie um repositório no GitHub ou GitLab.
• Passo 2: Adicione os arquivos main.tf, variables.tf e outputs.tf ao repositório.
• Passo 3: No Argo CD, adicione o repositório Git para que ele possa acessar e sincronizar a infraestrutura.

3.3. Configurando o Argo CD

1. Instale o Argo CD em seu cluster Kubernetes.
2. No painel do Argo CD, adicione seu repositório Git, que contém as configurações do Terraform.
3. Crie uma aplicação no Argo CD para monitorar as alterações no repositório Git.
4. Toda vez que o código no repositório Git for alterado (como mudanças em main.tf), o Argo CD automaticamente aplicará essas mudanças.

3.4. Sincronizando as Configurações do Terraform com Argo CD

No painel do Argo CD, crie uma nova aplicação com as seguintes configurações:

• Source: Repositório Git contendo os arquivos do Terraform.
• Destination: Cluster Kubernetes onde as configurações serão aplicadas.
• Path: O diretório dentro do repositório Git onde o Terraform está localizado.

Ao sincronizar o Argo CD, as mudanças serão aplicadas automaticamente ao seu ambiente AWS, conforme definido nas configurações do Terraform.

Passo 4: Integração com GitHub Actions para CI/CD

4.1. O que são GitHub Actions?

GitHub Actions é uma plataforma para automação de workflows de CI/CD diretamente no GitHub. Podemos usá-lo para automatizar a execução do Terraform sempre que houver uma alteração no repositório.

4.2. Configuração do GitHub Actions

Crie um arquivo de workflow no diretório .github/workflows/terraform.yml dentro do seu repositório Git.

name: Terraform CI/CD

on:
  push:
    branches:
      - main  # Ou a branch desejada

jobs:
  terraform:
    runs-on: ubuntu-latest

    steps:
    - name: Checkout repository
      uses: actions/checkout@v2

    - name: Set up AWS credentials
      uses: aws-actions/configure-aws-credentials@v1
      with:
        aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
        aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        aws-region: us-east-1

    - name: Install Terraform
      run: |
        curl -LO https://github.com/hashicorp/terraform/releases/download/v1.0.0/terraform_1.0.0_linux_amd64.zip
        unzip terraform_1.0.0_linux_amd64.zip
        sudo mv terraform /usr/local/bin/

    - name: Terraform Init
      run: terraform init

    - name: Terraform Plan
      run: terraform plan

    - name: Terraform Apply
      run: terraform apply -auto-approve

4.3. Configurando Secrets no GitHub

Para usar o GitHub Actions com AWS, você precisará configurar suas credenciais AWS como secrets no GitHub:

1. Vá até o repositório GitHub e clique em Settings.
2. Na seção Secrets, adicione suas credenciais AWS (AWS_ACCESS_KEY_ID e AWS_SECRET_ACCESS_KEY).

4.4. Automatizando o Deploy com GitHub Actions

Sempre que um push for feito para a branch main, o workflow do GitHub Actions será acionado. Isso executará os comandos terraform init, terraform plan e terraform apply, gerenciando sua infraestrutura automaticamente na AWS.

Conclusão

Neste tutorial, você aprendeu a integrar ferramentas de automação de infraestrutura como Terraform, Slack, Argo CD e GitHub Actions para criar uma infraestrutura na AWS com controle de versão contínuo. Agora você pode gerenciar sua infraestrutura de forma interativa via Slack e automatizada com práticas de CI/CD, seja utilizando Argo CD para integração contínua em Kubernetes ou GitHub Actions para automação de workflows diretamente no GitHub.

Essas ferramentas combinadas oferecem um processo robusto de gerenciamento, versionamento e implantação de infraestrutura em nuvem.