Skip to content

Devops ‐ Deploy

Jump to bottom
João Matheus Lamão edited this page May 16, 2025 · 2 revisions

🛠️ Deploy

🔍 Visão Geral

Objetivo

A prática de DevOps adotada pela equipe visa integrar o desenvolvimento com operações, permitindo a entrega contínua e automatizada de aplicações em produção. A implementação do pipeline CI/CD com GitHub Actions proporciona maior agilidade, controle e rastreabilidade durante o processo de entrega, reduzindo erros humanos e aumentando a confiabilidade dos deploys.

Entre os principais conceitos utilizados estão:

  • CI/CD (Integração Contínua e Entrega Contínua) com GitHub Actions
  • Ambientes containerizados com Docker
  • Pipelines independentes para cada repositório, com deploy individualizado e isolado

Relevância para o projeto

No contexto deste projeto, a automação dos deploys foi fundamental para manter a consistência entre os ambientes de desenvolvimento e produção. A adoção de DevOps possibilitou:

  • Deploy rápido e sem intervenção manual
  • Maior confiabilidade ao subir atualizações
  • Padronização entre os ambientes (dev/prod)

Prós:

  • Redução de erros operacionais
  • Integração simples com o GitHub
  • Escalabilidade futura com mínima adaptação

Contras/dificuldades enfrentadas:

  • Curva de aprendizado inicial para configurar workflows CI/CD
  • Configuração manual da infraestrutura na EC2
  • Dependência da configuração correta dos secrets para conexão SSH

⚙️ Implementação

O que foi feito

A automação dos deploys foi feita via GitHub Actions, com pipelines separados por repositório, integrando cada um com a instância EC2 da AWS. Cada aplicação (ETL em Python, backend em Spring Boot, frontend em Vue) possui seu próprio repositório e workflow YAML individual.

Cada repositório contém:

  • Um Dockerfile específico para sua aplicação
  • Um workflow .yml no GitHub Actions para build e deploy individual

O processo de deploy consiste em:

  • Gatilho a cada push na branch main
  • Conexão segura via SSH com EC2 usando chave privada criptografada
  • Pull do repositório na máquina e execução do docker build e docker run

Resumo técnico:

  • Arquivos .github/workflows/deploy.yml separados em cada repositório
  • Chaves SSH armazenadas via GitHub Secrets
  • Dockerfiles específicos por serviço
  • Deploy automatizado e desacoplado entre aplicações

Desafios e soluções

  • Problema: Primeiros testes falharam por permissões incorretas de execução do SSH no runner.
    Solução: Corrigido com permissões 600 para a chave via chmod.

  • Problema: Deploy falhava ao acessar diretório do projeto na EC2.
    Solução: Criado script para garantir o caminho correto do projeto e permissões apropriadas.

  • Problema: Diferentes configurações de build entre Vue, Spring e Python.
    Solução: Separação clara por repositório, cada um com seu Dockerfile e pipeline CI/CD própria.

📌 Justificativas

Tecnologias Escolhidas

Tecnologia Alternativas Justificativa
GitHub Actions Jenkins, GitLab CI Integração nativa com o GitHub, fácil configuração, baixo overhead
EC2 AWS ECS, Heroku Maior controle da infraestrutura e suporte a serviços heterogêneos
Docker Kubernetes (K8s) Solução mais simples e direta para containerização individualizada

Decisões de Arquitetura

  • EC2 foi escolhida por oferecer flexibilidade de configuração e permitir hospedar múltiplos serviços em um único servidor, ideal para o estágio inicial do projeto.
  • Containers Docker individuais, um por aplicação, com repositórios separados e pipelines independentes.
  • Divisão em múltiplos repositórios mantém a separação de responsabilidades entre os serviços, com deploys isolados e mais fáceis de versionar.
  • O uso de EC2 também permite upgrade vertical ou horizontal conforme o crescimento da base de usuários.

Dimensões da máquina EC2

  • Tipo atual: t3.medium (2 vCPUs, 6 GiB RAM)
  • Sistema: Ubuntu 22.04 LTS

Justificativa da escolha atual

  • Suficiente para hospedar os três serviços (ETL, API, Frontend) com baixa concorrência simultânea.
  • Custos reduzidos e operação simplificada na fase inicial de implantação.
  • Boa base para testar automações, pipelines e a confiabilidade do deploy.

Expectativa de escala

A instância t3.medium foi escolhida por equilibrar custo-benefício e oferecer recursos suficientes para hospedar três serviços containerizados simultaneamente:

O serviço de ETL em Python executa tarefas periódicas com uso moderado de CPU e memória.

A API em Spring Boot é responsiva e escalável, porém com carga baixa inicialmente.

O frontend em Vue consome poucos recursos e pode ser servido diretamente por um servidor web leve como Nginx.

Além disso, a instância suporta testes de carga, pipelines CI/CD em execução e acessos simultâneos dentro da expectativa atual de até 100 usuários no primeiro mês.

A arquitetura baseada em Docker garante isolamento e reutilização dos recursos de forma eficiente, maximizando o aproveitamento dos 2 vCPUs e 6 GB de memória disponíveis.

Plano futuro de escalabilidade

Para atender ao crescimento previsto:

  • Monitoramento de métricas com CloudWatch e/ou Prometheus + Grafana.
  • Adoção de Auto Scaling com múltiplas EC2 ou migração gradual para AWS ECS ou EKS (container orchestration com escalabilidade automática).
  • Separação de serviços críticos em instâncias distintas ou em fargate containers.
  • Armazenamento de dados e logs fora da EC2 (ex: S3, RDS, etc.), reduzindo acoplamento e melhorando performance.

Esse planejamento garante que o ambiente atual atenda à demanda inicial, mas já está pronto para ser evoluído com mínima refatoração à medida que a base de usuários cresce.

Clone this wiki locally