Pull-Credentials und Build-Registry
Woher klickops Images holt, die es nicht anonym erreicht, und wo gebaute Images landen.
Auf dieser Seite
Zwei verschiedene Dinge
Sie klingen ähnlich und tun das Gegenteil voneinander.
| Was es ist | Richtung | |
|---|---|---|
| Pull-Credentials | Zugangsdaten für eine Registry, in der deine Images liegen | klickops liest daraus |
| Build-Registry | Wohin klickops Images legt, die es für dich baut | klickops schreibt dorthin |
Die meisten Projekte brauchen beides nicht. Öffentliche Images brauchen keine Zugangsdaten, und Builds landen in der Registry, die klickops selbst betreibt, solange du nichts anderes angibst.
Pull-Credentials
Die brauchst du, wenn ein Deployment scheitert, weil das Image nicht geholt werden kann, und das Image privat ist. Ein öffentliches Image, das sich nicht holen lässt, hat ein anderes Problem, meistens einen Tippfehler im Tag.
- Geh in der Organisation auf Registries.
- Trag den Registry-Host ein, dazu Benutzer und Token. Nimm ein Token oder einen Deploy-Key statt eines Passworts, denn das kannst du widerrufen, ohne deine eigene Anmeldung zu ändern.
- Rolle erneut aus. Apps der Organisation können jetzt Images von diesem Host nutzen.
Das Token liegt als Secret und wird nie zurückgezeigt, genau wie jedes andere Secret.
Die Build-Registry
Wenn klickops aus einem Repository baut, muss das entstandene Image irgendwo liegen. Standardmässig ist das die Registry, die klickops selbst betreibt, und nichts verlässt die Plattform.
Zeig woandershin, wenn deine eigenen Systeme diese Images auch ziehen müssen, oder wenn eure Vorgaben sagen, dass Artefakte in eure eigene Registry gehören. Du gibst Host und Zugangsdaten mit Schreibrecht an, und Builds landen dort.
Einstellungen im Überblick
| Einstellung | Standard | Was sie bewirkt |
|---|---|---|
| Host | keiner | Der Hostname der Registry, etwa ghcr.io oder registry.example.com. |
| Benutzer | keiner | Das Konto oder der Roboter, der zieht. |
| Token | keines | Nur schreibbar. Ersetzbar, nie lesbar. |
| Build-Registry | klickops-intern | Wohin gebaute Images geschoben werden. |
Grenzen und Fallstricke
- Zugangsdaten gelten pro Organisation, nicht pro Projekt. Wer eine hinterlegt, stellt sie jedem Projekt der Organisation zur Verfügung.
- Eine geänderte Build-Registry verschiebt keine alten Images. Bestehende Deployments ziehen weiter von dort, wo ihr Image tatsächlich liegt.
- Ein rotiertes Token bricht das Ziehen still, bis zum nächsten Mal. Laufende Workloads laufen weiter, weil das Image schon auf dem Node liegt. Der Fehler zeigt sich beim nächsten Deployment oder Neustart.
- Manche Registries brauchen den vollen Pfad, nicht nur den Host. Scheitert ein Pull trotz korrekter Zugangsdaten, prüf, ob die Referenz das Projekt- oder Namespace-Segment enthält, das die Registry erwartet.
Verwandt
- Apps ist der Ort, an dem ein privates Image benutzt wird.
- Deployment aus Git ist das, was in die Build-Registry schiebt.