👇 💇🏾 🧀 Contentores para adultos (parte 01): um guia prático de terminologia 🐘 🈚️ 🧑🏿‍🤝‍🧑🏻

Você pode perguntar: por que lidar com terminologia se o conceito de contêiner parece bastante simples e direto? No entanto, muitas vezes o uso incorreto de termos cria obstáculos ao desenvolvimento de contêineres. Por exemplo, as pessoas geralmente pensam que os termos “contêineres” e “imagens” são usados de forma intercambiável, embora, de fato, haja importantes diferenças conceituais entre eles. Outro exemplo: no mundo dos contêineres, um "repositório" não significa o que você pensa. Além disso, a tecnologia de contêiner é muito mais do que apenas estivador.

Portanto, sem conhecer a terminologia, será difícil entender como o docker difere do CRI-O, rkt ou lxc / lxd; ou avaliar o papel da Open Container Initiative na padronização de tecnologias de contêineres.

1. Introdução

A introdução aos contêineres Linux é muito simples, mas logo se descobre que essa simplicidade é enganosa. Isso geralmente acontece assim: depois de passar apenas alguns minutos instalando uma janela de encaixe ou outro mecanismo de contêiner, você já insere seus primeiros comandos. Apenas alguns minutos - e você já criou sua primeira imagem do contêiner e a colocou em domínio público. Em seguida, você costuma seguir para a arquitetura do ambiente de produção e, de repente, percebe que, para isso, precisa primeiro lidar com a massa de termos e tecnologias que estão por trás de tudo isso. Pior, muitos dos termos listados abaixo são usados de forma intercambiável, o que cria muita confusão para iniciantes.

Container
Imagem
Imagem do container
Camada de imagem
Registo
Repositório
Tag
Imagem Base
Imagem da plataforma
Camada

Tendo dominado a terminologia estabelecida neste documento, você entenderá melhor a base tecnológica dos contêineres. Além disso, ajudará você e seus colegas a falarem o mesmo idioma, bem como o design consciente e intencional da arquitetura de ambientes de contêineres, de acordo com as especificidades das tarefas que estão sendo resolvidas. Por sua vez, do ponto de vista da comunidade de TI e da indústria como um todo, um aumento geral no entendimento das tecnologias de contêineres contribui para o surgimento de novas arquiteturas e soluções. Observe que este artigo é destinado a um leitor que já tenha uma idéia de como executar contêineres.

Contentores: Básico

Antes de prosseguir com a terminologia dos contêineres, determinaremos o que é, de fato, o próprio contêiner. O termo "contêiner" significa duas coisas ao mesmo tempo. Como um programa Linux normal, um contêiner pode estar em um dos dois estados: funcionando e não funcionando. No estado inativo, o contêiner é um arquivo ou um conjunto de arquivos armazenados no disco. É nesse estado que os termos Imagem do contêiner e Repositório do contêiner se referem. Quando você insere o comando de inicialização do contêiner, o mecanismo do contêiner descompacta os arquivos e metadados necessários e os transfere para o kernel do Linux. Iniciar um contêiner é muito semelhante a iniciar um processo normal do Linux e requer uma chamada de API para o kernel do Linux. Essa chamada de API geralmente inicia um isolamento adicional e monta uma cópia dos arquivos que estão na imagem do contêiner. Após o lançamento do contêiner, é apenas um processo do Linux. O procedimento para iniciar contêineres, bem como o formato das imagens dos contêineres armazenados em disco, são definidos e regulamentados por padrões.

Existem vários formatos para imagens de contêiner ( Docker , Appc , LXD ), mas o setor está gradualmente se movendo em direção a um único padrão da Open Container Initiative , às vezes chamado de Open Containers ou simplesmente OCI. Esse padrão define a especificação do formato da imagem do contêiner , que define o formato do disco para armazenar imagens do contêiner, bem como os metadados, que, por sua vez, definem coisas como a arquitetura de hardware e o sistema operacional (Linux, Windows, etc.). Um único formato de imagem em todo o setor é a chave para criar um ecossistema de software que permite que desenvolvedores, projetos de código aberto e fornecedores de software criem imagens compatíveis e várias ferramentas, como assinatura eletrônica, varredura, montagem, lançamento, movimentação e gerenciamento de imagens de contêiner.

Além disso, existem vários motores de contêiner, como Docker , CRI-O , Railcar , RKT , LXC . O mecanismo de contêiner obtém uma imagem do contêiner e o transforma em um contêiner (isto é, um processo em execução). O processo de conversão também é definido pelo padrão OCI, que inclui uma especificação de tempo de execução do contêiner e uma implementação de referência de tempo de execução chamada RunC, que é um modelo de código aberto que é regulado pela comunidade de desenvolvimento apropriada. Muitos mecanismos de contêiner usam esse modelo para interagir com o kernel host ao criar contêineres.

As ferramentas que suportam as especificações do formato de imagem do contêiner e o ambiente de execução do contêiner do padrão OCI fornecem portabilidade no ecossistema de várias plataformas de contêineres, mecanismos de contêiner e ferramentas de suporte em várias plataformas em nuvem e arquiteturas locais. Compreender a terminologia, os padrões e a arquitetura dos sistemas de contêineres permitirá que você se comunique com outros especialistas e projete aplicativos e ambientes em contêineres escalonáveis e suportados que garantam o uso eficiente dos contêineres nos próximos anos.

Vocabulário básico

Imagem do contêiner

Em sua definição mais simples, uma imagem de contêiner é um arquivo baixado do servidor de registro e usado localmente como um ponto de montagem quando o contêiner é iniciado. Apesar de o termo "imagem de contêiner" ser usado com bastante frequência, ele pode significar coisas diferentes. O fato é que, embora o Docker, o RKT e até o LXD funcionem de acordo com o princípio descrito, ou seja, eles baixam arquivos excluídos e os executam como contêineres, cada uma dessas tecnologias interpreta a imagem do contêiner de sua própria maneira. O LXD opera com imagens monolíticas (camada única), enquanto o docker e o RKT usam imagens OCI, que podem conter várias camadas.

A rigor, uma imagem de contêiner em um servidor de registro está longe de ser um único arquivo. Quando as pessoas usam o termo "imagem do contêiner", geralmente significam o repositório e um conjunto de várias camadas da imagem do contêiner, além de metadados que contêm informações adicionais sobre essas camadas.

Além disso, o conceito de uma imagem de contêiner implica implicitamente a existência de um formato para essa imagem.

Formato de imagem do contêiner

Inicialmente, cada mecanismo de contêiner, incluindo LXD, RKT e Docker, tinha seu próprio formato de imagem. Alguns desses formatos permitem apenas uma camada, enquanto outros suportam uma estrutura em árvore de várias camadas. Hoje, quase todas as principais ferramentas e mecanismos de contêiner mudaram para o formato OCI , que determina como as camadas e os metadados devem ser organizados na imagem do contêiner. Em essência, o formato OCI define uma imagem de contêiner que consiste em arquivos tar separados para cada camada e um arquivo manifest.json comum contendo metadados.

O padrão Open Container Initiative (OCI) , originalmente baseado no formato de imagem Docker V2 , combinou com sucesso um grande ecossistema de mecanismos de contêiner, plataformas e ferramentas em nuvem (scanners de segurança, ferramentas de assinatura, criação e movimentação de contêineres) e permite proteger seu investimento em conhecimento e ferramentas

Motor para contêiner

O mecanismo de contêiner é a parte do software que aceita solicitações de usuário, incluindo parâmetros de linha de comando, baixa imagens e, da perspectiva do usuário final, lança contêineres. Existem muitos mecanismos de contêiner, incluindo docker, RKT, CRI-O e LXD. Além disso, muitas plataformas em nuvem, serviços de PaaS e plataformas de contêineres têm seus próprios mecanismos que entendem imagens no formato Docker ou OCI. Ter um padrão do setor para o formato de imagem garante a interoperabilidade de todas essas plataformas.

Ao descer um nível, podemos dizer que a maioria dos mecanismos de contêineres não inicia os contêineres, mas através de um tempo de execução compatível com OCI, como runc. Normalmente, um tempo de execução do contêiner faz o seguinte:

Lida com parâmetros, entrada do usuário
Manipula os parâmetros passados pela API (geralmente o sistema de orquestração de contêiner)
Baixe imagens de contêiner do servidor de registro
Descompacta e salva a imagem do contêiner em disco usando o Driver Gráfico (bloco ou arquivo, dependendo do driver)
Prepara um ponto de montagem para o contêiner, geralmente no armazenamento de copiar na gravação (novamente, em bloco ou arquivo, dependendo do driver)
Prepara os metadados que serão passados para o tempo de execução para executar o contêiner corretamente usando:
- Configurações padrão específicas implícitas para a imagem do contêiner (por exemplo, ArchX86 )
- Entrada do usuário para substituir os valores padrão contidos na imagem do contêiner (por exemplo, CMD, ENTRYPOINT)
- Parâmetros padrão especificados pela imagem do contêiner (por exemplo, regras SECCOM )
Invoca o tempo de execução do contêiner

Container

Os contêineres existem nos sistemas operacionais há algum tempo, porque na verdade essa é apenas uma instância em execução de uma imagem de contêiner. Um contêiner é um processo Linux padrão que geralmente é criado usando a chamada do sistema clone () em vez de fork () ou exec (). Além disso, medidas adicionais de isolamento são frequentemente aplicadas a contêineres usando cgroups , SELinux ou AppArmor .

Host do contêiner

Um host de contêiner é um sistema no qual os processos em contêiner são executados, geralmente chamados de contêineres por simplicidade. Pode ser, por exemplo, uma máquina virtual RHEL Atomic Host localizada em uma nuvem pública ou executando bare metal em um data center corporativo. Quando a imagem do contêiner (em outras palavras, o repositório) do servidor de registro é baixada para o host do contêiner local, eles dizem que ela cai no cache local.

Você pode determinar quais repositórios são sincronizados com o cache local usando o seguinte comando:

  [root @ rhel7 ~] # imagens do docker -a

 ID DE IMAGEM DE REPOSITÓRIO IDENTIFICADO TAMANHO VIRTUAL
 registry.access.redhat.com/rhel7 mais recente 6883d5422f4e 3 semanas atrás 201,7 MB

Servidor de registro

Um servidor de registro é essencialmente um servidor de arquivos usado para armazenar repositórios de janela de encaixe. Como regra, o servidor de registro é especificado pelo nome DNS e, opcionalmente, pelo número da porta. A maioria dos benefícios do ecossistema docker é impulsionada pela capacidade de baixar e carregar repositórios nos servidores de registro.

Se o daemon do docker não encontrar uma cópia do repositório no cache local, ele fará o download automaticamente do servidor de registro. Na maioria das distribuições Linux, o daemon docker usará o site docker.io para isso, mas em algumas distribuições ele pode ser configurado da sua maneira. Por exemplo, o Red Hat Enterprise Linux tenta primeiro fazer o download do registry.access.redhat.com e somente depois do docker.io (Docker Hub).

Deve-se enfatizar aqui que o servidor de registro é implicitamente considerado confiável. Portanto, você deve decidir quanto confia no conteúdo de um registro e, respectivamente, permitir ou negar. Além da segurança, há outros aspectos que devem ser abordados com antecedência, por exemplo, problemas de licenciamento de software ou monitoramento de conformidade. A simplicidade com a qual o docker permite que os usuários baixem software torna a questão da confiança extremamente importante.

O Red Hat Enterprise Linux permite que você configure o registro do docker padrão. Além disso, o RHEL7 e o RHEL7 Atomic permitem adicionar ou bloquear servidores de registro por meio do arquivo de configuração :

  vi / etc / sysconfig / docker

RHEL7 e RHEL 7 Atomic usam o servidor de registro Red Hat por padrão:

  ADD_REGISTRY = '- adicione o registro registry.access.redhat.com'

Em alguns casos, por motivos de segurança, faz sentido bloquear registros públicos de janelas de encaixe, como o DockerHub:

  # BLOCK_REGISTRY = '- registro de bloco'

A Red Hat também oferece seu servidor de registro integrado como parte da OpenShift Container Platform , bem como o servidor de registro corporativo independente Quay Enterprise e repositórios em nuvem, públicos e privados Quay.io.

Orquestração de contêineres

As pessoas geralmente começam instalando um host de contêiner e primeiro baixando as imagens de contêiner de que precisam. Em seguida, eles criam suas próprias imagens e as carregam no servidor de registro para disponibilizar para o restante da equipe. Depois de algum tempo, é necessário combinar vários contêineres para que eles possam ser implantados como uma unidade. E, finalmente, em algum momento, essas unidades devem fazer parte do transportador de produção (development-QA-production). É assim que as pessoas geralmente percebem que precisam de um sistema de orquestração.

O sistema de orquestração de contêiner implementa apenas duas coisas:

Despachar dinamicamente cargas de contêiner entre computadores de cluster (geralmente chamado de "computação distribuída")
Fornece um arquivo de descrição de aplicativo padrão (kube yaml, composição do docker, etc.)

Essas duas coisas realmente oferecem uma série de benefícios:

A capacidade de gerenciar os contêineres que compõem o aplicativo, independentemente um do outro, o que permite resolver efetivamente as seguintes tarefas:
- Eliminação de grandes clusters de hosts de contêiner
- Falha no nível de contêineres individuais (não há mais processos de resposta, exaustão de memória)
- Failover no nível do host do contêiner (unidades, rede, reinicialização)
- Failover no nível do mecanismo do contêiner (dano, reinicialização)
- Escalonamento individual de contêineres para cima e para baixo
Fácil de implantar novas instâncias do mesmo aplicativo em novos ambientes, tanto na nuvem quanto na tradicional, por exemplo:
- Em máquinas de desenvolvedor controladas por um sistema de orquestração
- Em um ambiente de desenvolvimento compartilhado em um espaço para nome privado
- Em um ambiente de desenvolvimento comum em um espaço para nome público interno para garantir a visibilidade e o desempenho do teste
- No ambiente interno do controle de qualidade
- Em um ambiente de carga de teste fornecido dinamicamente e revogado na nuvem
- Em um ambiente de referência para verificar a compatibilidade com o ambiente de produção
- No ambiente de produção
- Em um ambiente de recuperação de desastre
- Em um novo ambiente de produção contendo hosts de contêiner atualizados, mecanismos de contêiner ou ferramentas de orquestração
- No novo ambiente de produção, que não é diferente do principal, mas localizado em uma região diferente

Comunidades de código aberto e fornecedores de software oferecem muitas ferramentas diferentes de orquestração. Inicialmente, as três grandes ferramentas incluíam Swarm , Mesos e Kubernetes , mas hoje o Kubernetes se tornou o padrão do setor, porque até o Docker e o Mesosphere anunciaram seu apoio, sem mencionar quase todos os principais provedores de serviços. No entanto, se você estiver procurando por um sistema de orquestração corporativo, recomendamos que você analise mais de perto o Red Hat OpenShift .

Dicionário Avançado

Tempo de execução do contêiner

O tempo de execução do contêiner é um componente de baixo nível que normalmente é usado como parte de um mecanismo de contêiner, mas também pode ser usado manualmente para testar contêineres. O padrão OCI define uma implementação de referência do tempo de execução conhecido como runc . Essa é a implementação mais usada, mas existem outros tempos de execução compatíveis com OCI, como crun , railcar e katacontainers . Docker, CRI-O e muitos outros mecanismos de contêiner usam runc.

O tempo de execução do contêiner é responsável pelos seguintes itens:

Obtém o ponto de montagem do contêiner fornecido pelo mecanismo de contêiner (para teste, poderia ser apenas um diretório)
Obtém os metadados do contêiner fornecidos pelo mecanismo de contêiner (durante o teste, pode ser um arquivo config.json montado manualmente)
Comunica-se com o kernel do SO para iniciar processos em contêiner (via chamada de sistema clone)
Configura cgroups
Configura a política do SELinux
Configura regras da armadura de aplicativo

Um pouco de digressão histórica: quando o mecanismo do Docker apareceu pela primeira vez, ele usou o LXC como um ambiente de tempo de execução. Os desenvolvedores do Docker então criaram sua própria biblioteca para executar contêineres chamados libcontainer. Foi escrito no idioma Golang e tornou-se parte do mecanismo do Docker. Após o estabelecimento da organização OCI, o Docker introduziu o código-fonte libcontainer nesse projeto e lançou esta biblioteca como um utilitário separado chamado runc, que se tornou a implementação de referência do tempo de execução do contêiner dentro do padrão OCI e é usado em outros mecanismos de contêiner, como o CRI-O . Runc é um utilitário muito simples que apenas espera que um ponto de montagem (diretório) e metadados (config.json) sejam passados para ele. Mais informações sobre runc podem ser encontradas aqui .

Para um entendimento mais aprofundado, consulte Noções básicas sobre padrões de contêiner e o tempo de execução do contêiner .

Camadas de imagem

Os repositórios são frequentemente referidos como imagens ou imagens de contêineres, embora na verdade os repositórios consistam em uma ou mais camadas. As camadas de imagem no repositório são interconectadas pelos relacionamentos pai-filho e cada camada de imagem contém diferenças da camada pai.

Vejamos as camadas do repositório no host do contêiner local. Desde o início da versão 1.7, o Docker não possui uma ferramenta interna para exibir camadas de imagem no repositório local (mas existem ferramentas para registros online), usaremos o utilitário Dockviz . Observe que cada camada possui uma tag e um identificador exclusivo universal (UUID) . Para visualizar UUIDs abreviados que geralmente são únicos na mesma máquina, usamos o seguinte comando (se você precisar de um UUID completo, use o mesmo comando com a opção -no-trunc):

docker run --rm --privileged -v /var/run/docker.sock:/var/run/docker.sock nate / dockviz images -t

  ├─2332d8973c93 Tamanho virtual: 187.7 MB
  Virtual └─ea358092da77 Tamanho virtual: 187,9 MB
  │ └─a467a7c6794f Tamanho virtual: 187,9 MB
  │ └─ca4d7b1b9a51 Tamanho virtual: 187,9 MB
  │ └─4084976dd96d Tamanho virtual: 384,2 MB
  Virtual └─943128b20e28 Tamanho virtual: 386,7 MB
  Virtual └─db20cc018f56 Tamanho virtual: 386,7 MB
  Virtual └─45b3c59b9130 Tamanho virtual: 398.2 MB
  Virtual └─91275de1a5d7 Tamanho virtual: 422,8 MB
  Virtual └─e7a97058d51f Tamanho virtual: 422,8 MB
  Virtual └─d5c963edfcb2 Tamanho virtual: 422.8 MB
  Virtual └─5cfc0ce98e02 Tamanho virtual: 422,8 MB
  Virtual └─7728f71a4bcd Tamanho virtual: 422,8 MB
  Virtual └─0542f67da01b Tamanho virtual: 422,8 MB Tags: docker.io/registry:latest

Como você pode ver, o repositório docker.io/registry na verdade consiste em várias camadas. No entanto, mais importante, o usuário pode, em princípio, "iniciar" o contêiner a partir de qualquer etapa dessa escada, por exemplo, digitando o comando abaixo (está completamente correto, mas ninguém pode garantir que foi testado ou que funcionará corretamente). Como regra, o coletor de imagens identifica (cria nomes) as camadas que devem ser usadas como ponto de partida:

  docker run -it 45b3c59b9130 bash

Os repositórios são organizados de maneira semelhante, porque sempre que o coletor cria uma nova imagem, as diferenças são salvas como outra camada. Existem duas maneiras principais de criar novas camadas no repositório. Primeiro, ao criar uma imagem manualmente, cada confirmação de alteração cria uma nova camada. Se o coletor criar uma imagem usando um arquivo Docker, cada diretiva no arquivo criará uma nova camada. Portanto, é sempre útil poder ver o que mudou no repositório entre as camadas.

Contentores para adultos (parte 01): um guia prático de terminologia