Desenvolvimento

24 mai, 2017

Ambientes por Branch com OpenShift Next Gen usando GitHub

100 visualizações
Publicidade

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:

- pipeline: "Build"
  trigger_mode: "ON_EVERY_PUSH"
  ref_name: "master"
  actions:
  - action: "Build Docker image"
    type: "DOCKERFILE"
    login: "${DOCKER_HUB_USER}"
    password: "${DOCKER_HUB_PASSWORD}"
    docker_image_tag: "${execution.to_revision.revision}"
    dockerfile_path: "Dockerfile"
    repository: "lucassabreu/k8s-pr-envs"

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:

$ oc login https://api.getupcloud.com:443
Authentication required for https://api.getupcloud.com:443 ...
Username: lucas.s.abreu@gmail.com
Password: 
Login successful.
...
$ oc project github-k8s-pr-envs #usar o seu projeto
Now using project "github-k8s-pr-envs" on server ...
$ oc create serviceaccount github
serviceaccount "github" created
$ oc policy add-role-to-user admin \
    system:serviceaccount:github-k8s-pr-envs:github
$ oc describe serviceaccount github
Name:  github
Namespace: github-k8s-pr-envs
Labels:  <none>
Image pull secrets: github-dockercfg-vat7r
Mountable secrets:  github-token-d3u3t
                    github-dockercfg-vat7r
Tokens:             github-token-2pimz
                    github-token-d3u3t
$ oc describe secret github-token-d3u3t
Name:  github-token-d3u3t
Namespace: github-k8s-pr-envs
Labels:  <none>
Annotations: kubernetes.io/service-account.name=github
  kubernetes.io/service-account.uid=zzz
Type: kubernetes.io/service-account-token
Data
====
ca.crt:  1066 bytes
namespace: 18 bytes
service-ca.crt: 2182 bytes
token:  token-do-openshift-que-estou-ocultando

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:

- pipeline: "Deploy Staging"
  trigger_mode: "ON_EVERY_PUSH"
  ref_name: "master"
  actions:
  - action: "Deploy Master to Staging"
    type: "BUILD"
    docker_image_name: "lucassabreu/openshift-k8s-cli"
    docker_image_tag: "latest"
    execute_commands:
    - TAG="${execution.to_revision.revision}"
      ENV=staging
      OPENSHIFT_NAMESPACE="${OPENSHIFT_NAMESPACE}"
      OPENSHIFT_API_URL="${OPENSHIFT_API_URL}"
      OPENSHIFT_TOKEN="${OPENSHIFT_TOKEN}"
      OPENSHIFT_DOMAIN="${OPENSHIFT_DOMAIN}"
      ./k8s/deploy
- pipeline: "Deploy Production"
  trigger_mode: "MANUAL"
  ref_name: "master"
  actions:
  - action: "Deploy Master to Production"
    type: "BUILD"
    docker_image_name: "lucassabreu/openshift-k8s-cli"
    docker_image_tag: "latest"
    execute_commands:
    - TAG="${execution.to_revision.revision}"
      ENV=production
      OPENSHIFT_NAMESPACE="${OPENSHIFT_NAMESPACE}"
      OPENSHIFT_API_URL="${OPENSHIFT_API_URL}"
      OPENSHIFT_TOKEN="${OPENSHIFT_TOKEN}"
      OPENSHIFT_DOMAIN="${OPENSHIFT_DOMAIN}"
      ./k8s/deploy

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.

Essas duas pipelines basicamente chamam o script abaixo:

#!/bin/bash

echo ">> Connecting to OpenShift..."
oc login "$OPENSHIFT_API_URL" --token "$OPENSHIFT_TOKEN"
oc project "$OPENSHIFT_NAMESPACE"

echo ">> Removing old application..."
oc delete all -l "app=$ENV"

IMAGE_TAG="lucassabreu/k8s-pr-envs:$TAG"
HOSTNAME="$OPENSHIFT_NAMESPACE-$ENV.$OPENSHIFT_DOMAIN"

if [ "$ENV" = "production" ]; then
    HOSTNAME=$OPENSHIFT_NAMESPACE.$OPENSHIFT_DOMAIN
fi

echo ">> Deploying application..."
sed "
    s|__ENV__|$ENV|;
    s|__IMAGE_TAG__|$IMAGE_TAG|;
    s|__HOSTNAME__|$HOSTNAME|;
    " k8s/full.yml | oc apply -f -

echo "Enviroment $ENV deployed to: http://$HOSTNAME/"

Este script basicamente se autentica contra a API do OpenShift usando o Token que criamos antes, destrói a aplicação antiga e executa o deploy de uma nova.

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.

É importante ressaltar que estou usando uma imagem customizada para rodar esses comandos (lucassabreu/openshift-k8s-cli) que basicamente é um ubuntu com o oc instalado dentro dela.

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.

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: hw-dpl-__ENV__
  labels:
    app: __ENV__
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: __ENV__
        name: hw-pod
    spec:
      containers:
      - name: hw-container
        image: __IMAGE_TAG__
        imagePullPolicy: Always
        ports:
        - name: web-port
          containerPort: 8080
---
apiVersion: "v1"
kind: Service
metadata:
  name: hw-src-__ENV__
  labels:
    app: __ENV__
spec:
  ports:
    - port: 80
      targetPort: "web-port"
      protocol: TCP
  selector:
    name: hw-pod
    app: __ENV__
---
apiVersion: v1
kind: Route
metadata:
  name: __ENV__
  labels:
    app: __ENV__
spec:
  host: __HOSTNAME__
  to:
    kind: Service
    name: hw-src-__ENV__

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

Agora que temos um processo de build e um de deploy automatizado, vamos adicionar a função de deploy por branch.

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:

- pipeline: "Review"
  trigger_mode: "ON_EVERY_PUSH"
  ref_name: "((?!master).*)"
  actions:
  - action: "Build Docker image"
    type: "DOCKERFILE"
    login: "${DOCKER_HUB_USER}"
    password: "${DOCKER_HUB_PASSWORD}"
    docker_image_tag: "${execution.branch.name}"
    dockerfile_path: "Dockerfile"
    repository: "lucassabreu/k8s-pr-envs"
  - action: "Deploy By Branch"
    type: "BUILD"
    docker_image_name: "lucassabreu/openshift-k8s-cli"
    docker_image_tag: "latest"
    execute_commands:
    - TAG="${execution.branch.name}"
      ENV="${execution.branch.name}"
      GITHUB_TOKEN="${GITHUB_TOKEN}"
      LOG_URL="${execution.html_url}"
      OPENSHIFT_NAMESPACE="${OPENSHIFT_NAMESPACE}"
      OPENSHIFT_API_URL="${OPENSHIFT_API_URL}"
      OPENSHIFT_TOKEN="${OPENSHIFT_TOKEN}"
      OPENSHIFT_DOMAIN="${OPENSHIFT_DOMAIN}"
      ./k8s/deploy

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.

if [ ! -z $GITHUB_TOKEN ] && [ "$ENV" != "production" ] && [ "$ENV" != "staging" ]; then
    echo ">> Registering $ENV deployment..."

    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")
    if [ "$(echo $RETURN | jq ".message")" != "null" ]; then
        echo $RETURN
        exit 1
    fi
fi

echo "Enviroment $ENV deployed to: http://$HOSTNAME/"

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.

O Pull Request da branch a-change fica assim:

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

Ainda fica faltando uma última atividade por realizar, que é destruir o ambiente da branch quando os Testers não mais precisarem deles.

Então, vamos adicionar uma nova pipeline no buddy.yml:

- pipeline: "Close Review"
  trigger_mode: "MANUAL"
  ref_name: "((?!master).*)"
  actions:
  - action: "Destroy Branch Environment"
    type: "BUILD"
    docker_image_name: "lucassabreu/openshift-k8s-cli"
    docker_image_tag: "latest"
    execute_commands:
    - ENV="${execution.branch.name}"
      GITHUB_TOKEN="${GITHUB_TOKEN}"
      OPENSHIFT_NAMESPACE="${OPENSHIFT_NAMESPACE}"
      OPENSHIFT_API_URL="${OPENSHIFT_API_URL}"
      OPENSHIFT_TOKEN="${OPENSHIFT_TOKEN}"
      ./k8s/destroy

Nesse pipeline manual, basicamente chamamos o script k8s/destroy (que está abaixo), que simplesmente destrói o ambiente inativa ele no GitHub.

#!/bin/bash

echo ">> Connecting to OpenShift..."
oc login "$OPENSHIFT_API_URL" --token "$OPENSHIFT_TOKEN"
oc project "$OPENSHIFT_NAMESPACE"

echo ">> Removing old application..."
oc delete all -l "app=$ENV"

k8s/github-deployment "lucassabreu/k8s-pr-envs" "$GITHUB_TOKEN" inactive "$ENV" >> /dev/null

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.