I am running mailcow in Docker and this features the possibility of running Nextcloud inside the Mailcow docker network.
I have Nextcloud sitting in the Nginx container, installed following the Mailcow documentation. In an extra docker container Collabora is running and that functions well with Nextcloud, cool btw.
Nextcloud mail either it tries to talk directly to Dovecot, or it does this using another container. Failure message is as follows, using the same settings I tried with Thunderbird (servername tried full dns name, single name, internal docker IP and LAN IP of the machine): "IMAP server is not reachable¨
Dovecot has the following port config (copied from the Portainer interface):
I can´t see if the above is blocking containers to access Dovecot (I am using all default IP adresses btw, and don´t understand the ::: rules in the above).
From within the ngynx container there is access over port 993, same for the PHP container (looking at some tips I found concerning running nexcloud mail with PHP).
Nextcloud mail is able to communicate with imap servers on the internet (so it works when talking outside).
I am also able to setup thunderbird email using imap to Dovecot from a laptop in the LAN.
I already found the following settings for Nextcloud, they had no effect when toggling:
Yes, the domain certs are auquired using the mailcow solution (letsencrypt). They made an integration for these parts, so it looked the most logical. Also all is accessed from the outside using the same set of ports, also resulting in potential conflicts.
I agree housing in nginx of mailcow also has challenges, maybe (but hopefully not) including this one.
your system is very “custom” this is a reason why you can’t expect many responses.
I’m wondering anybody is familiar with this docs… and I recommend you to stop using containers inside containers. the idea of containers is to have throw-away immutable objects which definitely doesn’t match with an approach to install additional stuff inside of the container.
this might look logical but results is issues nobody is willing to troubleshoot.
AFAIK the most common technology to run multiple services using same user-facing IP address/port combination is reverseproxy …many of them exist and work well with Nextcloud like apachenginxtraefikcaddy and you can choose the one you know or for any other reason.
The problem to differentiate different systems behind reverse proxy remains and you can choose different technologies - in my eyes using unique DNS name for every system is the best approach. Today when you get tls certificates from letsencrypt there is no additional requirement rather some additional DNS records (which you can add as CNAMEs for you existing DNS A-record pointing to your public-facing IP address). The reverse proxy in trun takes care of the TLS certificates and routes incoming traefik to the backend system according to the ruleset you define…
It is not container in container, it is using Nextcloud inside the Nginx container as hostcontainer for the website Nextcloud. For me, I am no docker specialist, this looked as the most simple solution for allready having a acme client, acquiring certs and fitting it into a running environment. I also used more multi container setups, as this is also more common in docker (applicationcontainer connecting to database container for instance).
But looking at the answers, I am convinced this is a dead end as knowledge on this subject is missing here (no complaint btw, it is what it is, maybe have to look at more docker forums for inter container support).
If a proxy could help above the containers (so nginx rerouting to multiple web servers), maybe, but I am expecting more inter container traffix what is going wrong…
Puzzling and I will do some more testing…
Regarding testing I wonder if a Nextcloud setup is possible without external certs, as that is blocking good testing for me, being able to forward a port only once and not again to a testing vm…