What's the best way to cache Bluefin's containers in a homelab? #4738
Replies: 2 comments 4 replies
|
Good news: bootc natively supports this via the standard How it works: bootc uses the same One caveat: Docker Registry's built-in pull-through cache only supports Docker Hub — it cannot proxy Setup outline:
sudo mkdir -p /etc/containers/registries.conf.d
cat <<'EOF' | sudo tee /etc/containers/registries.conf.d/50-local-cache.conf
[[registry]]
location = "ghcr.io"
[[registry.mirror]]
location = "myhome.internal:5000"
EOF
If your local registry uses HTTP (no TLS), add No need to For pre-warming the cache, a cron job or systemd timer on your NAS running something like To reply, just mention @dosu. Share context across your team and agents. Try Dosu. |
|
I'm using a local instance of zot as a image registry mirror and works fine. However, there's a caveat with the solution proposed above: bootc will fail to validate the sigstore signatures. To fix that, you have to enable the sigstore attachments for your image registry mirror with a yaml file in |
Uh oh!
There was an error while loading. Please reload this page.
I've got a couple of Bluefin-running devices and might add another soon. That's starting to look like I could use some kind of caching on my home NAS. Combined with some way to (nightly?) look for the latest update, all these clients could pull from my local copy on a 10G wired network or >1G WiFi instead of being bottlenecked on my home Internet connection.
Would I be best off setting up a Docker registry cache, perhaps as describe in this article? and bootc switching to e.g.
myhome.internal/ublue-os/bluefin-nvidia-open:gtsOr is there another better way to do this, perhaps one that isn't much more complicated than
brew install bluefin-caching-proxyand pointing my 😉With my Debian-based setups in the past, I configured
Acquire::https::Proxy-Auto-Detectto hit a normal general HTTP(S) proxy running with Squid, fronted by a script that could check if the expected proxy was accessible or not.All reactions