Nextcloud Push

[hoellen]

There is a new "high performance backend" for Nextcloud. It uses push to communicate with the Nextcloud clients. As we already use Nginx as a reverse proxy, it could be integrated/controlled very easily via docker env variables.

Should it be optional/default?

Useful links:

• https://nextcloud.com/blog/nextcloud-hub-21-out-with-up-to-10x-better-performance-whiteboard-and-more-collaboration-features/
• https://nextcloud.com/blog/nextcloud-faster-than-ever-introducing-files-high-performance-back-end/
• https://github.com/nextcloud/notify_push

Users of the Docker image can leave a reaction or comment here, if they have specific suggestions/concerns.

[waja]

Hi @hoellen,

thanks for maintaining this great project.

I think it would be nice to have the HPB shipped by default but (maybe for now) not enabled by default but as you suggested controlled via env variables.

Many thanks, Jan.

[GUNT0815]

Hi @hoellen,

I would vote for:

• best performance/ HPB should be enabled by default
• should be "switched off" via environment variables

I think this is the most convenient approach for the SOHO users out there, but also allows different configuration in case.

Thanks, Udo

[hathagat]

I vote for only adding the push location to the nginx config because there is an official HPB image already.
https://github.com/nextcloud/notify_push/blob/main/Dockerfile
https://hub.docker.com/r/icewind1991/notify_push

So we could use it the same way we use the database or redis:

 notify_push:
   image: icewind1991/notify_push
   environment:
     - NEXTCLOUD_URL=https://myclouddomain.com/
     - DATABASE_URL=mysql://MYDBUSER:MYDBPASSWORD@db/nextcloud
     - DATABASE_PREIX=oc_
     - REDIS_URL=redis://:MYREDISPASSSWORD@redis

[waja]

I vote for only adding the push location to the nginx config because there is an official HPB image already.

Adding another image creates lot of additional hassle. See nextcloud/docker#1422 and nextcloud/notify_push#11 for example.

You don't need to pass those variables, when you give notify_push the location of the nextcloud config.

You need also to deal with trusted proxies it seems.

[hathagat]

Yes, on the one hand you are right. It adds more complexity to the docker setup. On the other hand the complexity is not added to this image.
Additionally the HPB needs Redis, so you need an external image anyway. If HPB is enabled using an env variable only, it would not work out of the box.

From a conceptual point of view, this is just like Redis, OnlyOffice, Turn, Elasticsearch or similar: Another service for Nextcloud which can be added to the stack if required.

Anyways, I'm fine with both ways. ☺️
Atm HPB ist working for me in the seperate container.

[hoellen]

After thinking about it, I also don't want to include the push backend into the Nextcloud image. I see it like @hathagat, that it is something like Redis etc. that you can choose to use. We also support very small/limited user setups where you can run Nextcloud e.g. with sqlite. Also if you want to test things, there is less complexity preferred.

On the long run I want to provide an own image for the push backend with an easy-to-use config. But I still have to look into it.

[lexxxel]

@hoellen what is your conclusion today?

[waja]

Atm HPB ist working for me in the seperate container.

@hathagat do you wonna share your docker compose config with us?

[hathagat]

@hathagat do you wonna share your docker compose config with us?

Sure!

 # https://github.com/instrumentisto/coturn-docker-image
 coturn:
   image: instrumentisto/coturn:latest
   container_name: nextcloud-turn
   networks:
     - frontends
   ports:
     - "3478:3478"
     - "3478:3478/udp"
     - '49160-49200/udp'
   volumes:
     - ${DOCKER_DATA_PATH}/nextcloud/turn/turnserver.conf:/etc/coturn/turnserver.conf
     - ${DOCKER_DATA_PATH}/nextcloud/turn/data:/var/lib/coturn
   command:
     - -n
     - --no-cli
     - --log-file=stdout
     - --min-port=49160
     - --max-port=49200
     - --realm=${NEXTCLOUD_DOMAIN}
     - --use-auth-secret
     - --static-auth-secret=${NEXTCLOUD_TURN_SECRET}
   environment:
     VIRTUAL_HOST: turn.${NEXTCLOUD_DOMAIN}
     VIRTUAL_PORT: 3478
   restart: always

 # https://github.com/strukturag/nextcloud-spreed-signaling
 signaling:
   container_name: nextcloud-signaling
   build: ./signaling
   image: my-signaling:latest
   depends_on:
     - coturn
     - nats
     - janus
   volumes:
     - ${DOCKER_DATA_PATH}/nextcloud/signaling/server.conf:/config/server.conf
   restart: always

 nats:
   container_name: nextcloud-nats
   image: nats:2.2.1
   command: ["-c", "/config/gnatsd.conf"]
   volumes:
     - ${DOCKER_DATA_PATH}/nextcloud/nats/gnatsd.conf:/config/gnatsd.conf
   restart: always

 janus:
   container_name: nextcloud-janus
   build: ./janus
   image: my-janus:latest
   command: ["janus", "--full-trickle"]
   restart: always

The networks and environment stuff is just for my Nginx setup. So you can ignore that parts. Using network_mode: host would make things easier for you in this regard.
The signaling service builds the Dockerfile from the official repository.

Basically I followed this tutorial.

[waja]

@hathagat the part I'm missing here is the push part. I'm still trying to run the notify_push image from https://hub.docker.com/r/icewind1991/notify_push/, which is basically https://github.com/nextcloud/notify_push.

Following the suggestion on https://github.com/nextcloud/notify_push#push-server-is-not-a-trusted-proxy:

If you're running your setup in docker and your containers are linked, you should be able to use the name of the nextcloud container as hostname in the NEXTCLOUD_URL

I can use:

    environment:
      - NEXTCLOUD_URL=http://nextcloud:8888
    links:
      - nextcloud:nextcloud

cause the nextcloud container exposes on Port 8888. This leads to the issue:

nextcloud-push_1       | Error:
nextcloud-push_1       |    0: Invalid base url
nextcloud-push_1       |    1: relative URL without a base
nextcloud-push_1       |
nextcloud-push_1       | Location:
nextcloud-push_1       |    src/nc.rs:14
nextcloud-push_1       |
nextcloud-push_1       | Backtrace omitted.
nextcloud-push_1       | Run with RUST_BACKTRACE=1 environment variable to display it.
nextcloud-push_1       | Run with RUST_BACKTRACE=full to include source snippets.

It looks like ":8888" is not a valid string for the push client.

Dropping the port NEXTCLOUD_URL=http://nextcloud leeds to:

nextcloud-push_1       | [2021-10-28 16:18:22.196600 +00:00] ERROR [notify_push] src/main.rs:60: Self test failed: Failed to request app version: error sending request for url (http://nextcloud/index.php/apps/notify_push/test/version): error trying to connect: tcp connect error: Connection refused (os error 111): error trying to connect: tcp connect error: Connection refused (os error 111): tcp connect error: Connection refused (os error 111): Connection refused (os error 111)

Now the question is: Did anybody have running a notify_push container successfully with @hoellen nextcloud container and if, would he share his knowledge?