Fer­ra­men­tas do Docker

O vasto ecos­sis­tema do Docker oferece aos pro­gra­ma­do­res inúmeras opções para im­ple­men­tar apli­ca­ções e or­ques­trar con­ten­to­res, entre outras fun­ci­o­na­li­da­des. A seguir, apre­sen­ta­mos as fer­ra­men­tas do Docker mais im­por­tan­tes e os projetos de terceiros mais populares que estão a de­sen­vol­ver fer­ra­men­tas de código aberto para o Docker.

As fer­ra­men­tas mais básicas do Docker e os seus com­po­nen­tes

Hoje em dia, o Docker é muito mais do que uma pla­ta­forma leve para a gestão de con­ten­to­res de software. Para tornar a im­ple­men­ta­ção de apli­ca­ções em in­fra­es­tru­tu­ras e ambientes de nuvem dis­tri­buí­dos mais simples, rápida e flexível, a equipa de de­sen­vol­vi­mento dis­po­ni­bi­li­zou várias fer­ra­men­tas do Docker que oferecem aos uti­li­za­do­res fun­ci­o­na­li­da­des de cluster e or­ques­tra­ção, um mercado central de apli­ca­ções e uma fer­ra­menta para gerir recursos na nuvem.

Docker Engine

Quando se fala do Docker, ge­ral­mente refere-se à aplicação cliente-servidor de código aberto na qual se baseia a pla­ta­forma de con­ten­to­res, que, na sua própria no­men­cla­tura, é designada por Docker Engine. Os com­po­nen­tes centrais do motor do Docker são o Docker Daemon, uma API baseada em REST e uma CLI (Command Line Interface) como interface de uti­li­za­dor. É esta estrutura que permite controlar o motor do Docker através de comandos e gerir as imagens, os ficheiros do Docker e os con­ten­to­res a partir do terminal. O cliente e o daemon podem estar lo­ca­li­za­dos em sistemas di­fe­ren­tes. Pode encontrar uma apre­sen­ta­ção geral dos comandos mais im­por­tan­tes do Docker no nosso artigo adicional.

Docker Hub

Com o Docker Hub, os uti­li­za­do­res têm à dis­po­si­ção um servidor de registos na nuvem a partir do qual podem des­car­re­gar, gerir e partilhar imagens Docker. Após o registo, os uti­li­za­do­res podem optar por guardar as imagens em re­po­si­tó­rios públicos ou privados. Um sistema integrado de etiquetas permite o controlo de versões das imagens.

Para além dos re­po­si­tó­rios públicos de outros uti­li­za­do­res, no Docker Hub também se encontram vários recursos dis­po­ni­bi­li­za­dos por equipas de de­sen­vol­vi­mento e projetos de código aberto de renome em arquivos de imagens oficiais. Entre as imagens Docker mais populares contam-se o servidor web NGINX, a base de dados In-Memory Redis, o conjunto de fer­ra­men­tas Linux BusyBox e a dis­tri­bui­ção Linux Ubuntu.

Outra fun­ci­o­na­li­dade do Docker Hub são as chamadas «or­ga­ni­za­ções», grupos de trabalho que permitem aos uti­li­za­do­res da pla­ta­forma partilhar re­po­si­tó­rios privados com de­ter­mi­na­dos círculos. Os direitos de acesso são geridos in­ter­na­mente através de equipas e afi­li­a­ções a grupos.

Docker Swarm

O Docker Engine inclui fun­ci­o­na­li­da­des nativas que permitem ao uti­li­za­dor gerir hosts Docker em clusters, de­no­mi­na­dos «swarms» («enxames»). Estas fun­ci­o­na­li­da­des de gestão de clusters e or­ques­tra­ção in­te­gra­das no Docker Engine baseiam-se na toolbox Swarmkit.

A fer­ra­menta de clus­te­ring nativa Swarm agrupa uma série de hosts Docker num único host virtual e utiliza a API do Docker para que qualquer fer­ra­menta Docker que esteja em contacto com o Docker Daemon possa aceder ao Swarm e seja possível escalar para um de­ter­mi­nado número de hosts. Os uti­li­za­do­res utilizam a CLI do motor Docker para criar enxames, dis­tri­buir apli­ca­ções no cluster e controlar o com­por­ta­mento do enxame. Não requer software de or­ques­tra­ção adicional.

Os Docker Engines que foram agrupados em clusters funcionam no modo swarm. Este modo é ativado para criar um novo cluster ou para adicionar um host já existente a um swarm. Cada um dos hosts num cluster passa a ser um «nó» e estes nós podem ser exe­cu­ta­dos como hosts virtuais no mesmo sistema local, embora a variante mais comum consista numa estrutura baseada na nuvem, na qual os nós do swarm são dis­tri­buí­dos por vários sistemas e in­fra­es­tru­tu­ras.

Na base deste software encontra-se uma ar­qui­te­tura mestre-escravo: quando é ne­ces­sá­rio dis­tri­buir tarefas no enxame, os uti­li­za­do­res trans­fe­rem um chamado «serviço» para o nó gestor, que atua como mestre no cluster. Este mestre é res­pon­sá­vel pelo pla­ne­a­mento dos con­ten­to­res no cluster e funciona como interface principal para aceder aos recursos do Swarm.

O nó gestor envia cada unidade de trabalho se­pa­ra­da­mente, as chamadas «tasks» (tarefas), para nós su­bor­di­na­dos, co­nhe­ci­dos como «worker nodes» (nós de trabalho) na ter­mi­no­lo­gia do Docker.

• Serviços: os serviços são es­tru­tu­ras centrais nos clusters Docker. Um serviço é um grupo de con­ten­to­res baseados na mesma imagem e define as tarefas a executar no cluster. Um uti­li­za­dor que cria um serviço es­pe­ci­fica nele quais as imagens a utilizar e quais os comandos a executar. Também oferecem a pos­si­bi­li­dade de escalar apli­ca­ções. Para tal, os uti­li­za­do­res do Docker apenas têm de definir quantos con­ten­to­res devem ser iniciados para um serviço.
• Tarefas: para poder dis­tri­buir serviços no cluster, o nó mestre divide-os em unidades in­de­pen­den­tes ou tarefas. Cada uma delas inclui um contentor e os comandos que são exe­cu­ta­dos nele.

Além das funções de gestão do cluster e de or­ques­tra­ção dos con­ten­to­res, os nós mestres também de­sem­pe­nham funções de nós de trabalho na con­fi­gu­ra­ção padrão, a menos que o uti­li­za­dor limite as suas funções às tarefas de gestão.

Em cada nó de trabalho, é executado um programa agente (agent program). Este programa recebe as tarefas e envia ao nó mestre cor­res­pon­dente re­la­tó­rios sobre o andamento da tarefa que trans­fe­riu. O gráfico seguinte re­pre­senta, em linhas gerais, um enxame Docker:

Quando se trata de im­ple­men­tar um Docker Swarm, os uti­li­za­do­res recorrem fre­quen­te­mente ao Docker Machine.

Docker Compose

O Docker Compose permite ligar vários con­ten­to­res e executá-los com um único comando. O seu com­po­nente fun­da­men­tal é um ficheiro de controlo central baseado na linguagem de marcação YAML. A sintaxe deste ficheiro assemelha-se à do software de código aberto Vagrant, utilizado na criação e apro­vi­si­o­na­mento de máquinas virtuais.

No ficheiro docker-compose.yml, é possível definir quantos con­ten­to­res de software se desejar, incluindo todas as de­pen­dên­cias, bem como as suas inter-relações. O esquema seguido para gerir apli­ca­ções com vários con­ten­to­res não difere do ne­ces­sá­rio para gerir con­ten­to­res simples. Com o comando docker-compose e o sub­co­mando cor­res­pon­dente, é possível gerir todo o ciclo de vida da aplicação.

Esta fer­ra­menta de or­ques­tra­ção pode ser fa­cil­mente integrada num cluster baseado no Swarm. As apli­ca­ções com vários con­ten­to­res criadas com o Compose executam-se em sistemas dis­tri­buí­dos com a mesma fa­ci­li­dade que em hosts isolados.

Outra ca­rac­te­rís­tica do Docker Compose é o seu mecanismo de es­ca­la­bi­li­dade integrado: através da linha de comandos, esta fer­ra­menta do Docker permite definir quantos con­ten­to­res devem ser iniciados para um de­ter­mi­nado serviço.

Fer­ra­men­tas Docker de for­ne­ce­do­res externos

Para além destes programas de­sen­vol­vi­dos pela Docker Inc., alguns for­ne­ce­do­res externos também se decidiram a de­sen­vol­ver fer­ra­men­tas e pla­ta­for­mas que, ou bem se podem ligar ao Docker Engine, ou foram de­sen­vol­vi­das ex­clu­si­va­mente para a popular pla­ta­forma. Entre a di­ver­si­dade de projetos de código aberto abran­gi­dos pelo ecos­sis­tema do Docker, destacam-se a fer­ra­menta de or­ques­tra­ção Ku­ber­ne­tes, o sistema de gestão de clusters Shipyard, a solução de im­ple­men­ta­ção de apli­ca­ções mul­ti­con­tai­ner Panamax, a pla­ta­forma de in­te­gra­ção contínua Drone, o sistema operativo na nuvem OpenStack e o sistema operativo para centros de dados D2iQ DC/OS, baseado no gestor de clusters Mesos.

Ku­ber­ne­tes

Houve uma altura em que o Docker não conseguia fornecer fer­ra­men­tas próprias de or­ques­tra­ção, como o Swarm e o Compose. É por isso que, há já vários anos, inúmeras empresas investem no de­sen­vol­vi­mento de fer­ra­men­tas per­so­na­li­za­das para facilitar o fun­ci­o­na­mento da pla­ta­forma de con­ten­to­res em in­fra­es­tru­tu­ras de grande dimensão e dis­tri­buí­das. Entre as soluções mais co­nhe­ci­das deste tipo encontra-se o projeto de código aberto Ku­ber­ne­tes.

O Ku­ber­ne­tes é um gestor de clusters para apli­ca­ções em con­têi­ne­res. O seu objetivo é au­to­ma­ti­zar a gestão de apli­ca­ções em clusters. Para tal, esta fer­ra­menta de or­ques­tra­ção utiliza uma API REST, um programa de linha de comandos e uma interface web gráfica como in­ter­fa­ces de controlo, através das quais é possível executar au­to­ma­ti­za­ções e solicitar re­la­tó­rios de estado. Os uti­li­za­do­res utilizam o Ku­ber­ne­tes para:

• Executar apli­ca­ções em con­têi­ne­res num cluster
• Instalar e gerir apli­ca­ções em sistemas dis­tri­buí­dos
• Escalar apli­ca­ções
• Apro­vei­tar ao máximo o hardware dis­po­ní­vel

Para tal, o Ku­ber­ne­tes agrupa os con­ten­to­res em unidades lógicas, os chamados «pods», que cons­ti­tuem as unidades básicas do gestor e que podem ser dis­tri­buí­das pelo cluster através do método de agen­da­mento.

Tal como o Swarm, também o Ku­ber­ne­tes assenta na ar­qui­te­tura mestre-escravo: um cluster é composto por um mestre (Ku­ber­ne­tes Master) e por vários escravos ou Ku­ber­ne­tes Nodes (também chamados de Worker ou Minions). O mestre atua como nível de controlo central (Control Plane) no cluster e é composto por quatro elementos básicos que permitem coordenar a co­mu­ni­ca­ção no interior do cluster e dis­tri­buir as tarefas: um servidor API, a memória de con­fi­gu­ra­ção etcd, um scheduler e um Con­trol­ler Manager.

• Servidor API: num cluster Ku­ber­ne­tes, todos os processos au­to­ma­ti­za­dos são exe­cu­ta­dos num servidor API através de uma API REST. Este servidor funciona como ponto central de gestão no cluster.
• etcd: este ar­ma­ze­na­mento de chave-valor de código aberto pode ser con­si­de­rado a memória de um cluster Ku­ber­ne­tes. De­sen­vol­vido pela CoreOS es­pe­ci­al­mente para sistemas dis­tri­buí­dos, o etcd armazena dados de con­fi­gu­ra­ção e dis­po­ni­bi­liza-os aos nós. Isto permite gerir o estado atual do cluster a qualquer momento.
• Scheduler: a função do agendador consiste em dis­tri­buir os pods pelo cluster, para o que determina quantos recursos um pod necessita e os ajusta aos recursos dis­po­ní­veis em cada nó do cluster.
• Con­trol­ler Manager: este é um serviço do mestre do Ku­ber­ne­tes que regula o estado do cluster e executa tarefas de rotina, dirigindo assim a or­ques­tra­ção. A principal res­pon­sa­bi­li­dade do «gestor do con­tro­la­dor» é garantir que o estado do cluster cor­res­ponda ao estado pre­vi­a­mente definido como objetivo.

Estes quatro com­po­nen­tes de um servidor mestre podem estar lo­ca­li­za­dos num único servidor ou dis­tri­buí­dos por vários ser­vi­do­res num cluster de alta dis­po­ni­bi­li­dade.

Enquanto o mestre é res­pon­sá­vel pela or­ques­tra­ção, os pods dis­tri­buí­dos no cluster são exe­cu­ta­dos nos nós (hosts su­bor­di­na­dos ao host mestre). Para tal, em cada nó tem de estar em execução um Container Engine, na prática o Docker, embora o Ku­ber­ne­tes não esteja vinculado a nenhum motor de con­ten­to­res em par­ti­cu­lar.

Para além do Container Engine, os nós do Ku­ber­ne­tes também incluem os seguintes com­po­nen­tes:

• kubelet: este nome designa um agente que, ao ser executado em cada nó, o controla e gere. Como principal ponto de contacto nos nós, o kubelet mantém a co­mu­ni­ca­ção com o mestre e assegura que a in­for­ma­ção seja enviada para o nível de controlo e que este a receba.
• kube-proxy: além disso, em cada nó do Ku­ber­ne­tes, também é executado este serviço de proxy res­pon­sá­vel por garantir que as so­li­ci­ta­ções pro­ve­ni­en­tes do exterior sejam enviadas para o contentor cor­res­pon­dente e por fornecer serviços aos uti­li­za­do­res de apli­ca­ções em con­ten­to­res. Além disso, o kube-proxy oferece um ba­lan­ce­a­mento de carga básico.

O gráfico seguinte mostra es­que­ma­ti­ca­mente a ar­qui­te­tura mestre-escravo na qual se baseia a pla­ta­forma de or­ques­tra­ção Ku­ber­ne­tes:

As fun­ci­o­na­li­da­des do Ku­ber­ne­tes podem ser ampliadas com um vasto leque de fer­ra­men­tas e extensões. Entre as mais co­nhe­ci­das encontram-se as fer­ra­men­tas de mo­ni­to­ri­za­ção e di­ag­nós­tico de erros Pro­metheus, Weave Scope e sysdig, bem como o gestor de pacotes Helm. A estas juntam-se alguns plugins para o Apache Maven e o Gradle, bem como uma API Java para controlar o Ku­ber­ne­tes re­mo­ta­mente.

Estaleiro

O Shipyard é uma solução de gestão de­sen­vol­vida pela co­mu­ni­dade de uti­li­za­do­res do Docker, baseada no Swarm, que permite aos uti­li­za­do­res gerir recursos da pla­ta­forma, tais como con­ten­to­res, imagens, hosts e re­po­si­tó­rios privados, através de uma interface gráfica de uti­li­za­dor. O Shipyard está dis­po­ní­vel como aplicação web.

O programa é to­tal­mente com­pa­tí­vel com a Remote API do Docker e utiliza a base de dados NoSQL de código aberto RethinkDB para armazenar contas de uti­li­za­dor, endereços e eventos. Além de fornecer fun­ci­o­na­li­da­des de gestão de clusters numa interface web central, a fer­ra­menta inclui também uma fun­ci­o­na­li­dade de ve­ri­fi­ca­ção de uti­li­za­do­res e uma de controlo de acesso baseado em funções.

O software baseia-se no kit de fer­ra­men­tas de gestão de clusters Citadel e é composto, es­sen­ci­al­mente, por três elementos: Con­trol­ler, API e UI.

• Shipyard Con­trol­ler: este com­po­nente constitui o coração do Shipyard. O con­tro­la­dor interage com a base de dados RethinkDB para armazenar a in­for­ma­ção e permite a co­mu­ni­ca­ção com os hosts num cluster Docker, bem como o controlo dos eventos.
• API do Shipyard: a API do Shipyard é baseada em REST. Todas as funções da fer­ra­menta de gestão são con­tro­la­das por ela.
• Interface de Uti­li­za­dor (UI) do Shipyard: a interface de uti­li­za­dor do Shipyard é uma aplicação AngularJS que fornece aos uti­li­za­do­res uma interface gráfica para gerir os clusters Docker no navegador. Todas as in­te­ra­ções na interface de uti­li­za­dor ocorrem através da API do Shipyard.

No site oficial do Shipyard, pode conhecer em pro­fun­di­dade este projeto de código aberto.

Panamax

A equipa de pro­gra­ma­do­res da fer­ra­menta de código aberto Docker Panamax propôs-se sim­pli­fi­car a im­ple­men­ta­ção de apli­ca­ções com vários con­ten­to­res. A fer­ra­menta oferece aos uti­li­za­do­res uma interface gráfica que permite de­sen­vol­ver, im­ple­men­tar e dis­tri­buir apli­ca­ções complexas baseadas em con­ten­to­res Docker de forma simples, através de arrastar e largar.

O Panamax permite guardar estas apli­ca­ções sob a forma de modelos de aplicação e distribuí-las em es­tru­tu­ras de cluster com grande fa­ci­li­dade. Através de um App Mar­ket­place integrado na fer­ra­menta e alojado no GitHub, estes modelos podem ser guardados e pu­bli­ca­dos em re­po­si­tó­rios Git. Os com­po­nen­tes fun­da­men­tais da ar­qui­te­tura do Panamax podem ser sub­di­vi­di­dos em dois grupos: costuma-se dis­tin­guir entre o cliente local do Panamax, por um lado, e um número aleatório de Remote De­ploy­ment Targets, por outro.

O cliente local do Panamax (Panamax Local Client) é o principal com­po­nente das fer­ra­men­tas Docker. É executado no sistema local e permite criar apli­ca­ções complexas em con­têi­ne­res. O Panamax Local Client é composto pelos seguintes com­po­nen­tes:

• CoreOS: a ins­ta­la­ção do cliente local do Panamax pressupõe a uti­li­za­ção da dis­tri­bui­ção Linux CoreOS, es­pe­ci­al­mente orientada para software de con­te­ne­do­ri­za­ção, como sistema anfitrião. Com o Panamax, os uti­li­za­do­res têm à sua dis­po­si­ção não só as fun­ci­o­na­li­da­des próprias do Docker, mas também várias fun­ci­o­na­li­da­des do CoreOS, entre as quais se incluem o Fleet e o Jour­nalctl.
  • Fleet: em vez de interagir di­re­ta­mente com o Docker, o cliente do Panamax utiliza o Fleet para coordenar os con­ten­to­res. O Fleet é um gestor de clusters que controla o daemon systemd do Linux em clusters de com­pu­ta­do­res.
  • Jour­nalctl: o cliente do Panamax utiliza esta função para solicitar no­ti­fi­ca­ções de log do systemd a partir do Journal.
  • Ins­ta­la­dor do Cliente Local: o ins­ta­la­dor do cliente local contém todos os com­po­nen­tes ne­ces­sá­rios para instalar o cliente Panamax num sistema local.
• Agente Local do Panamax: o chamado agente local é o com­po­nente principal do cliente local e mantém o contacto com outros com­po­nen­tes e de­pen­dên­cias através da API do Panamax. Entre estes contam-se o host local do Docker, a interface de uti­li­za­dor do Panamax, os ser­vi­do­res de registo externos, bem como os agentes remotos nos Alvos de Im­ple­men­ta­ção do cluster. Com o objetivo de trocar in­for­ma­ções sobre apli­ca­ções em execução, o agente local interage no sistema local através da API do Panamax com as seguintes in­ter­fa­ces de pro­gra­ma­ção:
  • API Remota do Docker: através da API remota do Docker, o Panamax procura imagens no sistema local e solicita in­for­ma­ções de estado sobre os con­ten­to­res em execução.
  • API etcd: com esta API, são enviados dados para o daemon do Fleet (CoreOS Fleet Daemon).
  • systemd-journal-gatewayd.services: com esta diretiva, o Panamax solicita in­for­ma­ções sobre serviços ativos (saída do Journal).

Para além destas, a API do Panamax também permite a interação com APIs externas:

• API do Docker Registry: através desta API, o Panamax extrai as etiquetas de imagem do Panamax do registo do Docker (Docker Registry).
• API do GitHub: com ela, é possível carregar modelos do Panamax para re­po­si­tó­rios do GitHub.
• API Kis­s­Me­trics: a API da Kis­s­Me­trics recolhe dados sobre os modelos exe­cu­ta­dos pelos uti­li­za­do­res.
• Interface de uti­li­za­dor do Panamax: a interface de uti­li­za­dor do Panamax permite aos uti­li­za­do­res controlar a fer­ra­menta Docker no sistema local através de uma interface gráfica. Com a API do Panamax, os dados in­tro­du­zi­dos pelo uti­li­za­dor podem ser enviados di­re­ta­mente para o agente local. A interface de uti­li­za­dor do Panamax baseia-se no CTL Base UI Kit, uma bi­bli­o­teca básica com com­po­nen­tes de interface de uti­li­za­dor para projetos da Cen­tury­Link.

Os nós sem tarefas de ad­mi­nis­tra­ção num cluster Docker são de­sig­na­dos, na ter­mi­no­lo­gia do Docker, por «Remote De­ploy­ment Targets». Estes são cons­ti­tuí­dos por um host Docker con­fi­gu­rado com os seguintes com­po­nen­tes para a im­ple­men­ta­ção de modelos Panamax:

• Ins­ta­la­dor do Alvo de Im­ple­men­ta­ção: o ins­ta­la­dor inicia um host Docker, que inclui um agente remoto Panamax e um adaptador de or­ques­tra­ção (Or­ches­tra­tion Adapter).
• Agente Remoto Panamax: uma vez instalado o agente remoto do Panamax, as apli­ca­ções podem ser dis­tri­buí­das no cluster através do cliente local do Panamax. Este agente remoto é executado como um contentor Docker em cada alvo de im­ple­men­ta­ção (De­ploy­ment Target) no cluster.
• Adaptador de or­ques­tra­ção do Panamax: no adaptador de or­ques­tra­ção, a lógica de programa de cada uma das fer­ra­men­tas de or­ques­tra­ção dis­po­ní­veis para o Panamax é im­ple­men­tada numa camada in­de­pen­dente do adaptador. É assim que os uti­li­za­do­res têm a pos­si­bi­li­dade de escolher sempre a tec­no­lo­gia de or­ques­tra­ção exa­ta­mente com­pa­tí­vel com cada ambiente final. Os adap­ta­do­res pre­de­fi­ni­dos incluem o Ku­ber­ne­tes e o Fleet:
  • Panamax Ku­ber­ne­tes Adapter: em com­bi­na­ção com o agente remoto do Panamax, o adaptador Ku­ber­ne­tes permite dis­tri­buir modelos do Panamax em clusters Ku­ber­ne­tes.
  • Adaptador Panamax Fleet: em co­o­pe­ra­ção com o agente remoto do Panamax, o adaptador Fleet permite dis­tri­buir modelos do Panamax em clusters con­tro­la­dos pelo gestor de clusters Fleet.

O gráfico a seguir mostra a interação de cada com­po­nente do Panamax num cluster Docker:

O Panamax oferece aos uti­li­za­do­res várias tec­no­lo­gias padrão de or­ques­tra­ção de con­ten­to­res numa interface gráfica, bem como a pos­si­bi­li­dade de gerir apli­ca­ções com vários con­ten­to­res de grande com­ple­xi­dade em ar­qui­te­tu­ras de cluster em qualquer sistema, como, por exemplo, um com­pu­ta­dor portátil.

Com o re­po­si­tó­rio público de modelos, a Panamax dis­po­ni­bi­liza aos uti­li­za­do­res no GitHub uma bi­bli­o­teca gratuita de modelos com diversos recursos.

Drone

O Drone é uma pla­ta­forma de in­te­gra­ção contínua leve e pouco exigente. Com esta fer­ra­menta Docker, pode carregar au­to­ma­ti­ca­mente a versão mais recente a partir de um re­po­si­tó­rio Git, como o GitHub, e executá-la em con­ten­to­res Docker isolados para realizar testes. O uti­li­za­dor tem a pos­si­bi­li­dade de executar qualquer conjunto de testes e programar o envio de re­la­tó­rios e no­ti­fi­ca­ções de estado para o seu e-mail. Para cada teste de software, é gerado um novo contentor baseado numa imagem do re­po­si­tó­rio público do Docker, de modo que qualquer imagem do Docker dis­po­ní­vel pu­bli­ca­mente pode ser utilizada como ambiente para o código que se pretende testar.

O Drone está integrado no Docker e suporta várias lin­gua­gens de pro­gra­ma­ção, como PHP, Node.js, Ruby, Go ou Python. A única de­pen­dên­cia ne­ces­sá­ria é, pre­ci­sa­mente, a pla­ta­forma de con­ten­to­res. Isto significa que, para criar uma pla­ta­forma de in­te­gra­ção contínua com o Drone, é ne­ces­sá­rio fazê-lo num sistema no qual o Docker esteja instalado. O Drone suporta vários re­po­si­tó­rios de controlo de versões. Na do­cu­men­ta­ção do projeto encontra-se um manual com o nome readme.drone.io para a ins­ta­la­ção padrão com in­te­gra­ção do GitHub.

Para gerir a pla­ta­forma de CI, utiliza-se uma interface web através da qual se carregam as com­pi­la­ções de software a partir de qualquer re­po­si­tó­rio Git, se agrupam as apli­ca­ções e se executa o resultado num ambiente de testes pre­vi­a­mente definido. Para tal, para cada teste é definido um ficheiro .drone.yml no qual se es­pe­ci­fica como a aplicação deve ser criada e executada.

Com o Drone, os uti­li­za­do­res têm à sua dis­po­si­ção uma solução de CI de código aberto que combina as vantagens de produtos al­ter­na­ti­vos, como o Travis e o Jenkins, numa aplicação simples e intuitiva.

OpenStack

Quando se trata de construir e gerir in­fra­es­tru­tu­ras na nuvem baseadas em código aberto, o sistema operativo na nuvem OpenStack é a solução de software ideal. O OpenStack permite gerir os recursos de com­pu­ta­ção, memória e rede de um centro de dados a partir de um painel de controlo central e dis­po­ni­bi­lizá-los aos uti­li­za­do­res através de uma interface web.

Este sistema operativo baseia-se numa ar­qui­te­tura modular composta por vários elementos:

• Zun (Serviço de con­ten­to­res): O Zun é o serviço de con­ten­to­res do OpenStack que permite im­ple­men­tar e gerir fa­cil­mente apli­ca­ções em con­ten­to­res na nuvem OpenStack. O objetivo do Zun é permitir que os uti­li­za­do­res gerem con­ten­to­res através de uma API REST sem ne­ces­si­dade de gerir ser­vi­do­res ou clusters. O Zun necessita de outros três serviços OpenStack para funcionar: Keystone, Neutron e kuryr-lib­network. Op­ci­o­nal­mente, é possível ampliar a fun­ci­o­na­li­dade do Zun com outros serviços do OpenStack, como o Cinder e o Glance.
• Neutron (com­po­nen­tes de rede): O Neutron (an­te­ri­or­mente Quantum) é um com­po­nente do sistema baseado numa API portátil e escalável que se ocupa do controlo da rede. Este módulo fornece uma interface para to­po­lo­gias de rede complexas e suporta diversas extensões que permitem integrar funções de rede avançadas.
• kuryr-lib­network (con­tro­la­dor no Docker): o kuryr-lib­network é um con­tro­la­dor do Docker que atua como interface entre o Docker e o Neutron.
• Keystone (serviço de iden­ti­fi­ca­ção): com o Keystone, os uti­li­za­do­res do OpenStack dispõem de um serviço central de iden­ti­dade que funciona como sistema de au­ten­ti­ca­ção e gestão de direitos entre cada um dos com­po­nen­tes do OpenStack. Qualquer acesso a projetos na nuvem é regulado através dos chamados tenants (mandantes), cada um dos quais re­pre­senta uma unidade de uti­li­za­dor. Para cada unidade de uti­li­za­dor, podem ser definidos vários acessos com direitos di­fe­ren­ci­a­dos.
• Cinder (sistema de ar­ma­ze­na­mento em blocos): este é o nome dado a um com­po­nente da ar­qui­te­tura OpenStack que fornece memórias em blocos para o fun­ci­o­na­mento de máquinas virtuais. Este módulo fornece memórias virtuais através de uma API Self Service. Com ela, os uti­li­za­do­res podem solicitar recursos de memória sem poderem ver em que dis­po­si­tivo essa memória é instalada.
• Glance: com este serviço, o OpenStack permite armazenar e recuperar imagens de máquinas virtuais.

Para mais in­for­ma­ções sobre os com­po­nen­tes e serviços do OpenStack, consulte o nosso artigo sobre o OpenStack. Além dos com­po­nen­tes listados, a ar­qui­te­tura do OpenStack pode ser ampliada com vários módulos opcionais. Pode encontrar mais in­for­ma­ções no site do OpenStack.

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 (an­te­ri­or­mente Me­sosphere) para a gestão de sistemas dis­tri­buí­dos. O projeto tem como base o gestor de clusters de código aberto Apache Mesos e foi concebido como um sistema operativo para centros de dados. O código-fonte do DC/OS está dis­po­ní­vel no GitHub sob uma licença Apache Versão 2 e, em d2iq.com, os seus de­sen­vol­ve­do­res co­mer­ci­a­li­zam uma versão En­ter­prise do software. Em dcos.io, pode consultar-se a do­cu­men­ta­ção detalhada do projeto.

O DC/OS pode ser con­si­de­rado uma espécie de dis­tri­bui­ção do Mesos que, através de uma interface central, dis­po­ni­bi­liza ao uti­li­za­dor todas as fun­ci­o­na­li­da­des do gestor de clusters e as amplia con­si­de­ra­vel­mente.

O DC/OS utiliza o kernel dis­tri­buído do Mesos. Isto permite agrupar os recursos de todo um centro de dados e geri-los como um único servidor lógico, sob a forma de um sistema agregado. É assim que se podem coordenar conjuntos inteiros de máquinas físicas ou virtuais com a mesma fa­ci­li­dade com que se utiliza um único com­pu­ta­dor.

O software sim­pli­fica a ins­ta­la­ção e a gestão de apli­ca­ções dis­tri­buí­das e au­to­ma­tiza a gestão de recursos, a dis­tri­bui­ção de tarefas e a co­mu­ni­ca­ção entre processos, entre outras funções. Tanto os clusters baseados no D2iQ DC/OS como todos os serviços exe­cu­ta­dos neles são geridos de forma cen­tra­li­zada através de uma interface de linha de comandos (CLI) ou de uma interface web (GUI).

O DC/OS abstrai os recursos do cluster e fornece serviços comuns, como a des­co­berta de serviços ou a gestão de pacotes. Os com­po­nen­tes centrais do software são exe­cu­ta­dos num espaço protegido, o espaço do Kernel, ao qual pertencem os programas mestre e agente da pla­ta­forma Mesos, res­pon­sá­veis pela clas­si­fi­ca­ção de recursos, pelo iso­la­mento de processos e pelas funções de segurança.

• Mesos Master: trata-se de um processo mestre que é executado num nó mestre de um cluster e é res­pon­sá­vel pela gestão de recursos e pela co­or­de­na­ção de tarefas (unidades de trabalho abstratas) exe­cu­ta­das num nó agente. Para tal, o Mesos Master distribui os recursos entre os serviços DC/OS e recebe os re­la­tó­rios de recursos dos agentes Mesos.
• Agentes Mesos: os agentes Mesos são processos escravos que são exe­cu­ta­dos em nós de agente e são res­pon­sá­veis pela execução das tarefas dis­tri­buí­das pelo mestre. Estes agentes enviam pe­ri­o­di­ca­mente ao mestre re­la­tó­rios sobre os recursos dis­po­ní­veis no cluster, que o mestre envia a um planeador ou scheduler (Marathon, Chronos ou Cassandra). Este decide qual a tarefa que será executada em cada nó. As tarefas são isoladas e exe­cu­ta­das num contentor.

Os restantes com­po­nen­tes do sistema, bem como as apli­ca­ções exe­cu­ta­das pelos agentes Mesos através do executor, funcionam no Espaço do Uti­li­za­dor. Entre os com­po­nen­tes básicos de uma ins­ta­la­ção padrão do DC/OS contam-se o Admin Router, o DNS do Mesos, um proxy DNS dis­tri­buído, o ba­lan­ce­a­dor de carga Minuteman, o agendador Marathon, o Apache ZooKeeper e o Exhibitor. Apre­sen­ta­mos-os em pormenor a seguir:

• Admin Router: trata-se de um servidor web baseado em NGINX e con­fi­gu­rado de forma es­pe­cí­fica, que fornece tanto serviços DC/OS como funções centrais de ve­ri­fi­ca­ção e proxy.
• Mesos DNS: este com­po­nente inclui fun­ci­o­na­li­da­des de Service Discovery que permitem que todos os serviços e apli­ca­ções no cluster se iden­ti­fi­quem mu­tu­a­mente através de um Domain Name System (DNS) central.
• Proxy DNS Dis­tri­buído: trata-se de um dis­tri­bui­dor (dis­pat­cher) DNS interno.
• Minuteman: este com­po­nente atua como um ba­lan­ce­a­dor de carga interno que opera na camada de trans­porte (camada 4) do modelo de re­fe­rên­cia OSI.
• DC/OS Marathon: este é um com­po­nente central da pla­ta­forma Mesos com funções de init-System (se­me­lhante ao systemd) no D2iQ DC/OS. O Marathon inicia e su­per­vi­si­ona serviços DC/OS e apli­ca­ções em ambientes de cluster, ofe­re­cendo, além disso, funções de alta dis­po­ni­bi­li­dade, Service Discovery, ba­lan­ce­a­mento de carga, ve­ri­fi­ca­ções de in­te­gri­dade e uma interface web gráfica.
• Exhibitor: graças a este com­po­nente, o Zookeeper pode ser instalado e con­fi­gu­rado au­to­ma­ti­ca­mente em cada nó mestre de um cluster. O Exhibitor inclui ainda uma interface gráfica de uti­li­za­dor para os uti­li­za­do­res do Zookeeper.

Nos recursos do cluster agregados com o DC/OS, é possível executar várias tarefas em si­mul­tâ­neo, de modo que o sistema operativo do cluster permite, por exemplo, o fun­ci­o­na­mento em paralelo de sistemas de Big Data, mi­cros­ser­vi­ços ou pla­ta­for­mas de con­ten­to­res como o Hadoop, o Spark e o Docker.

O D2iQ Universe dis­po­ni­bi­liza um catálogo público de apli­ca­ções para o DC/OS, através do qual é possível instalar apli­ca­ções como o Spark, o Cassandra, o Chronos, o Jenkins ou o Kafka com grande fa­ci­li­dade através da interface de uti­li­za­dor.

Fer­ra­men­tas do Docker para a segurança

Embora os processos isolados em con­ten­to­res sejam exe­cu­ta­dos no mesmo kernel, o Docker utiliza uma série de técnicas de iso­la­mento para os proteger uns dos outros. Em par­ti­cu­lar, são uti­li­za­das fun­ci­o­na­li­da­des centrais do kernel do Linux, como Cgroups e Na­mes­pa­ces. Por isso, os con­ten­to­res não oferecem o mesmo nível de iso­la­mento que o que se consegue com máquinas virtuais.

Apesar das técnicas de iso­la­mento descritas, a partir dos con­ten­to­res é possível aceder a im­por­tan­tes sistemas se­cun­dá­rios do kernel, como os Cgroups ou as in­ter­fa­ces do kernel nos di­re­tó­rios /sys e /proc.

A equipa de de­sen­vol­vi­mento por trás do Docker também está ciente destes problemas de segurança, con­si­de­rando-os um obstáculo à con­so­li­da­ção desta tec­no­lo­gia em sistemas de produção. A par das técnicas fun­da­men­tais de iso­la­mento do kernel do Linux, as versões mais recentes do Docker Engine suportam, con­se­quen­te­mente, as es­tru­tu­ras AppArmor, SELinux e Seccomp, que fun­ci­o­na­riam como uma espécie de firewall para os recursos do kernel:

• AppArmor: permite controlar os direitos de acesso dos con­ten­to­res ao sistema de ficheiros.
• SELinux: apresenta um sistema complexo de regras com o qual é possível im­ple­men­tar controlos de acesso aos recursos do kernel.
• Seccomp: (Secure Computing Mode) su­per­vi­si­ona as chamadas de system calls.

Para além destas fer­ra­men­tas do Docker, o Docker também utiliza as chamadas «ca­pa­bi­li­ties» do Linux, que permitem limitar os direitos de root com que o Docker Engine inicia os con­ten­to­res.

Algumas vul­ne­ra­bi­li­da­des de software presentes em com­po­nen­tes das apli­ca­ções que se propagam através do registo do Docker também são motivo de pre­o­cu­pa­ção. Em princípio, não há res­tri­ções quanto à criação e pu­bli­ca­ção de imagens no Docker Hub, e é isso que acarreta o risco de in­tro­du­zir código malicioso num sistema através do download de uma imagem. Por isso, antes da im­ple­men­ta­ção de uma aplicação, os uti­li­za­do­res do Docker devem sempre cer­ti­fi­car-se de que o código completo fornecido por uma imagem para executar con­ten­to­res provém de uma fonte fiável.

A Docker oferece um programa de cer­ti­fi­ca­ção que permite avaliar e cer­ti­fi­car for­ne­ce­do­res de in­fra­es­tru­tu­ras, con­ten­to­res e extensões. Com este programa de cer­ti­fi­ca­ção, a Docker pretende facilitar aos pro­gra­ma­do­res a criação de cadeias de abas­te­ci­mento de software seguras para os seus projetos.

Para além de aumentar a segurança dos uti­li­za­do­res, os cer­ti­fi­ca­dos do Docker pretendem oferecer aos pro­gra­ma­do­res a pos­si­bi­li­dade de destacar os seus projetos entre os inúmeros recursos dis­po­ní­veis. Entre outros aspetos, as imagens cer­ti­fi­ca­das obtêm melhores clas­si­fi­ca­ções nos re­sul­ta­dos de pesquisa do Docker Hub e são iden­ti­fi­ca­das com o selo*«Verified Publisher*».