A missão do Docker é construir ferramentas de inovação em massa, começando com uma camada programável para a Internet que permite que desenvolvedores e equipes de operações de TI construam e executem aplicações distribuídas. Como parte dessa missão, temos sempre procurado contribuir com kits de ferramentas de software de volta para a comunidade, seguindo a filosofia UNIX da construção de pequenas ferramentas de baixo acoplamento que são criadas para simplesmente fazer uma coisa bem. Com a adoção do Docker crescendo de 0 para 6 bilhões, temos trabalhado para atender às necessidades de um conjunto crescente e diversificado de usuários de sistemas distribuídos. Esse trabalho levou à criação de muitos componentes de canalização de infraestrutura que foram contribuídos de volta para a comunidade.

Tudo começou em 2014, com o  libcontainer e o libnetwork. Em 2015, criamos o runC e cofundamos o OCI com uma vasta parceria com a indústria para fornecer um padrão para tempos de execução do container, uma implementação de referência com base em libcontainer e notary, que fornece a base para o Docker Content Trust. De lá para cá, acrescentamos o containerd, um daemon para controlar o runC, construido para desempenho e densidade. O motor do Docker foi refatorado para que o Docker 1.11 seja construído em cima de containerd e runC, proporcionando benefícios como a capacidade de atualizar o motor do Docker sem reiniciar os containers. Em maio de 2016, na OSCON, nós abrimos o código de HyperKit, VPNKit e DataKit,, os componentes subjacentes que nos permitem integrar profundamente o Docker a Mac e Windows com o sistema operacional nativo. Mais recentemente, em junho, revelamos o SwarmKit, um kit de ferramentas para tarefas de programação e a base para o modo swarm, o recurso de orquestração nativo no Docker 1.12.

Com o SwarmKit, o Docker introduziu um conjunto de ferramentas de gestão declarativa para orquestrar containers. Hoje, estamos fazendo o mesmo para a infraestrutura. Estamos animados em anunciar o InfraKit, um kit de ferramentas de gestão declarativa para orquestrar infraestrutura. Solomon Hykes o disponibilizou como código aberto no início de outubro, durante seu keynote na LinuxCon Europe. Você pode encontrar o código-fonte em https://github.com/docker/infrakit.

Origem do InfraKit

Em junho, no DockerCon, introduzimos Docker para AWS e Azure beta para simplificar a experiência de operações de TI na configuração do Docker e para otimizar e aproveitar as capacidades nativas do respectivo ambiente de nuvem. Para fazer isso, o Docker forneceu integrações profundas em capacidades nessas plataformas para armazenamento, rede e balanceamento de carga.

No diagrama abaixo, a arquitetura para essas versões inclui plugins de rede e armazenamento específicos da plataforma, mas também um novo componente específico para gestão de infraestrutura.

Enquanto trabalhávamos no Docker para AWS e Azure, percebemos a necessidade de ter uma forma padrão para criar e gerenciar o estado da infraestrutura que foi portado através de qualquer tipo de infraestrutura, de diferentes provedores de cloud computing e locais. Um desafio é que cada fornecedor tem um IP diferenciado investido em como eles lidam com certos aspectos da sua infraestrutura de nuvem. Não é suficiente apenas provisionar cinco servidores; o que as equipes de TI precisam é de uma maneira simples e consistente para declarar o número de servidores, que tamanho eles devem ter, e que tipo de configuração de software básica é necessária. E no caso de falhas no servidor (especialmente não planejadas), em que a mudança repentina tem de ser conciliada contra o estado desejado para garantir que todos os servidores necessários sejam re-provisionados com a configuração necessária. Começamos o InfraKit para resolver esses problemas e para fornecer a capacidade de criar uma infraestrutura de autorregeneração para sistemas distribuídos.

Por dentro do InfraKit

O InfraKit quebra a automação de infraestrutura em componentes simples, conectáveis para o estado da infraestrutura declarativa, vigilância ativa e reconciliação automática de estado. Esses componentes trabalham juntos para garantir ativamente que o estado da infraestrutura corresponde às especificações do usuário. O InfraKit enfatiza primitivas para a construção de infraestruturas de autorregeneração, mas também pode ser usado de forma passiva como ferramentas convencionais.

O InfraKit no núcleo é composto por um conjunto de processos ativos colaborativos. Esses componentes são chamados de plugins, e diferentes plugins podem ser escritos para atender a diferentes necessidades. Esses plugins são controladores ativos que podem olhar para o estado da infraestrutura atual e tomar medidas quando o estado diverge da especificação do usuário.

Inicialmente, esses plugins foram implementados como servidores de escuta em soquetes UNIX e se comunicam através de HTTP. Por natureza, as definições de interface plugin são independentes de linguagem, por isso é possível implementar um plugin em uma linguagem diferente do Go. Plugins podem ser empacotados e implementados de forma diferente, tal como acontece com os containers Docker.

Plugins são os componentes ativos que fornecem o comportamento para as primitivas que o InfraKit suporta. O InfraKit suporta estas primitivas: grupos, instâncias e flavors. Eles são componentes ativos que funcionam como plugins.

Grupos: Ao gerenciar a infraestrutura como clusters de computação, grupos fazem uma boa abstração, e trabalhar com grupos é mais fácil do que gerenciar instâncias individuais. Por exemplo, um grupo pode ser constituído por um conjunto de máquinas, assim como instâncias individuais. As máquinas de um grupo podem ter configurações idênticas (réplicas, ou os chamados “cattle”). Elas também podem ter configurações e propriedades um pouco diferentes, como identidade, ordenação e armazenamento persistente (como membros de um quórum ou os chamados “pets”).

Instâncias: Instâncias são membros de um grupo. Um plugin de instância administra algumas instâncias de recursos físicos. Ele sabe apenas sobre casos individuais e nada sobre grupos. Instância está tecnicamente definida pelo plugin, e não precisa ser uma máquina física. Como parte do kit de ferramentas, nós incluímos exemplos de plugins de instância para Vagrant e Terraform. Esses exemplos mostram que é fácil de desenvolver plugins. Eles também são exemplos de como o InfraKit pode jogar bem com ferramentas de gerenciamento de sistema existentes, ampliando as suas capacidades com uma gestão ativa. Nós encaramos mais plugins no futuro – por exemplo, plugins para o AWS e Azure.

Flavors: Flavors ajudam a distinguir os membros de um grupo de outro, descrevendo como esses membros devem ser tratados. Um plugin flavor pode ser pensado como ele define o que é executado em uma instância. Ele é responsável por configurar a instância física e por prover a verificação da saúde em uma application-aware.  Ele também é o que dá as propriedades das instâncias membros, como identidade e ordenação quando elas requerem um tratamento especial.  Exemplos de plugins de flavor incluem servidores simples, membros de conjunto Zookeeper e gerentes de modo swarm Docker. Ao separar o provisionamento de instâncias físicas e configuração de aplicativos em Instâncias e plugins Flavors, fornecedores de aplicativos podem desenvolver diretamente um plugin Flavor, por exemplo, MySQL, que pode trabalhar com uma grande variedade de plugins de instância.

Monitoramento ativo e reconciliação automática

O aspecto ativo de autorregeneração do InfraKit o diferencia de soluções de gerenciamento de infraestruturas existentes, e esperamos que ele ajude a nossa indústria a construir sistemas mais resistentes e autorregenerativos. Os plugins do InfraKit monitoram continuamente grupos, instâncias e flavors quanto a qualquer desvio na configuração e automaticamente os corrigem sem qualquer intervenção manual.

• O plugin de grupos faz a checagem do tamanho, da saúde geral do grupo e decide sobre as estratégias para a atualização.
• O plugin de instância monitora a presença física dos recursos.
• O plugin flavor pode fazer a determinação adicional além da presença do recurso. Por exemplo, o plugin flavor do modo swarm irá verificar não só que um node membro do swarm está funcionando, mas que o node é também membro do cluster. Isso fornece um significado específico do aplicativo para um node “health”.

Esse monitoramento ativo e reconciliação automática trazem um novo nível de confiabilidade para sistemas distribuídos.

O diagrama a seguir mostra um exemplo de como o InfraKit pode ser usado. Há três grupos definidos: um para o conjunto de instâncias de cattle stateless, um para o conjunto de instâncias pet com estado e com nomes exclusivos e um definido para o próprio gerente de instâncias Infrakit. Cada grupo será monitorado pelo seu estado de infraestrutura declarada e reconciliada de forma independente dos outros grupos. Por exemplo, se um dos nodes (azul e amarelo) no grupo de cattle cai, um novo será iniciado para manter o tamanho desejado. Quando o host líder (M2) executando o InfraKit cai, um novo líder será eleito (a partir do modo de espera M1 e M3). Esse novo líder vai entrar em ação iniciando um novo membro para se juntar ao quórum para garantir a disponibilidade e o tamanho desejado do grupo.

InfraKit, Docker e comunidade

O InfraKit nasceu de nossos esforços de engenharia no Docker para AWS e Azure, e as versões futuras terão uma maior integração do InfraKit no Docker e nesses ambientes, continuando no caminho de construir o Docker com um conjunto de componentes reutilizáveis.

Como mostra o diagrama abaixo, o motor do Docker já é constituído por um número de componentes de canalizações da infraestrutura mencionada anteriormente. Os componentes não só estão disponíveis separadamente para a comunidade, mas integrados em conjunto, como o Motor do Docker. Em uma versão futura, o InfraKit também vai se tornar parte do Motor do Docker.

Com a participação da comunidade, pretendemos evoluir o InfraKit em novas e excitantes áreas além da gestão nodes em um cluster. Há muito trabalho pela frente para construir isso em um framework coerente para a gestão de recursos de infraestrutura, físicos, virtuais ou em containers, de nodes de cluster nas redes para carregar balanceadores e volumes de armazenamento.

Estamos muito animados por abrir o código do InfraKit e convidamos a comunidade para participar desse projeto:

• Ajudar a definir e implementar plugins novos e interessantes
• Plugins de instância para suportar diferentes provedores de infraestrutura
• Plugins flavor para suportar uma variedade de sistemas, como clusters de ETCD ou MySQL
• Plugins de controle de grupo, como métricas autoescalabilidade e mais
• Ajudar a definir interfaces e implementar novos tipos de recursos de infraestrutura para coisas como balanceadores de carga, redes e provisionadores de volume de armazenamento

Confira o README do repositório do InfraKit para mais informações, um rápido tutorial e comece a experimentar – a partir de arquivos simples até integração Terraform para a construção de um conjunto Zookeeper. Dê uma olhada, explore e nos envie um PR ou abra uma issue com as suas ideias!

***

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/10/introducing-infrakit-an-open-source-toolkit-for-declarative-infrastructure/.