Construir uma aplicação web escalável, segura, com alta disponibilidade não é uma tarefa fácil pois devemos tomar decisões como: Arquitetura back/front, SCM, containers, storage, CI/CD, testes e mais um novo termo que nasce a cada novo dia. Além disso, obter o ambiente e o know-how para todas estas decisões custa (principalmente TEMPO).

Estrutura DEVOPS — https://www.profissionaisti.com.br/2018/04/curso-ao-vivo-devops-professional-preparatorio-oficial-exame-exin-10-de-desconto/

Hoje vou tratar de duas ferramentas que, pra minha surpresa, estão se integrando e entregando muito bem desde o gerenciamento de código fonte até o monitoramento da aplicação publicada: GitLab + GKE (Google Kubernetes Engine).

O que iremos construir:
Aplicação Spring Boot operando em um cluster Kubernetes no Google a custo zero

Você vai precisar de:
– Uma conta no Gitlab (https://gitlab.com/) privada ou cloud
– Uma conta Google (https://console.cloud.google.com/)
– Conhecimentos em Git, Java
Uma tesoura sem ponta e a presença de um adulto 🤓

Quanto isso irá custar
Nada, mas depende. Depende pois o Google oferece U$300,00 de uso em seu cloud durante um ano, se você nunca usou este crédito aproveite. Já o Gitlab tem planos de assinatura e a conta gratuita atende bem para equipes pequenas e open-source. 
Uma boa dica para empresas: No momento, ao linkar o Gitlab + Kubernetes e informando sobre a empresa você ganhará U$200,00 adicionais para o Google Kubernetes Engine.

Atividades:
– Criação do projeto Spring no Gitlab
– Criação da área de Kubernetes no Google
– Habilitar AutoDEVOPS
– Instalar módulos adicionais
– Visualizar o CI/CD e deploy efetuado

Criação do projeto Spring no Gitlab
Considerando que você já fez o setup de sua conta e área de trabalho no Gitlab, vá em “New project – Create from template” e use o template “Spring”. Após importar o projeto do modelo do Gitlab você obterá a seguinte tela:

Tela inicial do projeto

De imediato o Gitlab te sugere a opção de habilitar Auto DevOps nas configurações do projeto, clique em “Enable in settings” (ou se a dica sumiu, clique no botão “Enable Auto DevOps”). A tela de configurações aparece informando que você precisa de um domínio e um cluster Kubernetes para habilitar o Auto Review e Deploy — não marque esta opção agora — acione o link “Kubernetes cluster” e em seguida “Add Kubernetes cluster” (a única opção que aparece).

Configuração do projeto — Settings-CI/CD-Auto DevOps

Agora uma pausa para configurar sua conta Google Cloud
Acesse https://console.cloud.google.com/ e crie ou selecione um projeto. No guia a direita, selecione a opção “Kubernetes Engine” e espere o GCP habilitar a engine no projeto. Muito cuidado neste momento pois você precisa ter uma conta de faturamento com um cartão de crédito vinculado, ou seja, você pode ser cobrado pelos recursos solicitados se já utilizou o bonus de U$300.00 ou expirou 1 ano de uso da conta cloud.

Projeto com cluster Kubernetes habilitado

Voltando ao Gitlab…
Após vincular a conta Google, temos que informar os dados do projeto e cluster a ser criado:
– Nome do cluster
– Projeto do Google Cloud Platform
– Zona que será publicada a app (US, Europe, Asia, etc.)
– Número de nós — são VMs ou máquinas físicas dentro do cluster com a mesma configuração / ambiente.
– Tipo de máquina — cada tipo tem uma configuração e preço (vide o link abaixo do campo)

Sugestão para um primeiro ambiente

Estamos quase lá, pegue um café e espere o Gitlab criar o cluster no Google e você fará as últimas configurações em seguida. A guia do projeto em “Operations — Kubernetes” ficará selecionada e você pode instalar as aplicações sugeridas no cluster:
Helm Tiller — Um gerenciador de pacotes para o kubernetes
Ingress — Este recurso funcionará como um gerenciador de rotas / load balancer. Após instalado ele te dará um número IP, guarde este número.
Prometheus — Um sistema de monitoramento da saúde do seu cluster, vai prover os gráficos para o Ops pelo próprio Gitlab
Gitlab Runner — Esta é a imagem responsável por executar os jobs e distribuir os recursos do seu projeto diretamente para o ambiente criado.
JupyterHub — Este é novo, trabalha como um multiplicador do ambiente (ótimo para estudos em conjunto, não precisa habilitar)

Instale estes recursos em seu cluster

Após tudo instalado, por fim, volte à configuração do Auto DevOps (Settings — CI/CD — Auto DevOps) e habilite-o marcando a configuração e o número IP copiado + o sufixo .nip.io. Este sufixo é um serviço de DNS para qualquer IP público, se preferir, configure o domínio com seu provedor usando o IP obtido do Ingress. Marque também qual estratégia de Deploy você deseja, se diretamente no ambiente de produção ou para staging e manualmente transferido ao ambiente de produção — este último é interessante pois é possível a utilização de um deploy gradual (staged roll-outs).

Habilitando o Auto DevOps pipeline

E que o espetáculo comece
Após gravar as configurações, corra para a guia “CI/CD — Pipelines” e acompanhe o primeiro deploy da sua aplicação. Neste momento o Gitlab cria containers para executar o deploy de cada passo do pipeline de Continuous Integration repassando o output para cada estágio, impedindo ou não o Continuous Delivery. O próprio Gitlab gera um container Docker do projeto, grava no próprio Registry (há uma opção de menu para isso) e por fim, realiza o release no Kubernetes. Por padrão as configurações são salvas num arquivo chamado .gitlab-ci.yml que contém as informações de deploy. Você pode criar um novo arquivo que execute outros estágios para o deploy conforme sua preferência, porém, é necessário saber bem o que está fazendo (toda a documentação do arquivo pode ser acessada aqui: https://docs.gitlab.com/ee/ci/yaml/)

Pipeline em execução para distribuição em produção

Pipeline concluido como “passed”, vá na guia “Operations — Environments” que será exibido o ambiente criado pelo Auto DevOps para deploy, há um ícone que irá permitir ver o resultado do deploy

Clique no ícone para ver o resultado ou nos demais para monitoramento, console, reboot ou parar o ambiente
Resultado da aplicação Spring

Push Push Push
Depois de toda essa configuração seu ambiente estará pronto para cada alteração na branch efetuada, o Auto DevOps irá disparar um pipeline para envio em produção ou staging. Então atente-se, configure acessos, pull-requests, gitlab-flow, git-flow, whatever-flow que vão te assegurar sobre o conteúdo que está indo para seu ambiente.

Acabou, foque no seu negócio e “busque conhecimento”
O Gitlab, assim como o Github, hoje é muito mais que só o repositório com visualização web, permite controle de tarefas, automação e integração com vários outros serviços além de permitir instalar o ambiente em seu próprio hardware. 
Já o Google-Kubernetes oferece muito mais do que só um deploy de containers na nuvem, ele traz possibilidades e facilidades de escala e monitoramento que hoje é um assunto essencial para SAAS. 
Não é capricho mencionar que publicar aplicações num ambiente como este exige muito mais que criar contas no Gitlab e Google, ter um cartão de crédito e saber desenvolver, é necessário conhecer onde se está pisando. Procure informações e pessoas que podem contribuir para conhecer os termos CI/CD + Kubernetes, explore as ferramentas e veja o que elas oferecem a teu favor para entregar seu produto num tempo hábil e com qualidade.