Connection to proxy on a different host fails at Hearbeat

[kridgo]

I cannot connect to the docker-socket-proxy when it is running on another host. I am using this docker-compose setup to run the proxy on the remote host:

version: "3"
services:
 nextcloud-appapi-dsp:
 environment:
 - NC_HAPROXY_PASSWORD=some_secure_password
 - BIND_ADDRESS=192.168.178.5
 - EX_APPS_NET=ipv4@192.168.178.5
 volumes:
 - /var/run/docker.sock:/var/run/docker.sock
 container_name: nextcloud-appapi-dsp
 hostname: nextcloud-appapi-dsp
 restart: unless-stopped
 privileged: true
 image: ghcr.io/cloud-py-api/nextcloud-appapi-dsp:release
 network_mode: host

It does start as expected when running sudo docker-compose up and I can register it as a deploy daemon in my Nextcloud server. However, when I run the Test deploy for the daemon it fails at stage Heartbeat. It does install the test deploy container on the remote host and is able to start it:

CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
299ce125b19f ghcr.io/cloud-py-api/test-deploy-cpu:release "python3 main.py" 10 minutes ago Up 10 minutes (healthy) nc_app_test-deploy
1464ca39de38 ghcr.io/cloud-py-api/nextcloud-appapi-dsp:release "/bin/bash start.sh" 6 days ago Up 11 minutes (healthy) nextcloud-appapi-dsp

Still, Nextcloud server cannot connect to it. If I check the open ports on the remote host running the proxy with sudo netstat -tulpn | grep LISTEN, I get this:

tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 1779/cupsd
tcp 0 0 127.0.0.1:46689 0.0.0.0:* LISTEN 697/containerd
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 716/sshd: /usr/sbin
tcp 0 0 127.0.0.1:23000 0.0.0.0:* LISTEN 3165/python3
tcp 0 0 192.168.178.5:2375 0.0.0.0:* LISTEN 2452/haproxy
tcp6 0 0 :::22 :::* LISTEN 716/sshd: /usr/sbin
tcp6 0 0 ::1:631 :::* LISTEN 1779/cupsd

I guess the open port in the fourth line should be 192.168.178.23000 for the Heartbeat to work properly?

The Nextcloud server and the remote host are on the same network 192.168.178.0/24 and there is no firewall that could prevent any traffic. The remote host is a Raspberry Pi3 running Raspbian (it is setup for testing purpose only, I realize it is not a suitable platform to run the ExApps in a productive manner). It also does not help if I change the env variable for the sub containers according to the readme: - EX_APPS_NET="ipv4@127.0.0.1"

If the failing Heartbeat is not an issue of the docker-socket-proxy but my setup is messed up, any hint will be highly appreciated.

[bigcat88]

Sorry for the delay.

EX_APPS_NET should be "ipv4@127.0.0.1" for the remote installs.

HaProxy should listen on 2375 AND ON "BIND_ADDRESS":23000 port in case of remote installations.

Can I see output of cat haproxy_ex_apps.cfg ?

There should be some such line:

frontend ex_apps
 mode http
 bind 192.168.178.5:23000-23030 v4v6 ssl crt /certs/cert.pem

[alonsobasauri]

Hello, I have this:

nextcloud-appapi-dsp:/# cat haproxy_ex_apps.cfg
frontend ex_apps
mode http
BIND_ADDRESS_PLACEHOLDER

My docker command:

sudo docker run -e NC_HAPROXY_PASSWORD="some_secure_password" -e BIND_ADDRESS=192.168.1.97 -e EX_APPS_NET=ipv4@127.0.0.1 -v /var/run/docker.sock:/var/run/docker.sock -v pwd/certs/cert.pem:/certs/cert.pem --name nextcloud-appapi-dsp -h nextcloud-appapi-dsp --net host --restart unless-stopped --privileged -d ghcr.io/cloud-py-api/nextcloud-appapi-dsp:release

Hope you can help us, I'm like 50 hours into this :/

[andrey18106]

Hello, I have this:

nextcloud-appapi-dsp:/# cat haproxy_ex_apps.cfg frontend ex_apps mode http BIND_ADDRESS_PLACEHOLDER

My docker command:

sudo docker run -e NC_HAPROXY_PASSWORD="some_secure_password" -e BIND_ADDRESS=192.168.1.97 -e EX_APPS_NET=ipv4@127.0.0.1 -v /var/run/docker.sock:/var/run/docker.sock -v pwd/certs/cert.pem:/certs/cert.pem --name nextcloud-appapi-dsp -h nextcloud-appapi-dsp --net host --restart unless-stopped --privileged -d ghcr.io/cloud-py-api/nextcloud-appapi-dsp:release

Hope you can help us, I'm like 50 hours into this :/

Hello, this might be related and useful for you: nextcloud/app_api#413, https://nextcloud.github.io/app_api/CreationOfDeployDaemon.html#additional-options

[Haplo164]

I know it's been awhile, but I had to use the OVERRIDE_APP_HOST when setting up a deploy daemon in nextcloud expand the "deploy config" settings and "add additional option" then I had to set "OVERRIDE_APP_HOST" to the IP of my container host. For some reason you can't edit a Deploy Daemon to add additional options.

[cantrust-hosting-cooperative]

I am not sure if it's the same problem, but I was getting 503 errors for the heartbeats in my nextcloud-appapi-dsp container logs (shown using docker logs -f nextcloud-appapi-dsp ):

<134>Feb 20 21:35:29 haproxy[19]: 1.2.3.4:54094 [20/Feb/2025:21:35:26.712] ex_apps~ bk_ex_apps/ex_apps 0/0/-1/-1/3040 503 217 - - SC-- 2/1/0/0/3 0/0 "GET /heartbeat HTTP/1.1" 
 [ over and over again ]

When I used curl to check the failing URL shown from the nextcloud log (with curl -u app_api_haproxy_user:some_secure_password https://exapphost.example.com:23000/heartbeat from the NC server) I discovered it was a "503 Bad Gateway" error from haproxy, saying "Upstream Server is Unavailable".

This was strange since the upstream should be mapped to localhost:23000 in haproxy and a netstat command confirms that my ExApp docker container was listening on 127.0.0.1:23000 .

On a hunch, i changed the backend definition to use "127.0.0.1" instead of "localhost":

• docker exec -it nextcloud-appapi-dsp /bin/bash to connect to the container
• edit file haproxy_ex_apps.cfg and att the end adjust the backend line

backend bk_ex_apps
 mode http
# server ex_apps localhost
 server ex_apps 127.0.0.1

• exit the container with exit
• back on the outer Docker host, restart the container iwth: docker restart nextcloud-appapi-dsp

After this change, the proxying works correctly, no more 503 errors, the Nextcloud host is able to heartbeat and then enable the ExApp.

I'm not sure why that change is needed though - IPv6 is setup on both outer and inner, "ping localhost" pings (::1) the IPv6 version. Perhaps that's the problem when docker binds specifically to IPv4 localhost? But in that case why isn't this problem widespread?? It happened for me consistently on two ExApp hosts I tested with today.

[melroy89]

Would be nice if somebody would actually publish and share a working docker-compose instead of a docker run command to this official repo / README.

Something like:

services:
 docker-socket-proxy:
 userns_mode: host
 restart: always
 image: ghcr.io/nextcloud/nextcloud-appapi-dsp:release
 container_name: nextcloud-appapi-dsp
 privileged: true
 networks:
 - socket_proxy_external_network
 ports:
 - "127.0.0.1:2375:2375"
 volumes:
 - /var/run/docker.sock:/var/run/docker.sock
 environment:
 - NC_HAPROXY_PASSWORD=<secret>

networks:
 socket_proxy_external_network:

Replace <secret>

I try to use a custom Docker bridge, because I use a hardered Docker setup (eg. userns-remap": "default") for security reasons. I can't just deploy to the host network, or I will get:

Client error: `POST http://127.0.0.1:2375/v1.41/containers/create?name=nc_app_test-deploy` 
resulted in a `400 Bad Request` response: {"message":"cannot share the host's network namespace when user namespaces are enabled"} 

[derritter88]

I agree - it would be a good idea to get some official docker compose yml example from the developers.
Currently mine would be:

services:
 nextcloud-appapi-dsp:
 image: ghcr.io/nextcloud/nextcloud-appapi-dsp:v1.5.2
 container_name: nextcloud-appapi-dsp
 hostname: nextcloud-appapi-dsp
 network_mode: host
 environment:
 - NC_HAPROXY_PASSWORD=<password>
 - BIND_ADDRESS=<ip address of your docker host>
 - EX_APPS_NET=ipv4@127.0.0.1
 volumes:
 - /var/run/docker.sock:/var/run/docker.sock
 privileged: true
 restart: unless-stopped

Nextcloud can connect to it.

[Baggypants]

The only way I got this to work is with TLS certs. While Nextcloud can connect to a remote proxy without TLS, it seems mandatory if you want the heartbeat to pass. Because it will only correctly set the EX_APPS_NET variable if it can find a cert.pem file.