Caso você esteja planejando iniciar sua carreira em DevOps (ou mesmo se já estiver nela), se você já não tem o Docker em seu currículo, sem dúvida é hora de pensar nele, pois é uma das habilidades fundamentais para qualquer um que esteja na área de DevOps.

Neste artigo, vou tentar explicar o Docker da maneira mais simples possível.

Antes de examinarmos o assunto com mais profundidade e de começarmos a explorar o Docker, vamos dar uma olhada nos tópicos que cobriremos como parte deste guia para iniciantes.

• O que é o Docker?
• O problema que o Docker soluciona
• Vantagens e Desvantagens de usar Docker
• Componentes principais do Docker
• Terminologia do Docker
• O que é Docker Hub?
• Docker Editions
• Instalando o Docker
• Alguns comandos essenciais do Docker para começar
• Conclusão

Vamos começar entendendo: o que é Docker?

Em termos simples, o Docker é uma plataforma de software que simplifica o processo de criação, execução, gerenciamento e distribuição de aplicações. Ele faz isso virtualizando o sistema operacional do computador no qual ele está instalado e rodando.

A primeira edição do Docker foi lançada em 2013.

O Docker é desenvolvido usando a linguagem de programação GO.

Tendo em conta o rico conjunto de funcionalidades que o Docker tem para oferecer, ele tem sido amplamente utilizado para executar e gerir as aplicações de algumas das principais organizações e universidades do mundo, como a Visa, PayPal, Universidade de Cornell e Universidade de Indiana (só para citar algumas).

Agora vamos tentar entender o problema e a solução que o Docker pode oferecer.

O problema

Digamos que você tem três aplicações diferentes baseadas em Python que planeja hospedar em um único servidor (que pode ser uma máquina física ou virtual).

Cada uma dessas aplicações utiliza uma versão diferente do Python, assim como as bibliotecas e dependências associadas, que diferem de uma aplicação para outra.

Por não podermos ter diferentes versões do Python instaladas na mesma máquina, não conseguimos hospedar as três aplicações no mesmo computador.

A solução

Vamos ver sugestões para resolver esse problema sem usar o Docker. Nesse cenário, poderíamos usar três máquinas físicas, ou somente uma única máquina física poderosa o bastante para hospedar e executar três máquinas virtuais nela.

Ambas as opções nos permitiriam instalar diferentes versões do Python em cada uma dessas máquinas, juntamente com suas dependências associadas.

Independentemente da solução que escolhermos, os custos associados à aquisição e manutenção do hardware são bastante caros.

Agora, vamos ver como o Docker pode ser uma solução eficiente e econômica para esse problema.

Para entender isso, precisamos analisar exatamente como o Docker funciona.

A máquina na qual o Docker está instalado e em execução é geralmente chamada de Docker Host ou Host em termos simples.

Então, quando você planeja implantar uma aplicação no host, ele cria uma entidade lógica para hospedar essa aplicação. Na terminologia do Docker, chamamos essa entidade lógica de container ou Docker Container, para ser mais preciso.

Um Docker Container, ou contêiner do Docker (em português), não tem nenhum sistema operacional instalado e em execução nele. Ele, no entanto, tem uma cópia virtual da tabela de processos, da(s) interface(s) de rede e do(s) ponto(s) de montagem do sistema de arquivos. Tudo isso foi herdado do sistema operacional do host no qual o contêiner está hospedado e em execução.

Enquanto isso, o kernel do sistema operacional do host é partilhado por todos os contêineres que estão rodando nele.

Isso permite que cada contêiner seja isolado dos outros no mesmo host. Sendo assim, vários contêineres com diferentes requisitos e dependências de aplicações podem ser executados no mesmo host, desde que tenham os mesmos requisitos de sistema operacional.

Para entender como o Docker tem sido benéfico na resolução desse problema, é necessário consultar a próxima seção, que discute as vantagens e desvantagens da utilização do Docker.

Em resumo, o Docker virtualiza o sistema operacional do host no qual está instalado e em execução em vez de virtualizar os componentes de hardware.

Vantagens e desvantagens do uso do Docker

Vantagens do uso do Docker

Alguns dos principais benefícios do uso do Docker são:

• O Docker suporta várias aplicações com diferentes requisitos e dependências, a serem hospedadas em conjunto no mesmo host, desde que tenham os mesmos requisitos de sistema operacional.
• Armazenamento otimizado: um grande número de aplicações pode ser alojado no mesmo host, uma vez que os contêineres têm normalmente poucos megabytes de tamanho e consomem muito pouco espaço em disco.
• Robustez: um contêiner não tem um sistema operacional instalado. Assim, consome muito pouca memória em comparação com uma máquina virtual (que teria um sistema operacional completo instalado e em execução). Isto também reduz o tempo de instalação para apenas alguns segundos, em comparação com alguns minutos necessários para subir uma máquina virtual.
• Custos reduzidos: o Docker é menos exigente sobre o hardware necessário para executá-lo.

Desvantagens da utilização do Docker

• As aplicações com diferentes requisitos de sistema operacional não podem ser alojadas em conjunto no mesmo Docker Host. Por exemplo, digamos que temos 4 aplicações diferentes, das quais 3 requerem um sistema operacional baseado em Linux e a outra aplicação requer um sistema operacional baseado em Windows. Neste cenário, as 3 aplicações que requerem um sistema operacional baseado em Linux podem ser alojadas num único Docker Host, enquanto a aplicação que requer um sistema operacional baseado em Windows tem de ser alojada num Docker Host diferente.

Componentes principais do Docker

Docker Engine é um dos principais componentes do Docker. Ele é responsável pelo funcionamento geral da plataforma do Docker.

Docker Engine é uma aplicação baseada em client-servidor e consiste em 3 componentes principais.

1. Servidor
2. API REST
3. Client

O servidor executa um daemon, conhecido como dockerd (Docker Daemon), que nada mais é do que um processo. Ele é responsável por criar e gerenciar imagens, contêineres, redes e volumes do Docker na plataforma do Docker.

A API REST especifica como as aplicações podem interagir com o servidor e instruí-lo para realizar o seu trabalho.

O client nada mais é do que uma interface de linha de comandos, que permite aos utilizadores interagir com o Docker utilizando os comandos.

Terminologia do Docker

Vamos dar uma olhada rápida em algumas das terminologias associadas ao Docker.

As imagens e os contêineres do Docker são as duas coisas essenciais que você encontrará diariamente ao trabalhar com o Docker.

Em termos simples, uma imagen do Docker é um modelo que contém a aplicação e todas as dependências necessárias para executar essa aplicação no Docker.

Por outro lado, como dito anteriormente, um contêiner do Docker é uma entidade lógica. Em termos mais precisos, é uma instância em execução da imagem do Docker.

O que é o Docker Hub?

O Docker Hub é o repositório oficial on-line onde se encontram todas as imagens do Docker disponíveis para utilização.

O Docker Hub também nos permite armazenar e distribuir as nossas imagens personalizadas, se assim desejarmos. Podemos também torná-las públicas ou privadas, com base nos nossos requisitos.

Observação: podemos manter somente uma imagem do Docker como privada sendo usuários do plano gratuito. Se quisermos manter mais de uma imagem do Docker privada, precisamos de um plano pago.

Docker Editions

O Docker está disponível em 2 edições diferentes, conforme listadas abaixo:

• Community Edition (CE)
• Enterprise Edition (EE)

A Community Edition é adequada para programadores individuais e pequenas equipes. Oferece funcionalidades limitadas, em comparação com a Enterprise Edition.

A Enterprise Edition, por outro lado, é adequada para grandes equipes e para a utilização do Docker em ambientes de produção.

A Enterprise Edition é ainda categorizada em três edições diferentes, conforme listadas abaixo:

• Basic
• Standard
• Advanced

Instalação do Docker

Uma última coisa que precisamos saber antes de prosseguirmos e mergulharmos no Docker é como instalá-lo.

Abaixo você verá os links para os guias oficiais de instalação do Docker CE (em inglês). Recomendo seguir estes guias para instalar o Docker na sua máquina, pois são simples e diretos.

• CentOS Linux
• Debian Linux
• Fedora Linux
• Ubuntu Linux
• Microsoft Windows
• MacOS

Quer pular a instalação e ir direto para a prática do Docker?

Caso não queira instalar o Docker, ou não tenha recursos suficientes disponíveis no seu computador, não precisa se preocupar – aqui está a solução para o seu problema.

Você pode usar o Play with Docker, que é um playground on-line para o Docker. Com ele, você pode praticar comandos do Docker imediatamente, sem ter que instalar nada na sua máquina. A melhor parte é que é simples de usar e está disponível gratuitamente.

Comandos do Docker

Agora é hora de praticar os comandos do Docker, pelos quais todos nós temos esperado até agora.

docker create

O primeiro comando que vamos analisar é o docker create.

Esse comando é usado pra criar um contêiner.

A sintaxe para esse comando é mostrada abaixo:

docker create [opções] IMAGEM [comandos] [argumentos]

Observação: tudo o que estiver entre colchetes é opcional. Isso é aplicável a todos os comandos que você verá neste guia.

Alguns dos exemplos de uso desse comando são mostrados abaixo:

$ docker create fedora

02576e880a2ccbb4ce5c51032ea3b3bb8316e5b626861fc87d28627c810af03

No exemplo acima, o comando docker create criaria um contêiner utilizando a imagem mais recente do Fedora.

Antes de criar o contêiner, ele verificará se a imagem oficial mais recente do Fedora está disponível no Docker Host ou não. Se a imagem mais recente não estiver disponível no Docker Host, baixará a imagem do Fedora do Docker Hub antes de criar o contêiner. Se a imagem do Fedora já estiver presente no Docker Host, ele usará essa imagem e criará o contêiner.

Se o contêiner for criado com sucesso, o Docker retornará o ID do contêiner. Por exemplo, no exemplo acima, 02576e880a2ccbb4ce5c51032ea3b3bb8316e5b626861fc87d28627c810af03 é o ID do contêiner devolvido pelo Docker.

Cada contêiner tem um ID de contêiner único. Utilizamos o ID de contêiner para efetuar várias operações no contêiner, tais como iniciar, parar, reiniciar etc.

Agora, vamos ver um outro exemplo do comando docker create, que tem opções e comandos sendo passados para ele.

$ docker create -t -i ubuntu bash

30986b73dc0022dbba81648d9e35e6e866b4356f026e75660460c3474f1ca005

No exemplo acima, o comando docker create cria um contêiner utilizando a imagem do Ubuntu (como referido anteriormente, se a imagem não estiver disponível no Docker Host, este transferirá a imagem mais recente do Hub Docker antes de criar o contêiner).

As opções -t e -i instruem o Docker a alocar um terminal ao contêiner para que o usuário possa interagir com o contêiner, além de instruir o Docker a executar o comando bash sempre que o contêiner for iniciado.

docker ps

O próximo comando que veremos é o docker ps.

O comando docker ps nos permite visualizar todos os contêineres que estão em execução no Docker Host.

$ docker ps

CONTAINER ID IMAGE  COMMAND CREATED        STATUS            PORTS NAMES
30986b73dc00 ubuntu "bash"  45 minutes ago Up About a minute                 elated_franklin

Ele apenas apresenta os contêineres que estão atualmente em execução no Docker Host.

Se você quiser ver todos os contêineres que foram criados nesse Docker Host, independentemente de seu status atual, então você precisa incluir a opção -a, que exibe todos os contêineres que foram criados nesse Docker Host.

$ docker ps -a

CONTAINER ID IMAGE  COMMAND     CREATED           STATUS       PORTS NAMES 30986b73dc00 ubuntu "bash"      About an hour ago Up 29 minutes elated_franklin
02576e880a2c fedora "/bin/bash" About an hour ago Created hungry_sinoussi

Antes de prosseguirmos, vamos tentar decodificar e compreender a saída do comando docker ps.

CONTAINER ID: uma string única composta por caracteres alfanuméricos, associada a cada contêiner (neste caso, 30986b73dc00 para o primeiro e 02576e880a2c para o segundo).

IMAGE: nome da imagem do Docker usada para criar esse contêiner (ubuntu e fedora, respectivamente).

COMMAND: qualquer comando específico da aplicação que precise ser executado quando o contêiner é iniciado ("bash" e "/bin/bash").

CREATED: mostra o tempo decorrido desde que este contêiner foi criado (em ambos os casos, "About an hour ago" – há cerca de uma hora).

STATUS: mostra o estado atual do contêiner, juntamente com o tempo decorrido, no seu estado atual (no primeiro caso, "Up 29 minutes" – em execução há 29 minutos, e, no segundo caso, "Created" – criado) .

Se o contêiner estiver em execução, será apresentado como "Up", juntamente com o tempo decorrido (por exemplo, "Up" há cerca de uma hora ou "Up" há 3 minutos).

Se o contêiner estiver parado, será apresentado como "Exited" seguido do código de estado de saída entre colchetes, juntamente com o tempo decorrido (por exemplo, Exited (0) há 3 semanas ou Exited (137) há 15 segundos, onde 0 e 137 são os códigos de saída).

PORTS: mostra o mapeamento das portas definidas para o contêiner.

NAMES: para além do CONTAINER ID, a cada contêiner também é atribuído um nome único. Podemos referir-nos a um contêiner utilizando o seu ID de contêiner ou o seu nome único. O Docker atribui automaticamente um nome único a cada contêiner que cria, mas se você quiser especificar o seu próprio nome para o contêiner, pode fazê-lo incluindo a opção --name (nome com duplo hífen) no comando docker create ou docker run (veremos o comando docker run mais adiante).

Espero que isso dê a você uma melhor compreensão da saída do comando docker ps.

docker start

O próximo comando que veremos é o comando docker start.

Esse comando inicia qualquer contêiner que estiver parado.

A sintaxe para esse comando é mostrada abaixo:

docker start [opções] CONTAINER ID/NAME [CONTAINER ID/NAME…]

Podemos iniciar um contêiner especificando os primeiros caracteres únicos do seu ID de contêiner ou especificando o seu nome.

Alguns dos exemplos de utilização desse comando são mostrados abaixo:

$ docker start 30986

No exemplo acima, o Docker inicia o contêiner que começa com o ID de contêiner 30986.

$ docker start elated_franklin

Nesse exemplo, o Docker inicia o contêiner chamado "elated_franklin".

docker stop

O próximo comando da lista é o comando docker stop.

Este comando paralisa qualquer contêiner em execução.

A sintaxe para esse comando é mostrada abaixo:

docker stop [opções] CONTAINER ID/NAME [CONTAINER ID/NAME…]

É semelhante ao comando docker start.

Podemos parar o contêiner especificando os primeiros caracteres únicos do seu ID de contêiner ou especificando o seu nome.

Alguns dos exemplos de uso desse comando são mostrados abaixo:

$ docker stop 30986

No exemplo acima, o Docker interromperá a execução do contêiner que começa com o ID de contêiner 30986.

$ docker stop elated_franklin

Nesse exemplo, o Docker interromperá a execução do contêiner chamado "elated_franklin".

docker restart

O próximo comando que veremos é o comando docker restart.

Esse comando reinicia qualquer contêiner em execução.

A sintaxe para esse comando é mostrada abaixo:

docker restart [opções] CONTAINER ID/NAME [CONTAINER ID/NAME…]

Podemos reiniciar o contêiner especificando os primeiros caracteres únicos do seu ID de contêiner ou especificando o seu nome.

Alguns dos exemplos de utilização desse comando são mostrados abaixo:

$ docker restart 30986

No exemplo acima, o Docker reiniciará o contêiner começando com o ID do contêiner 30986.

$ docker restart elated_franklin

Nesse exemplo, o Docker reiniciará o container chamado "elated_franklin".

docker run

O próximo comando que veremos é o comando docker run.

Esse comando primeiro cria o contêiner e, em seguida, o inicia. Em resumo, esse comando é uma combinação dos comandos docker create e docker start.

A sintaxe desse comando é mostrada abaixo:

docker run [opções] IMAGEm [comandos] [argumentos]

Ele tem uma sintaxe semelhante à do comando docker create.

Alguns dos exemplos de uso desse comando são mostrados abaixo:

$ docker run ubuntu

30fa018c72682d78cf168626b5e6138bb3b3ae23015c5ec4bbcc2a088e67520

No exemplo acima, o Docker criará o contêiner usando a imagem mais recente do Ubuntu e, em seguida, iniciará o contêiner imediatamente.

Se executássemos o comando acima, ele iniciaria o contêiner e o pararia imediatamente – não teríamos nenhuma chance de interagir com o contêiner.

Se quisermos interagir com o contêiner, então precisamos especificar as opções: -it (hífen seguido de i e t) para o comando docker run mostrar o terminal, com o qual podemos interagir com o contêiner escrevendo os comandos apropriados. Veja o exemplo abaixo.

$ docker run -it ubuntu

root@e4e633428474:/#

Para sair do contêiner, é necessário escrever exit no terminal.

docker rm

Vamos passar para o próximo comando – se quisermos apagar um contêiner, usamos o comando docker rm.

A sintaxe desse comando é a mostrada abaixo:

docker rm [opções] CONTAINER ID/NAME [CONTAINER ID/NAME...]

Alguns dos exemplos de uso desse comando são mostrados abaixo:

$ docker rm 30fa elated_franklin

No exemplo acima, estamos instruindo o Docker para excluir 2 contêineres com um único comando. O primeiro contêiner a ser eliminado é especificado através do seu ID de contêiner (30fa) e o segundo contêiner a ser eliminado é especificado através do seu nome ("elated_franklin").

Observação: os contêineres precisam estar estar parados para serem eliminados.

docker images

docker images é o próximo comando da lista.

Esse comando lista todas as imagens do Docker que estão presentes no seu Docker Host.

$ docker images

REPOSITORY  TAG      IMAGE          CREATED        SIZE
mysql       latest   7bb2586065cd   38 hours ago   477MB
httpd       latest   5eace252f2f2   38 hours ago   132MB
ubuntu      16.04    9361ce633ff1   2 weeks ago    118MB
ubuntu      trusty   390582d83ead   2 weeks ago    188MB
fedora      latest   d09302f77cfc   2 weeks ago    275MB
ubuntu      latest   94e814e2efa8   2 weeks ago    88.9MB

Vamos decodificar o resultado do comando docker images.

REPOSITORY: representa o nome único da imagem do Docker.

TAG: cada imagem está associada a uma tag exclusiva. Uma tag basicamente representa uma versão da imagem.

Uma tag é geralmente representada usando uma palavra, um conjunto de números ou uma combinação de caracteres alfanuméricos.

IMAGE ID: uma string única constituída por caracteres alfanuméricos, associada a cada imagem.

CREATED: mostra o tempo decorrido desde que a imagem foi criada.

SIZE: mostra o tamanho da imagem.

docker rmi

O próximo comando da lista é o comando docker rmi.

O docker rmi nos permite remover uma imagem (ou imagens) do Docker Host.

A sintaxe desse comando é mostrada abaixo:

docker rmi [opções] IMAGE NAME/ID [IMAGE NAME/ID...]

Alguns dos exemplos de uso desse comando são mostrados abaixo:

docker rmi mysql

O comando acima remove a imagem chamada "mysql" do Docker Host.

docker rmi httpd fedora

O comando acima remove as imagens chamadas "httpd" e "fedora" do Docker Host.

docker rmi 94e81

O comando acima remove a imagem que começa com o ID de imagem "94e81" do Docker Host.

docker rmi ubuntu:trusty

O comando acima remove a imagem chamada "ubuntu", com a tag "trusty" do Docker Host.

Esses foram alguns dos comandos mais comuns usados no Docker. Há muitos outros comandos do Docker a serem explorados.

Conclusão

A conteinerização tem recebido recentemente a atenção que merece, embora já exista há muito tempo. Algumas das principais empresas de tecnologia, como Google, Amazon Web Services (AWS), Intel, Tesla e Juniper Networks, têm sua própria versão personalizada de container engines (em português, algo como "motor de containerização"). Essas empresas dependem fortemente das engines para criar, executar, gerir e distribuir as suas aplicações.

O Docker é um motor de containerização extremamente poderoso e tem muito para oferecer quando se trata de criar, executar, gerir e distribuir as suas aplicações de maneira eficiente.

Você acabou de ver uma visão extremamente geral do Docker. Há muito mais para aprender sobre o Docker, como:

• Comandos do Docker (comandos mais poderosos)
• Imagens do Docker (como criar suas próprias imagens personalizadas)
• Docker Networking (configurar e implantar a rede)
• Docker Services (agrupamento de contêineres que utilizam a mesma imagem)
• Docker Stack (agrupamento de serviços exigidos por uma aplicação)
• Docker Compose (ferramenta para gerir e executar vários contêineres)
• Docker Swarm (agrupamento e gestão de uma ou mais máquinas nas quais o Docker está sendo executado)
• E muito mais…

Se achou o Docker fascinante e está interessado em aprender mais sobre ele, então recomendo que se inscreva nos cursos que estão listados abaixo. Eles são muito informativos e objetivos.

Se é um iniciante, então sugiro que se inscreva neste curso (em inglês), que foi projetado para principiantes.

Se você tem um bom conhecimento sobre o Docker, se está bastante confiante com as coisas básicas e se quer expandir seu conhecimento, então eu sugiro que você se inscreva neste curso, que é mais voltado para tópicos avançados relacionados ao Docker.

Docker é uma habilidade muito importante para o futuro e está apenas ganhando impulso.

Investir seu tempo e dinheiro para aprender Docker não será algo de que você se arrependerá.

Espero que você tenha achado este artigo informativo. sinta-se à vontade para compartilhá-lo. Isso realmente significa muito para mim.

Antes de dizer adeus...

Para manter contato com o autor, clique aqui para cadastrar seu e-mail.

Agradeço por dedicar seu precioso tempo à leitura deste artigo.

Isenção de responsabilidades: todos os nomes de produtos e empresas são marcas comerciais™ ou marcas comerciais registradas® dos respectivos titulares. O uso deles não implica qualquer endosso. Pode haver links de afiliados neste artigo.

Se você já trabalhou com o Docker, mesmo que por um tempo curto, aposto que já se deparou com tags. Elas geralmente se parecem com "nome_da_minha_imagem: 1", onde a parte após os dois pontos é conhecida como uma tag. A tag nem sempre é especificada ao marcar imagens, mas chegaremos a isso mais tarde.

Desde que comecei a usar o Docker, fiquei muito confusa sobre as tags. A documentação não as explica muito bem. Na verdade, não há explicações completas sobre o tópico. É por isso que decidi escrever este artigo.

O que são as tags no Docker?

Então, o que são, exatamente, as tags do Docker? Em palavras simples, as tags do Docker transmitem informações úteis sobre uma versão/variante de imagem específica. Elas são aliases para o ID da sua imagem que, muitas vezes, parecem com isto: f1477ec11d12. É apenas uma maneira de se referir à sua imagem. Uma boa analogia é associar a como as tags do Git se referem a um commit específico em seu histórico.

Os dois casos mais comuns em que as tags podem ser vistas são:

1. Ao criar uma imagem, quando usamos o seguinte comando:

docker build -t nome_do_usuario/nome_da_imagem:nome_da_tag .

Vamos tentar descomplicar um pouco o que esse comando faz. Dizemos ao daemon do Docker para buscar o arquivo do Docker presente no diretório atual (é isso que o . no final faz). Em seguida, dizemos ao daemon do Docker para criar a imagem e fornecer a ela a tag especificada. Se você executar docker images, deverá ver uma imagem cujo repositório é nome_do_usuario/nome_da_imagem e a tag é nome_da_tag.

nome_do_usuario/nome_da_imagem não é um formato obrigatório para especificar o nome da imagem. É apenas uma convenção útil para evitar marcar sua imagem novamente quando você precisar enviá-la para um registro.

Sua imagem pode ser nomeada como você quiser. Para o registro público do Docker, você está restrito a uma hierarquia de dois níveis ao nomear imagens. Por exemplo, sua imagem não pode ter o nome a/b/c:1. Essa restrição geralmente não existe em registros privados. Como dito anteriormente, não é obrigatório especificar um nome_da_tag. Veremos o que acontece nesse caso em breve.

2. Marcação explícita de uma imagem através do comando tag.

docker tag IMAGEM_DE_ORIGEM[:TAG] IMAGEM_DE_DESTINO[:TAG]

Esse comando apenas cria um alias (uma referência) com o nome de IMAGEM_DE_DESTINO que se refere a IMAGEM_DE_ORIGEM. Isso é tudo o que o comando faz. É como atribuir a uma imagem existente outro nome para se referir a ela. Observe como a tag é especificada como opcional aqui também, por [:TAG].

O que acontece quando você não especifica uma tag?

Tudo bem, agora vamos descobrir o que acontece quando você não especifica uma tag ao marcar uma imagem. É aqui que a tag latest (em português, mais recente) entra em cena. Sempre que uma imagem é marcada sem uma tag explícita, ela recebe a tag latest por padrão. É uma escolha de nomenclatura infeliz, que causa muita confusão. Eu, porém, gosto de pensar nisso como a tag padrão que é dada às imagens quando você não especifica uma.

Muita confusão em torno de latest é causada pela expectativa de que seja a versão mais recente da imagem, especialmente no Dockerfiles. Vamos considerar os vários cenários com um exemplo:

Cenário 1:

Suponha que a seguinte instrução esteja presente em nosso Dockerfile:

FROM debian

Como não especificamos nenhuma tag, o Docker adicionará a tag latest e tentará puxar a imagem debian:latest.

Cenário 2:

FROM debian:9.3

Como a tag é explicitamente mencionada aqui, o Docker puxará a imagem Debian marcada como 9.3.

Outra coisa a ter em mente é que não há nenhuma regra que estabeleça que uma imagem precisa ter apenas uma tag. Uma imagem pode ter várias tags. Elas geralmente são usadas para especificar versões principais e secundárias. Por exemplo, considere o seguinte:

No momento em que escrevo este artigo, a tag latest para a imagem Debian aponta para a versão 9.3 e para a versão 9. Isso, provavelmente, mudará no futuro sempre que a versão principal ou secundária for alterada para a imagem.

Observe que as tags que estão sendo usadas para controle de versão semântico são uma convenção que é seguida, mas as tags não foram projetadas apenas para essa finalidade.

Para concluir, latest não é uma tag especial

A principal conclusão do que tratamos até agora é que latest é como qualquer outra tag. Cabe ao desenvolvedor marcar as imagens corretamente, de modo que latest sempre aponte para a última versão estável da imagem.

Portanto, não especificamos explicitamente uma tag em nossos Dockerfiles ao extrair imagens, pois podemos acabar com uma versão completamente diferente de imagem base em comparação com a que havíamos usado antes. Não há garantias de que isso será uma grande ou uma pequena mudança. Mesmo uma versão antiga pode ser marcada como latest.

Se você encontrar algum erro/imprecisão neste artigo, fique à vontade para enviar uma mensagem para a autora pelo Twitter.

A autora agradece a Jérôme Petazzoni por ajudá-la a entender um pouco do assunto em questão.

Vou contar a você um segredo do DevOps aqui: o que todas as pessoas do DevOps adoram fazer é construir um sistema supersofisticado e complexo e, em seguida, encontrar uma maneira de lidar com ele como um shell normal. Outra possibilidade é a de se conectar a ele com SSH e tratá-lo como um shell normal.

Com o Docker não é diferente! Você está executando um computador dentro de outro computador. Talvez esse computador seja uma instância do EC2 ou um laptop. Você pode até fazer algo realmente louco e executar uma VM que está executando o Docker.

Na maioria das vezes, quando uso o Docker, eu o uso para empacotar e distribuir uma aplicação. Às vezes, estou usando para algo mais legal, como um projeto de computação distribuída. Muitas vezes, porém lanço um Dockerfile em um repositório do GitHub para não precisar instalar CLIs que sei que, no fim, entrarão em conflito no meu laptop.

Para encurtar a história, você pode dizer ao Docker para executar o comando bash, que o leva a um shell:

docker run -it nome-da-imagem bash
# docker run -it continuumio/miniconda3:latest bash
# docker run -it node:latest bash

Continue lendo para saber mais. 😜

Experimente

Pesquise no Google o Docker da sua linguagem de programação favorita. Para mim, é Python e, especificamente, eu gosto do conda. Em seguida, execute alguns comandos para garantir que você esteja de fato nesse shell.

# A partir do sistema hospedeiro
echo $(pwd)
# Entre no shell do docker
docker run -it continuumio/miniconda3:latest bash
# Agora você está em um shell do docker!
echo $(pwd)
echo $USER

Legal, não é? É perfeito para depurar um contêiner que deveria, com certeza, estar funcionando corretamente. Também é ótimo para o meu caso de uso mais comum: "Não quero instalar isso no meu computador".

Faça a depuração de um Docker Build com Docker Run

Tratar sua imagem do Docker como um shell normal será útil ao tentar depurar compilações do Docker.

Digamos que você tenha um Dockerfile para uma imagem que está tentando criar. Normalmente, o que acontece é que, ao executar docker build -t minha-imagem . (onde -t é para a tag), o Docker executará cada uma das etapas de RUN e parará quando chegar a um comando que não saia corretamente.

Em um shell UNIX, o código de saída 0 (zero) significa que está tudo bem com um comando. Então, para ilustrar esse ponto, fiz nosso Dockerfile ter um comando RUN que sai com 1.

FROM continuumio/miniconda3:latest

RUN apt-get update -y; \
    apt-get upgrade -y; \
    apt-get install -y \
    vim-tiny vim-athena build-essential

RUN  conda update conda \
    && conda clean --all --yes

RUN exit 1

docker build -t minha-imagem .

Isso dará uma saída que se assemelhará a isto:

(base) ➜  docker build -t minha-imagem .
Sending build context to Docker daemon  2.048kB
Step 1/4 : FROM continuumio/miniconda3:latest
 ---> 406f2b43ea59
Step 2/4 : RUN apt-get update -y;     apt-get upgrade -y;     apt-get install -y     vim-tiny vim-athena build-essential
 ---> Using cache
 ---> 726af29a48a0
Step 3/4 : RUN  conda update conda     && conda clean --all --yes
 ---> Using cache
 ---> 19478bb3ce67
Step 4/4 : RUN exit 1
 ---> Running in 7c98aab6b52c
The command '/bin/sh -c exit 1' returned a non-zero code: 1

Você pode confirmar que sua imagem do Docker não foi criada executando docker images e verificando minha-imagem. Não estará lá porque não foi construído com sucesso.

Agora, o que podemos fazer é comentar o comando RUN problemático do Dockerfile.

FROM continuumio/miniconda3:latest

RUN apt-get update -y; \
    apt-get upgrade -y; \
    apt-get install -y \
    vim-tiny vim-athena build-essential

RUN  conda update conda \
    && conda clean --all --yes

#RUN exit 1

Então, o que você verá é:

Sending build context to Docker daemon  2.048kB
Step 1/3 : FROM continuumio/miniconda3:latest
 ---> 406f2b43ea59
Step 2/3 : RUN apt-get update -y;     apt-get upgrade -y;     apt-get install -y     vim-tiny vim-athena build-essential
 ---> Using cache
 ---> 726af29a48a0
Step 3/3 : RUN  conda update conda     && conda clean --all --yes
 ---> Using cache
 ---> 19478bb3ce67
Successfully built 19478bb3ce67
Successfully tagged minha-imagem:latest

Agora, você pode entrar em sua imagem Docker e começar a executar comandos interativamente!

docker run -it minha-imagem bash
# você também pode executar
# docker run -it minha-imagem:latest bash

A partir daqui, um por um, você pode começar a depurar seus comandos RUN para ver o que deu errado. Se você não tem certeza se um comando saiu corretamente ou não, execute $?:

# Primeiro, execute docker run -it minha-imagem bash para obter o shell
# Exibe o texto hello
echo "hello"
# hello
echo $?
# 0

# Executa um comando hello não existente
$(hello)
# bash: hello: command not found
echo $?
# 127

Você pode continuar executando essas etapas, comentando seu Dockerfile, entrando em um shell e descobrindo comandos problemáticos, até que suas imagens do Docker sejam criadas perfeitamente.

Conclusão

Espero ter mostrado a você que usar uma imagem do Docker não é diferente do terminal em seu computador. O uso de imagens do Docker é uma maneira incrível de distribuir aplicações.

Tente pegar sua aplicação de CLI favorita ou o próximo projeto do GitHub e, em vez de criar um script de instalação, empacote-o com o Docker. 😀

O Docker é um divisor de águas. Mas não é uma solução para todos os problemas.

Há muitas coisas boas sobre o Docker. Ele empacota, envia e executa aplicativos como uma ferramenta de conteinerização leve, portátil e autossuficiente. O Docker é ótimo para empresas de todos os tamanhos. Quando você está trabalhando em um trecho de código em uma equipe pequena, ele elimina o problema do "mas funciona na minha máquina". Enquanto isso, as empresas podem usar o Docker para criar pipelines de entrega de software Agile para enviar novos recursos com mais rapidez e segurança.

Com seu sistema de conteinerização integrado, o Docker é uma excelente ferramenta para computação em nuvem. Por sua vez, o Docker Swarm avança na clusterização e no design descentralizado. Parece bom demais para ser verdade, certo? Bem, ainda existem vários casos em que não se deve usar o Docker. Aqui estão sete deles.

Vamos passar por eles um por um.

Não use o Docker se você precisa de mais velocidade

Os contêineres do Docker são menores e exigem menos recursos do que uma máquina virtual com um servidor e um banco de dados. Ao mesmo tempo, o Docker usará tantos recursos do sistema quanto o agendador do kernel do host permitir. Você não deve esperar que o Docker acelere um aplicativo de forma alguma.

Mais do que isso, o Docker pode até torná-lo mais lento. Se estiver trabalhando com ele, você deve definir limites de memória, CPU ou bloco de E/S o contêiner pode usar. Caso contrário, se o kernel detectar que a máquina host está com pouca memória para executar funções importantes do sistema, ele poderá começar a matar processos importantes. Se o processo errado for eliminado (incluindo o próprio Docker), o sistema ficará instável.

Infelizmente, os ajustes de memória do Docker – a prioridade de falta de memória no daemon do Docker – não resolvem esse problema. Por outro lado, uma camada adicional entre um aplicativo e o sistema operacional também pode resultar em redução de velocidade. No entanto, essa diminuição será insignificante. Os contêineres do Docker não são totalmente isolados e não contêm um sistema operacional completo como qualquer máquina virtual.

Não use o Docker se você prioriza a segurança

A maior vantagem de segurança do Docker é que ele divide o aplicativo em partes menores. Se a segurança de uma parte for comprometida, as demais não serão afetadas.

No entanto, enquanto processos isolados em contêineres prometem segurança aprimorada, todos os contêineres compartilham acesso a um único sistema operacional de host. Você corre o risco de executar contêineres do Docker com isolamento incompleto. Qualquer código malicioso pode ter acesso à memória do seu computador.

Existe uma prática popular de executar muitos contêineres em um único ambiente. É assim que você deixa seu aplicativo exposto a ataques do tipo Abuso de Recursos, a menos que você limite os recursos do contêiner de recursos. Para máxima eficiência e isolamento, cada contêiner deve tratar de uma área específica de preocupação.

Outro problema é a configuração padrão do Docker – os usuários não têm espaços de nome (namespace, em inglês). Os espaços de nome permitem que os recursos de software usem outros recursos somente se eles pertencerem a um espaço de nome específico.

A execução de aplicativos com o Docker implica a execução do daemon do Docker com privilégios de root. Todos os processos que saem do contêiner do Docker terão os mesmos privilégios no host que tinham no contêiner. Executar seus processos dentro dos contêineres como um usuário sem privilégios não garante a segurança. Depende dos recursos que você adiciona ou remove. Para mitigar os riscos de rompimento de contêineres do Docker, você não deve baixar contêineres prontos para uso de fontes não confiáveis.

Não use o Docker se você desenvolve um aplicativo de interface gráfica para desktops

O Docker não é adequado para aplicativos que exigem interface do usuário avançada. O Docker destina-se principalmente a contêineres isolados com aplicativos baseados em console. Os aplicativos baseados em GUI (abreviação em inglês de interface gráfica de usuário) não são uma prioridade. Seu suporte dependerá do caso e da aplicação específicos. Os contêineres do Windows são baseados em Nano ou Core Server – ele não permite que os usuários iniciem uma interface baseada em GUI ou um servidor Docker RDP no contêiner Docker.

No entanto, você ainda pode executar aplicativos baseados em GUI desenvolvidos com Python e a estrutura QT em um contêiner Linux. Além disso, você pode usar o encaminhamento X11, mas essa solução é um pouco estranha.

Não use o Docker se você deseja facilitar o desenvolvimento e depuração

O Docker foi criado por desenvolvedores e para desenvolvedores. Ele fornece estabilidade ao ambiente: um contêiner na máquina de desenvolvimento funcionará exatamente da mesma forma no teste, na produção ou em qualquer outro ambiente. Isso elimina o problema de várias versões de programas em diferentes ambientes.

Com a ajuda do Docker, você pode adicionar facilmente uma nova dependência ao seu aplicativo. Nenhum desenvolvedor em sua equipe precisará repetir essa manipulação em sua máquina. Tudo estará funcionando no contêiner e será distribuído para toda a equipe.

Ao mesmo tempo, você precisa fazer algumas configurações extras para codificar seu aplicativo no Docker. Além disso, com a depuração do Docker, você precisa configurar a saída de logs e as portas de depuração. Você também pode precisar mapear portas para seus aplicativos e serviços em contêineres. Portanto, se você tiver um processo de implantação complicado e tedioso, o Docker o ajudará muito. Se você tem um aplicativo simples, ele apenas adiciona complexidade desnecessária.

Não use o Docker se você precisa usar sistemas operacionais e kernels diferentes

Com máquinas virtuais, o hipervisor pode abstrair um dispositivo inteiro. Você pode usar o Microsoft Azure para executar as duas instâncias do Windows Server e do Linux Server ao mesmo tempo. A imagem do Docker, no entanto, requer o mesmo sistema operacional para o qual foi criada.

Há um grande banco de dados de imagens de contêiner do Docker – o Docker Hub. No entanto, se uma imagem foi criada no Linux Ubuntu, ela será executada apenas no mesmo Ubuntu.

Se um aplicativo for desenvolvido no Windows, mas a produção for executada no Linux, você não poderá usar o Docker de maneira eficaz. Às vezes, é mais fácil configurar um servidor se você tiver vários aplicativos estáticos.

Não use o Docker se você tem muitos dados valiosos para armazenar

Por design, todos os arquivos do Docker são criados dentro de um contêiner e armazenados em uma camada de contêiner gravável. Pode ser difícil recuperar os dados do contêiner se um processo diferente precisar deles. Além disso, a camada gravável de um contêiner é conectada à máquina host na qual o contêiner está sendo executado. Se você precisar mover os dados para outro lugar, não poderá fazê-lo facilmente. Mais do que isso, todos os dados armazenados dentro de um contêiner serão perdidos para sempre quando o contêiner for encerrado.

Você precisa pensar em maneiras de salvar seus dados em outro lugar primeiro. Para manter os dados seguros no Docker, você precisa empregar uma ferramenta adicional – o Docker Data Volumes. No entanto, esta solução ainda é bastante desajeitada e precisa ser melhorada.

Não use o Docker se você busca a tecnologia mais fácil de gerenciar

Tendo sido introduzido em 2012, o Docker ainda é uma tecnologia nova. Como desenvolvedor, talvez seja necessário atualizar as versões do Docker regularmente. Infelizmente, a compatibilidade com versões anteriores não é garantida. Além disso, a documentação está ficando para atrás em relação ao avanço da tecnologia. Como desenvolvedor, você terá que descobrir algumas coisas sozinho.

As opções de monitoramento que o Docker oferece também são bastante ruins. Você pode obter uma visão rápida de algumas estatísticas simples. No entanto, se você quiser ver alguns recursos avançados de monitoramento, o Docker não tem nada a oferecer.

No caso de um aplicativo grande e complexo, a implementação do Docker tem um custo. Construir e manter a comunicação entre vários contêineres em vários servidores exigirá muito tempo e esforço. No entanto, existe uma ferramenta útil, que facilita o trabalho com aplicativos Docker de vários contêineres – o Docker Compose. Ele define serviços, redes e volumes em um único arquivo YAML.

No entanto, o ecossistema do Docker é bastante fragmentado – nem todos os produtos de contêiner de suporte funcionam bem uns com os outros. Cada produto é apoiado por uma determinada empresa ou comunidade. A competição acirrada entre elas resulta na incompatibilidade do produto.

Para resumir

Os profissionais da KeenEthics gostam de trabalhar com o Docker e costumam usá-lo para o desenvolvimento de aplicativos. Apesar de algumas desvantagens, você pode usá-lo facilmente para executar e gerenciar aplicativos lado a lado em contêineres isolados.

Instalar um aplicativo pode ser tão simples quanto executar um único comando – <docker run>. O Docker também fornece um ambiente de isolamento limpo e original para cada teste, tornando-o uma ferramenta importante e útil para testes de automação.

Os recursos do Docker oferecem benefícios em termos de gerenciamento de dependência e segurança. Aprimorado com ferramentas úteis como o Docker Hub, o Docker Swarm e o Docker Compose, o Docker é uma solução popular e fácil de usar.

Apesar de todos os benefícios do Docker, você não deve usá-lo para conteinerizar todo e qualquer aplicativo que você desenvolver.

Lembre-se: o Docker é um divisor de águas, mas não é uma solução para todos os problemas.

O Docker também não é a única ferramenta desse tipo no mercado. As alternativas ao Docker são o rkt (que se pronuncia como "rocket"), o Linux Containers ou o OpenVZ. Todos têm suas vantagens e desvantagens e são bastante semelhantes ao Docker. A crescente popularidade e as taxas de uso do Docker são causadas apenas pela decisão das empresas de adotá-lo.

Antes de tirar conclusões precipitadas sobre usar ou não o Docker, pesquise os requisitos do projeto. Converse com seus colegas de equipe ou colegas e deixe-os ajudá-lo a decidir quando usar o Docker, quando não usar contêineres e se é um desses casos de uso do Docker.

Quer você goste ou não, essa tecnologia tem futuro. Existem alguns desenvolvedores e agências de desenvolvimento que odeiam o Docker e tentam eliminá-lo de todos os seus projetos em andamento. Ao mesmo tempo, existem especialistas que colocam em contêiner tudo o que podem porque veem o Docker como uma panaceia. Talvez você não deva se juntar a nenhum dos lados. Mantenha-se imparcial, seja objetivo e tome uma decisão que dependa de sua situação específica.

Você tem uma ideia para um projeto do Docker?

A empresa do autor, a KeenEthics, é uma equipe de desenvolvedores de aplicativos da web experientes. Caso precise de um orçamento gratuito de um projeto semelhante, sinta-se à vontade para entrar em contato.

Você pode ler mais artigos semelhantes no blog do autor, o Keen Blog. Permita-me sugerir que você leia Why to Refactor Your Code? (em inglês) ou Software Development Models Explained:  Outsourcing vs Outstaffing,  Fixed Price vs Time & Material? (também em inglês)

Nota final

Por fim, o autor original gostaria de registrar seu "obrigado" a Alex Pletnov, por ser o coautor do artigo original, bem como aos leitores por chegarem até o final do texto!

O artigo original, postado no blog da KeenEthics, pode ser encontrado aqui: 7 Cases When Not to Use Docker (em inglês).

Você é um desenvolvedor e deseja começar a usar o Docker? Este artigo é para você.

Após uma breve apresentação sobre o que o Docker é e sobre o motivo para usá-lo, você poderá criar sua primeira aplicação com o Docker.

O que é o Docker?

Docker é um software livre desenvolvido pela Docker Inc. Ele foi apresentado ao público em geral em 13 de março de 2013 e se tornou desde então algo necessário no mundo do desenvolvimento em tecnologia.

Ele permite que os usuários criem ambientes de desenvolvimento independentes e isolados para lançar e implantar suas aplicações. Esses ambientes são, então, chamados de contêineres (containers, em inglês).

Isso permitirá ao desenvolvedor executar um contêiner em qualquer máquina.

Como você pode ver, com o Docker, não há mais problemas de dependências ou de compilação. Tudo o que você precisa é lançar seu contêiner e a aplicação iniciará imediatamente.

O Docker, portanto, é uma máquina virtual?

Esta é uma das perguntas que mais são feitas com relação ao Docker. A resposta é: bem, não exatamente.

Ele até pode parecer com uma máquina virtual para começar, mas a funcionalidade não é a mesma.

Diferente do Docker, uma máquina virtual incluirá todo o sistema operacional. Ela funcionará de modo independente e agirá como um computador.

O Docker compartilhará apenas os recursos da máquina host para executar seus ambientes.

Qual o motivo para usar o Docker como um desenvolvedor?

Essa ferramenta pode realmente mudar a vida diária de um desenvolvedor. Para melhor responder a essa pergunta, eu escrevi uma lista abrangente de benefícios que você encontrará:

• O Docker é rápido. Diferentemente de uma máquina virtual, sua aplicação pode ser iniciada em poucos segundos e encerrada com a mesma rapidez.
• O Docker é multiplataforma. Você pode lançar seu contêiner em qualquer sistema.
• Contêineres podem ser criados e destruídos mais rapidamente do que uma máquina virtual.
• Você não terá mais a dificuldade de configurar seu ambiente de trabalho. Quando o Docker estiver configurado, você nunca terá de reinstalar suas dependências de modo manual novamente. Se trocar de computador ou se um novo funcionário se juntar à empresa, tudo o que você precisa fazer é dar a ele ou ela sua configuração.
• Você mantém limpo seu espaço de trabalho, já que cada um dos ambientes estará isolado e você poderá exclui-los a qualquer momento, sem causar impacto ao resto.
• Será mais fácil implantar seu projeto em seu servidor para colocá-lo on-line.

Vamos criar sua primeira aplicação

Agora que você sabe o que o Docker é, está na hora de criar sua primeira aplicação!

A finalidade deste tutorial breve é criar um programa em Python que exiba uma frase. Esse programa terá de ser lançado por meio de um Dockerfile.

Como você verá, não é complicado quando você compreende o processo.

Observação: você não precisará instalar o Python em seu computador. Ele funcionará no ambiente do Docker para conter o Python que executará o seu código.

1. Instalar o Docker em sua máquina

Para o Ubuntu:

Primeiro, faça a atualização de seus pacotes:

$ sudo apt update

Em seguida, instale o Docker com apt-get:

$ sudo apt install docker.io

Por fim, verifique se o Docker está instalado corretamente:

$ sudo docker run hello-world

• Para o MacOSX: siga este link (instruções em inglês).
• Para o Windows: siga este link (instruções em inglês).

2. Criar seu projeto

Para criar sua primeira aplicação em Docker, convido você a criar uma pasta em seu computador. Ela deve ter os dois arquivos abaixo:

• Um arquivo 'main.py' (arquivo em Python que conterá o código a ser executado).
• Um arquivo 'Dockerfile' (arquivo do Docker que conterá as instruções necessárias para criar o ambiente).

Normalmente, você deverá ter a seguinte arquitetura de pasta:

.
├── Dockerfile
└── main.py
0 directories, 2 files

3. Editar o arquivo em Python

Você pode adicionar o código a seguir ao arquivo 'main.py':

#!/usr/bin/env python3

print("O Docker é mágico!")

Nada de excepcional, mas assim que você ver a linha "O Docker é mágico!" exibida em seu terminal, saberá que o Docker está funcionando.

4. Editar o arquivo Docker

Um pouco de teoria: a primeira coisa a fazer quando quiser criar seu arquivo Dockerfile é se perguntar o que você quer fazer. O objetivo aqui é lançar código em Python.

Para fazer isso, nosso Docker deve conter todas as dependências necessárias para lançar o Python. Um sistema Linux (Ubuntu) com o Python instalado nele deve ser o suficiente.

O primeiro passo ao criar um arquivo do Docker é acessar o site da web do DockerHub. Ele contém diversas imagens pré-projetadas para poupar seu tempo (por exemplo: todas as imagens para o Linux ou linguagens de código).

Em nosso caso, digitaremos 'Python' na barra de pesquisa. O primeiro resultado é a imagem oficial criada para executar o Python. Perfeito! Vamos usá-la!

# Um dockerfile sempre deve começar importando a imagem de base.
# Usamos a palavra-chave 'FROM' para isso.
# Em nosso exemplo, queremos importar a imagem do python.
# Assim, escrevemos 'python' para o nome da imagem e 'latest' para  a versão.
FROM python:latest

# Para lançar nosso código em Python, devemos importá-lo em nossa imagem.
# Usamos para isso a palavra-chave 'COPY'.
# O primeiro parâmetro, 'main.py', é o nome do arquivo no host.
# O segundo parâmetro, '/', é o caminho onde colocar o arquivo na imagem.
# Aqui, colocamos o arquivo na pasta raiz da imagem.
COPY main.py /

# Precisamos definir o comando para lançar quando rodarmos a imagem.
# Usamos a palavra-chave 'CMD' para isso.
# O comando a seguir executará "python ./main.py".
CMD [ "python", "./main.py" ]

4. Criar uma imagem do Docker

Quando seu código estiver pronto e o Dockerfile estiver escrito, tudo o que você precisa fazer é criar sua imagem para que contenha sua aplicação.

$ docker build -t python-test . 

A opção '-t' permite que você defina o nome de sua imagem. Em nosso caso, escolhemos 'python-test', mas você pode usar o nome que quiser.

5. Executar a imagem do Docker

Quando a imagem for criada, seu código estará pronto para ser lançado.

$ docker run python-test

Você precisa colocar o nome de sua imagem após 'docker run'.

Aí está. Você, agora, deverá ver "O Docker é mágico!" sendo exibido em seu terminal.

O código está disponível

Se deseja obter o código completo para descobri-lo facilmente ou executá-lo, eu o coloquei à sua disposição no meu GitHub.

-> GitHub: exemplo de primeira aplicação com o Docker (readme.md em inglês)

Comandos úteis para o Docker

Antes de encerrar, preparei uma lista de comandos que pode ser útil para você no Docker.

• Listar suas imagens.

$ docker image ls

• Excluir uma imagem específica.

$ docker image rm [nome da imagem]

• Excluir todas as imagens existentes.

$ docker image rm $(docker images -a -q)

• Listar todos os contêineres existentes (em execução ou não).

$ docker ps -a

• Parar um contêiner específico.

$ docker stop [nome do contêiner]

• Parar todos os contêineres em execução.

$ docker stop $(docker ps -a -q)

• Excluir um contêiner específico (que não estiver em execução).

$ docker rm [nome do contêiner]

• Excluir todos os contêineres (apenas se estiverem parados).

$ docker rm $(docker ps -a -q)

• Exibir os logs (registros) de um contêiner.

$ docker logs [nome do contêiner]

E agora?

Depois de receber o feedback sobre o texto, decidi escrever a segunda parte desse guia do iniciante. Nela, você descobrirá como usar o docker-compose para criar sua primeira aplicação client/servidor com o Docker.

-> A beginner’s guide to Docker — how to create a client/server side with docker-compose (texto em inglês)

Conclusão

Você pode usar este artigo como referência sempre que precisar de um exemplo simples e concreto de como criar sua primeira aplicação em Docker. Se tiver perguntas ou comentários, fique à vontade para perguntar ao autor.

Se quiser mais conteúdo como este, você pode seguir o autor no Twitter. Lá, ele faz tweets sobre desenvolvimento para a web, autoaperfeiçoamento e sobre sua jornada como desenvolvedor full-stack!

Você também pode encontrar outros artigos como este no site da web do autor: herewecode.io.

Neste artigo, você vai aprender como configurar um ambiente de desenvolvimento com o live-reload habilitado. Com isso, você poderá fazer com que aplicações legadas usem Docker, volumes do Docker e o docker-compose.

Alguns desenvolvedores torcem o nariz quando o assunto é utilizar o Docker em seus ambientes de desenvolvimento. Eles dizem que o Docker não é bom para desenvolvimento, pois é preciso reconstruir a imagem toda hora para refletir as novas alterações. Isso torna o trabalho improdutivo e lento.

Neste artigo, nosso objetivo é combater esse pensamento, demonstrando como algumas configurações simples podem trazer muitos benefícios, como a possibilidade de ter um ambiente confiável, tanto em produção, como em desenvolvimento.

Ao final deste artigo, você terá aprendido a:

• Configurar aplicações legadas para rodar em contêineres do Docker;
• Habilitar o cache de dependências em módulos do Node.js;
• Habilitar o live-reload utilizando volumes do Docker;
• Agregar todos os serviços utilizando o docker-compose.

Requisitos

Nos próximos passos, você vai clonar um projeto existente para executar todos os exemplos deste artigo. Antes de começar a escrever código, certifique-se de que você possui as seguintes ferramentas instaladas no seu computador:

• Docker e Docker compose
• Node.js 10+
• Git

Por que usar o Docker?

A todo momento, vemos na internet o surgimento de novas tecnologias de ponta. Elas são estáveis, e é divertido trabalhar com coisas novas, mas elas não são tão previsíveis quando estamos trabalhando nos mais diversos ambientes. Então, um grupo de desenvolvedores criou o Docker para reduzir as chances de possíveis erros nestes cenários de mudança de ambiente.

O Docker é uma das minhas ferramentas favoritas e eu o utilizo para trabalhar com aplicações desktop, web ou IoT. Agora, eu tenho o poder de mover minhas aplicações para os mais diversos ambientes, podendo também manter meu ambiente local sempre limpo.

Desenvolvedores que trabalham com tecnologias de ponta estão sempre mexendo com algo novo. Mas, e quanto às aplicações legadas? Deveríamos simplesmente reescrever tudo com uma nova tecnologia? Eu sei que isso não é tão simples quanto parece. Nós devemos trabalhar com coisas novas, mas também devemos sempre manter e aprimorar as aplicações existentes.

Vamos dizer que você decidiu trocar de servidores baseados em Windows para servidores baseados em Unix. Como isso deveria ser feito? Você sabe todas as dependências que seu aplicativo precisa para funcionar?

Como um ambiente de desenvolvimento deveria ser?

Desenvolvedores estão sempre tentando ser mais produtivos. Para isso, muitas vezes, tentamos adicionar plugins, boilerplates e bases de códigos prontas em nossas IDEs/editores/terminais. Na minha opinião, porém, o ambiente de desenvolvimento ideal deveria ser:

1. Fácil de executar e testar;
2. Agnóstico ao ambiente;
3. Rápido de avaliar/testar modificações;
4. Fácil de replicar em qualquer computador.

Nas próximas seções deste artigo, nós configuraremos uma aplicação que tem como base os princípios citados acima. Caso você ainda não tenha ouvido falar de live-reload (ou hot reload), sua tradução literal seria "atualização em tempo real", que nada mais é do que uma funcionalidade que fica observando as modificações que são feitas no código e reinicia a aplicação automaticamente. Com isso, você não precisa ficar toda hora fazendo o build e reiniciando sua aplicação.

Começando

Primeiro, você vai precisar de uma pasta vazia chamada post-docker-livereload, que será nosso local de trabalho. Acesse este repositório do Github e faça um clone dentro dele na pasta post-docker-live-reload.

Após clonar o repositório no seu ambiente local, vamos analisar quais os requerimentos da aplicação. Dando uma rápida olhada no arquivo README.md, podemos ver algumas instruções de como executar a aplicação, como mostra a imagem abaixo:

É necessário ter o Node.js na versão 10 ou superior e o MongoDB. Ao invés de fazermos uma instalação do MongoDB no seu ambiente local, vamos instalá-lo utilizando o Docker. Você vai expor o MongoDB em localhost:27017. Assim, mesmo aplicações executadas fora do Docker poderão acessá-lo sem a necessidade de conhecer o IP interno que é utilizado no Docker.

Copie o comando abaixo e cole no seu terminal:

docker run --name mongodb -p 27017:27017 -d mongo:4

Com o comando acima, você baixará e executará uma instância do MongoDB. Observe que, caso você já tenha uma instância com o mesmo nome, o comando lançará um erro de nome inválido.

Caso ocorra o erro, você pode remover a instalação anterior rodando o comando docker rm mongodb. Com isso, você removerá qualquer instância anterior e poderá rodar o comando docker run novamente.

Explorando a aplicação

O arquivo README.md diz que, antes de rodar sua aplicação, você precisará de uma instância do MongoDB, juntamente com o Node.js.

Se você já tiver instalado o Node.js, vá para a pasta nodejs-with-mongodb-api-example e execute os seguintes comandos:

npm i 
npm run build 
npm start

Após executar esses comandos, vá até o navegador e acesse http://localhost:3000. Assim, você poderá visualizar a aplicação sendo executada, como mostra a imagem abaixo:

Tenha em mente que a aplicação já possui um comando para habilitar o live-reload que é o npm run dev:watch. O fluxo deve seguir os seguintes passos:

1. O desenvolvedor muda um arquivo Typescript;
2. Os arquivos Typescript são transpilados (convertidos) para JavaScript;
3. O servidor identifica as modificações nos arquivos JavaScript e reinicia o servidor Node.js.

Então, fazendo um espelhamento dos arquivos para os contêineres Docker, essas alterações serão refletidas para o contêiner também. O comando npm run build:watch vai capturar as alterações e gerar novos arquivos na pasta lib. Então, todas as vezes que o comando npm run dev:run for disparado, o servidor será reiniciado.

Dockerizando a aplicação

Caso o Docker seja um mundo completamente novo para você, não tenha medo! Você fará essa configuração do zero. Você vai precisar criar apenas alguns arquivos para começar:

1. Dockerfile - é como uma receita onde será descrito como instalar sua aplicação;
2. .dockerignore - um arquivo onde listamos quais arquivos não irão para a instância do contêiner.

Criando o Dockerfile

Dockerfile é o conceito chave aqui. Nele, você especifica os passos e dependências para preparar e executar a aplicação. Desde que você tenha lido o arquivo README.md, será muito fácil de implementar o arquivo de "receita".

Vou colocar todo arquivo aqui e, mais para a frente, vamos explorá-lo mais a fundo. Na sua pasta nodejs-with-mongodb-api-example, crie um arquivo com o nome Dockerfile e cole o código abaixo.

FROM node:14-alpine

WORKDIR /src

ADD package.json /src 

RUN npm i --silent

ADD . /src 

RUN npm run build 

CMD npm start

O que estamos fazendo no Dockerfile?

• Na primeira linha - utilizamos uma imagem base do Node.js 14 - versão alpine;
• Da linha 2 até a linha 4 - é feita a cópia e instalação das dependências do Node.js do host para o contêiner. Note que a ordem aqui é importante. Adicionar o package.json para a pasta src antes de restaurar as dependências vai criar um cache e evitar que toda a vez que você fizer o build da imagem os pacotes sejam baixados novamente;
• Da linha 6 até a linha 7 - é feita a compilação e logo após a execução do programa como mencionado no arquivo README.md;

Ignorando arquivos desnecessários com o .dockerignore

Atualmente, eu estou trabalhando com um sistema operacional baseado em OSX. O contêiner Docker vai executar em um sistema operacional baseado em Alpine Linux. Quando você executar o comando npm install, serão baixadas as dependências para o ambiente específico.

Agora, você vai criar um arquivo para ignorar o código gerado no seu ambiente local - por exemplo, a pasta node_modules e a pasta lib. Assim, garantimos que, quando você fizer a cópia dos arquivos do seu diretório atual para o contêiner, nenhuma dependência indesejada seja copiada também.

Na pasta nodejs-with-mongodb-api-example, crie um arquivo com o nome .dockerignore e cole o código abaixo:

node_modules/
lib/

Construindo a imagem Docker

Eu prefiro executar essa aplicação a partir da pasta raiz. Volte para a pasta post-docker-live-reload e execute os comandos a seguir para preparar a imagem para a utilizarmos mais adiante:

docker build -t app nodejs-with-mongodb-api-example

Repare que o comando acima utiliza a flag -t para definir o nome da imagem. Logo depois disso, é informada a pasta que contém o arquivo Dockerfile.

Trabalhando com volumes

Antes de executar a aplicação, vamos fazer alguns "hacks" para melhorar nossa experiência com os contêineres do Docker.

Os volumes no Docker nos permitem espelhar arquivos da nossa máquina local para o ambiente do Docker. Você também pode compartilhar volumes entre diversos contêineres e reaproveitá-los para criar um cache das dependências.

Nosso objetivo aqui é observar qualquer mudança nos nossos arquivos .ts do ambiente local e espelhar essas mudanças para o contêiner, mesmo que os arquivos e a pasta node_modules estejam no mesmo diretório.

Você se lembra quando eu disse que as dependências podem ser diferentes dependendo do sistema operacional? Para ter certeza que nosso ambiente local não vai afetar o ambiente do Docker quando espelharmos os arquivos, nós vamos isolar a pasta node_modules do container em um volume separado.

Consequentemente, quando a pasta node_modules for criada no contêiner, ela não será criada na nosso ambiente local. Execute o comando abaixo no terminal para criar o volume:

docker volume create --name nodemodules

Executando e habilitando o live-reload

Como você já sabe, o comando npm run dev:watch especificado no arquivo README.md mostra como habilitar o live-reload. O problema é que você está programando em sua máquina local e suas alterações devem se refletir no contêiner.

Executando o comando abaixo, você vai conectar seu ambiente local com o contêiner do Docker. Assim, qualquer alteração na pasta nodejs-with-mongodb-api-example será refletida na pasta src do contêiner.

docker run \
    --name app \
    --link mongodb \
    -e MONGO_URL=mongodb \
    -e PORT=4000 \
    -p 4000:4000 \
    -v `pwd`/nodejs-with-mongodb-api-example:/src \
    -v nodemodules:/src/node_modules \
    app npm run dev:watch

Vamos nos aprofundar no que está sendo feito aqui:

• --link - dá a permissão para a aplicação acessar a instância do MongoDB;
• -e - são as variáveis de ambiente. Como mencionado no arquivo README.md, você pode especificar a string de conexão da instância do MongoDB a qual você quer se conectar sobrescrevendo a variável MONGO_URL. Sobrescreva a variável PORT, caso queira que a aplicação seja executada em uma porta diferente. Observe que o valor de mongodb é o mesmo que usamos para criar a nossa instância do MongoDB nas seções anteriores. Este valor também é um apelido para o IP interno da instância do MongoDB;
• -v - mapeia o diretório atual para o contêiner do Docker utilizando um volume virtual. Utilizando o comando pwd, você tem acesso ao caminho absoluto para seu diretório de trabalho atual e, em seguida, para a pasta que você gostaria de espelhar no contêiner do Docker, que, no caso, é o diretório :/src. A pasta src representa a instrução WORKDIR, definida no arquivo Dockerfile, para que possamos espelhar nosso diretório local para a pasta src do contêiner do Docker;
• -v - este segundo volume serve para espelhar a pasta node_modules do contêiner de maneira individual;
• app - é o nome da imagem;
• npm run dev:watch - este último comando vai sobrescrever o comando CMD que está no Dockerfile.

Após executar o comando acima, você pode acessar o browser novamente e fazer algumas alterações no seu arquivo index.ts para ver os resultados (atente-se que utilizamos a porta 4000 no comando shell). O vídeo abaixo demonstra esses passos:

Finalizando

Você sabe que trabalhar com comandos shell funciona. Não é muito comum , no entanto, usá-los aqui. Também não é muito produtivo executar todos esses comandos, construir as imagens e gerenciar as instâncias manualmente. Então, vamos fazer uma composição!

O Docker Compose é uma forma de simplificar a agregação e a conexão entre os serviços. Você pode especificar os bancos de dados, os logs, as aplicações, os volumes, as redes e assim por diante.

Primeiro, será preciso remover todas as instâncias inativas para evitar conflito nas portas expostas. Execute o seguinte comando no seu terminal para remover os volumes, serviços e contêineres:

docker rm app 
docker volume rm nodemodules
docker stop $(docker ps -aq)
docker rm $(docker ps -aq)

O arquivo docker-compose

Crie um arquivo docker-compose.yml na sua pasta post-docker-livereload usando as informações abaixo:

version: '3'
services:
    mongodb:
        image: mongo:4
        ports:
            - 27017:27017
    app:
        build: nodejs-with-mongodb-api-example
        command: npm run dev:watch
        ports:
            - 4000:4000
        environment: 
            MONGO_URL: mongodb
            PORT: 4000
        volumes:
            - ./nodejs-with-mongodb-api-example:/src/
            - nodemodules:/src/node_modules
        links:
            - mongodb
        depends_on: 
            - mongodb

volumes:
    nodemodules: {}

O arquivo acima especifica os recursos por seções. Repare que, nele, você possui as seções links e depends_on. O campo links representa a mesma flag que você utilizou no comando shell. O campo depends_on vai garantir que o MongoDB é uma dependência necessária para executar a aplicação. Isso fará com que o MongoDB seja executado antes da aplicação magicamente!

Voltando ao terminal, para iniciar os serviços, construir a imagem do Docker, criar os volumes e os links, execute o seguinte comando:

docker-compose up --build

Caso você precise remover todos os serviços criados anteriormente pelo Dockerfile, também pode executar o comando docker-compose down.

O Docker é seu amigo!

É isso, meu amigo. O Docker pode te ajudar a prevenir muitos erros. Você pode utilizá-lo tanto em aplicações front-end como em aplicações back-end. Até mesmo com IoT, quando é necessário controlar um hardware, você pode especificar políticas utilizando o Docker.

Como um próximo passo, eu recomendo fortemente que você dê uma olhada em ferramentas de orquestração de contêineres, como o Kubernetes e o Docker swarm. Elas podem melhorar ainda mais suas aplicações existentes e ajudar você a atingir um outro nível.

Muito obrigado por ler até aqui

Eu fico muito grato por esse tempo que passamos juntos. Espero que esse conteúdo seja mais do que apenas texto. Espero que ele ajude você a se tornar um pensador melhor e também um programador melhor. Siga-me no Twitter e confira meu blog pessoal, onde eu compartilho muitos conteúdos especiais.

Até mais!

O Docker fornece a capacidade e "empacotar" e executar uma aplicação em um ambiente relativamente isolado, chamado de contêiner.

Eu sei o que você está pensando – ah, não, outro artigo explicando o que é o Docker! A gente encontra isso em todo lugar agora!

Mas não se preocupe. Pularemos a parte introdutória. O público alvo desse artigo já deve ter um conhecimento básico sobre o Docker e sobre contêineres.

Mas você já se perguntou sobre como obter o endereço IP de um contêiner do Docker?

Rede do Docker explicada

Primeiro, vamos entender como a rede do Docker funciona. Para isso, vamos nos concentrar na rede bridge padrão. Ao usar o Docker, se você não especificar um driver, este é o tipo de rede que você usará.

A rede bridge funciona como uma rede interna privada para o host de modo que os contêineres dentro dele possam se comunicar. O acesso externo é garantido ao expor portas para os contêineres.

As redes bridge são usadas quando suas aplicações rodam em contêineres autônomos que precisam se comunicar.

Na figura acima, db e web podem se comunicar entre eles em uma rede bridge criada pelo usuário, chamada mybridge.

Se você nunca adicionou uma rede no Docker, deverá ver algo semelhante a isso:

$ docker network ls

NETWORK ID          NAME                  DRIVER              SCOPE
c3cd46f397ce        bridge                bridge              local
ad4e4c24568e        host                  host                local
1c69593fc6ac        none                  null                local

A rede bridge padrão está listada, junto com host e none.  Ignoraremos as outras duas e usaremos a rede bridge ao chegar aos exemplos.

Endereço IP do contêiner do Docker

Por padrão, o contêiner recebe um endereço IP para cada rede do Docker a qual ele se conecta. Cada rede é criada com uma máscara de sub-rede padrão, usando-a como um pool posteriormente para fornecer o endereço IP.

Em geral, o Docker usa a sub-rede padrão 172.17. 0.0/16 para colocar o contêiner em rede.

Para entender isso melhor, vamos executar um caso de uso real.

Exemplo do Docker

Para ilustrar, usaremos um ambiente de Hive e Hadoop, contendo 5 contêineres do Docker.

Confira o arquivo docker-compose.yml que estamos prestes a executar:

version: "3"

services:
  namenode:
    image: bde2020/hadoop-namenode:2.0.0-hadoop2.7.4-java8
    volumes:
      - namenode:/hadoop/dfs/name
    environment:
      - CLUSTER_NAME=test
    env_file:
      - ./hadoop-hive.env
    ports:
      - "50070:50070"
  datanode:
    image: bde2020/hadoop-datanode:2.0.0-hadoop2.7.4-java8
    volumes:
      - datanode:/hadoop/dfs/data
    env_file:
      - ./hadoop-hive.env
    environment:
      SERVICE_PRECONDITION: "namenode:50070"
    ports:
      - "50075:50075"
  hive-server:
    image: bde2020/hive:2.3.2-postgresql-metastore
    env_file:
      - ./hadoop-hive.env
    environment:
      HIVE_CORE_CONF_javax_jdo_option_ConnectionURL: "jdbc:postgresql://hive-metastore/metastore"
      SERVICE_PRECONDITION: "hive-metastore:9083"
    ports:
      - "10000:10000"
  hive-metastore:
    image: bde2020/hive:2.3.2-postgresql-metastore
    env_file:
      - ./hadoop-hive.env
    command: /opt/hive/bin/hive --service metastore
    environment:
      SERVICE_PRECONDITION: "namenode:50070 datanode:50075 hive-metastore-postgresql:5432"
    ports:
      - "9083:9083"
  hive-metastore-postgresql:
    image: bde2020/hive-metastore-postgresql:2.3.0

volumes:
  namenode:
  datanode:

Do GitHub docker-hive

Ninguém quer ler um arquivo de configuração ENORME, certo? Então, aí vai uma imagem:

Melhor assim! Vamos começar com os contêineres:

docker-compose up -d

Podemos ver 5 contêineres:

$ docker ps --format \
"table {{.ID}}\t{{.Status}}\t{{.Names}}"

CONTAINER ID        STATUS                   NAMES
158741ba0339        Up 1 minutes             dockerhive_hive-metastore-postgresql
607b00c25f29        Up 1 minutes             dockerhive_namenode
2a2247e49046        Up 1 minutes             dockerhive_hive-metastore
7f653d83f5d0        Up 1 minutes (healthy)   dockerhive_hive-server
75000c343eb7        Up 1 minutes (healthy)   dockerhive_datanode

Agora, vamos conferir as redes do Docker:

$ docker network ls

NETWORK ID          NAME                  DRIVER              SCOPE
c3cd46f397ce        bridge                bridge              local
9f6bc3c15568        docker-hive_default   bridge              local
ad4e4c24568e        host                  host                local
1c69593fc6ac        none                  null                local

Espere aí... tem uma nova rede chamada docker-hive_default!

Por padrão, o comando docker compose configura uma única rede para seu app. E a rede do app recebe seu nome com base no “nome do projeto”, originário do nome do diretório em que ele está.

Como o nome do nosso diretório é docker-hive, isso explica a nova rede.

Em seguida, veremos exemplos de como obter o endereço IP do contêiner do Docker.

Como obter o endereço IP do contêiner do Docker - exemplos

Agora que eu já tenho sua atenção, vamos revelar o mistério.

1. Usando docker inspect

O comando docker inspect é uma ótima forma de obter informações de baixo nível sobre os objetos do Docker. Você pode pegar qualquer campo do JSON retornado de maneira bastante direta.

Vamos usá-lo para obter o endereço IP de dockerhive_datanode?

$ docker inspect -f \
'{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' \
75000c343eb7

172.18.0.5

Você não disse que o Docker usa a sub-rede 172.17. 0.0/16 padrão para colocar o contêiner em rede? Por que o endereço IP retornado é 172.18.0.5  fora dele?

Para responder isso, temos que olhar para nossas configurações de rede:

$ docker network inspect -f \
'{{range .IPAM.Config}}{{.Subnet}}{{end}}'  9f6bc3c15568

172.18.0.0/16

Executamos esse exemplo em uma máquina virtual do Compute Engine. Neste teste, a rede do Docker foi atribuída a uma sub-rede diferente: 172.18.0.0/16. Isso explica a questão!

Além disso, podemos procurar os endereços IP na rede docker-hive_default.

Assim, não precisamos procurar o IP de cada contêiner individualmente:

$ docker network inspect -f \
'{{json .Containers}}' 9f6bc3c15568 | \
jq '.[] | .Name + ":" + .IPv4Address'

"dockerhive_hive-metastore-postgresql:172.18.0.6/16"
"dockerhive_hive-metastore:172.18.0.2/16"
"dockerhive_namenode:172.18.0.3/16"
"dockerhive_datanode:172.18.0.5/16"
"dockerhive_hive-server:172.18.0.4/16"

Caso não tenha percebido, usamos a ajuda do jq para analisar o objeto de mapa Containers.

2. Usando docker exec

No exemplo a seguir, trabalharemos com o dockerhive_namenode.

$ docker exec dockerhive_namenode cat /etc/hosts

127.0.0.1       localhost
::1     localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
172.18.0.3      607b00c25f29

3. Dentro do contêiner do Docker

$ docker exec -it dockerhive_namenode /bin/bash

# rodando dentro do contêiner dockerhive_namenode
ip -4 -o address

7: eth0    inet 172.18.0.3/16 brd 172.18.255.255 scope global eth0

Podemos até encontrar os endereços IP de outros contêineres que estão dentro da mesma rede:

Nó dos dados (data node)

# rodando dentro do contêiner dockerhive_namenode
ping dockerhive_datanode

PING dockerhive_datanode (172.18.0.5): 56 data bytes
64 bytes from 172.18.0.5: icmp_seq=0 ttl=64 time=0.092 ms

Metastore do Hive

# rodando dentro do contêiner dockerhive_namenode
ping dockerhive_hive-metastore

PING dockerhive_hive-metastore_1 (172.18.0.2): 56 data bytes
64 bytes from 172.18.0.2: icmp_seq=0 ttl=64 time=0.087 ms

Servidor do Hive

# rodando dentro do contêiner
ping dockerhive_hive-server

PING dockerhive_hive-server (172.18.0.4): 56 data bytes
64 bytes from 172.18.0.4: icmp_seq=0 ttl=64 time=0.172 ms

Para encerrar

Todos os exemplos foram executados em uma VM de uma distribuição Linux no Compute Engine. Se você executar os exemplos nos ambientes macOS ou Windows, os comandos dos exemplos podem mudar um pouco.

Lembre-se, também, de que esses endereços IP dos exemplos dados são internos à rede docker-hive_default usada na amostra. Por isso, se você tiver um caso de uso para conectar esses contêineres externamente, precisará usar o IP externo da máquina do host (levando em conta que você estará expondo as portas dos contêineres corretamente).

Se estiver usando kubernetes, por exemplo, para gerenciar seus contêineres do Docker, permita que ele trate dos endereços IP para você.

* Ilustrações de icons8.com feitas por Murat Kalkavan.

O Docker vem sendo adotado amplamente e é usado para executar e escalar aplicações em produção. Além disso, ele pode ser usado para iniciar aplicações rapidamente executando um único comando do Docker.

Empresas também estão investindo cada vez mais esforços na melhoria do desenvolvimento em contêineres locais e remotos do Docker, o que traz muitas vantagens.

Você pode obter as informações básicas sobre sua configuração do Docker executando o comando:

$ docker info

...
 Storage Driver: overlay2
 Docker Root Dir: /var/lib/docker
...

O resultado contém as informações sobre seu driver de armazenamento e sobre seu diretório raiz do Docker.

O local de armazenamento das imagens e contêineres do Docker

Um contêiner do Docker é composto de configurações de rede, volumes e imagens. O local dos arquivos do Docker depende de seu sistema operacional. Aqui, vemos uma visão geral dos sistemas operacionais mais utilizados:

• Ubuntu: /var/lib/docker/
• Fedora: /var/lib/docker/
• Debian: /var/lib/docker/
• Windows: C:\ProgramData\DockerDesktop
• MacOS: ~/Library/Containers/com.docker.docker/Data/vms/0/

No macOS e no Windows, o Docker executa contêineres do Linux em um ambiente virtual. Assim, é preciso saber mais algumas coisas.

Docker para o Mac

O Docker não é compatível nativamente com o macOS. Então, o Hyperkit é usado para executar uma imagem virtual. Os dados dessa imagem virtual estão localizados em:

~/Library/Containers/com.docker.docker/Data/vms/0

Dentro da imagem virtual, temos o caminho padrão do Docker /var/lib/docker.

Você pode investigar seu diretório raiz do Docker criando um shell no ambiente virtual:

$ screen ~/Library/Containers/com.docker.docker/Data/vms/0/tty 

Você pode encerrar essa sessão pressionando Ctrl+a e, depois, pressionando k e y.

Docker para o Windows

No Windows, o Docker é um pouco fracionado. Há contêineres nativos do Windows que funcionam de forma semelhante aos contêineres do Linux. Os contêineres do Linux são executados em um ambiente virtual mínimo baseado no Hyper-V.

A configuração e a imagem virtual para executar imagens do Linux são salvas no diretório padrão do Docker.

C:\ProgramData\DockerDesktop

Se você inspecionar as imagens normais, verá caminhos do Linux, como, por exemplo:

$ docker inspect nginx

...
"UpperDir": "/var/lib/docker/overlay2/585...9eb/diff"
...

Você pode se conectar com a imagem virtual com:

docker run -it --privileged --pid=host debian nsenter -t 1 -m -u -i sh

Lá, você pode ir até o local referenciado:

$ cd /var/lib/docker/overlay2/585...9eb/
$ ls -lah

drwx------    4 root     root        4.0K Feb  6 06:56 .
drwx------   13 root     root        4.0K Feb  6 09:17 ..
drwxr-xr-x    3 root     root        4.0K Feb  6 06:56 diff
-rw-r--r--    1 root     root          26 Feb  6 06:56 link
-rw-r--r--    1 root     root          57 Feb  6 06:56 lower
drwx------    2 root     root        4.0K Feb  6 06:56 work

A estrutura interna do diretório raiz do Docker

Dentro de /var/lib/docker, informações diversas são armazenadas. Por exemplo, dados de contêineres, volumes, builds, redes e clusters.

$ ls -la /var/lib/docker

total 152
drwx--x--x   15 root     root          4096 Feb  1 13:09 .
drwxr-xr-x   13 root     root          4096 Aug  1  2019 ..
drwx------    2 root     root          4096 May 20  2019 builder
drwx------    4 root     root          4096 May 20  2019 buildkit
drwx------    3 root     root          4096 May 20  2019 containerd
drwx------    2 root     root         12288 Feb  3 19:35 containers
drwx------    3 root     root          4096 May 20  2019 image
drwxr-x---    3 root     root          4096 May 20  2019 network
drwx------    6 root     root         77824 Feb  3 19:37 overlay2
drwx------    4 root     root          4096 May 20  2019 plugins
drwx------    2 root     root          4096 Feb  1 13:09 runtimes
drwx------    2 root     root          4096 May 20  2019 swarm
drwx------    2 root     root          4096 Feb  3 19:37 tmp
drwx------    2 root     root          4096 May 20  2019 trust
drwx------   15 root     root         12288 Feb  3 19:35 volumes

Imagens do Docker

O conteúdo mais pesado são, em geral, as imagens. Se você usar o driver de armazenamento padrão, o overlay2, suas imagens do Docker são armazenadas em /var/lib/docker/overlay2. Lá, você poderá encontrar arquivos diferentes que representam camadas somente para leitura de uma imagem do Docker e uma camada superior que contém suas alterações.

Vamos explorar o conteúdo usando um exemplo:

$ docker image pull nginx
$ docker image inspect nginx

[
    {
        "Id": "sha256:207...6e1",
        "RepoTags": [
            "nginx:latest"
        ],
        "RepoDigests": [
            "nginx@sha256:ad5...c6f"
        ],
        "Parent": "",
 ...
        "Architecture": "amd64",
        "Os": "linux",
        "Size": 126698063,
        "VirtualSize": 126698063,
        "GraphDriver": {
            "Data": {
                "LowerDir": "/var/lib/docker/overlay2/585...9eb/diff:
                             /var/lib/docker/overlay2/585...9eb/diff",
                "MergedDir": "/var/lib/docker/overlay2/585...9eb/merged",
                "UpperDir": "/var/lib/docker/overlay2/585...9eb/diff",
                "WorkDir": "/var/lib/docker/overlay2/585...9eb/work"
            },
...

LowerDir contém as camadas somente para leitura de uma imagem. A camada de leitura e escrita que representa as alterações são parte de UpperDir. Neste caso, a pasta UpperDir do NGINX contém os arquivos de log:

$ ls -la /var/lib/docker/overlay2/585...9eb/diff

total 8
drwxr-xr-x    2 root     root    4096 Feb  2 08:06 .
drwxr-xr-x    3 root     root    4096 Feb  2 08:06 ..
lrwxrwxrwx    1 root     root      11 Feb  2 08:06 access.log -> /dev/stdout
lrwxrwxrwx    1 root     root      11 Feb  2 08:06 error.log -> /dev/stderr

O MergedDir representa o resultado de UpperDir e LowerDir que é usado pelo Docker para executar o contêiner. O WorkDir é um diretório interno para overlay2 e deve estar vazio.

Volumes do Docker

É possível adicionar um armazenamento persistente para contêineres de modo a manter os dados por mais tempo do que a existência do contêiner ou para compartilhar o volume com o host ou com outros contêineres. Um contêiner pode ser iniciado com um volume usando a opção -v:

$ docker run --name nginx_container -v /var/log nginx

Podemos obter informações sobre o local do volume conectado com:

$ docker inspect nginx_container

...
"Mounts": [
            {
                "Type": "volume",
                "Name": "1e4...d9c",
                "Source": "/var/lib/docker/volumes/1e4...d9c/_data",
                "Destination": "/var/log",
                "Driver": "local",
                "Mode": "",
                "RW": true,
                "Propagation": ""
            }
        ],
...

O diretório referenciado contém arquivos do local /var/log do contêiner do NGINX.

$ ls -lah /var/lib/docker/volumes/1e4...d9c/_data

total 88
drwxr-xr-x    4 root     root        4.0K Feb  3 21:02 .
drwxr-xr-x    3 root     root        4.0K Feb  3 21:02 ..
drwxr-xr-x    2 root     root        4.0K Feb  3 21:02 apt
-rw-rw----    1 root     43             0 Jan 30 00:00 btmp
-rw-r--r--    1 root     root       34.7K Feb  2 08:06 dpkg.log
-rw-r--r--    1 root     root        3.2K Feb  2 08:06 faillog
-rw-rw-r--    1 root     43         29.1K Feb  2 08:06 lastlog
drwxr-xr-x    2 root     root        4.0K Feb  3 21:02 nginx
-rw-rw-r--    1 root     43             0 Jan 30 00:00 w

Limpeza do espaço usado pelo Docker

Recomenda-se usar o comando do Docker para limpar contêineres não utilizados. Contêiner, redes, imagens, e o cache criado podem ser limpos executando o seguinte comando:

$ docker system prune -a

Além disso, você pode remover volumes não utilizados com o comando:

$ docker volumes prune

Resumo

O Docker é uma parte importante dos ambientes e do conjunto de ferramentas de muitos desenvolvedores. Às vezes, o Docker pode parecer meio mágico ao resolver problemas de modo muito inteligente sem dizer ao usuário como ele funciona por debaixo dos panos. Ainda assim, ele é uma ferramenta normal, que armazena as partes mais pesadas em locais que podem ser abertos e alterados.

Por vezes, o armazenamento pode encher rapidamente. Desse modo, é útil inspecionar o diretório raiz, mas não é recomendado excluir ou alterar arquivos manualmente dentro dele. Em vez disso, os comandos de prune (ver acima) podem ser usados para liberar espaço em disco.

Esperamos que você tenha gostado do artigo. Se gostou e quiser parabenizar o autor, siga-o no Twitter. O autor trabalha no eBay Kleinanzeigen, uma das maiores empresas de anúncios classificados do mundo inteiro. Falando nisso, eles estão contratando!

Uma boa exploração do Docker para você :)

Referências (em inglês)

• Documentação do storagedriver do Docker
  https://docs.docker.com/storage/storagedriver/
• Documentação do sistema de arquivos OverlayFS
  https://www.kernel.org/doc/Documentation/filesystems/overlayfs.txt

Docker rmi

O comando docker rmi remove as imagens por ID.

Para remover a imagem, primeiro você precisa listar todas as imagens para obter os IDs de imagem, nomes de imagem e outros detalhes. Faça isso executando o comando docker images -a ou docker images.

Depois disso, certifique-se de qual imagem deseja remover, para depois fazer isso executando o comando docker rmi <id-da-imagem>. Em seguida, confirme que a imagem foi removida listando todas as imagens e verificando.

Remover várias imagens

Há uma forma de remover mais de uma imagem por vez quando você quiser remover diversas imagens. Para fazer isso, obtenha os IDs das imagens listando todas elas e execute o comando a seguir.

docker rmi <id-da-imagem> <id-da-imagem> ...

Escreva os IDs das imagens no comando acima com espaços entre eles.

Remover todas as imagens ao mesmo tempo

Para remover todas as imagens, há um comando que faz isso: docker rmi $(docker images -q)

No comando acima, há, de fato, dois comandos. O primeiro, executa em $(), que é a sintaxe do shell, e retorna seja quais forem os resultados executados naquela sintaxe. Enquanto isso, -q- é a opção usada para retornar os IDs exclusivos. $() retorna os resultados dos IDs de imagens e docker rmi remove todas elas.

Para obter mais informações:

• Documentação da Docker CLI: rmi (em inglês)

Docker rm

docker rm remove contêineres por nome ou por ID.

Quando você tem contêineres do Docker em execução, é preciso pará-los primeiro antes de exclui-los.

• Parar todos os contêineres em execução: docker stop $(docker ps -a -q)
• Excluir todos os contêineres parados: docker rm $(docker ps -a -q)

Remover diversos contêineres

Você pode parar e excluir diversos contêineres passando para os comandos uma lista dos contêineres que deseja remover. A sintaxe do shell $() retorna os resultados do que tiver sido executado dentro dos parênteses. Desse modo, você pode criar sua lista de contêineres dentro dela para passar a informação para os comandos stop e rm.

Aqui, você verá um resumo de docker ps -a -q

• docker ps lista contêineres
• -a opção para listar todos os contêineres, mesmo os parados. Sem isso, o padrão é listar apenas os contêineres em execução
• -q opção silenciosa para fornecer apenas os IDs numéricos dos contêineres, em vez de uma tabela inteira de informações sobre os contêineres

Mais informações:

• Documentação da Docker CLI: rm (em inglês)

Mais informações sobre imagens no Docker:

• Docker image guide (em inglês)
• Where are Docker images stored? (em inglês)

Mais informações sobre contêineres no Docker:

• How to automate Docker container deployment (em inglês)
• How to fix Docker container vulnerabilities (em inglês)

Mais informações sobre o Docker:

• A beginner's guide to Docker (em inglês)
• Docker DevOps course (curso gratuito em vídeo) (em inglês)
• Docker 101: from creation to deployment (em inglês)