owncloud / ocis

:atom_symbol: ownCloud Infinite Scale Stack
https://doc.owncloud.com/ocis/next/
Apache License 2.0
1.36k stars 180 forks source link

OCIS container port binding conflict in Podman Pods #9255

Closed AliveDevil closed 3 months ago

AliveDevil commented 3 months ago

Describe the bug

When using podman run --pod with the WOPI-sample (not using podman-compose or docker-compose, but manually creating the containers) there is a port-conflict between the appprovider-service and OCIS.

Steps to reproduce

  1. podman pod create --name ocis-pod
  2. podman run --pod ocis-pod -name ocis … / OCIS-runtime
  3. podman run --pod ocis-pod -name ocis-approvider / OCIS appprovider

Expected behavior

Both containers startup fine.

Actual behavior

The appprovider container or runtime container won't start due to already bound ports, as Podman Pods are sharing a network namespace, so that all services can use localhost as endpoint (no requirement for 0.0.0.0-binds).

Setup

Following the wopi-example, but manually creating each service manually, so that I can manage each Podman container using systemd.

Additional context

rhafer commented 3 months ago

Can you please share the full commands (including env vars) you're using to start the containers?

The appprovider container or runtime container won't start due to already bound ports

Which ports are that? Is it always the same or are they changing?

micbar commented 3 months ago

@AliveDevil

I think you could choose a simpler approach.

Normally you only need one app provider. We already have one in the ocis single process.

If you really need two, you should just change the port bindings via the ocis config.

AliveDevil commented 3 months ago

Ah, I see. So the WOPI example requires by-design separation of the app providers, while with a single app provider service, this isn't required at all. And the already-running app-provider in the ocis server-process isn't disableable, for instances where the app-provider should run outside of the ocis-server container?

@rhafer There is no need to change any environment variables. With just

podman volume create ocis-config

podman pod create ocis-pod

podman run -d --replace --rm --pod ocis-pod --name ocis -e "OCIS_INSECURE=true" -v ocis-config:/etc/ocis --entrypoint /bin/sh docker.io/owncloud/ocis:5.0.5 -c "ocis init || true; ocis server"

podman run --replace --rm --pod ocis-pod --name -v ocis-config:/etc/ocis ocis-apps docker.io/owncloud/ocis:5.0.5 app-provider server
{"level":"error","service":"app-provider","server":"app-provider","error":"listen tcp 127.0.0.1:9165: bind: address already in use","time":"2024-05-27T12:25:13Z","message":"Shutting down server"}

The second container won't start, due to the conflicting ports.

micbar commented 3 months ago

So the WOPI example requires by-design separation of the app providers, while with a single app provider service, this isn't required at all. And the already-running app-provider in the ocis server-process isn't disableable, for instances where the app-provider should run outside of the ocis-server container?

You can set OCIS_EXCLUDE_RUN_SERVICES=app-provider

micbar commented 3 months ago

With APP_PROVIDER_DEBUG_ADDR=127.0.0.1:<some-port> and APP_PROVIDER_GRPC_ADDR=127.0.0.1:<some-port> you can also avoid port collisions if more than one app-provider service is needed.

micbar commented 3 months ago

closing. Your use case is solvable via config.