sexta-feira, 30 de junho de 2017

Docker Swarm :: Quickstart do seu Cluster Local com Docker-Machine e Virtualbox.





Minha ideia é fazer uma série de posts sobre a implementação e as possibilidades de uso do Docker Swarm nas novas versões do Docker. Nesse primeiro post vou mostrar um Quickstart de como iniciar um cluster de testes local utilizando o Docker-Machine com o driver do Virtualbox. Ao decorrer das postagens, vou mostrar o mesmo processo utilizando demais drivers e provedores de Cloud, como AWS, Digital Ocean e etc.

Post migrado do Medium, desculpa galera... 

Dependências 

Inicialmente, nosso cluster de teste será composto por 3 hosts. Um master e dois workers.

Para isso, iremos utilizar o Docker Machine e a Virtualbox.
É importante que você possua os dois instalados localmente. 


Nossos Hosts serão:
  • master — Manager do Cluster 
  • minion01 — Worker do Cluster 
  • minion02 — Worker do Cluster 


Criando o Host Master

Com todas as dependências instaladas, vamos criar nossa docker-machine com o nome de master especificando o driver virtualbox.

$ docker-machine create -d virtualbox master


1. Utilizar o EVAL para importar as variáveis de ambiente para a shell local. 

A primeira que você criar uma máquina pelo docker-machine vai demorar consideravelmente, pois toda a resolução de dependências como o boot2docker serão instaladas de primeiro momento. Depois todas as outras tentativas vão ficar bala.


Depois de ter instalado e configurado o nosso host master, podemos listar nossos hosts e verificar mais informações de ambiente dos mesmos executando:


$ docker-machine ls // Lista os hosts ativos 
$ docker-machine env master // Exibe as configuracoes do host informado


Acabamos de criar um container chamado ‘master’. Para conseguirmos realizar uma ‘conexão’ com esse host para iniciar o cluster temos duas alternativas bem tranquilas.
Na primeira opção, vamos exportar as variáveis de ambiente do host para nossa sessão do shell.

Caso esteja utilizando o Bash ou Zsh:

$ eval "$(docker-machine env master)"

Caso esteja utilizando o Fishshell:

$ eval (docker-machine env master)


2. Pilotar os hosts via SSH.

Quando criamos a docker-machine ele já se encarrega de fazer a troca de chaves RSA entre nossa máquina e o host. Isso é bem bacana. 
Nos próximos posts vamos entrar mais a fundo nesse assunto e vamos ver que isso pode ser um ‘Power Up’ de segurança e flexibilidade em demais hosts com Amazon, DigitalOcean e etc.


$ docker-machine ssh master



Iniciando o Cluster do Swarm no Master

Com as variáveis de ambiente importadas para sua sessão do shell, vamos iniciar o swarm mode gerando um Token de Auth e Discovery.

Agora só precisamos iniciar o serviço. De costume, nosso IP externo da rede do Docker fica na interface eth1 em modo Bridge, enquanto a eth0 está configurada com um IP interno da rede do Virtualbox. Fica a sua preferência iniciar o serviço em qualquer uma delas.
As questões de segurança devem ser revisadas aqui.

Para exemplificar, vamos utilizar a interface de rede com IP externo a rede eth1. Então com a shell importada, ou via SSH no host master, execute:

$ docker swarm init --advertise-addr eth1


Após iniciar o cluster, a máquina já vai estar ingressada automaticamente como master do cluster. E irá nos mostrar o comando já pronto para ingressar novos hosts com o IP do host master e um Auth Token de discovery como o abaixo:

docker swarm join \
  --token SWMTKN-1-2e95hldkj5o49adkdz469fvlq311z1ral971gchs32hyol6rpn-57mr3rif9iy4mj54a29uekch0 \
 192.168.99.100:2377



Criando e Ingressando novos Hosts ao Cluster

Como combinamos nosso cluster será composto de 3 hosts simples:

Um master (que já criamos) e dois minions. Vamos trabalhar os mesmos agora. O processo de criação será parecido com o do master.

Também temos duas possibilidades:

1. Criar o host já ingressado no Cluster

Diretamente na criação do host no Docker Machine podemos informar alguns parâmetros do Swarm, como o  -- swarm-discovery informando o token que geramos acima.

$ docker-machine create -d virtualbox --swarm \
   --swarm-discovery token://SWMTKN-1-2e95hldkj5o49adkdz469fvlq311z1ral971gchs32hyol6rpn-57mr3rif9iy4mj54a29uekch0 \
minion01

$ docker-machine create -d virtualbox --swarm \
   --swarm-discovery token://SWMTKN-1-2e95hldkj5o49adkdz469fvlq311z1ral971gchs32hyol6rpn-57mr3rif9iy4mj54a29uekch0 \
minion02


2. Criar os hosts individualmente e ingressar via SSH

Podemos fazer o processo de criar os hosts um a um e ingressar os mesmos manualmente de forma individual com aquele comando que o swarm init nos gerou

$ docker-machine create -d virtualbox minion01 
$ docker-machine create -d virtualbox minion02

Criamos duas máquinas limpas utilizando o docker-machine. Agora podemos conectar nelas via SSH e ingressar no cluster

Ingressando o minion01

$ docker-machine ssh minion01

$ docker swarm join \
  --token SWMTKN-1-1rpipju4gbyqccce8gmbq1r5cwbqiyeg3zj3k7ikx0tjgq4mm0-abi0matsvro32s4oxzo00dpid \
  192.168.99.100:2377

Ingressando o minion02

$ docker-machine ssh minion02

$ docker swarm join \
  --token SWMTKN-1-1rpipju4gbyqccce8gmbq1r5cwbqiyeg3zj3k7ikx0tjgq4mm0-abi0matsvro32s4oxzo00dpid \
  192.168.99.100:2377


Listando os hosts ingressados no cluster e suas responsabilidades:

Podemos ter um controle em tempo real de todos os hosts ingressados e quais são suas responsabilidades dentro do cluster do swarm. Esse controle é muito bom caso você trabalhe diretamente com load balances e Auto Scaling dentro de algum provedor de cloud. Vamos abordar isso fielmente na continuidade dessa série de Swarm. Localmente não é tão importante, mas é um treino pro jogo da final.

Para listar todos os hosts ingressados:


$ docker node ls


Gerando redundância para o host Master

Todas as tarefas administrativas, como subir e descer containers, gerenciar comportamentos do cluster, rede, NAT, balance, deploys e criação de services devem ser feitos direto por um host manager (nosso master). Sem contar o ingress de novos hosts. Caso ele caia, essa tarefa se torna um pouco desastrosa.

Caso seja necessária uma manutenção programada, ou a máquina por algum motivo precisar morrer, podemos promover os demais hosts dentro do cluster como manager, tendo dois, três e até promover todos os hosts como master.

$ docker node promote minion01

Ou podemos promover vários hosts para manager

$ docker node promote minion01 minion02


Fazendo Deploy de uma Stack de Serviços no Cluster

Para fins de teste, podemos fazer um deploy simples de uma imagem de API que eu criei para testes educacionais e demonstrar o funcionamento de Load Balances e Auto Scaling. 
Vamos abordar mais a fundo esses conceitos nos próximos posts.

Link do Github: https://github.com/msfidelis/docker-api-demo
Link do Dockerhub: https://hub.docker.com/r/msfidelis/example-api/

Basicamente, o que importa é só nosso arquivo yml de deploy onde utilizaremos o Composer V3 para fazer o deploy do nosso serviço.

docker-compose-prodswarm.yml 

Para fazer o deploy é simples!


$ docker stack deploy -c docker-compose-prodswarm.yml app


Criamos um deploy da stack do docker-compose-prodswarm.yml com o nome de app. Nesse caso fizemos o deploy de 4 containers contendo nossa API. Você pode conferir isso rodando

$ docker stack ps app



Escalando Services do Cluster

Toda a Stack Docker nos oferece uma flexibilidade muito alta no aspecto de scaling. O modo Swarm, mais ainda! Com o docker, podemos listar todos os services que estão criados e rodando na nossa Stack que acabados de dar deploy. 

Para listá-los basta executar:

$ docker stack services app

Para escalar os serviços que estão rodando no cluster, em quantidade, devemos executar a partir de um host manager o seguinte comando:


$ docker service scale app_api=10

Onde app_api é o nome do serviço e 10 é a quantidade de novos containers que vamos fazer deploy no cluster. Depois podemos acompanhar a vida dos containers e a distribuição deles nos nossos hosts nodes normalmente.

$ docker stack ps app


Testando nossa API

Para testar a API, podemos pegar o IP do host master e acessar o Endpoint que nos mostra o hostname da máquina que está atendendo a requisição. Essa demonstração vai também nos provar que o load balance está acontecendo dentro do service da API. O correto é as requisições serem distribuídas entre todos os containers.$ docker-machine ip master

Agora acesse várias vezes:

http://ip-do-master/whoami




No próximo post iremos abordar um quickstart da criação de clusters com a Amazon AWS, usando EC2 e pois ECS.

:)

SOBRE O AUTOR

Matheus Fidelis

http://msfidelis.github.io/

Power Ranger, Piloto de Helicópteros e Astronauta da NASA. Analista DevOps e Desenvolvedor Web Backend. Apaixonado por Linux, Arquitetura, API's, Containers, Integração, Código, Testes, Escalabilidade e Cloud. :)

Postar um comentário

 
Nanoshots | Open Source Security, Linux e Tutoriais © 2015 - Designed by Templateism.com