How to deploy a FPM-based static image?

[andresmrm]

Hello!

The docs says it's possible to deploy a FPM-based static image (updates-via-redeploy), but I'm a bit lost about how to do it.

I've managed to do a Caddy + Wordpress-FPM deploy sharing a volume (/var/www/html) between them. It works, but, as expected, it's not static (so it's harder to control its upgrades through image tag version).

If I try to go static image and don't use a volume to share WP's files with Caddy, how will it serve its static files (CSS, JS etc)? They seem to be spread among many folders (and if I create a volume for each of these folders, which would be annoying, it would also make harder to upgrade these files).

Not sharing WP's files with Caddy also makes it harder (impossible?) to configure it to send the correct requests to FPM to run the corresponding PHP files.

I'm using Caddy, but I think the same problems would happen with other web servers.

Any tips about all that?

Thanks for your attention!

PS: The default Caddy config for PHP decides what to do based on file existence. Without sharing a volume that won't work. I came up with this Caddy config that seems to handle some routes, but probably missing many others. Still, the static files serving problem remains and I have no idea how to reasonably solve it.

localhost {
	handle {
		root * /usr/src/wordpress

		redir /wp-login /wp-login.php
		redir /wp-admin /wp-admin/index.php

		@toRootIndex {
			not path /wp-admin/index.php
			not path /wp-login.php
		}
		rewrite @toRootIndex index.php

		reverse_proxy wordpress:9000 {
			transport fastcgi {
				split .php
				capture_stderr
			}
		}
	}
}

[tianon]

This is definitely harder than it should be, but I think moby/moby#48798 is probably your best bet -- with that, you should be able to mount the WordPress image inside the Caddy container in the appropriate place (because you are correct - FPM won't serve static files by itself).

[andresmrm]

Thank you very much for your quick reply! 😃

I didn't know we could do that, nice! But I'm not sure we'll be able to go this way in this case. We are still installing the plugins after the image is built (couldn't make wp-cli install them without DB access). Also, our Caddy will be serving dozens of websites, and I guess Docker would recreate its container after each website image recreation, no?
For now we are using the Apache image, with Caddy in front of all of them.

[tianon]

Isn't "installing plugins" just copying the appropriate files into wp-content/plugins? 👀

Another option could be to build a custom Caddy image that copies the appropriate files, and make sure you rebuild and redeploy it any time one of your static sites changes, but that is a lot. 😄

[andresmrm]

Isn't "installing plugins" just copying the appropriate files into wp-content/plugins? 👀

That's what I thought, but wp-cli complained about missing DB access, even when not using --activate. There is probably a workaround for that, but I hadn't time to find it.

Another option could be to build a custom Caddy image that copies the appropriate files, and make sure you rebuild and redeploy it any time one of your static sites changes, but that is a lot. 😄

Yeah... I would like to avoid that. 😅