DEV Community

Celso Nery
Celso Nery

Posted on

Parte 5: Gerenciando Imagens

#docker #linux #devops #build

🇺🇸 English version here

Docker para Desenvolvedores — Parte 5: Gerenciando Imagens

Na Parte 4 desta série, vimos como containers se comunicam através de redes. Agora vamos abordar o ciclo de vida das imagens Docker: como construir a sua própria, listar as que já existem localmente, versioná-las corretamente e publicá-las em um registry — seja o Docker Hub, seja um registry privado.

Construindo uma imagem (build)

Para construir uma imagem a partir de um Dockerfile:

$ docker build -t <nome_da_imagem>:<versao> -f dockerfile .
Enter fullscreen mode Exit fullscreen mode

Onde:

  • -t <nome_da_imagem>:<versao>: define o nome e a tag (versão) da imagem resultante; caso for emitida a versão será criada uma latest;
  • -f dockerfile: indica o arquivo Dockerfile a ser usado (útil quando você tem múltiplos Dockerfiles no mesmo diretório, ou um nome de arquivo diferente do padrão); caso tenha somente um Dockerfile na raiz do projeto, este argumento pode ser omitido;
  • .: define o contexto de build — o diretório cujo conteúdo fica disponível para instruções como COPY e ADD dentro do Dockerfile.

Exemplo de um Dockerfile

FROM nginx:alpine
RUN apk update && apk upgrade --no-cache
WORKDIR /usr/share/nginx/html
COPY ./index.html ./
EXPOSE 80
CMD [ "nginx", "-g", "daemon off;" ]
Enter fullscreen mode Exit fullscreen mode
  • FROM: Informa a imagem base a ser usada.
  • RUN: Comandos para rodar para buildar a aplicação antes de buildar a imagem.
  • WORKDIR: Informa local interno na imagem onde se está trabalhando no momento.
  • COPY: Comando para copiar arquivos da aplicação local para dentro da imagem docker.
  • EXPOSE: Informa a porta que o container ira escutar.
  • CMD: Comando de execução final da aplicação. (Neste caso estou rodando o nginx).

Listando imagens

Para ver todas as imagens já baixadas ou construídas localmente:

$ docker image ls
Enter fullscreen mode Exit fullscreen mode

Versionando imagens (tag)

Antes de publicar uma imagem em um registry, geralmente é preciso "marcá-la" (tag) com o endereço completo do destino:

$ docker tag <nome_da_imagem_local>:<versao> <registro_remoto>/<nome_da_imagem_remoto>:<versao>
Enter fullscreen mode Exit fullscreen mode

Por exemplo, marcando uma imagem local myapp:1.0.0 para o Docker Hub, sob o usuário celsonery:

$ docker tag myapp:1.0.0 celsonery/myapp:1.0.0
Enter fullscreen mode Exit fullscreen mode

Ou para um registry privado:

$ docker tag myapp:1.0.0 registry.suaempresa.com/myapp:1.0.0
Enter fullscreen mode Exit fullscreen mode

É considerada boa prática usar versionamento semântico nas tags (1.0.0, 1.0.1, 1.1.0) em vez de depender apenas da tag latest, já que latest não indica qual versão exata está rodando em produção.

Removendo imagens

Para remover uma imagem específica:

$ docker image rm <nome_da_imagem>:<versao>
Enter fullscreen mode Exit fullscreen mode

Limpando imagens não utilizadas

Imagens intermediárias e não referenciadas por nenhum container tendem a se acumular ao longo do tempo, ocupando espaço em disco. Para limpar:

$ docker image prune
Enter fullscreen mode Exit fullscreen mode

Publicando uma imagem (push)

Para publicar uma imagem, primeiramente é preciso autenticar-se em algum registry.

  • Docker Hub (padrão) 
$ docker login
Enter fullscreen mode Exit fullscreen mode
  • Registry privado

Quando o destino não é o Docker Hub, é preciso informar o endereço do servidor:

$ docker login registry.suaempresa.com
Enter fullscreen mode Exit fullscreen mode
  • Push para o Docker Hub 
$ docker push <nome_da_imagem>:<versao>
Enter fullscreen mode Exit fullscreen mode
  • Push para um registry privado 
$ docker push <registry>/<nome_da_imagem>:<versao>
Enter fullscreen mode Exit fullscreen mode

Lembre-se: a imagem precisa ter sido taggeada (passo anterior) com o endereço completo do registro de destino antes do push — caso contrário, o Docker tentará enviá-la para o Docker Hub por padrão.

Próximos passos

Com o ciclo completo de imagens dominado — build, tag, push —, você já consegue distribuir suas próprias aplicações como imagens versionadas. Na Parte 6, e última desta série, vamos juntar tudo o que vimos até aqui (volumes, redes, múltiplos containers) usando o Docker Compose, tornando o gerenciamento de aplicações com múltiplos serviços muito mais simples e organizado.

Continua na Parte 6.

Top comments (0)