A reference implementation of a distributed Caddy build server

Hello all!

So I’ve enjoyed working on parts of Caddy the past few weeks, mainly on bugfixes and tinkering around with some new plugin ideas. I found myself having to build and test Caddy with different permutations of plugins and operating systems fairly frequently. Combine this need with some recent discussions around the future around caddy {add|remove}-package commands and it appeared that this might be useful in a few different cases. Some folks also asked about standing up their own build servers.

So I wrote one and tossed it up at GitHub - Compy/prox-builder: A distributed Caddy binary build server (I would’ve called it something like Caddy-builder or CaddyTron9000 but I didn’t want to risk stepping on any Trademark toes). It’s Apache 2.0 licensed, so feel free to go and do Apache 2.0 things with it.


What it does

  • Runs as a single binary or distributed amongst a hub process and 1-many agent processes
  • Wraps xcaddy functions
  • Allows you to specify a base Caddy version when compiling
  • Relays build log information back to you in realtime via websocket (no external dependencies like Pusher)
  • Caches builds based on a key of {arch,os,caddy version,sorted package list} so that duplicated builds are returned immediately (great for CI)
  • Features a lightweight UI (HTML/CSS/JS all roughly under 130kb), embedded directly into the go binary

What it doesn’t do (yet)

  • S3 storage, but I’m working on it
  • Update the “available Caddy versions” and latest commit SHA on regular intervals so that locally cached binaries are evicted appropriately
  • Storage pruning - serving tons of builds over local storage can quickly chew up disk space. We should consider culling based on a storage threshold being breached.
  • Work with {add|remove}-package commands. Ideally we want to support specifying and endpoint with that command. Though if the argument is made to keep things immutable with respect to suggested Caddy deploys, this can be stricken.

Demo

I threw a demo of it up at https://builder.prox.sh - It’s actively mirroring Caddy’s package list. However be warned, it’s running on dev hardware. If you point your CI stack at it, finger wagging will ensue.

I’ll be cleaning up the code and squashing some bugs.

Tiny Caveat

This runs with an altered version of xcaddy - I had to modify the core builder and environment structs to support passing a custom Logger via the context. This is solely for relaying build logs through websockets. We use a custom logger here per build job so that multiple websocket+build sessions don’t experience cross-talk. Those modifications are here.

Maybe this will be useful for someone!
Jimmy

5 Likes

This is great!

We were talking about this in our developer Slack. Sounds like it’s pretty similar to our custom build server (uses xcaddy, can have many builder processes, caches results, etc).

We’re trying to figure out a good way to go forward wit those commands, since we just don’t have the resources to guarantee our build server at scale these days. I agree that a way to specify the endpoint is a good idea. We’d want to formalize the API first though.

Do you want us to send you an invite to our Slack?

4 Likes

Please do! I’d love to help any way I can!

4 Likes

This topic was automatically closed after 30 days. New replies are no longer allowed.