Docker 1.12: agora com orquestração interna!

julho 25, 2016 6:00 pm Publicado por Deixe um comentário

Três anos atrás, o Docker fez uma tecnologia esotérica do kernel do Linux chamada conteinerização simples e acessível a todos. Recentemente, fizemos o mesmo para a orquestração de container (container orchestration).

Orquestração do container é o que é necessário para a transição de deploy de container individualmente em um único host, para a implantação de aplicativos complexos de multi-containers em muitas máquinas. Ela exige uma plataforma distribuída, independente da infraestrutura, que permaneça online durante todo o tempo de vida de sua aplicação, sobrevivendo a atualizações de falha de hardware e software. A orquestração está no mesmo estágio hoje que a conteinerização estava há três anos. Há duas opções: ou você precisa de um exército de especialistas em tecnologia para remendar um sistema ad hoc complexo, ou você tem que confiar em uma empresa com um monte de especialistas para cuidar de tudo para você, enquanto você compra todo o hardware, serviços, suporte e software deles. Há uma palavra para isso: lock-in.

Usuários do Docker têm compartilhado conosco que nenhuma opção é aceitável. Em vez disso, você precisa de uma plataforma que deixa a orquestração ser utilizável por todos, sem o lock-in. Orquestração de container seria mais fácil de implementar, mais portátil, segura, resiliente e mais rápida se fosse construída na plataforma.

Começando com o Docker 1.12, nós adicionamos funcionalidades ao núcleo do Docker Engine para fazer facilmente multi-host e orquestração multi-container. Nós adicionamos novos objetos da API, como Service e Node, que permitirá que você use a API Docker para deploy e gerencie aplicativos em um grupo de Docker Engines chamado de swarm. Com o Docker 1.12, a melhor maneira de orquestrar Docker é com o Docker!

docker-1

O projeto Docker 1.12 é baseado em quatro princípios:

  • Simples, mas poderoso – Orquestração é uma parte central de aplicações distribuídas modernas; é tão central que nós a construimos perfeitamente em nosso núcleo Docker Engine. Nossa abordagem para orquestração segue a nossa filosofia sobre container: nenhuma configuração, apenas um pequeno número de conceitos simples para aprender, e um “simplesmente funciona” quanto à experiência do usuário.
  • Resiliente – máquinas falham o tempo todo. Os sistemas modernos devem esperar essas falhas ocorrerem regularmente e adaptar-se, sem qualquer tempo de inatividade, e é por isso que um projeto sem um único ponto de falha é obrigatório.
  • Segurança – A segurança deve ser o padrão. Barreiras para segurança forte – geração de certificados, tendo que entender PKI – devem ser removidas. Mas usuários avançados ainda devem ser capazes de controlar e auditar todos os aspectos da assinatura de certificado e emissão.
  • Recursos opcionais e compatibilidade com versões anteriores – Com milhões de usuários, preservar a compatibilidade com versões anteriores é uma obrigação para o Docker Engine. Todos os novos recursos são opcionais, e você não tem qualquer sobrecarga (memória, CPU) se você não usá-los. Orquestração no Docker Engine alinha com as plataformas de baterias incluídas, mas a abordagem swappable permite que os usuários continuem usando qualquer orquestrador de terceiros que é construído sobre o Docker Engine.

Vamos dar uma olhada em como os novos recursos do Docker 1.12 funcionam.

Criando Swarms com um bloco de construção descentralizado

Tudo começa com a criação de um grupo swarm – auto-curável de engines – que para o node de bootstrap é tão simples como:

docker swarm init

Sob o capô, isso cria um grupo de consenso Raft de um node. Esse primeiro node tem o papel de manager, o que significa que aceita comandos e agenda tarefas. Conforme você juntar mais nodes ao swarm, eles vão por padrão ser workers, que irão simplesmente executar containers enviados pelo manager. Opcionalmente, você pode adicionar manager nodes adicionais. Os manager nodes farão parte do grupo de consenso Raft. Nós usamos um armazenamento Raft otimizado em que as leituras são atendidas diretamente da memória, o que torna o desempenho do agendamento rápido.

Criando e escalando os serviços

Assim como você executa um único container com o docker run, você pode agora começar um processo de balanceamento de carga replicado e distribuído em um swarm de Engines com o docker service:

docker service create –name frontend –replicas 5 -p 80:80/tcp nginx:latest

Esse comando declara um estado desejado no seu swarm de 5 containers nginx, acessível como um único serviço de balanceamento de carga na porta 80 de qualquer node no seu swarm. Internamente, nós fazemos isso funcionar usando Linux IPVS, uma camada de 4 multiprotocolos de balanceador de carga no kernel que está no kernel do Linux há mais de 15 anos. Com os pacotes de roteamento IPVS dentro do kernel, o encaminhamento do swarm oferece alto desempenho de balanceamento de carga no container-aware.

Quando você cria serviços, você pode, opcionalmente, criar serviços replicados ou globais. Serviços replicados significam que qualquer número de recipientes que você definir serão distribuídos entre os hosts disponíveis. Serviços globais, em contrapartida, agendam uma instância do mesmo container em cada host do swarm.

Vamos voltar à forma como Docker fornece resiliência. Engines com o modo swarm habilitado são auto-curáveis, o que significa que eles estão cientes do aplicativo que você definiu e continuamente verificam e conciliam o ambiente quando as coisas dão errado. Por exemplo, se você desligar uma das máquinas que executam uma instância nginx, um novo container irá aparecer em outro node. Desligue o interruptor de rede para metade das máquinas em seu swarm, e a outra metade vai assumir, redistribuindo os containers entre si. Para atualizações, agora você tem flexibilidade na forma como você faz o re-deploy dos serviços quando você faz uma mudança. Você pode definir uma atualização contínua ou paralela dos recipientes em seu swarm.

Quer escalar até 100 instâncias? É tão simples como:

docker service scale frontend=100

Uma aplicação típica de duas camadas (web+db) seria criada assim:

docker network create -d overlay mynet
docker service create –name frontend –replicas 5 -p 80:80/tcp
–network mynet mywebapp
docker service create –name redis –network mynet redis:latest

Esta é a arquitetura básica desta aplicação:

docker-2

Segurança

Um dos princípios fundamentais para o Docker 1.12 é a criação de uma configuração zero, segura por padrão, a partir da experiência fora da caixa para a plataforma Docker. Um dos principais obstáculos que os administradores enfrentam muitas vezes com a implantação de aplicativos em produção é executá-los de forma segura, e o Docker 1.12 permite que um administrador siga os mesmos passos da criação de um cluster de demonstração para configurar um cluster de produção segura.

A segurança não é algo que você pode colocar após o fato. É por isso que o Docker 1.12 vem com TLS mutuamente autenticado, fornecendo autenticação, autorização e criptografia para as comunicações de cada node que participa do swarm, já pronto.

Ao iniciar o seu primeiro manager, o Docker Engine irá gerar uma nova autoridade de certificação (CA) e um conjunto de certificados iniciais para você. Após essa etapa inicial, cada node que ingressar no swarm terá automaticamente emitido um novo certificado com um ID gerado aleatoriamente e o seu papel atual no swarm (manager ou worker). Esses certificados serão usados como sua identidade node criptograficamente segura para o tempo de vida de sua participação nesse swarm, e serão utilizados pelos managers para garantir a difusão segura de tarefas e outras atualizações.

docker-3

Uma das maiores barreiras de adoção do TLS sempre foi a dificuldade de criar, configurar e manter a Public Key Infrastructure (PKI) necessária. Com o Docker 1.12, tudo não só é instalado e configurado com os padrões seguros para você, mas também automatizamos uma das partes mais dolorosas de lidar com certificados TLS: rotação de certificado.

Sob o capô, cada node que participa do swarm está constantemente atualizando seus certificados, assegurando que os certificados que potencialmente vazaram ou foram comprometidos não sejam mais válidos. A frequência com que os certificados são rodados pode ser configurada pelo usuário, e definida tão baixo quanto a cada 30 minutos.

Se você quiser usar a sua própria Autoridade de Certificação, nós também suportamos um modo external-CA, no qual os managers do swarm simplesmente retransmitem as solicitações da assinatura do Certificado dos nodes que tentam ingressar no cluster para uma URL remota.

Bundles

O Docker 1.12 introduz um novo formato de arquivo chamado de Distributed Application Bundle (somente em build experimental). Bundle é uma nova abstração no topo do serviço focada na aplicação de pilha completa.

Um arquivo Docker Bundle é uma especificação declarativa de um conjunto de serviços que determina:

  • Que revisão de imagem específica executar
  • Que redes criar
  • Como os containers desses serviços devem ser ligados na rede para rodar

Arquivos bundle são totalmente portáteis e são artefatos de implantação perfeitos para condutas de entrega de software, porque eles permitem que você envie aplicativos Docker multi-container totalmente especificados e versionados.

A especificação do arquivo bundle é simples e aberta, e você pode criar bundles como quiser. Para começar, Docker Compose tem suporte experimental para a criação de arquivos do bundle e, com Docker 1.12 e modo swarm habilitado, você pode fazer deploy dos arquivos do bundle.

Bundles são um mecanismo eficiente para mover aplicativos multi-serviços a partir de laptops dos desenvolvedores através de CI para a produção. É experimental, e estamos à procura de feedback da comunidade.

Sob o capô do Docker 1.12

Quando você olha sob o capô, o Docker 1.12 utiliza uma série de outras tecnologias interessantes. Comunicação inter-node é feita usando gRPC, que nos dá benefícios HTTP/2 como multiplexação de ligação e compressão de cabeçalho. Nossas estruturas de dados são transmitidas de forma eficiente graças a protobufs.

Veja estes recursos adicionais no Docker 1.12:

Saiba mais sobre Docker

Novo no Docker? Experimente o nosso tutorial online de 10 min

Compartilhe imagens, automatize builds, e mais, com uma conta gratuita Docker Hub

***

Docker Core Engineering faz parte do time de colunistas internacionais do iMasters. A tradução do artigo é feita pela redação iMasters, com autorização do autor, e você pode acompanhar o artigo em inglês no link: https://blog.docker.com/2016/06/docker-1-12-built-in-orchestration/

Mensagem do anunciante:

Conheça a Umbler, startup de Cloud Hosting por demanda feita para agências e desenvolvedores. Experimente grátis!

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 *