vole
Clone
Read only, no credentials:
https://rodent.software/git/vole.git
Write over SSH with a registered key:
git clone ssh://git@0.0.0.0:2222/vole.git
A free and open-source forge that lives in your Git repo.
Remove the container deployment
9bce37233413e6a56c38d5cf90e79dfa496649b2 · Keenan Nemetz · 3d ago · parent c1edfd3c
Remove the container deployment A Vole instance is one process whose state is a directory on local disk. A container therefore adds a layer without removing one, and it costs something real: the service unit's hardening, and the CI half, which needs an OCI runtime the container does not have without mounting the host's socket — the thing the runner docs refuse. It was also the weakest path in practice. No image is published, so an upgrade meant a source checkout and a Go build where the package is one `apt install`. CI never ran the container; it was tested by hand once, which is a surface that rots quietly. So the Dockerfile, the compose file, the entrypoint, the image's configuration, and the guide go. The deployment checker loses its compose and COPY checks, and the render script is the only shipped script left. Every other mention of Docker in the repository means the CI container runtime, and those stay. Users who manage their machines with Compose or Kubernetes are told where they stand: give the forge a small virtual machine of its own, and the first-boot file works there unchanged.
deploy/README.md +12−14
| @@ -8,18 +8,15 @@ The files here put a Vole instance on a fresh machine. The guides are in | |||
| 8 | 8 | | `cloud-init/vole.yaml` | The forge's first-boot file. Installs the package, writes the configuration, creates the instance admin, starts the service | | |
| 9 | 9 | | `cloud-init/runner.yaml` | The CI runner's first-boot file. Rootless Podman, an unprivileged account, a pinned host key, and the unit enabled | | |
| 10 | 10 | | `cloud-init/render.sh` | Fills either file in from the environment, for pasting into a provider's user-data field | | |
| 11 | | `docker/Dockerfile` | The server in one image, built from this repository | | ||
| 12 | | `docker/compose.yaml` | That image, with a volume for the instance and a health check | | ||
| 13 | | `docker/vole.toml` | The configuration the image starts with, and the file to copy for a deployment | | ||
| 14 | | `docker/entrypoint.sh` | Runs `vole admin init` once, then the command you asked for | | ||
| 15 | |||
| 16 | Cloud-init is the whole deployment story, and it is deliberately the only one. | ||
| 17 | Vole is one package, one configuration file, and one directory, so a first-boot | ||
| 18 | file that installs the package and writes the configuration is the same work a | ||
| 19 | Terraform configuration would describe — without a provider, a state file, an API | ||
| 20 | token with write access to the account, or a second thing to keep upgraded. What | ||
| 21 | Terraform would do outside the machine — a firewall, an address, a DNS record — | ||
| 22 | is three fields in the console you already have open. | ||
| 11 | |||
| 12 | Cloud-init is the whole deployment story, and it is deliberately the only one. A | ||
| 13 | Vole instance is one package, one configuration file, and one directory on local | ||
| 14 | disk, so a first-boot file that installs the package and writes the configuration | ||
| 15 | is everything that happens *inside* the machine. What a provider configuration | ||
| 16 | would do outside it — a firewall, an address, a DNS record — is three fields in a | ||
| 17 | console the operator already has open, and a container would add a layer without | ||
| 18 | removing one: it loses the unit's hardening, and it cannot run the CI half, which | ||
| 19 | needs an OCI runtime of its own. | ||
| 23 | 20 | ||
| 24 | 21 | Three things are deliberate: | |
| 25 | 22 | ||
| @@ -34,6 +31,7 @@ Three things are deliberate: | |||
| 34 | 31 | afterwards is editing `/etc/vole/vole.toml` and restarting, and upgrading is a | |
| 35 | 32 | package install. See [Packages](../docs/packaging.md). | |
| 36 | 33 | ||
| 34 | |||
| 37 | 35 | The runner's unit and its configuration example ship in the package, not here: | |
| 38 | 36 | `packaging/systemd/vole-runner.service` and `packaging/runner.env`. One binary is | |
| 39 | 37 | the forge, the runner, the CLI, and the library, so one package carries both | |
| @@ -42,5 +40,5 @@ units. | |||
| 42 | 40 | `scripts/check-deploy.py` and the `deployment files` step in | |
| 43 | 41 | `.vole/workflows/verify.yaml` check these files on every push: the YAML parses, | |
| 44 | 42 | each template renders with no placeholder left behind, the boot scripts are valid | |
| 45 | `sh`, the container files name paths that exist, and the runner's template, unit, | ||
| 46 | and packaged example agree. It needs no cloud credentials and no network. | ||
| 43 | `sh`, and the runner's template, unit, and packaged example agree. It needs no | ||
| 44 | cloud credentials and no network. | ||