ENG | Podman (Docker) Compose Files Update, December 2024

This article is mostly for my own reference and fixes some past bad decisions

Many months ago, I split my main docker-compose.yml file into multiple files, each dedicated to a specific service group. This approach led to recurring warnings and errors when starting or updating my containers with Podman. Feeling that these issues were mostly harmless, I had ignored them—until now. I finally decided to resolve them with some assistance from ChatGPT.

For example, I would navigate to my docker directory and run:

[pavel@marten -=- /home/pavel]$ cd docker
[pavel@marten -=- /home/pavel/docker]$ podman-compose -f docker-compose-forgejo.yml up -d
Error: no container with name or ID "gitea" found: no such container
Error: no container with name or ID "gitea-mariadb" found: no such container
Error: no container with ID or name "gitea" found: no such container
Error: no container with ID or name "gitea-mariadb" found: no such container
Error: not all containers could be removed from pod ce87bbbbbb0c7912ed1a318c4d80dd593038717d9e546e22c3e3fe2741a1c764: removing pod containers
Error: error removing container 94e88257628a183b686e69c2ddbca1b843f59620c035d27e864d009d370c331d from pod ce87bbbbbb0c7912ed1a318c4d80dd593038717d9e546e22c3e3fe2741a1c764: cannot remove container 94e88257628a183b686e69c2ddbca1b843f59620c035d27e864d009d370c331d as it is running - running or paused containers cannot be removed without force: container state improper
...
(repeated few times with different ids)
...
Error: adding pod to state: name "pod_docker" is in use: pod already exists
663d6fd19f32b17a27a9bddc582d6f4918d3e4bb280a64a771acaf4e3ffac87a
gitea-mariadb
c1989a1d0d30ebffd31d39a3d00ee34e6b10bfa1951e65b599ad48ab6595c28c
gitea

[pavel@marten -=- /home/pavel/docker]$

These messages appeared when I worked with multiple Compose files in the same directory. They seemed harmless but turned annoying over time. According to ChatGPT’s explanation, Podman Compose uses the directory name as the project name, so each Compose file attempts to use the same pod name (pod_docker). That naming collision triggers these warnings.

At this point it’s wise to back up everything!

Specifying a Project Name

To fix this, I simply specified a project name directly in each compose file:

version: '3.8'
name: gitea # New
services:
  gitea:
    ...

By doing so, Podman Compose no longer relied on the docker directory name, and the errors disappeared.

New Problems After Assigning Project Names

1. Network Isolation

Each project now creates its own network. As a result, cloudflared can only see certain containers (like nginx) and cannot see others such as Forgejo, Nextcloud, or Umami. They are on different networks.

2. Volume Naming

Because the project name changed, Podman Compose created fresh volumes (e.g., gitea_gitea-db) instead of reusing the old ones (docker_gitea-db). My containers therefore loaded new, empty configurations. This was found by running podman volume ls command.

Fixing Network Isolation

To address container visibility, I created a single shared network and connected all Compose projects to it:

Step 1: Create a shared network:

podman network create shared_network

Step 2: Edit each docker-compose.yml file and each container (service) to use that network:

version: '3.8'
name: gitea
networks:           # New four lines for each docker-compose file
  shared_network:
    name: shared_network
    external: true
services:
  gitea:
    #...
    networks:       # New two lines for each container
      - shared_network

This ensures each container is attached to the same shared_network and can communicate normally.

Restoring Old Volume Data

To recover my previous configurations, I mapped existing volumes to the new Compose definitions:

volumes:
  gitea-data:
    external: true            # New to reference old volume
    name: docker_gitea-data   # ditto
  gitea-config:
    external: true
    name: docker_gitea-config
  gitea-db:
    external: true
    name: docker_gitea-db

By setting external: true and specifying the name: of the old volume, Podman Compose uses the existing volume rather than creating a new one.

Conclusion

Renaming projects in Podman Compose solved my initial warnings about pods but introduced network and volume naming issues. The key takeaways are:

• Use unique project names (preferably by name: in .yml) to avoid naming collisions.
• Connect all containers to a shared network to keep them discoverable across services.
• Map new volumes to old names if you want to retain existing data.

I hope these notes help anyone who might encounter similar issues.