caddycmd: Add upgrade command

[mholt]

I was getting stuck/frustrated on another feature I have planned for Caddy 2.4, so I took a quick break and threw this together, from my own personal wishlist which I expressed in a tweet recently: https://twitter.com/mholt6/status/1349186705002151937

The caddy upgrade command replaces the current Caddy executable with a new one from the build server. It honors custom builds, as long as all the plugins are registered on the Caddy website. Of course, this requires permissions to replace current executable. You might have to run sudo caddy upgrade.

This is very experimental but I figure we can merge this in sooner or later and have people try it out and offer feedback.

There's more we could do here, like allowing the user to customize versions and/or just download the binary without replacing the current one, and/or just print the download URL, even.

Please give it a try!

Here's my log, for illustration:

$ go run main.go upgrade
2021/01/13 22:22:49.201 INFO    this executable will be replaced        {"path": "/tmp/go-build129556065/b001/exe/main"}
2021/01/13 22:22:49.201 INFO    found non-standard module       {"id": "http.handlers.webdav", "package": "github.com/mholt/caddy-webdav"}
2021/01/13 22:22:49.201 INFO    requesting build        {"os": "linux", "arch": "amd64", "packages": ["github.com/mholt/caddy-webdav"]}
2021/01/13 22:22:49.386 INFO    build acquired; backing up current executable   {"current_path": "/tmp/go-build129556065/b001/exe/main", "backup_path": "/tmp/go-build129556065/b001/exe/main.tmp"}
2021/01/13 22:22:49.386 INFO    downloading binary      {"source": "https://caddyserver.com/api/download?arch=amd64&os=linux&p=github.com%2Fmholt%2Fcaddy-webdav", "destination": "/tmp/go-build129556065/b001/exe/main"}

Module versions:

admin.api.load v2.3.0
admin.api.metrics v2.3.0
caddy.adapters.caddyfile v2.3.0
caddy.listeners.tls v2.3.0
caddy.logging.encoders.console v2.3.0
caddy.logging.encoders.filter v2.3.0
caddy.logging.encoders.filter.delete v2.3.0
caddy.logging.encoders.filter.ip_mask v2.3.0
caddy.logging.encoders.json v2.3.0
caddy.logging.encoders.logfmt v2.3.0
caddy.logging.encoders.single_field v2.3.0
caddy.logging.writers.discard v2.3.0
caddy.logging.writers.file v2.3.0
caddy.logging.writers.net v2.3.0
caddy.logging.writers.stderr v2.3.0
caddy.logging.writers.stdout v2.3.0
caddy.storage.file_system v2.3.0
http v2.3.0
http.authentication.hashes.bcrypt v2.3.0
http.authentication.hashes.scrypt v2.3.0
http.authentication.providers.http_basic v2.3.0
http.encoders.gzip v2.3.0
http.encoders.zstd v2.3.0
http.handlers.acme_server v2.3.0
http.handlers.authentication v2.3.0
http.handlers.encode v2.3.0
http.handlers.error v2.3.0
http.handlers.file_server v2.3.0
http.handlers.headers v2.3.0
http.handlers.map v2.3.0
http.handlers.metrics v2.3.0
http.handlers.push v2.3.0
http.handlers.request_body v2.3.0
http.handlers.reverse_proxy v2.3.0
http.handlers.rewrite v2.3.0
http.handlers.static_response v2.3.0
http.handlers.subroute v2.3.0
http.handlers.templates v2.3.0
http.handlers.vars v2.3.0
http.handlers.webdav v0.0.0-20200916200058-c949b3226234
http.matchers.expression v2.3.0
http.matchers.file v2.3.0
http.matchers.header v2.3.0
http.matchers.header_regexp v2.3.0
http.matchers.host v2.3.0
http.matchers.method v2.3.0
http.matchers.not v2.3.0
http.matchers.path v2.3.0
http.matchers.path_regexp v2.3.0
http.matchers.protocol v2.3.0
http.matchers.query v2.3.0
http.matchers.remote_ip v2.3.0
http.matchers.vars v2.3.0
http.matchers.vars_regexp v2.3.0
http.reverse_proxy.selection_policies.cookie v2.3.0
http.reverse_proxy.selection_policies.first v2.3.0
http.reverse_proxy.selection_policies.header v2.3.0
http.reverse_proxy.selection_policies.ip_hash v2.3.0
http.reverse_proxy.selection_policies.least_conn v2.3.0
http.reverse_proxy.selection_policies.random v2.3.0
http.reverse_proxy.selection_policies.random_choose v2.3.0
http.reverse_proxy.selection_policies.round_robin v2.3.0
http.reverse_proxy.selection_policies.uri_hash v2.3.0
http.reverse_proxy.transport.fastcgi v2.3.0
http.reverse_proxy.transport.http v2.3.0
pki v2.3.0
tls v2.3.0
tls.certificates.automate v2.3.0
tls.certificates.load_files v2.3.0
tls.certificates.load_folders v2.3.0
tls.certificates.load_pem v2.3.0
tls.handshake_match.sni v2.3.0
tls.issuance.acme v2.3.0
tls.issuance.internal v2.3.0
tls.issuance.zerossl v2.3.0
tls.stek.distributed v2.3.0
tls.stek.standard v2.3.0

Version:
v2.3.0 h1:fnrqJLa3G5vfxcxmOH/+kJOcunPLhSBnjgIvjXV/QTA=

2021/01/13 22:22:50.544 INFO    upgrade successful; please restart any running Caddy instances  {"executable": "/tmp/go-build129556065/b001/exe/main"}

[mholt]

I suppose we could extend this to add and remove plugins too:
--add <package> / --remove <package>

Or maybe that should be a separate subcommand:
caddy add-package <package> / caddy remove-package <package>

Or even just:
caddy add <package> / caddy remove <package>

Ready, vote!

[francislavoie]

I think this might make sense:

caddy upgrade [--version <version>] [--add <package...>] [--remove <package...>]

I think letting people lock to a specific version is helpful in case they know there's a breaking change ahead that they can't upgrade to just yet, but want to swap out a plugin.

[mholt]

I'm leaning toward separate subcommands since I think upgrading Caddy and changing out its modules are different, separate actions, that probably shouldn't be performed together...

[francislavoie]

Before doing anything else, this should check that the current binary is writable. Otherwise the user may need to do sudo caddy upgrade, so we should warn about that.

I'm leaning toward separate subcommands since I think upgrading Caddy and changing out its modules are different, separate actions, that probably shouldn't be performed together...

Right, which is why I suggest adding --version to not actually upgrade, if that's what the user wants. Could have a thing like --version same I guess?

I don't like the idea of adding too many subcommands. I prefer having fewer with options for related ones.

[rumpelsepp]

I think there should be a way for distros to disable this functionality with e.g. a build tag. Distros manage packages via a package manager und the user should not easily be able to desync the binary with the package. Packages might deploy more files, for instance services, documentation, ….

[mholt]

@francislavoie I'll probably add a --version tag, but still make separate add and remove subcommands.

@rumpelsepp

I think there should be a way for distros to disable this functionality with e.g. a build tag.

I don't know, man... software wants to be free. I'm not thrilled with package managers so I'm not interested in giving them more control over a user's choices.

[rumpelsepp]

I'm not thrilled with package managers so I'm not interested in giving them more control over a user's choices.

You are the maintainer, so that's fine. :)

[mholt]

Going to merge this so people can start trying it more easily