O que é e como usar o Docker Stack.

Olá, exploradores do universo Docker! Hoje, vamos mergulhar mais fundo e descobrir as maravilhas do Docker Stack, a evolução natural do Docker Compose, especialmente desenhado para trabalhar com clusters através do Docker Swarm. Se você achou Docker Compose interessante, prepare-se para ficar ainda mais impressionado com o que Docker Stack pode fazer! Não se preocupe, se já passeou pelo mundo do Docker Compose, você está mais que preparado para essa nova aventura. Vamos lá?

Se você está acompanhando a série de posts sobre o Docker, já deve ter visto um pouco sobre Docker Compose. O Docker Stack é, de forma simplificada, a evolução do Compose, com foco em clusters (utilizando swarm). Com o Docker Stack você faz um script e configura nele quantos containers devem subir para cada serviço e o Swarm aloca estes serviços dentro do cluster.

A grosso modo, com o Docker Compose você cria um script com as camadas da sua aplicação, que serão aplicadas em um node. Com o Docker Stack você faz a mesma coisa, mas aplicando o resultado em um cluster.

Uma boa notícia: Se você passou pelo post que fala sobre Docker Compose, então já está familiarizado com boa parte do que precisamos para trabalhar com Docker Stack!

Para este post, como vou precisar de um cluster, utilizarei o Play-With-Docker. (Se você não está lembrando como criar um cluster, veja o post sobre como usar o Docker Swarm, mas deixe apenas 1 node como manager e os outros 4 como workers.)

Antes de utilizar o Docker Stack propriamente dito, precisamos de um arquivo, que segue o mesmo padrão do Docker Compose. No node manager, crie um arquivo chamado docker-stack.yml, conforme o exemplo abaixo:

version: "3"
services:

  wordpress:
    image: wordpress
    depends_on:
      - mysql:mysql
    ports:
      - 8080:80
    networks:
      - frontend
    deploy:
      replicas: 6
      restart_policy:
        condition: on-failure

  mysql:
    image: mysql
    environment:
      - MYSQL_ROOT_PASSWORD=password
    networks:
      - frontend
    deploy:
      placement:
        constraints: [node.role == manager]

networks:
  frontend:

Como você deve ter percebido, ele é bem parecido com o do Docker Compose, mas com algumas diferenças:

1. Para o deploy do frontend (wordpress), defini que ele possuirá 6 replicas, ou seja, existirão 6 containers com o meu frontend;
2. No banco de dados, inclui um constraint no deploy (placement: constraints: [node.role == manager]), que força este serviço a subir apenas no node que está marcado como manager.
3. Ao final do arquivo, inclui um network chamado frontend. Ele foi adicionado tanto para o wordpress quanto para o MySql. Este network funciona como uma espécie de “rede privada”. Apenas quem utilizar esta rede será capaz de se comunicar com os containers do seu cluster. Isso é interessante para criar um nível a mais de isolamento.

No mais, as mesmas regras se aplicam. Reforço que este é um documento que pode se tornar muito complexo e possui uma série de configurações que variam de acordo com a versão utilizada. Sendo assim, recomendo a leitura da documentação de referência.

Bom, agora que já temos o arquivo necessário, vamos utiliza-lo!

docker stack deploy --compose-file docker-stack.yml wp_app

No comando acima, estamos indicando que vamos utilizar o stack para fazer um deploy, tendo o arquivo docker-stack.yml como base. O wp_app no final da linha indica o prefixo que será utilizado nos serviços que subirem para esta stack, ou seja, o network que chamamos de frontend subirá com o nome wp_app_frontend, o wordpress com o nome wp_app_wordpress e o banco de dados com o nome wp_app_mysql.

Após executar o comando acima, o Docker irá gerar 6 containers com o wordpress e 1 com o MySql. Para sabermos se deu certo, podemos utilizar alguns comandos básicos (parte 2), aprendidos em posts anteriores:

docker service wp_app_wordpress

O comando acima mostra todos os containers que estão rodando o wordpress e em qual node eles estão.

Agora vamos conferir o banco de dados:

docker service wp_app_mysql

Devido a constraint (restrição) que colocamos, ao executar este comando, a lista deve conter apenas um container e este deve estar rodando no node manager.

O nome do serviço que você deve utilizar neste comando é o prefixo definido no comando docker stack deploy (wp_app, no nosso caso) + nome definido para cada serviço no arquivo docker-stack.yml. (que foi o nome logo cima do item image:)

Você deve ter reparado que não colei aqui os resultados dos comandos. Desta vez pulei esta etapa, pois a visualização não fica muito boa.

Espero ter ajudado!