Uma rápida introdução às tags no Docker

Artigo original: https://www.freecodecamp.org/news/an-introduction-to-docker-tags-9b5395636c2a/

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.