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?
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.
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.
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.
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:
I removed all Nextcloud AIO Containers and the nextcloud-aio Network
I re-created the nextcloud-aio Network myself with the macvlan driver and pointing to one of my VLANs like this:
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.
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.