Existem muitos modelos de construção de contêineres. Um contêiner é apenas uma versão executável de sua própria imagem. Portanto, a maneira de construir um contêiner está intimamente relacionada a como ele é iniciado.
Algumas imagens de contêiner funcionam bem sem privilégios especiais; outras requerem privilégios de root. Além disso, a mesma imagem / contêiner pode combinar vários padrões de construção e cenários de uso ao mesmo tempo.
Abaixo, consideraremos os casos de uso de contêiner mais comuns.
(Para uma introdução à terminologia de contêiner, consulte a primeira
parte )
Cenários de uso de contêineres
Contêineres para aplicativos
Os contêineres de aplicativos são o tipo mais comum de contêiner. Desenvolvedores e proprietários de aplicativos os tratam e eles mesmos contêm o código-fonte, além de coisas como MySQL, Apache, MongoDB e Node.js.
Um vasto ecossistema de contêineres de aplicativos está sendo formado. Projetos como o Software Collections fornecem imagens de contêiner de aplicativos seguras e suportadas para o Red Hat Enterprise Linux. Ao mesmo tempo, os membros da comunidade Red Hat estão desenvolvendo e dando suporte a contêineres de aplicativos inovadores.
Na Red Hat, acreditamos que os contêineres de aplicativos geralmente não precisam de privilégios especiais. No entanto, ao criar ambientes de produção de contêineres, são necessários outros contêineres.
Contêineres do sistema operacional
O contêiner do sistema operacional é um contêiner muito mais parecido com um sistema operacional virtual completo. Esses contêineres também usam o kernel do host, mas executam o sistema init completo, o que lhes permite executar facilmente vários processos. Exemplos de contêineres do sistema operacional são LXC e LXD.
Os contêineres do sistema operacional podem, em princípio, ser emulados usando contêineres docker / OCI, desde que você possa executar o sistema dentro deles para que o usuário final possa instalar software dentro desses contêineres da maneira usual e percebê-los como um sistema operacional virtual completo.
yum install mysql systemctl enable mysql
Isso simplifica bastante a conteinerização de aplicativos existentes. A Red Hat está trabalhando duro para simplificar os contêineres do sistema operacional, permitindo que o systemd execute dentro do contêiner e use o daemon usinado. Embora muitos clientes ainda não estejam prontos para a arquitetura de microsserviço, a transição para um modelo de entrega de software em contêiner com base em imagens de contêiner ainda pode oferecer muitas vantagens.
Recipientes para animais de estimação
Embora a Red Hat recomende, promova e ofereça suporte ao uso de
modelos baseados em nuvem no desenvolvimento de novos aplicativos, sabemos que nem todos os aplicativos existentes serão reescritos dessa maneira. Em particular, porque muitos deles são tão únicos e inimitáveis que, em comparação com aplicativos padrão, parecem animais de estimação (animais de
estimação ) contra um rebanho de vacas. É para essas aplicações que os
recipientes especiais para
animais de estimação são projetados.
Os contêineres para animais de estimação combinam a portabilidade e a conveniência de uma infraestrutura de contêiner construída com base em servidores de registro, imagens e hosts de contêineres com a flexibilidade de um ambiente de TI tradicional, implementado em um contêiner separado. A idéia aqui é simplificar a conteinerização de aplicativos existentes devido à mesma
capacidade de usar systemd dentro do contêiner para usar ferramentas de automação existentes, instalações de software e outras ferramentas para criar facilmente imagens prontas para contêineres para lançamento.
Super Privilege Containers
Ao criar uma infra-estrutura de contêiner baseada em hosts de contêiner dedicados como o Host Atômico do Red Hat Enterprise Linux, os administradores de sistema ainda precisam gerenciar. E os
Super Privileged Containers (SPCs) provam ser muito úteis nesses ambientes distribuídos, seja Kubernetes, OpenShift ou até contêineres independentes. Os SPCs podem até carregar módulos especializados do kernel, como systemtap.
Na infraestrutura criada para executar contêineres, é provável que os administradores precisem de contêineres do SPC para executar tarefas como monitoramento, backup etc. É importante entender que, como os contêineres do SPC geralmente estão muito mais conectados ao núcleo do host, os administradores devem Preste atenção especial aos problemas de confiabilidade e padronização ao escolher sistemas operacionais host, especialmente em grandes ambientes em cluster e distribuídos que dificultam a solução de problemas. Além disso, os administradores precisam garantir que o espaço do usuário no SPC seja compatível com o núcleo do host.
Ferramentas e software do sistema
As distribuições Linux sempre forneciam ao usuário software do sistema, como Rsyslogd, SSSD, sadc, etc. Tradicionalmente, esse software era instalado na forma de pacotes RPM ou DEB, mas com o advento dos formatos de embalagens de contêineres, tornou-se mais fácil e conveniente instalar imagens de contêineres. Em particular, a Red Hat oferece coisas como contêineres prontos, como as ferramentas de virtualização da Red Hat, rsyslog, sssd e sadc.
Arquitetura de contêiner
À medida que a entrega de software em contêiner está ganhando força, novos padrões de design de contêiner estão surgindo. Nesta seção, falaremos sobre alguns deles.
A maneira como o contêiner é salvo no disco (em outras palavras, o formato da imagem) pode afetar muito a forma como ele é iniciado. Por exemplo, um contêiner projetado para executar o sssd deve ter privilégios especiais toda vez que iniciar, caso contrário, não poderá executar seu trabalho. Abaixo, consideramos brevemente os principais padrões que atualmente estão passando pelo estágio de formação ativa.
Imagens de aplicativos
É com essas imagens que os usuários finais lidam. Os cenários para usar essas imagens variam de DBMS e servidores da Web a aplicativos individuais e barramentos de serviço. Essas imagens podem ser criadas internamente pela organização ou fornecidas por fornecedores de software. Portanto, os usuários finais geralmente se relacionam com o conteúdo desses contêineres autônomos com cautela e escrupulosidade. Além disso, embora essa seja a opção mais fácil para o usuário final de contêineres, as imagens independentes são muito mais difíceis de projetar, criar e corrigir.
Imagens básicas
Uma imagem básica é um dos tipos mais simples de imagens. No entanto, as pessoas podem denotar esse termo com várias coisas, por exemplo, uma montagem corporativa padrão ou até uma imagem de aplicativo. Embora, estritamente falando, essas não sejam imagens básicas, mas intermediárias.
Portanto, deixe claro que a imagem base é uma imagem que não possui uma camada pai. As imagens básicas geralmente contêm uma cópia limpa do sistema operacional, bem como as ferramentas necessárias para instalar pacotes de software ou atualizar a imagem posteriormente (yum, rpm, apt-get, dnf, microdnf). Imagens básicas podem ser coletadas manualmente pelo usuário final, mas na prática elas geralmente são criadas e liberadas por comunidades de desenvolvimento (por exemplo, Debian, Fedora ou CentOS) ou fornecedores de software (por exemplo, Red Hat). A origem da imagem base é fundamental para a segurança. Resumindo, o principal e único objetivo da imagem básica é fornecer uma base com base na qual você pode criar suas imagens filhas. Ao usar o dockerfile, a seleção da imagem base subjacente é feita explicitamente:
FROM registry.access.redhat.com/rhel7-atomic
Imagens do construtor
Este é um tipo especial de imagem com base no qual as imagens filho dos contêineres do aplicativo são criadas. As imagens do construtor incluem tudo, exceto o código-fonte escrito pelos desenvolvedores, como bibliotecas de SO, tempos de execução de idiomas, middleware e ferramentas de
origem para imagem .
Na inicialização, a imagem do construtor exibe o código-fonte do aplicativo gravado pelos desenvolvedores e cria uma imagem filho do contêiner do aplicativo que está pronto para ser lançado, que pode ser executado em um ambiente de desenvolvimento ou produção.
Digamos que os desenvolvedores tenham escrito o código PHP para o aplicativo e desejem executá-lo no contêiner. Para fazer isso, eles simplesmente pegam a imagem de construtor do PHP e passam a URL no site do GitHub, onde seu código é armazenado. Como resultado, os desenvolvedores preparam uma imagem de contêiner de aplicativo pronta para lançamento que contém o Red Hat Enterprise Linux, PHP da Software Collections e, é claro, o código PHP de origem para o aplicativo.
As imagens do construtor são uma maneira poderosa, fácil e rápida de transformar o código-fonte em um contêiner criado com base em componentes confiáveis.
Componentes em contêiner
Um contêiner destina-se principalmente a ser implantado como um componente de um sistema de software maior, e não como uma unidade independente. E há duas razões principais para isso.
Em primeiro lugar, a arquitetura de microsserviço aumenta a liberdade de escolha de componentes e também leva a um aumento no número de componentes dos quais os aplicativos e sistemas de software são compostos. Componentes em contêineres ajudam a implantar esses sistemas de maneira mais rápida e fácil. Por exemplo, imagens de contêiner facilitam a solução do problema da coexistência de versões diferentes do mesmo componente. E ferramentas de definição de aplicativo, como
implantações yaml / json no Kubernetes / OpenShift,
broker de serviço aberto ,
OpenShift Templates e
Helm Charts, fornecem a criação de descrições de aplicativos de alto nível.
Em segundo lugar, longe de sempre todas as partes de um sistema de software podem ser facilmente contêineres. Portanto, faz sentido executar a conteinerização apenas para componentes individuais mais adequados para isso ou mais promissores em termos de resultados. Em aplicativos multisserviço, uma parte dos serviços pode ser implantada como contêineres e a outra usando métodos tradicionais, como RPM ou scripts de instalação, consulte contêineres de animais de estimação. Além disso, alguns componentes podem ser difíceis de contêineres, porque são mal divididos em componentes, ou estão vinculados a algum hardware especial, ou usam chamadas de API de kernel de baixo nível etc. Portanto, em um grande sistema de software, provavelmente haverá peças que podem ser conteinerizadas e peças que não podem ser contêineres. Componentes em container são o que pode ser em container e já em container. Os componentes em contêineres são projetados para serem executados como parte de um aplicativo específico, e não sozinhos. É importante entender que eles não se destinam à operação autônoma, pois são úteis apenas como parte de um sistema de software maior e, isoladamente, são praticamente inúteis.
Por exemplo, no OpenShift Enterprise 3.0, a maior parte do código principal foi implantada usando o RPM, mas após a instalação, os administradores implantaram o roteador e o registro como contêineres. O OpenShift 3.1 introduziu a opção de implantação em contêiner para master, node, openvswitch e etcd e, uma vez instalados, os administradores também podem implantar elasticsearch, fluentd e kibana como contêineres.
Embora o instalador do OpenShift ainda esteja fazendo alterações no sistema de arquivos do servidor, todos os principais componentes de software agora podem ser instalados usando imagens de contêiner. Portanto, esses componentes em contêiner, por exemplo, uma instância da imagem etcd incorporada no OpenShift, nunca devem - e não serão - usados para armazenar o código-fonte do aplicativo com o qual seus clientes estão trabalhando, simplesmente porque esses componentes em contêiner devem ser executados como parte Plataforma de contêiner OpenShift.
Nas novas versões do OpenShift, a tendência para a conteinerização de componentes está se intensificando e outros desenvolvedores de software estão usando cada vez mais essa abordagem.
Imagens do implantador
A imagem do implementador é um tipo especial de contêiner que, quando iniciado, implanta ou gerencia outros contêineres. O Implantador permite implementar esquemas de implantação complexos, por exemplo, iniciando contêineres em uma determinada ordem ou executando algumas ações no primeiro início, como gerar um esquema de dados ou preencher inicialmente o banco de dados.
Por exemplo, no OpenShift, o modelo "tipo de imagem / contêiner" é usado para implantar logs e métricas. A implantação desses componentes usando imagens do implementador permite que os engenheiros do OpenShift controlem a ordem em que os vários componentes são executados e verifique se eles funcionam corretamente.
Imagens intermediárias
Uma imagem intermediária é qualquer imagem de um contêiner que depende de uma imagem base. Assemblies de kernel, middleware e tempos de execução de idioma geralmente são implementados como camadas adicionais na parte superior da imagem base e, em seguida, especificados na diretiva FROM com esta imagem base. As imagens intermediárias geralmente não são usadas por si próprias, mas como blocos de construção na criação de uma imagem autônoma.
Diferentes camadas da imagem, como regra, estão envolvidas em diferentes grupos de especialistas. Por exemplo, os administradores de sistema são responsáveis pela camada de montagem do kernel e os desenvolvedores pela camada de middleware. Ao mesmo tempo, as camadas subjacentes preparadas por uma equipe atuam como uma imagem intermediária para os responsáveis por camadas de nível superior. Embora algumas vezes essas imagens intermediárias possam ser usadas de forma autônoma, principalmente no teste.
Imagens multiuso (intermodais)
Imagens de contêiner multiuso são imagens com uma arquitetura híbrida. Por exemplo, muitas das imagens no Red Hat Software Collections podem ser usadas de duas maneiras. Primeiramente, como contêineres de aplicativos regulares com o servidor Ruby on Rails e Apache completo. Em segundo lugar, você pode usá-los como imagens do construtor para o OpenShift Container Platform e criar imagens filho baseadas nelas, contendo Ruby on Rails, Apache e o código do aplicativo que você passou para o processo de
origem para imagem ao criar uma imagem filho.
Observe que as imagens multiuso estão ganhando popularidade porque permitem que você resolva duas tarefas fundamentalmente diferentes usando a mesma imagem.
Contêineres do sistema
Ao implantar o software do sistema na forma de contêineres, os últimos geralmente exigem privilégios de superusuário. Para simplificar essa opção de implantação e garantir que esses contêineres sejam iniciados antes do tempo de execução do contêiner e do sistema de orquestração, a Red Hat desenvolveu um modelo especial chamado
contêineres do sistema . Esses contêineres são iniciados durante o processo de inicialização do sistema operacional usando systemd e o comando atômico, o que os torna independentes de qualquer sistema de orquestração de tempo de execução ou contêiner. Hoje, a Red Hat oferece contêineres de sistema para rsyslog, cockpit, etcd e flanneld e expandirá essa lista no futuro.
Os contêineres do sistema simplificam bastante a adição seletiva desses serviços ao Red Hat Enterprise Linux e Atomic Host.
Conclusão
Os contêineres parecem ser algo bastante simples para o consumidor final, mas muitas questões surgem ao criar um ambiente de produção de contêineres. Para discutir proveitosamente a arquitetura e os métodos de construção de tais ambientes, é necessária uma terminologia uniforme para todos os participantes. Quanto mais você se aprofunda no design e na construção de tais ambientes, mais armadilhas surgem. Por fim, lembramos apenas alguns deles.
As pessoas geralmente não vêem a diferença entre os termos "imagem do contêiner" e "repositório", especialmente quando são usados nos comandos do docker. Mas se você pode usar os comandos sem entender as diferenças, ao trabalhar na arquitetura dos ambientes de contêiner, você deve entender claramente que o repositório é realmente a principal estrutura de dados.
Também é muito fácil entender mal a diferença entre namespaces, repositórios, camadas de imagem e tags. Cada uma dessas coisas tem seu objetivo na arquitetura de contêiner. E embora fornecedores e usuários os usem para uma variedade de propósitos, eles são apenas ferramentas.
O objetivo deste artigo é ajudá-lo a entender a terminologia para que você possa criar arquiteturas mais avançadas. Por exemplo, imagine que você acabou de ser contratado para desenvolver uma infraestrutura que delimite a disponibilidade de namespaces, repositórios e, além disso, tags e camadas, dependendo das funções e regras de negócios. E a última - lembre-se de que a maneira como o contêiner é montado determina em grande parte como é iniciado (orquestração, privilégios etc.).