Um ambiente simples usando Kubernetes e OpenShift Next Gen – Parte 01 | iMasters
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.
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
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:
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
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.
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.
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).
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.
Permitem que você exponha os Services para a rede externa e também permitem algumas regras de proxy para melhor apresentá-los.
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.