Implantação de Sites

Desde o início da cultura de Monitoramento e a da imersão da equipe de tecnologia do NOSSAS, que foi voltada a discutir manutenção, encontramos uma necessidade de otimizar nossas aplicações para ter maior controle dos recursos alocados em cada parte funcional do sistema.

Essa arquitetura de sistema já foi debatida diversas vezes entre a equipe e aqui iremos atuar na parte funcional denominada Sites.

Sites são aplicações web que precisam responder a um endereço na internet e renderizar uma página HTML, podemos usar um CMS open-source ou até mesmo criarmos a aplicação web para tal processamento, o mais importante dessa parte funcional são suas camadas que definem suas características.

Vamos descrever cada ferramenta dentro dessa parte funcional:

• Servidor DNS: Usamos o serviço Route53 da Amazon, com isso é possível gerenciar o domínio comprado em qualquer loja como Registro.br e GoDaddy internamente, basta configurar os Nome de Servidores (NS) gerados no Route53 para que um novo domínio passe a ser gerenciado pela nossa tecnologia.
• Instância VPS: Instância VPS são máquinas virtuais onde instalamos nossas aplicações, atualmente usamos Instâncias da Amazon com o serviço EC2, mas pra esse conceito a empresa que compramos a instância VPS é indiferente o que precisamos mesmo é um IP que não irá mudar e seja público (porta 80 e 443 liberada) pois é usando desse IP que iremos fazer o roteamento no Servidor DNS.
• Docker: O Docker somado ao Docker Compose serve para orquestrar nossas aplicações internas do servidor, podemos usar de outras estratégias para disponibilizar nossas aplicações, mas iremos manter o Docker pela facilidade de aprendizado e manutenção.
• Traefik + Etcd: O Traefik é a primeira aplicação que irá responder a conexões na Instância VPS feitas na porta 80 e 443, ele tem a responsabilidade de direcionar essas conexões através da rede interna do Docker a uma outra aplicação atuando como um Proxy. Além de configurações básicas que o Traefik carrega a partir das definições de um arquivo docker-compose.yml ele usa o Etcd para carregar configurações dinâmicas e essa combinação permite criarmos rotas de maneira automatizada e programática.
• Aplicações Web: São aplicações que respondem com uma página HTML a partir de uma solicitação do navegador. Nessa ilustração acima temos 3 diferentes aplicações que podem responder com páginas HTML, BONDE (Público), DjangoCMS e Wordpress, é importante elucidar que cada aplicação tem sua maneira de renderizar páginas HTML, mas todas usam o endereço requisitado para saber quais dados deve usar para renderizar sua página HTML.

Migrando Sites para um servidor dedicado

Leitura recomendada: https://chatgpt.com/share/67093587-a8a0-8010-86c3-06699da23fbd

Entendendo nossa arquitetura projetada como microserviços mas executada em uma infraestrutura monolítica, isolamos um primeiro serviço crítico, o Sites, e iremos executá-lo em um servidor dedicado, tornando possível escala-lo de acordo com a demanda e remove-lo de um único ponto de falha.

Problema 1: Domínio e Nome de Servidores

Por ter uma infraestrutura monolítica, nós apoiamos a usar um único domínio para definir o ponto central de acesso o bonde.org dessa maneira tínhamos definições de endereços como alguns exemplos abaixo.

• api-graphql.bonde.org
• slug-de-campanha.bonde.org
• cms.bonde.org
• admin-canary.bonde.org
• app.bonde.org
• metabase.bonde.org
• api-rest.bonde.org
• api-activists.bonde.org

Como você pôde ver acima, vários serviços e aplicativos com responsabilidades completamente destintas estão endereçadas como subdomínio de um mesmo ponto central, isso era simplificado pelo uso do Docker e do Traefik que possibilitavam disponibilizar todos os nossos microserviços em uma única rede de acesso, isso foi representado neste repositório.

Para avançar é necessário organizar esses subdomínios em possíveis grupos de serviços para que possamos então executar esses grupos de serviços em servidores específicos, foi usado a técnica de Domain Driven Development, para agrupar esses serviços.

Hoje existe um funcionamento singular no BONDE (Versão Pública) que torna o domínio bonde.org um ponto principal para criação de Sites, pois usamos a URL slug-do-site.bonde.org para Sites que ainda não compraram um domínio. Manter a raiz do domínio bonde.org para os CMS garante que o conteúdo principal continue acessível no mesmo endereço, o que preserva a integridade das URLs e evita confusão para os usuários.

Criar um subdomínio para os serviços do servidor antigo é uma maneira prática de isolar essa parte do sistema enquanto fazemos a migração. Podemos criar um único domínio como por exemplo legacy.bonde.org como uma maneira temporária de dizer que esses serviços estão em processo de migração:

• api-graphql.legacy.bonde.org
• slug-de-campanha.bonde.org
• cms.bonde.org
• admin-canary.legacy.bonde.org
• app.legacy.bonde.org
• metabase.legacy.bonde.org
• api-rest.legacy.bonde.org
• api-activists.legacy.bonde.org

ou já criar subdomínios pensando os futuros agrupamentos como apis.bonde.org que poderia ter internamente os serviços

• graphql.apis.bonde.org
• rest.apis.bonde.org
• activists.apis.bonde.org

IMPORTANTE: É muito importante executar esse processo de migração em um momento previsto e comunicado com o restante das equipes, pois isso irá impactar o funcionamento das aplicações por algumas horas.