Questão de Sistemas Operacionais — Geral — VUNESP 2023

Containerd e a Arquitetura do Docker

Gabarito: letra C. O daemon containerd é o componente responsável por gerenciar o ciclo de vida dos containers (iniciar, parar, pausar, etc.), mas ele não executa essas operações sozinho — depende de outras ferramentas, como o runc, para a execução de fato. Essa é a essência da arquitetura modular do Docker, onde o containerd atua como uma camada intermediária entre o daemon do Docker e o runtime de baixo nível.

Para entender o papel do containerd, é preciso compreender a evolução da arquitetura do Docker. Nas versões 1.1 e posteriores, o Docker foi dividido em componentes especializados, cada um com uma função bem definida. O containerd (container daemon) é um desses componentes, e sua principal atribuição é gerenciar o ciclo de vida dos containers — ou seja, as operações de criar, iniciar, parar, pausar, retomar e destruir containers. No entanto, ele não realiza essas operações diretamente no sistema operacional; ele delega a execução a um runtime de nível mais baixo, como o runc, que é quem efetivamente interage com o kernel do Linux para criar os namespaces, cgroups e demais mecanismos de isolamento.

Essa separação de responsabilidades é uma decisão de design importante. O containerd fornece uma API estável e de alto nível para gerenciar containers, enquanto o runc (ou outro runtime compatível com a OCI — Open Container Initiative) cuida dos detalhes de baixo nível. Isso permite que o containerd seja usado não apenas pelo Docker, mas também por outras ferramentas de orquestração, como o Kubernetes, que pode usar o containerd diretamente como seu runtime de containers.

A alternativa C captura exatamente essa divisão de trabalho: o containerd gerencia as operações do ciclo de vida, mas "podendo contar com outras ferramentas para executar de fato essas operações". Essa é a descrição mais precisa do papel do containerd na arquitetura moderna do Docker.

As demais alternativas apresentam distorções sobre o papel do containerd. A alternativa A afirma que ele cria containers de forma standalone, o que é incorreto porque ele depende do runc para a criação efetiva. A alternativa B atribui a ele a função de prover a API do Docker, o que na verdade é papel do daemon dockerd. A alternativa D o descreve como um servidor web para download de imagens, o que é função de um registry (como o Docker Hub). A alternativa E, por fim, afirma que ele apenas para containers, o que é uma visão muito restrita e também incorreta, pois ele gerencia todo o ciclo de vida.

A pegadinha desta questão está em confundir o containerd com o daemon do Docker (dockerd). O dockerd é quem recebe os comandos do cliente docker e orquestra todo o processo, incluindo a comunicação com o containerd. Já o containerd é uma camada mais baixa, focada exclusivamente no gerenciamento do ciclo de vida dos containers. Guarde essa distinção: dockerd = API e orquestração; containerd = ciclo de vida dos containers; runc = execução de baixo nível.

Alternativa A — ❌ Incorreta

Afirma que o containerd cria containers de forma standalone, sem depender de outras ferramentas. Isso é falso: o containerd depende do runc (ou de outro runtime compatível com a OCI) para efetivamente criar e executar os containers. O containerd gerencia o ciclo de vida, mas a criação em si é delegada ao runtime de baixo nível.

Alternativa B — ❌ Incorreta

Atribui ao containerd a função de prover a API do Docker, respondendo diretamente às requisições do comando docker. Essa é a função do daemon dockerd, que é o componente que expõe a API REST do Docker e se comunica com o cliente docker. O containerd não expõe a API do Docker; ele é uma camada interna que o dockerd utiliza.

Alternativa C — ✅ Correta ⟵ GABARITO

Descreve corretamente o papel do containerd: gerenciar as operações do ciclo de vida dos containers (iniciar, parar, pausar, etc.), podendo contar com outras ferramentas (como o runc) para executar de fato essas operações. Essa é a definição precisa do containerd na arquitetura do Docker a partir da versão 1.1.

Alternativa D — ❌ Incorreta

Descreve o containerd como um servidor web que provê uma biblioteca de imagens para download. Essa é a função de um registry de imagens, como o Docker Hub ou um registry privado. O containerd não tem essa função; ele lida com o ciclo de vida dos containers, não com o armazenamento e distribuição de imagens.

Alternativa E — ❌ Incorreta

Afirma que o containerd apenas para containers em execução, de forma standalone. Isso é incorreto por dois motivos: primeiro, o containerd gerencia todo o ciclo de vida (criar, iniciar, parar, pausar, etc.), não apenas parar; segundo, ele não opera de forma standalone, pois depende de outras ferramentas para a execução efetiva.

A arquitetura do Docker pode ser visualizada como uma cadeia de responsabilidades:

Gabarito: letra C