Em dezembro anunciamos que o Docker está extraindo um componente-chave de sua plataforma de container, uma parte do motor de plumbing: containerd, um container central de runtime – que será doado para uma fundação aberta da comunidade. O containerd foi desenvolvido para ser menos acoplado e mais fácil de ser integrado a outros conjuntos de ferramentas. Ele está sendo feito para atender aos requisitos dos maiores provedores de nuvem e sistemas de orquestração de contêineres.

Como sabemos que muitos fãs do Docker querem saber como ele funciona internamente, nós pensamos em compartilhar o estado atual do Containerd e o que planejamos para a versão 1.0. Antes disso, é uma boa ideia olhar para o que o Docker se tornou nos últimos 3 ou 4 anos e meio.
A plataforma Docker não é um container runtime. É, na verdade, um conjunto de ferramentas integradas que permite que você construa, lance e execute aplicações distribuídas. Isso significa manusear a rede, infraestrutura, construção, orquestração, autorização, segurança e uma variedade de outros serviços que cobrem o ciclo de vida completo da aplicação.

O container central do runtime, que é o containerd, é uma parte pequena, porém vital, da plataforma. Começamos separando o containerd do resto do motor no Docker 1.11, planejando esse eventual lançamento.

Essa é uma amostra do motor do Docker 1.12 como atualmente está, e como o containerd se encaixa.

 

Você pode ver que o containerd contém apenas as APIs necessárias para executar um container. Uma API GRPC é chamada pelo Docker Engine, que inicia o processo de execução. Isso gera um supervisor e um executor que será responsável por monitorar e executar os contêineres. O container é executado pelo runC, que é um outro projeto plumbing que nós abrimos o código como uma referência da iniciativa de padrão de runtime da Open Container.

Quando o containerd atingir o 1.0, nós planejamos ter outras funcionalidades no Docker Engine também.

O conjunto de funcionalidades e escopo do containerd é:

• Um componente de distribuição que vai manipular um registro sem uma preferência para um vendor particular;
• Primitivas de rede para a criação as interfaces do sistema e APIs para gerenciar os namespaces de um container de rede;
• Armazenamento em nível de host para imagens e container filesystem;
• Uma API GRPI;
• Uma nova API de métricas no formato Prometheus para métricas no nível interno e de container;
• Suporte completo para a imagem OCI e referência de implementação runC

Uma revisão mais detalhada da arquitetura está disponível no repositório do projeto no GitHub.

Essa é uma amostra de uma futura versão do Docker Engine alavancando o containerd 1.0

O containerd é desenhado para ser incorporado em um sistema maior, ao invés de ser utilizado diretamente por desenvolvedores ou usuários finais; e na verdade essa evolução do Docker vai passar despercebida pelos usuários finais. Ele tem um CLI e ctr desenhados para depuração e testes, e uma API GRPC desenhada para ser embutida. É desenvolvido como um componente de entrada, desenhado para ser integrado a outros projetos que podem se beneficiar das lições que aprendemos executando contêineres.

Estamos na versão 0.2.4 do containerd, então muito trabalho precisa ser feito. Nós convidamos o ecosistema de contêineres a participar do projeto e estamos contentes em ter o apoio do Alibaba, AWS, Google, IBM e Microsoft que estão fornecendo colaboradores para ajudar a desenvolver o containerd. Você pode encontrar informações atualizadas de planejamento, arquitetura e definição dos APIs no repositório do GitHub.

***

Este artigo é do Docker Core Engineering. A tradução do artigo foi feita pela Redação iMasters com autorização, e você pode acompanhar o artigo em inglês no link: https://blog.docker.com/2016/12/containerd-core-runtime-component/