Support Caddy v2 via JSON configuration

[Baldinof]

Hi!

Here is a first draft of a migration for Caddy v2.

Todo list:

• [x] Caddy module with JSON configuration
• [x] Caddyfile support
• [ ] Tests
• [x] Updated README
• [ ] CI / Github Actions

@mholt For the Caddyfile support I might need your expertise :)

For what I understand we will need a new class to be able to configure the supervisor top level app. How should we proceed? Would you accept a PR?

Should fix #14

[Baldinof]

Thanks @mholt for the explanation, I think I will provide the 2 options, being able to configure supervisor in an HTTP Caddyfile is very useful (php-fpm is a good example), and it makes sense to have a dedicated adatper to use caddy as supervisor.

@lucaslorentz No problem to maintain this module in my Github account. I will just finish it here, so I can have reviewers :)

[Baldinof]

Hi there!

I think this can be released and I would like to move forward on this :)

I would appreciate some feedback on the Caddyfile syntax:

{
  supervisor {
    # No block prefix, whole command line on the block definition
    php-fpm --no-daemonize {
      env APP_ENV production

      restart_policy always

      redirect_stdout stdout # Should this be the default?
      redirect_stderr stderr
    }

    # block configuration is optional    
    node worker.js
  }
}

mysite.com

root * /var/www/html
php_fastcgi 127.0.0.1:9000
file_server

@mholt Do you have some pointers on how to make a module viewable here https://caddyserver.com/docs/modules/ ?

[lucaslorentz]

Caddyfile syntax looks good to me.

Now that caddy spits structured json logs by default. I think maybe a better default behavior would be to log stdout and stderr inside zap log messages. But that would require additional changes and can be implemented later.

So, the options for redirect_stdout and redirect_stderr would be:

• log (default)
• stdout (do we still need this? Or maybe only inside logs would be enough?)
• stderr (do we still need this? Or maybe only inside logs would be enough?)
• file
• null

[mholt]

@Baldinof To have your Caddy plugin show up on the Caddy website, simply go to Account, then claim the package there. It will then be available for download as well as showing documentation.

Actually, wait a few days before doing this since I'm releasing some big improvements to that system this week. Edit: All done. Go ahead.

[Baldinof]

@lucaslorentz You are right, and I initially experimented a bit with logs at first. But it comes with a lot of questions, for example:

• In which field the output should be stored so that it's clear where it comes from?
• Supervised process may log in JSON, should it be parsed and added as a zap field for easy filtering? It would be a lot of processing for caddy (but I think just writing json encoded strings to a log field would not be good)
• Do we need to bufferize the output? (users will expect each log entry to be an output line)

Maybe a lot of this could be configured via Caddyfile or JSON, but it's a lot of work.

So, the options for redirect_stdout and redirect_stderr would be:

• log (default)
• stdout (do we still need this? Or maybe only inside logs would be enough?)
• stderr (do we still need this? Or maybe only inside logs would be enough?)
• file
• null

I like it! I implemented it without the log supports for now.

[Baldinof]

Hey there,

The package is claimed on the Caddy website, and this branch has been merged on the master branch under my fork :)

Thank you for you help!