Getting AIO's child containers to use network defined in docker-compose?

ℹ️ Support
1

I am using the AIO image with docker-compose, and I want it to live on its own subnet. To do this I’ve added the following to my docker-compose.yml:

networks:
  my-custom-network:
    ipam:
      config:
        - subnet: 192.168.200.0/24

Under the Nextcloud service, I’ve specified my network and assigned an ipv4 address to it. This works, but the other containers spawned by AIO (e.g. nextcloud-aio-database) join the default nextcloud-aio network instead of my-custom-network. How can I configure these other containers to live on the subnet I’ve defined?

2

This is not possible as you can see.

3

However the container does create and use its own subnet automatically with the name nextcloud-aio.

4

I had the same issue in situation where my proxy manager had own network - so reverse proxy couldn’t work because the container didnt see nextcloud aio instances. You have to add network nextcloud-aio to the reverse proxy container.

5

I wonder how you secured your instance then? As far as I can see the Default nextcloud-aio Network is a bridge and every container part of that network has access to the docker host and the whole network it resides. In a business scenario of course I would just put that particular docker host into its own subnet and isolate it from the rest of the network, but in a home scenario with limited resources / budget that is not feasible just for a single service.

Putting a Reverse proxy in front of the Nextcloud instance is just a part of the solution. It is still better than port forwarding directly to the NC instance, but once something bad happens within one of the nextcloud-aio containers, it can spread into the whole network. All other containers I reverse proxy to sit in a separate docker network with its own firewalled VLAN, so they are isolated. If this is not possible with Nextcloud AIO, I probably have to host my own LAMP Container and install NC manually inside that.

Apart from that, the AIO setup looks very convenient with the Update and Backup logic implemented.

1 Like
6

This is what AIO is doing as well. It creates the nextcloud-aio network for you automatically where all the AIO containers reside in.

7

Yes it does, but if you docker exec in one of the nextcloud-aio containers, your whole network is reachable from within the containers. At least this is what happens for me. So, yes. It creates the nextcloud-aio network, but it is bridged to the host and has access to everything the host has access to. If someone manages to instruct the apache within the nextcloud-aio-apache container to do something malicious, it has access to everything.

Since I posted, I think I found a solution, but I have to test it and will report back when I am confident that it runs.

1 Like
8

I think I got it sorted. Whether this will still work after an Update of the Mastercontainer I do not know yet. Unfortunately the last update ran yesterday, so I might need to wait for a few weeks until the next release to see if stuff breaks.

What I did:

  1. I removed all Nextcloud AIO Containers and the nextcloud-aio Network
  2. I re-created the nextcloud-aio Network myself with the macvlan driver and pointing to one of my VLANs like this:
docker network create -d macvlan -o parent=bond0.20 --subnet 192.168.2.0/24 --gateway=192.168.2.1 nextcloud-aio
  1. After that I altered my docker-compose file for the nextcloud-aio-mastercontainer to include my new network. If I do not do this, compose creates its own default network.
version: "3.8"

volumes:
  nextcloud_aio_mastercontainer:
    name: nextcloud_aio_mastercontainer

services:
  nextcloud:
    image: nextcloud/all-in-one:latest
    restart: unless-stopped
    container_name: nextcloud-aio-mastercontainer
    volumes:
      - nextcloud_aio_mastercontainer:/mnt/docker-aio-config
      - /var/run/docker.sock:/var/run/docker.sock:ro
    ports:
      - 8080:8080
    environment:
      - APACHE_PORT=11000
      - APACHE_IP_BINDING=0.0.0.0
    networks:
      - nextcloud-aio
networks:
  nextcloud-aio:
    name: nextcloud-aio
    external: true

For my Reverse Proxy (Caddy at the moment), I included the nextcloud-aio network, so name resolution works between those two and they can communicate freely. Since I can not give the nextcloud-aio-apache Container a fixed IP address, it might change, so just using my Firewall to create a rule to allow traffic from my Caddy Proxy → nextcloud-aio-apache:11000 would not be a stable solution. But since Caddy + Nextcloud each run in their own VLANs, isolated from the rest of the network, that´s OK for me.

This works great at the moment. All containers AIO spins up are connected to the nextcloud-aio Network and thus to my dedicated VLAN for Nextcloud.

This might break, should the AIO Master Container at some point (future update?) decide to recreate the nextcloud-aio Network, but at this moment all works as intended and everything is isolated from the rest of the network.

9

I do have another workaround.

Using Traefik v2 Reverse Proxy as docker container connecting to Nextcloud AIO docker

Let me quickly recap the issue, as it took me a while to figure it out:

  • Nextcloud AIO will create the Nextcloud containers. It is not possible to add these “child” containers to a dedicated docker network
  • Instead, they will expose the used ports to the host.
  • Issue: exposed ports are only available to the hosts “localhost” and not to other containers “localhost”

If you want a reverse proxy as descibed in the docs, this reverse proxy must be installed “natively” or on another machine, but can not run as docker container on the same machine.

Reason: A docker container can not reach the host network, it can only expose ports to the host network.
(Exception: a container using the " Host network driver" - but 1. it is not recommended and 2. it is mutually exclusive to using any other “Bridge network”)

Workaround
It is nevertheless possible to reach the host network form within a docker container via host.docker.internal - special setup presupposed!
Important Note - this method is “for development purpose only” - for me it is still the most elegant solution.

Reference:

Setup
Add a dynamic traefik configuration to a file (e.g. nextcloud.yml) - don’t forget to include this to traefik via fiel provider:

http:
    routers:
        nextcloud:
            rule: "Host(`<public.nextcloud.domain>`)"
            service: nextcloud
            middlewares:
                - nextcloud-secure-headers
            tls:
                certresolver: "<your cert resolver>"

    services:
        nextcloud:
            loadBalancer:
                servers:
                    - url: "http://host.docker.internal:11000" # connect to nextcloud via localhost port

    middlewares:
        nextcloud-secure-headers:
            headers:
                hostsProxyHeaders:
                    - "X-Forwarded-Host"
                referrerPolicy: "same-origin"

In your traefik docker-compose.yml enable the extra_hosts - don’t forget to stop and start docker-compose afterwards:

services:
  proxy:
    image: ...
    # the following 2 lines are the important part you have to add:
    extra_hosts:
      - "host.docker.internal:host-gateway"

For Nextcloud-AIO container, ensure to set the environment variables:

  • APACHE_PORT=11000
  • APACHE_IP_BINDING=0.0.0.0

The port mapping for 80 and 8443 should be removed, then the Nextcloud-AIO is ready to spin up :blush:

Finally, start nextcloud-aio, connect to the aio port (default 8080) and afterwards you should be able to add your subdomain, forwarded via traefik.

Best wishes,
Simon

10

What are your experiences with the next update?

11

This thread only describes a workaround, not a real solution.

The developers don’t seem to understand the problem.

With software like Nextcloud that needs to be accessible from the Internet, it is a must have, that it is operated in a separate network, like a DMZ.
In a corporate environment, you wouldn’t get approval for this. A reverse proxy is very good, but no substitute for this.

If someone uses Docker, it should be assumed that more than one container is being operated there. Here I need different networks/VLANs, otherwise the use of Docker has no added value.

12

Not long after my post, I switched to the unofficial Docker Image.

For me, it is less bloated, fits into my Backup strategy with Kopia (rather than Borg in the AiO), easily integrates into my VLANs and I had no issue so far upgrading.

For me, personally, this is far superior to the AiO, although I can understand that the AiO has its benefits. It always depends where you are coming from and what you want to achieve, so I do not want to put down AiO. It might fit a lot of peoples needs, but I found out that it was not for me and I´m happy we have alternatives.

1 Like