docker-compose-stack
Moby
docker-compose-stack | Moby | |
---|---|---|
4 | 214 | |
7 | 67,824 | |
- | 0.4% | |
3.5 | 10.0 | |
about 2 months ago | 5 days ago | |
Shell | Go | |
MIT License | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
docker-compose-stack
-
What if your Pods need to trust self-signed certificates?
You're right, it's a little weird. I wrote a short essay about my setup[1] but the tl;dr is that I wanted certificates distributed in the same way every other thing on my machines is distributed.
I wanted my homeprod setup to be as hands off as possible while still allowing easy management. Each physical host is running Alpine. During provisioning I install docker, Tailscale, and manually start a "root" container that runs[2] docker compose and then starts a cron daemon. The compose commands include one or more "stack" files and are generated based on a yaml file listing the stacks for each host. Watchtower runs with a 30 second cycle time to keep everything updated, including the root container. Adding or updating services means committing and pushing a change to the root container repo, then CI builds and pushes a new image. Watchtower picks up the new image and restarts the root container, which re-runs Compose which in turn starts, stops, modifies, etc anything that's changed.
For certificates, I tried a number of different things but ultimately settled on the method I described earlier. The purpose of the container image is to 1) transport the certificates and install them in the right spot and 2) be updatable automatically with Watchtower.
Certificate changes are very similar to the root container, except the git repo self-modifies upon renewals (yes I keep private keys committed to git, it's a homelab, it's really not a big deal).
[1]: https://www.petekeen.net/homeprod-management-with-docker
[2]: https://github.com/peterkeen/docker-compose-stack/blob/main/...
-
Old School Linux Administration (My Next Homelab Generation)
I really like this article just for the straightforwardness of the setup. Pets not cattle should be the home server mantra.
My setup is not quite as simple. I have one homeprod server running Proxmox with a number of single task VMs and LXCs. A task, for my purposes, is a set of one or more related services. So I have an internal proxy VM that also runs my dashboard. I have a media VM that runs the *arrs. I have an LXC that runs Jellyfin (GPU pass through is easier with LXC). A VM running Home Assistant OS. Etcetera.
Most of these VMs are running Docker on top of Alpine and a silly container management scheme I've cooked up[1]. I've found this setup really easy to wrap my head around, vs docker swarm or k8s or what have you. I'm even in the process of stripping dokku out of my stack in favor of this setup.
[1]: https://github.com/peterkeen/docker-compose-stack
- docker-compose-stack: a fun little zero-ish dependency docker compose continuous deployment tool
- What is everyone using to deploy Docker?
Moby
- An open framework to assemble specialized container systems
-
Release Radar • March 2024 Edition
Having been featured in our February 2023, and January 2024 Release Radars, Moby is the original Linux Container runtime. This new version adds a bunch of changes to the Docker CLI and Moby itself with additional features. There's bug fixes and enhancements, with the main thing for users to be on the look out for containers that were created using Docker Engine 25.0.0. These containers might have duplicate MAC addresses, and thus must be recreated. The same goes for those containers created with Moby 25.0+ and with user defined MAC addresses. Read up on all these changes in the release notes.
-
Choosing a Name for Your Computer
Formlabs does this as well for their 3d printers, my earliest encounter of this was when Docker started getting popular: https://github.com/moby/moby/blob/master/pkg/namesgenerator/...
- Docker Inc. refuses to patch HIGH vulnerabilities in Docker
-
Do not install Docker Desktop on GNU/Linux systems
Try to use moby instead since that is the engine in Docker.
https://github.com/moby/moby
-
Exploring Podman: A More Secure Docker Alternative
> Podman is designed to help with this by providing stronger default security settings compared to Docker. Features like rootless containers, user namespaces, and seccomp profiles, while available in Docker, aren't enabled by default and often require extra setup.
Seccomp has been enabled by default since 2015: https://github.com/moby/moby/pull/18780
It is true that Rootless isn't enabled by default but its "extra setup" can be done with a single command (`dockerd-rootless-setuptool.sh install`)
- Moby: Block io_uring_* syscalls in default profile
- Io_uring will be blocked by default on Docker
-
OpenZFS 2.2: Block Cloning, Linux Containers, BLAKE3
Perhaps.
Thing is, https://github.com/moby/moby/blob/670bc0a46c4ca03b75f1e72f73... is using https://github.com/mistifyio/go-zfs which features code like `out, err := zfsOutput("get", "-H", key, d.Name)` (Source: https://github.com/mistifyio/go-zfs/blob/master/zfs.go#L315) to get a single zfs property.
Somebody chose to use a library as abstraction that looks good but is implemented as a MVP (nothing wrong with that). "In the future, we hope to work directly with libzfs" should have raised an alarm somewhere, though.
What are some alternatives?
CasaOS - CasaOS - A simple, easy-to-use, elegant open-source Personal Cloud system.
podman - Podman: A tool for managing OCI containers and pods.
trust-manager - trust-manager is an operator for distributing trust bundles across a Kubernetes cluster.
containerd - An open and reliable container runtime
kubernetes-replicator - Kubernetes controller for synchronizing secrets & config maps across namespaces
nerdctl - contaiNERD CTL - Docker-compatible CLI for containerd, with support for Compose, Rootless, eStargz, OCIcrypt, IPFS, ...
docker_installs - Docker and Docker-Compose install scripts for various linux distros and versions
docker-openwrt - OpenWrt running in Docker
ca-injector - Painlessly use off-the-shelf images (and your own) in your k8s cluster, with custom root CAs.
ofelia - A docker job scheduler (aka. crontab for docker)
k3d - Little helper to run CNCF's k3s in Docker
Packer - Packer is a tool for creating identical machine images for multiple platforms from a single source configuration.