A orquestração de deploys para aplicações corporativas exige consistência, rastreabilidade e eliminação de falhas humanas. O Java Spring Boot, padrão indiscutível no desenvolvimento de software corporativo, beneficia-se profundamente de processos de Integração Contínua e Entrega Contínua (CI/CD) aliados à conteinerização.

• Pré-requisitos

Para acompanhar a implementação arquitetural deste guia, certifique-se de cumprir os seguintes requisitos:

• Conta ativa no Locaweb Cloud: com acesso liberado ao painel de controle.
• Chave de autenticação SSH: uma chave privada SSH (arquivo .key ou .pem) gerada e com a respectiva chave pública cadastrada no painel do Locaweb Cloud. No seu terminal local, ajuste a permissão da chave privada com chmod 400 sua-chave.key.
• Conhecimento básico de terminal: familiaridade com navegação de diretórios e uso do gerenciador de pacotes em ambientes Linux.
• (Opcional) Domínio próprio: um domínio ou subdomínio apontando para o IP público da VM de aplicação, necessário para emitir um certificado HTTPS gratuito com Let’s Encrypt.

2.  Configuração de infraestrutura (painel)

A base de uma aplicação segura é o isolamento de rede. Criaremos uma Virtual Private Cloud (VPC) para abrigar nossos servidores, garantindo que o banco de dados não seja exposto diretamente à internet.

2.1. Criação da Rede VPC e Tiers

1. Navegue até Rede > VPC no painel do Locaweb Cloud e clique em Adicionar VPC.
2. Defina o bloco CIDR principal (exemplo: 10.0.0.0/16) e selecione a Oferta de VPC adequada ao seu projeto.
3. Dentro da nova VPC, acesse a aba Redes e clique em Adicionar novo tier.
4. Crie um tier chamado Tier-Aplicacao (exemplo de CIDR: 10.0.1.0/24) para o servidor da aplicação Spring Boot e outro chamado Tier-BancoDados (exemplo de CIDR: 10.0.2.0/24) para o PostgreSQL.

2.2. Provisionamento das máquinas virtuais (VMs)

Serão necessárias duas instâncias: uma para o banco de dados e outra para a aplicação.

1. Navegue até Computação > VMs e clique em Adicionar VM.
2. VM de Banco de Dados:
   • Template: selecione Ubuntu 22.04 LTS.
   • Oferta: escolha um plano com recursos de CPU e RAM otimizados para banco de dados (exemplo: 4 vCPUs, 8 GB de RAM).
   • Rede: conecte ao Tier-BancoDados.
   • Chave SSH: selecione a sua chave pública previamente cadastrada.
   • Disco secundário: durante a criação, adicione um Datadisk (exemplo: 50 GB) que será usado para persistir os dados do PostgreSQL.
3. VM da Aplicação:
   • Repita o processo, escolhendo um plano adequado para a carga do seu projeto (exemplo: 2 vCPUs, 4 GB de RAM).
   • Template: Ubuntu 22.04 LTS.
   • Rede: conecte ao Tier-Aplicacao.
   • Chave SSH: selecione a mesma chave pública cadastrada.

2.3. IPs Públicos, encaminhamento de porta e regras de Firewall

A VM de banco de dados permanecerá isolada, comunicando-se apenas com a VM da aplicação via IP privado. Para a VM da aplicação receber tráfego web:

1. Acesse Rede > VPC > [Sua VPC] > IPs Públicos e clique em Obter um novo IP.
2. Selecione o IP adquirido e vá para a aba Encaminhamento de porta. Crie regras direcionando as portas públicas para a VM da aplicação conforme a tabela abaixo:

Porta pública	Porta privada	Protocolo	Destino	Finalidade
22	22	TCP	VM-SpringBoot	Acesso SSH
8080	8080	TCP	VM-SpringBoot	API Spring Boot
80	80	TCP	VM-SpringBoot	HTTP (Let’s Encrypt)
443	443	TCP	VM-SpringBoot	HTTPS

 

1. Na aba Firewall, adicione regras de entrada liberando o tráfego de entrada (inbound) para as portas 22, 80, 443 e 8080. Para a porta 22 (SSH), recomendamos fortemente restringir o CIDR de origem ao IP da sua rede de administração (exemplo: <SEU_IP_DE_ESCRITORIO>/32), em vez de liberar 0.0.0.0/0.

2.4. ACL de rede entre os Tiers

Para que a VM da aplicação alcance o banco de dados pela rede privada, configure a ACL da VPC permitindo o tráfego da sub-rede de aplicação até a porta do PostgreSQL:

Origem (CIDR)	Destino	Protocolo	Porta	Ação
10.0.1.0/24 (Tier-Aplicacao)	Tier-BancoDados	TCP	5432	Permitir
0.0.0.0/0	Tier-BancoDados	TCP	5432	Negar

 

3. Preparação do disco de dados na VM de banco de dados

Para que os dados do PostgreSQL sobrevivam a reinicializações e recriações da instância, vamos formatar e montar o disco secundário de forma persistente. Acesse a VM de banco de dados via SSH (fazendo um salto a partir da VM de aplicação, já que o banco não possui IP público) e execute:

Bash

# Lista os discos disponíveis para identificar o disco secundário 
(geralmente /dev/vdb)
lsblk

# Cria o sistema de arquivos ext4 no disco secundário identificado
 sudo mkfs.ext4 /dev/vdb

# Cria o ponto de montagem onde os dados do PostgreSQL 
serão armazenados 

sudo mkdir -p /mnt/dados

Em vez de referenciar o disco pelo nome do dispositivo, usamos o UUID estável no /etc/fstab:

Bash

# Exibe o UUID do disco secundário
sudo blkid /dev/vdb

# Copie o valor de UUID exibido na saída

# Adiciona a montagem permanente usando o UUID (substitua )
echo 'UUID=  /mnt/dados  ext4  defaults,nofail,noatime  0  2' 
| sudo tee -a /etc/fstab

# Monta todos os pontos definidos no fstab e confirma o resultado
sudo mount -a
df -h /mnt/dados

 

4. Configuração do banco de dados: PostgreSQL

Como estamos operando em IaaS, o banco de dados é configurado dentro da VM designada no Tier-BancoDados. Ainda conectado a essa VM via SSH, instale o PostgreSQL:

Bash

# Atualiza a lista de pacotes e instala o servidor PostgreSQL e
 utilitários extras
 sudo apt update && sudo apt install postgresql postgresql-contrib -y

# Habilita o serviço para iniciar junto com o sistema e o inicia
 imediatamente
sudo systemctl enable --now postgresql

Confirme a versão instalada para localizar corretamente os arquivos de configuração:

Bash

# Exibe a versão instalada; o número compõe o caminho dos 
arquivos de configuração
psql --version

4.1. Apontando o PostgreSQL para o banco e rede privada

Abra o arquivo de configuração principal para permitir que o PostgreSQL aceite conexões na interface da rede privada da Tier:

Bash

sudo nano /etc/postgresql/14/main/postgresql.conf

Altere a linha correspondente para escutar em todas as interfaces:

Snippet de código

listen_addresses = '*'

Para elevar a segurança, configure restrições diretamente no banco de dados, definindo quais origens possuem permissão para autenticação. Edite o arquivo de autenticação de host (HBA) para aceitar conexões apenas da Tier-Publica-Web (10.0.1.0/24):

Bash

sudo nano /etc/postgresql/14/main/pg_hba.conf

Adicione a seguinte linha ao final do arquivo para liberar a autenticação criptografada somente para a sub-rede da aplicação:

Snippet de código

# TYPE  DATABASE        USER            ADDRESS              METHOD

host    all             all             10.0.1.0/24       scram-sha-256

 

4.2. Criação das credenciais da aplicação

Acesse o prompt administrativo do PostgreSQL para criar a estrutura do projeto:

Bash

# Acessa o prompt administrativo do PostgreSQL como o 
usuário do sistema "postgres"
sudo -u postgres psql

No prompt do psql, execute os comandos abaixo:

SQL

-- Cria o banco de dados da aplicação

CREATE DATABASE app_db;

 

-- Cria o usuário da aplicação com senha criptografada
 (use uma senha forte real)

CREATE USER spring_user WITH ENCRYPTED PASSWORD '';

 

-- Concede todos os privilégios sobre o banco ao usuário criado

GRANT ALL PRIVILEGES ON DATABASE app_db TO spring_user;

 

-- Sai do prompt do psql\q

 

Reinicie o serviço para aplicar as configurações e encerre a sessão na VM de dados:

Bash

# Reinicia o PostgreSQL para carregar as novas configurações

sudo systemctl restart postgresql

 

# Encerra a sessão na VM-Postgres e volta ao terminal da VM Web

exit 

4.3. Configuração do application.properties

No arquivo src/main/resources/application.properties do seu projeto Java, estruture a string de conexão apontando para o IP privado da camada de dados. Recomenda-se a externalização das credenciais de acesso utilizando variáveis de ambiente.

Properties

# Conexão isolada via rede interna da VPC (Tier Web -> Tier DB)

# Substitua 10.0.2.5 pelo IP privado real da VM-Postgres

spring.datasource.url=jdbc:postgresql://10.0.2.5:5432/app_db

spring.datasource.username=spring_user

spring.datasource.password=${DB_PASSWORD}

spring.datasource.driver-class-name=org.postgresql.Driver

 

# Estratégia de geração de schema do Hibernate

spring.jpa.hibernate.ddl-auto=update

spring.jpa.properties.hibernate.dialect=org.hibernate.dialect.
PostgreSQLDialCore

 

# Porta de exposição da aplicação

server.port=8080

4.4. Configuração do Dockerfile no projeto Spring Boot

Crie um arquivo chamado Dockerfile na raiz do projeto Spring Boot para empacotar o artefato de maneira enxuta:

Dockerfile

# Imagem base enxuta com Java 17

FROM eclipse-temurin:17-jre-alpine

# Diretório de trabalho dentro do container

WORKDIR /app

# Copia o artefato gerado pelo build para dentro da imagem

COPY target/app.jar app.jar

# Porta exposta pela aplicação

EXPOSE 8080

# Comando de inicialização da aplicação

ENTRYPOINT ["java", "-jar", "app.jar"]

5. Deploy da aplicação (dois métodos)

Com a infraestrutura de rede isolada e o banco de dados configurado, você tem total autonomia para escolher a estratégia de publicação que melhor atenda ao fluxo operacional da sua equipe.

Método 1: CI/CD automatizado com Docker e GitHub Actions

Este é o método moderno recomendado. A cada push na branch main, o GitHub Actions compila a aplicação, gera a imagem Docker e dispara o deploy automatizado na VM via SSH, eliminando gargalos manuais.

1. No seu repositório do GitHub, acesse Settings > Secrets and variables > Actions e cadastre os seguintes Repository Secrets:
   • SSH_HOST: o IP público da sua VPC no Locaweb Cloud.
   • SSH_USER: o usuário de acesso remoto do servidor (exemplo: ubuntu).
   • SSH_KEY: o conteúdo completo do seu arquivo de chave privada SSH.
2. Estruture o arquivo de workflow em .github/workflows/deploy.yml:

YAML

name: Deploy Spring Boot na Locaweb Cloud
 


on:

  push:

    branches: [ main ]

 

jobs:

  deploy:

    runs-on: ubuntu-latest

    steps:

      - name: Checkout do código

        uses: actions/checkout@v4

 

      - name: Configurar JDK 17

        uses: actions/setup-java@v4

        with:

          distribution: temurin

          java-version: '17'

 

      - name: Compilar a aplicação com Maven

        run: mvn -B clean package -DskipTests

 

      - name: Deploy via SSH na VM Web

        uses: appleboy/ssh-action@v1.0.3

        with:

          host: ${{ secrets.SSH_HOST }}

          username: ${{ secrets.SSH_USER }}

          key: ${{ secrets.SSH_KEY }}

          script: |

            cd /home/ubuntu/app

            git pull origin main

            docker build -t spring-app .

            docker stop spring-app || true

            docker rm spring-app || true

            docker run -d --name spring-app --restart always -p 
8080:8080 spring-app

Método 2: Deploy manual com systemd

Caso sua operação ainda não utilize pipelines automatizados, envie o arquivo app.jar local para a VM Web via SCP:

Bash

# Copia o app.jar da máquina local para o diretório home na VM Web

scp -i sua_chave.key app.jar ubuntu@:/home/ubuntu/app.jar

Para garantir que a aplicação continue rodando em segundo plano e reinicie sozinha em caso de falhas, configure-a como um serviço gerenciado pelo systemd. Crie o arquivo de unidade:

Bash

 sudo nano /etc/systemd/system/springboot.service  

Adicione o conteúdo abaixo no arquivo:

Ini, TOML

[Unit]

Description=Aplicacao Spring Boot

After=network.target

 

[Service]

User=ubuntu

WorkingDirectory=/home/ubuntu

ExecStart=/usr/bin/java -jar /home/ubuntu/app.jar

SuccessExitStatus=143

Restart=always

RestartSec=10

 

[Install]

WantedBy=multi-user.target

Recarregue os daemons e inicialize o serviço:

Bash

# Recarrega o systemd para reconhecer o novo arquivo de serviço

sudo systemctl daemon-reload

# Habilita a aplicação para iniciar no boot e a inicia imediatamente

sudo systemctl enable --now springboot

6. Configuração de HTTPS com Let’s Encrypt

Para garantir total privacidade no tráfego de dados e eliminar alertas de segurança, configure o Nginx como proxy reverso gerenciando o certificado SSL gratuito do Let’s Encrypt. Na VM Web, execute:

Bash

# Instala o servidor web Nginx e o cliente Certbot

sudo apt update && sudo apt install -y nginx certbot 
python3-certbot-nginx


# Cria o arquivo de configuração do Nginx para a aplicação

sudo nano /etc/nginx/sites-available/springboot.conf

Adicione as regras de proxy direcionando as requisições para a porta 8080:

Nginx

server {

    listen 80;

    server_name seu-dominio.com.br;

 

    location / {

        proxy_pass http://127.0.0.1:8080;

        proxy_set_header Host $host;

        proxy_set_header X-Real-IP $remote_addr;

        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        proxy_set_header X-Forwarded-Proto $scheme;

    }

}

Ative o site, valide as configurações e emita o certificado digital:

Bash

# Cria o link simbólico que ativa o site no Nginx

sudo ln -s /etc/nginx/sites-available/springboot.conf 
/etc/nginx/sites-enabled/

# Testa a sintaxe da configuração do Nginx antes de aplicar

sudo nginx -t

# Recarrega o Nginx aplicando a nova configuração

sudo systemctl reload nginx

# Gera e instala o certificado TLS para o domínio 
(substitua pelo seu domínio real)

sudo certbot --nginx -d seu-dominio.com.br

7. Validação 

A validação atesta a resiliência do bloqueio e o sucesso da topologia de rede implementada em formato IaaS.

7.1. Teste interno na VM Web

Conectado à VM-SpringBoot, valide se a aplicação está respondendo localmente:

Bash

# Confirma que o serviço da aplicação está ativo e rodando

sudo systemctl status springboot 

# Faz uma requisição local ao endpoint de saúde da aplicação

curl -I http://localhost:8080/api/health

7.2. Teste externo da aplicação (máquina local)

A partir do terminal do seu computador local, faça uma requisição externa utilizando o IP público da VPC:

Bash

curl -I http://:8080/api/health

 

Se o HTTPS já estiver configurado, valide a segurança da rota executando curl -I https://seu-dominio.com.br/api/health.

7.3. Teste de isolamento do banco de dados (crítico)

Este é o teste que comprova a segurança da arquitetura. A partir da sua máquina local, tente forçar uma conexão direta ao banco de dados pela internet pública:

Bash

psql -h -U spring_user -d app_db -p 5432

 

8. Solução de problemas (Troubleshooting)