Caddy in Docker is simplicity of use really.
I’m running 2 large apps (GitLab/Discourse) on a single server both in their own container. Being able to do the same with Caddy is really convenient. I can make sure it always restarts on crash/boot just by specifying --restart always. No messing with a bunch of systemd files for each service.
Plus I know if I completely mess things up I don’t have to rebuild the entire VPS, just stop the containers
Now I just need to learn docker-compose because it will probably make what I’m doing now seem way too complex.
tl;dr
I can run a bunch of different apps easily on a single server because of Docker.
I mentioned in another thread that there could be tags for all the common configurations, and then an onbuild tag similar to Rails, which might expect a user defined list of desired plugins be present, and build a custom container based on that.
I think the use case would be identical to Nginx, which people use in docker all the time. It has a similar set of problems as well – Nginx can only have plugins added at compile time as well. If none of the official Nginx tags work for someone then they use a community image or make their own. All of this is very O.K., in my opinion.
I’m just imagining a lot of people using Caddy via a Docker image which has a limited set of plugins and never taking advantage of all Caddy has to offer.
Is this problem only in my head? I over think stuff =)
Well, we choose the standard plugins carefully so as to serve the widest number of users (predicted) without bloating the code base or introducing a maintenance burden. It’s a delicate balance.
It’s tricky to get statistics on how many users have Caddy with add-ons or without, but the new build server in the future will give us a better idea.
Anyway, the 6 or so Docker images that are already produced are split about 50/50. 3 of them do not include add-ons, 3 of them do. Of the 3 which do, 2 of them only include the git add-on, and 1 of them includes all of them (but goes out of date very easily).
If there is to be an “official” image, it probably should be without any third-party add-ons; just Caddy core and its standard plugins.
ONBUILD would allow us to create a base Caddy image that would include everything needed to build Caddy+plugins. Then a consumer would make a new Dockerfile to use it like this:
FROM caddy/caddy:base
ENV PLUGINS git,hugo
// Entrypoint & CMD
That way users get to easily choose their plugins without having to wait for compilation whenever they run the image.
Actually, NGINX recently added support for dynamic modules in 1.9.11 so now, at least for some third-party and native modules, you don’t have to recompile NGINX to add new features.
That’s cool! Probably is really nice for people who use Nginx, as it compiles pretty slowly.
I’ve realized an image that builds when run wouldn’t work well at all. I find myself recreating containers all the time with docker-compose, so fast startup time is a must.
# Dockerfile
FROM caddy/caddy:onbuild
# Nothing else in this file
And then the user would have to have a file called plugins in the same directory, that the onbuild directives would derive the requisite information from. This is more or less how the Rails onbuild image works.
git,hugo
I’ll try and whip up a proof of concept this weekend.
It would be ideal to do it your way, what I’m saying is I’m pretty sure it won’t work. All of the onbuild instructions would happen before ENV PLUGINS git,hugo was set properly.
