DEV Community: Mairon Costa

Testes de Integração no Spring Boot: H2 vs @MockBean com exemplos reais

Mairon Costa — Wed, 23 Apr 2025 19:26:21 +0000

1. Introdução

Se você chegou até aqui, provavelmente quer entender como fazer testes de integração com Spring Boot, usando @MockBean ou um banco de dados em memória como o H2.

A diferença entre essas abordagens é simples:

Com @MockBean, você simula componentes específicos, retornando valores pré-definidos.
Com H2, você executa os testes em um banco em memória que simula o comportamento do banco real.

Antes de seguir, é importante entender duas anotações do Spring Boot:

@WebMvcTest: ideal para testes unitários de controllers, sem carregar todo o contexto da aplicação.
@SpringBootTest: carrega o contexto completo da aplicação, sendo o que usaremos aqui.

Observações importantes:

o projeto evita o uso de @Service, @Repository e @Autowired , a injeção de dependência é feita de forma manual;
há links no fim do artigo explicando os motivos para evitar as notações citadas e sobre os tipos de testes.

Descubra como escrever testes de integração eficazes com Spring Boot usando duas abordagens poderosas: banco de dados em memória com H2 e simulações com @MockBean. Nesta postagem, será mostrado como configurar cada cenário com exemplos reais, boas práticas e dicas práticas para evitar armadilhas comuns. Testar nunca foi tão direto ao ponto.

Então, vamos lá!?

2. Visão Geral do Projeto

2.1. Dependências do Maven (`pom.xml`)

O pom.xml está configurado com dependências para Spring Boot, JPA, PostgreSQL, H2, Lombok e bibliotecas de teste.

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>3.4.4</version>
        <relativePath/> <!-- lookup parent from repository -->
    </parent>
    <groupId>com.javawebtest</groupId>
    <artifactId>java-web-test</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <name>java-web-test</name>
    <description>Project to test anything about java web</description>
    <properties>
        <java.version>17</java.version>
    </properties>
    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-data-jdbc</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-data-jpa</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-devtools</artifactId>
            <scope>runtime</scope>
            <optional>true</optional>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-docker-compose</artifactId>
            <scope>runtime</scope>
            <optional>true</optional>
        </dependency>
        <dependency>
            <groupId>com.h2database</groupId>
            <artifactId>h2</artifactId>
            <scope>runtime</scope>
        </dependency>
        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <optional>true</optional>
        </dependency>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-test</artifactId>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>io.projectreactor</groupId>
            <artifactId>reactor-test</artifactId>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.postgresql</groupId>
            <artifactId>postgresql</artifactId>
            <scope>runtime</scope>
        </dependency>
    </dependencies>

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <configuration>
                    <annotationProcessorPaths>
                        <path>
                            <groupId>org.projectlombok</groupId>
                            <artifactId>lombok</artifactId>
                        </path>
                    </annotationProcessorPaths>
                </configuration>
            </plugin>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
                <configuration>
                    <excludes>
                        <exclude>
                            <groupId>org.projectlombok</groupId>
                            <artifactId>lombok</artifactId>
                        </exclude>
                    </excludes>
                </configuration>
            </plugin>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.8.0</version>
                <configuration>
                    <annotationProcessorPaths>
                        <path>
                            <groupId>org.projectlombok</groupId>
                            <artifactId>lombok</artifactId>
                            <version>${lombok.version}</version>
                        </path>
                        <dependency>
                            <groupId>org.projectlombok</groupId>
                            <artifactId>lombok-mapstruct-binding</artifactId>
                            <version>0.2.0</version>
                        </dependency>
                    </annotationProcessorPaths>
                    <compilerArgs>
                        <compilerArg>
                            -Amapstruct.defaultComponentModel=spring
                        </compilerArg>
                    </compilerArgs>
                </configuration>
            </plugin>
        </plugins>
    </build>

</project>

Nota: verifique as configurações do plugin do Lombok caso a aplicação não inicie corretamente.

2.2. Configuração dos `@Bean`

O projeto utiliza uma classe com @Configuration para definir os @Bean principais:

@Configuration
public class ProductConfiguration {

    public static final String PRODUCT_REPOSITORY_BEAN = "productRepositoryBean";
    public static final String PRODUCT_SERVICE_BEAN = "productServiceBean";

    @Profile({"!test"})
    @Bean(PRODUCT_REPOSITORY_BEAN)
    public ProductRepository productRepository(ProductJpaRepository productJpaRepository) {
        return new ProductRepositoryImpl(productJpaRepository);
    }

    @Bean(PRODUCT_SERVICE_BEAN)
    public ProductService productService(@Qualifier(PRODUCT_REPOSITORY_BEAN) ProductRepository productRepository) {
        return new ProductServiceImpl(productRepository);
    }
}

Atenção a notação @Profile({"!test"}), aqui é informado que quando o profile a ser executado contiver o valor teste esse @Bean deverá ficar sem ser ativado. Isso é importante para exemplificar o ponto aqui a ser passado.

2.3. Estrutura de Classes

O projeto possui:

Product : entidade

@JsonInclude(JsonInclude.Include.NON_EMPTY)
@Data
@Builder
@AllArgsConstructor
@NoArgsConstructor
@Entity(name = "product")
@Table(name = "product")
public class Product {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "id")
    private Long id;

    @Column(name = "name")
    private String name;

    @Column(name = "creation_date")
    @JsonFormat(pattern = "yyyy-MM-dd'T'HH:mm:ss'Z'")
    private LocalDateTime creationDate;

}

ProductController: API Rest

@EnableWebMvc
@RestController
@RequestMapping(value = "/product")
public class ProductController {

    private final ProductService productService;

    public ProductController(ProductService productService) {
        this.productService = productService;
    }

    @PostMapping(value = {"", "/"},
            produces = {MediaType.APPLICATION_JSON_VALUE},
            consumes = {MediaType.APPLICATION_JSON_VALUE})
    public ResponseEntity<Product> save (@RequestBody Product product) {

        product = productService.save(product);

        return ResponseEntity.status(HttpStatus.CREATED).body(product);
    }
}

ProductService: lógica de negócio

public interface ProductService {
    Product save(Product product);
}

public class ProductServiceImpl implements ProductService {

    private final ProductRepository productRepository;

    public ProductServiceImpl(ProductRepository productRepository) {
        this.productRepository = productRepository;
    }

    @Override
    public Product save(Product product) {

        product = productRepository.save(product);

        return product;
    }
}

ProductRepository: camada de persistência

public interface ProductJpaRepository extends JpaRepository<Product, Long> {
}

public interface ProductRepository {
    Product save(Product product);
}

public class ProductRepositoryImpl implements ProductRepository {

    private final ProductJpaRepository productJpaRepository;

    public ProductRepositoryImpl(ProductJpaRepository productJpaRepository) {
        this.productJpaRepository = productJpaRepository;
    }

    @Override
    public Product save(Product product) {

        product = productJpaRepository.save(product);

        return product;
    }
}

2.4. Fluxo da Aplicação

O fluxo é Controller → Service → Repository → Banco de Dados.

2.5. `application.yml` (ambiente dev)

Quando se trabalha com Springboot uma das formas de se configurar as variáveis do projeto é através do arquivo application.yml, sendo assim, a configuração do banco de dados também fica neste arquivo, segue um exemplo da configuração do projeto.

spring:
  config:
    activate:
      on-profile: dev

  jpa:
    defer-datasource-initialization: true
    show-sql: true

  datasource:
    url: jdbc:postgresql://localhost:5432/test
    username: test
    password: test1234
    driverClassName: org.postgresql.Driver

server:
  port: 8080

3. Teste de Integração com H2

Ao realizar testes, é comum substituir o banco real por um banco em memória como o H2. Para isso:

3.1. `application.yml` para testes

Arquivo localizado em src/test/resources/:

spring:
  config:
    activate:
      on-profile: test

  jpa:
    defer-datasource-initialization: true
    show-sql: true
    hibernate:
      ddl-auto: create-drop

  h2:
    console:
      enabled: true

  datasource:
    url: jdbc:h2:mem:test;MODE=PostgreSQL;DATABASE_TO_LOWER=TRUE;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=FALSE
    username: sa
    password:
    driverClassName: org.h2.Driver

3.2. Configuração dos `@Bean` para teste

Assim como em produção os @Bean deverão ser mapeados, no caso em tela, o @Bean relativo ao banco de dados deverá ser mapeado também. Repare que a notação mudou de @Configuration para @TestConfiguration.

@TestConfiguration
public class ConfigTest {

    @Profile({"test"})
    @Bean(ProductConfiguration.PRODUCT_REPOSITORY_BEAN)
    public ProductRepository productRepository(ProductJpaRepository productJpaRepository) {
        return new ProductRepositoryImpl(productJpaRepository);
    }
}

Atenção a notação @Profile({"test"}), aqui é informado que quando o profile a ser executado contiver o valor teste esse @Bean deverá ser ativado. Isso é importante para exemplificar o ponto aqui a ser passado.

3.3. O Teste

O ponto mais esperado chegou, o momento de criar o teste e vê-lo funcionar.

@ActiveProfiles({"test"})
@SpringBootTest(classes = {ConfigTest.class}, webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
@AutoConfigureMockMvc
public class ProductControllerH2Test {

    @Autowired
    MockMvc mockMvc;

    ObjectMapper objectMapper;

    @BeforeEach
    void beforeEach() {
        objectMapper = new ObjectMapper();
    }

    @Test
    public void test() throws Exception {
        String body = objectMapper.writeValueAsString(Product.builder()
                .name("new product")
                .build());

        mockMvc.perform(MockMvcRequestBuilders.post("/product/")
                        .content(body)
                        .contentType(MediaType.APPLICATION_JSON_VALUE))
                .andExpect(MockMvcResultMatchers.status().isCreated())
                .andExpect(MockMvcResultMatchers.jsonPath("$.name").value("new product"))
                .andExpect(MockMvcResultMatchers.jsonPath("$.id").value(1));
    }
}

Neste ponto é importante observar algumas notações, tais quais @ActiveProfiles({"test"}) e
@SpringBootTest . A notação @ActiveProfiles({"test"}) indica que para executar os testes desta classe deverá ser ativado o profile test, desta forma, excluindo outras configurações. Sobre a notação @SpringBootTest foi explicado anteriormente sobre a sua função, no entanto, tem algo especificado dentro dela que é importante, que é classes = {ConfigTest.class}, isso significa que a classe ConfigTest.class deverá ser carregada no contexto do Spring quando o mesmo for inicializado.

Repare que inexiste notações de mock para os @Bean do projeto, isso ocorreu pois de fato nada está sendo “mockado”, o fluxo ocorrerá do início ao fim, porém, o banco de dados utilizado será o H2 ao invés do banco utilizado em prod, dev, homolog ou algo do tipo que poderia ser um MySQL, PostgreSQL, Oracle ou outro.

4. Teste de Integração com @MockBean

Aqui, ao invés de usar um banco em memória, utilizamos mocks para simular o comportamento do repositório.

@ActiveProfiles({"test"})
@SpringBootTest(classes = {ConfigTest.class}, webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
@AutoConfigureMockMvc
public class ProductControllerMockTest {

    @Autowired
    MockMvc mockMvc;

    ObjectMapper objectMapper;

    @MockBean
    ProductJpaRepository productJpaRepository;

    @BeforeEach
    void beforeEach() {
        objectMapper = new ObjectMapper();
    }

    @Test
    public void test() throws Exception {
        Product product = Product.builder()
                .name("new product")
                .build();

        Mockito.when(productJpaRepository.save(product))
                .thenReturn(Product.builder()
                        .id(1L)
                        .name("test mock productJpaRepository")
                        .build());

        String body = objectMapper.writeValueAsString(product);

        mockMvc.perform(MockMvcRequestBuilders.post("/product/")
                        .content(body)
                        .contentType(MediaType.APPLICATION_JSON_VALUE))
                .andExpect(MockMvcResultMatchers.status().isCreated())
                .andExpect(MockMvcResultMatchers.jsonPath("$.name").value("test mock productJpaRepository"))
                .andExpect(MockMvcResultMatchers.jsonPath("$.id").value(1));
    }
}

Atenção: o @MockBean precisa ser usado no ponto certo do fluxo. Mockar classes fora da cadeia de execução esperada pode quebrar a injeção de dependências.

5. Quando usar H2 ou @MockBean?

Critério	H2 (Banco em Memória)	@MockBean (Simulação de Dependências)
Fidelidade com banco real	✅ Alta (simula o banco de verdade com SQL real)	❌ Baixa (lógica simulada, sem persistência real)
Performance	❌ Mais lento (carrega contexto + banco em memória)	✅ Rápido (sem overhead de banco)
Cobertura de integração	✅ Completa (inclui JPA, transações, etc.)	❌ Limitada (testa só partes isoladas)
Manutenção de testes	⚠️ Média (precisa manter schema e dados consistentes)	✅ Simples (mocka só o necessário)
Diagnóstico de bugs reais	✅ Melhor (simula situações reais de persistência)	❌ Pode mascarar bugs que só aparecem com DB real
Complexidade de setup	❌ Alta (requires profile, config H2, beans específicos)	✅ Baixa (só anotar com `@MockBean` e boa)
Indicado para testes de...	🔍 Integração ponta-a-ponta, fluxo completo	🧪 Lógica de negócio, regras isoladas
Depende de schema do banco?	✅ Sim	❌ Não
Ideal para TDD?	❌ Não (mais lento e complexo)	✅ Sim (rápido e direto ao ponto)

Pode-se considerar então que:

use H2 se quiser testar o comportamento completo da aplicação, incluindo a persistência real de dados.
use @MockBean para testar lógica de negócio de forma isolada, sem depender da infraestrutura.

Ambas técnicas são válidas e, inclusive, complementares.

6. Links de Referência

Se você leu até aqui, parabéns: agora tem munição suficiente pra escrever testes robustos no Spring Boot. Se não escrever, o bug vai te pegar! 😂

Debug Golang com VSCode

Mairon Costa — Fri, 06 Jan 2023 19:09:46 +0000

Opa, fala aí, pessoal, tudo beleza!? Depois de muito tempo sem escrever algo eu estou aparecendo aqui com esse mini tutorial (ou “how to” como alguns chamam) para explicar como configurar o VSCode para que se possa debugar ao desenvolver em Go (Golang). A minha principal motivação vem da galera com a qual eu trabalho, pois muitos têm dado preferência a utilizar o VSCode para desenvolver e, quando eles precisam de alguma ajuda ou tem alguma dúvida, que eu paro para tentar ajudá-los, eles colocam alguns println para entender o fluxo do sistema e para tentar saber o valor que determinada variável possui e por aí vai. Com isso, acabam repetindo as mesmas ações e outras coisas mais que acabam dificultando o entendimento e a resolver a questão. Como eu sou de uma geração um pouco mais antiga, eu desde cedo fui moldado a utilizar o debug na qual as IDEs disponibilizam e eu achei estranho - até meio improdutivo, isso alinhado a tortura do println - essa galera mais nova adicionar um monte de println ao código e depois sair removendo tudo quando vão realizar o commit.

Bem. Eu já falei (eu quis dizer escrever, mas você entendeu) demais. Vamos ao que interessa!

Sumário

Sistema e Configurações
Pré-Requisitos
- Instalar Go no VSCode
- Instalar o DLV no VSCode
Template básico do arquivo de configuração
Configurando o projeto
Inicializando a aplicação no modo debug
Conclusão
Referências
Apêndices

Sistema e Configurações

Pop!_OS versão 22.04 LTS em Máquina Virtual (VM);
Go na versão 1.19.4 instalado via GVM;
VSCode versão 1.74.1 instalado via flatpak;

Pré-Requisitos

Instalar Go no VSCode

Para esse tutorial foi utilizado a extensão Go na versão 0.37.0 da empresa Go team at Google.

Instalar o DLV no VSCode

Para tirar maior proveito na manutenção e assim manter atualizado o modo debug, pode-se utilizar o dlv. O jeito mais fácil de instalar o dlv é utilizar o comando "Go: Install/Update Tools" na paleta de comando do VSCode (Linux/Windows: Ctrl+Shift+P). O comando mostrará o dlv na listagem de ferramentas.

Template básico do arquivo de configuração

Para usar o modo debug no VSCode será necessário ter na raíz do projeto a pasta .vscode e dentro dela o arquivo launch.json, assim ficando /.vscode/launch.json.

Exemplo:

| raíz_projeto
| - .vscode
| - - launch.json

A seguir, um template básico do launch.json.

 {
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Run Name",
            "type": "go",
            "request": "launch",
            "mode": "debug",
            "program": "${workspaceFolder}",
            "env": {},
            "args": [],
            "showLog": true
        }
    ]
}

${workspaceFolder} é uma variável de ambiente gerada pelo VSCode que corresponde ao diretório raíz da aplicação.

Configurando o projeto

Para ter um exemplo mais concreto do uso será utilizado um projeto de exemplo como base para demonstrar as configurações.

Estrutura base do projeto:

| test-debug
| - .vscode
| - - launch.json
| - cmd
| - - main.go
| - envfile.env
| - go.mod

É possível ter mais de uma configuração no mesmo launch.json para ser utilizada de acordo com a necessidade, ou seja, é desnecessário ter mais de um launch.json ou então ficar alterando as configurações do mesmo para obter configurações diferentes. Em outras palavras, significa que dentro do mesmo launch.json é possível ter uma configuração para inicializar a aplicação com configurações para ambiente de dev, ambiente de homologação, de produção e assim por diante.

Vejamos a seguir exemplo de configuração para inicializar a aplicação:

Arquivo launch.json:

{
    "version":"0.2.0",
    "configurations":[
        {
            "name":"Test: Simple",
            "type":"go",
            "request":"launch",
            "mode":"debug",
            "program":"${workspaceFolder}/cmd",
            "env":{},
            "args":[],
            "showLog":true
        },
        {
            "name":"Test: Env And Args",
            "type":"go",
            "request":"launch",
            "mode":"debug",
            "program":"${workspaceFolder}/cmd",
            "envFile":"${workspaceFolder}/envfile.env",
            "env":{
                "HOST":"test.com"
            },
            "args":[
                "redirect",
                "test"
            ],
            "showLog":true
        }
    ]
}

Repare que na configuração que corresponde a Test: Env And Args foi utilizado um arquivo que contém algumas variáveis de ambiente, *, tem o *env no qual é possível também declarar variáveis de ambiente e o args, que é utilizado para passar argumentos a aplicação. Todos esses atributos possibilitam passar dados a aplicação.

Arquivo envfile.env:
```
ENVIRONMENT=dev
MESSAGE=HELLO WORLD!
```

Desta forma, seria possível externalizar num arquivo .env as variáveis de ambiente que são comuns aos ambientes, ou seja, simplifica a configuração.

Arquivo main.go:

package main
import (
    "fmt"
    "os"
)

func main() {
    HOST := os.Getenv("HOST")
    MESSAGE := os.Getenv("MESSAGE")
    ENVIRONMENT := os.Getenv("ENVIRONMENT")
    args := os.Args

    // without these println there is a compile error
    fmt.Println(fmt.Sprintf("Host: %s; Message: %s; Environment: %s", HOST, MESSAGE, ENVIRONMENT))

    for  i, arg := range args {
        fmt.Println(fmt.Sprintf("arg(%d): %s ", i, arg))
    }

}

Ao executar o programa será possível visualizar todas as variáveis e seus respectivos valores no painel de variáveis do VSCode.

Inicializando a aplicação no modo debug

Para inicializar a aplicação é bem simples, só seguir os seguintes passos:

clicar no ícone Run and Debug que fica, por padrão, do lado esquerdo do VSCode;
selecionar qual configuração do launch.json se deseja executar;
adicionar breakpoint no ponto que deseja pausar a execução da aplicação;
clicar no botão Start Debugging (F5) - ou Iniciar Depuração (F5).

Conclusão

Com o passo-a-passo descrito eu espero que agora seja possível configurar o ambiente de desenvolvimento, fazendo uso das configurações no launch.json e, a debuggar a aplicação, para que se possa acompanhar o fluxo do sistema e suas variáveis, desta forma, melhorando a produtividade e o entendimento durante o desenvolvimento.

Referências

Apêndices

A seguir algumas informações sobre as tecnologias utilizadas para desenvolver esse exemplo de aplicação:

SO utilizado Pop!_OS versão 22.04 LTS
Máquina Virtual (VM) foi utilizado o Gnome Boxes via flatpak;
Go na versão 1.19.4 instalado via GVM;
VSCode versão 1.74.1 instalado via flatpak;

AWS Lambda com Localstack

Mairon Costa — Tue, 26 May 2020 01:43:19 +0000

for english, click here.

Hoje em dia é muito comum ver as pessoas fazendo uso de plataformas de serviços online como a AWS, Azure, GoogleCloud. Estes são as mais famosas "Cloud". E, como qualquer outro desenvolvedor, é muito importante testar seus códigos antes de colocá-lo em produção, e neste caso, algumas questões surgem, "Como é possível testar o código que está em produção?", "Como eu posso atualizar o código que já funciona sem quebrá-lo?" ou algo do tipo. Então, para estes casos, este trabalho foi pensado. A meta principal é explicar como é possível testar um AWS Lambda na sua máquina usando PyCharm com Python e Localstack.

Então... vamos lá!!!!!

Setup

Ubuntu 20.04 LTS;
IDE: PyCharm Professional;
Python 3.8;
Docker;
AWS SAM CLI: é necessário para IDE funcionar com AWS Services;
AWS CLI: você pode usar suas credenciais verdadeiras (como descrito aqui), ou pode fazer uma ficticia. O Localstack verifica se as credenciais estão presentes e não se elas são válidas;
Serverless framework;

Configuração

AWS CLI

Sobre o AWS CLI, é possível checar o material para instalar no site da AWS, clique aqui.

AWS SAM CLI

Para instalar o AWS SAM CLI é informado nos documentos da AWS que é para instalá-lo pelo Homebrew, mas em alguns casos é difícil instalar o Homebrew e pensando nisto, aqui está um outro jeito de instalar o AWS SAM CLI, é possíve pegar o código fonte no Github clicando aqui.

$ git clone https://github.com/awslabs/aws-sam-cli.git
$ cd aws-sam-cli
$ sudo python3.8 ./setup.py build install
$ sam --version

A saída final:

SAM CLI, version 0.47.0

Localstack Docker

Neste momento o "docker-compose.yaml" deve ser criado na raíz do projeto, com isto será possível rodar o localstack de um docker container.

$ touch docker-compose.yml

docker-compose.yml

version: '2.1'
services:    
  localstack:  
    image: localstack/localstack  
    ports:  
      - "4567-4597:4567-4597"  
      - "${PORT_WEB_UI-8080}:${PORT_WEB_UI-8080}"  
    environment:  
      - SERVICES=${SERVICES- }  
      - DEBUG=${DEBUG- }  
      - DATA_DIR=${DATA_DIR- }  
      - PORT_WEB_UI=${PORT_WEB_UI- }  
      - LAMBDA_EXECUTOR=${LAMBDA_EXECUTOR- }  
      - KINESIS_ERROR_PROBABILITY=${KINESIS_ERROR_PROBABILITY- }  
      - DOCKER_HOST=unix:///var/run/docker.sock  
    volumes:  
      - "${TMPDIR:-/tmp/localstack}:/tmp/localstack"  
      - "/var/run/docker.sock:/var/run/docker.sock"

E agora vamos rodar o "docker-compose" com o seguinte comando:

$ docker-compose up

A partir deste momento é possível acessar diferentes serviços da AWS atráves das diferentes portas no servidor local. Por enquanto vamos testar o serviço do AWS S3.

$ curl -v http://localhost:4572

Parte da saída:

<ListAllMyBucketsResult xmlns="http://s3.amazonaws.com/doc/2006-03-01">
    <Owner><ID>bcaf1ffd86f41161ca5fb16fd081034f</ID>                
    <DisplayName>webfile</DisplayName></Owner><Buckets></Buckets>
</ListAllMyBucketsResult>

Este teste pode ser realizado também no browser. Apenas copie o endereço e cole na url do browser ou apenas click aqui.

Algumas portas do AWS Service com Localstack

S3: 4572
DynamoDB: 4570
CloudFormation: 4581
Elasticsearch: 4571
ES: 4578
SNS: 4575
SQS: 4576
Lambda: 4574
Kinesis: 4568

PyCharm com AWS Lambda

Uma vez o "docker-compose" estiver funcionando é hora de criar o projeto. Neste momento vamos criar um projeto novo no PyCharm:

Criando um no projeto:

No passo número 3 é muito importante checar se o "SAM CLI" foi automáticamente reconhecido.

Criando o arquivo principal, o lambda_function.py , na raíz do projeto.

import urllib.parse
import boto3
import json

# print('Loading function')

HOST = "http://[YOUR_IP]"
# Get the service resource
# To production it's not necessary inform the "endpoint_url" and "region_name"
s3 = boto3.client('s3',
                  endpoint_url= HOST + ":4572",
                  region_name="us-east-1")
sqs = boto3.client('sqs',
                  endpoint_url= HOST + ":4576",
                  region_name="us-east-1")

def lambda_handler(event, context):
    # print("Received event: " + json.dumps(event, indent=2))

    # Get the object from the event and show its content type
    bucket = event['Records'][0]['s3']['bucket']['name']
    key = urllib.parse.unquote_plus(event['Records'][0]['s3']['object']['key'], encoding='utf-8')
    url_queue = HOST + ":4576/queue/lambda-tutorial"

    try:

        response = s3.get_object(Bucket=bucket, Key=key)

        deb = {
            "request_id": response['ResponseMetadata']['RequestId'],
            "queue_url": url_queue,
            "key": key,
            "bucket": bucket,
            "message": "aws lambda with localstack..."
        }

        print("#########################################################")
        print("Send Message")
        #Send message to SQS queue
        response = sqs.send_message(
                QueueUrl=deb["queue_url"],
                MessageBody=json.dumps(deb)
        )

        print("response: {}".format(response))

        print("#########################################################")
        print("Receive 10 Messages From SQS Queue")
        response = sqs.receive_message(
            QueueUrl=deb["queue_url"],
            MaxNumberOfMessages=10,
            VisibilityTimeout=0,
            WaitTimeSeconds=0
        )

        print("#########################################################")
        print("Read All Messages From Response")
        messages = response['Messages']
        for message in messages:
            print("Message: {}".format(message))

        print("Final Output: {}".format(json.dumps(response)))
        return json.dumps(response)

    except Exception as e:
        print(e)
        raise e

Se o "boto3" não estiver instalado a IDE irá notificar, assim sendo, abra o terminal e execute o seguinte comando:

$ pip3.8 install boto3

Criando os arquivos que darão suporte ao projeto.

Neste momento algumas pastas e arquivos serão criados, as pastas conterão os arquivos utilizados no teste. Vamos criar as pastas "test/files" na raíz do projeto e então criar os arquivo para rodar o projeto.

aws-lambda-localstack
|test/
|- file/
|- - test_file.log
|- - input-event-test.json
|requirements.txt

test_file.log: Este arquivo será usado como exemplo vindo do bucket. Pode ser um arquivo vazio.

requirements.txt: Este arquivo é exigido pelo "SAM CLI".

input-event-test.json: Este arquivo será executado para rodar o projeto. Ele contém as informações do bucket.

{
  "Records": [
    {
      "eventVersion": "2.0",
      "eventSource": "aws:s3",
      "awsRegion": "us-east-1",
      "eventTime": "1970-01-01T00:00:00.000Z",
      "eventName": "ObjectCreated:Put",
      "userIdentity": {
        "principalId": "EXAMPLE"
      },
      "requestParameters": {
        "sourceIPAddress": "127.0.0.1"
      },
      "responseElements": {
        "x-amz-request-id": "EXAMPLE123456789",
        "x-amz-id-2": "EXAMPLE123/5678abcdefghijklambdaisawesome/mnopqrstuvwxyzABCDEFGH"
      },
      "s3": {
        "s3SchemaVersion": "1.0",
        "configurationId": "testConfigRule",
        "bucket": {
          "name": "tutorial",
          "ownerIdentity": {
            "principalId": "EXAMPLE"
          },
          "arn": "arn:aws:s3:::example-bucket"
        },
        "object": {
          "key": "lambda/test_file.log",
          "size": 1024,
          "eTag": "0123456789abcdef0123456789abcdef",
          "sequencer": "0A1B2C3D4E5F678901"
        }
      }
    }
  ]
}

Uma vez que os passos anteriores estivem terminados, o próximo passo será configurar o "run configuration".

Agora a configuração de IDE está feita, hora de configurar as entradas. Para configurar as entradas é obrigatório rodar alguns comando para criar os arquivos no S3 e criar a fila no SQS.

1 - Criando o bucket no S3: o bucket será nomeado como "tutorial".

$ aws --endpoint-url=http://localhost:4572 s3 mb s3://tutorial

2 - Criando a pasta no S3: será criada uma pasta chamada "lambda".

$ aws --endpoint-url=http://localhost:4572 s3api put-object --bucket tutorial --key lambda

O Response será alguma como:

{
    "ETag": "\"d41d8cd98f00b204e9800998ecf8427e\""
}

3 - Copiando arquivos para o bucket: copiando os arquivos de "test/files" para "s3://tutorial/lambda/".

$ aws --endpoint-url=http://localhost:4572 s3 cp ./test/files/ s3://tutorial/lambda/ --recursive

Deve-se checar se o bucket foi criado. Copie o valor de "endpoint-url" e execute um "curl" ou cole no browser, por exemplo:

$ curl -v http://localhost:4572/tutorial

A saída será algo como:

<?xml version="1.0" encoding="UTF-8"?>
<ListBucketResult xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
   <Name>tutorial</Name>
   <MaxKeys>1000</MaxKeys>
   <Delimiter>None</Delimiter>
   <IsTruncated>false</IsTruncated>
   <Contents>
      <Key>lambda</Key>
      <LastModified>2020-04-28T01:36:04.128Z</LastModified>
      <ETag>"d41d8cd98f00b204e9800998ecf8427e"</ETag>
      <Size>0</Size>
      <StorageClass>STANDARD</StorageClass>
      <Owner>
         <ID>75aa57f09aa0c8caeab4f8c24e99d10f8e7faeebf76c078efc7c6caea54ba06a</ID>
         <DisplayName>webfile</DisplayName>
      </Owner>
   </Contents>
   <Contents>
      <Key>lambda/input-event-test.json</Key>
      <LastModified>2020-04-28T01:40:27.882Z</LastModified>
      <ETag>"4e114da7aa17878f62bf4485a90a97a2"</ETag>
      <Size>1011</Size>
      <StorageClass>STANDARD</StorageClass>
      <Owner>
         <ID>75aa57f09aa0c8caeab4f8c24e99d10f8e7faeebf76c078efc7c6caea54ba06a</ID>
         <DisplayName>webfile</DisplayName>
      </Owner>
   </Contents>
   <Contents>
      <Key>lambda/test_file.log</Key>
      <LastModified>2020-04-28T01:40:27.883Z</LastModified>
      <ETag>"4ac646c9537443757aff7ebd0df4f448"</ETag>
      <Size>29</Size>
      <StorageClass>STANDARD</StorageClass>
      <Owner>
         <ID>75aa57f09aa0c8caeab4f8c24e99d10f8e7faeebf76c078efc7c6caea54ba06a</ID>
         <DisplayName>webfile</DisplayName>
      </Owner>
   </Contents>
</ListBucketResult>

4 - Criando um fila no SQS.

$ aws --endpoint-url=http://localhost:4576 sqs create-queue --queue-name lambda-tutorial

O retorno será algo como:

{
    "QueueUrl": "http://localhost:4576/queue/lambda-tutorial"
}

Uma vez que tudo estiver feito e todas as saídas estão okays, é hora de rodar o projeto. Note que, no código foi inscrito a entrada e a saída pra este texto. Assim sendo, para rodar o projeto clique no botão "Run '[Local] lambda_function.lambda_handler'".

Depois disto, é possível ver a saída do processo no console. É exibido as entradas e ao final dez mensagens serão recuperadas da fila e exibidas no console.

BOA!

Concluído!

Este pode ser somente o ponto inicial e eu espero que este texto ajude-os a testar seus serviços na AWS... Eu espero que todos vocês alcancem suas metas.

Repositório: aws-lambda-localstack.

Obrigado por ter lido até o fim!

Referências

Algumas referências que foram utilizadas para concluir este texto.

Algumas Cloud Computing

AWS Lambda with Localstack

Mairon Costa — Tue, 26 May 2020 01:29:08 +0000

AWS Lambda with Localstack

for portguese, click here.

Nowadays it's very common to see people using online platform stacks services like the AWS, Azure, GoogleCloud. They're the most famous "Cloud". And, as anything as others developer, it's very important to test your code before putting it on production, and in this case, some question shows up, "How is possible to test the code that is in production?", "How could I update a code that works without broke it?" or something like that. And so, to these cases, this work was thought. The main goal is to explain how it's possible to run an AWS Lambda in a machine using PyCharm with python and localstack.

and so... let's go!

Setup

Ubuntu 20.04 LTS;
IDE: PyCharm Professional;
Python 3.8;
Docker;
AWS SAM CLI: It's necessary to IDE works with AWS Services;
AWS CLI: You can use real credentials (as described here), or dummy ones. Localstack requires that these values are present, but it doesn’t validate them;
Serverless framework;

Configuration

AWS CLI

About the AWS CLI, it's possible to check the AWS material to install it, click here.

AWS SAM CLI

To install the AWS SAM CLI is informed in the AWS docs that it's necessary to install it by Homebrew, but in some cases is hard to install the Homebrew, and thinking about this, there is another way to install it, it's possible to get the source code from Github repository here.

$ git clone https://github.com/awslabs/aws-sam-cli.git
$ cd aws-sam-cli
$ sudo python3.8 ./setup.py build install
$ sam --version

The final output:

SAM CLI, version 0.47.0

Localstack Docker

At this time, the "docker-compose.yaml" have to be created at the root of the project. With this, it will be possible to run localstack from a docker container.

$ touch docker-compose.yml

docker-compose.yml

version: '2.1'
services:    
  localstack:  
    image: localstack/localstack  
    ports:  
      - "4567-4597:4567-4597"  
      - "${PORT_WEB_UI-8080}:${PORT_WEB_UI-8080}"  
    environment:  
      - SERVICES=${SERVICES- }  
      - DEBUG=${DEBUG- }  
      - DATA_DIR=${DATA_DIR- }  
      - PORT_WEB_UI=${PORT_WEB_UI- }  
      - LAMBDA_EXECUTOR=${LAMBDA_EXECUTOR- }  
      - KINESIS_ERROR_PROBABILITY=${KINESIS_ERROR_PROBABILITY- }  
      - DOCKER_HOST=unix:///var/run/docker.sock  
    volumes:  
      - "${TMPDIR:-/tmp/localstack}:/tmp/localstack"  
      - "/var/run/docker.sock:/var/run/docker.sock"

And now, let's run the docker-compose with this command:

$ docker-compose up

Now it's possible to access different AWS services through different ports on your local server. For a while, let's test the AWS S3 service.

$ curl -v http://localhost:4572

Some part of output:

<ListAllMyBucketsResult xmlns="http://s3.amazonaws.com/doc/2006-03-01">
    <Owner><ID>bcaf1ffd86f41161ca5fb16fd081034f</ID>                
    <DisplayName>webfile</DisplayName></Owner><Buckets></Buckets>
</ListAllMyBucketsResult>

This test can be done in the web browser, too. Just copy the address and then paste it in the browser URL or just click here.

Some ports from AWS Service with Localstack

S3: 4572
DynamoDB: 4570
CloudFormation: 4581
Elasticsearch: 4571
ES: 4578
SNS: 4575
SQS: 4576
Lambda: 4574
Kinesis: 4568

PyCharm with AWS Lambda

Once the docker-compose it's working and running, it's time to create the project. Let's create a new project in the PyCharm:

Creating a new project

In step number 3 it's very important to check if the "SAM CLI" was automatically recognized.

Creating the main file, the lambda_function.py , in the root of the project.

import urllib.parse
import boto3
import json

# print('Loading function')

HOST = "http://[YOUR_IP]"
# Get the service resource
# To production it's not necessary inform the "endpoint_url" and "region_name"
s3 = boto3.client('s3',
                  endpoint_url= HOST + ":4572",
                  region_name="us-east-1")
sqs = boto3.client('sqs',
                  endpoint_url= HOST + ":4576",
                  region_name="us-east-1")

def lambda_handler(event, context):
    # print("Received event: " + json.dumps(event, indent=2))

    # Get the object from the event and show its content type
    bucket = event['Records'][0]['s3']['bucket']['name']
    key = urllib.parse.unquote_plus(event['Records'][0]['s3']['object']['key'], encoding='utf-8')
    url_queue = HOST + ":4576/queue/lambda-tutorial"

    try:

        response = s3.get_object(Bucket=bucket, Key=key)

        deb = {
            "request_id": response['ResponseMetadata']['RequestId'],
            "queue_url": url_queue,
            "key": key,
            "bucket": bucket,
            "message": "aws lambda with localstack..."
        }

        print("#########################################################")
        print("Send Message")
        #Send message to SQS queue
        response = sqs.send_message(
                QueueUrl=deb["queue_url"],
                MessageBody=json.dumps(deb)
        )

        print("response: {}".format(response))

        print("#########################################################")
        print("Receive 10 Messages From SQS Queue")
        response = sqs.receive_message(
            QueueUrl=deb["queue_url"],
            MaxNumberOfMessages=10,
            VisibilityTimeout=0,
            WaitTimeSeconds=0
        )

        print("#########################################################")
        print("Read All Messages From Response")
        messages = response['Messages']
        for message in messages:
            print("Message: {}".format(message))

        print("Final Output: {}".format(json.dumps(response)))
        return json.dumps(response)

    except Exception as e:
        print(e)
        raise e

If the "boto3" is not installed the IDE will warning, and so, open a terminal and executing the following command:

$ pip3.8 install boto3

Creating files that will support the project

At this time, there are some folders and files to be created, the folders must contain the files test. Let's create the folders "test/files" in the root of the project, and then, creating the files to run the project.

aws-lambda-localstack
|test/
|- file/
|- - test_file.log
|- - input-event-test.json
|requirements.txt

test_file.log: this file will be used as an example from the bucket. It could be just an empty file.

requirements.txt: this file is required by "SAM CLI".

input-event-test.json: this one is the input test that will be called when running the project.

{
  "Records": [
    {
      "eventVersion": "2.0",
      "eventSource": "aws:s3",
      "awsRegion": "us-east-1",
      "eventTime": "1970-01-01T00:00:00.000Z",
      "eventName": "ObjectCreated:Put",
      "userIdentity": {
        "principalId": "EXAMPLE"
      },
      "requestParameters": {
        "sourceIPAddress": "127.0.0.1"
      },
      "responseElements": {
        "x-amz-request-id": "EXAMPLE123456789",
        "x-amz-id-2": "EXAMPLE123/5678abcdefghijklambdaisawesome/mnopqrstuvwxyzABCDEFGH"
      },
      "s3": {
        "s3SchemaVersion": "1.0",
        "configurationId": "testConfigRule",
        "bucket": {
          "name": "tutorial",
          "ownerIdentity": {
            "principalId": "EXAMPLE"
          },
          "arn": "arn:aws:s3:::example-bucket"
        },
        "object": {
          "key": "lambda/test_file.log",
          "size": 1024,
          "eTag": "0123456789abcdef0123456789abcdef",
          "sequencer": "0A1B2C3D4E5F678901"
        }
      }
    }
  ]
}

Once the steps before are done, the next step will configure the "run configuration".

Now the IDE configuration is done, and then, let's configure the entries. For configuring the entries it's mandatory to run some commands to create the files on the S3 and to create the SQS Queue.

1 - Creating the bucket on S3: the bucket will be named "tutorial".

$ aws --endpoint-url=http://localhost:4572 s3 mb s3://tutorial

2 - Creating a folder on S3: it'll be creating a folder named "lambda".

$ aws --endpoint-url=http://localhost:4572 s3api put-object --bucket tutorial --key lambda

The response will be something like that:

{
    "ETag": "\"d41d8cd98f00b204e9800998ecf8427e\""
}

3 - Copying files to bucket: copying files from "./test/files" to "s3://tutorial/lambda/"

$ aws --endpoint-url=http://localhost:4572 s3 cp ./test/files/ s3://tutorial/lambda/ --recursive

To check if the bucket was created, copy the value from "endpoint-url" and execute a "curl" or paste in the browser, for example:

$ curl -v http://localhost:4572/tutorial

The output will be something like:

<?xml version="1.0" encoding="UTF-8"?>
<ListBucketResult xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
   <Name>tutorial</Name>
   <MaxKeys>1000</MaxKeys>
   <Delimiter>None</Delimiter>
   <IsTruncated>false</IsTruncated>
   <Contents>
      <Key>lambda</Key>
      <LastModified>2020-04-28T01:36:04.128Z</LastModified>
      <ETag>"d41d8cd98f00b204e9800998ecf8427e"</ETag>
      <Size>0</Size>
      <StorageClass>STANDARD</StorageClass>
      <Owner>
         <ID>75aa57f09aa0c8caeab4f8c24e99d10f8e7faeebf76c078efc7c6caea54ba06a</ID>
         <DisplayName>webfile</DisplayName>
      </Owner>
   </Contents>
   <Contents>
      <Key>lambda/input-event-test.json</Key>
      <LastModified>2020-04-28T01:40:27.882Z</LastModified>
      <ETag>"4e114da7aa17878f62bf4485a90a97a2"</ETag>
      <Size>1011</Size>
      <StorageClass>STANDARD</StorageClass>
      <Owner>
         <ID>75aa57f09aa0c8caeab4f8c24e99d10f8e7faeebf76c078efc7c6caea54ba06a</ID>
         <DisplayName>webfile</DisplayName>
      </Owner>
   </Contents>
   <Contents>
      <Key>lambda/test_file.log</Key>
      <LastModified>2020-04-28T01:40:27.883Z</LastModified>
      <ETag>"4ac646c9537443757aff7ebd0df4f448"</ETag>
      <Size>29</Size>
      <StorageClass>STANDARD</StorageClass>
      <Owner>
         <ID>75aa57f09aa0c8caeab4f8c24e99d10f8e7faeebf76c078efc7c6caea54ba06a</ID>
         <DisplayName>webfile</DisplayName>
      </Owner>
   </Contents>
</ListBucketResult>

4 - Creating an SQS Queue

$ aws --endpoint-url=http://localhost:4576 sqs create-queue --queue-name lambda-tutorial

The exit will be somthing like:

{
    "QueueUrl": "http://localhost:4576/queue/lambda-tutorial"
}

Once everything is done, and all output was okay, it's time to run the project. Note, in the code was written the input and the output for this text. And so, to run click in the "Run '[Local] lambda_function.lambda_handler'" button.

After this, it's possible to see the output from this process on the console. It's showing the entries, and in the final ten messages are recovered from the queue and printed in the console.

GREAT!

It's Done!

This can be just the initial point, and I hope that this text helps you test your AWS services... I hope that all of you reach your goals.

Repository: aws-lambda-localstack.

Thank you for reading 'till the end!

References

Some references that I have used to complete this text.

Some Cloud Computing

Bitbucket-Pipeline: How to deploy a docker image to Heroku using Springboot

Mairon Costa — Fri, 20 Dec 2019 20:13:29 +0000

Hey, guys, how’s going!? Nowadays (2019-2020) the IT market has been growing, new technologies appeared, and, as tendencies, the CI - Continuous Integration - and CD - Continuous Delivery (in some case Continuous Deploy).

The following text has as a goal to explain how to deploy a docker image on Heroku platform using Bitbucket, using the bitbucket-pipeline. This way, it’ll be done a deploy after a commit be done on Bitbucket. The text has an academic context and as a programming language was choice Java, using Springboot with maven. It’s important to inform that it depends on you getting better and/or change what’s been informed here to help or support you.

Presume it here that for you came here the reader is a Bitbucket user, in this case, know use git, and, you know use Heroku. If you don’t know what is it, it’s recommended you search for both, as about the Bitbucket (https://bitbucket.org/ , https://pt.wikipedia.org/wiki/Bitbucket) as a Heroku (https://www.heroku.com/ , https://en.wikipedia.org/wiki/Heroku).

let’s go!

To do this example the Intellij Community was used as IDE and the Ubuntu 18.04 LTS was used as the operational system.

The project tree as like following:

Look that exists the “bitbucket-pipeline.yml” file in the root project and this is fundamental to get success. However, this will be talked about and some other points as follows.

1. Heroku

At this point, the Heroku configuration will be done. The application will be created, the environment variable will be added and the “API key” will be generated.

1.1 Creating the application on Heroku

1.2 Adding the environment variable

The reason to have the environment variable it's because it will be informed which “Profile” will be used to start the application on Heroku. In this case, for example, it’s possible that you may want to have a test environment, or developer environment, or production environment and because of this, it’ll be passed this information through the environment variable.

To add a environment variable is necessary that you go in the page of project created, in “Settings”, click in “Reveal Config Vars” and following inform the variables, that in this case, it will be informed as key “SPRING_PROFILE” and as value will be informed “heroku”, and after inform, you have to click on “Add” button.

1.3 API Key

At this moment you have to save the “API Key”. This key will make possible to do the deploy being out from Heroku platform. For this, you have to go in “Account settings” and following go to the field “API Key”, if the key doesn’t exist you must create it.

2. BitBucket

At this step, the Bitbucket Pipeline will be turned on and the environment variable will be added.

2.1 Turn on Pipeline

At the Bitbucket platform, the pipeline will be turned on and for such, it’s necessary to go to settings from the project, go to option “Pipeline > Settings” and turned on this option.

2.2 Adding the environment variable

In the next step, the environment variables will be added into the project and for such, you have to return to the project configuration and to go to “Pipeline > Repository variables”. The environment variables that will be added are “HEROKU_API_KEY”, this one was generated into the “API Key” step from Heroku and it’ll be added “HEROKU_APP_NAME” too, this one which is the application name created on Heroku.

3. Application

It’s time to configure the application to it could be possible to run the pipeline when a commit on branch master will be done and this way the deploy could be done on Heroku.
It’s important to say that Java with Springboot was chosen as the programming language, and the Intellij Community is used as IDE.

3.1 Application.yml

Now it’ll be created the “application.yml” file inside the “resource” folder from the project at the same level that the “application.properties”. Into this file will be informed of the profile name and the port that the application will start. Realize that there are two profiles, one is for development (dev profile) and another one in which the Heroku (heroku profile) will use to start the application.

#redis
#host: if you going to use docker you must change the host to work based on IP,
# its mean that you musn't use localhost or 127.0.0.1
#spring.redis.host=10.0.0.21
spring:
  application:
    name: bbpipeline-heroku-api

---
spring:
  profiles: dev
server:
  port: 8081

---
spring:
  profiles: heroku

3.2 Bitbucket-pipeline.yml

In this point is necessary to create the “bitbucket-pipeline.yml” file into the root project, because this one has the formula that will be read and execute inside the Bitbucket.

# This is a sample build configuration for Java (Maven).
# Check our guides at https://confluence.atlassian.com/x/zd-5Mw for more examples.
# Only use spaces to indent your .yml configuration.
# -----
# You can specify a custom docker image from Docker Hub as your build environment.
image: maven:3.6.1

pipelines:
  branches:
    master:
      - step: #Its working
          name: Create Artifact
          caches:
            - maven
          script: # Modify the commands below to build your repository.
            - mvn -B package # -B batch mode makes Maven less verbose
          artifacts: # defining the artifacts to be passed to each future step.
            - target/**

      - step:
          name: Push docker image to the Heroku
          deployment: Production
          services:
            - docker
          script:
            - curl https://cli-assets.heroku.com/install-ubuntu.sh | sh
            - heroku container:login
            - heroku container:push web -a $HEROKU_APP_NAME
            - heroku container:release web -a $HEROKU_APP_NAME

Pay attention that there is “branch: master:”, in this case, the pipeline will be executed every single time that a commit will be done on branch master and inside this hierarchy, there are the steps, this steps that will be executed by script after the commit on branch master be done.

Into step named by “Create Artifact” will be executed the “mvn -B package” command (if there are tests they will be executed) and following it’ll be created for a short time a folder named by “target”, this folder contains the files that will be used on application create on docker container.
Into step called by “Push docker image to the Heroku” will be used “services’ from docker to create the image and the following will be executed the script. Into script, the first step is to install the “heroku standalone” (command used to install: curl https://cli-assets.heroku.com/install-ubuntu.sh | sh); after to do log in on Heroku system and in this moment it will be using the “API Key” (this one that was put as environment variable) as access key to the Heroku; and as follow the docker image created will be sent and the deploy will be done.

3.3 Dockerfile

At this step will be created the file that will be used to create the docker image. The Dockerfile has to be created into the root project and it doesn’t must to contain an extension, in other words, nothing like “Dockerfile.txt”, “Dockerfile.yml”, “Dockerfile.doc” or “Dockerfile.sh”.

# https://spring.io/guides/gs/spring-boot-docker/
#FROM openjdk:11
FROM adoptopenjdk/openjdk11:latest
VOLUME /tmp

ARG DEPENDENCY_CLASS=target/dependency
COPY ${DEPENDENCY_CLASS}/BOOT-INF/lib        /app/lib
COPY ${DEPENDENCY_CLASS}/META-INF            /app/META-INF
COPY ${DEPENDENCY_CLASS}/BOOT-INF/classes    /app

CMD ["java","-Dspring.profiles.active=${SPRING_PROFILE}","-cp","app:app/lib/*","com.bbpipeline.BBPipelineApplication"]

Realize that the “target/dependency” folder is used into Dockerfile, because of this folder that into “bitbucket-pipeline.yml” is created the artifact “target/**” and has the “SPRING_PROFILE” as environment variable too, this variable that was informed as an environment variable on Heroku.

Look that, into the command line used to start the application into docker is used the “CMD”, this one is used because of Heroku can inform the environment variable, because if it was with “ENTRYPOINT” this doesn’t work.

3.4 Application.properties

Into the “application.properties” will be added to the line “server.port=${PORT}”, this line allows that when the application starts the Heroku could inform what port the application will run. If the application is with the developer it will be used the profile “dev”, this line will be ignored and the port will be informed by the respective profile describe into “application.yml”.

spring.profiles.active=dev
# Server port
server.port=${PORT}

#logging
logging.level.org.springframework.data=debug
logging.level.=error

spring.main.allow-bean-definition-overriding=true

After executing these steps, the application will start on Heroku and it will be possible to check into the log that the application started with the heroku profile.

It’s could say that the process flow is simple, basically, there is an entrance that is a commit, there is processing that will run inside on Bitbucket and an out that will be the deploy the docker image on Heroku.

The project repository on Bitbucket:

git clone https://MaironCosta@bitbucket.org/maironpublic/test-bitbucket-pipeline-heroku.git
git clone git@bitbucket.org:maironpublic/test-bitbucket-pipeline-heroku.git

Thank you for following until the final and I hope that this can help you!

DEV Community: Mairon Costa

Testes de Integração no Spring Boot: H2 vs @MockBean com exemplos reais

1. Introdução

2. Visão Geral do Projeto

2.1. Dependências do Maven (pom.xml)

2.2. Configuração dos @Bean

2.3. Estrutura de Classes

2.4. Fluxo da Aplicação

2.5. application.yml (ambiente dev)

3. Teste de Integração com H2

3.1. application.yml para testes

3.2. Configuração dos @Bean para teste

3.3. O Teste

4. Teste de Integração com @MockBean

5. Quando usar H2 ou @MockBean?

6. Links de Referência

Debug Golang com VSCode

Sumário

Sistema e Configurações

Pré-Requisitos

Instalar Go no VSCode

Instalar o DLV no VSCode

Template básico do arquivo de configuração

Configurando o projeto

Inicializando a aplicação no modo debug

Conclusão

Referências

Apêndices

AWS Lambda com Localstack

Setup

Configuração

AWS CLI

AWS SAM CLI

Localstack Docker

PyCharm com AWS Lambda

Concluído!

Referências

Algumas Cloud Computing

AWS Lambda with Localstack

AWS Lambda with Localstack

Setup

Configuration

AWS CLI

AWS SAM CLI

Localstack Docker

PyCharm with AWS Lambda

It's Done!

References

Some Cloud Computing

Bitbucket-Pipeline: How to deploy a docker image to Heroku using Springboot

1. Heroku

1.1 Creating the application on Heroku

1.2 Adding the environment variable

1.3 API Key

2. BitBucket

2.1 Turn on Pipeline

2.2 Adding the environment variable

3. Application

3.1 Application.yml

3.2 Bitbucket-pipeline.yml

3.3 Dockerfile

3.4 Application.properties

2.1. Dependências do Maven (`pom.xml`)

2.2. Configuração dos `@Bean`

2.5. `application.yml` (ambiente dev)

3.1. `application.yml` para testes

3.2. Configuração dos `@Bean` para teste