Ambientes por Branch com OpenShift Next Gen usando GitHub | iMasters
Este artigo é uma continuação da "Ambientes por Branch com OpenShift Next Gen", a introdução do problema está lá e também mostro como implementar o processo de deploy usando o GitLab nele, se não viu ainda, dá uma conferida! Vale o investimento.
Como prometi antes, vamos criar um processo de deploy de ambientes por branch usando o GitHub.
No caso do GitHub, ele cobre "apenas" a parte de repositório de fontes; ele, em si, não tem integração direta com o Kubernetes/OpenShift, mas possui uma grande gama de opções no que diz respeito à ferramentas de CI e CD.
A implementação que vou demonstrar usará o Buddy, mas pode ser replicada para qualquer outro CI com dificuldade semelhante. Para o registro de imagens, usarei o Docker Hub e novamente o OpenShift, da Getup Cloud.
Obs.: sobre uma introdução ao Kubernetes/OpenShift pode ver aqui. Já o cliente de linha de comando do OpenShift, pode ser baixado em: https://github.com/openshift/origin/releases.
O que queremos montar é um ambiente por branch/PR que deve ser facilmente criado e destruído. Para demonstrar, criei um repositório no GitHub com uma aplicação bem simples que apenas retorna uma página estática, mas é o suficiente para o objetivo.
E configurei o Buddy para construir uma imagem com base nesse repositório e publicá-la como lucassabreu/k8s-pr-envs no Docker Hub.
Nesse momento, o arquivo buddy.yml está assim:
A fonte nesse momento pode ser visto neste link.
Nesse primeiro momento, não possuímos nenhum processo de deploy, seja de teste, produção ou por branch.
Então, vamos adicionar um processo de deploy no OpenShift para o ambiente de produção e testes, sendo que o ambiente de testes é atualizado automaticamente para os commits na master e o de produção apenas quando um usuário disparar o deploy via interface web do Buddy.
Precisamos preparar o OpenShift para montar esse processo. Primeiramente, criamos um Namespace. A forma como criamos um varia de vendor para vendor – no caso do OpenShift, da Getup Cloud, basta ir em https://portal.getupcloud.com/projects e criar um novo projeto. O nome do projeto será o Namespace.
Tendo um Namespace, precisamos de uma forma do Buddy se autenticar contra o OpenShift. Para isso, podemos criar um ServiceAccount e usar o seu Token para isso. O script abaixo mostra como criar uma ServiceAccount e resgatar o Token usando o CLI do OpenShift:
Agora podemos informar no Buddy algumas variáveis para ele nos disponibilizar depois. Meu painel ficou como mostrado abaixo:
A URL da API e o domínio que o OpenShift irá utilizar também dependem do seu vendor. No meu caso, a API está em https://api.getupcould.com:443 e o domínio base é getup.io.
Agora, podemos criar os novos pipelines no Buddy. No buddy.yml, as linhas abaixo:
Basicamente, criei duas novas pipelines, uma chamada Deploy Staging e outra Deploy Production. As únicas diferenças entre elas é que a Deploy Staging é automática para todo o commit na master e usa ENV=staging para indicar o ambiente; e Deploy Production é manual e usa ENV=production. Também criei variáveis para injetar os valores que informamos antes no Buddy e uma extra COMMIT para que ele consiga identificar qual imagem deve usar.
Para poder identificar quais os componentes de cada ambiente, estou marcando-os com a label app=$ENV. Dessa forma, todos os componentes do ambiente staging estão marcados com app=staging e fica fácil eliminá-los e identificá-los.
Também estou usando um truque de "templating" com o YAML que define os ambientes para poder inserir as variáveis de cada ambiente nele. Existem outras ferramentas mais avançadas como o Helm, mas para o meu exemplo, templating com sed é o suficiente.
Agora, toda vez que é feito commit na master, o ambiente de staging é automaticamente atualizado, e ficou bem simples atualizar o ambiente production.
Obs.: Fonte até agora: https://github.com/lucassabreu/k8s-pr-envs/tree/v2
Basicamente, precisamos de duas novas etapas no nosso CI: uma para subir o ambiente para uma branch e outra para destruir esse ambiente.
Primeiro, vamos preparar o deploy por branch. Para isso, adicionei as seguintes linhas do buddy.yml:
No novo pipeline Review, temos um build da imagem e um deploy de um ambiente para a branch em questão, para uma rota própria.
Eu acabei juntando essas duas ações, pois o build que roda na master vai versionando as imagens por commit, que é uma prática comum e que ajudaria a fazer o deploy para produção mais simples, porém branchs de desenvolvimento tendem a ser mais caóticas e iriam poluir muito o registro de imagens (se usar o do AWS, seria um custo maior também), então, preferi manter uma imagem por branch, até para não confundir também.
Se eu criar uma nova branch nesse momento, o Buddy automaticamente irá montar uma imagem para ela e inseri-la no OpenShift. Se o nome da branch for a-change, o nome do ambiente será http://github-k8s-pr-envs-a-change.getup.io (talvez ainda esteja acessível).
Eu sei disso porque eu escrevi o script. Eu poderia documentar isso no projeto para todos saberem como descobrir as URLs corretas, mas é mais do que natural esperar erros por esse caminho, um "o" que vira "a" na hora de digitar, um nome de branch estranho etc.
Dessa forma, fica difícil para a equipe de QA acessar aos ambientes por branch toda vez correndo o risco de errar. Então, fiz algumas alterações no k8s/deploy para utilizar a API de Deployments do GitHub para registrar as URLs diretamente nos commits.
ID_DEPLOYMENT=$(k8s/github-deployment "lucassabreu/k8s-pr-envs" "$GITHUB_TOKEN" create "$ENV" "$ENV" true | jq ".id")
RETURN=$(k8s/github-deployment "lucassabreu/k8s-pr-envs" "$GITHUB_TOKEN" status set "$ID_DEPLOYMENT" success "http://$HOSTNAME/" "$LOG_URL")
Com isso, faço algumas chamadas a API do GitHub usando o k8s/github-deployment (que é basicamente um facilitador para a API) e consigo registrar o deploy no GitHub.
Nesse botão "View deployment" está o link para a rota que criamos no deploy. E dessa forma fica extremamente fácil para a equipe de QA acessar os ambientes.
Obs.: Fontes até agora: https://github.com/lucassabreu/k8s-pr-envs/tree/v3.1
Então, vamos adicionar uma nova pipeline no buddy.yml:
Nesse pipeline manual, basicamente chamamos o script k8s/destroy (que está abaixo), que simplesmente destrói o ambiente inativa ele no GitHub.
Agora, podemos chamálo para eliminar os ambientes de branch em aberto.
Obs.: Fontes até o momento: https://github.com/lucassabreu/k8s-pr-envs/tree/v4
Um comportamento que ainda não conseguimos reproduzir usando o Buddy e o GitHub é destruir os ambientes quando o Pull Request é finalizado.
Para resolver esse problema, podemos adicionar um webhook no GitHub e dispararmos o pipeline através desse webhook. Isso pode ser feito de várias formas, usando Lambda Functions ou um endpoint para esse fim.
No caso, criei um novo Pod com um contêiner que criei (lucassabreu/buddy-works-pullrequest-webhook) e associei-a ao meu projeto no GitHub.
E pronto! Tenho um processo completo, mesmo que se esqueçam de derrubar o ambiente no momento que o merge acontecer, automaticamente o ambiente será destruído.
Veja o meu "webhook", caso opte por um caminho semelhante e poder ter uma base de como é a chamada.
Foi mais complexo implementar a integração do OpenShift com o GitHub, mas ainda, sim, temos um grande ecossistema de integrações que nos permitem contornar essa questão. E o resultado continua sendo o esperado.