🇺🇸 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 .
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 comoCOPYeADDdentro 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;" ]
-
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
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>
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
Ou para um registry privado:
$ docker tag myapp:1.0.0 registry.suaempresa.com/myapp:1.0.0
É 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 taglatest, já quelatestnã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>
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
Publicando uma imagem (push)
Para publicar uma imagem, primeiramente é preciso autenticar-se em algum registry.
- Docker Hub (padrão)
$ docker login
- Registry privado
Quando o destino não é o Docker Hub, é preciso informar o endereço do servidor:
$ docker login registry.suaempresa.com
- Push para o Docker Hub
$ docker push <nome_da_imagem>:<versao>
- Push para um registry privado
$ docker push <registry>/<nome_da_imagem>:<versao>
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.
