Zum Hauptinhalt springen
Version: Weekly Build

Übersicht über Static Builds

Ein Workspace baut seine Anwendung bei jedem Deployment neu auf: Er klont das Repository, führt die prepare-Stage aus und startet die Services. Das ist während der Entwicklung genau richtig. Sobald eine Version fertig ist, braucht man jedoch ein unveränderliches Artefakt, das genau so in Produktion geht, wie es getestet wurde – ohne erneuten Build – und das an andere Teams übergeben oder auf andere Codesphere-Installationen ausgeliefert werden kann, ohne Zugriff auf das Quell-Repository zu benötigen.

Ein Static Build ist genau dieses Artefakt. Es verpackt ein CI-Profil einer Landscape in vorgefertigte Container-Images und eine reine Run-Konfiguration der Landscape und überträgt beides unter einem Tag in ein Repository einer Container-Registry nach Wahl. Verwende es, um:

  • In Produktion zu veröffentlichen. Erstelle einen Workspace aus dem Artefakt. Dieser führt die vorgefertigten Images aus, es wird nichts gebaut.
  • Einen Service zu verteilen. Veröffentliche das Artefakt als Managed-Service-Anbieter. Andere Teams – auf dieser oder einer anderen Codesphere-Installation – deployen ihn mit einem Klick aus dem Service-Katalog.

Jeder Konsument führt exakt die exportierten Images aus, sodass sich ein Release überall gleich verhält, wo es deployt wird.

Static Builds benötigen das Feature-Flag static-landscapes; das Erstellen von Workspaces aus einem Artefakt zusätzlich das Flag static-build-workspace-creation. Siehe Feature Flags.

Funktionsweise​

Man wählt ein CI-Profil und ein Ziel-repository:tag, entweder im Landscape Config Editor oder über die Public API. Codesphere führt die prepare-Schritte des Profils sowie die build-Schritte jedes Service in einem Workspace aus, baut pro Service ein Image und überträgt alles in das Ziel-Repository.

Das Repository enthält anschließend unter dem gewählten Tag:

  • Ein Image pro reaktivem Service oder Container-Service. Das im Feld image des Service angegebene Basis-Image, ergänzt um die Pfade, die der Abschnitt build hineinkopiert, sowie den Startbefehl des Service. Managed Containers werden unverändert in das Repository kopiert, sodass das Artefakt nicht von ihrer ursprünglichen Registry abhängt. Der Landscape-Router ist ebenfalls enthalten.
  • Die reine Run-Konfiguration. Eine Kopie des Profils mit leerer prepare-Stage, in der jeder Service auf sein Image im Repository verweist. Pläne, Replicas, Ports, Mounts und templatisierte Werte wie ${{ vault.KEY }} bleiben erhalten und werden dort aufgelöst, wo das Artefakt deployt wird. Managed Services und virtuelle Maschinen bleiben unverändert in der Konfiguration und werden von der Installation bereitgestellt, die das Artefakt deployt.

Die Referenz registry.example.com/team-1/shop:v1 ist das Artefakt. Konsumenten benötigen lediglich Lesezugriff auf das Repository.

Nächste Schritte​