Packaging Caddy

[alfiepates]

@Bitti09 Ehh, could end up being a bit convoluted, and IMO doesn’t line up with the Caddy philosophy.

[matt]

when caddy would become more modular we could manage it like:

• caddy -> Installs caddy server without any plugins
• caddy-plugin-hugo -> adds Hugo Plugin to caddy and restarts caddy after successful install
• caddy-plugin-git -> adds Git Plugin to caddy and restarts caddy after successful install

Interesting idea.

When Caddy gets a REST API this will be possible with a simple HTTP request.

IMO doesn’t line up with the Caddy philosophy.

It does if another machine does the build, and the “working” Caddy process doesn’t stop until the new one is working fine (we already have this logic in current reloads).

[alfiepates]

another machine does the build

I feel I’m going to end up hacking together a script that generates .deb packages based on the plugins you want…

[z00000mer]

I just woke up from my old man nap, so just kick me if I’m spewing fumes. What about having plugins available via something like Webmin and have this automagically parked behind a Basic Authentication wall? And this whole webpanel available as a boolean choice on the initial caddyserver install?

I know. It’s either time to brew a pot of joe or go back to letting the cat sleep on my head.

[matt]

I’m fine with it if people in the community (you folks) want to package Caddy up for distros. I’m not gonna stop you. Do it however you think is best. I don’t have experience in that area. I just ask that if you do so, to keep it maintained and up to date with the latest stable Caddy version.

[hendry]

As an ex-Debian maintainer myself, I think distro packages are a gigantic waste of time.

Developers should use go get. Production users should use Docker.

KISS!

[alfiepates]

@matt Why not consider a Caddy-specific package manager that can be installed as a distro package? That way, you’d be able to leave the build process on the Caddy build servers but still automate, say, the creation of a Caddy user/service file/etc. Once we had a functional package manager/build environment, it could even be genericised for other go-based projects.

@hendry

I think distro packages are a gigantic waste of time.

As someone who doesn’t particularly enjoy writing systemd service files, I think they’re a gigantic time-saver

Production users should use Docker.

I disagree. Firstly, docker doesn’t solve the issue we’ve run into (distributing a “package” with a user’s selection of plugins), and secondly I honestly don’t think Docker all that good. I don’t want to risk getting too off topic, mind, so I’ll shut up and we can have that conversation elsewhere if you fancy it.

[captncraig]

OOOO, cvm = “caddy version manager”

cvm get master
cvm get 0.8
cvm list plugins
cvm install git

Maybe this is what caddyext already is?

[matt]

@matt Why not consider a Caddy-specific package manager that can be installed as a distro package? That way, you’d be able to leave the build process on the Caddy build servers but still automate, say, the creation of a Caddy user/service file/etc. Once we had a functional package manager/build environment, it could even be genericised for other go-based projects.

That’s an interesting idea. It would require installing Go as well, though. So, not for production use – for development machines only?

OOOO, cvm = “caddy version manager”

Something like that would be good. Not sure if “version” is quite the right word, but definitely something along those lines. I think @abiosoft expressed interest in something like this. We’re going to coordinate so that this tool and the build server can share more of the same code.

[alfiepates]

@matt My idea is something along the lines of @abiosoft… as an end-user, I install… say, sudo apt-get install cvm, and fire a command, say, sudo cvm install caddy caddy-hugo caddy-git and then cvm grabs the caddy+hugo+git from the Caddy build servers (just like getcaddy already does), drops it in the appropriate location for the distro you’re on, creates the caddy user, setups up the systemd service file, etc, etc.

Basically, I’d like a tool to automate all the things I already do when deploying Caddy for production use

[abiosoft]

I think I like what @captncraig just proposed and surely going to put it in consideration. Though I’d go for caddyctl or caddytool over cvm. I am not looking at a version manager, rather a caddy tool.

sudo cvm install caddy caddy-hugo caddy-git

Erm… cvm is already Caddy version manager, why install Caddy again ?

[alfiepates]

@abiosoft Yeah, I like caddytool.

Erm… cvm is already Caddy version manager, why install Caddy again?

In my mental picture, the cvm/caddytool/whatever package doesn’t install Caddy itself, it instead grabs the appropriate Caddy binary from the Caddy build servers and plonks it in the right place along with setting up the other guff you need for a decent prod env.

EDIT: Although I would propose calling it something more generic than caddytool, because in that case the Caddy/Caddy plugin architecture could be genericised for other Go-based applications.

[hendry]

Oh no, not another package manager I need to learn to figure out how to install, list, uninstall, rollback, upgrade… please no.

[matt]

How, then, do you propose we teach existing ones how to build Caddy with a custom set of plugins?

[hendry]

Can’t we have instructions with go get?

Or have a Dockerfile generator?

[matt]

But then people need to install Go or Docker (and learn how to use them). I for one would refuse.

[hendry]

You would rather learn a new packaging system for each software you use?

Golang IIUC is supposed to be all about static binaries. So static binaries can be thought of as packages themselves. If people really don’t want to learn something new, why not create a build service for the crazy permutation explosion of plugins you want to offer users?

[matt]

You would rather learn a new packaging system for each software you use?

Not really. Caddy is a bit unique though, in that its static binaries are available for every platform right from compilation and don’t need packaging.

Packaging isn’t really the right word here; what we really want is a way for people to manage their Caddy plugins without having to get their hands in the code. Not that it’s bad, but it can be more convenient to just type a command on the command line, and it knows where to get the plugin or how to download a build of Caddy with those exact features from the build server.

So, ultimately all we need to do is wrap the Go tools or the Download page in front of a nice, user-friendly facade that makes it really easy to get a Caddy binary with or without certain plugins.

[alfiepates]

Or have a Dockerfile generator

No, because Docker is not a solution to this problem.

[crohr]

I was reading about Caddy, and stumbled upon this thread. So just in case you’re still considering package managers, what about trying Packager.io (disclaimer: I’m the guy behind it)?

I suppose it will require a few additional files to have the Heroku Go buildpack correctly detect the app (at the moment it’s failing), but then you would end up with packages for a wide range of Linux distributions.

Let me know if I can be of any help.