Forem: Pedro H. Santos

Raspberry Pi como runner do GitHub Action

Pedro H. Santos — Mon, 13 Mar 2023 22:40:37 +0000

Raspberry Pi 🖱️ + GitHubActions 🤖

Estamos em 2023, o carnaval já passou e agora estou retomando meus estudos e laboratórios. Há alguns eu tive a ideia de utilizar o meu "Home Server" (foto abaixo) que no caso é um Raspberry Pi 4 como um Runner para executar processos de CI/CD no GitHub Actions.

Então neste artigo a ideia é exemplificar como configurar um self-hosted runner para utilizar em seus processos de CI/CD.

Eu utilizei como base para esse hands-on a documentação do oficial do GitHub, lá você irá encontrar todos os detalhes sobre sistemas operacionais suportados, arquitetura e mais detalhes das configurações possíveis.

Instalação e configuração do runner 🛠

Vamos lá! Você pode adicionar self hosted runners a nível de organização se utilizar o GitHub Corporativo. Assim todos os repositórios dentro daquela conta poderão utilizar os servidores configurados, ou você pode configurar a nível de repositório, que é como irei seguir por aqui.

O primeiro passo da configuração é ir no seu repositório em: Settings -> Actions -> Runners e clica no botão "New self-hosted runner", nesse momento você irá selecionar a arquitetura do servidor e o sistemas operacional.

Será exibido um passo-a-passo que precisar ser feito no servidor que será o runner.

Agora eu vou conectar no meu Raspberry Pi e executar o passo-a-passo informado para fazer instalação.

Download

# Create a folder
$ mkdir actions-runner && cd actions-runner

# Download the latest runner package
$ curl -o actions-runner-linux-arm64-2.302.1.tar.gz -L https://github.com/actions/runner/releases/download/v2.302.1/actions-runner-linux-arm64-2.302.1.tar.gz

# Extract the installer
$ tar xzf ./actions-runner-linux-arm64-2.302.1.tar.gz

Configure

# Create the runner and start the configuration experience
$ ./config.sh --url https://github.com/santospedroh/raspberry-pi-runner --token XXXXXXXXXXXXXXXXXXXXXX 
# Last step, run it!
$ ./run.sh

Após esses passos de instalação será exibida uma tela no seu terminal para que seja feita as configurações do self-hosted runner onde será solicitado o grupo do runner, nome do runner e diretório de working.

Após a instalação e configuração finalizadas com sucesso o runner precisar ser iniciado utilizar o script run: $ ./run.sh.

Se tudo deu certo, o seu repositório já irá exibir o runner como Idle quer dizer que está ativo aguardando um Job para executar. 🤓

Testando um hello world 🌎

Na branch main do repositório eu deixei salvo um workflow que vai executar no Raspberry Pi que acabamos de configura como self-runner.

Abaixo dos detalhes do workflow:

name: workflow-raspberry

on:
  push:
    branches: [ "main" ]

jobs:
  hello-world:
    runs-on: self-hosted
    steps:
      - uses: actions/checkout@v3
      - name: Run a one-line script
        run: echo Hello, world in runner raspberry-pi

No comando run do workflow além da mensagem de hello world vou adicionar o comando uname -a para exibir as informações do meu Raspberry Pi, assim que o commit for feito a action será disparada para execução. 🚀

Exemplo prático 💡

Já que agora já temos o runner instalado e configurado no Raspberry Pi para executar os jobs do GitHub Actions tive a ideia de fazer o deploy de um programinha em python para piscar um led utilizando as portas GPIO do Raspberry Pi.

Segue abaixo o esquema eletrônico com as conexões na GPIO:

Segue abaixo o código fonte que vou utilizar na branch ´feature/led´ é um código bem simples que faz o led piscar 10 vezes.

import RPi.GPIO as GPIO
import time

pinoLed = 12
cont = 10

GPIO.setwarnings(False)
GPIO.setmode(GPIO.BOARD)
GPIO.setup(12, GPIO.OUT)

print("---------- Inicio ----------")
for i in range(cont):
    GPIO.output(pinoLed, GPIO.HIGH)
    time.sleep(1)
    GPIO.output(pinoLed, GPIO.LOW)
    time.sleep(1)
    i = i+1
    print("Piscou... " + str(i) + " de " + str(cont) + "")
print("------------ Fim -----------")
GPIO.cleanup()

Também vamos precisar alterar o workflow para executar o código python dentro do runner Raspberry:

name: workflow-raspberry

on:
  push:
    branches: [ "main" ]

jobs:
  hello-world:
    runs-on: self-hosted
    steps:
      - uses: actions/checkout@v3
      - name: Run a one-line script
        run: echo Hello, world in runner raspberry-pi && uname -a
  ## Novo Job pisca led 
  led:
    needs: hello-world
    runs-on: self-hosted
    steps:
      - name: Run script python blink led 10x
        run: python3 app/led.py

Veja no YouTube como ficou o resultado final com o led piscando no Raspberry 🏮

Repositório GitHub - raspberry-pi-runner

Descobrindo os custos da sua infraestrutura utilizando Infracost

Pedro H. Santos — Thu, 07 Jul 2022 03:50:28 +0000

Introdução

Um dos maiores problemas na jornada de uma empresa quando decide migrar seu ambiente e aplicações para a Cloud é: Quanto vai custar? 💸

Temos algumas formas de calcular e ter uma previsão dos gastos em nuvem utilizado as calculadoras dos próprios providers, porém, na minha visão a forma mais interessante de ter uma previsão de custos é utilizando o infracost.io.

O que é o Infracost? 💰

O Infracost é uma ferramenta utilizada junto com o seu Terraform, ou seja, você terá uma previsão de quanto a sua infraestrutura vai custar assim que executar o terraform plan no seu projeto.

Alguns benefícios ao utilizar o Infracost:

Maior conscientização sobre custos: Os engenheiros recebem antecipadamente o custo estimado da infraestrutura, antes que quaisquer recursos sejam lançados ou alterados. Eles podem fazer escolhas econômicas enquanto mantêm a velocidade de entrega de software.
Visibilidade de custo para equipes de plataforma: O impacto de custo de módulos compartilhados que são usados em muitas equipes pode ser avaliado pelas equipes de plataforma.
Retrabalho de infraestrutura reduzido: O Infracost integrado a sua pipeline CI/CD fornece as informações necessárias para tomar as decisões corretas. Os orçamentos não são quebrados e menos retrabalho é necessário para consertar a infraestrutura para alinhar com os orçamentos após o lançamento.
Orçamentos e custos alinhados: Se as mudanças na infraestrutura ou o lançamento de um novo produto quebrarem os orçamentos, a comunicação pode acontecer antecipadamente, não após a chegada da fatura.

Mão na massa 💻

Neste laboratório vamos utilizar o projeto que criamos no artigo: Pipeline IaC com Terraform e GitHub Actions. Se você não acompanhou o post anterior faça o clone do projeto: git clone https://github.com/santospedroh/iac-pipeline.git.

Vamos alterar o workflow do GitHub Action para adicionar os recursos do Infracost, assim vamos poder analisar quando o terraform plan for executado quais os custos da nossa infraestrutura.

Instalação e configuração do CLI 🛠

O Infracost tem uma documentação bem completa e simples com Get started super legal. No meu caso estou utilizando um MacOS e vou fazer a instalação utilizando o gerenciador de pacotes Homebrew.

➜  iac-pipeline git:(main) brew install infracost

Após a instalação você precisa criar uma API KEY para o Infracost gerar os custos estimados da infraestrutura, será necessário executar o comando infracost register e informa seu nome e e-mail para gerar a API KEY.

➜  iac-pipeline git:(main) infracost register
Please enter your name and email address to get an API key.
See our FAQ (https://www.infracost.io/docs/faq) for more details.
Name: Pedro Santos
Email: santos.pedroh@gmail.com

Thanks Pedro Santos! Your API key is: <SUA_API_KEY_VAI_APARECER_AQUI>
This was saved to /Users/santospedroh/.config/infracost/credentials.yml

Follow https://infracost.io/docs to use Infracost.

Agora já podemos executar o Infracost e verificar a estimativa de custos do projeto Terraform utilizando o comando infracost breakdown --path . para gerar a estimativa de custos direto no terminal.

➜  iac-pipeline git:(main) ✗ infracost breakdown --path .
Evaluating Terraform directory at .
  ✔ Downloading Terraform modules 
  ✔ Evaluating Terraform directory 
  ✔ Retrieving cloud prices to calculate costs 

Project: santospedroh/iac-pipeline/.

 Name                                                 Monthly Qty  Unit   Monthly Cost 

 module.ec2_instance.aws_instance.this[0]                                              
 ├─ Instance usage (Linux/UNIX, on-demand, t3.micro)          730  hours         $7.59 
 └─ root_block_device                                                                  
    └─ Storage (general purpose SSD, gp2)                       8  GB            $0.80 

 OVERALL TOTAL                                                                   $8.39 
──────────────────────────────────
10 cloud resources were detected:
∙ 1 was estimated, it includes usage-based costs, see https://infracost.io/usage-file
∙ 9 were free, rerun with --show-skipped to see details

Também podemos alterar o formato o qual as informações de custos são exibidas. Para gerar um arquivo html por exemplo, utilize o comando infracost breakdown --path . --format html > infracost.html um arquivo html vai ser criado.

Mais detalhes sobre os formatos pode ser verificados na documentação.

➜  iac-pipeline git:(main) infracost breakdown --path . --format html > infracost.html
Evaluating Terraform directory at .
  ✔ Downloading Terraform modules 
  ✔ Evaluating Terraform directory 
  ✔ Retrieving cloud prices to calculate costs

➜  iac-pipeline git:(main) ✗ ls -ltr *.html
-rw-r--r--  1 santospedroh  staff  16269  6 Jul 16:09 infracost.html

Arquivo HTML com a previsão de custos do projeto.

Podemos ver que o custo da infraestrutura atual utilizando uma instância t3.micro é de $8.39

Integração com o GitHub Action 🤖

Agora chegou o momento de integrarmos o Infracost com o nosso workflow no GitHub Action para recebemos os valores estimados direto nas Pull Request's que forem criadas. O primeiro passo para a integração é criar uma secret da sua API KEY do Infracost no repositório do projeto, assim como fizemos no artigo anterior.

Vamos utilizar o Infracost Actions oficial como referência para editar o nosso workflow plan.yml que já temos em nosso projeto.

name: "Plan"

on:
  pull_request:

env:
  AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
  AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

jobs:
  terraform:
    name: "Terraform"
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v1
        with:
          terraform_version: 0.15.5

      - name: Terraform Init
        id: init
        run: terraform init

      - name: Terraform Validate
        id: validate
        run: terraform validate -no-color

       # Aqui vamos gerar o terraform plan em arquivo para passar para o infracost
      - name: Terraform Plan
        id: plan
        run: terraform plan -out tfplan.binary

      - name: Terraform show
        id: show
        run: terraform show -json tfplan.binary > plan.json
        working-directory: ${{ env.working-directory }}

      - uses: actions/github-script@v6
        if: github.event_name == 'pull_request'
        env:
          PLAN: "terraform\n${{ steps.plan.outputs.stdout }}"
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          script: |
            const output = `#### Terraform Format and Style 🖌\`${{ steps.fmt.outcome }}\`
            #### Terraform Initialization ⚙️\`${{ steps.init.outcome }}\`
            #### Terraform Validation 🤖\`${{ steps.validate.outcome }}\`
            #### Terraform Plan 📖\`${{ steps.plan.outcome }}\`
            <details><summary>Show Plan</summary>
            \`\`\`\n
            ${process.env.PLAN}
            \`\`\`
            </details>
            *Pushed by: @${{ github.actor }}, Action: \`${{ github.event_name }}\`*`;
            github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: output
            })
      - name: Terraform Plan Status
        if: steps.plan.outcome == 'failure'
        run: exit 1

      # Chamar a action do infracost passando a nossa secret
      - name: Setup Infracost
        uses: infracost/actions/setup@v1
        with:
          api-key: ${{ secrets.INFRACOST_API_KEY }}

      # Passar o arquivo plan.json para o infracost gerar os custos
      - name: Generate Infracost JSON
        run: infracost breakdown --path plan.json --format json --out-file /tmp/infracost.json

      - name: Infracost Actions
        uses: infracost/actions/comment@v1
        with:
          path: /tmp/infracost.json
          behavior: update

Enviando um Pull Request para alteração da infraestrutura 📈

Agora vamos simular um aumento da capacidade computacional com 2 instâncias EC2, atualmente estamos utilizando apenas uma instância do tipo t3.micro que tem 2 vCPU e 1GB de memória RAM e vamos para 2 instâncias do tipo m5.large que tem 2 vCPU e 4GB de memória RAM.

Vamos criar uma nova branch no projeto com o nome infracost para fazer as alterações e enviar o Pull Request.

➜  iac-pipeline git:(main) git checkout -b infracost
Switched to a new branch 'infracost'
➜  iac-pipeline git:(infracost)

Atualizar o arquivo main.ft com as novas instâncias do tipo m5.large

module "ec2_instance" {
  source = "terraform-aws-modules/ec2-instance/aws"

  for_each = toset(["server-01", "server-02"]) # Duas instâncias ec2

  name                   = "snake-game-${each.key}"
  ami                    = "ami-0cff7528ff583bf9a"
  instance_type          = "m5.large" # Tipo das instâncias m5.large
  vpc_security_group_ids = [aws_security_group.game_snake_sg.id]
  subnet_id              = module.vpc.public_subnets[0]
  user_data              = file("userdata.sh")
  tags = {
    Name = "snake-game-ec2"
    Terraform = "true"
    Environment = "prod"
    Team = "gamer-development"
    Application = "snake-game"
    Language = "javascript"
  }
}

Vamos fazer o commit e o push e criar o Pull Request no GitHub

➜  iac-pipeline git:(infracost)  git add .
➜  iac-pipeline git:(infracost)  git commit -m "Infra com 2 instancias do tipo m5.large"
[infracost 1d900e7] Infra com 2 instancias do tipo m5.large
 4 files changed, 28 insertions(+), 10 deletions(-)
 create mode 100644 .terraform.lock.hcl
➜  iac-pipeline git:(infracost) git push origin infracost                              
Enumerating objects: 14, done.
Counting objects: 100% (14/14), done.
Delta compression using up to 12 threads
Compressing objects: 100% (7/7), done.
Writing objects: 100% (8/8), 1.59 KiB | 1.59 MiB/s, done.
Total 8 (delta 4), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (4/4), completed with 4 local objects.
To github.com:santospedroh/iac-pipeline.git
   8e2c8e8..1d900e7  infracost -> infracost

Após a execução do workflow plan podemos ver nos comentários do Pull Request a estimativa de custo do Infracost.

O valor da nova infra ficou estimado em $142

Conclusão

Utilizando o Infracost dificilmente você vai ter surpresas ao receber a fatura do seu cloud provider, podemos saber a estimativa de custo de cada projeto Terraform, podemos avaliar e discutir os valores em cada Pull Request enviada podendo aprovar ou não o Merge para a branch principal do projeto antes de qualquer mudança ser aplicada.

Todos esses benefícios ajudam bastante no dia a dia de um time que utiliza as práticas DevOps e FinOps.

Espero que tenha gostado desse hands-on, aproveitem bem o Infracost, até a próxima! ✌🏼

Pipeline IaC com Terraform e GitHub Actions

Pedro H. Santos — Wed, 22 Jun 2022 20:28:14 +0000

Introdução

Com a difusão da cultura DevOps nos últimos anos algumas práticas para entrega de novos produtos ou novas funcionalidades no ambiente produtivo mudaram bastante. Nesse artigo vou exemplificar em um pequeno laboratório um processo de pipeline CD/CD para entrega de uma infraestrutura utilizando Terraform, GitHub Actions e AWS como cloud pública.

Terraform 🌎

Terraform é uma ferramenta de infraestrutura como código (IaC) que permite criarmos recursos em clouds públicas ou privadas utilizando uma linguagem simples e declarativa, podendo assim reutilizar e versionar o código da sua infraestrutura assim como é feito com a aplicação. Você pode então usar um workflow consistente para provisionar e gerenciar toda a sua infraestrutura ao longo de seu ciclo de vida.

GitHub Actions 🤖

GitHub Actions é uma plataforma de integração contínua e entrega contínua (CI/CD) que permite automatizar sua compilação de código, testar e entregar de forma simples e rápida.

Mão na massa! 💻

A ideia do laboratório é provisionar uma instância EC2 com ip público executando um webserver nginx rodando o famoso jogo da cobrinha 🐍.

Preparando o GitHub para acessar a AWS com o Terraform

A primeira etapa que precisa ser feita é configura as secrets AWS_ACCESS_KEY_ID e AWS_SECRET_ACCESS_KEY para que o GitHub Actions consiga acessar esses valores durante a execução do workflow e ter acesso a sua conta da AWS.

Dentro do repositório vá em: Settings -> Secrets -> Actions e adicionei as chaves de acesso da AWS.

Criando os workflows do GitHub Actions

Para termos as actions do GitHub rodando de acordo com cada evento precisamos criar o diretório .github/workflows na raiz do projeto. Neste caso vamos criar 3 arquivos de workflow, um para o executar o terraform plan quando for criado um pull request, outro para executar o terraform apply quando o merge for feito na branch main e o último e não menos importante para executar o terraform destroy, esse será executado manualmente quando for necessário destruir a infraestrutura.

Eu utilizei como base para a criação dos workflows a action oficial da HashiCorp - Setup Terraform

💡Dica: No site HashiCorp Learn temos um tutorial de como criar uma pipeline com GitHub Actions utilizando Terraform Cloud.

plan.yml

name: "Plan"

on:
  pull_request:

env:
  AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
  AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

jobs:
  terraform:
    name: "Terraform"
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v1
        with:
          terraform_version: 0.15.5

      - name: Terraform Init
        id: init
        run: terraform init

      - name: Terraform Validate
        id: validate
        run: terraform validate -no-color

      - name: Terraform Plan
        id: plan
        run: terraform plan -no-color -input=false
        continue-on-error: true

      - uses: actions/github-script@v6
        if: github.event_name == 'pull_request'
        env:
          PLAN: "terraform\n${{ steps.plan.outputs.stdout }}"
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          script: |
            const output = `#### Terraform Format and Style 🖌\`${{ steps.fmt.outcome }}\`
            #### Terraform Initialization ⚙️\`${{ steps.init.outcome }}\`
            #### Terraform Validation 🤖\`${{ steps.validate.outcome }}\`
            #### Terraform Plan 📖\`${{ steps.plan.outcome }}\`
            <details><summary>Show Plan</summary>
            \`\`\`\n
            ${process.env.PLAN}
            \`\`\`
            </details>
            *Pushed by: @${{ github.actor }}, Action: \`${{ github.event_name }}\`*`;
            github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: output
            })
      - name: Terraform Plan Status
        if: steps.plan.outcome == 'failure'
        run: exit 1

      - name: Terraform Apply
        if: github.ref == 'refs/heads/main' && github.event_name == 'push'
        run: terraform apply -auto-approve -input=false

apply.yml

name: "Apply"

on:
  push:
    branches:
      - main

env:
  AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
  AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

jobs:
  terraform:
    name: "Terraform"
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v1
        with:
          terraform_version: 0.15.5

      - name: Terraform Init
        id: init
        run: terraform init

      - name: Terraform Validate
        id: validate
        run: terraform validate -no-color

      - name: Terraform Plan
        id: plan
        run: terraform plan -no-color -input=false
        continue-on-error: true

      - uses: actions/github-script@v6
        if: github.event_name == 'pull_request'
        env:
          PLAN: "terraform\n${{ steps.plan.outputs.stdout }}"
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          script: |
            const output = `#### Terraform Format and Style 🖌\`${{ steps.fmt.outcome }}\`
            #### Terraform Initialization ⚙️\`${{ steps.init.outcome }}\`
            #### Terraform Validation 🤖\`${{ steps.validate.outcome }}\`
            #### Terraform Plan 📖\`${{ steps.plan.outcome }}\`
            <details><summary>Show Plan</summary>
            \`\`\`\n
            ${process.env.PLAN}
            \`\`\`
            </details>
            *Pushed by: @${{ github.actor }}, Action: \`${{ github.event_name }}\`*`;
            github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: output
            })
      - name: Terraform Plan Status
        if: steps.plan.outcome == 'failure'
        run: exit 1

      - name: Terraform Apply
        if: github.ref == 'refs/heads/main' && github.event_name == 'push'
        run: terraform apply -auto-approve -input=false

destroy.yml

name: "Destroy"

on:
  workflow_dispatch:

env:
  AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
  AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

jobs:
  destroy:
    name: "terraform destroy"
    runs-on: ubuntu-latest    
    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v1
        with:
          terraform_version: 0.15.5

      - name: Terraform Init
        id: init
        run: terraform init

      - name: Terraform Validate
        id: validate
        run: terraform validate -no-color

      - name: Terraform Destroy
        run: terraform destroy -auto-approve

Código da infra no Terraform

Não vou me aprofundar muito nos detalhes do código do Terraform, isso pode ficar para outro artigo. Basicamente temos a criação de 3 recursos dentro da AWS são eles: VPC, Security Group e a Instância EC2.

Para a criação da VPC já com a subnet pública, zonas de disponibilidades (AZs) e NAT Gateway estou utilizando o módulo vpc. Abaixo o trecho de código:

module "vpc" {
  source = "terraform-aws-modules/vpc/aws"

  name = "snake-vpc"
  cidr = "10.200.0.0/16"

  azs             = ["us-east-1a", "us-east-1b"]
  public_subnets  = ["10.200.101.0/24", "10.200.102.0/24"]

  enable_nat_gateway = true

  tags = {
    Terraform   = "true"
    Environment = "prod"
  }
}

Para a criação do Security Group estou utilizando o resource aws_security_group, onde configuramos a liberação geral na porta 80, padrão HTTP. Abaixo o trecho de código:

resource "aws_security_group" "game_snake_sg" {
  name        = "instances-snake-sg"
  description = "SG for Instances Snake Security Group"
  vpc_id      = module.vpc.vpc_id

  ingress {
    description = "Game Snake port 80"
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
  egress {
    from_port        = 0
    to_port          = 0
    protocol         = "-1"
    cidr_blocks      = ["0.0.0.0/0"]
    ipv6_cidr_blocks = ["::/0"]
  }

  tags = {
    Terraform = "true"
    Environment = "prod"
  }
}

Para finalizar criamos a instância EC2 utilizando o módulo ec2_instance, o servidor será provisionado com a imagem Amazon Linux 2, tipo t1.micro, anexamos o Security Group criando anteriormente, anexamos também a instância dentro da subnet pública que foi criada junto com a VPC e por fim passamos um arquivo no userdata, que basicamente é um shell script que será executando quando a instância for iniciada.

module "ec2_instance" {
  source = "terraform-aws-modules/ec2-instance/aws"

  name                   = "snake-game"
  ami                    = "ami-0cff7528ff583bf9a"
  instance_type          = "t1.micro"
  vpc_security_group_ids = [aws_security_group.game_snake_sg.id]
  subnet_id              = module.vpc.public_subnets[0]
  user_data              = file("userdata.sh")
  tags = {
    Name = "snake-game-ec2"
    Terraform = "true"
    Environment = "prod"
    Team = "gamer-development"
    Application = "snake-game"
    Language = "javascript"
  }
}

Desta forma o arquivo do terraform finalizado fica da seguinte maneira:

main.tf

module "vpc" {
  source = "terraform-aws-modules/vpc/aws"

  name = "snake-vpc"
  cidr = "10.200.0.0/16"

  azs             = ["us-east-1a", "us-east-1b"]
  public_subnets  = ["10.200.101.0/24", "10.200.102.0/24"]

  enable_nat_gateway = true

  tags = {
    Terraform   = "true"
    Environment = "prod"
  }
}

resource "aws_security_group" "game_snake_sg" {
  name        = "instances-snake-sg"
  description = "SG for Instances Snake Security Group"
  vpc_id      = module.vpc.vpc_id

  ingress {
    description = "Game Snake port 80"
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
  egress {
    from_port        = 0
    to_port          = 0
    protocol         = "-1"
    cidr_blocks      = ["0.0.0.0/0"]
    ipv6_cidr_blocks = ["::/0"]
  }

  tags = {
    Terraform = "true"
    Environment = "prod"
  }
}

module "ec2_instance" {
  source = "terraform-aws-modules/ec2-instance/aws"

  name                   = "snake-game"
  ami                    = "ami-0cff7528ff583bf9a"
  instance_type          = "t1.micro"
  vpc_security_group_ids = [aws_security_group.game_snake_sg.id]
  subnet_id              = module.vpc.public_subnets[0]
  user_data              = file("userdata.sh")
  tags = {
    Name = "snake-game-ec2"
    Terraform = "true"
    Environment = "prod"
    Team = "gamer-development"
    Application = "snake-game"
    Language = "javascript"
  }
}

Enviando um Pull Request, fazendo o Merge e executando o deploy da infraestrutura 🚀

Vamos criar uma nova branch no projeto chamada deployment fazer uma alteração no arquivo README.md e criar um Pull Request. Assim que Pull Request for criado o workflow plan.yml será disparado e poderemos verificar o que o Terraform irá provisionar na AWS.

Pull Request

Veja que após a execução do workflow plan.yml dentro dos comentários da Pull Request o GitHub Actions informa o resultado na execução, incrível né?! 🤩

Merge

Agora vamos aprovar o Merge da Pull Request para a branch main. Com essa estratégia é possível revisar o que exatamente o Terraform irá aplicar antes ser executado.

Após a execução podemos verificar no workflow apply.yml que tudo foi executado com sucesso.

Validando a infraestrutura na AWS

Verificando a conta AWS vemos que toda a infraestrutura foi provisionada com sucesso e a aplicação do jogo da cobrinha 🐍 está online.

Executando o Destroy 🗑

Caso seja necessário deletar toda a infraestrutura que foi provisionada devemos executar o workflow destroy.yml manualmente.

Após a execução todos recursos na AWS foram deletados.

Conclusão

Utilizando pipelines CD/CD é possível entregar ambientes completos de forma automática e rápida. Se você notou criamos todos os recurso dentro da AWS sem precisar dar ao menos um clique dentro do painel administrativo. Use e abuse da infraestrutura como código (IaC). Espero que tenha gostado desse hands-on, até a próxima! ✌🏼

Databases Migrations

Pedro H. Santos — Thu, 16 Jun 2022 04:24:25 +0000

Introdução

Esse trimestre estou estudando a disciplina de DBRE(Database Reliability Engineer) no curso de Pós Graduação DevOps and Cloud Solutions do Mackenzie que está sendo ministrada pelo professor Walter o qual solicitou um trabalho acadêmico sobre migrations. Então porque não escrever um pequeno artigo sobre esse assunto, let's go! ✍🏼

Afinal que são databases Migrations?

Sendo bem direto ao ponto, migrations trata-se do gerenciamento de mudanças incrementais e reversíveis no seu schema(estrutura) de banco de dados, ou seja, um controle de versionamento do seu banco de dados em repositório de código como o github por exemplo.

O que é um seeder?

Seeders são semeadores, são utilizados para popular a base de dados. Normalmente é muito utilizado para inserir dados padrões no banco de dados para o funcionamento correto da aplicação ou para inserção de dados fake em um ambiente de dev para execução de testes.

Método Up()

O método up é utilizado para executar uma migration que foi criada e alterar propriamente dito o schema do seu banco de dados. Criar uma nova coluna, criar uma nova tabela por exemplo.

Médoto Down()

O método down é utilizado para reverter uma migration para a posição anterior, como se fosse um rollback na estrutura do seu banco de dados. Remover uma coluna que foi criada, remover uma nova tabela que foi criada por exemplo.

Mão na massa! 💻

Para exemplificar tudo que foi dito até agora, vamos executar um projeto bem simples. Trata-se de uma aplicação de catálogo de livros, que foi escrita em Node utilizando como migrations a biblioteca mysql-migrations, todos os detalhes estão no repositório no github.com/santospedroh/dbre-migration.

Executando a migration inicial

Faça o clone do projeto executando o comando: git clone https://github.com/santospedroh/dbre-migration.git observe que existe um diretório chamado src/migrations e dentro dele temos dois arquivos: 1655316346150_create_table_books.js e o 1655323973586_create_books.js. Esse hash numérico que vemos no início do nome do arquivo é um timestamp o qual a migrations utiliza para fazer o controle de versionamento.

➜  migrations git:(main) ls -ltr
total 16
-rw-r--r--  1 santospedroh  staff  199 15 Jun 19:52 1655316346150_create_table_books.js
-rw-r--r--  1 santospedroh  staff  377 15 Jun 19:52 1655323973586_create_books.js

O arquivo _create_table_books.js trata-se da migration inicial com a criação da tabela de livros.

module.exports = {
    "up": "CREATE TABLE books (id INT NOT NULL AUTO_INCREMENT, UNIQUE KEY id (id), capa TEXT, nome varchar(255), editora varchar(255), link TEXT)",
    "down": "DROP TABLE books"
}

O arquivo _create_books.js trata-se do seeder com a inserção de um registro de livro para a base não iniciar vazia.

module.exports = {
    "up": "INSERT INTO books (capa, nome, editora, link) VALUES ('https://lh3.googleusercontent.com/JvM0JKKuZNJMWAC5iZPm4j-mdS9ORpZbpEWzg0zmJ0i2_xgIcju0OLXJ-zmnvz_GtFFGHe9qZ9Dz-6W0u5fRLFQaRlOI_hGzbetw','Site Reliability Engineering','O Reilly Media','https://sre.google/books/');",
    "down": "DELETE FROM books WHERE nome='Site Reliability Engineering';"
}

Vou considerar que você já tem o Docker instalado em seu computador, caso você não tenha o docker instalado siga o passo a passo descrito no README.md do projeto.

Execute o seguinte comando docker: docker run --rm -p 3306:3306 --name mysql -e MYSQL_ROOT_PASSWORD=rootpass -e MYSQL_USER=db_user -e MYSQL_PASSWORD=db_pass -e MYSQL_DATABASE=library -d mysql:5.6.51

Este comando irá criar um container docker com banco de dados MySQL 5.6 onde executaremos as migrations e a aplicação irá utilizar.

➜  ~ docker ps
CONTAINER ID   IMAGE          COMMAND                  CREATED       STATUS       PORTS                    NAMES
0a806d5d41a8   mysql:5.6.51   "docker-entrypoint.s…"   2 hours ago   Up 2 hours   0.0.0.0:3306->3306/tcp   mysql

Agora para criar o schema basta executar o comando: node ./src/migration.js up

Para executar a aplicação e verificar se deu tudo certo execute o comando: node ./src/app_books.js

Alterando a aplicação, adicionando colunas na tabela

Agora vamos acessar a branch release-1.0 do projeto o qual existe uma alteração que adiciona os novos campos autor e número de páginas para a entidade livros (tabela books).

Criando a nova migration e o novo seeder

Será necessário criar mais uma migration, para adicionar as colunas na tabela e mais um seeder, para atualizar o registro exemplo do livro.

Para criar a nova migration execute:

➜  migrations git:(main) node .src/migration.js add migration add_columns_books

Para criar o novo seeder execute:

➜  migrations git:(main) node .src/migration.js add seed add_autor_pags

Mais dois arquivos serão criados dentro do diretório src/migrations com os métodos up e down.

Precisamos inserir as instruções SQL nestes arquivos conforme abaixo:

O arquivo _add_columns_books.js trata-se da migration para adicionar as novas colunas.

module.exports = {
    "up": "ALTER TABLE books ADD COLUMN autor varchar(255), ADD COLUMN num_pags INT",
    "down": "ALTER TABLE books DROP COLUMN autor, DROP COLUMN num_pags"
}

O arquivo _add_autor_pags.js trata-se do seeder com a inserção do autor e número de páginas para registro do livro.

module.exports = {
    "up": "UPDATE books SET autor='Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy', num_pags=524 WHERE nome='Site Reliability Engineering';",
    "down": "UPDATE books SET autor=NULL, num_pags=NULL WHERE nome='Site Reliability Engineering';"
}

Executando a nova migration

Agora para alterar o schema basta executar novamente o comando: node ./src/migration.js up

Para executar a aplicação e verificar se deu tudo certo execute o comando: node ./src/app_books.js

Voltar versão anterior do schema

Para voltar para o estado anterior do schema do banco de dados basta executar o comando: node ./src/migration.js down 2 vezes, a primeira irá reverter o seeder com os dados dos campos autor e número de páginas e a segunda irá reverter a migration removendo as colunas autor e num_pags da tabela books.

➜  dbre-migration git:(release-1.0) ✗ node ./src/migration.js down
Run: true Type: DOWN: UPDATE books SET autor=NULL, num_pags=NULL WHERE nome='Site Reliability Engineering';
No more DOWN migrations to run
finished running migrations
➜  dbre-migration git:(release-1.0) ✗ node ./src/migration.js down
Run: true Type: DOWN: ALTER TABLE books DROP COLUMN autor, DROP COLUMN num_pags
No more DOWN migrations to run
finished running migrations

Conclusão

Migrations é uma ótima maneira de versionar o schema da sua base de dados junto com o código fonte da sua aplicação no repositório git. Para este hands-on eu utilizei a biblioteca do npm mysql-migration que é bem simples porém vários frameworks em várias linguagens já tem suporte nativo a migrations.