Closed silverham closed 3 months ago
That's great sleuthing @silverham - that's why our lagoon default setup only uses the default network for pod networking.
No worries ^^
Joshua Stuart Graham
I had an idea/consideration, maybe create an second network "amazeeio-network-tooling", if needing to share a central mailhog etc. then make sure to NOT attach a pmagy/http proxy server to it. Also, it might be good to have a different/additional hostname for mailhog e.g "mailhog.shared" so it's less confusing where mail is going and no conflict if a project already has a mailhog setup locally.
The Lagoon images configure the mailhub settings (to use the mailhog provided with pygmy or similar) in an entrypoint, based on the host docker network - so it shouldn't require a different network to access it. https://github.com/uselagoon/lagoon-images/blob/main/images/php-fpm/entrypoints/50-ssmtp.sh#L24C42-L24C63
If you're not running pygmy - any docker service exposing a mailhog/mailpit instance on port 1025 will collect the outbound mail
mailhog:
image: pygmystack/mailhog:latest
labels:
lagoon.type: none
ports:
- "1025:1025"
- "8025:8025"
Thanks for digging in @silverham — I think you're right with the local stack should define the mailhog service (either in docker.compose.yml with a lagoon.type of none or in the override) and we can provide default configuration to connect Drupal to it rather than using the one provided by pygmy.
I'll get a PR going to resolve.
@silverham — after doing some extra digging, it looks like the standard entrypoint for Lagoon has a hardcoded IP for the docker bridge that it checks to see if mailhog is listening with:
elif nc -z -w 1 172.17.0.1 1025 &> /dev/null; then
echo -e "\nmailhub=172.17.0.1:1025" >> /etc/ssmtp/ssmtp.conf
return
on mac in particular, this IP is not available by default unless the container is attached to the network
I've added https://github.com/uselagoon/lagoon-images/pull/1073 to add support for host.docker.internal
.
Wow, that's amazing that support is mostly already built in. Awesome digging to you too!
PROBLEM
Hi Team, due to commit:
[ https://github.com/govCMS/scaffold commit ]
Commit: 5f315bf4a1d4dffacb87f73c343d84a506b086ce PR: https://github.com/govCMS/scaffold/pull/72
[ Per project GovCMS SaaS commit ]
When you multiple GovCMS projects running, the
nginx
docker container will connect to any projects'php
container, as all projects have access to each othersphp
container via the externalamazeeio-network
network. So then local development is broken. Previously this issue didn't exist because theamazeeio-network
network only existed on thenginx
container.Additionally, local development override for oembed is now broken, so if the internet goes down, local development of firewalled GovCMS instances cannot function. e.g.
@see here
nginx
connects tophp
container (which the hostname is not unique per network), where it should connects overdefault
network which is per project so issues.https://github.com/uselagoon/lagoon-images/blob/main/images/nginx-drupal/drupal.conf#L78
I propose to revert this commit.
WHAT SHOULD OF BEEN DONE INSTEAD for mailhog etc.
These services should be defined in a
docker-compose.override.yml
file and use thedefault
network so no conflicts.WORKAROUND
Option 1) FOR ALL PROJECTS - revert the commit by commenting out the
- amazeeio-network
line except for nginix.OLD:
NEW:
Then
docker-compose up -d
on all projects.Option 2)
Create a new separate network e.g.
amazeeio-network-additional
.Run:
docker network create amazeeio-network-additional
Attach the
pygmy
reverse proxy to the new networkdocker network connect amazeeio-network-additional amazeeio-haproxy
Then per project, comment out the
- amazeeio-network
line and add the- amazeeio-network-additional
line.OLD:
NEW:
And same with the
external network definition at the bottom of the
docker-compose.yml` file.OLD:
Then
docker-compose up -d
on that project.