Static Builds verwenden
Ein Static-Build-Artefakt kann auf zwei Arten bereitgestellt werden: entweder wird daraus ein Workspace erstellt, um selbst eine Instanz zu betreiben, oder es wird als Managed Service Provider veröffentlicht, sodass andere Teams es über den Servicekatalog bereitstellen können.
Beide Wege benötigen die beim Export ausgegebene Artefaktreferenz, zum Beispiel registry.example.com/team-1/shop:v1. Siehe Einen Static Build erstellen für die Erstellung eines solchen Artefakts.
Einen Workspace aus einem Artefakt erstellen
Ein aus einem Artefakt erstellter Workspace besitzt kein Git-Repository. Beim ersten Start schreibt Codesphere die reine Run-Konfiguration des Artefakts als ci.static.yml in den Workspace. Sie erscheint als CI-Profil static.
Dafür ist zusätzlich zu static-landscapes das Feature-Flag static-build-workspace-creation erforderlich.
- UI
- Public API
- Klicke in der Resource Group (Team) auf Create Workspace.
- Wähle als Quelle den Tab Static Build.
- Füge die OCI-Artefaktreferenz ein, zum Beispiel
registry.example.com/team-1/shop:v1. - Wähle wie gewohnt einen Namen und einen Plan für den Workspace und erstelle ihn.
Erstellen eines Workspace aus einem Static-Build-Artefakt.
POST /api/workspaces akzeptiert die Referenz in staticBuildArtifact anstelle von gitUrl.
curl -X POST "https://<your-codesphere-url>/api/workspaces" \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"teamId": 1,
"name": "shop-v1",
"planId": 21,
"isPrivateRepo": false,
"replicas": 1,
"staticBuildArtifact": "registry.example.com/team-1/shop:v1"
}'
Sobald der Workspace läuft, wird das static-Profil wie jedes andere Profil bereitgestellt:
- UI
- Public API
- Öffne Deploy im Workspace und wechsle zum Execution Manager.
- Wähle das CI-Profil
static. - Klicke auf Sync Landscape und bestätige. Die Services starten aus den vorgefertigten Images.
curl -X POST "https://<your-codesphere-url>/api/workspaces/<workspaceId>/landscape/deploy/static" \
-H "Authorization: Bearer YOUR_API_KEY"
Templatisierte Werte in der Konfiguration, wie ${{ vault.KEY }} oder ${{ workspace.env['KEY'] }}, werden aus dem Vault und der Umgebung dieses Workspace aufgelöst. Der Workspace enthält keinen Quellcode. Um die Anwendung zu ändern, muss die Quell-Landscape geändert und ein neues Artefakt exportiert werden; anschließend wird daraus ein neuer Workspace erstellt.
Ein Artefakt als Managed Service Provider veröffentlichen
Ein Landscape-basierter Provider kann anstelle eines Git-Repositorys aus einem Static-Build-Artefakt bereitgestellt werden. Teams stellen die Anwendung dann über den Servicekatalog bereit, und Codesphere erstellt in ihrem Team einen Workspace aus dem Artefakt und deployt dessen static-Profil. Deployments hängen von keinem Repository-Zugriff ab und führen exakt die exportierten Images aus.
In der Provider-Definition wird backend.landscape.staticBuildArtifact anstelle von gitUrl auf das Artefakt-Repository ohne Tag gesetzt. Jeder Eintrag in versions legt dann einen artifactTag anstelle von gitRef und ciProfile fest.
name: shop
schemaVersion: v1
author: Your Team
displayName: Shop
category: ecommerce
description: The shop, deployed from a static build.
backend:
landscape:
staticBuildArtifact: registry.example.com/team-1/shop
configSchema:
type: object
properties:
SHOP_NAME:
type: string
description: Name shown in the shop header
default: My Shop
detailsSchema:
type: object
properties:
hostname:
type: string
format: uri
versions:
1.0.0:
artifactTag: v1
description: Initial release
Konfiguration und Secrets funktionieren wie bei Git-basierten Providern. Eigenschaften aus configSchema werden zu Umgebungsvariablen der Landscape, und Eigenschaften aus secretsSchema landen in deren Vault. Sie werden daher vor dem Export in der Quell-Landscape mit ${{ workspace.env['SHOP_NAME'] }} und ${{ vault.KEY }} referenziert. Siehe Konfiguration und Secrets an Landscapes übergeben.
- Provider-Editor
- Public API
- Setze den Backend-Typ auf Landscape (Static-Build-Artefakt).
- Gib das Artifact Repository ein, zum Beispiel
registry.example.com/team-1/shop. - Füge unter Versions eine Version hinzu und gib deren Artifact Tag ein, zum Beispiel
v1. - Fülle die übrigen Abschnitte aus und klicke auf Publish to Catalog.
Erstellen eines Service Providers aus einem Static-Build-Artefakt.
Siehe Einen Provider in der UI erstellen für den gesamten Editor.
Die Definition wird über denselben Endpunkt wie bei jedem anderen Provider veröffentlicht, PUT /api/managed-services/providers, mit der obigen Definition sowie einem scope. Siehe Einen Provider veröffentlichen und aktualisieren.
Um ein neues Release auszuliefern, wird die Landscape erneut mit einem neuen Tag exportiert, eine Version hinzugefügt, die diesen fixiert, und die Definition erneut veröffentlicht. Bestehende Versionen bleiben unverändert.
Private Artefakte
Codesphere liest ein Artefakt und zieht dessen Images mit den Container-Registry-Zugangsdaten der Resource Group (Team), der der konsumierende Workspace gehört. Bei einem selbst erstellten Workspace ist das das eigene Team. Bei einem Managed Service ist es das Team, das den Service aus dem Katalog bereitstellt; Codesphere erstellt den Workspace des Services in diesem Team. Die Zugangsdaten desjenigen, der den Provider veröffentlicht hat, werden nicht verwendet.
Ein öffentliches Artefakt-Repository funktioniert daher überall. Ein privates benötigt in jedem konsumierenden Team einen Container-Registry-Eintrag, dessen Adresse das Artefakt-Repository abdeckt, zum Beispiel registry.example.com/team-1. Ohne diesen Eintrag startet der Workspace nicht, und wird der Eintrag später entfernt, schlägt der nächste Start des Services fehl.