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.

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.

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.