After lurking for a while and having been helped out quite a bit by discussions here, I wanted to share a CoreOS-based home-server setup I’ve had working for the past couple of months – this is still largely undocumented and has some rough edges, but hopefully may have enough breadth to be useful to someone.
The basic theory behind this is quite simple: use CoreOS and Butane to set up a bare-metal host (though this will extend to remote/VPS setups), and install user-defined configuration into
/etc/coreos-home-server, and systemd services into
/etc/systemd/system. These systemd services will then build containers, run these under Podman, and ensure that all related infrastructure (volumes, networks, etc.) are set up correctly.
File structure is split as follows:
hosts/<name>is the “entrypoint” Butane file, used to include any host-specific configuration as well as any services deployed to the host.
config/commoncontains configuration commonly used by hosts, such as base systemd services for managing Podman containers, volumes, and the like.
config/servicecontains configuration for services deployed to hosts. Hosts can include any and all of these, and currently these cover functionality such as a mail server (Postfix, Dovecot, and Rspamd), XMPP server (Prosody), a MariaDB and Redis setup shared among other services, etc.
Included alongside bare-metal hosts is a special “virtual” host, which is used to integration test on a local QEMU-based setup. All of this is tied together by a Makefile, which will ensure that Butane files are included and re-built as needed, and that can serve compiled host configuration over a one-time HTTP server, for use in setting up bare-metal hosts on a local network.
Secrets are currently handled as GPG-encrypted environment files at rest, transmitted to hosts unencrypted and stored with root-only permissions – not ideal, but it’s simple and allows for using the same files in both systemd services and Podman containers. It’s exciting to see native supports for secrets in Podman and Buildah, though, so we’ll see how this pans out.
There’s still a bit of work to do but I’m happy with the setup (enough to share it and not be embarrassed); things I’m looking forward to fixing:
Service dependencies can sometimes trigger out-of-order due to the fact that systemd
Type=Notifywill, at best, wait for conmon to set up and does not respect how much time a service itself might take to start up. This is mostly an issue with MariaDB, which unfortunately isn’t build with systemd support by default (on
docker.iobuilds). I just saw that a recent request to hook up
sd_notifywith health-checks has been closed, so the future looks bright: [RFE] Integrate sd_notify with podman health checks · Issue #6160 · containers/podman · GitHub
Volume backups are currently not generating correctly, and there’s no service for pushing these to an external provider (such as rsync.net or whatever).
All containers run on the same network, due to DNS resolution issues when more than one network is attached (DNS resolution works only for one network when two networks are attached · Issue #8399 · containers/podman · GitHub). Ideally we’d have container-specific networks, where needed, so that not all containers can open connections to the database, etc.
Hopefully some of this is of use to y’all! Thanks for reading, and feel free to weigh in with questions or improvements!