Desenvolvimento

10 mar, 2017

Um ambiente simples usando Kubernetes e OpenShift Next Gen – Parte 01

Publicidade

Como parte das minhas metas dentro da Coderockr está a construção de um cluster usando algumas das ferramentas de orquestração de contêineres que existem no mercado; como o Docker Swarm, Kubernetes, Apache Mesos etc.

Optei pelo Kubernetes no momento, tanto pelo pedigree, criado pelo Google e mantido pela Cloud Native Computing Foundation; quanto pela oferta de grandes clouds como a Red Hat, Azure e Google.

Quando estava avaliando as opções disponíveis, o Jean Carlo Machado (colega da CompuFácil), me sugeriu usar o OpenShift Next Gen, a plataforma da Red Hat para Kubernetes, que esta em Developer Preview permitindo que você se cadastre para testar a ferramenta deles por 30 dias.

Isso me salvou de já ter de sair pagando para testar, ou ter de fazer o setup do minikube na minha máquina, o que não me era muito atrativo.

Assim, resolvi dar uma chance a plataforma da Red Hat e construir um ambiente simples com um servidor HTTP em Node e um banco de dados MySQL, o que já me permite cobrir vários aspectos básicos do Kubernetes.

Mas como o texto foi ficando muito grande, achei melhor quebrá-lo em quatro partes para não cansar quem for ler e que irei publicar nos próximos dias.

Nessa primeira parte, vou dar uma introdução aos conceitos básicos do Kubernetes, e nas próximas irei fazer uso desses conceitos.

  • Parte 2 – Construindo o Ambiente
  • Parte 3 – Volumes Persistentes
  • Parte 4 – Segredos

A aplicação que construí usa um conjunto de dados sobre faltas em consultas que achei no Kaggle e gera os gráficos abaixo, podendo escolher o dia da semana como filtro.

 

O fonte dessa aplicação pode ser encontrado aqui

Então, publiquei no Docker Hub uma imagem para a aplicação (lucassabreu/openshift-app-test) e outra para o banco de dados (lucassabreu/openshift-mysql-test) – essa imagem é um MySQL normal, mas que adicionei um dump da base que vou usar para facilitar o deploy.

Agora, se eu quiser executar essa aplicação na minha máquina, posso simplesmente executar os seguintes comando do Docker e terei o servidor me respondendo em http://localhost:

#!/bin/bash
docker run -d --name db-test \
  -e MYSQL_ROOT_PASSWORD=root -e MYSQL_DATABASE=appointments \
  -e MYSQL_USER=appoint -e MYSQL_PASSWORD=123 \
  lucassabreu/openshift-mysql-test

docker run -d --name app-test --link db-test:db \
  -e DATABASE_CONNECTION=mysql://appoint:123@$db:3306/appointments \
  -p 80:8080 lucassabreu/openshift-app-test

Certo, agora que tenho certeza de que a minha aplicação está operacional, comecei a criar os objetos do Kubernetes, mas antes é importante entender alguns conceitos da plataforma para não ficar muito perdido:

Pod

Este é o menor componente do Kubernetes. Representa um nó no cluster, executando um ou mais contêineres que entregam uma mesma função.

Eles têm a característica de serem descartáveis, ou seja, se eventualmente acontecer algum problema a um Pod, este pode ser destruído sem nenhum efeito colateral ou remorso.

Deployment

Como o nome sugere, controla o deploy de Pods dentro do cluster. Quando se cria esse componente, deve-se informar um template de Pod e quantos destes você precisa, e se necessário, uma regra para criar mais instâncias.

Ele irá garantir duas coisas principalmente: que existam suficientes Pods quanto foi definido, e que os mesmos estejam atualizados em relação ao template que foi definido.

Então, caso você mude algo no template, o Deployment vai subir novos Pods e destruir os antigos para manter a expectativa (ele também “versiona” os deploys, então, se algo explodir dá para voltar atrás).

Service

Assim como os Pods, além de efêmeros, os Services podem existir em números variados por culpa dos Deployments, não há forma confiável de tentar conectar dois Pods diretamente, seja porque o Pod que você está dependendo pode morrer e quando voltar terá outro IP, e provavelmente outro nome, ou porque o Pod que você “fixou” pode não ser o mas indicado (menos ocupado ou mais próximo).

Para resolver esse problema, existem os Services. Em vez de tentar fazer as chamadas diretamente para um Pod, podemos chamar pelo nome de um Service e este irá rotear para um Pod que esteja abaixo dele.

É importante ressaltar que os Services fazem “apenas” a descoberta dos Pods; eles não os mantêm ligados – isso é responsabilidade dos Deployments.

Route

Permitem que você exponha os Services para a rede externa e também permitem algumas regras de proxy para melhor apresentá-los.

Embora seja possível fazer a exposição de Services para a rede externa com Kubernetes, na plataforma da OpenShift é necessário o uso do componente Route para isso.

Como comentei no início, estou escrevendo uma série de postagens para mostrar como usar o básico do Kubernetes, e no próximo artigo, irei usar os conceitos que acabei de descrever para implementar o ambiente.