Docker tools: Fer­ra­men­tas Docker

O vasto ecos­sis­tema Docker oferece a de­sen­vol­ve­do­res inúmeras opções de de­ploy­ment de apli­ca­ções, or­ques­tra­ção de con­têi­ne­res, entre outros. Com o nosso guia de Docker tools, você conhecerá as fer­ra­men­tas Docker mais im­por­tan­tes, assim como os projetos de código aberto mais in­te­res­san­tes.

Docker tools oficiais e es­sen­ci­ais

Atu­al­mente, o Docker é muito mais do que uma simples pla­ta­forma de operação de con­têi­ne­res de software. Ao longo do tempo, sua equipe de de­sen­vol­vi­mento foi ex­pan­dindo diversas fer­ra­men­tas Docker (Docker tools) com o objetivo de tornar de­ploy­ments de apli­ca­ções em in­fra­es­tru­tu­ras dis­tri­buí­das e em ambientes de nuvem mais fáceis, rápidas e flexíveis. Além de funções de cluster e or­ques­tra­ção, Docker toos oferecem a seus usuários um mar­ket­place de apli­ca­ti­vos cen­tra­li­zado, assim como uma fer­ra­menta de ge­ren­ci­a­mento de recursos de nuvem.

Docker Engine

Quando uma pessoa usa o termo “Docker”, ela costuma estar se referindo à aplicação cliente-servidor de código aberto na qual a pla­ta­forma de con­têi­ne­res é baseada. Ofi­ci­al­mente, esta leva o nome de Docker Engine e tem como com­po­nen­tes centrais o Docker daemon(API REST) e uma interface de linha de comando (CLI) que funciona como interface do usuário. Ambos permitem que usuários utilizem o Docker Engine por comandos. Assim, tanto imagens Docker quanto arquivos Docker e con­têi­ne­res Docker podem ser ge­ren­ci­a­dos di­re­ta­mente do terminal. Da mesma forma, cliente edaemon podem localizar-se em sistema di­fe­ren­tes.

Conheça os prin­ci­pais comandos Docker ex­plo­rando nosso artigo es­pe­ci­a­li­zado.

Docker Hub

O projeto de código aberto Docker Hub dis­po­ni­bi­liza a seus usuários um registro baseado em nuvem, que pode ser utilizado para baixar imagens Docker, gerenciá-las cen­tral­mente e com­par­ti­lhá-las com outros usuários. Quem tem registro na pla­ta­forma também pode armazenar imagens Docker, tanto pu­bli­ca­mente quanto em re­po­si­tó­rios privados. Mecanismo integrado de tagging permite o controle de versões.

Além de re­po­si­tó­rios públicos de outros usuários, no Docker Hub você pode encontrar recursos de­sen­vol­vi­dos pela própria equipe do Docker, assim como por co­nhe­ci­dos projetos open source. Estes ficam dis­po­ní­veis em arquivos de imagens oficiais. Entre as imagens Docker mais populares estão o servidor web leve NGINX, o banco de dados na memória, o Redis, o kit de fer­ra­men­tas Unix BusyBox e a dis­tri­bui­ção Linux Ubuntu.

Or­ga­ni­za­ções fazem parte dos recursos do Docker Hub. Elas nada mais são que grupos de trabalho privados, que só aceitam de­ter­mi­na­dos usuários. Em uma or­ga­ni­za­ção, au­to­ri­za­ções de acesso são ge­ren­ci­a­das por equipes e as­so­ci­a­ções.

Docker Swarm

O Docker Engine contém funções nativas que permitem que usuários façam o ge­ren­ci­a­mento de Docker hosts em clusters(swarms). Tais funções de ge­ren­ci­a­mento e or­ques­tra­ção declusters, in­te­gra­das ao Docker Engine, baseiam-se no conjunto de fer­ra­men­tas Swarmkit.

A fer­ra­menta de cluster nativa do Docker, Swarm, usa a API REST do Docker e combina grupos de Docker hosts em uma única hos­pe­da­gem virtual, o que permite que qualquer fer­ra­menta Docker conectada ao daemon acesse o Swarm e faça es­ca­lo­na­men­tos em qualquer quan­ti­dade de Docker hosts. Usuários utilizam a interface de linha de comando Docker Engine para criar swarms, fazer de­ploy­ments em apli­ca­ções no cluster e controlar o com­por­ta­mento do Swarm. Or­ques­tra­ção adicional não é requerida pelo software.

Docker Engines mesclados a clusters são exe­cu­ta­dos pelo modo swarm. Ative-o para criar um novo cluster ou para adicionar um Dockerhosta umswarmjá existente. In­di­vi­du­al­mente, Dockerhostsde umclustersão chamados de nós. Nós de umclusterpodem ser exe­cu­ta­dos comohostsvirtuais no mesmo sistema local, mas é mais comum que es­tru­tu­ras baseadas em nuvem sejam uti­li­za­das. Nelas, nós in­di­vi­du­ais de Dockerswarms são dis­tri­buí­dos a di­fe­ren­tes sistemas e in­fra­es­tru­tu­ras.

O Docker Swarm é baseado na ar­qui­te­tura mestre-escravo. Assim, quando serviços têm de ser dis­tri­buí­das aos swarms, usuários devem repassar a res­pon­sa­bi­li­dade a um nó ge­ren­ci­a­dor, que atuará como mestre do cluster. Como mestre, ele se ocupará da pro­gra­ma­ção dos con­têi­ne­res no clustere fun­ci­o­nará como principal interface de usuário para se acessar recursos do Swarm. Um nó ge­ren­ci­a­dor envia unidades de trabalho in­di­vi­du­ais (tarefas) a seus escravos su­bor­di­na­dos, chamados deworker nodes pela ter­mi­no­lo­gia Docker.

• Serviços: Cons­ti­tuem a estrutura central dos clusters Docker. Um serviço é um grupo de con­têi­ne­res baseados na mesma imagem, que define as tarefas a serem exe­cu­ta­das no cluster. Ao criarem serviços, usuários es­pe­ci­fi­cam as imagens a serem uti­li­za­das e os comandos que devem ser aplicados. Serviços também pos­si­bi­li­tam o di­men­si­o­na­mento das apli­ca­ções: usuários Docker podem definir, com fa­ci­li­dade, quantos con­têi­ne­res devem ser iniciados por um serviço.
• Tarefas: Antes de serem dis­tri­buí­dos no cluster, serviços são divididos em unidades de trabalho in­di­vi­du­ais (tarefas) pelo nó ge­ren­ci­a­dor. Cada tarefa inclui um contêiner Docker e os comandos a serem exe­cu­ta­dos.

Além das funções de controlar clusters e de or­ques­trar con­têi­ne­res, nós ge­ren­ci­a­do­res também podem funcionar como meros worker nodes, a não ser que você restrinja as atri­bui­ções do nó mestre, o limitando ao ge­ren­ci­a­mento.

Em cada worker node é executado um programa agente, que aceita tarefas e fornece, ao res­pec­tivo nó mestre, re­la­tó­rios de status atu­a­li­za­dos. O gráfico abaixo ilustra processos no Docker Swarm:

Docker Compose

O Docker Compose pos­si­bi­lita a vin­cu­la­ção de con­têi­ne­res, para que eles possam ser exe­cu­ta­dos por um único comando. Seu elemento fun­da­men­tal é um arquivo de controle central baseado na linguagem de marcação YAML. A sintaxe deste arquivo é se­me­lhante à do software de código aberto Vagrant, usado para criar e pro­vi­si­o­nar máquinas virtuais.

O arquivo docker-compose.yml permite a definição qualquer número de con­têi­ne­res de software, incluindo todas as de­pen­dên­cias e relações. Apli­ca­ções com múltiplos con­têi­ne­res são con­tro­la­das da mesma forma que con­têi­ne­res de software in­di­vi­du­ais. Use o comando docker-compose em com­bi­na­ção com o sub­co­mando desejado para gerenciar o ciclo de vida de cada aplicação.

Essa fer­ra­menta Docker pode ser fa­cil­mente integrada a um cluster baseado em Swarm. A in­te­gra­ção contribui para a execução de múltiplos con­têi­ne­res criados pelo Compose, pois executa-os, com a mesma fa­ci­li­dade, em sistemas dis­tri­buí­dos ou em um Docker host único.

Outro in­te­res­sante recurso do Docker Compose é seu mecanismo de es­ca­lo­na­mento. Com esta fer­ra­menta de or­ques­tra­ção, você pode usar o terminal para de­ter­mi­nar, de forma con­ve­ni­ente, quantos con­têi­ne­res deseja ini­ci­a­li­zar para a execução de um serviço es­pe­cí­fico.

Docker tools de terceiros

Além de fer­ra­men­tas de­sen­vol­vi­das pela própria Docker Inc., diversos for­ne­ce­do­res externos oferecem com­ple­men­tos à pla­ta­forma de con­têi­ne­res, assim como in­ter­fa­ces para o Docker Engine. Entre os projetos open sourcemais populares dentro do ecos­sis­tema Docker estão a fer­ra­menta de or­ques­tra­ção Ku­ber­ne­tes, a fer­ra­menta de ge­ren­ci­a­mento declustersShipyard, a solução de envio de múltiplos con­têi­ne­res Panamax, a pla­ta­forma de in­te­gra­ção contínua Drone, o sistema ope­ra­ci­o­nal de nuvem OpenStack e o sistema ope­ra­ci­o­nal de centros de dados D2iQ DC/OS, baseado no ge­ren­ci­a­dor declusters Mesos.

Ku­ber­ne­tes

Nem sempre o Docker dispôs de Docker tools de or­ques­tra­ção próprias, como o Swarm e o Compose. Por esse motivo, diversas empresas in­ves­ti­ram (e continuam in­ves­tindo) tempo e dinheiro no de­sen­vol­vi­mento de fer­ra­men­tas per­so­na­li­za­das para facilitar operações na pla­ta­forma de con­têi­ne­res, prin­ci­pal­mente em in­fra­es­tru­tu­ras grandes e dis­tri­buí­das. O Ku­ber­ne­tes está entre as soluções que­ri­di­nhas.

Ku­ber­ne­tes é um ge­ren­ci­a­dor de clusters para apli­ca­ções baseadas em con­têi­ne­res. Ele tem por objetivo au­to­ma­ti­zar apli­ca­ções no cluster, fazendo uso, para tanto, de uma API REST, de um programa de linha de comando e de uma interface gráfica web. Ela pode ser usada tanto para acionar a automação quanto para consultar re­la­tó­rios de status. Além das descritas acima, o Ku­ber­ne­tes promete realizar as seguintes funções:

• Executar, em um cluster, apli­ca­ti­vos baseados em con­têi­ne­res
• Con­fi­gu­rar e gerenciar apli­ca­ções em sistemas dis­tri­buí­dos
• Di­men­si­o­nar apli­ca­ções
• Otimizar o uso do hardware

Para cumprir o que promete, o Ku­ber­ne­tes agrupa con­têi­ne­res em partes lógicas, chamadas de Pods. Pods podem ser dis­tri­buí­dos no cluster por meio de agen­da­men­tos e re­pre­sen­tam a unidade básica deste ge­ren­ci­a­dor de clusters.

Como o Docker Swarm, o Ku­ber­ne­tes também é baseado numa ar­qui­te­tura mestre-escravo. Assim sendo, cada cluster é composto de um mestre e do seu grande número de escravos, chamados ku­ber­ne­tes notes, workers ou minions. No Ku­ber­ne­tes, mestres são camadas de ge­ren­ci­a­mento (control planes). Estas, por sua vez, são formadas por quatro com­po­nen­tes básicos: apiserver, etcd, scheduler e con­trol­ler-manager. Juntos, eles permitem que o cluster seja con­tro­lado cen­tral­mente, assim como pos­si­bi­lita sua co­mu­ni­ca­ção e a dis­tri­bui­ção de tarefas.

• kube-apiserver: Qualquer au­to­ma­ti­za­ção em um cluster é acionada por API REST, no servidor de APIkube-apiserver. Ele atua como a interface de ad­mi­nis­tra­ção central docluster.
• etcd: É a memória dosclustersKu­ber­ne­tes e consiste em um ar­ma­ze­na­mento de chave-valor de software livre. De­sen­vol­vido pelo CoreOS es­pe­ci­al­mente para sistemas dis­tri­buí­dos, o banco de dados de chave-valor armazena os dados de uma con­fi­gu­ra­ção e os dis­po­ni­bi­liza aos nós docluster. Gerencie o status docluster, a qualquer tempo, poretcd.
• kube-scheduler: Res­pon­sá­vel por dis­tri­buir grupos de con­têi­ne­res (Pods) em umcluster. Para fazer isso, ele define re­qui­si­tos de recursos de umPode os compara aos recursos dis­po­ni­bi­li­za­dos por cada nó de umcluster.
• kube-con­trol­ler-manager: Controla o status de umclustere executa tarefas de rotina, ou seja, monitora a or­ques­tra­ção. A principal tarefa docon­trol­ler-manageré garantir que o estado docluster cor­res­ponda ao estado de destino definido.

Os com­po­nen­tes de um mestre Ku­ber­ne­tes podem localizar-se todos em um único host ou serem dis­tri­buí­dos a vários hosts mestres, em clusters de alta dis­po­ni­bi­li­dade.

Embora, no Ku­ber­ne­tes, o mestre seja o res­pon­sá­vel pela or­ques­tra­ção dos con­têi­ne­res, Pods dis­tri­buí­dos no cluster são exe­cu­ta­dos nos hosts escravos (ku­ber­ne­tes notes), o que exige que cada nó execute, também um engine de contêiner. Na prática, o Docker é o padrão, mas, na teoria, o Ku­ber­ne­tes não se destina a nenhuma pla­ta­forma de con­têi­ne­res es­pe­cí­fica.

Além de um engine próprio, cada kubernete nodes inclui estes dois elementos:

• kubelet: Este agente é executado em cada nó do Ku­ber­ne­tes, para controlá-lo e gerenciá-lo. Como ponto de contato central de cadanode, okubeletconecta-se com o mestre, ga­ran­tindo que in­for­ma­ções sejam en­ca­mi­nha­das e recebidas pelo nível de controle.
• kube-proxy: O proxy de redekube-proxytambém é executado em cada nó do Ku­ber­ne­tes, ga­ran­tindo que so­li­ci­ta­ções externas sejam en­ca­mi­nha­das aos res­pec­ti­vos con­têi­ne­res. Ainda, okube-proxy fornece aos usuários, serviços para apli­ca­ções baseadas em con­têi­ne­res e de ba­lan­ce­a­mento de carga, apesar de ru­di­men­ta­res.

O gráfico abaixo mostra como a ar­qui­te­tura mestre-escravo funciona na pla­ta­forma de or­ques­tra­ção de con­têi­ne­res Ku­ber­ne­tes:

Além de seu projeto central, o Ku­ber­ne­tes dis­po­ni­bi­liza numerosas extensões, que adicionam funções extras à pla­ta­forma de or­ques­tra­ção de con­têi­ne­res. Entre as mais co­nhe­ci­das estão as Docker tools de mo­ni­to­ra­mento e di­ag­nós­tico de erros Pro­metheus, Weave Scope e sysdig; o ge­ren­ci­a­dor de pacotes Helm; os plugins Apache Maven e Gradle; e uma API Java para controlar o Ku­ber­ne­tes re­mo­ta­mente.

Shipyard

O Shipyard é uma solução de ge­ren­ci­a­mento baseada no Swarm que é de­sen­vol­vida pela própria co­mu­ni­dade de usuários Docker. Ela permite que recursos Docker, como con­têi­ne­res, imagens, hosts e registros privados sejam ge­ren­ci­a­dos por interface gráfica de usuário web, que pode ser acessada pelo navegador. A interface é 100% com­pa­tí­vel com a API remota do Docker e usa o banco de dados NoSQL RethinkDB, de código aberto, para armazenar dados de contas de usuários, endereços e eventos. Além de pos­si­bi­li­tar o ge­ren­ci­a­mento de clusters por interface web cen­tra­li­zada, o Shipyard inclui au­ten­ti­ca­ção de usuários e controle de acessos baseado em atri­bui­ções.

Essa fer­ra­menta Docker baseia-se no kit de fer­ra­men­tas de ge­ren­ci­a­mento de cluster Citadel, e é es­sen­ci­al­mente formada por três com­po­nen­tes: pelo con­tro­la­dor, pela API e pela interface de usuário (UI).

• Con­trol­ler: É o com­po­nente principal do Shipyard. O con­trol­ler interage com o RethinkDB no contexto do ar­ma­ze­na­mento de dados, per­mi­tindo que hosts in­di­vi­du­ais de um cluster Docker sejam en­de­re­ça­dos e que eventos sejam con­tro­la­dos.
• API: A API do Shipyard é baseada em REST. Ela controla todas as funções desta fer­ra­menta de ge­ren­ci­a­mento.
• UI: A interface de usuário do Shipyard é uma aplicação AngularJS que pos­si­bi­lita que usuários gerenciem clusters Docker pelo navegador. Também na UI, todas as in­te­ra­ções ocorrem por meio da API.

Encontre mais in­for­ma­ções sobre este projeto open source no site oficial do Shipyard.

Panamax

A equipe de de­sen­vol­vi­mento da fer­ra­menta para Docker Panamax tem como meta sim­pli­fi­car o de­ploy­ment de apli­ca­ti­vos de múltiplos con­têi­ne­res. Gratuita e de código aberto, ela dis­po­ni­bi­liza a seus usuários uma interface gráfica que permite que apli­ca­ti­vos complexos baseados em con­têi­ne­res sejam de­sen­vol­vi­dos, im­plan­ta­dos e dis­ri­buí­dos de forma con­ve­ni­ente, por arrastar e soltar.

Com o Panamax, tornou-se possível salvar apli­ca­ti­vos complexos, de múltiplos con­têi­ne­res, como modelos de apli­ca­ti­vos, assim como distribuí-los, com um único clique, em ar­qui­te­tu­ras de clusters. Na sua loja hospedado no GitHub, modelos de apli­ca­ções criados por usuários podem ser salvos em re­po­si­tó­rios Git e dis­po­ni­bi­li­za­dos ao público.

Os com­po­nen­tes básicos da ar­qui­te­tura do Panamax podem ser divididos em dois: cliente local e alvos de de­ploy­ments remotos.

O cliente local é o com­po­nente central da fer­ra­menta Panamax. Executado no sistema local, ele pos­si­bi­lita a criação de apli­ca­ções complexas baseadas em con­têi­ne­res. Por sua vez, o cliente local subdivide-se nos seguintes elementos:

• CoreOS: A ins­ta­la­ção do cliente local requer a dis­tri­bui­ção Linux CoreOS como sistema host, já que ela foi es­pe­ci­al­mente projetada para con­têi­ne­res de software. No CoreOS, o Panamax é executado como contêiner Docker. Adi­ci­o­nal­mente, o Panamax também dis­po­ni­bi­liza outras funções de CoreOS, como Fleet e Jour­nalctl:
  • Fleet Adapter: Em vez de interagir di­re­ta­mente com o Docker, o cliente Panamax usa o ge­ren­ci­a­dor de cluster Fleet para or­ques­trar con­têi­ne­res. Fleet é o ge­ren­ci­a­dor de clusters que controla o daemon Linux systemd em clusters de com­pu­ta­do­res.
  • Jour­nalctl: É utilizado pelo cliente Panamax para recuperar mensagens do chamado journal, log do ge­ren­ci­a­dor de sistemas Linux systemd.
• Local Client Installer: Contém todos os com­po­nen­tes ne­ces­sá­rios a ins­ta­la­ção do cliente Panamax em um sistema local.
• Local Agent: O elemento central do cliente local Panamax é o Local Agent. Por meio da sua API, ele se comunica com vários outros com­po­nen­tes e de­pen­dên­cias, como com o Docker host local, a interface de usuário do Panamax, os registros externos e os agentes remotos nos alvos de de­ploy­ment no cluster. No sistema local, o agente local também interage com as seguintes in­ter­fa­ces de pro­gra­ma­ção, pela API, para trocar in­for­ma­ções sobre as apli­ca­ções em execução:
  • Docker Remote API: Fazendo uso da API remota do Docker, o Panamax procura imagens no sistema local e recupera in­for­ma­ções de status dos con­têi­ne­res em execução.
  • etcd API: Dados do CoreOS Fleet são trans­mi­ti­dos ao daemon, por meio da API do etcd.
  • systemd-journal-gatewayd.services: Usado pelo Panamax para recuperar re­sul­ta­dos do journal sobre os serviços em execução.

Para com­ple­men­tar, a API do Panamax também suporta in­te­ra­ções com APIs externas, tais como:

• API dos registros Docker: O Panamax usa esta API para recuperar tags de imagens dos registros Docker.
• API do GitHub: Templates do Panamax podem ser car­re­ga­dos em re­po­si­tó­rios do GitHub por meio desta API.
• API do Kis­s­Me­trics: A API do Kis­s­Me­trics coleta dados sobre templates exe­cu­ta­dos por usuários.
• UI do Panamax: Atua no sistema local, per­mi­tindo que usuários controlem a fer­ra­menta por interface gráfica. Entradas inseridas por usuários são en­ca­mi­nha­das di­re­ta­mente ao agente local por meio da API do Panamax. A UI do Panamax é baseada na CTL Base UI Kit, bi­bli­o­teca de com­po­nen­tes de UI para projetos web Cen­tury­Link.

O gráfico abaixo exem­pli­fica a interação de com­po­nen­tes e elementos Panamax com clusters Docker:

A fer­ra­menta de ge­ren­ci­a­mento de con­têi­ne­res Panamax, baseada no CoreOS, oferece a seus usuários uma interface gráfica que comporta di­fe­ren­tes tec­no­lo­gias-padrão de or­ques­tra­ção de con­têi­ne­res. Ela é uma con­ve­ni­ente al­ter­na­tiva ao ge­ren­ci­a­mento de apli­ca­ções complexas em múltiplos con­têi­ne­res com ar­qui­te­tu­ras de clusters, e pode ser utilizada por pra­ti­ca­mente qualquer sistema (por exemplo, pelo seu laptop).

O Panamax também dis­po­ni­bi­liza aos usuários um re­po­si­tó­rio público de templates, com diversos recursos, no GitHub.

Drone

Drone é uma pla­ta­forma de in­te­gra­ção contínua leve, que exige re­qui­si­tos mínimos. Com esta fer­ra­menta, você pode carregar au­to­ma­ti­ca­mente a com­pi­la­ção mais recente de um re­po­si­tó­rio Git, como do GitHub, e executá-la em con­têi­ne­res isolados, para fins de teste. É possível executar qualquer conjunto de testes e receber re­la­tó­rios e mensagens de status por e-mail. Para cada teste de software, um novo contêiner, com base em uma imagem do registro público, é criado. Assim, qualquer imagem Docker acessível pu­bli­ca­mente pode ser usada como ambiente para o código a ser testado.

O Drone, que pode ser integrado ao Docker (pre­su­mi­da­mente a única de­pen­dên­cia obri­ga­tó­ria), oferece suporte a várias lin­gua­gens de pro­gra­ma­ção, como ao PHP, Node.js, Ruby, Go e Python. Use o Drone para criar uma pla­ta­forma de in­te­gra­ção contínua pessoal em qualquer sistema que suporta uma ins­ta­la­ção Docker. Ele admite vários re­po­si­tó­rios de controle de versão, o que é outra vantagem. Ins­tru­ções sobre o processo de ins­ta­la­ção padrão da fer­ra­menta, com in­te­gra­ção ao GitHub, podem ser en­con­tra­das no projeto open source readme.drone.io.

Essa fer­ra­menta pode ser con­tro­lada por interface web. Utilize-a para carregar com­pi­la­ções de software de qualquer re­po­si­tó­rio Git, combiná-las em apli­ca­ções e executar re­sul­ta­dos em ambientes de teste pre­vi­a­mente definidos. Para cada teste de software, um arquivo drone.yml é criado. Nele, você deve es­pe­ci­fi­car como a aplicação deve ser gerada e executada.

Em resumo, o Drone é de fácil uti­li­za­ção e oferece a seus usuários uma solução de CI de código aberto, que combina pontos fortes de produtos al­ter­na­ti­vos, como do Travis e do Jenkins.

OpenStack

O sistema ope­ra­ci­o­nal de nuvem OpenStack, de código aberto, é o preferido entre os que precisam con­fi­gu­rar e operar es­tru­tu­ras de nuvem open source. Com esta fer­ra­menta para Docker, recursos de com­pu­ta­ção, rede e ar­ma­ze­na­mento em centros de dados podem ser ge­ren­ci­a­dos por um painel central e dis­po­ni­bi­li­za­dos a usuários finais por interface web.

Baseado em ar­qui­te­tura modular, o OpenStack é composto por di­fe­ren­tes módulos. Entre os princpais estão:

• Zun (serviço de con­têi­ne­res): Ele pos­si­bi­lita de­ploy­ments fa­ci­li­ta­dos e o ge­ren­ci­a­mento de apli­ca­ções em con­têi­ne­res ar­ma­ze­na­dos na nuvem do OpenStack. Com o Zun, usuários gerenciam con­têi­ne­res por meio de uma API REST, o que os desobriga de gerenciar ser­vi­do­res e clusters. Para funcionar, este com­po­nente requer três outros serviços do OpenStack: Keystone, Neutron e kuryr-lib­network. Amplie, op­ci­o­nal­mente, a fun­ci­o­na­li­dade do Zun, com outros serviços do OpenStack, como o Cinder e o Glance.
• Neutron (com­po­nente de rede): O Neutron (antigo Quantum) é um com­po­nente de sistema portátil, di­men­si­o­ná­vel e que suporta API, usado para controle de rede. Ele dis­po­ni­bi­liza uma interface para to­po­lo­gias de rede complexas e oferece suporte a vários plugins, que podem ser uti­li­za­dos para integrar e estender funções de rede.
• kuryr-lib­network (driver do Docker): Atua como interface entre o Docker e o Neutron.
• Keystone (serviço de iden­ti­dade): Oferece a usuários do OpenStack um serviço de iden­ti­fi­ca­ção cen­tra­li­zado, atuando como sistema de au­ten­ti­ca­ção e au­to­ri­za­ção entre com­po­nen­tes in­di­vi­du­ais. O acesso a projetos na nuvem é regulado pelos chamados lo­ca­tá­rios — cada locatário re­pre­senta uma unidade de usuário. Defina direitos de acesso para cada unidade de usuário.
• Cinder (ar­ma­ze­na­mento de blocos): Módulo da ar­qui­te­tura OpenStack que fornece ar­ma­ze­na­mento em blocos per­sis­tente, para a operação de máquinas virtuais. O ar­ma­ze­na­mento, em memória virtual, é feito por meio de uma API de au­to­a­ten­di­mento, que não exige que usuários finais saibam onde o ar­ma­ze­na­mento está sendo im­plan­tado e/ou em que tipo de dis­po­si­tivo.
• Glance (serviço de imagem): O módulo Glance pode ser usado para armazenar e recuperar imagens de máquinas virtuais.

Obtenha mais in­for­ma­ções sobre com­po­nen­tes e serviços ofe­re­ci­dos pelo OpenStack no nosso artigo es­pe­ci­a­li­zado. Ainda, é possível expandir a ar­qui­te­tura do OpenStack com outros módulos, que não foram aqui apre­sen­ta­dos. O site oficial do OpenStack tem a lista completa.

D2iQ DC/OS

O DC/OS (Dis­tri­bu­ted Cloud Operating System) é um software de código aberto de­sen­vol­vido pela D2iQ Inc. (antiga Me­sosphere), para a operação de sistemas dis­tri­buí­dos. O projeto, um sistema ope­ra­ci­o­nal para centros de dados, é baseado no ge­ren­ci­a­dor de clusters, também open source, Apache Mesos. Assim sendo, esta fer­ra­menta para Docker pode ser con­si­de­rada um tipo de dis­tri­bui­ção ampliada do Mesos, já que dis­po­ni­bi­liza todas as funções do Cluster Manager por uma interface de usuário cen­tra­li­zada.

O código-fonte do DC/OS, que pode ser en­con­trado no GitHub, é liberado aos usuários sob a licença Apache 2.0. Uma versão cor­po­ra­tiva do DC/OS também é co­mer­ci­a­li­zada por seus de­sen­vol­ve­do­res. Explore a do­cu­men­ta­ções do DC/OS.

O DC/OS utiliza o núcleo do sistema dis­tri­buído da pla­ta­forma Mesos, o que pos­si­bi­lita o agru­pa­mento de recursos completos de um banco de dados, assim como ge­ren­ci­a­mento se­me­lhante ao de um sistema agregado de servidor lógico único. Com a fer­ra­menta, você poderá controlar clusters inteiros, de máquinas físicas ou virtuais, com a mesma fa­ci­li­dade com que opera um simples com­pu­ta­dor.

O software, de ins­ta­la­ção simples, também sim­pli­fica o ge­ren­ci­a­mento de apli­ca­ções dis­tri­buí­das e au­to­ma­tiza tarefas, como de ge­ren­ci­a­mento de recursos, de agen­da­mento e de co­mu­ni­ca­ção entre processos. Por ter base no D2iQ DC/OS, um cluster, e todos os serviços nele exe­cu­ta­dos, podem ser ge­ren­ci­a­dos cen­tra­li­za­da­mente pelo terminal ou por uma interface gráfica web.

A fer­ra­menta DC/OS despreza recursos para clusters e fornece serviços com­par­ti­lha­dos, como de des­co­berta de serviços e de ge­ren­ci­a­mento de pacotes. Os prin­ci­pais com­po­nen­tes do software são exe­cu­ta­dos em área protegida, chamada de espaço de núcleo (kernel). Ele inclui programas mestre e agente da pla­ta­forma Mesos, res­pon­sá­veis pela alocação de recursos, pelo iso­la­mento de processos e por funções de segurança.

• Mesos Master: No Mesos, o mestre de um processo é executado em um nó do cluster, chamado de nó mestre. A função de um mestre é controlar o ge­ren­ci­a­mento de recursos e o or­ques­tra­mento de tarefas (unidades de trabalho abstratas), exe­cu­ta­das em um nó agente. Para tanto, mestres dis­tri­buem recursos entre os serviços DC/OS re­gis­tra­dos. De volta, eles recebem re­la­tó­rios sobre os recursos.
• Mesos Agents: No Mesos, agentes são processos escravos que executam, em contas de agentes, tarefas dis­tri­buí­das por um mestre. Ainda, eles fornecem re­la­tó­rios a seus mestres, com re­gu­la­ri­dade, que tratam dos recursos dis­po­ní­veis no cluster. Em posse dos re­la­tó­rios, mestres os en­ca­mi­nham a um es­ca­lo­na­dor (Marathon, Chronos ou Cassandra, por exemplo), que decidirá qual tarefa será executada por cada nó. Tarefas podem ser exe­cu­ta­das in­di­vi­du­al­mente ou em um contêiner.

Todos os demais com­po­nen­tes e apli­ca­ções de agentes do Mesos são exe­cu­ta­dos no espaço do usuário. Entre os com­po­nen­tes básicos de uma ins­ta­la­ção DC/OS padrão estão Admin Router, Mesos DNS, Dis­tri­bu­ted DNS Proxy, Minuteman (ba­lan­ce­a­dor de carga), Marathon (agendador), Apache ZooKeeper e Exhibitor.

• Admin Router: Um roteador de ad­mi­nis­tra­ção nada mais é que um servidor web es­pe­ci­al­mente con­fi­gu­rado para NGINX, que dis­po­ni­bi­liza serviços DC/OS, bem como au­ten­ti­ca­ções cen­tra­li­za­das e funções de proxy.
• Mesos DNS: Este com­po­nente de sistema executa funções de des­co­berta de serviços, que permitem que serviços e apli­ca­ções in­di­vi­du­ais, em um cluster, iden­ti­fi­quem uns aos outros por meio de um sistema de nomes de domínio (DNS) central.
• Dis­tri­bu­ted DNS Proxy: É o des­pa­chante (dis­tri­bui­dor) do DNS interno.
• Minuteman: Atua como ba­lan­ce­a­dor de carga interno, operando no nível de trans­porte (camada 4) do modelo OSI.
• DC/OS Marathon: Com­po­nente central da pla­ta­forma Mesos. Atua como sistema de ini­ci­a­li­za­ção (se­me­lhante ao systemd) no D2iQ DC/OS. Ele ini­ci­a­liza e monitora serviços e apli­ca­ções do DC/OS em ambientes de cluster, e também realiza funções de alta dis­po­ni­bi­li­dade, des­co­berta de serviços, ba­lan­ce­a­mento de carga, ve­ri­fi­ca­ções de in­te­gri­dade, além de oferecer uma interface gráfica web.
• Apache ZooKeeper: É um com­po­nente de software de código aberto que de­sem­pe­nha funções de co­or­de­na­ção para a operação e o controle de apli­ca­ções em sistemas dis­tri­buí­dos. No D2iQ DC/OS, o ZooKeeper coordena todos os serviços ins­ta­la­dos de sistema.
• Exhibitor: É o com­po­nente do sistema que pos­si­bi­lita a ins­ta­la­ção e a con­fi­gu­ra­ção au­to­má­tica do ZooKeeper em cada nó mestre de um cluster. Ele ainda dis­po­ni­bi­liza uma interface gráfica aos usuários do ZooKeeper.

Cargas de trabalho múltiplas podem ser exe­cu­ta­das si­mul­ta­ne­a­mente em recursos de clusters agregados pelo DC/OS. Esta fer­ra­menta para Docker permite, por exemplo, a operação paralela de sistemas de big data, de mi­cros­ser­vi­ços e de pla­ta­for­mas de con­têi­ne­res, como o Hadoop, o Spark e o próprio Docker.

No catálogo público de apli­ca­ções para DC/OS, D2iQ Universe, você encontra ins­tru­ções para a ins­ta­la­ção de outros sistemas, como Spark, Cassandra, Chronos, Jenkins e Kafka.

Docker tools para aumentar a segurança

Mesmo quando processos en­cap­su­la­dos são exe­cu­ta­dos no mesmo núcleo de um contêiner, o Docker aplica uma série de técnicas de iso­la­mento para protegê-los uns dos outros. Funções de núcleo do Linux, como cgroups e na­mes­pa­ces, são es­pe­ci­al­mente uti­li­za­das para este fim. Mesmo assim, con­têi­ne­res não conseguem oferecer o mesmo grau de iso­la­mento de máquinas virtuais. Apesar dos esforços de iso­la­mento acima descritos, im­por­tan­tes sub­sis­te­mas do núcleo (como o Cgroups) e in­ter­fa­ces de núcleo presentes nos di­re­tó­rios /sys e /proc, por exemplo, podem ser acessados por con­têi­ne­res. A equipe de de­sen­vol­vi­mento do Docker reconhece que a vul­ne­ra­bi­li­dade de segurança põe freio a esta tec­no­lo­gia de con­têi­ne­res em sistemas de produção. Além de técnicas básicas de iso­la­mento do núcleo Linux, as versões mais recentes do Docker Engine suportam as seguintes Docker tools de segurança: AppArmor, SELinux e Seccomp. Elas atuam como uma espécie de firewall para os recursos do núcleo.

• AppArmor: Pode ser usado para con­fi­gu­rar direitos de acesso de con­têi­ne­res ao sistema de arquivos.
• SELinux: Dis­po­ni­bi­liza um complexo sistema de regras que pos­si­bi­lita a im­ple­men­ta­ção de controles de acesso aos recursos do núcleo.
• Seccomp: O Secure Computing Mode pode ser usado para monitorar a invocação de chamadas do sistema.

Além das fer­ra­men­tas acima, o Docker utiliza Linux Ca­pa­bi­li­tiespara res­trin­gir direitosroot au­to­ma­ti­ca­mente definidos durante a ini­ci­a­li­za­ção de seus con­têi­ne­res.

Outra vul­ne­ra­bi­li­dade de segurança do Docker diz respeito a com­po­nen­tes de apli­ca­ções de usuários dis­po­ní­veis nos registros Docker. Como, em princípio, qualquer pessoa pode criar imagens e torná-las públicas no Docker Hub, existe o risco de algumas conterem códigos ma­li­ci­o­sos que podem invadir e pre­ju­di­car o seu sistema. Por causa disso, re­co­men­da­mos que você se cer­ti­fi­que da origem da imagem Docker que deseja executar para implantar um apli­ca­tivo, ve­ri­fi­cando se a mesma é pro­ve­ni­ente de uma fonte confiável.

O Docker Verified Publisher Program é o programa de cer­ti­fi­ca­ção do Docker, que verifica a segurança de imagens for­ne­ci­das por terceiros, con­ce­dendo-lhes um cer­ti­fi­cado. Atestando a ido­nei­dade de seus for­ne­ce­do­res, o Docker se esforça para oferecer cada vez mais segurança na dis­po­ni­bi­li­za­ção de softwares. Além de proteger usuários, o programa também é in­te­res­sante para de­sen­vol­ve­do­res, que têm maiores opor­tu­ni­da­des de destaque ao possuírem o cer­ti­fi­cado de segurança Verified Publisher — imagens cer­ti­fi­ca­das são mais bem clas­si­fi­ca­das pelos re­sul­ta­dos de buscas re­a­li­za­das no Docker Hub.