DEV Community: Celso Nery

Part 6: Automating with Docker Compose

Celso Nery — Tue, 18 Aug 2026 23:16:51 +0000

Using Docker — Part 6: Automating with Docker Compose

Throughout this series, we've covered containers, volumes, networks, and image management — always using individual commands like docker run, docker network create, docker volume create, etc. That works, but it becomes tedious (and error-prone) once an application starts depending on multiple services. That's where Docker Compose comes in: it lets you describe all of this configuration in a single declarative file, making the process cleaner, easier to repeat, and easier to version in a Git repository.

Creating your docker-compose.yaml

A minimal docker-compose.yaml

The simplest possible structure, running a single service:

services:
  web:
    image: httpd
    ports:
      - "80:80"

This is already equivalent to running docker run -p 80:80 httpd — but in a declarative, reapplyable, and easily versioned way.

Adding a volume

To persist that service's data (as we saw in Part 3 of this series), just add a volumes section:

services:
  web:
    image: httpd
    ports:
      - "80:80"
    volumes:
      - web-data:/usr/local/apache2/htdocs

volumes:
  web-data:

Notice the volume needs to be declared in two places: referenced inside the service (volumes: under web) and defined in the root-level volumes: section at the end of the file — that's where Compose actually creates the named volume.

Adding a network

Likewise, you can declare custom networks (covered in Part 4):

services:
  web:
    image: httpd
    ports:
      - "80:80"
    volumes:
      - web-data:/usr/local/apache2/htdocs
    networks:
      - app-network

volumes:
  web-data:

networks:
  app-network:

In practice, when you don't explicitly declare a network, Compose already creates a default network for the project automatically, allowing services within the same docker-compose.yaml to see each other by name. Declaring networks manually is worth it when you need more than one isolated network, or want to connect services across different Compose files.

Bringing up the containers

To create and start all the services defined in the file:

$ docker compose up

Just like with docker run, the terminal stays "stuck," showing the logs of all services. To run it in the background:

$ docker compose up -d

Tearing down the containers

To stop and remove the containers and networks, while (by default) preserving the volumes created by Compose:

$ docker compose down

By default, docker compose down does not remove volumes — this prevents accidental data loss. If you want to remove volumes too, use docker compose down -v (with caution).

Bringing multiple containers together: App + Database + Redis

Compose's real power shows up when an application depends on multiple services working together. A common example: an Nginx proxy in front, an application, a MySQL database, and a Redis cache.

services:
  nginx:
    image: nginx:latest
    ports:
      - "80:80"
    volumes:
      - ./nginx.conf:/etc/nginx/conf.d/default.conf:ro
    depends_on:
      - app
    networks:
      - app-network

  app:
    image: myapp:1.0.0
    environment:
      DB_HOST: db
      DB_USER: appuser
      DB_PASSWORD: apppassword
      REDIS_HOST: redis
    depends_on:
      - db
      - redis
    networks:
      - app-network

  db:
    image: mysql:8.0
    environment:
      MYSQL_ROOT_PASSWORD: rootpassword
      MYSQL_DATABASE: appdb
      MYSQL_USER: appuser
      MYSQL_PASSWORD: apppassword
    volumes:
      - db-data:/var/lib/mysql
    networks:
      - app-network

  redis:
    image: redis:alpine
    networks:
      - app-network

volumes:
  db-data:

networks:
  app-network:

A few important points from this example:

depends_on: defines the startup order of the containers (app only starts after db and redis). Note this only guarantees the starting order of the container, not that the internal service (like MySQL) is already ready to accept connections — for that, the application usually needs to implement some retry logic on the database connection;
Environment variables (environment): used to configure the application and MySQL without needing to modify images or hardcode values;
db-data: a named volume ensuring MySQL's data survives container restarts and recreations;
app-network: all services share the same network, letting them communicate with each other by service name (db, redis) instead of fixed IPs.

Bringing everything up at once:

$ docker compose up -d

With a single command, Compose creates the network, the volumes, and brings up all four containers already connected and ready to talk to each other.

Series wrap-up

Throughout this series, we covered the complete day-to-day Docker lifecycle: installation, essential CLI commands, data persistence with volumes, container-to-container communication via networks, image management and publishing, and finally, orchestrating multiple services with Docker Compose. With this foundation, you now have everything you need to run containerized applications professionally — whether in a local development environment or on a production server.

For anyone looking to go beyond a single host, the natural next step is Kubernetes — which solves the same orchestration problems, but at scale, distributing containers across multiple servers.

Part 5: Managing Images

Celso Nery — Tue, 18 Aug 2026 23:15:22 +0000

🇧🇷 Artigo em português aqui

Using Docker — Part 5: Managing Images

In Part 4 of this series, we covered how containers communicate through networks. Now let's tackle the lifecycle of Docker images: how to build your own, list the ones already available locally, version them correctly, and publish them to a registry — whether Docker Hub or a private registry.

Building an image

To build an image from a Dockerfile:

$ docker build -t <image_name>:<version> -f dockerfile .

Where:

-t <image_name>:<version>: sets the name and tag (version) of the resulting image; if the version is released, a 'latest' version will be created;
-f dockerfile: specifies which Dockerfile to use (useful when you have multiple Dockerfiles in the same directory, or a non-default filename); if there is only one Dockerfile at the project root, this argument can be omitted;
.: sets the build context — the directory whose contents become available to instructions like COPY and ADD inside the Dockerfile.

Dockerfile example:

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: Specifies the base image to be used.
RUN: Commands to execute in order to build the application before building the image.
WORKDIR: Specifies the internal location within the image where operations are currently taking place.
COPY: Command to copy files from the local application into the Docker image.
EXPOSE: Specifies the port the container will listen on.
CMD: Command for the final execution of the application. (In this case, I am running Nginx).

Listing images

To see all images already downloaded or built locally:

$ docker image ls

Versioning images (tag)

Before publishing an image to a registry, you generally need to "tag" it with the full destination address:

$ docker tag <local_image_name>:<version> <remote_registry>/<remote_image_name>:<version>

For example, tagging a local myapp:1.0.0 image for Docker Hub, under the user celsonery:

$ docker tag myapp:1.0.0 celsonery/myapp:1.0.0

Or for a private registry:

$ docker tag myapp:1.0.0 registry.yourcompany.com/myapp:1.0.0

It's considered good practice to use semantic versioning in your tags (1.0.0, 1.0.1, 1.1.0) instead of relying solely on the latest tag, since latest doesn't indicate exactly which version is running in production.

Removing images

To remove a specific image:

$ docker image rm <image_name>:<version>

Cleaning up unused images

Intermediate images and images no longer referenced by any container tend to pile up over time, taking up disk space. To clean up:

$ docker image prune

Publishing an image (push)

To publish an image, you must first authenticate with a registry.

Docker Hub (default)

$ docker login

Private registry

When the destination isn't Docker Hub, you need to provide the server address:

$ docker login registry.yourcompany.com

Push to Docker Hub

$ docker push <image_name>:<version>

Push to a private registry

$ docker push <registry>/<image_name>:<version>

Remember: the image needs to have been tagged (previous step) with the full destination registry address before the push — otherwise, Docker will try to send it to Docker Hub by default.

Next steps

With the complete image lifecycle covered — build, tag, push —, you can now distribute your own applications as versioned images. In Part 6, the last of this series, we'll bring everything we've covered together (volumes, networks, multiple containers) using Docker Compose, making it much simpler and more organized to manage applications with multiple services.

Continued in Part 6.

Part 4: Working with Networks

Celso Nery — Tue, 18 Aug 2026 23:13:48 +0000

🇧🇷 Artigo em português aqui

Using Docker — Part 4: Working with Networks

In Part 3 of this series, we covered persisting data with volumes. Now let's tackle another fundamental pillar of multi-container applications: networking. When an application depends on several services (for example, an API that needs to talk to a database), those containers need to be able to communicate with each other — and that's what Docker networks make possible.

Listing networks

Docker already creates a few default networks on installation (bridge, host, none). To list all existing networks:

$ docker network ls

Creating a network

To create a custom network, isolated from the others:

$ docker network create <network_name>

Containers connected to the same custom network can communicate with each other using the container name as the hostname — no need to discover or hardcode IP addresses manually.

Inspecting a network

To see details about a network — such as the IP range, driver used, and which containers are connected to it:

$ docker network inspect <network_name>

Running a container already connected to a network

To create a container and connect it to a specific network right at creation time:

$ docker run -it -d --rm --net <network_name> httpd

Connecting a running container to a network

If the container is already running and you want to add it to an additional network (a container can belong to multiple networks at once):

$ docker network connect --ip 192.168.100.10 <network_name> httpd

The --ip flag lets you pin a specific IP for the container within that network — useful when other applications need a predictable address to connect to.

Disconnecting a container from a network

$ docker network disconnect <network_name> httpd

Removing a network

$ docker network rm <network_name>

A network can only be removed if no container is currently connected to it.

Cleaning up unused networks

Just like with volumes, it's common to accumulate orphaned networks over time. To remove all networks not currently used by any container:

$ docker network prune

Why this matters

Running isolated containers without a custom network works fine for quick tests — but as soon as an application needs multiple services talking to each other (app + database + cache, for example), custom networks stop being optional. They provide isolation (containers from different projects can't see each other by default) and simple name-based communication, without relying on manually managed fixed IPs.

Next steps

With volumes for persistence and networks for communication between containers, we now have the two fundamental pieces needed to run multi-service applications. In Part 5 of this series, we'll cover image management: how to build, version (tag), and publish your own images to a registry.

Continued in Part 5.

Part 3: Persisting Data with Volumes

Celso Nery — Tue, 18 Aug 2026 23:12:00 +0000

🇧🇷 Artigo em português aqui

Using Docker — Part 3: Persisting Data with Volumes

In Part 2 of this series, we covered the essential commands for operating containers day to day. But there's an important detail: by default, data written inside a container is ephemeral — if the container is removed, that data disappears with it. For stateful applications (databases, user uploads, configuration files), that's a problem. That's what volumes exist to solve.

Bind mount vs. Volume

There are two main ways to persist data outside a container's lifecycle:

Bind mount: mounts a specific folder from the host (the machine running Docker) inside the container. You have full control over where the data lives on the host, but you become more dependent on that specific machine's folder structure.
Volume: managed by Docker itself, stored in an internal area (/var/lib/docker/volumes/ on Linux). This is the recommended approach for most cases, since it's more portable across environments and easier to back up, inspect, and clean up.

This article focuses on volumes — the recommended approach for professional use.

Creating a volume

To create a named volume that will store an application's data:

docker volume create vol_name

Listing volumes

To see all volumes that already exist on the system:

docker volume ls

Inspecting a volume

To see details about a specific volume — such as the actual path where the data is stored on the host:

docker volume inspect vol_name

Running a container with a volume `-v`

Using a bind mount

docker run --rm -d -it -v local_folder:remote_folder httpd

Here, local_folder is an absolute path on the host (for example, /home/celso/data), and remote_folder is the path inside the container where that data should appear (for example, /var/www/htdocs/).

Using a created volume

docker run --rm -d -it -v volume_name:remote_folder httpd

In this case, volume_name is the name of the volume created earlier with docker volume create — Docker handles where that data is physically stored.

Removing a volume

If any container is still using the volume, you'll need to remove the container first:

docker rm <container_name>

Then, to remove the volume:

docker volume rm vol_name

Cleaning up unused volumes

Over time, it's common to accumulate orphaned volumes (created by containers that have since been removed). To clean up all volumes not currently used by any container:

docker volume prune

⚠️ This command permanently removes the data of any volume not referenced by an active container — confirm before running this on an environment with important data.

Using NFS volumes

In environments with multiple Docker hosts (or when you want to share data across different servers), you can create a volume pointing to an NFS share instead of local storage:

docker volume create --opt type=nfs --opt o=addr=10.0.0.35,rw,nfsvers=4 --opt device=:/home/nfsshare nfs-volume

Where:

type=nfs: sets the volume driver to NFS;
o=addr=10.0.0.35,rw,nfsvers=4: NFS server address and mount options (read/write, protocol version);
device=:/home/nfsshare: path exported by the NFS server;
nfs-volume: name given to the volume in Docker.

This is especially useful in scenarios where multiple containers (possibly on different hosts) need access to the same shared data set.

Next steps

With volumes handling data persistence, the next challenge is communication between containers — especially when an application depends on multiple services (for example, an API that needs to talk to a database). In Part 4 of this series, we'll look at how to create and manage networks in Docker.

Continued in Part 4.

Part 2: Essential CLI Commands

Celso Nery — Tue, 18 Aug 2026 23:10:25 +0000

🇧🇷 Artigo em português aqui

Using Docker — Part 2: Essential CLI Commands

In Part 1 of this series, we installed Docker on Debian and ran our first container. Now let's cover the commands you'll use day to day to manage containers: running, listing, entering, stopping, removing, tailing logs, and monitoring resources.

Running a container

The most basic command is docker run, which creates and starts a container from a builded image:

$ docker run --rm -p 8080:80 httpd

Where:

--rm: automatically removes the container as soon as it stops (useful for tests, avoiding a pile-up of stopped containers);
-p 8080:80: maps port 8080 of the host to port 80 of the container.

Running this command keeps the terminal "stuck," showing the container's logs in the foreground. To free up the terminal and run it in the background, use the -d (daemon) flag:

$ docker run --rm -d -p 8080:80 httpd

Listing containers

To see the containers that are currently running:

$ docker ps

To see all containers, including the ones that have already stopped, use the -a flag:

$ docker ps -a

This is useful for spotting stopped containers that might not have been removed (because they weren't run with the --rm flag).

Connecting a container

To interactively enter a running container (opening a shell):

$ docker exec -it <container name or ID> bash

If the image is Alpine-based (as many lightweight production images are), it usually doesn't have bash installed — use ash instead:
$ docker exec -it <container name or ID> ash

Now you can run any command inside container to check cat /etc/os-release ou env.

You can also run a specific command without opening an interactive session — for example, to check an environment variable:

$ docker exec -it <container name or ID> env

This way, you won't need to enter the container.

Stopping and removing containers

To stop a running container:

$ docker stop <container name or ID>

Stopping doesn't remove the container — it continues to exist (stopped), until you explicitly remove it or it was created with --rm.

To remove it manually:

$ docker rm <container name or ID>

Tailing logs

Containers typically write their logs to stdout/stderr, and Docker captures that automatically. To view them (and follow in real time, like tail -f):

$ docker logs -f <container name or ID>

Without the -f flag, the command just prints the existing logs up to that point, without continuing to follow.

Monitoring resources

To see, in real time, the CPU, memory, disk I/O, and network usage of all running containers:

$ docker stats

This command is useful for quickly identifying containers consuming excessive resources, without needing external monitoring tools.

Next steps

With the essential CLI commands in hand, you can already operate containers day to day with confidence. But so far, data inside containers is ephemeral — if the container is removed, the data goes with it. In Part 3 of this series, we'll solve that with volumes, ensuring data persistence between runs.

Continued in Part 3.

Part 1: Installing on Debian

Celso Nery — Tue, 18 Aug 2026 23:08:49 +0000

🇧🇷 Artigo em português aqui

Docker for Devs — Part 1: Installing on Debian

This is the first part of a series on using Docker day to day: installation, CLI usage, volumes, networks, image management, and Docker Compose. The goal is to start from scratch and build up to a complete, professional workflow with Docker.

In this first part, we cover the complete installation on Debian — from scratch to running your first container.

Use sudo before the commands below if you're running them as a regular user (not root).

Updating the system

Before installing any new package, update the package list and the system:

# apt update
# apt upgrade

Installing required packages

A few packages are prerequisites for safely adding external repositories (GPG keys, HTTPS, etc.):

# apt install curl gnupg2 apt-transport-https software-properties-common ca-certificates

Adding the Docker repository

Download and register Docker's official GPG key:

# curl -fsSL https://download.docker.com/linux/debian/gpg | gpg --dearmor -o /etc/apt/trusted.gpg.d/docker.gpg

Create the repository file at /etc/apt/sources.list.d/docker.list and add this content:

deb [arch=amd64 signed-by=/etc/apt/trusted.gpg.d/docker.gpg] https://download.docker.com/linux/debian bookworm stable

⚠️ Watch your Debian version: the codename (bookworm, in the example) needs to match your Debian version — bookworm is Debian 12, bullseye is Debian 11, buster is Debian 10. To find out your installation's codename, run:
$ lsb_release -cs

or

$ cat /etc/os-release
And replace bookworm with the returned value, if you're on a different version.

Container runtime: Docker or containerd?

If the end goal is building a Kubernetes cluster, it's worth pausing here: Kubernetes hasn't used Docker directly as its runtime since version 1.24 — it relies on containerd (which, as it happens, already ships alongside the Docker Engine installation, but can also be installed standalone). If that's your case, skip straight to the Kubernetes installation article, which covers installing containerd specifically for that scenario.

If your goal is to use the full Docker Engine (to run standalone containers, Docker Compose, etc.), continue with the steps below.

Installing Docker

# apt update
# apt install docker-ce

If you run into issues running containers with the latest version, you can install a previous version, such as 18.06.0:
# apt install docker-ce=18.06.0~ce~3-0~debian

Configuring the daemon

Create the /etc/docker/daemon.json file with the following settings:

{
    "exec-opts": ["native.cgroupdriver=systemd"],
    "log-driver": "json-file",
    "log-opts": {
        "max-size": "100m"
        },
    "storage-driver": "overlay2"
}

This configuration:

Uses systemd as the cgroup driver (important for staying consistent with other systemd-managed services on the system, including Kubernetes itself, if you install it later);
Limits each container's log size to 100MB, preventing "noisy" containers from filling up the disk with logs;
Uses the overlay2 storage driver, currently recommended for most use cases.

Create the Docker systemd service override directory:

# mkdir -p /etc/systemd/system/docker.service.d

Reload and restart the service:

systemctl daemon-reload
systemctl restart docker

Allowing a regular user to use Docker

By default, Docker commands require root privileges. To let a regular user run containers without needing sudo for every command, add them to the docker group:

# usermod -aG docker $USER

You need to log out and log back in (or restart your session) for the group change to take effect.

Verifying the installation

Confirm Docker is installed and working:

$ docker version

The output should look similar to this:

Client:
 Version:           18.06.0-ce
 API version:       1.38
 Go version:        go1.10.3
 Git commit:        0ffa825
 Built:             Wed Jul 18 19:09:33 2018
 OS/Arch:           linux/amd64
 Experimental:      false

Server:
 Engine:
  Version:          18.06.0-ce
  API version:      1.38 (minimum version 1.12)
  Go version:       go1.10.3
  Git commit:       0ffa825
  Built:            Wed Jul 18 19:07:38 2018
  OS/Arch:          linux/amd64
  Experimental:     false

The version shown will vary depending on what's installed on your system — the example above reflects version 18.06.0.

Running your first container

The classic test, using Docker's official example image:

$ docker run hello-world

Or, for a slightly more tangible test, spinning up an Apache web server (httpd) on port 80:

$ docker run --rm -p 8080:80 httpd

To confirm it worked, open your browser and access the host machine's IP:

http://127.0.0.1:8080

If Apache's default page shows up, the Docker installation is complete and working correctly.

Next steps

With Docker installed, configured with the correct cgroup driver, and successfully tested, the server is now ready for day-to-day container work. In Part 2 of this series, we'll explore the most commonly used Docker CLI commands: run, ps, exec, stop, rm, logs, and stats.

Continued in Part 2.

Parte 6: Automatizando com Docker Compose

Celso Nery — Tue, 18 Aug 2026 23:01:59 +0000

🇺🇸 English version here

Docker para Desenvolvedores — Parte 6: Automatizando com Docker Compose

Ao longo desta série, vimos containers, volumes, redes e gerenciamento de imagens — sempre usando comandos individuais do docker run, docker network create, docker volume create, etc. Isso funciona, mas se torna trabalhoso (e propenso a erros) conforme uma aplicação passa a depender de múltiplos serviços. É aí que o Docker Compose entra: ele permite descrever toda essa configuração em um único arquivo declarativo, tornando o processo mais limpo, mais fácil de repetir e de versionar em um repositório Git.

Criando seu docker-compose.yaml

Um docker-compose.yaml mínimo

A estrutura mais simples possível, rodando um único serviço:

services:
  web:
    image: httpd
    ports:
      - "8080:80"

Isso já é equivalente a rodar docker run -p 8080:80 httpd — mas de forma declarativa, reaplicável e fácil de versionar.

Acrescentando um volume

Para persistir dados desse serviço (como vimos na Parte 3 desta série), basta adicionar uma seção volumes:

services:
  web:
    image: httpd
    ports:
      - "8080:80"
    volumes:
      - web-data:/usr/local/apache2/htdocs

volumes:
  web-data:

Repare que o volume precisa ser declarado em dois lugares: referenciado dentro do serviço (volumes: dentro de web) e definido na seção raiz volumes: no final do arquivo — é ali que o Compose realmente cria o volume nomeado.

Acrescentando uma rede

Da mesma forma, é possível declarar redes customizadas (vistas na Parte 4):

services:
  web:
    image: httpd
    ports:
      - "80:80"
    volumes:
      - web-data:/usr/local/apache2/htdocs
    networks:
      - app-network

volumes:
  web-data:

networks:
  app-network:

Na prática, quando você não declara uma rede explicitamente, o Compose já cria uma rede padrão para o projeto automaticamente, permitindo que os serviços do mesmo docker-compose.yaml se enxerguem entre si pelo nome. Declarar redes manualmente vale a pena quando você precisa de mais de uma rede isolada, ou quer conectar serviços de arquivos Compose diferentes.

Subindo os containers

Para criar e iniciar todos os serviços definidos no arquivo:

$ docker compose up

Assim como no docker run, o terminal fica preso mostrando os logs de todos os serviços. Para rodar em segundo plano:

$ docker compose up -d

Derrubando os containers

Para parar e remover os containers, redes e (por padrão) preservar os volumes criados pelo Compose:

$ docker compose down

Por padrão, docker compose down não remove volumes — isso evita perda acidental de dados. Se você quiser remover os volumes também, use docker compose down -v (com cautela).

Juntando vários containers: App + Database + Redis

O verdadeiro poder do Compose aparece quando uma aplicação depende de múltiplos serviços trabalhando juntos. Um exemplo comum: um proxy Nginx na frente, uma aplicação, um banco de dados MySQL e um cache Redis.

services:
  nginx:
    image: nginx:latest
    ports:
      - "80:80"
    volumes:
      - ./nginx.conf:/etc/nginx/conf.d/default.conf:ro
    depends_on:
      - app
    networks:
      - app-network

  app:
    image: myapp:1.0.0
    environment:
      DB_HOST: db
      DB_USER: appuser
      DB_PASSWORD: apppassword
      REDIS_HOST: redis
    depends_on:
      - db
      - redis
    networks:
      - app-network

  db:
    image: mysql:8.0
    environment:
      MYSQL_ROOT_PASSWORD: rootpassword
      MYSQL_DATABASE: appdb
      MYSQL_USER: appuser
      MYSQL_PASSWORD: apppassword
    volumes:
      - db-data:/var/lib/mysql
    networks:
      - app-network

  redis:
    image: redis:alpine
    networks:
      - app-network

volumes:
  db-data:

networks:
  app-network:

Alguns pontos importantes desse exemplo:

depends_on: define a ordem de inicialização dos containers (o app só sobe depois do db e do redis). Vale notar que isso garante apenas a ordem de início do container, não que o serviço interno (como o MySQL) já esteja pronto para aceitar conexões — para isso, a aplicação normalmente precisa implementar alguma lógica de retry na conexão com o banco;
Variáveis de ambiente (environment): usadas para configurar a aplicação e o MySQL sem precisar alterar imagens ou hardcodar valores;
db-data: volume nomeado garantindo que os dados do MySQL sobrevivam a reinicializações e recriações do container;
app-network: todos os serviços compartilham a mesma rede, permitindo que se comuniquem entre si pelo nome do serviço (db, redis) em vez de IPs fixos.

Subindo tudo de uma vez:

$ docker compose up -d

Com um único comando, o Compose cria a rede, os volumes, e sobe os quatro containers já conectados e prontos para se comunicar entre si.

Considerações finais da série

Ao longo desta série, cobrimos o ciclo completo do Docker no dia a dia: instalação, comandos essenciais da CLI, persistência de dados com volumes, comunicação entre containers via redes, gerenciamento e publicação de imagens, e, por fim, orquestração de múltiplos serviços com Docker Compose. Com essa base, você já tem tudo o que precisa para rodar aplicações containerizadas de forma profissional — seja em um ambiente de desenvolvimento local, seja em um servidor de produção.

Para quem quiser ir além de um único host, o próximo passo natural é o Kubernetes — que resolve os mesmos problemas de orquestração, mas em escala, distribuindo containers entre múltiplos servidores.

Você pode encontrar uma série de artigo que fiz sobre kubernetes

Parte 5: Gerenciando Imagens

Celso Nery — Tue, 18 Aug 2026 23:00:15 +0000

🇺🇸 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 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;" ]

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

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.

Parte 4: Trabalhando com Redes

Celso Nery — Tue, 18 Aug 2026 22:53:22 +0000

🇺🇸 English version here

Docker para Desenvolvedores — Parte 4: Trabalhando com Redes

Na Parte 3 desta série, vimos como persistir dados com volumes. Agora vamos abordar outro pilar fundamental de aplicações com múltiplos containers: a rede. Quando uma aplicação depende de vários serviços (por exemplo, uma API que precisa conversar com um banco de dados), esses containers precisam conseguir se comunicar entre si — e é isso que as redes do Docker viabilizam.

Listando redes

O Docker já cria algumas redes padrão na instalação (bridge, host, none). Para listar as redes existentes:

$ docker network ls

Criando uma rede

Para criar uma rede customizada, isolada das demais:

$ docker network create <nome_da_rede>

Containers conectados à mesma rede customizada conseguem se comunicar entre si usando o nome do container como hostname — sem precisar descobrir ou fixar endereços IP manualmente.

Inspecionando uma rede

Para ver detalhes de uma rede — como o range de IPs, driver usado e quais containers estão conectados a ela:

$ docker network inspect <nome_da_rede>

Rodando um container já conectado a uma rede

Para criar um container e já conectá-lo a uma rede específica no momento da criação:

$ docker run -it -d --rm --net <nome_da_rede> httpd

Conectando um container já em execução a uma rede

Se o container já está rodando e você quer adicioná-lo a uma rede adicional (um container pode pertencer a múltiplas redes simultaneamente):

$ docker network connect --ip 192.168.100.10 <nome_da_rede> httpd

A flag --ip permite fixar um IP específico para o container dentro dessa rede — útil quando outras aplicações precisam de um endereço previsível para se conectar.

Desconectando um container de uma rede

$ docker network disconnect <nome_da_rede> httpd

Removendo uma rede

$ docker network rm <nome_da_rede>

Uma rede só pode ser removida se não houver nenhum container conectado a ela no momento.

Limpando redes não utilizadas

Assim como acontece com volumes, é comum acumular redes órfãs ao longo do tempo. Para remover todas as redes que não estão sendo usadas por nenhum container:

$ docker network prune

Por que isso importa

Rodar containers isolados, sem uma rede customizada, funciona para testes rápidos — mas assim que uma aplicação precisa de múltiplos serviços conversando entre si (app + banco de dados + cache, por exemplo), redes customizadas deixam de ser opcionais. Elas garantem isolamento (containers de projetos diferentes não se enxergam por padrão) e comunicação simples por nome, sem depender de IPs fixos gerenciados manualmente.

Próximos passos

Com volumes para persistência e redes para comunicação entre containers, já temos as duas peças fundamentais para rodar aplicações multi-serviço. Na Parte 5 desta série, vamos falar sobre gerenciamento de imagens: como construir, versionar (tag) e publicar suas próprias imagens em um registry.

Continua na Parte 5.

Parte 3: Persistindo Dados com Volumes

Celso Nery — Tue, 18 Aug 2026 22:51:29 +0000

🇺🇸 English version here

Docker para Desenvolvedores — Parte 3: Persistindo Dados com Volumes

Na Parte 2 desta série, vimos os comandos essenciais para operar containers no dia a dia. Mas há um detalhe importante: por padrão, os dados escritos dentro de um container são efêmeros — se o container for removido, esses dados desaparecem junto. Para aplicações com estado (bancos de dados, uploads de usuários, arquivos de configuração), isso é um problema. É para resolver isso que existem os volumes.

Bind mount x Volume

Existem duas formas principais de persistir dados fora do ciclo de vida do container:

Bind mount: monta uma pasta específica do host (a máquina onde o Docker roda) dentro do container. Você tem controle total sobre onde os dados ficam no host, mas fica mais dependente da estrutura de pastas daquela máquina específica.
Volume: gerenciado pelo próprio Docker, armazenado em uma área interna (/var/lib/docker/volumes/ no Linux). É a forma recomendada para a maioria dos casos, pois é mais portável entre ambientes e mais fácil de fazer backup, inspecionar e limpar.

Este artigo foca em volumes — a abordagem mais indicada para uso profissional.

Criando um volume

Para criar um volume nomeado, que vai armazenar os dados de uma aplicação:

docker volume create nome_do_vol

Listando volumes

Para ver todos os volumes já existentes no sistema:

docker volume ls

Inspecionando um volume

Para ver detalhes de um volume específico — como o caminho real onde os dados ficam armazenados no host:

docker volume inspect nome_do_vol

Rodando um container com um volume `-v`

Usando bind mount

docker run --rm -d -it -v pasta_local:pasta_remota httpd

Aqui, pasta_local é um caminho absoluto no host (por exemplo, /home/celso/dados), e pasta_remota é o caminho dentro do container onde esses dados devem aparecer (por exemplo, /var/www/htdocs/).

Usando um volume criado

docker run --rm -d -it -v nome_do_volume:pasta_remota httpd

Nesse caso, nome_do_volume é o nome do volume criado anteriormente com docker volume create — o Docker cuida de onde esses dados ficam fisicamente armazenados.

Removendo um volume

Se algum container ainda estiver usando o volume, será preciso remover o container primeiro:

docker rm <nome_do_container>

Depois, para remover o volume:

docker volume rm nome_do_vol

Limpando volumes não utilizados

Com o tempo, é comum acumular volumes órfãos (criados por containers que já foram removidos). Para limpar todos os volumes que não estão sendo usados por nenhum container:

docker volume prune

⚠️ Esse comando remove permanentemente os dados de qualquer volume não referenciado por um container ativo — confirme antes de rodar em um ambiente com dados importantes.

Usando volumes NFS

Em ambientes com múltiplos hosts Docker (ou quando você quer compartilhar dados entre diferentes servidores), é possível criar um volume que aponta para um compartilhamento NFS em vez de armazenamento local:

docker volume create --opt type=nfs --opt o=addr=10.0.0.35,rw,nfsvers=4 --opt device=:/home/nfsshare nfs-volume

Onde:

type=nfs: define o driver de volume como NFS;
o=addr=10.0.0.35,rw,nfsvers=4: endereço do servidor NFS e opções de montagem (leitura/escrita, versão do protocolo);
device=:/home/nfsshare: caminho exportado pelo servidor NFS;
nfs-volume: nome dado ao volume no Docker.

Isso é especialmente útil em cenários onde múltiplos containers (possivelmente em hosts diferentes) precisam acessar o mesmo conjunto de dados compartilhado.

Próximos passos

Com volumes garantindo persistência de dados, o próximo desafio é a comunicação entre containers — especialmente quando uma aplicação depende de vários serviços (por exemplo, uma API que precisa falar com um banco de dados). Na Parte 4 desta série, vamos ver como criar e gerenciar redes no Docker.

Continua na Parte 4.

Parte 2: Comandos Essenciais da CLI

Celso Nery — Tue, 18 Aug 2026 22:45:46 +0000

🇺🇸 English version here

Docker para Desenvolvedores — Parte 2: Comandos Essenciais da CLI

Na Parte 1 desta série, instalamos o Docker no Debian e rodamos nosso primeiro container. Agora vamos conhecer os comandos que você vai usar no dia a dia para gerenciar containers: rodar, listar, entrar, parar, remover, acompanhar logs e monitorar recursos.

Rodando um container

O comando mais básico é o docker run, que cria e inicia um container a partir de uma imagem pronta:

$ docker run --rm -p 8080:80 httpd

Onde:

--rm: remove o container automaticamente assim que ele parar (útil para testes, evitando acumular containers parados);
-p 8080:80: mapeia a porta 8080 do host(sua máquina) para a porta 80 do container.

Rodando esse comando, o terminal fica "preso" mostrando os logs do container em primeiro plano. Para liberar o terminal e rodar em segundo plano, use a flag -d (daemon):

$ docker run --rm -d -p 8080:80 httpd

Listando containers

Para ver os containers que estão em execução no momento:

$ docker ps

Para ver todos os containers, incluindo os que já pararam, use a flag -a:

$ docker ps -a

Isso é útil para identificar containers parados que talvez não tenham sido removidos (por não terem usado a flag --rm).

Entrando em um container

Para entrar interativamente em um container já em execução "abrindo um shell":

$ docker exec -it <nome ou ID do container> bash

Se a imagem for baseada em Alpine (como muitas imagens leves de produção), ela geralmente não tem bash instalado — use ash no lugar:
$ docker exec -it <nome ou ID do container> ash

Agora veja que está dentro do container, pode verificar cat /etc/os-release ou env.

Também é possível executar um comando específico sem precisar abrir uma sessão interativa — por exemplo, para conferir uma variável de ambiente:

$ docker exec -it <nome ou ID do container> env

Desta forma você não precisará entrar no container.

Parando e removendo containers

Para parar um container em execução:

$ docker stop <nome ou ID do container>

Parar não remove o container — ele continua existindo (parado), até que você remova explicitamente ou tenha usado --rm na criação.

Para remover manualmente:

$ docker rm <nome ou ID do container>

Acompanhando logs

Containers normalmente escrevem seus logs em stdout/stderr, e o Docker captura isso automaticamente. Para visualizar (e acompanhar em tempo real, como um tail -f):

$ docker logs -f <nome ou ID do container>

Sem a flag -f, o comando apenas imprime os logs existentes até o momento, sem continuar acompanhando.

Monitorando recursos

Para ver, em tempo real, o consumo de CPU, memória, I/O de disco e rede de todos os containers em execução:

$ docker stats

Esse comando é útil para identificar rapidamente containers consumindo recursos excessivos, sem precisar recorrer a ferramentas externas de monitoramento.

Próximos passos

Com os comandos essenciais da CLI em mãos, já é possível operar containers no dia a dia com confiança. Mas até aqui, os dados dentro dos containers são efêmeros — se o container for removido, os dados vão junto. Na Parte 3 desta série, vamos resolver isso com volumes, garantindo persistência de dados entre execuções.

Continua na Parte 3.

Parte 1: Instalando o Docker no Debian

Celso Nery — Tue, 18 Aug 2026 22:44:05 +0000

🇺🇸 English version here

Docker para Desenvolvedores - Parte 1: Instalando o Docker no Debian

Antes de rodar qualquer container — seja para uma aplicação isolada, seja como pré-requisito para um cluster Kubernetes — é preciso ter o Docker Engine instalado e configurado corretamente no servidor. Este artigo cobre a instalação completa no Debian, do zero até o primeiro container rodando.

Use sudo antes dos comandos abaixo caso esteja executando como usuário comum (não como root).

Atualizando o sistema

Antes de instalar qualquer pacote novo, atualize a lista de pacotes e o sistema:

# apt update
# apt upgrade

Instalando pacotes necessários

Alguns pacotes são pré-requisitos para adicionar repositórios externos com segurança (chaves GPG, HTTPS, etc.):

# apt install curl gnupg2 apt-transport-https software-properties-common ca-certificates

Adicionando o repositório do Docker

Baixe e registre a chave GPG oficial do Docker:

# curl -fsSL https://download.docker.com/linux/debian/gpg | gpg --dearmor -o /etc/apt/trusted.gpg.d/docker.gpg

Crie o arquivo de repositório em /etc/apt/sources.list.d/docker.list e adicione este conteúdo:

deb [arch=amd64 signed-by=/etc/apt/trusted.gpg.d/docker.gpg] https://download.docker.com/linux/debian bookworm stable

⚠️ Atenção à versão do Debian: o nome (bookworm, no exemplo) precisa corresponder à versão do seu Debian — bookworm é o Debian 12, bullseye é o Debian 11, buster é o Debian 10. Para descobrir qual é o codinome da sua instalação, rode:
$ lsb_release -cs

ou

cat /etc/os-release
E substitua bookworm pelo valor retornado, caso esteja usando uma versão diferente.

Container runtime: Docker ou containerd?

Se o objetivo final é montar um cluster Kubernetes, vale uma pausa aqui: o Kubernetes não usa o Docker diretamente como runtime desde a versão 1.24 — ele depende do containerd (que, inclusive, já vem junto com a instalação do Docker Engine, mas também pode ser instalado isoladamente). Se esse for o seu caso, siga direto para o artigo de instalação do Kubernetes, que cobre a instalação do containerd especificamente para esse cenário.

Se o objetivo é usar o Docker Engine completo (para rodar containers isolados, Docker Compose, etc.), continue com os passos abaixo.

Instalando o Docker

# apt update
# apt install docker-ce

Se você tiver problemas ao executar containers com a versão mais recente, é possível instalar uma versão anterior como a 18.06.0:
# apt install docker-ce=18.06.0~ce~3-0~debian

Configurando o daemon

Crie o arquivo /etc/docker/daemon.json com as seguintes configurações:

{
    "exec-opts": ["native.cgroupdriver=systemd"],
    "log-driver": "json-file",
    "log-opts": {
        "max-size": "100m"
        },
    "storage-driver": "overlay2"
}

Essa configuração:

Usa o systemd como cgroup driver (importante para manter consistência com outros serviços gerenciados por systemd no sistema, incluindo o próprio Kubernetes, caso você venha a instalá-lo depois);
Limita o tamanho dos logs de cada container a 100MB, evitando que containers "barulhentos" encham o disco com logs;
Usa o driver de armazenamento overlay2, recomendado atualmente para a maioria dos casos.

Crie o diretório de override do serviço systemd do Docker:

# mkdir -p /etc/systemd/system/docker.service.d

Recarregue e reinicie o serviço:

systemctl daemon-reload
systemctl restart docker

Permitindo uso do Docker por um usuário comum

Por padrão, comandos do Docker exigem privilégios de root. Para permitir que um usuário comum rode containers sem precisar de sudo em todo comando, adicione-o ao grupo docker:

# usermod -aG docker $USER

É necessário fazer logout e login novamente (ou reiniciar a sessão) para que a mudança de grupo tenha efeito.

Verificando a instalação

Confirme que o Docker está instalado e funcionando:

$ docker version

A saída deve ser parecida com:

Client:
 Version:           18.06.0-ce
 API version:       1.38
 Go version:        go1.10.3
 Git commit:        0ffa825
 Built:             Wed Jul 18 19:09:33 2018
 OS/Arch:           linux/amd64
 Experimental:      false

Server:
 Engine:
  Version:          18.06.0-ce
  API version:      1.38 (minimum version 1.12)
  Go version:       go1.10.3
  Git commit:       0ffa825
  Built:            Wed Jul 18 19:07:38 2018
  OS/Arch:          linux/amd64
  Experimental:     false

A versão exibida vai variar conforme a versão instalada no seu sistema — o exemplo acima reflete a versão 18.06.0.

Rodando o primeiro container

O teste clássico, usando a imagem oficial de exemplo do Docker:

$ docker run hello-world

Ou, para um teste um pouco mais tangível, subindo um servidor web Apache (httpd) na porta 80:

$ docker run --rm -p 8080:80 httpd

Para confirmar que funcionou, acesse pelo navegador o IP da máquina host:

http://127.0.0.1:8080

Se a página padrão do Apache aparecer, a instalação do Docker está completa e funcionando corretamente.

Considerações finais

Com o Docker instalado, configurado com o cgroup driver correto e testado com sucesso, o servidor já está pronto tanto para rodar containers isolados no dia a dia. Na Parte 2 desta série, iremos explorar os comandos mais comuns do Docker CLI: run, ps, exec, stop, rm, logs, and stats.

Continua na Parte 2.

DEV Community: Celso Nery

Part 6: Automating with Docker Compose

Using Docker — Part 6: Automating with Docker Compose

Creating your docker-compose.yaml

A minimal docker-compose.yaml

Adding a volume

Adding a network

Bringing up the containers

Tearing down the containers

Bringing multiple containers together: App + Database + Redis

Series wrap-up

Part 5: Managing Images

Using Docker — Part 5: Managing Images

Building an image

Listing images

Versioning images (tag)

Removing images

Cleaning up unused images

Publishing an image (push)

Next steps

Part 4: Working with Networks

Using Docker — Part 4: Working with Networks

Listing networks

Creating a network

Inspecting a network

Running a container already connected to a network

Connecting a running container to a network

Disconnecting a container from a network

Removing a network

Cleaning up unused networks

Why this matters

Next steps

Part 3: Persisting Data with Volumes

Using Docker — Part 3: Persisting Data with Volumes

Bind mount vs. Volume

Creating a volume

Listing volumes

Inspecting a volume

Running a container with a volume -v

Using a bind mount

Using a created volume

Removing a volume

Cleaning up unused volumes

Using NFS volumes

Next steps

Part 2: Essential CLI Commands

Using Docker — Part 2: Essential CLI Commands

Running a container

Listing containers

Connecting a container

Stopping and removing containers

Tailing logs

Monitoring resources

Next steps

Part 1: Installing on Debian

Docker for Devs — Part 1: Installing on Debian

Updating the system

Installing required packages

Adding the Docker repository

Container runtime: Docker or containerd?

Installing Docker

Configuring the daemon

Allowing a regular user to use Docker

Verifying the installation

Running your first container

Next steps

Parte 6: Automatizando com Docker Compose

Docker para Desenvolvedores — Parte 6: Automatizando com Docker Compose

Criando seu docker-compose.yaml

Um docker-compose.yaml mínimo

Acrescentando um volume

Acrescentando uma rede

Subindo os containers

Derrubando os containers

Juntando vários containers: App + Database + Redis

Considerações finais da série

Parte 5: Gerenciando Imagens

Docker para Desenvolvedores — Parte 5: Gerenciando Imagens

Construindo uma imagem (build)

Listando imagens

Running a container with a volume `-v`

Rodando um container com um volume `-v`