I have a compose.yaml serving WordPress with a Traefik reverse proxy. The https port 443 loopback for the WordPress container fails by default because the WordPress container only listens on http port 80. I need to have the loopback go through the reverse proxy. I can do this by adding the site’s domain to the extra_hosts, but I have to hardcode the traefik container IP address, which is not static, so it has to be updated after deploy. What’s the proper way to add a record to the WordPress container’s /etc/hosts file with the Traefik container’s IP address?
services:
traefik:
image: traefik
ports:
- 80:80
- 443:443
...
wordpress:
image: wordpress
extra_hosts:
# how to avoid hardcoding traefik container IP here?
- mysite.com:172.18.0.2
...
It registers the domain as an alias for the container in Docker’s built-in DNS server.
The reverse proxy is usually in a different compose project. If that’s the case, you have an extrnal network and you need to set the alias on that network and not on the default.
Perfect! Just what I was looking for. Is it generally best practice for the reverse proxy service to specify an alias for all the domains/subdomains that it routes?
No. I never needed it. In case I need to access the app itself from the same container, I would configure an internal URL or just use a DNS server pointing to a host machine instead of using loopback ip addresses and hosts files on the host. Since I don’t know what kind of request requires using mysite.com from the wordpress container, I could only recommend using the network alias. You can open a new topic if you want to discuss the internal vs external URL option. If you do so, please, share more details about your use-case.
Update:
Just to be clear. There is nothing wrong with setting the network alias in a local development environment. I just never needed this solution.
Thanks for your help. To clarify, this is a production deployment of a small WordPress site on a VPS server. Traefik manages TLS certificates and forwards HTTP traffic to HTTPS. WordPress and plugins use the loopback interface for various things, including its internal REST API and scheduled tasks. I found certain downloads that generate a PDF performed poorly and site health reports an error by default when it fails trying to access its own container’s port 443, as it only listens on port 80.
I got even more confused. How does the hostname helps with a request towards a loopback (127.0.0.1) IP address? If you just. To be honest I just offered an alternative to the hosts file, but I didn’t completely understand the “loopback” part in the original question either.
By the way if the environment is a production environment I also don’t understand why the domain name has to be added as a network alias or extra host at all. That’s why I assumed it was a dev environment, but on a publicly available production server you could have just set the IP address of the host machine in the extra hosts instead of the IP of the container.
I think I would need more information to understand your situation, but there is no need for more explanation if the network alias works for you. I can live with the thought that I don’t know everything
I don’t fully understand why it works the way it does. The loopback seems to be more than just a request to 127.0.0.1, where the hostname record changes the behavior. By default, the loopback fails with a port 443 connection refused. I did try using the host’s IP in the extra_hosts at first, but then the loopback fails with a connection timeout. The workaround I finally got working was using the Traefik container’s IP. But your alias solution also works and avoids hardcoding the dynamic container IP. Seems like this might be a problem specific to the way containerized WordPress works.
