# 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.

## 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 e*daemon* podem localizar-se em sistema diferentes.

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

[![Imagem: Representação gráfica do Docker Engine](https://www.ionos.com/pt-br/digitalguide/fileadmin/_processed_/b/1/csm_schematic-representation-of-the-docker-engine_b1d06acafa.webp "Representação gráfica do Docker Engine")](https://www.ionos.com/pt-br/digitalguide/fileadmin/DigitalGuide/Schaubilder/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.

[![Imagem: Repositório oficial do Docker Hub](https://www.ionos.com/pt-br/digitalguide/fileadmin/_processed_/1/7/csm_docker-hub-repositories_857d775687.webp "Repositório oficial do Docker Hub")](https://www.ionos.com/pt-br/digitalguide/fileadmin/DigitalGuide/Screenshots_2023/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 de*clusters*, integradas ao Docker Engine, baseiam-se no conjunto de ferramentas [Swarmkit](https://github.com/moby/swarmkit "Conjunto de ferramentas Swarmkit — guithub.com").

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 Docker*host*a um*swarm*já existente. Individualmente, Docker*hosts*de um*cluster*são chamados de nós. Nós de um*cluster*podem ser executados como*hosts*virtuais no mesmo sistema local, mas é mais comum que estruturas baseadas em nuvem sejam utilizadas. Nelas, nós individuais de Docker*swarms* 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 *cluster***e 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 de*worker 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:

[![Imagem: Representação gráfica do Docker Swarm](https://www.ionos.com/pt-br/digitalguide/fileadmin/_processed_/5/8/csm_schematic-representation-of-a-docker-swarm_35226c9b62.webp "Representação gráfica do Docker Swarm")](https://www.ionos.com/pt-br/digitalguide/fileadmin/DigitalGuide/Schaubilder/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 source***mais populares dentro do ecossistema Docker estão a ferramenta de orquestração Kubernetes, a ferramenta de gerenciamento de*clusters*Shipyard, 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 de*clusters* 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](https://www.ionos.com/pt-br/digitalguide/servidor/conhecimento/o-que-e-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 API*kube-apiserver*. Ele atua como a interface de administração central do*cluster*.
- **etcd:** É a memória dos*clusters*Kubernetes 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 do*cluster*. Gerencie o status do*cluster*, a qualquer tempo, por*etcd*.
- **kube-scheduler:** Responsável por distribuir grupos de contêineres (*Pods*) em um*cluster*. Para fazer isso, ele define requisitos de recursos de um*Pod*e os compara aos recursos disponibilizados por cada nó de um*cluster*.
- **kube-controller-manager:** Controla o status de um*cluster*e executa tarefas de rotina, ou seja, monitora a orquestração. A principal tarefa do*controller-manager*é garantir que o estado do*cluster* 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 cada*node*, o*kubelet*conecta-se com o mestre, garantindo que informações sejam encaminhadas e recebidas pelo nível de controle.
- **kube-proxy:** O proxy de rede*kube-proxy*também é executado em cada nó do Kubernetes, garantindo que solicitações externas sejam encaminhadas aos respectivos contêineres. Ainda, o*kube-proxy* fornece aos usuários, serviços para aplicações baseadas em contêineres e de [balanceamento de carga](https://www.ionos.com/pt-br/digitalguide/servidor/conhecimento/melhorar-tempos-de-acesso-ao-servidor-com-load-balancers/ "Balanceamento de carga em servidores"), apesar de rudimentares.

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

[![Imagem: Representação gráfica da arquitetura do Kubernetes](https://www.ionos.com/pt-br/digitalguide/fileadmin/_processed_/4/b/csm_schematic-representation-of-the-kubernetes-architecture_b06c1dc6c7.webp "Representação gráfica da arquitetura do Kubernetes")](https://www.ionos.com/pt-br/digitalguide/fileadmin/DigitalGuide/Schaubilder/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](https://prometheus.io/ "Prometheus: De métricas a insights — prometheus.io"), [Weave Scope](https://www.weave.works/products/weave-scope/ "Automação GitOps para Kubernetes stacks — weave.works") e [sysdig](http://www.sysdig.org/ "sysdig: Seguro a cada segundo — sysdig.org"); o gerenciador de pacotes [Helm](https://helm.sh/pt/ "O gerenciador de pacotes para Kubernetes — helm.sh"); os plugins [Apache Maven](https://maven.apache.org/ "Projeto Apache Maven — maven.apache.org") e [Gradle](https://gradle.org/ "Acelere o desenvolvimento da produtividade — gradle.org"); 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](https://www.ionos.com/pt-br/digitalguide/hospedagem/tecnologia-de-hospedagem/nosql/ "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](https://shipyard-project.com/ "Shipyard: Composable Docker Manager — shipyard-project.com").

### Panamax

A equipe de desenvolvimento da ferramenta para Docker [Panamax](https://github.com/CenturyLinkLabs/panamax-ui/wiki "Panamax UI — github.com") 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:

[![Imagem: Representação gráfica da arquitetura de software do Panamax, ferramenta de gerenciamento de contêineres](https://www.ionos.com/pt-br/digitalguide/fileadmin/_processed_/6/8/csm_schematic-representation-of-the-software-architecture-for-the-panamax-container-management-tool_8b61ba12b4.webp "Representação gráfica da arquitetura de software do Panamax, ferramenta de gerenciamento de contêineres")](https://www.ionos.com/pt-br/digitalguide/fileadmin/DigitalGuide/Schaubilder/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*](https://github.com/CenturyLinkLabs/panamax-public-templates "Templates públicas Panamax — github.com"), com diversos recursos, no GitHub.

### Drone

[Drone](https://github.com/drone "Drone by Harness — github.com") é 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](https://www.ionos.com/pt-br/digitalguide/sites-de-internet/criar-sites/aprenda-php-nosso-tutorial-abrangente-sobre-php-para-iniciantes/), Node.js, Ruby, Go e [Python](https://www.ionos.com/pt-br/digitalguide/sites-de-internet/desenvolvimento-web/aprender-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*](http://readme.drone.io/ "Documentação do projeto Drone by Harness — 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](https://travis-ci.org/ "Travis CI — travis-ci.org") e do [Jenkins](https://jenkins.io/index.html "Jenkins — jenkins.io").

### 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](https://www.openstack.org/software/project-navigator/openstack-components#openstack-services "Componentes e serviços OpenStack — openstack.org") 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](https://github.com/dcos "Repositórios DC/OS — github.com"), que pode ser encontrado no GitHub, é liberado aos usuários sob a licença Apache 2.0. Uma [**versão corporativa** do DC/OS](https://d2iq.com/ "Gerenciamento de Kubernetes — d2iq.com") também é comercializada por seus desenvolvedores. Explore a [documentações do DC/OS](https://archive-docs.d2iq.com/?l=en "Arquivo de documentação D2iQ — dcos.io").

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](https://zookeeper.apache.org/ "Apache Zookeeper — zookeeper.apache.org"):** É 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](https://www.ionos.com/pt-br/digitalguide/marketing-online/analise-web/o-que-e-big-data/), de microsserviços e de plataformas de contêineres, como o Hadoop, o [Spark](https://www.ionos.com/pt-br/digitalguide/servidor/conhecimento/o-que-e-o-apache-spark/ "O que é Apache Spark e como ele funciona") 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 Capabilities***para restringir direitos*root* 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](https://docs.docker.com/trusted-content/dvp-program/ "Docker Verified Publisher Program — docs.docker") é 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.


This is a markdown version of: [https://www.ionos.com/pt-br/digitalguide/servidor/conhecimento/docker-tools-principais-ferramentas-docker/](https://www.ionos.com/pt-br/digitalguide/servidor/conhecimento/docker-tools-principais-ferramentas-docker/) for AI/LLM consumption.