89 lines
2.9 KiB
Markdown
89 lines
2.9 KiB
Markdown
# Commercial Deployment
|
|
|
|
Diese Datei beschreibt die technische Härtung der offiziellen, lizenzierten Distribution. Sie ist keine Vertrags- oder Lizenzvorlage.
|
|
|
|
## Runtime-Secrets
|
|
|
|
Bevorzugt werden Datei-Secrets:
|
|
|
|
```env
|
|
LICENSE_TOKEN_FILE=/run/secrets/license/token
|
|
BULK_API_KEY_FILE=/run/secrets/bulk/key
|
|
```
|
|
|
|
statt Secrets direkt in Prozesslisten, Compose-Dateien oder Git-Repositories zu hinterlegen.
|
|
|
|
## Lizenzmodi
|
|
|
|
- `offline`: vollständig lokale Signaturprüfung;
|
|
- `hybrid`: zentrale Prüfung mit signiertem Lease-Cache und Offline-Grace-Periode;
|
|
- `online`: aktuelle zentrale Prüfung erforderlich.
|
|
|
|
Für hochverfügbare Publisher-Installationen ist `hybrid` meist der geeignetste technische Kompromiss. Für einen streng kontrollierten, zentral widerrufbaren Dienst kann `online` sinnvoll sein.
|
|
|
|
## Full-/API-Container
|
|
|
|
Ein lizenziertes Full-Deployment kann beispielsweise setzen:
|
|
|
|
```env
|
|
REQUIRE_LICENSE=true
|
|
LICENSE_MODE=hybrid
|
|
WHITE_LABEL=true
|
|
```
|
|
|
|
`WHITE_LABEL=true` wirkt nur mit der Capability `white_label`.
|
|
|
|
## Bulk
|
|
|
|
Der Bulk-Dienst sollte separat skaliert werden. Er benötigt:
|
|
|
|
```text
|
|
bulk_api
|
|
```
|
|
|
|
und sollte mit `BULK_REQUIRE_API_KEY=true` betrieben werden. Das mitgelieferte `Dockerfile.bulk` erzwingt diese Defaults bereits.
|
|
|
|
## Kubernetes
|
|
|
|
`deploy/kubernetes-bulk.yaml` enthält:
|
|
|
|
- 3 Replikate;
|
|
- Rolling Update ohne geplante Unterbrechung;
|
|
- PodDisruptionBudget;
|
|
- HPA;
|
|
- Topology Spread;
|
|
- non-root;
|
|
- read-only root filesystem;
|
|
- seccomp `RuntimeDefault`;
|
|
- keine Linux-Capabilities;
|
|
- deaktiviertes ServiceAccount-Token;
|
|
- Lizenz- und API-Key-Secrets als Dateien;
|
|
- internen ClusterIP-Service;
|
|
- keinen öffentlichen Ingress.
|
|
|
|
## CORS
|
|
|
|
`API_ALLOWED_ORIGIN=*` ist für offen konsumierbare Badge-/Manifest-APIs bequem. Für interne kommerzielle APIs kann CORS vollständig deaktiviert werden:
|
|
|
|
```env
|
|
API_ALLOWED_ORIGIN=
|
|
```
|
|
|
|
oder auf einen kontrollierten Origin beschränkt werden.
|
|
|
|
## Observability
|
|
|
|
- `X-Request-ID` wird übernommen oder erzeugt;
|
|
- Requests werden strukturiert als JSON protokolliert;
|
|
- `/metrics` liefert Prometheus-Metriken;
|
|
- `/healthz` ist reine Liveness;
|
|
- `/readyz` berücksichtigt bei Bulk die Lizenz-Capability und die notwendige API-Key-Konfiguration.
|
|
|
|
## Supply Chain
|
|
|
|
Die GitHub-Actions-Vorlage baut Full- und Bulk-Images für amd64/arm64, erzeugt BuildKit-Provenance und SBOMs und signiert den veröffentlichten Multi-Arch-Digest keyless mit Sigstore/Cosign über GitHub OIDC. Produktive Deployments sollten freigegebene Digests statt ausschließlich `latest` verwenden und die Signatur vor dem Rollout prüfen. Siehe [`SUPPLY-CHAIN.md`](SUPPLY-CHAIN.md).
|
|
|
|
## Getrennte Bulk-Topologie
|
|
|
|
In einer professionellen Topologie sollte der interne Bulk-Dienst `BASE_URL` für seine eigene Instanz-/Domainbindung verwenden und `OUTPUT_BASE_URL` auf die öffentlich erreichbare Deklarationsinstanz setzen. So bleiben erzeugte Links gültig, obwohl `SERVICE_MODE=bulk` selbst keine HTML-Deklarationen oder Badge-Endpunkte bereitstellt.
|