You might be overcomplicating things a fair bit. For example, wordpress:latest has Apache and PHP, so you don’t need PHP in your Caddy container, you don’t even need fastcgi, just proxy everything to the WordPress container.
Here’s my boilerplate configuration for WordPress on Docker served by Caddy.
docker-compose.yml
version: '3'
services:
caddy:
image: abiosoft/caddy:latest
command: ["-log", "stdout",
"-email", "letsencrypt@example.com",
"-conf", "/etc/Caddyfile"]
ports:
- 80:80
- 443:443
volumes:
- ./Caddyfile:/etc/Caddyfile
- ./certificates:/root/.caddy
# restart: unless-stopped
wordpress:
image: wordpress:latest
depends_on:
- wordpress-db
environment:
WORDPRESS_DB_PASSWORD: [snip]
WORDPRESS_DB_HOST: wordpress-db
volumes:
- ./wordpress:/var/www/html
# restart: unless-stopped
wordpress-db:
image: mariadb:latest
environment:
MYSQL_ROOT_PASSWORD: [snip]
volumes:
- ./wordpress-db:/var/lib/mysql
# restart: unless-stopped
Caddyfile
example.com {
proxy / wordpress {
transparent
}
}
Portainer would be very similar and easy to add, another Compose service and a proxy.
I like how you’ve got Discourse on an unix socket!
This format won’t work. You need a valid host and port to forward to. If you know the IP of the host, you can use that, but I prefer to use Composed networks wherever possible and refer to services by their container name (as shown in the boilerplate example). This way I don’t need to publish any ports other than Caddy’s.
The Caddyfile WP example is for if Caddy were serving WordPress files itself. This would be the case if you downloaded a distribution of WP and unzipped it to your web root and ran Caddy with PHP on-host; you’re running it off the official Docker image instead, which is a prepackaged deal.
Yep, use the PHP Dockerfile instead of the base repository Dockerfile by using the raw URL instead of the git URL. Plugins build arg still applies.
docker build --build-arg \
plugins=filemanager,git,linode \
https://raw.githubusercontent.com/abiosoft/caddy-docker/master/php/Dockerfile
Need? No, to both of the above. They both have a purpose, though, and could be quite helpful. realip can help for instances where you have orange-clouded your domain in Cloudflare as it will translate all instances of the remote IP (which will be Cloudflare itself 99% of the time) to the real remote client (given by Cloudflare as X-Forwarded-For among other headers), including in your server logs.
cloudflare is a DNS plugin used for DNS validation and might be necessary if you orange-cloud your A records.