preloader

Docker Enterprise 2.1 na DigitalOcean – Parte II

Na primeira parte desta série nós aprendemos como fazer o setup do novo cluster do Docker Enterprise 2.1 na DigitalOcean com Terraform e Ansible.

Se você ainda não leu a primeira parte, clique aqui.

Neste Artigo nós vamos discutir como configurar o Docker Enterprise de forma que:

  • Os volumes persistentes criem volumes no block storage na DigitalOcean
  • Controladores Ingress criem load-balancers na DigitalOcean

Desta maneira um cluster de Docker Enterprise irá se comportar como um cluster kubernetes nativo na Digital Ocean.

O que você precisará?

Tenha certeza de ter completado a primeira parte desta série e cheque se seu shell atual está configurado para se conectar com o cluster remotamente (executando o script do client bundle  “env.sh”).

Certifique-se que possui o kubectl e o helm instalados. A ferramenta “kubectl” ( linha de comandos para o kubernetes) vem em conjunto com o Docker Desktop, mas você pode instalar isso manualmente.

No OSX estas ferramentas podem ser instaladas com Homebrew:

brew install kubernetes-cli
brew install kubernetes-helm

Note que o Docker Enterprise utiliza o Kubernetes 1.11, então é recomendável utilizar a versão do kubectl mais próxima a 1.11 (1.12 é bom).

Isto assume que você passou pelo primeiro artigo e que no seu shell reside o projeto já clonado do repositório (https://github.com/vertigobr/dockeree-digitalocean). Você pode verificar o funcionamento executando o seguinte comando:

kubectl get nodes
NAME         STATUS    ROLES     AGE       VERSION
do-manager   Ready     master    43m       v1.11.2-docker-2
do-worker1   Ready     <none>    30m       v1.11.2-docker-2
do-worker2   Ready     <none>    30m       v1.11.2-docker-2

 

Step 1: Configure Secret

Um token válido precisa ser usado internamente para criar recursos na sua conta da DigitalOcean, ou seja, você terá que criar um Secret e guardá-lo no cluster.

Apenas copie o “digitalocean-secret.yml.template” providenciado no projeto para um novo  arquivo “digitalocean-secret.yml” (por favor, não renomeie o arquivo original):

cp digitalocean-secret.yml.template digitalocean-secret.yml

Agora edite “digitalocean-secret.yml” e troque o valor dentro da entrada  de “access-token” pelo seu próprio token da DigitalOcean.

Você irá criar o recurso do Secret executando o seguinte comando:

kubectl apply -f digitalocean-secret.yml
secret "digitalocean" created

 

Step 2: Instalação do Storage CSI

Nós iremos instalar o CSI (Container Storage Interface) localizado em  https://github.com/digitalocean/csi-digitalocean. O plugin do CSI permite que use o Block Storage da DigitalOcean com o Orquestrador de Kubernetes do Docker Enterprise de forma transparente, transformando isto no storage padrão para os volumes persistentes.

Um simples comando que faz esse truque:

kubectl apply -f https://raw.githubusercontent.com/digitalocean/csi-digitalocean/master/deploy/kubernetes/releases/csi-digitalocean-v0.2.0.yaml

Vários recursos serão criados (você pode encontrar eles dentro do namespace “kube-system”). Você pode checar que este novo controlador do storage é o default do cluster:

kubectl get sc
NAME                         PROVISIONER                 AGE
do-block-storage (default)   com.digitalocean.csi.dobs   27m

Importante: Nós precisamos manter a versão no CSI 0.2.0 enquanto o Kubernetes do Docker Enterprise continuar na versão 1.11.

Para testar o CSI, você tem que criar uma requisição de volume persistente (persistent volume claim). Por sorte, nós já temos um yaml pronto para isto:

kubectl apply -f https://raw.githubusercontent.com/digitalocean/csi-digitalocean/master/examples/kubernetes/deployment-single-volume/pvc.yaml persistentvolumeclaim “csi-deployment-pvc” created

Você pode checar a DigitalOcean para ver o novo volume do block storage criado:

Step 3: Instale o  CCM

O CCM (Cluster Control Manager) da DigitalOcean contém um importante componente de servicecontroller, responsável por criar Load Balancers quando o serviço do tipo: LoadBalancer é criado no Kubernetes.

O CCM pode ser instalado com o comando abaixo:

kubectl apply -f https://raw.githubusercontent.com/digitalocean/digitalocean-cloud-controller-manager/master/releases/v0.1.8.yml

Step 4: Instalando Helm (Tiller)

Helm (Um Gerenciador de Pacotes para Kubernetes) opera com um componente server-side (Tiller). Você precisa instalar isto e dar as permissões apropriadas:

helm init
kubectl create rolebinding default-view \
  --clusterrole=view \
  --serviceaccount=kube-system:default \
  --namespace=kube-system
kubectl create clusterrolebinding add-on-cluster-admin \
  --clusterrole=cluster-admin \
  --serviceaccount=kube-system:default

A saída será algo parecido com isto:

...
Tiller (the Helm server-side component) has been installed into your Kubernetes Cluster.
...
Happy Helming!
rolebinding.rbac.authorization.k8s.io "default-view" created
clusterrolebinding.rbac.authorization.k8s.io "add-on-cluster-admin" created

Step 5: Setup do controlador do Ingress

O repositório do CCM no github tem múltiplos exemplos de controladores Ingress (load balancers) para diferentes situações. Nós vamos falar deles mais tarde. Para este momento, nós iremos instalar um load balancer de propósitos gerais com o Helm:

helm install stable/nginx-ingress --name my-nginx --set rbac.create=true --namespace nginx-ingress

Este controlador de ingress deve ter ativado sozinho em um novo load balancer na DigitalOcean. Observe na DigitalOcean, na página “Networking/Load Balancers” para ver se existe algo parecido com isto:

Anote este endereço IP, você pode testar o load balancer agora, utilizando o curl para acessar o backend default e “healthz” endpoint:

curl <ip_address>
default backend - 404
curl -v <ip_address>/healthz
...
< HTTP/1.1 200 OK
...

Ótimo! Vamos para os próximos passos.   🙂

Step 6: Algumas magias com Domínios

Este seria um excelente momento para criar um subdomínio wildcard, sobre o domínio que você vem controlando na DigitalOcean.

Agora você criará um novo registro “A” em seu domínio no console da DigitalOcean com o hostname (“*.apps”) e o apontará para o endereço IP do load balancer.

Com este simples truque, qualquer recurso do ingress que declare o próprio hostname sobre este domínio “*.apps.devops.mycompany.com” vai ser servido propriamente através do load balancer.

Por outro lado, qualquer URL sobre este domínio que não esteja mapeada nos recursos do ingress vai ser automaticamente respondida pelo default do backend:

curl dummy.apps.devops.mycompany.com
default backend - 404

Se o novo subdomínio levar muito tempo para se propagar para o seu atual DNS, você pode sempre utilizar o curl diretamente para o IP do load balancer e utilizar o hostname falso:

curl -H "Host: dummy.apps.devops.mycompany.com" <ip_address>
default backend - 404

Step 7: Um exemplo completo (HTTP)

Baseado no exemplo original de controlador “nginx-ingress” no Github, alguns poucos arquivos que residem na pasta “cafe” para nossos testes de ambiente com um conjunto de aplicações reais no backend.

  • cafe.yaml: dois pequenos exemplares de aplicações web
  • cafe-ingress-http.yaml: uma configuração http de um Ingress para ambas as aplicações

As aplicações podem ser publicadas pelo comando abaixo:

kubectl apply -f cafe/cafe.yaml
deployment.extensions "coffee" created
service "coffee-svc" created
deployment.extensions "tea" created
service "tea-svc" created

Estes serviços estão executando agora no cluster, escalados para múltiplos pods especificados no arquivo de deployment.

Um recurso ingress é o que nós precisamos para nossa aplicação ser atendida através da URL apropriada:

kubectl apply -f cafe/cafe-ingress-http.yaml
ingress.extensions "cafe-ingress" created

Ambas aplicações agora podem ser alcançadas, cada uma com sua própria URL:

curl cafe.apps.devops.mycompany.com
Server address: 192.168.175.76:80
Server name: coffee-7dbb5795f6-k7ffn
Date: 20/Nov/2018:19:41:50 +0000
URI: /
Request ID: 337252aea94dae202c9da959ecdc333e
curl tea.apps.devops.mycompany.com
Server address: 192.168.175.79:80
Server name: tea-7d57856c44-dshh4
Date: 20/Nov/2018:19:41:57 +0000
URI: /
Request ID: 4f10a61e67e3e8f5a538101ae999f319

Observe que o wildcard aponta para o load-balancer, que foi atuo-configurado pelo CCM. Desta forma o request é encaminhado do controlador ingress para o nó servidor em execução.

Em nosso próximo artigo desta série, nós iremos aprender como usar os certificados HTTPS para load balancers (i.e. fora do cluster) e em cada serviço ingress (dentro do cluster). Aprenderemos outras maneiras de obter certificados HTTPS.

Vejo vocês na próxima!

 

Tradução: Thor Salgado – Estagiário Vertigo Tecnologia e  Docker Enthusiast

Revisão: Rubens Freitas – Gerente de Infraestrutura Vertigo Tecnologia


Que tal aprender também como integrar Docker com Java?

Se você ama tecnologia e gosta de se manter atualizado, inscreva-se no nosso blog!
Você também pode se interessar por...
contato

Vamos bater um papo?
Estamos aqui para te ajudar_