Von Git in die Produktion

Git-basierte Auslieferung verbindet eine geprüfte Quellrevision mit einem unveränderlichen Artefakt und dann mit dem Lebenszyklus einer zuständigen Opfield-Ressource. Die Quellintegration weist nach, was gelesen werden darf, der Build Worker ist für die isolierte Ausführung zuständig, die Registry speichert das Artefakt, und der Container, das Deployment, das Compose-Projekt oder das Pages-Projekt entscheidet, ob dieses Artefakt die Benutzer erreicht.

Die Berechtigung, ein Repository zu bauen, ist keine Berechtigung, eine Produktionsroute zu ändern, und ein erfolgreicher Build ist noch kein erfolgreiches Deployment.

Git-Builds und Push-to-Deploy für Container, Deployments, Compose-Projekte und Pages erfordern Business oder Enterprise; siehe Tarife und Leistungsumfang.

Bereiten Sie vor dem Start die Integration der Quellcodeverwaltung und den Build Worker vor. Lesen Sie für eine statische Website außerdem Pages-Git-Deployments.

Zuständigkeit und Release-Richtlinie festlegen

Einigen Sie sich auf diese Entscheidungen, bevor Sie Produktionsquellen verbinden:

• welche Integration und welche Repository-Identität Opfield verwenden darf;
• welche Repositories und Branches auf der Allowlist stehen;
• wer Quelleinstellungen und Build Secrets bearbeiten darf;
• ob Pushes automatisch Builds auslösen;
• ob ein freigegebener Build automatisch bereitgestellt werden darf oder eine Übernahme erfordert;
• welche Schwachstellenrichtlinie ein Artefakt blockiert;
• welche genauen Prüfungen aus Benutzersicht ein erfolgreiches Deployment definieren;
• wer zurücksetzen oder eine laufende Operation abbrechen darf.

Halten Sie automatischen Build und automatisches Deployment getrennt. Ein automatischer Build erzeugt ein Kandidatenartefakt. Ein automatisches Deployment ändert eine laufende Ressource oder einen Pages-Tag und birgt daher ein anderes Risiko.

Die Ausführungsgrenze vorbereiten

Konfigurieren Sie eine unterstützte GitLab-, GitHub-, generische Git- oder External-SSH-Integration unter Settings > Integrations. Geben Sie dem Connector nur den Repository-Zugriff, der für Erkennung und Klonen nötig ist. Betten Sie keine Zugangsdaten in Repository-URLs ein.

Registrieren Sie einen dedizierten Build Worker und prüfen Sie, dass er Online ist und die für die Build-Zulassung erforderlichen Fähigkeiten zu Ausführung, dedizierter Laufzeit und Ressourcendurchsetzung meldet. Ein Build Worker verwendet dedizierte BuildKit/containerd-Dienste und legt dem Builder-Profil keinen gewöhnlichen Docker-Engine-Socket offen.

Behandeln Sie den äußeren Host des Build Workers oder den unprivilegierten Systemcontainer als Sicherheitsgrenze. Er verarbeitet vom Repository gesteuerte Eingaben und darf keine fremden Workloads, Instanz-Zugangsdaten der Cloud, Deployment-Schlüssel oder Secrets der Control Plane enthalten. Das konfigurierte Egress-Profil sollte zum Build passen: Öffentliche Abhängigkeiten herunterzuladen kann nötig sein, Metadaten-, private und Control-Plane-Bereiche sollten aber gesperrt bleiben.

Die Ressource verbinden

1. Erstellen oder öffnen Sie den Ziel-Container, das Deployment, das Compose-Projekt oder das Pages-Projekt.
2. Wählen Sie den Modus Repository und wählen Sie die freigegebene Integration, das Repository und den Branch.
3. Konfigurieren Sie den Build-Kontext und das Dockerfile oder die begrenzte Compose-Datei und die unterstützten build-Felder. Wählen Sie bei Pages die Erkennung des Paketmanagers, das Build-Skript, die Node-Version und das Artefaktverzeichnis.
4. Fügen Sie quellbezogene Build Secrets nur hinzu, wenn der Build sie wirklich benötigt.
5. Entscheiden Sie automatischen Build und automatisches Deployment getrennt.
6. Speichern Sie die Quellkonfiguration und prüfen Sie den aufgelösten Repository-Pfad, bevor Sie einen Produktionskandidaten auslösen.

Build Secrets werden über den Secret-Mechanismus von BuildKit eingebunden und in unterstützten Logs geschwärzt. Sie sind keine gewöhnlichen Build-Argumente und sollten niemals in ARG, ENV, eingecheckte Dateien, Image-Labels, URLs von Paketmanagern oder Shell-Tracing kopiert werden. Ein während des Builds verwendetes Secret kann durch ein bösartiges Dockerfile dennoch offengelegt werden, daher bleibt die Prüfung des Repositorys Teil der Grenze.

Ein Artefakt bauen und freigeben

Reihen Sie den Build ein und verfolgen Sie seinen dauerhaften Job-Eintrag. Prüfen Sie:

• den aufgelösten Branch und den genauen Commit;
• den zugewiesenen Build Worker und die Zielplattform;
• die Build-Logs mit der erwarteten Schwärzung von Secrets;
• die Ergebnisse von Schwachstellen- und Richtlinienprüfungen;
• den erzeugten unveränderlichen Digest oder das Pages-Artefakt;
• den Status Abbruch, Wiederholung oder abgelöst;
• die zuständige Ressource, die das Artefakt verwenden wird.

Ein Build ist erst dann veröffentlichungsfähig, wenn seine Richtlinienentscheidung freigegeben ist und das Artefakt in der konfigurierten Registry oder im Pages-Deployment-Ablauf verfügbar ist. Ersetzen Sie es nicht durch einen veränderlichen Image-Tag, wenn ein Ausfall von Worker oder Registry die Erstellung des freigegebenen Digests verhindert.

Verhalten bei Compose-Stapeln

Eine Compose-Datei aus einem Repository kann für jeden Dienst mit einem unterstützten build-Abschnitt einen untergeordneten Build erzeugen. Jeder Build Worker führt jeweils einen Build aus, daher kann ein Projekt bei begrenzter Kapazität nacheinander eingereiht werden.

Opfield wartet, bis jedes erwartete untergeordnete Artefakt freigegeben ist, bevor es die per Digest festgelegte, unveränderliche Compose-Revision erstellt. Ein fehlgeschlagener, abgelehnter, abgebrochener oder abgelöster untergeordneter Build blockiert den gesamten Rollout. Das ist beabsichtigt: Eine Mischung aus alten und neuen Dienst-Images anzuwenden, würde dazu führen, dass Quell- und Laufzeitrevision nicht übereinstimmen.

Netzwerke nur für die Laufzeit und Overlays für verwaltete Datenbanken können der bereitgestellten Revision hinzugefügt werden, ohne die verfasste Compose-Quelle umzuschreiben. Prüfen Sie die endgültige Revision, statt anzunehmen, dass die Quelldatei jede Laufzeitanbindung beschreibt, die Opfield gehört.

Bereitstellen und prüfen

Übernehmen Sie das freigegebene Artefakt über den Lebenszyklus seines Eigentümers:

• ein Container verwendet eine kontrollierte Neuerstellung;
• ein Deployment verwendet seinen Blue/Green-Rollout mit Health Checks;
• ein Compose-Projekt erstellt und wendet eine unveränderliche Revision an;
• ein Pages-Projekt erstellt ein unveränderliches Deployment und verschiebt den vorgesehenen Tag.

Prüfen Sie den bereitgestellten Digest oder Commit, den Laufzeitzustand, die Logs, die öffentliche Route und jedes Datenbank-Binding. Prüfen Sie bei Pages das ausgelieferte HTML, die Assets, die für Clients sichtbare Laufzeitkonfiguration und den ausgewählten Tag. Bestätigen Sie bei Docker-Workloads, dass der Ziel-Node den freigegebenen Digest bezogen hat und nicht einen ähnlich benannten Tag.

Halten Sie vor der Übernahme das letzte bekannt fehlerfreie Artefakt fest. Ein Rollback der Quelle sollte ausdrücklich erfolgen: Stellen Sie den vorherigen freigegebenen Digest erneut bereit oder verschieben Sie den Pages-Tag zurück. Denselben Branch später neu zu bauen, kann einen anderen Kandidaten erzeugen, wenn sich Abhängigkeiten geändert haben, und ist daher nicht gleichbedeutend mit der Verwendung des bekannt fehlerfreien Artefakts.

Fehler und Wiederherstellung

Die Quellerkennung schlägt fehl: Prüfen Sie die Autorisierung des Connectors, die Allowlist der Repositories, die Existenz des Branches und das Anwendungsverzeichnis. Erweitern Sie die Integration nicht ohne Prüfung auf eine ganze Organisation.

Kein Worker nimmt den Job an: Prüfen Sie Worker-Status und benötigte Fähigkeiten, Schreibbarkeit der Registry, Leistungsumfang des Tarifs und Egress-Richtlinie. Bestehende Deployments bleiben gültig; warten Sie auf sichere Build-Kapazität, statt den Weg über unveränderliche Artefakte zu umgehen.

Die Richtlinie lehnt das Artefakt ab: Prüfen Sie die Befunde und den Schwellenwert der Richtlinie. Beheben Sie die Ursache oder ändern Sie die Richtlinie ausdrücklich über den freigegebenen Sicherheitsprozess; kennzeichnen Sie denselben Digest nicht nachträglich als vertrauenswürdig.

Das Deployment schlägt nach einem erfolgreichen Build fehl: Behalten Sie den Build-Eintrag. Diagnostizieren Sie die zuständige Ressource, den Health Check, die Node-Kapazität, Secrets und externe Abhängigkeiten. Ein erfolgreicher Build weist die Erstellung des Artefakts nach, nicht die Korrektheit zur Laufzeit.

Automatische Auslieferung schafft Risiken: Deaktivieren Sie zuerst das automatische Deployment und behalten Sie automatische Builds bei, falls sie nützlich sind. So werden weiterhin Kandidaten erzeugt, ohne die Produktion bei jedem Quellereignis zu ändern.

Diagnoseübersicht

Symptom	Zuerst prüfen	Ausführliche Anleitung
Repository wird nicht erkannt	Autorisierung des Connectors, Allowlist der Repositories, Branch, Anwendungsverzeichnis	Integrationen der Quellcodeverwaltung
Build Worker nimmt den Job nicht an	Node-Status, Fähigkeiten, Tarif, Schreibzugriff auf die Registry	Git-Quellen und Build Worker
Build wird abgelehnt	Richtlinienbefunde und blockierender Schwellenwert im Build-Eintrag	Git-Quellen und Build Worker
Artefakt existiert, Deployment schlägt fehl	Deployment-Task, Ziel-Node, Logs, Health Check	Tasks, Ereignisse und Audit
Image kann nicht bezogen werden	Erreichbarkeit der Registry, Digest und gespeicherte Zugangsdaten	Registries und Image-Vertrauen

Bewahren Sie Build-ID, Task-ID, genauen Commit und Fehler, bevor Sie es erneut versuchen. Ein neuer Build kann verdecken, ob der frühere Kandidat abgeschlossen wurde, fehlgeschlagen ist oder noch läuft.