Zum Hauptinhalt springen
Version: Weekly Build

Erstellen eines Static Builds

Diese Seite erklärt, wie eine Landscape für den Export vorbereitet wird und wie der Export über den Landscape Config Editor oder die Public API ausgeführt wird.

Voraussetzungen​

Eine v0.5-Landscape-Konfiguration​

Static Builds erfordern mindestens schemaVersion: v0.5. Der Export lehnt ältere Konfigurationen ab, und der Landscape Config Editor bietet an, eine v0.4-Konfiguration mit einem Klick zu migrieren. In v0.5 listet ein Service seine Ports als einfache Zahlen auf, und der Service, der den öffentlichen Traffic der Landscape empfängt, benennt seinen Port unter network.landscapeGateway. Eine Landscape mit mehreren öffentlichen Services fügt einen Router-Service mit type: router und network.isLandscapeGateway: true hinzu, der die Pfade enthält.

schemaVersion: v0.5
prepare:
  steps:
    - name: Install dependencies
      command: npm ci
    - name: Compile
      command: npm run build
run:
  web:
    image: node:24-slim
    plan: 21
    network:
      ports: [3000]
      landscapeGateway:
        httpPort: 3000
    steps:
      - name: Start
        command: node dist/server.js

Der Landscape Config Editor bearbeitet v0.5-Konfigurationen, bei allem, was das Formular nicht zeigt, auf Edit YAML klicken. Eine v0.5-Landscape wird wie jede andere bereitgestellt, also vor dem Export testen.

Aktualisieren des CI.yml-Schemas mit einem Klick in der UI.

Ein Image auf jedem Reactive​

In einer regulären Deployment läuft ein Reactive ohne image auf dem Base Image des Workspace. Ein Static Build kann noch nicht auf dieses Image zurückfallen. Er baut jeden Reactive auf dem im image-Feld genannten Image auf, und der Export schlägt bei einem Reactive ohne dieses Feld fehl. Ein Image wählen, das die vom Startbefehl benötigte Runtime mitbringt, zum Beispiel node:24-slim oder python:3.13-slim. Im visuellen Editor unter Runtime Config in den Service-Einstellungen Custom Base Image auswählen.

Nur kopierte Dateien gelangen ins Image​

Das Image eines Reactive enthält drei Dinge: das Base Image, die Pfade, die sein build-Abschnitt hineinkopiert, und seinen Startbefehl. Nichts anderes aus dem Workspace wird übernommen. Insbesondere:

  • Im Workspace installierte Tools bleiben dort, egal ob sie über nix, apt oder einen prepare-Schritt installiert wurden. Ihre Dateien werden nicht kopiert, und die Shell-Umgebung des Workspace, die sie in den PATH einträgt, ist ebenfalls nicht Teil des Images.
  • Dateien unter /home/user/app, die nicht unter copy aufgeführt sind, einschließlich Abhängigkeiten, die prepare installiert hat, wie node_modules oder eine virtuelle Umgebung.

Ein Service, der im Workspace problemlos startet, kann daher im Artefakt mit einem fehlenden Befehl oder Modul fehlschlagen. Für jedes Tool und jede Abhängigkeit, die der Startbefehl benötigt, entweder ein Base Image verwenden, das es mitbringt, oder es in einem build-Schritt erzeugen und hineinkopieren. Das Beispiel im nächsten Abschnitt kopiert dist, node_modules und package.json für eine Node-Anwendung. Nach dem Export das <profile> (static build)-Profil, das er im Workspace hinterlässt, deployen, um das Ergebnis zu prüfen, bevor das Artefakt weitergegeben wird.

Registry-Zugangsdaten​

Für eine private Ziel-Registry die Zugangsdaten einmalig unter Team > Settings > Container Registries konfigurieren. Der Export verwendet den Eintrag, dessen Adresse mit dem Ziel-Repository übereinstimmt, und dieselben Einträge ermöglichen es auch, private Base Images zu ziehen. Siehe Verwendung einer privaten Registry.

Option A: Konfigurieren einer neuen Container-Registry durch Navigation zu den Resource-Group-(Team-)Einstellungen aus der Workspace-Tabelle.

Option B: Konfigurieren einer neuen Container-Registry aus dem Static-Build-Export-Dialog.

Konfigurieren des Build-Abschnitts​

Jeder Reactive kann einen build-Abschnitt enthalten, der angibt, welche Workspace-Dateien in sein Image gelangen und welche Befehle vor dem Kopieren ausgeführt werden. Ohne einen solchen enthält das Image nur das Base Image und den Startbefehl.

Im Landscape Config Editor die Einstellungen des Reactive öffnen und zum Tab Build wechseln.

  1. Optional Context festlegen, das Verzeichnis, in dem die Schritte ausgeführt werden, relativ zum Workspace-Root.
  2. Unter Copy Mapping für jeden Pfad, der ins Image kopiert werden soll, auf Add Path klicken. Source ist relativ zum Context, Destination ist ein Pfad innerhalb des Images.
  3. Unter Steps für Befehle, die vor dem Kopieren ausgeführt werden sollen, auf Add Step klicken.
  4. Den Service speichern.

Konfigurieren der Build-Schritte für ausgewählte Services.

Die Build-Schritte laufen nach den prepare-Schritten des Profils, im Workspace, der den Export durchführt, sodass sie sich auf alles verlassen können, was prepare installiert hat. Nur die kopierten Pfade gelangen ins Image.

Exportieren​

  1. Deploy > Landscape Config Editor öffnen und das gewünschte CI Profile auswählen. Änderungen speichern, der Export ist verfügbar, sobald das Profil gespeichert und gültig ist.
  2. Auf Export as Static Build in der Editor-Kopfzeile klicken.
  3. Das Target-Repository eingeben, zum Beispiel registry.example.com/team-1/shop, und einen Tag, zum Beispiel v1.
  4. Auf Export klicken.

Der Dialog zeigt den Fortschritt des Exports an. Er kann geschlossen werden, der Export läuft weiter. Nach Abschluss zeigt der Dialog Static Build Pushed mit der Artefakt-Referenz, und der Workspace erhält ein Profil namens <profile> (static build) mit der exportierten Konfiguration, sodass die statische Version direkt dort deployt werden kann, um das Ergebnis zu überprüfen.

Exportieren einer Landscape als Static Build.

Ein Export kann mit Warnungen abgeschlossen werden. Sie weisen auf Teile der Landscape hin, die das Artefakt nicht vollständig erfasst, zum Beispiel einen Reactive ohne build-Abschnitt.

Private Artefakte

Ein Verbraucher liest ein privates Artefakt mit den Container-Registry-Zugangsdaten der Resource Group (Team), die es deployt, nicht mit den eigenen. Siehe Private Artefakte.