03 - Estudo de Microsserviços ingresso.x - Monorepo e Docker

🔓 Esse artigo é o terceiro de uma sequência de estudo em andamento.

---

Padronização
Padronização, normalização, normatização ou estandardização é o processo de desenvolvimento e implementação de normas técnicas. A padronização tem como objetivo definir especificações técnicas que auxiliem na maximização da compatibilidade, reprodutibilidade, segurança ou qualidade de determinado processo, produto ou serviço.

Fonte: Wikipédia

O texto abaixo é referente à branch feature/initial-main-000 do repositório de estudo.

---

🧭 Orientação

O desenvolvimento de software é cercado de ritos, formações inteiras são criadas com o objetivo de dar assertividade ao planejamento; passando pelo defasado "Waterfall" até o "Desenvolvimento Ágil e Limpo". Os ritos iniciais devem criar linhas gerais de desenvolvimento, as guidelines.

Cada microsserviço pode ser escrito de um jeito, torna-se tentador novos serviços serem criados com a "big next thing". Devs entusiasmados podem subestimar trade-offs para adotar tecnologias emergentes diferentes das linhas gerais. Damos a isso o nome de "dispersão técnica". Cultive esse entusiasmo, mas não permita que ele aumente desordenadamente sua dispersão técnica

Não estou dizendo para criar softwares sempre com ${qualquer_tecnologia_antiga}. Mas devemos introduzir aos poucos novas tecnologias ao que foi previamente acordado nas guidelines. Elas levam a padronização o que reduz a dispersão técnica. Devemos ter foco.

---

💍 Um Para a Todos Dominar

Em projetos é comum clonar e levantar um a um repositórios git para desenvolver. Isso pode ser uma dor de cabeça multiplicada pelas tecnologias, versões e configurações.

Ciclos de Desenvolvimento, Processos de Implantação e a Introdução e Descontinuação devem ser estáveis, padronizados. Isso leva a estabilidade, primeiro princípio da disponibilidade. Rodar o projeto deveria ser tão simples quanto o possível, no nosso caso podemos instalar o docker e o docker compose responsável por levantar todas as imagens necessárias para rodar local

Após o docker e o docker compose instalados encontre o arquivo ./packages/cine-ticket-front-site/.sample_env e crie uma copia dele com o nome de .env.

Arquivos .env devem estar no gitignore e por segurança nunca são comitados nos repositórios de código, para que não existam vazamento de dados.

então na raiz do projeto, digite o seguinte comando:

$ docker compose up --build

Deve demorar alguns minutos até que as imagens dos dockerfiles sejam construídas. Ao término do processo, acesse o endereço http://localhost:8080 e teremos a página inicial, o front-end de nosso projeto:

Projeto inicial rodando local após docker instalado.

Um repositório para todos dominar! Um gerenciador para auxiliar nessa tarefa. São nossas guidelines, nosso padrão de desenvolvimento. Analisemos a estrutura de pastas atual da raiz do projeto (tag v0.0.0):

  $ tree
  .
  ├── .vscode
  ├── docs
  |    ├── icons
  |    ├── logo.png
  |    └── project.png
  └── packages
  |    ├── cine-ticket-front-site
  |    └── cine-ticket-nginx
  ├── .dockerignore
  ├── .eslintignore
  ├── .eslintrc.json
  ├── .gitignore
  ├── .prettierignore
  ├── .prettierrc
  ├── docker-compose.yml
  ├── jest.config.ts
  ├── jest.preset.js
  ├── nx.json
  ├── package-lock.json
  ├── package.json
  ├── README.md
  └── tsconfig.base.json

Trata-se de um monorepo que iremos evoluir, nele se concentrarão nossos microsserviços, imagens de infra e suporte como bancos, caches, storages, filas, etc...

Observe dentro da pasta packages os diretórios cine-ticket-front-site e cine-ticket-nginx, são as aplicações que estão servindo a página localhost:8080. No mesmo nível de packages encontra-se o arquivo docker-compose.yml, que faz tudo acontecer, vamos esmiuçá-lo a seguir:

version: '3.7'
services:
  cine-ticket-nginx:
    build:
      context: ./packages/cine-ticket-nginx
      dockerfile: Dockerfile
    ports:
      - 8080:80
    depends_on:
      - cine-ticket-front-site
    networks:
      - cine-ticket-network

  cine-ticket-front-site:
    build:
      context: ./packages/cine-ticket-front-site
      dockerfile: Dockerfile
    ports:
      - 3080:3000
    volumes:
      - ./packages/cine-ticket-front-site/src:/usr/src/app/src
      - ./packages/cine-ticket-front-site/dist:/usr/src/app/dist
    env_file: ./packages/cine-ticket-front-site/.env
    command: npm run start:dev
    tty: true
    networks:
      - cine-ticket-network

networks:
  cine-ticket-network:

Nosso dockerfile.yml define os serviços de:

1. cine-ticket-nginx:

   • build:
     • context: constrói a imagem a partir do diretório ./packages/cine-ticket-nginx
     • dockerfile: Usa um arquivo Dockerfile que se encontra no diretório do context para dar as instruções de como montar a imagem.
   • ports: Mapeia as solicitações na porta 8080 da máquina hospedeira para porta 80 para da imagem
   • depends_on: O serviço cine-ticket-front-site precisa estar de Pé, "up and running" antes que esse serviço esteja funcional
   • networks: Rede na qual esta imagem vai estar integrada, para que tenhamos comunicação adequada no que podemos chamar de "por debaixo do capô" deve ser na mesma rede de sua dependência

2. cine-ticket-front-site:

   • build:
     • context: constrói o container a partir do diretório ./packages/cine-ticket-front-site
     • dockerfile: Usa um arquivo Dockerfile que se encontra no diretório do context para dar as instruções de como montar o contêiner.
   • ports: Mapeia as solicitações na porta 3080 da máquina hospedeira para porta 3000 do contêiner
   • volumes:
     • Mapeia de maneira a sincronizar diretórios entre a máquina hospedeira e o contêiner hospedeira:contêiner, útil para hot-reload (esse caso em especifico) e persistência de dados.
     • ./packages/cine-ticket-front-site/src:/usr/src/app/src
     • ./packages/cine-ticket-front-site/dist:/usr/src/app/dist
     • env_file: Define arquivo para injetar variáveis de ambiente para o container.
     • command: comando que será executado quando o contêiner for iniciado a partir da imagem Docker
     • tty: Permite que você veja a saída interativa e do container.
   • networks: Rede

3. networks: Define a rede cine-ticket-network
   
   
   

Outro arquivo interessante para nossa jornada é o ./packages/cine-ticket-nginx/conf/nginx.conf

events {
    worker_connections  4096;  ## Default: 1024
}

http {
  server {
    listen 80;

    location / {
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

      proxy_pass http://cine-ticket-front-site:3000;

      proxy_set_header Host $host;
      proxy_set_header X-NginX-Proxy true;
      proxy_redirect off;
      proxy_set_header X-Real-IP $remote_addr;
    }
  }
}

Ele define nosso proxy reverso. Um intermediário, melhorando o desempenho e a segurança, encaminhando solicitações para o serviço cine-ticket-front-site:3000 e manipulando os cabeçalhos para a comunicação correta entre os componentes.

vamos considerar para fins didáticos que apenas as requisições servidas pelo NGINX são públicas e o restante estão debaixo da rede cine-ticket-network, nossa "nuvem local" que vai possuir microsserviços privados.

---

🤓 Conclusão (por hora)

Vimos que padronização garante estabilidade reduzindo dispersão técnica, baixamos o docker e o docker compose e entendemos como as partes do nosso monorepo interagem entre si.

Adotaremos como padrão de desenvolvimento muitos dos conceitos apresentados nesse artigo para nossos futuros microsserviços.

Mantenha o entusiasmo mas reduza o quanto puder a dispersão técnica.

Utilizamos Monorepo e Docker para alcançar nossos objetivos.

---

👣 Próximos passos

Vamos finalmente iniciar a codar nosso primeiro Microsserviço de Catálogo, a partir de diagramas propostos e com guidelines claras e objetivas que apenas boas documentações garantem.

Até breve.

---

👈 Anterior	Próximo 👉
Alguns Desafios	Microsserviço de Catálogo