bottlerocket-os / bottlerocket-os/bottlerocket

Support overriding server for registry mirrors

Open
#4,891 0 comments 0 reactions 0 assignees View on GitHub
status/needs-triage type/enhancement
Dominant language
Rust
Stars
9.7k
Forks
586
Avg merge
1d 18h
Merged PRs (30d)
12

Description

**What I'd like:**

When configuring registry mirrors, I'd like to be able to ensure "_only_ the mirror is utilised and the upstream not consulted" as in [the example in the containerd docs](https://github.com/containerd/containerd/blob/main/docs/hosts.md).

On AL2023, I can manage this by configuring `/etc/containerd/certs.d/` exactly how I want it, via user data. On Bottlerocket, however, I'm limited to what's supported by [`settings.container-registry.mirrors`](https://bottlerocket.dev/en/os/1.62.x/api/settings/container-registry/#mirrors), which at the time of writing behaves as follows.

> The runtime will still try the default registry URL if the mirrors fail.

**Any alternatives you've considered:**

It's a nonstarter practically, but it would be technically possible to replace every `image` in every manifest on every cluster with the appropriate mirrors.

I would probably need a little hand-holding, but I'd be happy to open a PR (or two) for this if agreeable. I've found the similar (in area) PR https://github.com/bottlerocket-os/bottlerocket-settings-sdk/pull/134 and I figure thar-be-registries needs to be updated in https://github.com/bottlerocket-os/bottlerocket-core-kit too.

Contributor guide

Open the contributing guide

Research direction

Start by reviewing the settings.container-registry.mirrors API behavior and the referenced bottlerocket-settings-sdk PR #134. Then inspect thar-be-registries in bottlerocket-core-kit to trace how mirror configuration is generated. Done means the configuration can prevent fallback to the upstream registry, with the relevant behavior covered by project tests.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
infrastructure, operating-systems
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
62/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.