Este é um exemplo de um de nossos pipelines de entrega que realizam atividades automáticas de entregas de microsserviços, APIs e até mesmo frontends .
Neste exemplo nós temos a seguinte estrutura:
Temos uma pasta específica para cada módulo, no caso o de back-end e o de front-end, cada um com suas responsabilidades, variáveis de ambiente etc.
Para cada módulo temos um Dockerfile, que determina como será cada uma das imagens, seus comportamentos etc.
É muito importante que você tenha em mente onde será o seu Registry de Imagens de Containers, no caso, você pode usar um DockerHub, porém o próprio Gitlab oferece um Registro de Imagens para que você possa utilizá-lo também, veremos isto em detalhes em uma próxima oportunidade.
Empresas geralmente tem seu registry corporativo, de maneira geral, este serve como um "banco de imagens" dos serviços e componentes da sua Arquitetura de Serviços, o que dará inclusive origem ao seu catálogo num futuro. Quando você estiver utilizando o Kubernetes, basicamente o que o serviço de deployment fará é sempre "consultar" se existem novas versões das imagens e dependendo do caso já realizar o deploy automático:
Pipeline no GitLab
Toda a vez que você quiser criar um pipeline automático para seus projetos, você poderá criar na raiz do seu módulo/projeto o arquivo .gitlab-cy.yml, como exibido abaixo:
Este é o arquivo que define todo o processo de pipeline do seu projeto, este por sua vez fornece todos os passos necessários para a sequencia do seu fluxo de atividades, no nosso caso, iremos realizar os seguintes passos apenas:
Logar no Registry
Realizar o build das imagens de backend e front-end
Realizar o push das imagens para o repositório
E por último atualizar o deployment para o Kubernetes de homologação.
Com base nos passos, acima, nós iremos utilizar o seguinte código para executar o pipeline:
Vamos agora cortar o entendimento de cada parte deste pipeline:
|  | Aqui estamos dizendo que este é um pipeline que usa a imagem docker padrão docker:latest, e que no estágio de build vamos usar o serviço dind da imagem docker. |
Logar no Registry |  | Nas linhas 7 e 8 vamos logar no ambiente de Registry para poder realizar o push (depósito) das imagens. Veja que nós referenciamos a variáveis de ambientes, que é um recurso que veremos no seguinte tópico deste post. |
Realizar o build das imagens de backend e front-end Realizar o push das imagens para o repositório |  | Da linha 9 a 18, nós chamamos o script que faz com que façamos o build e push das imagens para o registry em questão. |
Deployment para o Kubernetes de homologação. |  | Da linha 19 a 21, como esta imagem Docker não possui o utilitário kubectl, nós o instalamos na mesma e o deixamos configurado. Da linha 22 a 25 nós capturamos o conteúdo como arquivo da variável $K8SCONFIG e setamos como o KUBECONFIG para que o kubectl possa realizar as operações no cluster Kubernetes em questão. Na linha 26 e 27 nós apenas atualizamos um deployment já existente no Kubernetes, tendo como base a nova versão das imagens. |
Da maneira acima, todas as vezes que tivermos um commit na branch main, esta operação será disparada de forma automática.
Variáveis no Gitlab
Este é um recurso no Gitlab, mas existem também em outras ferramentas como GitHub, Azure DevOps, Harness etc. Que permite com que guardemos nossas informações de ambiente, senhas, arquivos etc, e possamos referenciá-los como no exemplo acima. Para este projeto nós temos as seguintes variáveis definidas:
A diferença entre variable e file , é que no caso de variável é extraído o conteúdo da String, já como file é referenciado o arquivo, e por sua vez, seu conteúdo. Isto é importante quando? Se você tiver uma operação por exemplo : mysql -u sysdba -p $senha , no caso $senha pode ser apenas uma variável com o valor masterkey e pronto, a execução irá executar mysql -u sysdba -p masterkey. Mas em nosso caso, como estamos usando o Kubectl, o mesmo precisa do arquivo de configuração de cluster, desta maneira ao chamar o comando: export KUBECONIG=$K8SCONFIG , no caso K8CONFIG sendo um File, ao executar a chamada real será mais ou menos como : KUBECONIG=.tmp/K8SCONFIG.file . Esta é uma grande dica para operações com clusters Kubernetes.
O Pulo do Gato com Rancher
O Rancher é um dos orquestradores mais simples e menos burocráticos que você encontrará no mercado. Simplesmente tudo que você quer fazer dentro dele, (ao contrário de outras ferramentas): É extremamente simples.
Para este cenário, nós fizemos um provisionamento de EKS na AWS para o cliente ter seu cluster apartado de nosso ambiente, e poder realizar todos seus deployments de forma isolada e segura, se amanhã ele nos pedir que seja em Azure, Oracle OCI, ou mesmo em bare metal, graças ao Rancher essa tarefa será super facilitada.
Para este módulo de exemplo, nós definimos 2 deployments, um que será pro Backend e outro para o Frontend, cada uma deles têm suas características e definições de variáveis de ambientes. Veja abaixo nosso deployment deste exemplo no Rancher:
Vamos entrar em cada um dos deployments tem algumas informações importantes, por exemplo no backend:
Neste Pod, temos 3 variáveis que são 100% alimentáveis e configuráveis em simples configurações visuais pela UI, mas claro, podem ser enviados via API do K8S ou mesmo chamada do kubectl.
Para os serviços acima, nós já temos os Ingress/Load Balancer configurado para os mesmos, e estes também são gerenciados pela UI do Rancher ou também por API ou kubectl:
Como os deployments estão prontos no Rancher, e toda a complexidade do Kuberentes já está abstraída, as únicas coisas que nosso kubectl do pipeline precisa fazer é atualizar nosso deployment e pronto, nova versão de homologação no ar.
Conclusão
Uma boa ferramenta de DevOps e um orquestrador de containers são ferramentas fundamentais para quem espera ter agilidade de forma efetiva e pragmática na sua organização. Se você quiser ver essa demonstração, envie uma mensagem para gente aqui, e em breve iremos mostrar outros exemplos com novas soluções, fiquem atentos aos nossos posts.