DEV Community: Stefano Martins

Configurando o Terraform para funcionar corretamente com o LocalStack

Stefano Martins — Tue, 20 Aug 2024 12:22:02 +0000

Nos últimos anos o LocalStack tem ganho notoriedade como uma ferramenta extremamente útil para a criação de laboratórios para estudos simulando a API da AWS, ainda que não seja 100% compatível. Com seu uso estudantes podem economizar uma quantia razoável de dinheiro utilizando uma stack local.

Entretanto, isso não significa que ela seja 100% compatível com todas as ferramentas, e infelizmente o Terraform é uma delas. Nestes dias ao realizar testes para um projeto de uma nova infraestrutura deparei-me com o seguinte erro ao tentar criar um bucket S3:

Plan: 1 to add, 0 to change, 0 to destroy.
aws_s3_bucket.this: Creating...
╷
│ Error: creating S3 Bucket (stefano-martins-default): operation error S3: CreateBucket, https response error StatusCode: 0, RequestID: , HostID: , request send failed, Put "http://stefano-martins-default.localhost:4566/": dial tcp: lookup stefano-martins-default.localhost: no such host

Neste artigo nós vamos aprender a realizar a instalação do LocalStack, a criação de um profile e como contornar o problema acima mencionado.

Para fins de simplicidade e redução de stack, nós não utilizaremos TFLocal neste artigo.

tl;dr

# Instalando o LocalStack (macOS com Homebrew)
brew install localstack/tap/localstack-cli

# Instalando o LocalStack (Linux amd64)
curl --output localstack-cli-3.6.0-linux-amd64-onefile.tar.gz \
    --location https://github.com/localstack/localstack-cli/releases/download/v3.6.0/localstack-cli-3.6.0-linux-amd64-onefile.tar.gz

# Instalando o LocalStack (Linux arm64)
curl --output localstack-cli-3.6.0-linux-arm64-onefile.tar.gz \
    --location https://github.com/localstack/localstack-cli/releases/download/v3.6.0/localstack-cli-3.6.0-linux-arm64-onefile.tar.gz

# Descompactando o binário para um diretório que está em seu path (Linux amd64/arm64)
sudo tar xvzf localstack-cli-3.6.0-linux-*-onefile.tar.gz -C /usr/local/bin

# Criando um novo profile
cat <<EOF >> ~/.aws/config
[profile localstack]
region = us-east-1
output = json
endpoint_url = http://localhost:4566
aws_access_key_id = blablabla
aws_secret_access_key = blablabla
EOF

# Instalando o awsp (opcional, apenas caso você possua múltiplos profiles da AWS)
npm install -g awsp
alias aws="source _awsp" # Adicione ao seu ~/.bashrc ou ~/.zshrc

# Altere seu profile para o do LocalStack
awsp

# Teste
aws s3 mb s3://meu-bucket-bonitinho

Instalando o LocalStack

A instalação do LocalStack é relativamente simples. Como pré-requisitos é necessário que o Homebrew (macOS) e o Docker estejam instalados na sua máquina.

A instalação pode ser realizada da seguinte forma em máquinas macOS:

brew install localstack/tap/localstack-cli

Em máquinas Linux você pode realizar o download do pacote .tar.gz e descompactá-lo em um diretório listado no $PATH:

# amd64
curl --output localstack-cli-3.6.0-linux-amd64-onefile.tar.gz \
    --location https://github.com/localstack/localstack-cli/releases/download/v3.6.0/localstack-cli-3.6.0-linux-amd64-onefile.tar.gz

# arm64
curl --output localstack-cli-3.6.0-linux-arm64-onefile.tar.gz \
    --location https://github.com/localstack/localstack-cli/releases/download/v3.6.0/localstack-cli-3.6.0-linux-arm64-onefile.tar.gz

sudo tar xvzf localstack-cli-3.6.0-linux-*-onefile.tar.gz -C /usr/local/bin

Caso você se depare com algum problema de permissão, você pode resolvê-lo da seguinte forma:

sudo chmod 755 /usr/local/bin/localstack

Instalando o AWSP

O AWSP é uma ferramenta muito útil para alternarmos facilmente entre profiles da AWS configurados no arquivo ~/.aws/config. Sua instalação é simples e requer a presença do NPM.

npm install -g awsp

Uma vez instalado, é necessária a criação de um alias dentro do seu arquivo ~/.bashrc ou ~/.zshrc (a depender do shell utilizado por você). Você pode fazer isso adicionando a seguinte linha ao arquivo:

alias awsp="source _awsp"
source ~/.zshrc  # Caso você utilize ZSH
source ~/.bashrc # Caso você utilize Bash

Iniciando o LocalStack

Para testar se o LocalStack foi devidamente instalado na máquina você pode executar o seguinte comando:

localstack --version

Já para iniciá-lo utilize um dos seguintes comandos:

localstack start    # Inicialização em foreground
localstack start -d # Inicialização em background

Agora podemos testar seu uso com o AWSCLI:

aws s3 mb s3://meu-bucket-bonitinho

Configurando o seu projeto Terraform

A configuração do seu provider no Terraform ficará ligeiramente diferente com isso. Segue um exemplo:

provider "aws" {
  region = "us-east-1"
  profile = "localstack"
  s3_use_path_style = true
  endpoints {
    s3 = "http://localhost:4566"
  }
}

Para endpoints de demais serviços da AWS é possível utilizar a documentação oficial do LocalStack.

Jenkins: Criando campos dinâmicos a partir de chamadas à APIs

Stefano Martins — Sun, 28 Aug 2022 18:49:00 +0000

Neste artigo mostraremos como criar campos dinâmicos com base em uma chamada API para builds parametrizados no Jenkins. Para isso nós utilizaremos cURL, Groovy, JsonSlurper, JSON e o plugin Active Choices.

Para exemplificar a utilização, faremos uma chamada à API do IBGE retornando os Estados do Brasil. Segue abaixo um exemplo do JSON que ela retorna:

[
    {
        "id": 11,
        "sigla": "RO",
        "nome": "Rondônia",
        "regiao": {
            "id": 1,
            "sigla": "N",
            "nome": "Norte"
        }
    },
    {
        "id": 12,
        "sigla": "AC",
        "nome": "Acre",
        "regiao": {
            "id": 1,
            "sigla": "N",
            "nome": "Norte"
        }
    },
    ...
]

Aqui nós iremos pegar apenas as UFs dos Estados armazenadas no campo sigla e popular um single select do Active Choices (que já deve estar instalado):

Você pode testar a API utilizando Postman, enviando uma requisição do tipo GET para https://servicodados.ibge.gov.br/api/v1/localidades/estados.

Vamos ao código da pipeline:

import groovy.json.JsonSlurperClassic
node {
    properties([
        parameters([
            [$class: 'ChoiceParameter',
                choiceType: 'PT_SINGLE_SELECT',
                description: 'Selecione o Estado',
                name: 'estado',
                script: [$class: 'GroovyScript',
                    script: [
                        sandbox: false,
                        classpath: [],
                        script: 
                            """
                            import groovy.json.JsonSlurperClassic
                            def proc = "curl -s -H 'Accept:application/json;charset=UTF-8' https://servicodados.ibge.gov.br/api/v1/localidades/estados".execute()
                            proc.waitFor()

                            def output = proc.in.text
                            def exit_code = proc.exitValue()
                            def error = proc.err.text

                            if (error) {
                                print("Std err: \${error}")
                                print("Process exit code \${exitcode}")
                                return exitcode
                            }

                            def json = new JsonSlurperClassic().parseText(output)

                            def siglas = []

                            json.each { v ->
                                siglas.push(v.sigla)
                            }

                            return siglas.sort()
                            """
                    ]
                ]
            ]
        ])
    ])

    stage('Estágio único') {         
            print("O Estado escolhido foi ${estado}.")         
    }
}

Por meio da função parameters(), estamos definindo uma lista com todos os parâmetros que nosso job irá possuir. Neste caso, estamos definindo apenas um campo do tipo ChoiceParameter. Precisamos especificar o tipo da escolha, setando-a como PT_SINGLE_SELECT, damos um nome através da propriedade name e escrevemos então o script em Groovy que será executado para gerar as opções do campo.

Importante: Todo script colocado aqui deve retornar uma lista para popular o campo.

Estamos utilizando aqui a biblioteca JsonSlurper para fazer o deserialize do JSON, transformando-o em um array do Groovy e após isso, iteramos sobre o mesmo retornando apenas as UFs.

Por fim, temos um único stage no pipeline, printando na tela a UF do Estado selecionado.

Alguns pontos importantes:

Você pode utilizar tanto scripted pipelines quando declarative pipelines para chegar ao objetivo final. Inclusive, caso não queira colocar os parâmetros dentro do código da pipeline, você pode fazer isso (embora eu não recomende);
Pode acontecer de ser necessária a autorização da execução de scripts e bibliotecas na área de Gerenciamento do Jenkins;
O plugin Active Choices possui outros tipos de campos, inclusive reativos (imagine uma situação em que você possui dois campos, A e B, e os valores de B dependem do que foi selecionado em A);
Pode ser necessária uma execução do job que falhará (isso é normal) para que a opção Build with parameters esteja disponível.

Troubleshooting

Para que você consiga fazer um melhor troubleshooting do script Groovy executado para o Active Choices, você pode criar um logger especialmente para ele. Isso é útil quando queremos separar o debug desse script do pipeline principal. Para isso, vá em Manage Jenkins > System Log > Clique em Add new log recorder > Dê um nome como "ActiveChoices" > Clique em Add > No campo Logger digite org.biouno.unochoice, selecione o nível desejado e depois clique em Save.

Referências

Subindo um cluster Kubernetes no AWS EKS com eksctl

Stefano Martins — Tue, 21 Jun 2022 15:06:44 +0000

Por mais surpreendente que seja, subir um cluster Kubernetes no AWS EKS há uns tempos atrás não era uma tarefa lá muito fácil, ainda mais comparado com outros cloud providers como o GCP. Foi então que surgiu o eksctl, ferramenta desenvolvida em Go pela comunidade e que hoje é patrocinada pela Weave, sendo o CLI oficial da AWS para gestão do EKS. Com ela, nós podemos criar e gerenciar clusters utilizando arquivos YAML e por debaixo dos panos são utilizadas stacks no CloudFormation para gestão dos recursos necessários.

Instalação

Assim como outros binários escritos em Go, a instalação é super simples:

curl --silent --location "https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C /tmp
sudo mv m/tmp/eksctl /usr/local/bin
eksctl version

Configuração de uma conta AWS

Não utilize sua conta root para a criação do cluster. Aliás, não utilize sua conta root para nada que não seja criar outras contas ou habilitar e gerir recursos muito específicos da AWS.

Caso seja sua conta pessoal, crie um outro usuário. Agora, caso seja uma conta corporativa, eu sugiro que habilite o AWS Organizations.

Crie um novo usuário no IAM com as seguintes policies atreladas a ele:

AmazonEC2FullAccess
AWSCloudFormationFullAccess
EksAllAccess
IamLimitedAccess

As duas primeiras são policies gerenciadas pela própria AWS e você não precisará criá-las. Já as duas últimas terão o seguinte conteúdo:

EkaAllAccess:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "eks:*",
            "Resource": "*"
        },
        {
            "Action": [
                "ssm:GetParameter",
                "ssm:GetParameters"
            ],
            "Resource": [
                "arn:aws:ssm:*:<account_id>:parameter/aws/*",
                "arn:aws:ssm:*::parameter/aws/*"
            ],
            "Effect": "Allow"
        },
        {
             "Action": [
               "kms:CreateGrant",
               "kms:DescribeKey"
             ],
             "Resource": "*",
             "Effect": "Allow"
        },
        {
             "Action": [
               "logs:PutRetentionPolicy"
             ],
             "Resource": "*",
             "Effect": "Allow"
        }        
    ]
}

IamLimitedAccess:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "iam:CreateInstanceProfile",
                "iam:DeleteInstanceProfile",
                "iam:GetInstanceProfile",
                "iam:RemoveRoleFromInstanceProfile",
                "iam:GetRole",
                "iam:CreateRole",
                "iam:DeleteRole",
                "iam:AttachRolePolicy",
                "iam:PutRolePolicy",
                "iam:ListInstanceProfiles",
                "iam:AddRoleToInstanceProfile",
                "iam:ListInstanceProfilesForRole",
                "iam:PassRole",
                "iam:DetachRolePolicy",
                "iam:DeleteRolePolicy",
                "iam:GetRolePolicy",
                "iam:GetOpenIDConnectProvider",
                "iam:CreateOpenIDConnectProvider",
                "iam:DeleteOpenIDConnectProvider",
                "iam:TagOpenIDConnectProvider",
                "iam:ListAttachedRolePolicies",
                "iam:TagRole",
                "iam:GetPolicy",
                "iam:CreatePolicy",
                "iam:DeletePolicy",
                "iam:ListPolicyVersions"
            ],
            "Resource": [
                "arn:aws:iam::<account_id>:instance-profile/eksctl-*",
                "arn:aws:iam::<account_id>:role/eksctl-*",
                "arn:aws:iam::<account_id>:policy/eksctl-*",
                "arn:aws:iam::<account_id>:oidc-provider/*",
                "arn:aws:iam::<account_id>:role/aws-service-role/eks-nodegroup.amazonaws.com/AWSServiceRoleForAmazonEKSNodegroup",
                "arn:aws:iam::<account_id>:role/eksctl-managed-*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "iam:GetRole"
            ],
            "Resource": [
                "arn:aws:iam::<account_id>:role/*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "iam:CreateServiceLinkedRole"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "iam:AWSServiceName": [
                        "eks.amazonaws.com",
                        "eks-nodegroup.amazonaws.com",
                        "eks-fargate.amazonaws.com"
                    ]
                }
            }
        }
    ]
}

Substitua <account_id> pelo ID da sua conta AWS.

Gere agora para o usuário uma credencial e guarde a access key ID e a secret key. O eksctl necessita que o AWS CLI esteja instalado. Caso não o tenha, execute:

curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install
aws configure

Serão solicitados dados como região padrão da AWS (us-east-1, por exemplo), a access key ID e a secret key para criação do perfil padrão (default). Agora, caso você já tenha o AWS CLI instalado e configurado, você pode criar o novo perfil manualmente editando o arquivo ~/.aws/credentials.

Atenção: quando possuir múltiplos profiles dentro do seu arquivo ~/.aws/credentials, informe qual você quer utilizar setando o valor da variável AWS_PROFILE com o comando export AWS_PROFILE=meu_perfil.

Criação do cluster

O eksctl por padrão criará o cluster em um VPC separado utilizando instâncias do tipo m5.large. Isso traz algumas implicações:

Pela quota padrão, pode-se ter no máximo cinco VPCs por conta;
Caso esteja utilizando um ambiente de estudos, laboratórios ou testes, esse tipo de instância pode ser considerado um pouco caro;
Caso você precise que as aplicações do cluster comuniquem-se com recursos da AWS - uma instância no RDS, por exemplo - localizados em outro VPC, é necessária a configuração de VPC Peering e de rotas para que isso ocorra.

Nosso cluster terá as seguintes características:

Ele será chamado de demo-eks e estará localizado em us-east-1 (Virgínia do Norte);
Quatro subredes serão criadas no novo VPC sendo duas públicas e duas privadas. Por padrão, o eksctl aloca os nós do cluster nas subredes privadas;
Será criado um nodegroup chamado ng-01 com um auto scaling group, com no mínimo uma instância e no máximo 5 do tipo t3.medium;
Policies do IAM para external-dns, auto-scaling, cert-manager, ebs e efs. Falaremos mais sobre esses caras logo menos.

---
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: demo-eks
  region: us-east-1

managedNodeGroups:
  - name: ng-01
    instanceType: t3.medium
    desiredCapacity: 2
    minSize: 1
    maxSize: 5
    iam:
      withAddonPolicies:
        autoScaler: true
        externalDNS: true
        certManager: true
        ebs: true
        efs: true

Como pode-se notar, o YAML é um manifesto muito parecido com os utilizados no Kubernetes.

Salve o arquivo acima como demo-eks.yaml e agora apenas execute eksctl cluster create -f demo-eks.yaml --kubeconfig=demo-eks-kubeconfig e deixe a mágica acontecer (naturalmente). O eksctl gerará a stack (ou stacks) dentro do CloudFormation e criará todos os recursos necessários, o que demorará cerca de quinze a vinte minutos (sim, é um pouco demorado) e pronto, você terá um cluster Kubernetes para uso no AWS EKS, com as credenciais para acesso ao mesmo no arquivo demo-eks-kubeconfig.yaml.

Importante: Caso a opção --kubeconfig seja omitida, o eksctl gerará o arquivo de acesso em ~/.kube/config, o que pode ser um problema caso você já possua outros clusters configurados. Caso seja o caso, você pode criar um diretório chamado ~/.kube/configs, para armazenar os arquivos e alternar entre os mesmos setando a variável de KUBECONFIG apontando para o caminho do arquivo desejado (ex: export KUBECONFIG=${HOME}/.kube/configs/demo-eks-kubeconfig). Este passo é essencial para que o kubectl consiga conectar-se ao cluster.

Instalação do Helm

Muito provavelmente você já ouviu falar do Helm, mas se isso não ocorreu, relaxa. O Helm é a grosso modo um gerenciador de pacotes para o Kubernetes. Esses pacotes são disponibilizados na forma de charts e com ele podemos criar os manifestos das nossas aplicações de uma forma mais dinâmica, organizada, parametrizável, e posteriormente hospedando-o em repositórios para deployment.

Curiosidade inútil: "chart" pode ser traduzido para "carta de navegação". "Kubernetes" = "timão". Sacou, sacou? Hehehe.

Sua instalação é super simples:

curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

Agora, caso você utilize uma distribuição Debian-like e deseje utilizar um pacote:

curl https://baltocdn.com/helm/signing.asc | gpg --dearmor | sudo tee /usr/share/keyrings/helm.gpg > /dev/null
sudo apt-get install apt-transport-https --yes
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/helm.gpg] https://baltocdn.com/helm/stable/debian/ all main" | sudo tee /etc/apt/sources.list.d/helm-stable-debian.list
sudo apt-get update
sudo apt-get install helm

Instalação de add-ons

Metrics Server

O Metrics Server é um recurso necessário para o uso de HPAs (Horizontal Pod Autoscalers). HPAs são extremamente úteis quando nós queremos escalonar nossas aplicações horizontalmente quando as mesmas necessitam de mais recursos.

helm repo add metrics-server https://kubernetes-sigs.github.io/metrics-server/
helm upgrade --install --create-namespace -n metrics-server metrics-server metrics-server/metrics-server

Prometheus

O Prometheus é uma solução de monitoramento. Caso você utilize o Lens ou outro dashboard para monitoramento dos seus clusters, ele irá fornecer gráficos de uso de CPU, memória, rede e disco para o cluster, nodes, controllers e pods. O Prometheus é comumente utilizado junto com o Grafana.

helm repo add bitnami https://charts.bitnami.com/bitnami
helm install --create-namespace -n kube-prometheus prometheus bitnami/kube-prometheus

ExternalDNS

O ExternalDNS sincroniza recursos do Kubernetes com registros DNS externos hospedados em providers como AWS Route 53, Google Cloud DNS, AzureDNS, etc. Com ele, nós não precisamos manualmente criar entradas DNS toda vez que subimos uma nova aplicação no nosso cluster. Bacana né?

helm install external-dns stable/external-dns \
  --create-namespace \
  --namespace external-dns \
  --set provider=aws \
  --set aws.zoneType=public \
  --set txtOwnerId=<ZONE_ID>
  --set policy=sync
  --set registry=txt
  --set interval=20s
  --set domainFilters[0]=<DOMAIN>

Altere <ZONE_ID> para o ID da sua zona no AWS Route 53 e <DOMAIN> para o seu domínio no formato dominio.com.

cert-manager

O cert-manager é um CRD (Custom Resource Definition) que gerará dinamicamente certificados TLS/SSL para as nossas aplicações utilizando o Let's Encrypt (embora ele também suporte outros issuers).

helm repo add bitnami https://charts.bitnami.com/bitnami
helm install --create-namespace -n cert-manager cert-manager bitnami/cert-manager \
  --create-namespace \
  --namespace cert-manager \
  --set installCRDs=true

Com o chart instalado, é necessária a criação de dois CRDs, cada qual representando um issuer diferente do Let's Encrypt, um para produção e outro para staging. A diferença entre ambos é basicamente a limite de requisições que nós podemos realizar. Em ambiente de testes, prefira utilizar o ambiente de staging.

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: <meu_email>
    privateKeySecretRef:
      name: letsencrypt-prod
    solvers:
      - http01:
          ingress:
            class: nginx

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-staging
spec:
  acme:
    server: https://acme-staging-v02.api.letsencrypt.org/directory
    email: <meu_email>
    privateKeySecretRef:
      name: letsencrypt-prod
    solvers:
      - http01:
          ingress:
            class: nginx

Nota: Substitua <meu_email> pelo seu endereço de e-mail. Caso você esteja utilizando um Ingress diferente do Nginx, é necessário alterar os manifestos acima setando a classe adequada.

Execute o comando kubectl apply -f cert-manager-staging.yaml -f cert-manager-prod.yaml para criá-los no cluster.

NGINX Ingress Controller

É por meio do NGINX Ingress Controller que nós permitiremos acesso às nossas aplicações. Você pode enxergar um Ingress como um proxy reverso.

helm upgrade --install ingress-nginx ingress-nginx \
  --repo https://kubernetes.github.io/ingress-nginx \
  --namespace ingress-nginx \
  --create-namespace

Auto Scaling Group

Um dos recursos mais legais de cloud computing é a elasticidade. Imagine que durante o ano todo nós temos uma demanda relativamente constante, mas em certas épocas - como Black Friday - elas podem aumentar consideravelmente e logo você vai precisar de mais nós dentro dos seus nodegroups para suprir as necessidades dos seus pods. Para que não tenhamos que fazer isso manualmente, vamos adicionar a funcionalidade de escalonamento automático do nosso nodegroup.

helm repo add autoscaler https://kubernetes.github.io/autoscaler
helm install --create-namespace -n cluster-autoscaler autoscaler/cluster-autoscaler \
  --set 'autoDiscovery.clusterName=<cluster_name>'

Nota: Substitua <cluster_name> pelo nome do seu cluster (neste caso, demo-eks).

Para testar, após subir uma aplicação qualquer, aumente a quantidade de réplicas para um número não atendido pelos recursos disponíveis no seu nodegroup. O cluster-autoscaler disponibilizará novos nós até o número máximo setado no nodegroup. Quando a quantidade de pods consumir menos do que 50% dos recursos de um nó por mais do que 10 minutos, este nó será removido do nodegroup. Bacana né?

Subindo uma aplicação

Com o nosso cluster montado e os add-ons instalados, está na hora de subir uma aplicação teste. Abaixo os manifestos dentro de um único arquivo hello-kubernetes.yaml:

apiVersion: v1
kind: Namespace
metadata:
  name: hello-kubernetes
---
apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: hello-kubernetes
  name: hello-kubernetes
spec:
  replicas: 2
  selector:
    matchLabels:
      app: hello-kubernetes
  template:
    metadata:
      labels:
        app: hello-kubernetes
    spec:
      containers:
      - name: hello-kubernetes
        image: paulbouwer/hello-kubernetes:1.5
        ports:
        - containerPort: 8080
        resources:
          requests:
            memory: "128Mi"
            cpu: "250m"
          limits:
            memory: "256Mi"
            cpu: "500m"
---
apiVersion: v1
kind: Service
metadata:
  namespace: hello-kubernetes
  name: hello-kubernetes
spec:
  type: ClusterIP
  selector:
    app: hello-kubernetes
  ports:
  - port: 80
    targetPort: 8080
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  namespace: hello-kubernetes
  name: hello-kubernetes-ingress
  annotations:
    kubernetes.io/ingress.class: nginx
    external-dns.alpha.kubernetes.io/hostname: <app.DOMINIO>
    cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
  tls:
    - hosts:
        - <app.DOMINIO>
      secretName: <app.DOMINIO>
  rules:
    - host: <app.DOMINIO>
      http:
        paths:
        - path: /
          pathType: Prefix
          backend:
            service:
              name: hello-kubernetes
              port: 
                number: 80

Nota: Substitua ` pelo domínio que você quer utilizar na sua aplicação, algo como app-01.juquinha.net.

Se tudo der certo, eis o que devera acontecer:

Entradas serão criadas dentro da sua zona DNS lá dentro do AWS Route 53 de acordo com o que foi configurado no seu ingress e nas configurações do seu ExternalDNS e dentro de alguns minutos você poderá acessar sua aplicação por meio desse nome. Você pode monitorar a propagação por meio da ferramenta dig;
Um certificado será gerado automaticamente para sua aplicação. Isso pode demorar um tempo para aplicações novas;
Nós alocamos duas réplicas para a aplicação e aqui cabe uma ressalva muito importante: O Kubernetes por padrão fará um balanceamento do tipo round-robin entre os pods. Em grande parte das aplicações web atuais nós trabalhamos com sessões e como consequência disso, pode ocorrer o cenário em que o usuário se autentica em um pod, e na próxima requisição ser redirecionado ao outro, onde a sessão não existe. Como consequência, são apresentados comportamentos estranhos para o usuário, como o redirecionamento para a tela de login, mensagens de "Não autorizado", intermitência no acesso, etc. Para que isso não ocorra, nós normalmente utilizamos algum serviço como o Redis, memcached (estes podendo ou não serem no AWS ElastiCache) ou a funcionalidade de sticky-sessions, em que um usuário é constantemente enviado para o mesmo pod.

Conclusão

Kubernetes é um assunto extremamente extenso e complexo é há uma infinidade de possibilidades com ele. Apresentei aqui algumas delas que podem ser utilizadas não só no AWS EKS, mas em instalações on-premises (com excessão do cluster-autoscaler, a menos que você esteja utilizando OpenStack na sua empresa). Existe também uma série de melhorias de segurança que podem ser realizadas no cluster montado neste artigo. Espero que vocês tenham curtido!

Referências

eksctl

Criação de múltiplos objetos utilizando locals e loops

Stefano Martins — Wed, 01 Jun 2022 18:12:02 +0000

Se você já se encontrou em uma situação onde teve que gerenciar uma grande quantidade de recursos com os mesmos argumentos, e quando olha para o lado, você está lá editando um arquivo .tf com pelo menos 1500 linhas, chato, repetitivo, cheio de recursos iguais, na base do copia-e-cola bem, talvez este artigo seja para você. Nele apresentarei uma forma para escrever um código menor e mais dinâmico com o uso de locals e loops for_each com o objetivo de tornar a nossa vida um pouco melhor. Chega mais!

Vamos pegar o código abaixo como exemplo:

resource "aws_sqs_queue" "fila_01_dlq" {
  name = "fila-01-dlq"

  message_retention_seconds = 172800
  delay_seconds = 0
  max_message_size = 256000
  visibility_timeout_seconds = 40
  receive_wait_time_seconds = 20
}

resource "aws_sqs_queue" "fila_01" {
  name = "fila-01"

  message_retention_seconds = 172800
  delay_seconds = 0
  max_message_size = 256000
  visibility_timeout_seconds = 40
  receive_wait_time_seconds = 20

  redrive_policy = jsonencode({
    deadLetterTargetArn = aws_sqs_queue.fila_01_dlq.arn
    maxReceiveCount = 3
  })
}

resource "aws_sqs_queue" "fila_02_dlq" {
  name = "fila-02-dlq"

  message_retention_seconds = 172800
  delay_seconds = 0
  max_message_size = 256000
  visibility_timeout_seconds = 40
  receive_wait_time_seconds = 20
}

resource "aws_sqs_queue" "fila_02" {
  name = "fila-02"

  message_retention_seconds = 172800
  delay_seconds = 0
  max_message_size = 256000
  visibility_timeout_seconds = 40
  receive_wait_time_seconds = 20

  redrive_policy = jsonencode({
    deadLetterTargetArn = aws_sqs_queue.fila_02_dlq.arn
    maxReceiveCount = 3
  })
}

resource "aws_sqs_queue" "fila_03_dlq" {
  name = "fila-03-dlq"

  message_retention_seconds = 172800
  delay_seconds = 0
  max_message_size = 256000
  visibility_timeout_seconds = 40
  receive_wait_time_seconds = 20
}

resource "aws_sqs_queue" "fila_03" {
  name = "fila-03"

  message_retention_seconds = 172800
  delay_seconds = 0
  max_message_size = 256000
  visibility_timeout_seconds = 40
  receive_wait_time_seconds = 20

  redrive_policy = jsonencode({
    deadLetterTargetArn = aws_sqs_queue.fila_03_dlq.arn
    maxReceiveCount = 3
  })
}

Nele, nós temos o seguinte:

São definidas 6 filas SQS, sendo 3 normais e suas respectivas DLQs (Dead-Letter Queues), ou seja, filas para onde as mensagens são enviadas caso não processadas;
Os atributos das 3 filas normais são os mesmos, assim como os das filas DLQs. Isso é importante porque nós temos um padrão de recurso para criação de um loop;
Temos vários valores de argumentos que se repetem, e nós podemos utilizar para eles variáveis, mantendo o nosso código DRY (Don't Repeat Yourself).

Vamos aplicar essas mudanças aos poucos para podermos analisar a melhoria gradual do arquivo. O primeiro desses passos será a substituição dos valores dos argumentos por variáveis:

variable "sqs_message_retention_seconds" {
  type = number
  default = 172800
}

variable "sqs_delay_seconds" {
  type = number
  default = 0
}

variable "sqs_max_message_size" {
  type = number
  default = 256000
}

variable "sqs_visibility_timeout_seconds" {
  type = number
  default = 40
}

variable "sqs_receive_wait_time_seconds" {
  type = number
  default = 20
}

variable "sqs_maxReceiveCount" {
  type = number
  default = 3
}

resource "aws_sqs_queue" "fila_01_dlq" {
  name = "fila-01-dlq"

  message_retention_seconds = var.sqs_message_retention_seconds
  defay_seconds = var.sqs_delay_seconds
  max_message_size = var.sqs_max_message_size
  visibility_timeout_seconds = var.sqs_visibility_timeout_seconds
  receive_wait_time_seconds = var.sqs_receive_wait_time_seconds
}

resource "aws_sqs_queue" "fila_01" {
  name = "fila-01"

  message_retention_seconds = var.message_retention_seconds
  defay_seconds = var.sqs_delay_seconds
  max_message_size = var.sqs_max_message_size
  visibility_timeout_seconds = var.sqs_visibility_timeout_seconds
  receive_wait_time_seconds = var.sqs_receive_wait_time_seconds

  redrive_policy = jsonencode({
    deadLetterTargetArn = aws_sqs_queue.fila_01_dlq.arn
    maxReceiveCount = var.sqs_maxReceiveCount
  })
}

resource "aws_sqs_queue" "fila_02_dlq" {
  name = "fila-02-dlq"

  message_retention_seconds = var.message_retention_seconds
  defay_seconds = var.sqs_delay_seconds
  max_message_size = var.sqs_max_message_size
  visibility_timeout_seconds = var.sqs_visibility_timeout_seconds
  receive_wait_time_seconds = var.sqs_receive_wait_time_seconds
}

resource "aws_sqs_queue" "fila_02" {
  name = "fila-02"

  message_retention_seconds = var.message_retention_seconds
  defay_seconds = var.sqs_delay_seconds
  max_message_size = var.sqs_max_message_size
  visibility_timeout_seconds = var.sqs_visibility_timeout_seconds
  receive_wait_time_seconds = var.sqs_receive_wait_time_seconds

  redrive_policy = jsonencode({
    deadLetterTargetArn = aws_sqs_queue.fila_02_dlq.arn
    maxReceiveCount = var.sqs_maxReceiveCount
  })
}

resource "aws_sqs_queue" "fila_03_dlq" {
  name = "fila-03-dlq"

  message_retention_seconds = var.message_retention_seconds
  defay_seconds = var.sqs_delay_seconds
  max_message_size = var.sqs_max_message_size
  visibility_timeout_seconds = var.sqs_visibility_timeout_seconds
  receive_wait_time_seconds = var.sqs_receive_wait_time_seconds
}

resource "aws_sqs_queue" "fila_03" {
  name = "fila-03"

  message_retention_seconds = var.message_retention_seconds
  defay_seconds = var.sqs_delay_seconds
  max_message_size = var.sqs_max_message_size
  visibility_timeout_seconds = var.sqs_visibility_timeout_seconds
  receive_wait_time_seconds = var.sqs_receive_wait_time_seconds

  redrive_policy = jsonencode({
    deadLetterTargetArn = aws_sqs_queue.fila_03_dlq.arn
    maxReceiveCount = var.sqs_maxReceiveCount
  })
}

O nosso principal ganho com esta nova versão é que caso desejemos modificar o valor de um argumento, não precisamos fazê-lo em todos os resources, mas apenas na variável.

Agora vamos criar um bloco locals para armazenar os nossos dados das filas normais e DLQ, assim como a criação dos resources padrão:

variable "sqs_message_retention_seconds" {
  type = number
  default = 172800
}

variable "sqs_delay_seconds" {
  type = number
  default = 0
}

variable "sqs_max_message_size" {
  type = number
  default = 256000
}

variable "sqs_visibility_timeout_seconds" {
  type = number
  default = 40
}

variable "sqs_receive_wait_time_seconds" {
  type = number
  default = 20
}

variable "sqs_maxReceiveCount" {
  type = number
  default = 3
}

locals {
  aws_sqs_queues_dlq = {
    fila_01_dlq = {
      name = "fila-01-dlq"
    }
    fila_02_dlq = {
      name = "fila-02-dlq"
    }
    fila_03_dlq = {
      name = "fila-03-dlq"
    }
    fila_01 = {
      name = "fila-01"
      deadLetterTargetArn = aws_sqs_queue.aws_sqs_queues_dlq["fila_01_dlq"].arn
    }
    fila_02 = {
      name = "fila-02"
      deadLetterTargetArn = aws_sqs_queue.aws_sqs_queues_dlq["fila_02_dlq"].arn
    }
    fila_03 = {
      name = "fila-03"
      deadLetterTargetArn = aws_sqs_queue.aws_sqs_queues_dlq["fila_03_dlq"].arn
    }
  }
}

resource "aws_sqs_queue" "aws_sqs_queues_dlq" {
  for_each = local.aws_sqs_queues_dlq
  name = each.value.name

  message_retention_seconds = try(each.value.message_retention_seconds, var.sqs_message_retention_seconds)
  delay_seconds = try(each.value.delay_seconds, var.sqs_delay_seconds)
  max_message_size = try(each.value.delay_seconds, var.sqs_max_message_size)
  visibility_timeout_seconds = try(each.value.visibility_timeout_seconds, var.sqs_visibility_timeout_seconds)
  receive_wait_time_seconds = try(each.value.receive_wait_time_seconds, var.sqs_receive_wait_time_seconds)
}

resource "aws_sqs_queue" "aws_sqs_queues" {
  for_each = local.aws_sqs_queue
  name = each.value.name

  message_retention_seconds = try(each.value.message_retention_seconds, var.sqs_message_retention_seconds)
  delay_seconds = try(each.value.delay_seconds, var.sqs_delay_seconds)
  max_message_size = try(each.value.delay_seconds, var.sqs_max_message_size)
  visibility_timeout_seconds = try(each.value.visibility_timeout_seconds, var.sqs_visibility_timeout_seconds)
  receive_wait_time_seconds = try(each.value.receive_wait_time_seconds, var.sqs_receive_wait_time_seconds)

  redrive_policy = jsonencode({
    deadLetterTargetArn = each.value.deadLetterTargetArn
    maxReceiveCount = try(each.value.maxReceiveCount, var.sqs_maxReceiveCount)
  })
}

Pontos sobre esta nova versão:

Dentro do bloco locals foram criados dois maps: um para armazenar as nossas filas normais chamado aws_sqs_queues, e outro chamado aws_sqs_queues_dlq para as filas DLQ. Dentro de cada um estamos definindo os atributos que serão consumidos pelos resources (name, deadLetterTargetArn, etc.). A escolha pelo uso de locals sobre variáveis normais dá-se devido ao fato de que diferentemente de linguagens de programação normais, o Terraform não suporta que variáveis tenham como seus valores resultados de expressões, atributos de resources ou que os mesmos sejam sobreescritos ao longo da execução do Terraform;
Em cada um dos dois resources, temos um loop for_each iterando sobre o respectivo map. A nossa preocupação aqui é definir um resource padrão, onde tentamos resgatar os valores do map com o uso da função try(), e caso não consigamos, ele tentará pegar o valor da variável.

É possível melhorar ainda mais esta estrutura com a utilização de módulos, abstraindo ainda mais a infraestrutura, mas fica para um próximo artigo.

Armazenando dados sensíveis em código Terraform utilizando KMS

Stefano Martins — Wed, 27 Apr 2022 08:27:11 +0000

Tratando-se de IaC, chegará cedo ou tarde o fatídico dia em que você terá que colocar uma senha, chave, ou qualquer outro dado sigiloso no seu código. Algumas pessoas não se preocupam muito quando estão versionando seus projetos, levando em consideração coisas como o fato de seus repositórios serem privados, por exemplo. Entretanto, sejamos sinceros: não há lá muita garantia que o código fique só no seu repositório, não é?

A grande maioria das ferramentas hoje conta com pelo menos um mecanismo para resolver esse pequeno probleminha. O Ansible, por exemplo, conta com o Ansible Vault. Já o Terraform conta com vários, como por exemplo a integração com o Vault (também da Hashicorp).

Neste breve artigo demonstrarei como manter seus dados seguros utilizando o AWS KMS (Key Management Service), serviço da AWS utilizado para criação e armazenamento de chaves e criptografia que conta com 20.000 requisições gratuitas no free tier e que pode ser utilizado entre múltiplos serviços. Bora lá?

O primeiro passo é a criação de uma chave dentro do KMS, que pode ser feita por meio do próprio Terraform ou através da Console. Caso opte pela primeira opção, serão necessários três tipos diferentes de objetos Terraform: um data source (aws_iam_policy_document) e dois resources (aws_kms_key e aws_kms_alias). Abaixo uma breve descrição do papel que cada um desempenhará:

aws_iam_policy_document: este é o data source onde definiremos o documento da política informando usuários e suas respectivas permissões referentes às chaves e recursos dentro do KMS.

Detalhe: aqui nós estamos utilizando uma policy do tipo resource-based.

aws_kms_key: a chave propriamente dita. Aqui informaremos o tipo da chave, se ela é simétrica ou assimétrica, se ela pode ser utilizada para criptografar ou descriptografar, assim como associar o documento criado no data source para definir uma política de acesso à ela';
aws_kms_alias: um alias nada mais é do que um apelido utilizado para referenciar a chave.

Abaixo o código Terraform:

data "aws_iam_policy_document" "how_to_terraform_kms_pd" {
  statement {
    sid = "Enable IAM User Permissions"
    effect = "Allow"
    principals {
      type = "AWS"
      identifiers = [
        "arn:aws:iam::111111111111:root"
      ]
    }
    actions = [
      "kms:*"
    ]
    resources = [
      "*"
    ]
  }

  statement {
    sid = "Allow use of the key"
    effect = "Allow"
    principals {
      type = "AWS"
      identifiers = [
        "arn:aws:iam::111111111111:user/meu-usuario"
      ]
    }
    actions = [
      "kms:Encrypt",
      "kms:Decrypt",
      "kms:ReEncrypt*",
      "kms:GenerateDataKey*",
      "kms:DescribeKey"
    ]
    resources = [
      "*"
    ]
  }

  statement {
    sid = "Allow attachment of persistent resources"
    principals {
      type = "AWS"
      identifiers = [
        "arn:aws:iam::111111111111:user/meu-usuario"
      ]
    }
    actions = [
      "kms:CreateGrant",
      "kms:ListGrants",
      "kms:RevokeGrant"
    ]
    resources = [
      "*"
    ]
    condition {
      test = "Bool"
      variable = "kms:GrantIsForAWSResource"
      values = [
        "true"
      ]
    }
  }
}

resource "aws_kms_key" "how_to_terraform_kms" {
  description = "Teste de criptografia com KMS"
  key_usage = "ENCRYPT_DECRYPT"
  customer_master_key_spec = "SYMMETRIC_DEFAULT"
  policy = data.aws_iam_policy_document.how_to_terraform_kms_pd.json
}

resource "aws_kms_alias" "how_to_terraform_kms_alias" {
  name = "alias/how_to_terraform_kms"
  target_key_id = aws_kms_key.how_to_terraform_kms.key_id
}

output "how_to_terraform_kms_id" {
  value = aws_kms_key.how_to_terraform_kms.key_id
}

Nota: no data source how_to_terraform_kms_pd, nós definimos o account ID como 111111111111 e o usuário como meu-usuario. Ajuste esses valores para o seu caso.

Após um terraform plan e um terraform apply os recursos já devem estar presentes na sua conta AWS. Note que há também um output que imprime o ID da chave recém-criada e caso você opte por consultá-lo diretamente na Console, o mesmo pode ser removido.

Com a chave pronta para uso, agora é hora de criptografar algo. E é aí que o nosso velho amigo AWS CLI entra em cena. Utilize para isso o seguinte comando:

aws kms encrypt --key-id ${key_id} \ 
  --plaintext ${texto_a_ser_criptografado} \
  --output text \
  --query CiphertextBlob

Nota: não se esqueça que você deve ter exportado as variáveis como AWS_SECRET_ACCESS_KEY e AWS_ACCESS_KEY_ID corretamente no seu terminal para acessar sua conta.

Se tudo der certo, o valor criptografado deve aparecer na tela.

Neste momento você deve estar se perguntando "OK, mas o propósito não era esconder as coisas no código do Terraform?". Estamos chegando lá. Este valor criptografado que nós geramos utilizando o AWS CLI pode ser resgatado dentro do próprio Terraform, que consulta o KMS durante sua execução utilizando o data source aws_kms_secrets da seguinte forma:

data "aws_kms_secrets" "teste_kms" {
  secret {
    name = "valor_resgatado"
    payload = "AQICAHhAVXI4s1jnWVzWUxKnuk9yI2/aDoEQu8vyYkhh0tUC2QEMKXf54sQFje6ImNjDyraEAAAAcjBwBgkqhkiG9w0BBwagYzBhAgEAMFwGCSqGSIb3DQEHATAeBglghkgBZQMEAS4wEQQMoKPEjuATAOXqrzraAgEQgC9Kwf2DiUTxrDy0g8kggiLc+bhWhuYLDQaB/DhsMxyV9pD6ROsT/boZztyJFD30oQ=="
  }
}

output "valor_resgatado" {
  value = data.aws_kms_secrets.teste_kms.plaintext["valor_resgatado"]
}

Dentro do bloco secret do data source você deve dar um nome único para referenciá-lo e o seu valor criptográfico. Não é necessário informar a chave, uma vez que ela já está contida no payload. Você pode então referenciar o secret em qualquer parte do seu código utilizando a notação data.aws_kms_secrets.teste_kms.plaintext["valor_resgatado"]. Você pode incluir quantos blocos secret quiser dentro do data source.

Referências

Storing secrets in terraform codebase with KMS

Recarregando o inventário do Ansible durante a execução

Stefano Martins — Mon, 11 Oct 2021 23:42:05 +0000

Introdução

Esta dica surgiu a partir de uma dúvida no Telegram da LINUXtips e é ótima para quem precisa trabalhar com inventários dinâmicos ou realiza modificações em seu arquivo de inventário.

Imagine o seguinte cenário: Você possui um playbook que realiza modificações no seu inventário como adicionar um novo host, e durante a mesma execução do playbook precisa que este host recém-adicionado seja levado em consideração para uma próxima task ou role.

Para melhor ilustrar, criei abaixo um arquivo de inventário e um playbook que simplesmente irá imprimir todos os hosts do inventário, adicionar um novo host chamado host-03 e depois imprimir novamente os hosts:

# hosts
[all]
host-01
host-02

# playbook.yml
--- 
- hosts: localhost
  become: true
  connection: local
  tasks:

    - name: Print list of hosts in inventory
      ansible.builtin.debug:
        msg: "{{ item }}"
      loop: "{{ groups['all'] }}"

    - name: Add host to inventory
      ansible.builtin.lineinfile:
        line: host-03
        path: ./hosts
        regexp: "^host-03"
        state: present

    - name: Print list of hosts in inventory
      ansible.builtin.debug:
        msg: "{{ item }}"
      loop: "{{ groups['all'] }}"

Vamos executar o nosso playbook com ansible-playbook -i hosts playbook.yml, obtendo o seguinte resultado:

PLAY [localhost] ************************************************************************************************************************************************************

TASK [Gathering Facts] ******************************************************************************************************************************************************
ok: [localhost]

TASK [Print list of hosts in inventory] *************************************************************************************************************************************
ok: [localhost] => (item=host-01) => {
    "msg": "host-01"
}
ok: [localhost] => (item=host-02) => {
    "msg": "host-02"
}

TASK [Add host to inventory] ************************************************************************************************************************************************
changed: [localhost]

TASK [Print list of hosts in inventory] *************************************************************************************************************************************
ok: [localhost] => (item=host-01) => {
    "msg": "host-01"
}
ok: [localhost] => (item=host-02) => {
    "msg": "host-02"
}

PLAY RECAP ******************************************************************************************************************************************************************
localhost                  : ok=4    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Percebe que foi adicionado um novo host host-03 (inclusive, você perceberá a nova entrada no arquivo hosts), porém na segunda impressão, ele continua não sendo impresso? O motivo disso é devido ao fato de que o Ansible apenas carrega na memória o inventário durante o início da execução do playbook, ignorando eventuais alterações no mesmo (inclusive para inventários dinâmicos).

Mas a pergunta que fica é: OK, e se eu precisar que alterações no meu inventário sejam à quente, para continuidade na execução? Bom, aí temos principalmente duas opções:

Opção A: utilize o módulo add_host

O módulo add_host serve para adicionarmos hosts dinamicamente à execução do Ansible, porém não persistidas no arquivo de inventário. Podemos utilizá-lo, adicionando uma task extra ao nosso playbook, carregando o host host-03 também na memória:

--- 
- hosts: localhost
  become: true
  connection: local
  tasks:

    - name: Print list of hosts in inventory
      ansible.builtin.debug:
        msg: "{{ item }}"
      loop: "{{ groups['all'] }}"

    - name: Add host to inventory file
      ansible.builtin.lineinfile:
        line: host-03
        path: ./hosts
        regexp: "^host-03"
        state: present

    - name: Add host to inventory (memory)
      ansible.builtin.add_host:
        name: host-03

    - name: Print list of hosts in inventory
      ansible.builtin.debug:
        msg: "{{ item }}"
      loop: "{{ groups['all'] }}"

O resultado da execução é o seguinte:

PLAY [localhost] ************************************************************************************************************************************************************

TASK [Gathering Facts] ******************************************************************************************************************************************************
ok: [localhost]

TASK [Print list of hosts in inventory] *************************************************************************************************************************************
ok: [localhost] => (item=host-01) => {
    "msg": "host-01"
}
ok: [localhost] => (item=host-02) => {
    "msg": "host-02"
}

TASK [Add host to inventory file] *******************************************************************************************************************************************
changed: [localhost]

TASK [Add host to inventory (memory)] ***************************************************************************************************************************************
changed: [localhost]

TASK [Print list of hosts in inventory] *************************************************************************************************************************************
ok: [localhost] => (item=host-01) => {
    "msg": "host-01"
}
ok: [localhost] => (item=host-02) => {
    "msg": "host-02"
}
ok: [localhost] => (item=host-03) => {
    "msg": "host-03"
}

PLAY RECAP ******************************************************************************************************************************************************************
localhost                  : ok=5    changed=2    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Opção B: utilize a metatask refresh_inventory

Metatasks são basicamente tasks que alteram o comportamento do Ansible durante sua execução. Vamos adicionar uma delas no nosso playbook após a adição do nosso host ao arquivo de inventário para que o mesmo seja recarregado antes da nova impressão:

--- 
- hosts: localhost
  become: true
  connection: local
  tasks:

    - name: Print list of hosts in inventory
      ansible.builtin.debug:
        msg: "{{ item }}"
      loop: "{{ groups['all'] }}"

    - name: Add host to inventory file
      ansible.builtin.lineinfile:
        line: host-03
        path: ./hosts
        regexp: "^host-03"
        state: present

    - meta: refresh_inventory

    - name: Print list of hosts in inventory
      ansible.builtin.debug:
        msg: "{{ item }}"
      loop: "{{ groups['all'] }}"

PLAY [localhost] ************************************************************************************************************************************************************

TASK [Gathering Facts] ******************************************************************************************************************************************************
ok: [localhost]

TASK [Print list of hosts in inventory] *************************************************************************************************************************************
ok: [localhost] => (item=host-01) => {
    "msg": "host-01"
}
ok: [localhost] => (item=host-02) => {
    "msg": "host-02"
}

TASK [Add host to inventory file] *******************************************************************************************************************************************
changed: [localhost]

TASK [Print list of hosts in inventory] *************************************************************************************************************************************
ok: [localhost] => (item=host-01) => {
    "msg": "host-01"
}
ok: [localhost] => (item=host-02) => {
    "msg": "host-02"
}
ok: [localhost] => (item=host-03) => {
    "msg": "host-03"
}

PLAY RECAP ******************************************************************************************************************************************************************
localhost                  : ok=4    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Conclusão

Neste breve artigo nós vimos como o Ansible lê seu inventário, e como podemos adicionar novos hosts durante sua execucão para novas tasks e roles, este conhecimento sendo aplicável tanto para inventários dinâmicos quanto estáticos (ou quando nós queremos manipular o nosso arquivo hosts).

Espero que tenham curtido!

Mantendo o ENTRYPOINT e o CMD originais de uma imagem Docker gerada através do Packer

Stefano Martins — Thu, 23 Sep 2021 21:19:44 +0000

Imagine o seguinte cenário: existe uma imagem Docker que faz quase-tudo que você precisa, mas falta alguma coisinha, um pacote, um arquivinho, um redirect. Logo, o que você faz? Cria um Dockerfile, utiliza aquela imagem como base em um FROM, executa meia dúzia de RUN, COPY, e cria uma imagem nova, adiciona uma tag e pronto. Problema resolvido, certo?

Uma outra possibilidade é utilizar o Packer para gerar a imagem. Ele, diferente do Docker, não utilizará um arquivo Dockerfile, mas gerará a nova imagem provisionando um container, fazendo as coisas que tem que fazer lá dentro e quando tudo estiver pronto, ele executará um commit, criando assim uma nova imagem.

Se você optou pelo segundo método, pode ter se frustrado no momento de executar um container baseado na segunda imagem. Um serviço não subiu, o container não fez o que ele deveria ter feito, e você ficou com uma cara de "ué".

O motivo disso é que, diferentemente de um Dockerfile, o Packer não faz com que a nova imagem herde o ENTRYPOINT e o CMD da imagem base. Para contornar esse comportamento do Packer, escreva o seu arquivo de template da seguinte forma:

source "docker" "my-jenkins" {
    image = "jenkins/jenkins:lts-jdk11"
    commit = true
    run_command = ["-d", "-i", "-t", "--", "{{.Image}}"]
    changes = [
        "ENTRYPOINT /sbin/tini -- /usr/local/bin/jenkins.sh",
        "CMD bash"
    ]
    exec_user = "root"
}

build {
    sources = [
        "source.docker.my-jenkins"
    ]
    provisioner "shell" {
        inline = [
            "apt update",
            "apt install -y htop"
        ]
    }
    post-processor "docker-tag" {
        repository = "my-jenkins"
    }
}

Neste exemplo, nós estamos criando uma nova imagem do Jenkins com o pacote htop, utilizando a imagem base do mesmo. Para isso, fizemos o seguinte:

run_command: opções utilizados pelo Packer ao inicializar o container que gerará a imagem. Por padrão, há uma opção --entrypoint=/bin/sh, que nós estamos removendo;
changes: esta é a parte mais importante. Precisamos restaurar o ENTRYPOINT e o CMD originais da imagem, e para isso, vá até a página da mesma no Docker Hub e verifique-os consultando o Dockerfile da mesma;
exec_user: o usuário utilizado (UID) para executar o provisioner da imagem. Um provisioner é a parte do template responsável pela instalação dos pacotes, arquivos, etc. Como estamos instalando um novo pacote através do apt, precisamos que esse comando seja executado como root;

Ao final, estamos colocando a tag my-jenkins na imagem por meio do post-processor docker-tag.

Conclusão

Embora muitas pessoas ainda utilizem Dockerfiles para a construção de suas imagens - e não há nada de errado nisso - o Packer é uma opção interessante e que pode nos auxiliar a fazer o mesmo. O intuito deste artigo não é o apresentar como tal, mas sim resolver um problema comum que provavelmente afetará as pessoas que escolheram tal caminho.

Dica rápida: Criando commits vazios no Git

Stefano Martins — Mon, 21 Jun 2021 22:34:53 +0000

Esta é uma dica ótima para todo mundo que vive criando arquivos com "este é um teste", "este é outro teste", "mais um teste", "teste número X" em seu repositório com o intuito de disparar triggers e webhooks dos servidores para seus jobs e pipelines.

Ao invés de fazer isso, apenas digite utilize a opção --allow-empty ao seu commit. Assim:

$ git commit --allow-empty -m "Disparando trigger"

Após isso, realize o seu push normalmente para o origin e pronto.

Talking a little bit about Ansible's loops

Stefano Martins — Mon, 19 Apr 2021 02:53:06 +0000

Introduction

For most people working with technology, writing general loops has become something so natural that you can do in the time between waking up with an hangover, asking yourself "What the f*** happened?", a shower, a bottle of water and a cup of coffee. As a teacher, I know that loops are a control structure that can make programming newcomers bang their heads on the door (great The Cure album, by the way).

In this article, we're gonna talk a little bit about Ansible's loops, their old syntax with with_items and the new one. But first, an important message from our sponsor Balas Juquinha remembering us all that:

Ansible's not a programming language

As we discover and get along with new technology, some of us tend to converge the solutions of all problems into it, such as:

Managing hundreds (even thousands) of servers
Deploying applications
Checking out if Elvis is still alive
Relationship problems
Overthrow your neo-fascist government

When people discover Ansible, they're usually trying to replace several Bash and/or Python scripts with screaming "FOR THE LOVE OF OXÓSSI, DON'T RUN IT TWICE!" preceded by "#" on top and code quality that would let any SonarQube crying under the shower in fetal position listening to Tim Maia's "Ela Partiu". So they become emotional ending with a nice folder structure, organization, readable YAML code and a tool that not only gets the job done, but also gives them a workflow. Pretty neat, right?

Not always.

Some people are addicted to shell-scripts, so they try to Anshell-script, or Ansibell-script. Here's an example of how to create 10 empty files:



--- 
- hosts: localhost
  connection: local
  tasks:
    - name: Making Stefano cry
      shell: for i in {1..10}; do touch $i; done;
      args:
        executable: /bin/bash

The problem with the above form is that it isn't idempotent, because there's no checking of the files are already present in the filesystem. Let's rewrite that, shall we?

Solving it with the Ansible way:



--- 
- hosts: localhost
  connection: local
  tasks:
    - name: Making Stefano happy (the old way)
      copy:
        content: ""
        dest: "{{ item }}"
        force: no
        mode: 0640
      with_sequence: start=1 end=10

With the 2.5 version, Ansible introduced the new loop syntax. The main difference between both syntaxes is that with_* is more explicit, while loop relies on Jinja2 lookups to work. Still not to worry, Ansible's team won't deprecate with_* in the near future, but it's a good idea to learn the new syntax. Here's the above playbook with it:



--- 
- hosts: localhost
  connection: local
  tasks:
    - name: Making Stefano happy (the new way)
      copy:
        content: ""
        dest: "{{ item|format }}"
        force: no
        mode: 0640
      loop: "{{ range(1, 11)|list }}"

Is it too late to talk about the basics?

I know, I should've started with it. Sorry people...



--- 
- hosts: localhost
  connection: local
  tasks:
    - name: Installing several packages (don't do it)
      apt:
        name: "{{ item }}"
        state: present
      become: yes
      with_items: 
        - glances
        - htop
        - tree

Note: this was just for example purposes. The apt module recommends that you use a list in the name argument instead of loops.

This is the simplest, most common loop in Ansible. Ansible comes with an iterator called item. And this is the newer form:



--- 
- hosts: localhost
  connection: local
  tasks:
    - name: Installing several packages (don't do it)
      apt:
        name: "{{ item }}"
        state: present
      become: yes
      loop: 
        - glances
        - htop
        - tree

Not much of a difference, huh?

Hashes and dictionaries

You can also work with hashes and dictionaries, as shown below:



--- 
- hosts: localhost
  connection: local
  tasks:
    - name: (Hashes example) 
      debug:
        msg: "My name is {{ item.name }} and my surname is {{ item.surname }}"
      loop:
        - { name: "Stefano", surname: "Martins" }

    - name: (Dictionaries example) Some Tim Maia albums
      debug:
        msg: "Year: {{ item.key }} - Album: {{ item.value }}"
      loop: "{{ tim_maia_albums | dict2items }}"
      vars:
        tim_maia_albums:
          1970: Tim Maia
          1974: Racional Volume 1
          1975: Racional Volume 2

Nested loops

Let's suppose you wanna create this folder structure:



.
├── bebeto
│   ├── di_melo
│   ├── joao_do_vale
│   ├── jorge_ben
│   └── tim
├── joao
│   ├── di_melo
│   ├── joao_do_vale
│   ├── jorge_ben
│   └── tim
└── jose
    ├── di_melo
    ├── joao_do_vale
    ├── jorge_ben
    └── tim

Using Bash and nested loops, you usually would create it with:



for i in bebeto joao jose; do
    mkdir $i;
    for j in di_melo joao_do_vale jorge_ben tim; do
        mkdir ${i}/${j};
    done;
done;

Many people don't know, but you can also have nested loops in Ansible. Check it out:



--- 
- hosts: localhost
  connection: local
  tasks:
    - name: Creating directories
      file:
        mode: 0755
        path: "{{ ansible_user }}/teste/{{ item[0] }}/{{ item[1] }}"
        recurse: yes
        state: directory
      loop: "{{ ['bebeto', 'joao', 'jose'] | product(['di_melo', 'joao_do_vale', 'jorge_ben', 'tim']) | list }}"

Subelements

Now let's suppose we want to create a different structure, where each user has a different subset of folders. For instance:



.
├── bebeto
│   ├── di_melo
│   └── joao_do_vale
├── joao
│   ├── di_melo
│   └── tim
└── jose
    └── tim

To achieve that, we're gonna have to declare a dictionary with lists in it, ending with a playbook similar to this:



--- 

- hosts: localhost

  connection: local

  tasks:

    - name: Creating directories

      file:

        mode: 0755

        path: "{{ ansible_user }}/teste/{{ item.0.user }}/{{ item.1 }}"

        recurse: yes

        state: directory

      vars:

        folders:

          - user: bebeto

            subfolders:

              - di_melo

              - joao_do_vale

          - user: joao

            subfolders:

              - di_melo

              - tim

          - user: jose

            subfolders:

              - tim

      loop: "{{ folders | subelements('subfolders', 'skip_missing=True') }}"

Conclusion

In this not-so-brief article, we talked a little bit about Ansible loops, why fighting with our emotions to not use Ansible as shell-scripting, and finally about some brief code and different use cases that hopefully can improve your playbooks.

Ansible's documentation is one of the best ones I ever used, with plenty examples.

Hope you all enjoyed.

Abraços!

Como continuar a execução de um build do Jenkins quando um stage falha

Stefano Martins — Tue, 13 Apr 2021 17:01:10 +0000

A grande maioria das pessoas irá trabalhar com esteiras relativamente lineares do Jenkins - ainda que estas esteiras chamem outras esteiras, que chamem outras esteiras, e outras, e assim por diante, criando verdadeiros monstros dos espaguetis voadores.

Entretanto há uma coisa que Jenkins - seja por design ou por qualquer outro motivo inexplicável - simplesmente não faz bem: manter controle sobre os status dos stages durante a execução do build. Uma das consequências disso é o fato de que o comportamento padrão do Jenkins é falhar uma esteira quando qualquer um dos seus stages falha. E cabe a você, a pessoa que está desenvolvendo a esteira, cuidar disso.

Durante este post, irei abordar alguns cenários comuns e algumas soluções possíveis para os mesmos.

Primeiro cenário: continuar um build mesmo quando um stage falha

Esta é uma pergunta muito comum na stack mais famosa do mundo. Imagine que você possui um stage que pode falhar, mas que não necessariamente impedirá a execução da esteira como um todo. Se você ama Java, você simplesmente irá adorar o quê vem a seguir.

Para o cenário, iremos trabalhar com a seguinte pipeline:



pipeline {
    agent any

    stages {
        stage('Primeiro stage') {
            steps {
                script {
                    git credentialsId: 'Bitbucket', url: 'https://bitbucket.org/stefano/bla.git' 
                }
            }
        }

        stage('Segundo stage') {
            steps {
                script {
                    print('Ooopsie, nunca vou rodar! :(')
                }
            }
        }
    }
}

Esta pipeline intencionalmente irá falhar, uma vez que o repositório especificado na linha 8 não existe. Na apresentação visual da pipeline, teremos algo parecido com isto:

Primeira solução: utilizar um bloco `try {} catch() {}`

Podemos utilizar um bloco try {} catch() {} ao redor do trecho passível de erro.



pipeline {
    agent any

    stages {
        stage('Primeiro stage') {
            steps {
                script {
                    try {
                        git credentialsId: 'Bitbucket', url: 'https://bitbucket.org/stefano/bla.git' 
                    }
                    catch(Exception e) {
                        print("${e}")
                    }
                }
            }
        }

        stage('Segundo stage') {
            steps {
                script {
                    print('Ooopsie, nunca vou rodar! :(')
                    print('Opa pera! :)')
                }
            }
        }
    }
}

E a apresentação da pipeline:

Como pode-se observar, ambos os stages são executados, contudo o primeiro é apresentado com sucesso, ainda que o comando tenha apresentado falha. Isso é uma questão de semântica: houve um erro em tempo de execução da pipeline e houve uma tratativa quanto a ele, logo, há o entendimento de que está tudo bem e que o stage deve ser marcado como SUCCESS.

Segunda solução: Quando queremos marcar o stage como FAILED

Caso desejemos marcar aquele stage como FAILED, devemos utilizar um bloco catchError(), podendo utilizá-lo juntamente com um bloco try {} catch() {} ou sozinho. O quê o catchError() faz é pegar o resultado de um step (ou steps) que estão dentro do bloco e caso algum destes termine em erro, ele setará os status do stage ou o build conforme o seu desejo, normalmente sendo como SUCCESS ou FAILURE. Abaixo dois exemplos, um não aninhado e o outro com um bloco try {} catch() {}, assim como suas respectivas execuções:



pipeline {
    agent any

    stages {
        stage('Primeiro stage') {
            steps {
                script {
                    catchError(buildResult: 'SUCCESS', stageResult: 'FAILURE') {
                        git credentialsId: 'Bitbucket', url: 'https://bitbucket.org/stefano/bla.git' 
                    }
                }
            }
        }

        stage('Segundo stage') {
            steps {
                script {
                    print('Ooopsie, nunca vou rodar! :(')
                    print('Opa, vou sim! :)')
                }
            }
        }
    }
}



pipeline {
    agent any

    stages {
        stage('Primeiro stage') {
            steps {
                script {
                    try {
                        sh 'cat /tmp'
                    }
                    catch(Exception e) {
                        print("${e}")
                        catchError(buildResult: 'SUCCESS', stageResult: 'FAILURE') {
                            sh 'exit 1'
                        }
                    }
                }
            }
        }

        stage('Segundo stage') {
            steps {
                script {
                    print('Ooopsie, nunca vou rodar! :(')
                    print('Opa, vou sim!')
                }
            }
        }
    }
}

Segundo cenário: Execução de um stage de forma condicional

Imagine que você deseja que um stage seja executado condicionalmente, dependendo do status do anterior. A primeira solução que nos vêm à mente é trabalhar com blocos when {}. Infelizmente, ela não é viável, pois os mesmos são analisados no começo da execução da pipeline.

A segunda solução é criar algumas variáveis de ambiente em bloco environment {} e analisá-las de um bloco para o outro, o quê também não daria certo, pois não conseguimos trocar seus valores.

Chegamos então à uma solução possível que é: Arquivos texto. Abaixo um exemplo:



pipeline {
    agent any

    stages {
        stage("stage1") {
            steps {
                script {
                    try {
                        sh 'cat /tmp'
                        writeFile encoding: 'utf-8', file: 'stageStatus', text: 'SUCCESS'
                    }
                    catch(Exception e) {
                        writeFile encoding: 'utf-8', file: 'stageStatus', text: 'FAILED'
                        print("Ooopsie!")
                        catchError(buildResult: 'SUCCESS', stageResult: 'FAILURE') {
                            sh 'exit 1'
                        }
                    }
                }
            }
        }

        stage("stage2") {
            steps {
                script {
                    def previousStageStatus = readFile encoding: 'utf-8', file: 'stageStatus'
                    if (previousStageStatus == 'FAILED') {
                        print('The previous stage failed')
                    }
                }
            }
        }
    }
}

Nele, estamos utilizando as funções writeFile() e readFile() para respectivamente escrever e ler o nosso arquivo texto, que conterá o status do primeiro stage e, caso seja FAILURE, o corpo do segundo stage será executado.

O único problema desta solução - que não é grande, pelo menos da minha perspectiva - é que não importa o quê aconteça, o segundo stage sempre será executado, ainda que ele não faça nada.

Pipeline quando o stage é disparado

Pipeline quando o stage não é disparado

Bom pessoal, por hoje é só. Espero que tenham gostado!

Abraços!

A different approach working with Ansible variables

Stefano Martins — Mon, 12 Apr 2021 20:15:47 +0000

When using folders to organize Ansible projects, usually we use the host_vars subfolder to store the variables that belong to hosts declared in our inventory files, ending with something like this in our hands:

.
├── group_vars
├── hosts
├── host_vars
│   └── host-01.yml
├── roles
│   └── webservers
│       ├── files
│       ├── tasks
│       │   └── main.yml
│       └── templates
└── webservers.yml

Here, we're using the hosts file as our inventory, which has only one host, host-01, and storing all its variables on the host_vars/host-01.yml file.

For many people, this approach will work just great, with absolutely nothing wrong with it. But as our infrastructure grows, so does the number of variables, and manage it can become a little bit cumbersome, with two major problems:

Over time all variables from all subjects (different roles, for instance) are stored in the same place, so it can become quite messy.

The second problem is that when you're using Ansible Vault to encrypt files that contains sensitive information, like passwords, you have a workflow similar to this:

Run git pull
Edit your file with ansible-vault edit ${file}
Commit your changes
Run git push

But in this approach, you have to that even you're not changing anything sensitive-related, which is a bummer.

To solve those two problems, what you can do instead is create a folder inside host_vars with the name of your host, and inside of it YAML files containing your variables. Ansible automatically will concatenate them when called. Then, use Vault just for the files that have sensitive information (here, for instance, we're assuming that for the host_vars/host-01/password.yml file). Here's an example:

.
├── group_vars
├── hosts
├── host_vars
│   └── host-01
│       ├── main.yml
│       └── passwords.yml
├── roles
│   └── webservers
│       ├── files
│       ├── tasks
│       │   └── main.yml
│       └── templates
└── webservers.yml

You can have as many YAML files you want inside the folder, and by the way, you don't have to name "main.yml" any of them.

Abraços!

DEV Community: Stefano Martins

Configurando o Terraform para funcionar corretamente com o LocalStack

tl;dr

Instalando o LocalStack

Instalando o AWSP

Iniciando o LocalStack

Configurando o seu projeto Terraform

Jenkins: Criando campos dinâmicos a partir de chamadas à APIs

Troubleshooting

Referências

Subindo um cluster Kubernetes no AWS EKS com eksctl

Instalação

Configuração de uma conta AWS

Criação do cluster

Instalação do Helm

Instalação de add-ons

Metrics Server

Prometheus

ExternalDNS

cert-manager

NGINX Ingress Controller

Auto Scaling Group

Subindo uma aplicação

Conclusão

Referências

Criação de múltiplos objetos utilizando locals e loops

Armazenando dados sensíveis em código Terraform utilizando KMS

Referências

Recarregando o inventário do Ansible durante a execução

Introdução

Opção A: utilize o módulo add_host

Opção B: utilize a metatask refresh_inventory

Conclusão

Mantendo o ENTRYPOINT e o CMD originais de uma imagem Docker gerada através do Packer

Conclusão

Dica rápida: Criando commits vazios no Git

Talking a little bit about Ansible's loops

Introduction

Ansible's not a programming language

Is it too late to talk about the basics?

Hashes and dictionaries

Nested loops

Subelements

Conclusion

Como continuar a execução de um build do Jenkins quando um stage falha

Primeiro cenário: continuar um build mesmo quando um stage falha

Primeira solução: utilizar um bloco try {} catch() {}

Segunda solução: Quando queremos marcar o stage como FAILED

Segundo cenário: Execução de um stage de forma condicional

A different approach working with Ansible variables

Primeira solução: utilizar um bloco `try {} catch() {}`