podman-compose icon indicating copy to clipboard operation
podman-compose copied to clipboard

Default network management different from docker

Open stac47 opened this issue 2 years ago • 2 comments

Describe the bug

Let's take the following simple compose.yaml file:

services:
  exposed:
    image: "ealen/echo-server"
    ports:
      - "3000:80"
    networks:
      - "shared"
      - "default"
  other:
    image: "ealen/echo-server"
    ports:
      - "3001:80"
networks:
  shared:
    external: true

There is an external network named shared that has been created manually with docker/podman network create shared.

If we start it with Docker compose:

  • the -default network is created
  • the container exposed will be connected to the default and the shared networks
  • the container other will be implicitly connected to the default network.
% docker compose up -d
 ⠿ Network reproducer_podman_compose_default      Created
 ⠿ Container reproducer_podman_compose-exposed-1  Started
 ⠿ Container reproducer_podman_compose-other-1    Started
% docker container inspect reproducer_podman_compose-exposed-1 --format '{{ range $key, $_ := .NetworkSettings.Networks}}{{$key}} {{end}}'
reproducer_podman_compose_default shared
% docker container inspect reproducer_podman_compose-other-1 --format '{{ range $key, $_ := .NetworkSettings.Networks}}{{$key}} {{end}}'
reproducer_podman_compose_default

Now if we do the same with podman-compose:

% podman-compose up -d
podman-compose version: 1.0.6
['podman', '--version', '']
using podman version: 4.5.0
Traceback (most recent call last):
  File "/usr/local/bin/podman-compose", line 33, in <module>
    sys.exit(load_entry_point('podman-compose==1.0.6', 'console_scripts', 'podman-compose')())
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/Cellar/podman-compose/1.0.6/libexec/lib/python3.11/site-packages/podman_compose.py", line 2941, in main
    podman_compose.run()
  File "/usr/local/Cellar/podman-compose/1.0.6/libexec/lib/python3.11/site-packages/podman_compose.py", line 1421, in run
    self._parse_compose_file()
  File "/usr/local/Cellar/podman-compose/1.0.6/libexec/lib/python3.11/site-packages/podman_compose.py", line 1568, in _parse_compose_file
    raise RuntimeError(f"missing networks: {missing_nets_str}")
RuntimeError: missing networks: default

It seems podman-compose, contrarily to docker, does not figure out that the default network must be created and the two containers must be connected to the default network.

To workaround that, we must explicitly define the default network in the top-level networks section as follows:

[...]
networks:
  shared:
    external: true
  default:

In that case, podman-compose can start the containers and attaches the containers to the default network.

% podman container inspect reproducer_podman_compose_exposed_1 --format '{{ range $key, $_ := .NetworkSettings.Networks}}{{$key}} {{end}}'
reproducer_podman_compose_default shared
% podman container inspect reproducer_podman_compose_other_1 --format '{{ range $key, $_ := .NetworkSettings.Networks}}{{$key}} {{end}}'
reproducer_podman_compose_default

Trying the latest development branch, we have the same problem:

% ~/temp_latest_podman_compose/bin/podman-compose up -d
podman-compose version: 1.0.7
['podman', '--version', '']
using podman version: 4.5.0
Traceback (most recent call last):
  File "/Users/stac/temp_latest_podman_compose/bin/podman-compose", line 8, in <module>
    sys.exit(main())
             ^^^^^^
  File "/Users/stac/temp_latest_podman_compose/lib/python3.11/site-packages/podman_compose.py", line 3072, in main
    podman_compose.run()
  File "/Users/stac/temp_latest_podman_compose/lib/python3.11/site-packages/podman_compose.py", line 1488, in run
    self._parse_compose_file()
  File "/Users/stac/temp_latest_podman_compose/lib/python3.11/site-packages/podman_compose.py", line 1649, in _parse_compose_file
    raise RuntimeError(f"missing networks: {missing_nets_str}")
RuntimeError: missing networks: default

To Reproduce Steps to reproduce the behavior:

  1. what is the content of the current working directory (ex. docker-compose.yml, .env, Dockerfile, ...etc.)
% tree
.
└── compose.yaml
% cat compose.yaml
services:
  exposed:
    image: "ealen/echo-server"
    ports:
      - "3000:80"
    networks:
      - "shared"
      - "default"
  other:
    image: "ealen/echo-server"
    ports:
      - "3001:80"

networks:
  shared:
    external: true
  1. what is the sequence of commands you typed: see above

Expected behavior I expect the default network to be created even in presence of an external network as Docker compose does.

Actual behavior It fails to start with the following error: RuntimeError: missing networks: default To workaround that behaviour, we must explicitly define the default network in the top-level networks section.

Output

% podman-compose version
podman-compose version: 1.0.6
['podman', '--version', '']
using podman version: 4.5.0
podman-compose version 1.0.6
podman --version
podman version 4.5.0

Environment:

  • OS: Mac
  • podman version: 4.5.0 (but the same with previous versions)
  • podman compose version: 1.0.6

Additional context

Add any other context about the problem here.

stac47 avatar Apr 15 '23 13:04 stac47

Adding an external: true directive in the network section seems to be a workaround for the issue.

That still doesn't explain why the behavior is different between hosts though ...

Updated compose.yml file

version: "3.9"
networks:
  podman:
    external: true
services:
  nginx:
    image: nginx:latest
    container_name: nginx
    userns_mode: "host"
    ports:
      - 8080:80
    networks:
      - podman

luckylinux avatar Dec 30 '23 20:12 luckylinux

creating a network of same name multiple times, is supposed to only work for the first time and then return already exists for the second run. the end result would be having a single network

$ podman network create foo
foo
$ podman network create foo
Error: network name foo already used: network already exists

so this is not a problem other than the confusing message

muayyad-alsadi avatar Dec 30 '23 23:12 muayyad-alsadi