Orquestração nativa no Docker pronta para produção: Docker 1.12 GA

agosto 31, 2016 6:03 pm Publicado por Deixe um comentário

Nós queríamos agradecer a todos na comunidade por nos ajudar a alcançar esse grande marco tornar o Docker 1.12 amplamente disponível para ambientes de produção. O Docker 1.12 adiciona o maior e mais sofisticado conjunto de funcionalidades em um único lançamento desde o início do projeto Docker. Dezenas de engenheiros, tanto funcionários Docker quanto colaboradores externos, fizeram contribuições substanciais para todos os aspectos da orquestração da versão 1.12, incluindo algoritmos do núcleo, integração no Docker Engine, documentação e testes.

Somos muito gratos à comunidade, que nos ajudou com feedback, relatórios de bugs e novas ideias. Nós não poderíamos ter feito isso sem a ajuda, em especial, das dezenas de milhares de usuários beta do Docker para Mac e Windows, que têm testado nossas funcionalidades da 1.12 desde a DockerCon, em junho. Nós vimos colaborações que vão desde a conclusão de tabulação bash até uma UX de votos para cima e para baixo que nos ajudaram a entender o que os usuários mais queriam. Comparado com o que nós revelamos na DockerCon, acabamos com melhorias significativas no swarm node incluindo fluxo de trabalho (é mais simples), relatório de erros (mais fácil de visualizar), melhorias de UX (mais lógicas), rede (problemas de confiabilidade corrigidos) etc.

A equipe principal também queria dar um agradecimento especial a um dos nossos mantenedores externos e Capitão Docker, Chanwit Kaewkasi, que conduziu a incrível iniciativa DockerSwarm2000, que reuniu toda a comunidade em torno de escalar um RC de 1.12 com o Swarm mode para quase 2.4k nodes e um pouco menos de 100 mil containers. Isso foi conseguido através de nossa comunidade global, que doou o acesso às suas máquinas em todas as formas e tamanhos de metal, desde Raspberry Pi a várias nuvens para VMs de arquiteturas x86 até sistemas baseados em ARM. Através dessa avaliação utilizando dados em tempo real, identificamos que a orquestração nativa no Docker já – em seu primeiro release – dobrou a escala de orquestração do Docker em apenas meio ano. Enquanto isso valida a escalabilidade da arquitetura, há ainda espaço para uma maior otimização de desempenho no futuro.

swarm-1

Vamos agora cavar fundo nessa nova arquitetura integrada de orquestração e por que nós tomamos uma abordagem de arquitetura muito diferente em relação a outros que estão tentando resolver a orquestração de containers.

Topologia de arquitetura Swarm mode

swarm-topology

Orquestração nativa de container no Docker 1.12 é um conjunto de recursos opcionais que envolve ativar um recurso conhecido como Swarm mode. Um swarm é um grupo descentralizado e altamente disponível de nodes Docker. Cada node é um subsistema de orquestração independente que tem todas as capacidades inerentes necessárias para criar um pool de recursos comuns para agendar serviços Dockerized.

Um swarm de nodes Docker cria uma topologia programável, permitindo ao operador escolher os nodes que são gerentes e os que são trabalhadores. Isso inclui configurações comuns, como a distribuição de gestores em várias zonas de disponibilidade. Como esses papéis são dinâmicos, eles podem ser alterados a qualquer momento através da API ou da CLI.

Os gerentes são responsáveis por orquestrar o cluster, servindo a API de serviço, agendando tarefas (containers), corrigindo containers que falharam na checagem de segurança e muito mais. Em contraste, nodes trabalhadores têm uma função muito mais simples, que é a execução das tarefas para desovar containers e rotear tráfego de dados destinados a containers específicos. Em ambientes de produção, é altamente recomendável ter nodes designados como “gerentes” ou “trabalhadores”. Nesse modo, os gestores não executam containers, reduzindo assim a sua superfície de carga de trabalho e ataque. Separadamente, um dos avanços de segurança do Swarm mode é que os nodes trabalhadores não têm acesso à informação no armazenamento de dados ou à API Service. Nodes trabalhadores só podem aceitar o trabalho e informar sobre status. Assim, um node trabalhador comprometido é limitado no dano que pode fazer ao sistema.

Nossa equipe se concentrou um pouco na arquitetura de comunicação entre esses nodes. Gerentes e trabalhadores têm diferentes requisitos de comunicação em termos de consistência, velocidade e volume; portanto, eles usam dois métodos de comunicação distintos. Raft é usado para compartilhar dados entre os gestores para consistência forte (ao custo de velocidade de gravação e volume limitado), enquanto gossip é usado entre os trabalhadores para uma comunicação rápida e de alto volume (embora apenas com consistência eventual). E a comunicação entre os gestores e os trabalhadores tem ainda exigências distintas. A única coisa que todos eles têm em comum é que eles possuem comunicação criptografada por padrão; mTLS.

Comunicação de gestor para gestor: sempre com quóruns disponíveis

Quando um node recebe o papel de gerente, ele se junta a um grupo de consenso Raft para compartilhar informações e realizar a eleição do líder. O líder é a autoridade central mantendo o estado, que inclui listas de nodes, serviços e tarefas no swarm, além de tomar decisões de agenda. Esse estado é distribuído em cada node do gerente através de uma loja Raft embutida. Ou seja, os gestores não têm qualquer dependência de uma loja de key-value externo como etcd ou Consul, que é menos um componente para operadores terem de gerenciar.  Gerentes não-líderes agem como hot spares e redirecionam solicitações de API para o líder atual. O sistema é, portanto, tolerante a falhas e altamente disponível.

Ter um sistema de arquivos distribuído integrado permite muitas otimizações que não poderiam ter sido alcançadas usando uma loja genérica – isso resulta em nosso sistema de orquestração nativa ser extremamente rápido. Uma grande otimização é que todo o estado swarm é mantido na memória resultando em leituras instantâneas. Essa otimização de leitura é altamente benéfica para a orquestração crítica; estado de reconciliação, que é um fluxo de trabalho de leitura pesada. Normalmente, um programador tem que realizar centenas de leituras: ler a lista de nodes, ler o que outras tarefas estão executando nesses nodes, e assim por diante. Com a otimização de leitura, há um aumento da velocidade, que resulta na remoção da necessidade de centenas viagens de leitura na rede para a base de dados externa.

Gravações também são fundamentais para orquestração, e a otimização é que em gravações no Swarm mode podem ser agrupadas em conjunto em uma única rede de ida e volta. Um exemplo de escrita comum é quando você escala um serviço e o orquestrador tem que criar um novo objeto para cada instância que o usuário solicita. Com uma loja externa, seria preciso enviar uma solicitação de rede para a loja para cada objeto que criamos, esperar por eles para salvar a gravação, e repetir. Isso pode levar dezenas de milissegundos por pedido e eles se somam (especialmente se você está adicionando centenas de novos casos). Com o nosso modelo, podemos fazer um lote com centenas desses objetos em uma única gravação.

A mesma otimização de gravação tem grande impacto na resiliência. Por exemplo, se um node que tinha 100 containers caiu, em vez de executar 100 gravações para movê-los para diferentes nodes, podemos fazer tudo isso em uma única gravação.

A otimização final está em quão eficiente os dados são persistidos tanto em termos de tamanho (buffers de protocolo) quanto de desempenho (domínio específico de indexação). Podemos imediatamente consultar na memória os containers que estão sendo executados em uma determinada máquina, os containers que não são saudáveis para um serviço específico etc.

swarm-quorum-layer

Comunicação do gerente para o trabalhador

Nodes trabalhadores conversam com os nodes gerentes usando gRPC, um protocolo rápido que funciona muito bem em condições de rede adversas, permite a comunicação através de links de Internet (construídos sobre HTTP/2) e foi construído com controle de versão (de modo que diferentes nodes trabalhadores executando diferentes versões da Engine podem falar com o mesmo node gerente). Gerentes enviam aos trabalhadores conjuntos de tarefas a serem executadas. Trabalhadores enviam aos gerentes o status das tarefas em seu conjunto de atribuição, e num piscar de olhos para que os gerentes possam confirmar que o trabalhador ainda está vivo.

Como o diagrama abaixo ilustra, o componente dispatcher do código gerente é o que finalmente se comunica com os trabalhadores. É responsável por despachar tarefas para cada trabalhador, enquanto o trabalhador (através da seu componente executor) é responsável por traduzir essas tarefas em containers e criá-los.

swarm-node-breakdown

Com base no diagrama acima, vamos caminhar brevemente através do que acontece quando um serviço Docker é criado e, finalmente, gerar esse conjunto de recipientes:

Criação de serviços

  • Usuário envia a definição de serviço para a API. A API aceita e armazena.
  • Orquestrador reconcilia o estado desejado (como definido pelo usuário) com o estado atual (que está atualmente em execução no swarm). Ele vai pegar o novo serviço criado pela API e responder a ele através da criação de uma tarefa (assumindo, nesse caso, que o usuário solicitou apenas uma instância do serviço).
  • Alocador aloca recursos para as tarefas. Ele vai notar um novo serviço (criado pelo API) e uma nova tarefa (criada pelo orquestrador) e vai atribuir endereços IP para ambos.
  • Scheduler é responsável por atribuir tarefas a nodes trabalhadores. Ele vai notar uma tarefa sem node atribuído e, portanto, vai começar a programação. Ele tenta encontrar a melhor correspondência (com base em restrições, recursos…) e, finalmente, ele vai atribuir a tarefa a um dos nodes.
  • Dispatcher é onde os trabalhadores se conectam. Uma vez que os trabalhadores estão ligados ao Dispatcher, eles esperam para obter instruções. Dessa forma, uma tarefa atribuída pelo scheduler irá eventualmente fluir para o trabalhador.

Atualização de serviço

  • O usuário atualiza uma definição de serviço através da API (por exemplo, alteração de 1 para 3 instâncias). A API aceita e armazena.
  • Orquestrador reconcilia desejado vs real. Ele vai notar que mesmo que o usuário queira 3 instâncias, apenas 1 está em execução e irá responder a isso criando duas tarefas adicionais.
  • Alocador, Scheduler e Dispatcher irão executar os mesmos passos como explicado acima e as duas novas tarefas irão pousar nos trabalhadores.

Falha no node

  • Dispatcher detectará um node que estava ligado a ele e falhou (por causa de batimentos cardíacos). Ele vai sinalizar o node como caído.
  • Orquestrator reconcilia. 3 instâncias devem ser executadas, mas uma delas falhou. Responde criando uma nova tarefa.
  • Alocador, Scheduler e Dispatcher irão executar os mesmos passos como explicado acima e as 2 novas tarefas irão pousar em novos nodes trabalhadores.

worker-to-worker-gossip

Os trabalhadores usam uma rede Gossip para comunicar a informação de rede uns com os outros. O Gossip é um grande volume, rede peer to peer (P2P) projetada para funcionar em alta escala. Um node aceita uma tarefa, começa um container e, em seguida, ele informa os outros nodes que um container foi iniciado na rede de sobreposição especificada. Essa transmissão da comunicação acontece na camada trabalhador. A escala é conseguida porque a informação é gossiped apenas para um número constante de nodes aleatórios e não para todos os nodes que funcionam da mesma maneira, independentemente do tamanho do swarm.

O que tudo isso significa?

Então, o que a orquestração do Docker 1.12 realmente significa para desenvolvedores e operadores? Há três temas realmente importantes nesse release capacitados pela rica arquitetura detalhada acima:

  • Plataforma de implementação de aplicativo tolerante a falhas. Aplicativos modernos são cada vez mais concebidos em um padrão de arquitetura de microsserviços, em que o processo de servir de volta os dados para um usuário pode precisar chamar vários serviços diferentes. Máquinas do mundo real falham o tempo todo, e esses microsserviços precisam continuar disponíveis, mesmo em face de tais falhas aleatórias. O Docker 1.12 te dá esse poder, fornecendo um projeto zero-SPOF, aproveitando um quórum de gestores, além de uma abstração de serviço que gera várias réplicas e rapidamente as reprograma se seu hospedeiro desaparece.
  • Escala e desempenho. A orquestração do Docker 1.12 em Swarm mode foi concebida do zero com escala e desempenho em mente. Por exemplo, a loja interna distribuída Raft foi otimizada para leituras relâmpago através de uma camada de cache em memória. Caching possibilita leitura rápida, mas o que acontece quando uma gravação acontece?  É claro que o cache em cada máquina deve ser invalidado e atualizado. Nossa solução para esse problema foi desenhar o resto da orquestração do sistema de maneira que as leituras são intensivas mas apenas para gravação loja Raft quando absolutamente necessário. Essa combinação de decisões de design leva a um sistema de orquestração que proporciona melhor desempenho do que o que é possível com orchestrators que são baseados em lojas de key-value genéricas.
  • Rede segura. Em muitos sistemas, a segurança é algo que você tem que “ligar” através da geração de certificados TLS, executando o sistema em uma porta diferente, e descobrindo os fluxos de tráfego para garantir que nenhum pacote passe para uma rede insegura sem criptografia. Com o Docker 1.12, todas essas coisas são feitas para você fora da caixa [*].  O sistema é “seguro por padrão”, o que significa que você não precisa ser um especialista em segurança para obter uma plataforma segura de gerenciamento de aplicações.

[*] Há uma pequena exceção a essa declaração.  Para o tráfego de rede de sobreposição, as versões atuais do Docker exigem que você especifique manualmente a flag -o encrypted (em docker network create -d overlay) para ativar a criptografia. Para todos os outros tráfegos, a criptografia está habilitada por padrão.

Confira o Docker 1.12 Modo Swarm Deep Dive:

***

Este artigo é do Docker Core Engineering. A tradução do artigo foi feita pela Redação iMasters, e você pode acompanhar o artigo em inglês no link: https://blog.docker.com/2016/07/docker-built-in-orchestration-ready-for-production-docker-1-12-goes-ga/#comment-354936

Mensagem do anunciante:

Experimente a Umbler, startup de Cloud Hosting por demanda feita para agências e desenvolvedores e ganhe até R$ 100 em créditos!

Source: IMasters

Categorizados em:

Este artigo foi escrito pormajor

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *