DEV Community: Felipe Lima

Rodando SQS localmente com LocalStack

Felipe Lima — Sun, 16 Oct 2022 19:27:05 +0000

O LocalStack é um emulador de serviços na nuvem que permite que serviços AWS sejam testados localmente, sem que seja necessário se conectar a uma conta remota.

O que iremos fazer:

Vou documentar aqui como executei o LocalStack pela primeira vez.
Os passos que segui foram:

iniciar um container com o LocalStack usado docker-compose
configurar o aws cli
criar e consumir uma fila SQS

Vou utilizar o docker-compose, conforme a documentação disponível na página https://docs.localstack.cloud/get-started/#docker-compose.

Requisitos:

docker
docker-compose versão >= 1.9.0
AWS Cli

Iniciando o container

Iremos utilizar o arquivo disponibilizado na própria página do LocalStack:

https://github.com/localstack/localstack/blob/master/docker-compose.yml

version: "3.8"

services:
  localstack:
    container_name: "${LOCALSTACK_DOCKER_NAME-localstack_main}"
    image: localstack/localstack
    ports:
      - "127.0.0.1:4566:4566" # LocalStack Gateway
      - "127.0.0.1:4510-4559:4510-4559" # external services port range
      - "127.0.0.1:53:53" # DNS config (only required for Pro)
      - "127.0.0.1:53:53/udp" # DNS config (only required for Pro)
      - "127.0.0.1:443:443" # LocalStack HTTPS Gateway (only required for Pro)
    environment:
      - DEBUG=${DEBUG-}
      - PERSISTENCE=${PERSISTENCE-}
      - LAMBDA_EXECUTOR=${LAMBDA_EXECUTOR-}
      # - LOCALSTACK_API_KEY=${LOCALSTACK_API_KEY-} # only required for Pro
      - DOCKER_HOST=unix:///var/run/docker.sock
    volumes:
      - "${LOCALSTACK_VOLUME_DIR:-./volume}:/var/lib/localstack"
      - "/var/run/docker.sock:/var/run/docker.sock"

E iniciar o container:

docker compose up

Configurando AWS Cli

Caso não tenha o Cli da AWS pode seguir essa documentação: https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html

$ aws --version
$ export AWS_ACCESS_KEY_ID="test"
$ export AWS_SECRET_ACCESS_KEY="test"
$ export AWS_DEFAULT_REGION="us-east-1"
$ aws configure --profile localstack
$ aws configure list

Criando uma fila

Criando uma fila chamada "teste", utilizando o profile "localstack":

$ aws sqs create-queue --endpoint-url http://localhost:4566 --queue-name teste --profile localstack

{
    "QueueUrl": "http://localhost:4566/000000000000/teste"
}

Listando filas

Conferindo as filas criadas:

$ aws sqs list-queues --endpoint-url http://localhost:4566 --profile localstack

{
    "QueueUrls": [
        "http://localhost:4566/000000000000/teste"
    ]
}

Enviando uma mensagem à fila

Antes de mais nada vamos criar um arquivo message.json contendo os atributos da mensagem:

{
  "id": {
    "DataType": "String",
    "StringValue": "e8f50240-be67-463a-a479-d540697931c0"
  },
  "name": {
    "DataType": "String",
    "StringValue": "blue-car-toy"
  }
}

Após isso irei enviar a nossa fila "teste" a mensagem "Mensagem de Teste":

$ aws sqs send-message --endpoint-url http://localhost:4566 --queue-url http://localhost:4566/000000000000/teste --message-body "Mensagem de Teste" --message-attributes file://./message.json --profile localstack
{
    "MD5OfMessageBody": "90a9cc3ce1350489e33ee38d19bf287a",
    "MD5OfMessageAttributes": "16894947ed19d2117e32efdb4f734250",
    "MessageId": "bc406501-3632-4f87-934b-11a1c909f8c6"
}

Recebendo as mensagens da fila

Lendo a mensagem da fila, uma a uma:

$ aws sqs receive-message --endpoint-url http://localhost:4566 --queue-url http://localhost:4566/000000000000/teste --attribute-names All --message-attribute-names All  --profile localstack
{
    "Messages": [
        {
            "MessageId": "bc406501-3632-4f87-934b-11a1c909f8c6",
            "ReceiptHandle": "N2VkNDdhZGQtMmUxZS00NmVjLWE5NzYtNGQzM2
ExNWZmODVlIGFybjphd3M6c3FzOnVzLWVhc3QtMTowMDAwMDAwMDAwMDA6dGVzdGUgYm
M0MDY1MDEtMzYzMi00Zjg3LTkzNGItMTFhMWM5MDlmOGM2IDE2NjU5MzkyODIuNDQ3NTc4NA==",
            "MD5OfBody": "90a9cc3ce1350489e33ee38d19bf287a",
            "Body": "Mensagem de Teste",
            "Attributes": {
                "SenderId": "000000000000",
                "SentTimestamp": "1665939195032",
                "ApproximateReceiveCount": "1",
                "ApproximateFirstReceiveTimestamp": "1665939282447"
            },
            "MD5OfMessageAttributes": "16894947ed19d2117e32efdb4f734250",
            "MessageAttributes": {
                "id": {
                    "StringValue": "e8f50240-be67-463a-a479-d540697931c0",
                    "DataType": "String"
                },
                "name": {
                    "StringValue": "blue-car-toy",
                    "DataType": "String"
                }
            }
        }
    ]
}

É isso! 😉

Referências:

https://github.com/flflima/localstack-docker

LocalStack

AWS Cli

https://docs.aws.amazon.com/cli/latest/reference/sqs/

Integrando Gradle + Jacoco + SonarQube

Felipe Lima — Sun, 18 Apr 2021 21:16:41 +0000

Cobertura de testes é um assunto polêmico. Se meu código tem 100% de cobertura de código, significa que ele está a prova de falhas? Não exatamente. Mas é essencial ter uma boa noção da cobertura dos teste no nosso código e ter em mãos ferramentas de análise que nos ajudem a ter uma noção melhor dos pontos de atenção no código (seja quanto a sua complexididade, tamanho de classes, dependências etc).

Em alguns projetos que trabalhei muitas vezes utilizava apenas o Jacoco para analisar a cobertura dos meus testes a partir dos relatórios gerados por ele.

Com o SonarQube podemos dar um passo adiante, já que a partir do relatório gerado pelo Jacoco ele consegue dar um complemento na análise e saúde do nosso código, gerando um dashboard com várias informações. Ele complementa esse relatório de cobertura, trazendo informações de violações de boas práticas no código, potênciais bugs, duplicações, falhas de segurança e entre outras coisas...

Rodando SonarQube localmente

Nesta demonstração utilizei a versão 8.8-community.

Antes de mais nada é preciso seguir as recomendações da página do Dockerhub, que sugerem ajustar a quantidade de memória virtual:

For example, on Linux, you can set the recommended values for the current session by running the following commands as root on the host:

sysctl -w vm.max_map_count=262144
sysctl -w fs.file-max=65536
ulimit -n 65536
ulimit -u 4096

Após isso criar um docker-compose.yml seguindo as orientações fornecidas na documentação para Docker do SonarQube e subir o container localmente:

docker-compose up -d

No navegador acessar http://localhost:9000/ e entrar na tela de login, como abaixo:

Neste primeiro acesso conectei com login e senha admin/admin. Em seguida será solicitada uma nova senha:

Pronto! Podemos acessar nosso SonarQube:

Configurando meu projeto

Para fazer essa integração utilizei um projeto pessoal desenvolvido em Kotlin: https://github.com/flflima/shopping-cart.

Primeiramente no SonarQube criei e configurei um projeto manualmente:

Foi gerado um código para adicionar no meu arquivo de configuração do projeto. No meu caso, estou utilizando o Gradle como gerenciador de dependência:

Após adicionar o plugin conforme sugerido, bastou executar o comando que gera meus relatórios via Jacoco e integra com o SonarQube:

./gradlew clean test sonarqube \
  -Dsonar.projectKey=<<your-project-key-configured>> \
  -Dsonar.host.url=http://localhost:9000 \
  -Dsonar.login=<<the-login>>

Na primeira vez que executei, o report marcou 0% de cobertura, o que não deveria ter acontecido já que o relatório do Jacoco marcava uma cobertura acima de 80%.

Mais precisamente 99% para cobertura por linha e 86% para cobertura por branches:

Já no SonarQube:

Após algumas pesquisas, descobri que precisava fazer alguns ajustes para que o Sonarqube pudesse enxergar o relatório gerado pelo Jacoco:

habilitar a flag xml.enabled, para que o SonarQube pudesse ler o relatório gerado em formato XML (a partir da versão 8 ele deixou de suportar o arquivo .exec gerado pelo Jacoco - mais aqui)

jacocoTestReport {
    reports {
        xml.enabled true // a flag anteriormente era false
        csv.enabled false
        html.destination file("${buildDir}/jacocoHtml")
    }

    afterEvaluate {
        excludeFiles(classDirectories, coverageExclusions)
    }
}

incluí uma configuração para o SonarQube localizar o relatório em XML e mapeei os mesmos arquivos excluídos da verificação do Jacoco:

sonarqube {
    properties {
        property "sonar.coverage.jacoco.xmlReportPaths", "${buildDir}/reports/jacoco/test/*.xml"
        property "sonar.java.coveragePlugin", "jacoco"
        property "sonar.coverage.exclusions", coverageExclusions
    }
}

na verificação da cobertura de código, removi a flag enabled = false, para que o relatório fosse gerado sempre, mesmo que a cobertura de código não fosse atingida:

jacocoTestCoverageVerification {
    violationRules {
        rule {
            limit {
                // enabled = false
                counter = 'BRANCH'
                value = 'COVEREDRATIO'
                minimum = 0.8
            }
        }
    }

    afterEvaluate {
        excludeFiles(classDirectories)
    }
}

Após essas alterações o SonarQube começou a apresentar os valores de cobetura. Na aba 'Measures' podemos ver que o mesmo valor (ou uma aproximação) é marcado, tanto para cobertura por linhas como por branches:

E como cobertura geral do SonarQube temos:

Como comentei no início do texto, essas são ferramentas que agregam nossa busca em qualidade de código.

É claro que precisamos estar sempre atentos porque até mesmos os testes podem estar sujeitos a bugs e nos dar a falsa sensação de que por termos uma alta cobertura nosso código está protegido.

Mas como toda ferramenta de apoio é bem vinda, acredito que seja extremamente interessante que um desenvolvedor tenha conhecimento delas e ao longo do tempo vá usando todas com consciência.

Referências

https://www.eclemma.org/jacoco/
https://www.sonarqube.org/
https://hub.docker.com/_/sonarqube
https://docs.sonarqube.org/latest/setup/install-server/

Referência ao erro: https://github.com/SonarSource/docker-sonarqube/issues/317

"Hello World" com Kotlin e Javalin

Felipe Lima — Fri, 02 Apr 2021 18:07:48 +0000

Eu lembro que a primeira vez que me ofereceram uma oportunidade para trabalhar com Kotlin achei estranho e acabei perguntando na hora: "Ah conhecço Kotlin, mas não serve pra desenvolvimento de apps?"

Bem, sim e muito mais!

Kotlin é uma linguagem multiplataforma desenvolvida pela JetBrains, que combina programação orientada a objetos com funcional, podendo ser utilizada para desenvolvimento de aplicações no lado do servidor, desenvolvimento Android, compilar JavaScript e código nativo.

Sua principal vantagem está em ter um código mais conciso e expressivo, mantendo compatibilidade com outros códigos em Java além de ter uma boa curva de aprendizagem.

Dito isso, como seria uma aplicação web desenvolvida em Kotlin. É o que irei demonstrar neste texto.

Criando um servidor web

Neste exemplo que eu fiz eu irei trabalhar com o Javalin.
Javalin é um framework leve que serve tanto para Java como para Kotlin.

Existem vários outros frameworks para Kotlin, mas acho que pra uma rápida demonstração ele serve, principalmente para quem está começando a programar nessa linguagem, já que não é necessário aprender muitos conceitos do framework para poder usá-lo e subir uma aplicação.

Olá Mundo!

Uma vez que você criou e configurou seu projeto, basta começar a adicionar as dependências para por nosso servidor em pé.

No meu exemplo eu utilizo o Gradle.

Primeiramente eu adicionei a biblioteca do Javalin e algumas outras dependências.

implementation 'io.javalin:javalin:3.13.4'
implementation 'org.slf4j:slf4j-simple:1.7.30'

Após isso criei um arquivo Main.kt e adicionei o seguinte conteúdo:

import io.javalin.Javalin

fun main() {
    val app = Javalin.create().start(7000)
    app.get("/hello") { ctx -> ctx.result("Hello World") }
}

Basicamente estou dizendo para que seja criada uma aplicação que escute na porta 7000, e que ao acessar o recurso /hello (GET http://localhost:7000/hello) retorne a mensagem "Hello World".

Executando a chamada no Postman temos o seguinte:

Simples, não?

A partir disso podemos evoluir cada vez mais a nossa aplicação (incluir outros endpoints, integração com banco de dados, segurança) mas isso pode ficar para um próxima ;)

Referências

https://kotlinlang.org/docs/server-overview.html

https://javalin.io/