Skip to content

JohnnyPaixaum/Continuous-Deploy-com-Docker-Swarm

Repository files navigation

Continuous Deploy com Docker Swarm

Aqui será abordado de forma teorica sem o intuito de ser um tutorial sobre o projeto em questão em que desenvolvi com o objetivo de demonstrar habilidades e conhecimento relacionados a Docker, CI/CD, Automação, Shell_Script, Clasterização, Arquivos YAML's, Storage e Sistemas GNU/Linux. Posteriormente ao fim desse "artigo" estarei implementando o Nexus Repository para versionamento de Imagens Docker e futuramente recriando essa mesma estrutura com base no Kubernetes, HA Proxy, Jenkins como Dashboard de Deployments e aplicões de monitoramento(EX: Prometheus, Grafana...).

In_Build

Aplicacãoes utilizadas e suas respectivas funcionalidades e funçoes dentro do projeto:

  • Docker Swarm: Conjunto de servidores para funcionamento de um Cluster Docker Swarm que consiste em 3 servidores onde é possível garantir LoadBalance e Alta Disponibilidade entre os serviços em funcionamento nele. Por exemplo: Vamos teorizar que uma aplicação web estivesse em Docker Swarm, então criaremos um serviço dessa aplicação que consistiria em configurar e adaptar ela ao Docker, com o serviço criado escalaremos ele para 6, logo haverá 6 containers idênticos com a aplicação web espalhados uniformemente entre os 3 nós do Swarm, sendo assim, caso o nó 03 caia, ainda haveria os nós 01 e 02 disponíveis com a aplicação web que não seria afetada pela queda do nó 03 garantindo assim a disponibilidade da aplicação web, além de promover um LoadBalance que consistiria em distribuir as requisições entre os containers do serviço contido nos nós evitando então uma carga elevada em apenas um ponto. E para se ter uma estrutura automatizada há um conjunto de aplicações que será explicadas a baixo.

  • Traefik: É um proxy reverso capaz de viabilizar o LoadBalance e ajudar na Alta Disponibilidade dos serviços rodando em Docker, no qual, é a porta que intercepta e roteia todas as solicitações recebidas: conhece toda a lógica e todas as regras que determinam quais serviços tratam de quais solicitações (com base no caminho , no host , cabeçalhos , e assim por diante ...).

  • Rundeck: É uma ferramenta de automação de rotinas, que em nossa estrutura fornece a função de criação automátizada e contínua de serviços a partir de um git push feito por um Dev no Gitlab. Assim criando um serviço no Docker Swarm conrrespondente a um projeto no Gitlab.

  • Glusterfs: É um software de escalabilidade de armazenamento, sendo o responsável por distribuir e persistir os dados dos volumes utilizados e criados pelos serviços entre os nós do Docker Swarm.

A figura a seguir mostra a arquitetura do projeto: Arquitetura Kubernetes

Workflow:

Tudo começaria com um Push efetuado por um Develop a um projeto no Gitlab no qual o Rundeck esteja configurado, em seguida o Gitlab enviará um Webhook para um projeto no Rundeck conrrespondente ao projeto em questão e iniciará as tarefas necessarias para que tal projeto "suba" de forma automatizada no Cluster de Docker Swarm, e conforme as informações passadas nas configurações de como o projeto deve "subir" no docker(como em um arquivo .yaml ou via CLI) o Traefik irá criar um Hostname para o acesso ao Service relacionado ao projeto em questão. Em caso de um Service de um projeto já existente o Rundeck iria apenas criar uma nova Image de Docker e atualizaria os containers conrrespondente ao Service do projeto.

Como Aprimorar:

Releases

No releases published

Packages

No packages published