Docker tools: Ferramentas Docker

O vasto ecossistema Docker oferece a desenvolvedores inúmeras opções de deployment de aplicações, orquestração de contêineres, entre outros. Com o nosso guia de Docker tools, você conhecerá as ferramentas Docker mais importantes, assim como os projetos de código aberto mais interessantes.

Hospedagem web com consultor pessoal

Rápido e escalável, confie na hospedagem da IONOS, que inclui domínio grátis no primeiro ano e endereço de e-mail!

  • Domínio
  • SSL Wildcard
  • Suporte 24 horas

Docker tools oficiais e essenciais

Atualmente, o Docker é muito mais do que uma simples plataforma de operação de contêineres de software. Ao longo do tempo, sua equipe de desenvolvimento foi expandindo diversas ferramentas Docker (Docker tools) com o objetivo de tornar deployments de aplicações em infraestruturas distribuídas e em ambientes de nuvem mais fáceis, rápidas e flexíveis. Além de funções de cluster e orquestração, Docker toos oferecem a seus usuários um marketplace de aplicativos centralizado, assim como uma ferramenta de gerenciamento 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 plataforma de contêineres é baseada. Oficialmente, esta leva o nome de Docker Engine e tem como componentes 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 contêineres Docker podem ser gerenciados diretamente do terminal. Da mesma forma, cliente edaemon podem localizar-se em sistema diferentes.

Conheça os principais comandos Docker explorando nosso artigo especializado.

schematic-representation-of-the-docker-engine.png
Componentes básicos do Docker Engine: daemon, API REST e CLI

Docker Hub

O projeto de código aberto Docker Hub disponibiliza a seus usuários um registro baseado em nuvem, que pode ser utilizado para baixar imagens Docker, gerenciá-las centralmente e compartilhá-las com outros usuários. Quem tem registro na plataforma também pode armazenar imagens Docker, tanto publicamente quanto em repositórios privados. Mecanismo integrado de tagging permite o controle de versões.

Além de repositórios públicos de outros usuários, no Docker Hub você pode encontrar recursos desenvolvidos pela própria equipe do Docker, assim como por conhecidos projetos open source. Estes ficam disponí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 ferramentas Unix BusyBox e a distribuição Linux Ubuntu.

docker-hub-repositories.png
No repositório do Docker Hub, você pode encontrar mais de 100 mil imagens Docker gratuitas para a sua instalação

Organizações fazem parte dos recursos do Docker Hub. Elas nada mais são que grupos de trabalho privados, que só aceitam determinados usuários. Em uma organização, autorizações de acesso são gerenciadas por equipes e associações.

Docker Swarm

O Docker Engine contém funções nativas que permitem que usuários façam o gerenciamento de Docker hosts em clusters(swarms). Tais funções de gerenciamento e orquestração declusters, integradas ao Docker Engine, baseiam-se no conjunto de ferramentas Swarmkit.

Nota

Clusters são Docker hosts (em qualquer número) hospedados na infraestrutura de um provedor externo de IaaS ou em um centro de dados próprio.

A ferramenta de cluster nativa do Docker, Swarm, usa a API REST do Docker e combina grupos de Docker hosts em uma única hospedagem virtual, o que permite que qualquer ferramenta Docker conectada ao daemon acesse o Swarm e faça escalonamentos em qualquer quantidade de Docker hosts. Usuários utilizam a interface de linha de comando Docker Engine para criar swarms, fazer deployments em aplicações no cluster e controlar o comportamento do Swarm. Orquestração adicional não é requerida pelo software.

Docker Engines mesclados a clusters são executados pelo modo swarm. Ative-o para criar um novo cluster ou para adicionar um Dockerhosta umswarmjá existente. Individualmente, Dockerhostsde umclustersão chamados de nós. Nós de umclusterpodem ser executados comohostsvirtuais no mesmo sistema local, mas é mais comum que estruturas baseadas em nuvem sejam utilizadas. Nelas, nós individuais de Dockerswarms são distribuídos a diferentes sistemas e infraestruturas.

O Docker Swarm é baseado na arquitetura mestre-escravo. Assim, quando serviços têm de ser distribuídas aos swarms, usuários devem repassar a responsabilidade a um nó gerenciador, que atuará como mestre do cluster. Como mestre, ele se ocupará da programação dos contêineres no clustere funcionará como principal interface de usuário para se acessar recursos do Swarm. Um nó gerenciador envia unidades de trabalho individuais (tarefas) a seus escravos subordinados, chamados deworker nodes pela terminologia Docker.

  • Serviços: Constituem a estrutura central dos clusters Docker. Um serviço é um grupo de contêineres baseados na mesma imagem, que define as tarefas a serem executadas no cluster. Ao criarem serviços, usuários especificam as imagens a serem utilizadas e os comandos que devem ser aplicados. Serviços também possibilitam o dimensionamento das aplicações: usuários Docker podem definir, com facilidade, quantos contêineres devem ser iniciados por um serviço.
  • Tarefas: Antes de serem distribuídos no cluster, serviços são divididos em unidades de trabalho individuais (tarefas) pelo nó gerenciador. Cada tarefa inclui um contêiner Docker e os comandos a serem executados.

Além das funções de controlar clusters e de orquestrar contêineres, nós gerenciadores também podem funcionar como meros worker nodes, a não ser que você restrinja as atribuições do nó mestre, o limitando ao gerenciamento.

Em cada worker node é executado um programa agente, que aceita tarefas e fornece, ao respectivo nó mestre, relatórios de status atualizados. O gráfico abaixo ilustra processos no Docker Swarm:

schematic-representation-of-a-docker-swarm.png
Arquitetura mestre-escravo de um Docker Swarm

Docker Compose

O Docker Compose possibilita a vinculação de contêineres, para que eles possam ser executados por um único comando. Seu elemento fundamental é um arquivo de controle central baseado na linguagem de marcação YAML. A sintaxe deste arquivo é semelhante à do software de código aberto Vagrant, usado para criar e provisionar máquinas virtuais.

O arquivo docker-compose.yml permite a definição qualquer número de contêineres de software, incluindo todas as dependências e relações. Aplicações com múltiplos contêineres são controladas da mesma forma que contêineres de software individuais. Use o comando docker-compose em combinação com o subcomando desejado para gerenciar o ciclo de vida de cada aplicação.

Essa ferramenta Docker pode ser facilmente integrada a um cluster baseado em Swarm. A integração contribui para a execução de múltiplos contêineres criados pelo Compose, pois executa-os, com a mesma facilidade, em sistemas distribuídos ou em um Docker host único.

Outro interessante recurso do Docker Compose é seu mecanismo de escalonamento. Com esta ferramenta de orquestração, você pode usar o terminal para determinar, de forma conveniente, quantos contêineres deseja inicializar para a execução de um serviço específico.

Docker tools de terceiros

Além de ferramentas desenvolvidas pela própria Docker Inc., diversos fornecedores externos oferecem complementos à plataforma de contêineres, assim como interfaces para o Docker Engine. Entre os projetos open sourcemais populares dentro do ecossistema Docker estão a ferramenta de orquestração Kubernetes, a ferramenta de gerenciamento declustersShipyard, a solução de envio de múltiplos contêineres Panamax, a plataforma de integração contínua Drone, o sistema operacional de nuvem OpenStack e o sistema operacional de centros de dados D2iQ DC/OS, baseado no gerenciador declusters Mesos.

Kubernetes

Nem sempre o Docker dispôs de Docker tools de orquestração próprias, como o Swarm e o Compose. Por esse motivo, diversas empresas investiram (e continuam investindo) tempo e dinheiro no desenvolvimento de ferramentas personalizadas para facilitar operações na plataforma de contêineres, principalmente em infraestruturas grandes e distribuídas. O Kubernetes está entre as soluções queridinhas.

Kubernetes é um gerenciador de clusters para aplicações baseadas em contêineres. Ele tem por objetivo automatizar aplicaçõ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 relatórios de status. Além das descritas acima, o Kubernetes promete realizar as seguintes funções:

  • Executar, em um cluster, aplicativos baseados em contêineres
  • Configurar e gerenciar aplicações em sistemas distribuídos
  • Dimensionar aplicações
  • Otimizar o uso do hardware

Para cumprir o que promete, o Kubernetes agrupa contêineres em partes lógicas, chamadas de Pods. Pods podem ser distribuídos no cluster por meio de agendamentos e representam a unidade básica deste gerenciador de clusters.

Como o Docker Swarm, o Kubernetes também é baseado numa arquitetura mestre-escravo. Assim sendo, cada cluster é composto de um mestre e do seu grande número de escravos, chamados kubernetes notes, workers ou minions. No Kubernetes, mestres são camadas de gerenciamento (control planes). Estas, por sua vez, são formadas por quatro componentes básicos: apiserver, etcd, scheduler e controller-manager. Juntos, eles permitem que o cluster seja controlado centralmente, assim como possibilita sua comunicação e a distribuição de tarefas.

  • kube-apiserver: Qualquer automatização em um cluster é acionada por API REST, no servidor de APIkube-apiserver. Ele atua como a interface de administração central docluster.
  • etcd: É a memória dosclustersKubernetes e consiste em um armazenamento de chave-valor de software livre. Desenvolvido pelo CoreOS especialmente para sistemas distribuídos, o banco de dados de chave-valor armazena os dados de uma configuração e os disponibiliza aos nós docluster. Gerencie o status docluster, a qualquer tempo, poretcd.
  • kube-scheduler: Responsável por distribuir grupos de contêineres (Pods) em umcluster. Para fazer isso, ele define requisitos de recursos de umPode os compara aos recursos disponibilizados por cada nó de umcluster.
  • kube-controller-manager: Controla o status de umclustere executa tarefas de rotina, ou seja, monitora a orquestração. A principal tarefa docontroller-manageré garantir que o estado docluster corresponda ao estado de destino definido.

Os componentes de um mestre Kubernetes podem localizar-se todos em um único host ou serem distribuídos a vários hosts mestres, em clusters de alta disponibilidade.

Embora, no Kubernetes, o mestre seja o responsável pela orquestração dos contêineres, Pods distribuídos no cluster são executados nos hosts escravos (kubernetes 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 Kubernetes não se destina a nenhuma plataforma de contêineres específica.

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

  • kubelet: Este agente é executado em cada nó do Kubernetes, para controlá-lo e gerenciá-lo. Como ponto de contato central de cadanode, okubeletconecta-se com o mestre, garantindo que informações sejam encaminhadas e recebidas pelo nível de controle.
  • kube-proxy: O proxy de redekube-proxytambém é executado em cada nó do Kubernetes, garantindo que solicitações externas sejam encaminhadas aos respectivos contêineres. Ainda, okube-proxy fornece aos usuários, serviços para aplicações baseadas em contêineres e de balanceamento de carga, apesar de rudimentares.

O gráfico abaixo mostra como a arquitetura mestre-escravo funciona na plataforma de orquestração de contêineres Kubernetes:

schematic-representation-of-the-kubernetes-architecture.png
Arquitetura mestre-escravo da plataforma de orquestração de contêineres Kubernetes

Além de seu projeto central, o Kubernetes disponibiliza numerosas extensões, que adicionam funções extras à plataforma de orquestração de contêineres. Entre as mais conhecidas estão as Docker tools de monitoramento e diagnóstico de erros Prometheus, Weave Scope e sysdig; o gerenciador de pacotes Helm; os plugins Apache Maven e Gradle; e uma API Java para controlar o Kubernetes remotamente.

Shipyard

O Shipyard é uma solução de gerenciamento baseada no Swarm que é desenvolvida pela própria comunidade de usuários Docker. Ela permite que recursos Docker, como contêineres, imagens, hosts e registros privados sejam gerenciados por interface gráfica de usuário web, que pode ser acessada pelo navegador. A interface é 100% compatí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 possibilitar o gerenciamento de clusters por interface web centralizada, o Shipyard inclui autenticação de usuários e controle de acessos baseado em atribuições.

Essa ferramenta Docker baseia-se no kit de ferramentas de gerenciamento de cluster Citadel, e é essencialmente formada por três componentes: pelo controlador, pela API e pela interface de usuário (UI).

  • Controller: É o componente principal do Shipyard. O controller interage com o RethinkDB no contexto do armazenamento de dados, permitindo que hosts individuais de um cluster Docker sejam endereçados e que eventos sejam controlados.
  • API: A API do Shipyard é baseada em REST. Ela controla todas as funções desta ferramenta de gerenciamento.
  • UI: A interface de usuário do Shipyard é uma aplicação AngularJS que possibilita que usuários gerenciem clusters Docker pelo navegador. Também na UI, todas as interações ocorrem por meio da API.

Encontre mais informações sobre este projeto open source no site oficial do Shipyard.

Panamax

A equipe de desenvolvimento da ferramenta para Docker Panamax tem como meta simplificar o deployment de aplicativos de múltiplos contêineres. Gratuita e de código aberto, ela disponibiliza a seus usuários uma interface gráfica que permite que aplicativos complexos baseados em contêineres sejam desenvolvidos, implantados e disribuídos de forma conveniente, por arrastar e soltar.

Com o Panamax, tornou-se possível salvar aplicativos complexos, de múltiplos contêineres, como modelos de aplicativos, assim como distribuí-los, com um único clique, em arquiteturas de clusters. Na sua loja hospedado no GitHub, modelos de aplicações criados por usuários podem ser salvos em repositórios Git e disponibilizados ao público.

Os componentes básicos da arquitetura do Panamax podem ser divididos em dois: cliente local e alvos de deployments remotos.

O cliente local é o componente central da ferramenta Panamax. Executado no sistema local, ele possibilita a criação de aplicações complexas baseadas em contêineres. Por sua vez, o cliente local subdivide-se nos seguintes elementos:

  • CoreOS: A instalação do cliente local requer a distribuição Linux CoreOS como sistema host, já que ela foi especialmente projetada para contêineres de software. No CoreOS, o Panamax é executado como contêiner Docker. Adicionalmente, o Panamax também disponibiliza outras funções de CoreOS, como Fleet e Journalctl:
    • Fleet Adapter: Em vez de interagir diretamente com o Docker, o cliente Panamax usa o gerenciador de cluster Fleet para orquestrar contêineres. Fleet é o gerenciador de clusters que controla o daemon Linux systemd em clusters de computadores.
    • Journalctl: É utilizado pelo cliente Panamax para recuperar mensagens do chamado journal, log do gerenciador de sistemas Linux systemd.
  • Local Client Installer: Contém todos os componentes necessários a instalaçã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 componentes e dependências, como com o Docker host local, a interface de usuário do Panamax, os registros externos e os agentes remotos nos alvos de deployment no cluster. No sistema local, o agente local também interage com as seguintes interfaces de programação, pela API, para trocar informações sobre as aplicações em execução:
    • Docker Remote API: Fazendo uso da API remota do Docker, o Panamax procura imagens no sistema local e recupera informações de status dos contêineres em execução.
    • etcd API: Dados do CoreOS Fleet são transmitidos ao daemon, por meio da API do etcd.
    • systemd-journal-gatewayd.services: Usado pelo Panamax para recuperar resultados do journal sobre os serviços em execução.

Para complementar, a API do Panamax também suporta interaçõ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 carregados em repositórios do GitHub por meio desta API.
  • API do KissMetrics: A API do KissMetrics coleta dados sobre templates executados por usuários.
  • UI do Panamax: Atua no sistema local, permitindo que usuários controlem a ferramenta por interface gráfica. Entradas inseridas por usuários são encaminhadas diretamente ao agente local por meio da API do Panamax. A UI do Panamax é baseada na CTL Base UI Kit, biblioteca de componentes de UI para projetos web CenturyLink.

O gráfico abaixo exemplifica a interação de componentes e elementos Panamax com clusters Docker:

schematic-representation-of-the-software-architecture-for-the-panamax-container-management-tool.PNG
Arquitetura de software da ferramenta de gerenciamento de contêineres Panamax

A ferramenta de gerenciamento de contêineres Panamax, baseada no CoreOS, oferece a seus usuários uma interface gráfica que comporta diferentes tecnologias-padrão de orquestração de contêineres. Ela é uma conveniente alternativa ao gerenciamento de aplicações complexas em múltiplos contêineres com arquiteturas de clusters, e pode ser utilizada por praticamente qualquer sistema (por exemplo, pelo seu laptop).

O Panamax também disponibiliza aos usuários um repositório público de templates, com diversos recursos, no GitHub.

Drone

Drone é uma plataforma de integração contínua leve, que exige requisitos mínimos. Com esta ferramenta, você pode carregar automaticamente a compilação mais recente de um repositório Git, como do GitHub, e executá-la em contêineres isolados, para fins de teste. É possível executar qualquer conjunto de testes e receber relató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 publicamente pode ser usada como ambiente para o código a ser testado.

Dica

Integração contínua (CI) é um processo de desenvolvimento no qual componentes de software recém-desenvolvidos (chamados builds) são montados em intervalos regulares e executados em ambientes de teste. CI constitui uma interessante estratégia para se reconhecer e eliminar erros de integração que podem ocorrer quando diferentes desenvolvedores trabalham juntos em estágios iniciais.

O Drone, que pode ser integrado ao Docker (presumidamente a única dependência obrigatória), oferece suporte a várias linguagens de programação, como ao PHP, Node.js, Ruby, Go e Python. Use o Drone para criar uma plataforma de integração contínua pessoal em qualquer sistema que suporta uma instalação Docker. Ele admite vários repositórios de controle de versão, o que é outra vantagem. Instruções sobre o processo de instalação padrão da ferramenta, com integração ao GitHub, podem ser encontradas no projeto open source readme.drone.io.

Essa ferramenta pode ser controlada por interface web. Utilize-a para carregar compilações de software de qualquer repositório Git, combiná-las em aplicações e executar resultados em ambientes de teste previamente definidos. Para cada teste de software, um arquivo drone.yml é criado. Nele, você deve especificar como a aplicação deve ser gerada e executada.

Em resumo, o Drone é de fácil utilização e oferece a seus usuários uma solução de CI de código aberto, que combina pontos fortes de produtos alternativos, como do Travis e do Jenkins.

OpenStack

O sistema operacional de nuvem OpenStack, de código aberto, é o preferido entre os que precisam configurar e operar estruturas de nuvem open source. Com esta ferramenta para Docker, recursos de computação, rede e armazenamento em centros de dados podem ser gerenciados por um painel central e disponibilizados a usuários finais por interface web.

Baseado em arquitetura modular, o OpenStack é composto por diferentes módulos. Entre os princpais estão:

  • Zun (serviço de contêineres): Ele possibilita deployments facilitados e o gerenciamento de aplicações em contêineres armazenados na nuvem do OpenStack. Com o Zun, usuários gerenciam contêineres por meio de uma API REST, o que os desobriga de gerenciar servidores e clusters. Para funcionar, este componente requer três outros serviços do OpenStack: Keystone, Neutron e kuryr-libnetwork. Amplie, opcionalmente, a funcionalidade do Zun, com outros serviços do OpenStack, como o Cinder e o Glance.
  • Neutron (componente de rede): O Neutron (antigo Quantum) é um componente de sistema portátil, dimensionável e que suporta API, usado para controle de rede. Ele disponibiliza uma interface para topologias de rede complexas e oferece suporte a vários plugins, que podem ser utilizados para integrar e estender funções de rede.
  • kuryr-libnetwork (driver do Docker): Atua como interface entre o Docker e o Neutron.
  • Keystone (serviço de identidade): Oferece a usuários do OpenStack um serviço de identificação centralizado, atuando como sistema de autenticação e autorização entre componentes individuais. O acesso a projetos na nuvem é regulado pelos chamados locatários — cada locatário representa uma unidade de usuário. Defina direitos de acesso para cada unidade de usuário.
  • Cinder (armazenamento de blocos): Módulo da arquitetura OpenStack que fornece armazenamento em blocos persistente, para a operação de máquinas virtuais. O armazenamento, em memória virtual, é feito por meio de uma API de autoatendimento, que não exige que usuários finais saibam onde o armazenamento está sendo implantado e/ou em que tipo de dispositivo.
  • Glance (serviço de imagem): O módulo Glance pode ser usado para armazenar e recuperar imagens de máquinas virtuais.

Obtenha mais informações sobre componentes e serviços oferecidos pelo OpenStack no nosso artigo especializado. Ainda, é possível expandir a arquitetura do OpenStack com outros módulos, que não foram aqui apresentados. O site oficial do OpenStack tem a lista completa.

D2iQ DC/OS

O DC/OS (Distributed Cloud Operating System) é um software de código aberto desenvolvido pela D2iQ Inc. (antiga Mesosphere), para a operação de sistemas distribuídos. O projeto, um sistema operacional para centros de dados, é baseado no gerenciador de clusters, também open source, Apache Mesos. Assim sendo, esta ferramenta para Docker pode ser considerada um tipo de distribuição ampliada do Mesos, já que disponibiliza todas as funções do Cluster Manager por uma interface de usuário centralizada.

O código-fonte do DC/OS, que pode ser encontrado no GitHub, é liberado aos usuários sob a licença Apache 2.0. Uma versão corporativa do DC/OS também é comercializada por seus desenvolvedores. Explore a documentações do DC/OS.

O DC/OS utiliza o núcleo do sistema distribuído da plataforma Mesos, o que possibilita o agrupamento de recursos completos de um banco de dados, assim como gerenciamento semelhante ao de um sistema agregado de servidor lógico único. Com a ferramenta, você poderá controlar clusters inteiros, de máquinas físicas ou virtuais, com a mesma facilidade com que opera um simples computador.

O software, de instalação simples, também simplifica o gerenciamento de aplicações distribuídas e automatiza tarefas, como de gerenciamento de recursos, de agendamento e de comunicação entre processos. Por ter base no D2iQ DC/OS, um cluster, e todos os serviços nele executados, podem ser gerenciados centralizadamente pelo terminal ou por uma interface gráfica web.

A ferramenta DC/OS despreza recursos para clusters e fornece serviços compartilhados, como de descoberta de serviços e de gerenciamento de pacotes. Os principais componentes do software são executados em área protegida, chamada de espaço de núcleo (kernel). Ele inclui programas mestre e agente da plataforma Mesos, responsáveis pela alocação de recursos, pelo isolamento 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 gerenciamento de recursos e o orquestramento de tarefas (unidades de trabalho abstratas), executadas em um nó agente. Para tanto, mestres distribuem recursos entre os serviços DC/OS registrados. De volta, eles recebem relatórios sobre os recursos.
  • Mesos Agents: No Mesos, agentes são processos escravos que executam, em contas de agentes, tarefas distribuídas por um mestre. Ainda, eles fornecem relatórios a seus mestres, com regularidade, que tratam dos recursos disponíveis no cluster. Em posse dos relatórios, mestres os encaminham a um escalonador (Marathon, Chronos ou Cassandra, por exemplo), que decidirá qual tarefa será executada por cada nó. Tarefas podem ser executadas individualmente ou em um contêiner.

Todos os demais componentes e aplicações de agentes do Mesos são executados no espaço do usuário. Entre os componentes básicos de uma instalação DC/OS padrão estão Admin Router, Mesos DNS, Distributed DNS Proxy, Minuteman (balanceador de carga), Marathon (agendador), Apache ZooKeeper e Exhibitor.

  • Admin Router: Um roteador de administração nada mais é que um servidor web especialmente configurado para NGINX, que disponibiliza serviços DC/OS, bem como autenticações centralizadas e funções de proxy.
  • Mesos DNS: Este componente de sistema executa funções de descoberta de serviços, que permitem que serviços e aplicações individuais, em um cluster, identifiquem uns aos outros por meio de um sistema de nomes de domínio (DNS) central.
  • Distributed DNS Proxy: É o despachante (distribuidor) do DNS interno.
  • Minuteman: Atua como balanceador de carga interno, operando no nível de transporte (camada 4) do modelo OSI.
  • DC/OS Marathon: Componente central da plataforma Mesos. Atua como sistema de inicialização (semelhante ao systemd) no D2iQ DC/OS. Ele inicializa e monitora serviços e aplicações do DC/OS em ambientes de cluster, e também realiza funções de alta disponibilidade, descoberta de serviços, balanceamento de carga, verificações de integridade, além de oferecer uma interface gráfica web.
  • Apache ZooKeeper: É um componente de software de código aberto que desempenha funções de coordenação para a operação e o controle de aplicações em sistemas distribuídos. No D2iQ DC/OS, o ZooKeeper coordena todos os serviços instalados de sistema.
  • Exhibitor: É o componente do sistema que possibilita a instalação e a configuração automática do ZooKeeper em cada nó mestre de um cluster. Ele ainda disponibiliza uma interface gráfica aos usuários do ZooKeeper.

Cargas de trabalho múltiplas podem ser executadas simultaneamente em recursos de clusters agregados pelo DC/OS. Esta ferramenta para Docker permite, por exemplo, a operação paralela de sistemas de big data, de microsserviços e de plataformas de contêineres, como o Hadoop, o Spark e o próprio Docker.

No catálogo público de aplicações para DC/OS, D2iQ Universe, você encontra instruções para a instalação de outros sistemas, como Spark, Cassandra, Chronos, Jenkins e Kafka.

Docker tools para aumentar a segurança

Mesmo quando processos encapsulados são executados no mesmo núcleo de um contêiner, o Docker aplica uma série de técnicas de isolamento para protegê-los uns dos outros. Funções de núcleo do Linux, como cgroups e namespaces, são especialmente utilizadas para este fim. Mesmo assim, contêineres não conseguem oferecer o mesmo grau de isolamento de máquinas virtuais. Apesar dos esforços de isolamento acima descritos, importantes subsistemas do núcleo (como o Cgroups) e interfaces de núcleo presentes nos diretórios /sys e /proc, por exemplo, podem ser acessados por contêineres. A equipe de desenvolvimento do Docker reconhece que a vulnerabilidade de segurança põe freio a esta tecnologia de contêineres em sistemas de produção. Além de técnicas básicas de isolamento 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 configurar direitos de acesso de contêineres ao sistema de arquivos.
  • SELinux: Disponibiliza um complexo sistema de regras que possibilita a implementaçã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 ferramentas acima, o Docker utiliza Linux Capabilitiespara restringir direitosroot automaticamente definidos durante a inicialização de seus contêineres.

Outra vulnerabilidade de segurança do Docker diz respeito a componentes de aplicações de usuários disponí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 maliciosos que podem invadir e prejudicar o seu sistema. Por causa disso, recomendamos que você se certifique da origem da imagem Docker que deseja executar para implantar um aplicativo, verificando se a mesma é proveniente de uma fonte confiável.

O Docker Verified Publisher Program é o programa de certificação do Docker, que verifica a segurança de imagens fornecidas por terceiros, concedendo-lhes um certificado. Atestando a idoneidade de seus fornecedores, o Docker se esforça para oferecer cada vez mais segurança na disponibilização de softwares. Além de proteger usuários, o programa também é interessante para desenvolvedores, que têm maiores oportunidades de destaque ao possuírem o certificado de segurança Verified Publisher — imagens certificadas são mais bem classificadas pelos resultados de buscas realizadas no Docker Hub.

Este artigo foi útil?
Para melhorar a sua experiência, este site usa cookies. Ao acessar o nosso site, você concorda com nosso uso de cookies. Mais informações
Page top