Visão geral executiva da utilização de containers

Visão geral executiva da utilização de containers

"Tradução de artigo da Canonical"

A tecnologia de contêineres trouxe uma mudança na tecnologia de virtualização. As organizações que implementam contêineres veem consideráveis oportunidades para melhorar a agilidade, eficiência, velocidade e capacidade de gerenciamento seus ambientes de TI. Contêineres prometem melhorar a eficiência e desempenho do datacenter sem ter que fazer investimentos adicionais em hardware ou infraestrutura.

Este post explica os antecedentes e a linha do tempo do desenvolvimento de contêineres e a tecnologia mais recente que levou à proliferação de contêineres na plataforma Linux. Explica as diferenças, vantagens e desvantagens de contêiners de processo e contêiners de máquinas. Ele examina as duas principais ferramentas de software (Docker e LXD) usadas para manipular recipientes.

Os hipervisors tradicionais fornecem a forma mais comum de virtualização, e máquinas virtuais executadas em tais hipervisors são comuns em quase todo datacenter.

Os conteiners oferecem uma nova forma de virtualização, fornecendo níveis quase equivalentes de isolamento de recursos de um hypervisor tradicional. No entanto, os conteiners tem baixo overhead, menor consumo de memória e maior eficiência. Isto significa que uma densidade mais alta pode ser alcançada – você pode obter mais com o mesmo hardware.

Os conteiners vêm em duas variedades: conteiners de processo e conteiners para máquinas. Os conteiners das máquinas agem muito como máquinas físicas ou virtuais leves, tem sua própria imagem completa do sistema operacional, mas compartilham o mesmo kernel que a máquina host; eles compartilham ferramentas e fluxos de trabalho familiares e são simples de adotar. Os conteiners de processo ainda são mais leves, contendo apenas os binários ou processos para o aplicativo específico que eles executam. Como tal, eles exigem mudanças no fluxo de trabalho, que pode acarretar custos associados. No entanto, essas mesmas mudanças no fluxo de trabalho oferecem outras vantagens, como a capacidade de mudar facilmente para infraestrutura imutável, que por si só traz benefícios em implantações grandes, gerenciáveis ​​e escaláveis.

Grandes implantações de conteiners trazem desafios associados ao gerenciamento de rede e descoberta de serviços. Se cada contêiner carregar seu próprio endereço IP (que é a rota simples para evitar problemas de descoberta de serviço), o gerenciamento de endereços IP e o gerenciamento sobreposição de endereços se tornam questões significativas quando em larga escala. Tecnologias como fan network, popularizadas pela Canonical, podem aliviar significativamente esses problemas.

A atração pelos contêineres não é apenas eficiência estática. Conteiners também são mais rápidos para subir e derrubar. Isso facilita uma arquitetura mais escalável onde os aplicativos são divididos em microsserviços, onde cada um desses serviços pode ser desenvolvido, implantado e dimensionado independentemente. Essa arquitetura proporciona maior agilidade e capacidade de resposta dos negócios, além de menor custo total de propriedade e maior resiliência; no entanto, requer um software de orquestração de contêiner para tirar o máximo proveito.

Assim, os conteiners apresentam uma nova oportunidade para o CTO reduzir custos, aumentar a agilidade e mudar para uma arquitetura mais escalável e resiliente. No entanto, os CTOs também devem reconhecer que alguns casos de uso são mais adequados para containers do que outros, que aproveitar esta oportunidade requer um reconhecimento custos de transição e, em alguns casos, essa mudança na infraestrutura também traz alguns desafios. Esses conceitos são explicados mais detalhadamente no corpo deste white paper.

O background dos conteiners

O CONTEXTO HISTÓRICO

A virtualização chegou pela primeira vez no sistema operacional Linux na forma de hipervisors como Xen e KVM (máquinas virtuais de kernel) – referidos neste artigo como “hipervisors tradicionais”. Cada segmento da máquina host é conhecido como uma ‘máquina virtual’, executando seu próprio kernel do sistema operacional.

Aqueles que executam aplicativos particularmente sensíveis ao custo (o primeiro exemplo, hospedagem de consumidor) espremem o máximo possível de um determinado hardware.

No entanto, altas densidades eram difíceis alcançar com as formas existentes de virtualização, especialmente quando o aplicativo era pequeno em comparação com o kernel, pois a maior parte da memória do sistema era ocupada com várias cópias do kernel – geralmente o mesmo kernel. Para aplicações de alta densidade, as máquinas foram divididas usando tecnologia cruder (por exemplo, “chroot jails”), apesar de isso fornecer isolamento imperfeito da carga de trabalho e ter implicações de segurança. Em 2001, a virtualização do sistema operacional (na forma de Linux vServer) foi introduzida com uma série de patches do kernel.

Essa foi uma forma antiga de virtualização de contêiner. Em vez de executar uma cópia do kernel por inquilino, o próprio kernel reconheceu agrupamentos separados de processos pertencentes a inquilinos diferentes, cada um compartilhando o mesmo kernel, mas cada um sendo isolado um do outro. Além disso, emprestando idéias do FreeBSD jails e de zonas do Solaris, formaram a base dos Process Containers do Google, que acabou se tornando cgroups e namespaces do Linux, a base dos containers no Linux moderno, com o user-space ‘LXC’ sendo introduzido pela IBM e Canonical para gerenciá-los.

RECIPIENTES E APLICAÇÕES HOJE

Como os conteiners não contêm seu próprio kernel, eles geralmente são rápidos para implantar e remover. Eles podem assumir duas formas: conteiners de processos (um conteiner contendo apenas um único aplicativo) ou conteiners de máquinas (um conteiner com sistema operacional do espaço do usuário, mas compartilhando o kernel de um host). Atualmente o termo “conteiner” não se refere apenas ao mecanismo de isolamento de tempo de execução, mas também a imagem implantada com ele; essas duas formas de conteiner diferem no tipo de imagem implantada.

Enquanto isso, os próprios aplicativos mudaram. Em vez de processos monolíticos, eles agora são compostos de múltiplos componentes. Cada componente pode ter muitas instâncias em execução ao mesmo tempo para escalar e cada componente precisa se comunicar com outros componentes. Esta divisão da aplicação em muitos elementos componentes é frequentemente referida como “Microsserviços”.

A necessidade de implantação rápida, tanto para dimensionar quanto para permitir agilidade e rapidez nas atualizações de componentes individuais, de acordo com a tendência de ‘DevOps’ e metodologias de desenvolvimento ágil. Ambos favorecem o uso de conteiners, pois cada aplicativo é pequeno comparado ao sistema operacional (o que constituiria uma sobrecarga significativa na virtualização tradicional baseada em hipervisor) e as atualizações podem ser executadas sem a sobrecarga de uma inicialização do sistema operacional.

Essas tendências também trouxeram uma necessidade crescente de rastrear, criar e destruir o número crescente de contêineres e ferramentas de gerenciamento que atendem a essa necessidade. O Docker gerencia conteiners de processo em um único host e fornece o padrão de fato para empacotar arquivos dentro de um imagem do contêiner. Da mesma forma, o LXD fornece um meio de executar conteiners de máquinas em um único host. Tecnologias como Docker Swarm e Kubernetes permitem o gerenciamento de contêineres em vários hosts. Essas tecnologias representam o status atual da tecnologia de conteiners.

O QUE É EXATAMENTE UM CONTAINER?

Os conteiners são uma tecnologia que permite ao usuário dividir uma máquina para que ele possa executar mais de um aplicativo (no caso de conteiners de processo) ou instância do sistema operacional (no caso de conteiners da máquina) no mesmo kernel e hardware e, ao fazê-lo, mantenha o isolamento entre essas cargas de trabalho.

Antes que os conteiners chegassem ao horário nobre, duas outras técnicas foram usadas: multitarefa e virtualização tradicional baseada em hipervisor.

A multitarefa permite que vários aplicativos sejam executados no mesmo sistema operacional, kernel e hardware; no entanto, fornece pouco isolamento entre aplicações diferentes. Por exemplo, um aplicativo descontrolado pode esgotar memória, capacidade de E/S ou espaço em disco. Um aplicativo mal-intencionado ou com bugs pode fornecer acesso ao sistema operacional e, portanto, aos dados de cada aplicativo.

A virtualização tradicional baseada em hipervisor permite que os kernels convidados executem no topo (ou ao lado) de um kernel host. Cada um desses kernels hóspedes possui sua própria instância do sistema operacional. Esses hipervisors tradicionais oferecem ótimo isolamento, bem como a capacidade de executar uma ampla gama de sistemas operacionais e kernels simultaneamente no mesmo hardware. No entanto, eles vêm com uma série de desvantagens:

• Cada kernel e sistema operacional demora um pouco para inicializar.

• Cada kernel ocupa seu próprio espaço de memória permanente e causa uma sobrecarga na CPU, portanto, a sobrecarga da virtualização é bastante grande.

• E/S é menos eficiente. Para que o aplicativo convidado execute E/S, ele precisa primeiro chamar o kernel convidado, que faz uma solicitação para o que ele acredita ser o hardware. Por sua vez, emulado pelo hypervisor e passado para o host sistema operacional e, finalmente, ao hardware. A resposta é então passada pela mesma rota tortuosa; embora tenham sido introduzidos drivers paravirtualizados para remover a sobrecarga da emulação, dois núcleos ainda estão envolvidos e, portanto, ainda há degradação do desempenho, tanto em termos de sobrecarga quanto de latência.

• Alocação de recursos não são refinados. Como um exemplo simples, cada máquina virtual possui um tamanho de memória especificado na criação; portanto, a memória deixada inativa por uma máquina virtual não está geralmente disponível para outra. Tecnologias como ‘ballooning’ podem aliviar o problema, a alocação de recursos é necessariamente menos eficiente.

• A carga de manutenção para manter atualizado um kernel por máquina virtual (conforme necessário na virtualização tradicional baseada em hipervisor) é significativamente maior que um kernel por host (como é o caso da virtualização baseada em contêiner) e o tempo de inatividade resultante com a tradicional virtualização baseada em hipervisor também é correspondentemente maior.

Os conteiners, de certa forma, fornecem o melhor dos dois mundos. Um único kernel lida com instâncias logicamente separadas de aplicativos (conteiners de processo) ou sistemas operacionais (conteiners de máquina). Portanto, a E/S passa diretamente do aplicativo para o kernel host e para o hardware, e, portanto, o desempenho é o mesmo dos aplicativos nativos, e a latência é minimizada.

Os conteiners fornecem um isolamento quase tão bom quanto um hipervisor tradicional; de fato, o isolamento é mais flexível, pois os conteiners podem (por exemplo) compartilhar alguns recursos, mas não outros. A inicialização é mais rápida, pois não é necessário iniciar o kernel e (no caso de conteiners de processo), não é necessário iniciar o sistema operacional – na verdade, até os conteiners das máquinas tendem a transportar sistemas operacionais leves com tempos de inicialização em segundos. E a alocação de recursos por meio de cgroups é refinada, sendo manipulada pelo kernel host, permitindo métricas efetivas de qualidade de serviço por container (QoS) e eficiência adicional impulsionada por mais flexibilidade no agendamento de tarefas. Por exemplo, no sistema de orquestração de conteiners Borg do Google, os trabalhos em lote com uso intensivo de computação e demorados geralmente são executados em conteiners ao lado de aplicativos voltados para o usuário mais sensíveis à latência.

Normalmente, estes últimos reservam mais recursos do que precisam em uma base contínua para satisfazer os requisitos de latência no caso de picos na carga ou diminuição da disponibilidade de alguns membros do cluster. Os trabalhos em lote podem fazer uso dessa capacidade não utilizada, sujeita à preempção pelos aplicativos voltados para o usuário. O cgroups também fornece uma medição precisa do consumo desses recursos, permitindo o desenvolvimento de ferramentas como o cAdvisor do Google e o dimensionamento automático inteligente.

No entanto, existem desvantagens dos conteiners em comparação com a virtualização tradicional baseada em hipervisor, que inclui:

• Os convidados são limitados aos que podem usar o mesmo kernel: você não pode executar diretamente um sistema operacional Windows em um contêiner Linux.

• Existe um isolamento adicional indiscutível fornecido por um hipervisor tradicional que não está disponível para conteiners, o que significa que o problema ‘vizinho barulhento’ é potencialmente mais significativo em conteiners do que em um hipervisor tradicional. No entanto, deve-se notar que essa diferença foi minimizada nos últimos anos pelos avanços no suporte do kernel para conteiners. Por exemplo, existem recursos como cache de processador de nível 3 e largura de banda de memória que nenhuma tecnologia de virtualização pode arbitrar. Pode-se argumentar um isolamento adicional fornecido por um hipervisor tradicional para tornar a virtualização tradicional baseada em hipervisor mais segura que os conteiners, embora isso seja essencialmente uma questão de saber se as defesas do hipervisor tradicional são melhores do que as defesas do kernel. Quarto, há desvantagens de executar um único núcleo – um argumento de ‘todos os ovos em uma cesta’. Se esse kernel travar ou for explorado, talvez devido a uma vulnerabilidade dentro de um aplicativo que é insegura, toda a máquina estará comprometida; A atualização do kernel é, portanto, sem dúvida mais problemática (quanto mais depende dele) do que a atualização dos kernels em um ambiente tradicional baseado em hipervisor.

• Técnicas como a migração ao vivo de conteiners estão em sua infância em comparação com o equivalente nos hipervisores tradicionais.

Vale ressaltar que as técnicas de virtualização podem ser aninhadas. Por exemplo, os hipervisors tradicionais podem ser executados dentro de hipervisors ou conteiners, e os conteiners podem ser executados dentro de hipervisores ou conteiners tradicionais. Isso, às custas de alguma complexidade, fornece maior flexibilidade no isolamento de recursos e no desempenho.

CONTAINERS DE PROCESSOS VS. DE MÁQUINA

Distinguimos brevemente acima entre conteiners de processo e conteiners de máquinas, dizendo que um contêiner de processo contém apenas um único aplicativo, mas um contêiner de máquina contém um ou mais aplicativos e seu próprio sistema operacional. Nos dois casos, eles compartilham um kernel com o host. Para aprofundar um pouco mais nas diferenças, precisamos entender um pouco mais sobre como os aplicativos funcionam em um ambiente Linux e o que exatamente queremos dizer com ‘Sistema Operacional’.

Em um ambiente de contêiner de processo, como o Docker, os contêineres são projetados para que sejam muito pequenos. Eles contêm apenas os binários para um único aplicativo. Geralmente, eles são vinculados estaticamente ou contêm um subconjunto mínimo de bibliotecas necessárias apenas para esse aplicativo. Por exemplo, eles não precisam conter um shell ou um processo tradicional de ‘init’. O espaço em disco necessário para um contêiner de processo pode ser muito pequeno (talvez apenas alguns megabytes). Tecnologias como o Docker costumam ‘compor’ esses contêineres (sobrepor uma imagem à outra) para que um aplicativo possa ser construído com base em um modelo. O armazenamento de leitura e gravação é normalmente separado da imagem. Como resultado, eles tendem a ser ideais para criar pequenos serviços imutáveis. Obviamente, uma implantação no mundo real pode conter dezenas ou centenas desses serviços.

Um ambiente de contêiner de máquina, como o fornecido pelo LXD, parece muito mais semelhante a uma máquina virtual. O contêiner parecerá ter sua própria imagem de disco, geralmente contendo uma versão reduzida de um sistema operacional. Ele terá seu próprio processo de inicialização e poderá executar um número limitado de daemons. Normalmente também contém um shell. Os programas são instalados da maneira que o sistema operacional convidado normalmente esperaria (por exemplo, usando o ‘apt-get’ em um sistema Ubuntu). Portanto, o LXD funciona de maneira semelhante a um hypervisor tradicional. Os contêineres são normalmente com estado, ou seja, fornecem configuração mutável, embora as tecnologias de cópia na gravação permitam que eles sejam redefinidos facilmente para sua configuração inicial. Algumas fontes se referem aos contêineres de máquina como ‘contêineres do sistema’.

Podemos ver, acima, que usamos “sistema operacional” para significar os programas no espaço do usuário que cercam o kernel que não fazem parte do próprio aplicativo. O fato de cada contêiner de máquina possuir seu próprio ‘sistema operacional’ não significa que cada um deles tenha uma cópia completa do Linux ou seu próprio kernel. Em vez disso, eles executam alguns daemons leves e têm vários arquivos necessários para fornecer um ‘SO dentro de um SO’.

Existe uma terceira maneira de implantação de contêineres. Isso é para utilizar a capacidade de contêineres e executar contêineres de processo em contêineres de máquinas – por exemplo, para executar contêineres Docker em contêineres LXD. Como os contêineres são muito leves, esse ambiente de contêiner misto é uma proposta eminentemente prática e oferece uma excelente maneira de gerenciar hosts Docker.

Containers no Linux

A terminologia que envolve os containers no Linux pode ser confusa, em parte porque os nomes de vários componentes foram alterados, alguns projetos se transformaram em outros projetos e, ocasionalmente, o mesmo nome foi usado para mais de um componente. Esta seção define o estado atual do jogo.

No final da pilha está o kernel do Linux. Talvez surpreendentemente, o próprio kernel do Linux não tenha um conceito de ‘contêineres’ em si; a funcionalidade dos contêineres é fornecida por três conceitos de kernel: cgroups (grupos de controle), namespaces do Linux e a infraestrutura de segurança do kernel.

Os grupos de controle limitam e respondem por diferentes tipos de uso de recursos (CPU, memória, E/S de disco, rede I/O e assim por diante) em uma coleção de diferentes processos; eles também fornecem priorização do uso de recursos e controle de ponto de verificação.

Os namespaces do Linux fornecem maneiras de segregar vários tipos de recursos do Linux em diferentes grupos, por exemplo, os namespaces de rede permitem que diferentes grupos de processos tenham visões completamente independentes da pilha de redes do Linux. Os outros tipos de recursos que podem ser segregados incluem o espaço de ID do processo, os filesystems montados, os atributos do filesystem, o espaço IPC e o espaço de semáforo do System V. Se todos os espaços forem segregados, os processos segregados não terão atributos do sistema operacional em comum com aqueles que os ativaram.

Portanto, um contêiner em termos de kernel é uma árvore de processos segregada da árvore de processos que o iniciou e, normalmente, essa segregação se aplica a todos os recursos.

Mas, a segregação não é suficiente para isolamento. Para isolar completamente um contêiner, ele não apenas deve não ser “visualizado” em outros contêineres, mas também deve ter seu uso de recursos controlado. Por exemplo, não deve ser possível consumir memória ou largura de banda de E/S que outros contêineres possam precisar. Para conseguir isso, o kernel do Linux usa cgroups para proteger um contêiner da inanição ou contenção de recursos causada por outro contêiner (se originado de um processo descontrolado ou de um ataque de negação de serviço) e, portanto, fornece garantias de QoS.

Por fim o kernel fornece um nível de segurança para contêineres via Apparmor, SELinux, recursos de kernel e seccomp. Isso evita, entre outras coisas, um processo em execução como raiz em um contêiner com acesso total ao sistema (por exemplo, ao hardware) e ajuda a garantir que os processos não possam escapar do contêiner no qual são executados.

Assim, os contêineres oferecem duas formas complementares de controle de acesso. Em primeiro lugar, o DAC (controle de acesso discricionário) medeia o acesso a recursos com base nas políticas aplicadas pelo usuário, para que os contêineres individuais não possam interferir entre si e possam ser executados com segurança por usuários não raiz. Em segundo lugar, o controle de acesso obrigatório (MAC) garante que nem o próprio código do contêiner nem o código executado dentro dos contêineres tenham um maior grau de acesso do que o próprio processo exige, de modo que os privilégios concedidos ao processo não autorizado ou comprometido sejam minimizados.

O conjunto de ferramentas de espaço do usuário para manipulação de contêineres, o mais popular deles é o LXC. Isso por si só é dividido em várias partes: uma biblioteca chamada liblxc, que realiza todo o trabalho pesado, ligações de idiomas para essa biblioteca, um conjunto de ferramentas de linha de comando para manipular contêineres em um nível baixo e um conjunto de modelos de contêineres padrão.

É possível usar contêineres LXC diretamente, mas é improvável que eles tenham muita aplicação prática, pois a interface é de nível muito baixo. Portanto, a maioria dos usuários os abstrai ainda mais, usando programas como o Docker para criar contêineres de processo ou o LXD para construir contêineres de máquinas.

Docker e contêineres de processos

Docker é um projeto de código aberto que permite ao usuário automatizar a implantação de aplicativos dentro de contêineres de processo. Ele permite que um pequeno subconjunto de um filesystem (apenas os arquivos necessários para a execução de um aplicativo) seja incorporado em um modelo e, em seguida, permite que ele seja implantado, repetidamente, em um contêiner leve. Como tal, o aplicativo é empacotado para ser separado do sistema operacional no qual é executado. Usando apenas bibliotecas estáticas (ou bibliotecas incorporadas na imagem do contêiner), um contêiner construído em uma versão do Ubuntu pode ser executado em um host executando outra; um contêiner criado no RHEL (por exemplo) pode até ser executado no Ubuntu.

O docker segue o princípio da infraestrutura imutável. Quando iniciado, cada contêiner se parece exatamente com o modelo, portanto, se um contêiner for reiniciado, todas as alterações feitas anteriormente serão perdidas. Isso garante que um determinado contêiner seja lançado sempre da mesma forma e evita desvios de configuração, onde as atualizações em um modelo e em uma máquina em execução ficam fora de sincronia. A maneira recomendada de atualizar um contêiner é simplesmente destruí-lo e reiniciá-lo com uma nova imagem. Obviamente, é necessário armazenar estado em algum lugar – por exemplo, um banco de dados precisa armazenar seus dados em algum lugar. O Docker fornece ‘volumes’ para esse fim. Volumes são contêineres externos que possuem dados e nenhum código, que são vinculados ao modelo no tempo de execução para criar o aplicativo em contêiner em execução. Essa mudança para infraestrutura e configuração imutáveis ​​pode representar uma mudança significativa de práticas de trabalho (e, portanto, um obstáculo à adoção), mas, em última análise, é uma arma poderosa na simplificação do gerenciamento de grandes propriedades de contêineres, principalmente quando combinada com a orquestração de contêineres.

O Docker usa um arquivo de configuração de texto sem formatação (chamado Dockerfile) para descrever o que entra em um contêiner e permite a composição de modelos existentes e novos arquivos para produzir novos modelos. Dessa maneira, os modelos existentes podem ser construídos e modificados. Subjacente a isso (e à imutabilidade descrita acima) está o uso de Docker de copy-on-write filesystems. As versões tiradas de várias distribuições (incluindo Ubuntu, Centos e CoreOS) são fornecidas como modelos base, mas não precisam necessariamente ser usadas. Os modelos criados, na forma de imagens, podem ser carregados e compartilhados e, portanto, podem ser baixados de um repositório de imagens público ou privado.

O Docker tem uma maneira incomum de lidar com redes. Cada contêiner não é uma imagem completa do sistema operacional independente e, portanto, não tem necessariamente seu próprio endereço IP. Em vez disso, ele executa um ou mais processos, cada um dos quais normalmente estará escutando em uma porta. O Dockerfile pode, portanto, descrever quais dessas portas precisam ser ‘expostas’, o que, na prática, significa conversão de portas para uma porta no host. Para administradores de sistema, essa alteração na técnica pode exigir aclimatação significativa. As versões mais recentes do Docker permitem que os contêineres tenham seus próprios endereços IP e tenham interfaces de rede mapeadas para pontes ou redes de sobreposição.

O Docker anteriormente usava o LXC para construir seus contêineres, mas agora, por padrão, usa libcontainer, que fornece funcionalidade semelhante.

Docker tem um significativo ecosistema de outras ferramentas nas quais está integrado. Por exemplo, ele forma a base do gerenciamento de contêineres no Kubernetes e é integrado ao Cloud Foundry PaaS. Ele também possui integrações com ferramentas de gerenciamento de configuração convencionais, como Ansible, CFEngine, Chef, Puppet e Salt, e com várias plataformas em nuvem, como AWS, GCE, Azure e OpenStack.

Existem alternativas ao Docker, principalmente rkt (pronuncia-se “rocket”), um rival de código aberto do Docker cujo desenvolvimento é liderado pelo CoreOS; fornece funcionalidade amplamente semelhante.

LXD e conteiners de máquinas

O LXD é uma ferramenta de código aberto que fornece um meio de gerenciar recipientes para máquinas. Eles agem muito mais como máquinas virtuais em um hipervisor tradicional do que os contêineres de processo gerenciados pelo Docker, o que levou a Canonical a descrever o LXD como um “hipervisor de contêiner puro”.

O LXD é composto de três componentes. Em primeiro lugar, um daemon em todo o sistema (ele próprio chamado ‘lxd’) realiza todo o trabalho pesado. Ele fornece uma API REST para uso local, que também pode ser exportada pela rede, se desejado. Este daemon se comunica com o liblxc para criar os próprios contêineres. Em segundo lugar, uma ferramenta de linha de comando (chamada ‘lxc’, mas usada para manipular contêineres LXD e não contêineres LXC) se comunica com o daemon, no mesmo host ou na rede, por meio da API REST. Em terceiro lugar, um plug-in para o OpenStack (Nova LXD) permite que o OpenStack use o LXD como um hypervisor, para que o OpenStack possa criar instâncias no LXD da mesma maneira que normalmente criaria máquinas virtuais em execução em um hypervisor tradicional como o KVM.

A segurança tem sido um princípio fundamental do LXD desde o estágio de design. Ele cria contêineres sem privilégios por padrão (o que significa que usuários não raiz podem iniciar contêineres). As restrições de recursos para contêineres foram incorporadas desde o início, e não como uma reflexão tardia. Dessa forma, fornece uma maneira simples de criar contêineres de máquinas com excelente isolamento do resto do sistema.

Ao fornecer operação pela rede e localmente, os contêineres podem ser criados em sistemas remotos através do mesmo prompt de linha de comando usado para criar contêineres no laptop do desenvolvedor. Isso permite uma escalabilidade e gerenciamento simples de contêineres em vários hosts.

O LXD foi projetado para ser um sistema intuitivo, com uma API e uma linha de comando limpas. Portanto, é fácil seguir em frente e é familiar para aqueles que vieram de um ambiente de máquina virtual.

Os contêineres LXD são baseados em imagens, o que significa que cada contêiner possui um sistema de arquivamento completo, em vez de uma composição de modelos, como nos contêineres de processo. Isso significa que fontes de imagem confiáveis ​​existentes podem ser usadas e é possível compartilhar os repositórios de imagens usados ​​em máquinas virtuais tradicionais baseadas em hipervisor. Isso facilita a migração entre ambientes baseados em hipervisor.

O LXD também fornece suporte para migração ao vivo, para que, se um nó host precisar de manutenção, o contêiner possa ser migrado para outro local para garantir a continuidade do serviço. Novamente, dessa maneira, é semelhante às máquinas virtuais tradicionais baseadas em hipervisor. Também estão disponíveis vários outros recursos familiares aos usuários tradicionais do hipervisor, como snapshots e passagem de dispositivo.

Como os contêineres LXD são contêineres totalmente isolados, eles têm uma rede que parece muito semelhante à rede baseada em máquina virtual. Cada contêiner possui seu próprio endereço IP (ou endereços IP), e o dispositivo Ethernet virtual do contêiner pode aparecer em uma ponte no host. Isso torna a rede não diferente das máquinas virtuais em um hipervisor tradicional e evita a complexidade do mapeamento e exposição de portas.

No entanto, isso significa que o gerenciamento de endereços IP se torna mais complexo e que é necessário proteger (via filtros de pacotes ou de outra forma) os contêineres da máquina da mesma maneira que seria necessário para proteger as máquinas virtuais.

Como descrito acima, é possível aninhar contêineres em contêineres de máquinas, para que você possa executar o Docker em um contêiner LXD ou mesmo contêineres LXD em um contêiner LXD.

Conteiners e a necessidade de software de orquestração

A necessidade de agilidade nos negócios levou à pressão comercial pela implantação mais frequente de software. Para dar suporte a isso, novas técnicas de desenvolvimento de software (classificadas como ‘ágeis’) e novas culturas operacionais (como ‘DevOps’) se firmaram, permitindo maior frequência de alterações na implantação.

Cada vez mais, os aplicativos tendem a ser criados a partir de componentes existentes, reutilizando a tecnologia interna ou (mais comumente) utilizando elementos de código aberto. Em vez de um aplicativo monolítico, um aplicativo moderno consiste em vários componentes, muitos deles sendo elementos de código aberto executando uma configuração de barra inalterada (por exemplo, bancos de dados, servidores da web, filas de mensagens etc.), com um número menor sendo gravado internamente (por elementos da instância da lógica de negócios). A conclusão lógica disso é que a tendência é uma situação em que o aplicativo é composto inteiramente de microsserviços, pequenos serviços implantáveis ​​de forma independente que se comunicam localmente em uma rede.

Os contêineres fornecem um veículo ideal para esses componentes devido à sua baixa sobrecarga e velocidade de implantação. Eles também permitem dimensionamento horizontal eficiente com a implantação de vários contêineres idênticos do componente relevante, cada um compartilhando a mesma imagem. Aplicativos modernos, portanto, podem ser construídos a partir de centenas ou até milhares de contêineres, potencialmente com interdependências complexas. Como esses contêineres podem ser implantados de maneira confiável e reproduzível? Se um determinado contêiner deixa de funcionar, como ele pode ser substituído automaticamente? E se um aplicativo precisa ser dimensionado, como o componente correto a ser dimensionado pode ser identificado e ter sua matriz de contêineres expandida? Esses são os problemas abordados pelo software de orquestração de contêineres.

Como a Canonical ajuda

A distribuição Ubuntu Linux da Canonical permite que as organizações tenham acesso direto a toda a significativa tecnologia de contêineres Linux. O Ubuntu traz variedade, velocidade e qualidade: variedade significa uma ampla seleção de tecnologia de contêineres na qual sua organização pode selecionar a opção mais adequada; velocidade, que significa pontualidade de entrega com uma cadência de liberação que garante que as versões mais atualizadas do software de contêiner estejam disponíveis para você através de nossa cadência de liberação previsível; e qualidade, significando um grande foco na usabilidade, compatibilidade e interoperabilidade.

Em conjunto com o Google, a Canonical lançou sua própria distribuição do Kubernetes – A distribuição canônical de Kubernetes (CDK). O CDK fornece uma experiência de ‘K8s puros’, testado em uma ampla variedade de nuvens e integrado com métricas e monitoramento modernos. Além disso, o CDK trabalha em todas as principais nuvens públicas e infraestrutura privada, permitindo que as equipes operem clusters Kubernetes sob demanda, em qualquer lugar. A Canonical está ajudando muitas empresas a tirar o máximo proveito dos contêineres. Desde a criação de aplicativos distribuídos e os microsserviços para ambientes Platform as a Service (PaaS), trabalhos em lote e ETL (extrair, transformar, carregar) no setor de serviços financeiros e melhorar a eficiência do DevOps por meio de integração e implantação contínuas.

Próximas etapas

Os contêineres oferecem uma nova forma de virtualização, com menor sobrecarga do que os hipervisores tradicionais, tanto em termos de menor consumo de memória quanto em maior eficiência. Isso permite que as organizações obtenham maior densidade e executem a mesma carga de computação por menos dinheiro. Os contêineres de máquinas fornecem um meio simples de obter essa vantagem de custo para cargas de trabalho Linux em Linux sem reprojetar o aplicativo, enquanto os contêineres de processo oferecem oportunidades adicionais para aumentar a agilidade e mudar para uma arquitetura mais escalável e resiliente.

Para descobrir como a Canonical pode ajudá-lo a tirar vantagem dos contêineres, convidamos você a testar a distribuição canônica de contêineres Kubernetes e LXD usando o Conjure-up. Essa distribuição upstream pura do Kubernetes foi projetada para ser facilmente implementável em nuvens públicas, laptops locais, bare metal e desenvolvedores. Durante a instalação, a conjuração perguntará em que nuvem você deseja implantar e solicitará as credenciais apropriadas. Se você estiver implantando em contêineres locais (LXD), consulte estas instruções para considerações específicas do host local.

Para implantações de nível de produção e gerenciamento do ciclo de vida do cluster, é recomendável ler a documentação completa da Distribuição Canonical de Kubernetes.

Página inicial: jujucharms.com/canonical- kubernetes/

Código-fonte: github.com/juju-solutions/bundle-canonical-kubernetes

Se quiser aprender mais sobre como a Canonical pode ajudar a desenvolver e implantar sua estratégia de contêiner, ligue para +1 781 761 9427 (Americas), +44 207 093 5161 (Resto do mundo) ou entre em contato conosco online.