Orchestrator/bahn/aisupport/powers/db-pipeship-onboarding/POWER.md

name, displayName, description, keywords, author

name	displayName	description	keywords	author
db-pipeship-onboarding	DB pipeship Onboarding	Schritt-für-Schritt-Anleitung, um ein GitLab-Repo im DB-Konzern mit pipeship aufzusetzen: Group- und Project-Onboarding, deploy_k8s_generic nach OpenShift/DBCS, CI/CD-Secrets (SOPS/age), Trivy-Container-Security, Container-Annotations und Renovate-Updates.	pipeship gitlab ci deploy_k8s_generic cdaas renovate sops age trivy dbcs onboarding cloud native buildpacks	einfachbahn-lab

DB pipeship Onboarding

Overview

Diese Power führt durch das Aufsetzen eines Code-Repos mit pipeship (Pipeline-as-a-Service der DB Systel): vom Group-/Project-Onboarding über das pipeship-Produkt deploy_k8s_generic (Build → Test → Deploy nach OpenShift/DBCS) bis zu CI/CD-Secrets, Container-Security (Trivy) und automatischen Updates via Renovate. Ergebnis ist eine vollautomatische, compliance-konforme CI/CD-Pipeline.

Für das Hintergrundwissen zum Ökosystem siehe die Power DB DXP Platform Guide. Für scm-info.yaml-Details die Power DB scm-info & Compliance.

Onboarding (Voraussetzungen)

• Zugriff auf GitLab (git.tech.rz.db.de), Artifactory (bahnhub), Cloud-/K8s-Provider
• DXP Mandant (Digitalshop), GitLab-Gruppe via GroupTrust verbunden, GitOps-Repo (tenant-information)
• pipeship CLI: brew tap dbsystel/pipeship https://git.tech.rz.db.de/pipeship/toolbox/homebrew.git && brew install pipeship-cli
• Zusätzlich kubectl, oc, sops, age → prüfen mit pipeship dependency

Schnellster Weg: Im Developer Portal das Software-Template „DBCS project with CDaaS agent" (dbcs-with-cdaas) bzw. ein kombiniertes Template, das Repo + Pipeline + Namespace + Runner erzeugt.

Prinzipien von pipeship

• Reference instead of copy: Pipelines per GitLab include einbinden (kein Copy&Paste).
• Update at your own pace: Updates kommen als Merge Requests (Renovate).
• Convention over Configuration: Standard-Pipeline pro Use-Case, anpassbar.
• Baut auf GitLab Auto DevOps + Buildpacks auf.

Onboarding-Fluss

GROUP-ONBOARDING (einmal pro Top-Level-GitLab-Gruppe)
  Artifactory-Registries (BASS) · CDaaS-Runner · (SonarQube) · CI/CD-Secrets → "pipeship it!"
PROJECT-ONBOARDING (pro Repo)
  Compliance herstellen · Include injizieren · Renovate einrichten

Common Workflows

1. Basis-Compliance herstellen

• scm-info.yaml (Endung .yaml, schema-valide, Beam-ID), README.md, LICENSE → Template init-app-general
• Default-Branch schützen: Settings ➞ Repository ➞ Protected Branches
• Tags per Wildcard *.* schützen (Format major.minor, z. B. 1.2)

2. K8s-Namespace + CDaaS-Runner (GitOps)

Template dbcs-with-cdaas → MR ins tenant-information-Repo. Mit pipeshipSupport: true werden alle nötigen Secrets automatisch im Namespace angelegt:

apiVersion: kas.dp.db.de/v1alpha1
kind: Project
metadata:
  name: myapp-prod
  namespace: p-<tenant>-tenant
spec:
  cluster: riga            # prag für prod
  environment: prod
  pipeshipSupport: true
  customDockerRepos:        # OpenShift kennt keine Wildcards
    - "myteam-docker-release-local.bahnhub.tech.rz.db.de"

3. CI/CD-Secrets verschlüsseln (falls nötig)

Secrets nie im Klartext in GitLab (ADR-18). age-/PGP-Keys liegen im Namespace (K8s) bzw. KMS (AWS). Lokal mit SOPS + age verschlüsseln, verschlüsselt committen — pipeship entschlüsselt zur Laufzeit und exportiert als Umgebungsvariablen. (Beim CDaaS Shared Agent stattdessen secrets.yaml mit GPG-PGP MESSAGE und Tag cdaas-shared-agent.)

4. pipeship-Pipeline injizieren

Template pipeship Pipeline Onboarding → Vendor pipeship, Produkt deploy_k8s_generic, Release-Channel (z. B. resolved/release oder baserunner/release), Zielprojekt → MR mergen. Ergebnis .gitlab-ci.yml:

---
include:
  - https://bahnhub.tech.rz.db.de/artifactory/pipeship-generic-release-local/release/products/deploy_k8s_generic/<version>.yaml
variables:
  DK8G_K8S_TAG: "kubernetes"
  DK8S_HELM_REMOTE_VALUES: |
    https://bahnhub.tech.rz.db.de/artifactory/pipeship-generic-release-local/values-library/1.1.119/tmp-volume.yaml
run_unit_tests:
  image: <image-mit-test-framework>
  script:
    - <test-script>

Build-Verhalten: Dockerfile vorhanden → wird genutzt; kein Dockerfile → Cloud Native Buildpacks (ADR-23). Image wird in Artifactory promoted und in die K8s-Stages deployt.

5. Container-Security & Compliance

• pipeship-Images werden vom pipeship-Team per Trivy/AquaSec gescannt → du bist compliant, solange du aktuell hältst (≤ 14 Tage, Renovate).
• Eigene/überschriebene Images → Risikobewertung liegt bei dir (selbst scannen/Restrisikodeklaration).
• SBOM: Job generate_image_sbom_syft; Compliance Suite scannt Dependencies/Lizenzen.
• read-only securityContext per Default (Schreibpfade als Volume mounten).
• Annotations (Beam-ID, Contacts) automatisch aus scm-info.yaml (GA_REFERENCE_ID, GA_CONTACT).

6. Updates aktivieren (Renovate)

Template pipeship Renovate Starter + Preset:

{ "extends": ["local>renovate/renovate-presets:pipeship", "local>renovate/renovate-presets:pipeship-group"] }

Release-Channels (über Include-URL bestimmt): canary, release, resolved/..., baserunner/....

Definition of Done (Code-Repo)

• scm-info.yaml (.yaml, valide, Beam-ID), README.md, LICENSE
• Default-Branch + Tags (*.*) protected
• DXP Mandant + GitLab-Gruppe (GroupTrust) + GitOps-Repo
• Artifactory-Registries (Naming-Konvention), CDaaS-Runner
• DBCS-Namespace mit pipeshipSupport: true
• .gitlab-ci.yml mit deploy_k8s_generic + Unit-Test-Job
• CI/CD-Secrets verschlüsselt (age/SOPS/KMS), nichts im Klartext
• read-only securityContext + Container-Annotations
• SBOM-Job aktiv, Findings geprüft
• Renovate-Preset aktiv

Available Steering Files

• repo-typen – Setup-Matrix für Code / Doku / Architektur / Konzept-Repos (welche Bausteine wann nötig sind, inkl. deploy_pages_generic für Doku/Architektur).

Troubleshooting

• Pipeline triggert nicht → Tag matcht nicht das geschützte Wildcard (*.*, Format major.minor).
• Include nicht auflösbar → Registry-Naming/Anonymous-Scope prüfen; Channel-URL korrekt?
• pipeship dependency schlägt fehl → sops/age/kubectl/oc nachinstallieren.
• Secret im Pipeline-Log sichtbar → entschlüsselte env-Vars nie ungefiltert ausgeben.
• Renovate erkennt Updates nicht → pipeship-Preset (Regex-Manager) fehlt.

Weiterführend

Vollständiger Praxis-Guide im Repo einfachbahn-lab/doku/deployment-doku, Datei docs/09-pipeship-setup-guide.md (Teil A–D).