Installationsanleitung

Diese Anleitung enthält umfassende Anweisungen zur Installation von Codesphere Private Cloud. Codesphere wird primär als Helm-Chart bereitgestellt und setzt auf zwei zentrale externe Komponenten: PostgreSQL für die Datenbank und Ceph für hochverfügbaren, verteilten Speicher. Obwohl diese Bestandteil des Helm-Deployments sein könnten, werden sie zur Erhöhung von Stabilität und Robustheit als externe Komponenten behandelt.

Dieses Dokument beschreibt zwei unterschiedliche Installationsmethoden:

1. Multi-Node-Installer: Diese Methode nutzt ein Skript, das über SSH von einer zentralen Setup-Maschine aus Verbindungen zu verschiedenen Hosts aufbaut und die Komponenten sequenziell installiert. Sie ist darauf ausgelegt, ein vollständiges Codesphere-Rechenzentrum von Grund auf (Bare Metal, VMs) zu provisionieren oder sich mit bereits vorhandenen Komponenten zu integrieren.
2. Single-Node-Installer: Dieses Skript installiert jeweils eine bestimmte Komponente auf einem festgelegten Host. Die zu installierende Komponente muss im Befehl explizit angegeben werden.

Beide Installationsmethoden setzen eine globale Konfigurationsdatei config.yaml voraus und erfordern SSH-Zugriff auf alle Ziel-Hosts von der Maschine aus, auf der die Installationsskripte ausgeführt werden.

Die Installer im Überblick​

Warum diese Installer?​

Der Kern von Codesphere wird über ein Helm-Chart bereitgestellt. Für kritische Infrastrukturkomponenten wie PostgreSQL und Ceph (für verteilten, hochverfügbaren Speicher) empfehlen wir jedoch, diese als robuste, externe Dienste einzurichten, anstatt sie im Helm-Chart zu bündeln. Dieser Ansatz sorgt für eine stabilere und belastbarere Umgebung.

Diese Installer sind modulare Werkzeuge und ermöglichen es dir:

• Ein komplettes Codesphere-Rechenzentrum auf neuer Hardware (Bare Metal oder VMs) zu provisionieren.
• Bestimmte bereits vorhandene Komponenten zu nutzen und zu integrieren, falls verfügbar.

Zentrale Installer-Komponenten​

Der Installationsprozess umfasst mehrere zentrale Komponenten:

Globale Voraussetzungen & Einrichtung​

Diese Voraussetzungen gelten sowohl für die Multi-Node- als auch für die Single-Node-Installationsmethode.

Unterstütztes Betriebssystem​

• Ubuntu 22.04 LTS (Server Edition) ist das empfohlene und unterstützte Betriebssystem für alle Knoten.

Hardwareanforderungen​

• PostgreSQL-Knoten (falls die Installation über diese Anleitung erfolgt – für HA werden 2 Server empfohlen):

  • Mindestens 2 CPU-Kerne pro Server
  • Mindestens 4 GB RAM pro Server
  • Mindestens 200 GB unter / (inklusive /etc/codesphere)

• Ceph-Knoten (für HA werden mindestens 3 Server empfohlen):

  • Mindestens 2 CPU-Kerne pro Server
  • Mindestens 8 GB RAM pro Server
  • 1 Festplatte mit mindestens 200 GB für Ceph-Metadaten (BlueStore DB/WAL). Dieser Speicher sollte schnell sein (z. B. SSD/NVMe) und mindestens 4 % der gesamten Block-Speicherkapazität ausmachen. Muss vollständig leer sein (kein Dateisystem).
  • 1 oder mehr Festplatten mit jeweils mindestens 300 GB für Ceph-Blockspeicher (OSDs). Müssen vollständig leer sein (kein Dateisystem).
  • 1 Root-Festplatte mit mindestens 200 GB für das Betriebssystem.

• Kubernetes-Knoten:

  • Mindestens 1 Control-Plane-Knoten.
  • Mindestens 2 Worker-Knoten.
  • Jeder Kubernetes-Server:
    • Mindestens 200 GB unter / (inklusive /etc/codesphere)
    • Zusätzlich 200 GB unter /var/lib/docker (bzw. /var/lib/k0s, falls k0s containerd direkt verwaltet – siehe k0s-Speicherdokumentation).
  • Mindestens 8 CPU-Threads pro Knoten (wie von Kubernetes erkannt).
  • Mindestens 16 GB Gesamtspeicher über alle Worker-Knoten zusammen.
  • Mindestens 8 GB Speicher pro Control-Plane-Knoten.

Benötigte Softwarepakete​

Stelle sicher, dass die folgende Software installiert ist:

• Auf der Installer-Maschine (nur Multi-Node, oder deine Verwaltungsmaschine bei Single-Node):

  • OpenSSH-Client
  • scp (Secure Copy Protocol Client)
  • Node.js Version 22 (eine node-Binärdatei wird auch mit dem Installer geliefert)

• Auf allen Ziel-Knoten (Ceph, Kubernetes, PostgreSQL):

  • iptables
  • Ein Texteditor wie vi oder nano
  • curl

SSH-Zugriff​

• Die Maschine, auf der die Installer-Skripte ausgeführt werden, muss SSH-Zugriff auf alle entfernten Ziel-Maschinen (PostgreSQL-, Ceph-, Kubernetes-Knoten) haben.
• Die SSH-Konfiguration muss SSH-Sitzungen von bis zu 3 Stunden erlauben, z. B. durch Setzen eines geeigneten ServerAliveInterval (siehe unten).
• Der Installer erwartet, dass ein einfaches ssh <IP-ADRESSE> funktioniert, d. h. ohne Passwort und ohne Angabe eines Benutzers.
• Um ein passwortloses Login zu ermöglichen, konfiguriere ein öffentliches Schlüsselpaar für SSH (ersetze id_ed25519_csinstall durch den gewünschten Schlüsselnamen):

  ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_csinstall -C "some identifier"
  # Nutze ssh-copy-id oder kopiere den öffentlichen Schlüssel (*.pub) auf /root/.ssh/authorized_keys auf allen VMs
  ssh-copy-id -i ~/.ssh/id_ed25519_csinstall root@host
  

• Der Benutzer auf den entfernten Maschinen MUSS derzeit root sein.
• Du kannst den SSH-Zugriff für verschiedene Hosts über deine SSH-Konfigurationsdatei konfigurieren (z. B. ~/.ssh/config). Beispiel:

  Host 10.10.123.1
    HostName 10.10.123.1
    User root
    IdentityFile ~/.ssh/id_ed25519_csinstall
      # Optional
    ServerAliveInterval 30
  
  
  # Für alle weiteren Maschinen wiederholen
  

  Weitere Details findest du auf der ssh_config-Manpage.
• SSH-Konnektivität testen: Bevor du mit der Installation beginnst, prüfe, ob du dich per SSH mit jedem Knoten verbinden kannst, indem du einfach ssh <IP-ADRESSE> ausführst, ohne Benutzer, Port oder Schlüsseldatei anzugeben. Bei der ersten Verbindung erscheint möglicherweise:

  Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
  Warning: Permanently added 'hostname,ip_address' (ED25519) to the list of known hosts.
  

  Bestätige yes für jeden neuen Host.

Abhängigkeiten herunterladen​

1. Beziehe das Codesphere-Installer-Archiv (installer.tar.gz) von Codesphere. Dies kann über eine direkte Download-URL oder ein physisches Speichermedium erfolgen.
2. Bei Multi-Node: Lege das Archiv auf dem Server ab, von dem aus du die Installation durchführst.
3. Bei Single-Node: Du musst dieses Archiv auf jedem an der Installation beteiligten Host hochladen und entpacken.
4. Entpacke das Installer-Archiv in ein Verzeichnis (z. B. /etc/codesphere). Du kannst auch das Abhängigkeiten-Archiv deps.tar.gz entpacken, das später nützlich sein könnte.

   mkdir /etc/codesphere
   tar -xvzf ./installer.tar.gz -C /etc/codesphere
   mkdir /etc/codesphere/deps
   tar -xvzf ./etc/codesphere/deps.tar.gz -C /etc/codesphere/deps
   

inotify-Watcher-Limits konfigurieren​

Erhöhe auf allen Kubernetes-Knoten die inotify-Limits, um Probleme mit der Dateiüberwachung zu vermeiden. Erstelle oder bearbeite /etc/sysctl.d/11-inotify.conf mit folgendem Inhalt:

fs.inotify.max_queued_events=16384
fs.inotify.max_user_instances=8192
fs.inotify.max_user_watches=524288

Wende die Änderungen an:

sudo sysctl -p /etc/sysctl.d/11-inotify.conf

Hinweis: Größere Server benötigen möglicherweise proportional höhere Limits.

Konfigurationsdateien und Secrets-Verwaltung​

Beide Installer-Methoden basieren auf zwei Hauptdateien:

• config.yaml: Enthält die Hauptkonfiguration für deine Codesphere-Umgebung.
• prod.vault.yaml: Speichert sensible Informationen, verschlüsselt mit SOPS und Age.

Zertifikate und Schlüssel erzeugen​

Allgemeiner Hinweis: Füge neu erstellten Schlüsseln keine Passphrasen hinzu.

Ceph-SSH-Schlüssel​

Dieser Schlüssel ermöglicht es cephadm, Ceph-Knoten zu bootstrappen und zu verwalten. Erzeuge ihn auf deiner Setup-Maschine:

# Dies erstellt ceph_id_rsa (privater Schlüssel) und ceph_id_rsa.pub (öffentlicher Schlüssel)
ssh-keygen -t rsa -b 4096 -C "ceph" -f ./ceph_id_rsa

Cluster-Ingress-CA​

Codesphere unterstützt mehrere Optionen zur Ausstellung und Verwaltung der Cluster-Ingress-CA, die Zertifikate für den gesamten Ingress-Verkehr innerhalb des Clusters signiert. Die Maschinen der Benutzer, die auf Codesphere zugreifen, müssen dieser CA vertrauen. Du kannst:

• Eine neue selbstsignierte CA erzeugen (Standard, einfach für einen schnellen Start)
• Die bestehende CA oder Zwischen-CA deiner Organisation nutzen (für den Produktivbetrieb empfohlen)
• Eine externe Zertifizierungsstelle einbinden (z. B. HashiCorp Vault, AWS PCA, Let's Encrypt) für automatisiertes Zertifikatsmanagement

Die folgende Tabelle bietet eine Übersicht:

Konfigurationsdetails und Beispiele findest du unter Optionen für die Cluster-Ingress-CA.

(Optional): Eine neue CA erzeugen​

Ersetze MyOrg, DE, KA durch die Angaben deiner Organisation.

# CA-Schlüssel erzeugen
openssl genrsa -out ca.key 2048
openssl rsa -in ca.key -outform PEM -pubout -out ca-pub.pem

# CA-Zertifikat erzeugen
openssl req -x509 -new -nodes -key ca.key -sha256 -days 1068 \
  -outform PEM -out ca.pem \
  -subj '/CN=MyOrg Root CA/C=DE/L=KA/O=MyOrg'

Einen neuen Serverschlüssel für Ingress mit deiner CA signieren​

Ersetze <hostname> durch den primären Hostnamen für deinen Codesphere-Zugriff und MyOrg durch den Namen deiner Organisation.

# Certificate Signing Request (CSR) und neuen Schlüssel für Ingress erstellen
openssl req -new -nodes -out ingress.csr -newkey rsa:4096 -keyout ingress.key \
  -subj '/CN=<hostname>/O=MyOrg'

# CSR mit deiner bestehenden CA signieren
openssl x509 -req -in ingress.csr -CA existing_ca.pem -CAkey existing_ca.key -CAcreateserial \
  -outform PEM -out ingress.pem \
  -days 730 -sha256

(Falls du im vorherigen Schritt eine neue CA erzeugt hast, ist existing_ca.pem gleich ca.pem und existing_ca.key gleich ca.key)

PostgreSQL-Zertifikate (falls PostgreSQL installiert wird)​

Wenn du PostgreSQL über die bereitgestellten Skripte installieren möchtest, musst du dafür Zertifikate erzeugen. Dies erfordert ebenfalls eine CA. Du kannst dieselbe CA verwenden, die für Ingress erzeugt wurde, oder eine dedizierte.

CA erzeugen (falls noch nicht für Ingress erfolgt): Folge den Schritten unter „Eine neue CA erzeugen“ in Abschnitt 3.1.2, falls du eine separate CA für PostgreSQL benötigst. Wir nehmen an, du verwendest pg_ca.key und pg_ca.pem.

Primäres PostgreSQL-Serverzertifikat erzeugen: Ersetze <primary_pg_hostname> und <primary_pg_ip_address>. Falls dein PostgreSQL-Server nicht über einen Hostnamen erreichbar ist, kannst du für das Feld CN auch jeden anderen beschreibenden Namen verwenden.

# CSR für den Primärserver erstellen
openssl req -new -nodes -out pg_primary.csr -newkey rsa:4096 -keyout pg_primary.key \
  -subj '/CN=<primary_pg_hostname>/O=MyOrg'

# Erweiterungsdatei erstellen (primary.v3.ext)
cat > pg_primary.v3.ext << EOF
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names
[alt_names]
IP.1 = <primary_pg_ip_address> # z. B. 10.50.0.1
EOF

# Primärzertifikat signieren
openssl x509 -req -in pg_primary.csr -CA pg_ca.pem -CAkey pg_ca.key -CAcreateserial \
  -outform PEM -out pg_primary.pem \
  -days 730 -sha256 -extfile pg_primary.v3.ext

Replica-PostgreSQL-Serverzertifikat erzeugen: Ersetze <replica_pg_hostname> und <replica_pg_ip_address>.

# CSR für die Replica erstellen
openssl req -new -nodes -out pg_replica.csr -newkey rsa:4096 -keyout pg_replica.key \
  -subj '/CN=<replica_pg_hostname>/O=MyOrg'

# Erweiterungsdatei erstellen (replica.v3.ext)
cat > pg_replica.v3.ext << EOF
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names
[alt_names]
IP.1 = <replica_pg_ip_address> # z. B. 10.50.0.2
EOF

# Replica-Zertifikat signieren
openssl x509 -req -in pg_replica.csr -CA pg_ca.pem -CAkey pg_ca.key -CAcreateserial \
  -outform PEM -out pg_replica.pem \
  -days 730 -sha256 -extfile pg_replica.v3.ext

Starke Passwörter für PostgreSQL-Benutzer erzeugen​

Codesphere verwendet mehrere verschiedene PostgreSQL-Benutzer für den Zugriff auf die Datenbank. Die Benutzer werden vom Installer automatisch in der DB angelegt, die Passwörter für jeden Benutzer müssen jedoch in der Secrets-Datei angegeben werden. Die Passwörter werden mit den Codesphere-Diensten geteilt; in der Regel findet keine direkte Interaktion mit ihnen statt. Verwende eine beliebige Methode, um starke Passwörter zu erzeugen, z. B.

openssl rand -base64 16

Domain-Auth-Schlüssel erzeugen​

Codesphere verfügt über eine Domain-Validierung zur Überprüfung neuer benutzerdefinierter Domains. Dafür werden Secrets aus einem privaten/öffentlichen Schlüsselpaar erzeugt. Diese müssen in der prod.vault.yaml angegeben werden. Nutze folgende Befehle zur Erzeugung:

openssl ecparam -name prime256v1 -genkey -noout -out domain_auth_key.pem
openssl ec -in domain_auth_key.pem -pubout -out domain_auth_public.pem

Secrets-Datei erstellen (prod.vault.yaml)​

Diese Datei speichert alle deine Secrets. Erstelle sie unter einem Pfad wie /home/<myuser>/secrets/prod.vault.yaml. <myuser> kann ein dedizierter Benutzer oder root sein.

# /home/<myuser>/secrets/prod.vault.yaml
secrets:
  # --- Allgemeine Secrets ---
  - name: cephSshPrivateKey
    file:
      # Inhalt von 'ceph_id_rsa', erzeugt in Abschnitt 3.1.1
      name: id_rsa
      content: |
        -----BEGIN OPENSSH PRIVATE KEY----- # Oder passender Typ für deinen Schlüssel
        ...
        -----BEGIN OPENSSH PRIVATE KEY-----
  - name: selfSignedCaKeyPem # Oder deine bestehende CA-Schlüssel, falls für Ingress verwendet
    file:
      name: key.pem
      # Inhalt von 'ca.key' (oder deiner bestehenden CA-Schlüssel) aus Abschnitt 3.1.2
      content: |
        -----BEGIN PRIVATE KEY----- # Oder passender Typ für deinen Schlüssel
        ...
        -----END PRIVATE KEY-----
  - name: domainAuthPrivateKey
    file:
      name: key.pem
      # Inhalt von 'domain_auth_key.pem' aus Abschnitt 3.1.4
      content: |
        -----BEGIN EC PRIVATE KEY-----
        ...
        -----END EC PRIVATE KEY-----
  - name: domainAuthPublicKey
    file:
      name: key.pem
      # Inhalt von 'domain_auth_public.pem' aus Abschnitt 3.1.4
      content: |
        -----BEGIN PUBLIC KEY-----
        ...
        -----END PUBLIC KEY-----

  # (Optional) Falls dein Managed-Service-Backend so provisioniert wurde, dass es
  # Anfragen über einen API_KEY authentifiziert, musst du diesen API_KEY hier setzen
  #- name: managedServiceSecrets
  #  fields:
  #    # JSON-Array von Objekten
  #    password: |-
  #      [
  #          {
  #              "name": "postgres", # Providername
  #              "version": "v1" # Providerversion
  #              "api": {
  #                  "secret": "MY-API-KEY-123123"
  #              }
  #          }
  #      ]

  # --- Zugangsdaten für externe Registry (falls verwendet) ---
  # Optional bei Nutzung eines von Codesphere verwalteten K8s, verpflichtend bei Nutzung eines externen K8s
  - name: registryUsername
    fields:
      password: 'YOUR_REGISTRY_USERNAME'
  - name: registryPassword
    fields:
      password: 'YOUR_REGISTRY_PASSWORD'

  # --- Optional: Bei Installation von PostgreSQL ---
  - name: postgresPassword
    fields:
      # Erzeuge ein starkes primäres Admin-Passwort (z. B. 25 Zeichen)
      password: 'YOUR_POSTGRES_ADMIN_PASSWORD'
  - name: postgresReplicaPassword
    fields:
      # Erzeuge ein starkes Replica-Passwort
      password: 'YOUR_POSTGRES_REPLICA_PASSWORD'
  - name: postgresPrimaryServerKeyPem
    file:
      name: primary.key # Interner Name, muss nicht mit dem Dateinamen übereinstimmen
      # Inhalt von 'pg_primary.key' aus Abschnitt 3.1.3
      content: |
        -----BEGIN RSA PRIVATE KEY-----
        ...
        -----END RSA PRIVATE KEY-----
  - name: postgresReplicaServerKeyPem
    file:
      name: replica.key # Interner Name
      # Inhalt von 'replica.key' aus Abschnitt 3.1.3
      content: |
        -----BEGIN RSA PRIVATE KEY-----
        ...
        -----END RSA PRIVATE KEY-----

  # --- Optional: Bei Nutzung von externem Kubernetes (siehe config.yaml) ---
  - name: kubeConfig
    file:
      name: kubeConfig # Interner Name
      content: |
        apiVersion: v1
        kind: Config
        clusters:
        - cluster:
            certificate-authority-data: ...
            server: https://<your-k8s-api-server>
          name: external-cluster
        contexts:
        - context:
            cluster: external-cluster
            user: external-admin
          name: external-context
        current-context: external-context
        users:
        - name: external-admin
          user:
            client-certificate-data: ...
            client-key-data: ...
        # ... (Rest deines Admin-Kubeconfigs)
  # Postgres-Benutzer & Passwörter für Codesphere
  # Benutzernamen unverändert lassen, einschließlich *_blue
  - name: postgresUserAuth
    fields:
      password: auth_blue
  - name: postgresUserDeployment
    fields:
      password: deployment_blue
  - name: postgresUserIde
    fields:
      password: ide_blue
  - name: postgresUserMarketplace
    fields:
      password: marketplace_blue
  - name: postgresUserPayment
    fields:
      password: payment_blue
  - name: postgresUserPublicApi
    fields:
      password: public_api_blue
  - name: postgresUserTeam
    fields:
      password: team_blue
  - name: postgresUserWorkspace
    fields:
      password: workspace_blue
  - name: postgresPasswordAuth
    fields:
      password:
  - name: postgresPasswordDeployment
    fields:
      password:
  - name: postgresPasswordIde
    fields:
      password:
  - name: postgresPasswordMarketplace
    fields:
      password:
  - name: postgresPasswordPayment
    fields:
      password:
  - name: postgresPasswordPublicApi
    fields:
      password:
  - name: postgresPasswordTeam
    fields:
      password:
  - name: postgresPasswordWorkspace
    fields:
      password:

  # --- Optional: OAuth-Zugangsdaten für Git-Anbieter (in config.yaml aktivieren) ---
  # GitHub
  - name: githubAppsClientId
    fields:
      password: 'YOUR_GITHUB_APP_CLIENT_ID'
  - name: githubAppsClientSecret
    fields:
      password: 'YOUR_GITHUB_APP_CLIENT_SECRET'
  # GitLab
  - name: gitlabAppClientId
    fields:
      password: 'YOUR_GITLAB_APP_CLIENT_ID'
  - name: gitlabAppClientSecret
    fields:
      password: 'YOUR_GITLAB_APP_CLIENT_SECRET'
  # Bitbucket
  - name: bitbucketAppsClientId
    fields:
      password: 'YOUR_BITBUCKET_APP_CLIENT_ID'
  - name: bitbucketAppsClientSecret
    fields:
      password: 'YOUR_BITBUCKET_APP_CLIENT_SECRET'
  # Azure DevOps
  - name: azureDevOpsAppClientId
    fields:
      password: 'YOUR_AZUREDEVOPS_APP_CLIENT_ID'
  - name: azureDevOpsAppClientSecret
    fields:
      password: 'YOUR_AZUREDEVOPS_APP_CLIENT_SECRET'

Fülle die ...-Platzhalter mit deinem tatsächlichen Schlüssel-/Zertifikatsinhalt aus und vergebe starke Passwörter.

Konfigurationsdatei erstellen (config.yaml)​

Diese Datei definiert die Struktur und Einstellungen deiner Codesphere-Installation. Erstelle sie unter einem Pfad wie /home/<myuser>/secrets/config.yaml.

# /home/<myuser>/secrets/config.yaml
dataCenter:
  id: 1
  name: main
  city: Karlsruhe # Die Stadt deines Rechenzentrums
  countryCode: DE # Der Ländercode deines Rechenzentrums
secrets:
  baseDir: /home/<myuser>/secrets/ # Pfad zu deinem Secrets-Verzeichnis (wo prod.vault.yaml liegt)

# Falls eine externe Container-Registry verwendet wird
# Optional bei Nutzung eines von Codesphere verwalteten K8s, verpflichtend bei Nutzung eines externen K8s
registry:
  server: "my-registry.example.com"
  replaceImagesInBom: true # Optional, sollte bei Nutzung einer externen Registry auf true gesetzt werden
  loadContainerImages: true # Optional, auf true setzen, wenn Images aus dem Installer-Bundle geladen werden sollen


# --- PostgreSQL-Konfiguration ---
# Wähle eine Option: "Neues PostgreSQL installieren" ODER "Externes PostgreSQL nutzen"
postgres:
  # Option 1: Neues PostgreSQL installieren (Passwörter & Schlüssel siehe Secrets-Datei)
  # CA-Zertifikat für PostgreSQL (pg_ca.pem aus Abschnitt 3.1.3)
  caCertPem: |
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----
  primary:
    sslConfig:
      # Primäres PostgreSQL-Serverzertifikat (pg_primary.pem aus Abschnitt 3.1.3)
      serverCertPem: |
        -----BEGIN CERTIFICATE-----
        ...
        -----END CERTIFICATE-----
    ip: 10.50.0.2 # Reale IP des primären PostgreSQL-Servers
    hostname: pg-primary-node # Hostname des primären PostgreSQL-Knotens
  replica:
    ip: 10.50.0.3 # Reale IP des Replica-PostgreSQL-Servers
    name: replica1 # kann beliebig sein, PostgreSQL erlaubt jedoch nur [a-z0-9_]
    sslConfig:
      # Replica-PostgreSQL-Serverzertifikat (pg_replica.pem aus Abschnitt 3.1.3)
      serverCertPem: |
        -----BEGIN CERTIFICATE-----
        ...
        -----END CERTIFICATE-----
  # Ende von Option 1

  # Option 2: Externes PostgreSQL nutzen
  # caCertPem: | # CA-Zertifikat deines externen PostgreSQL-Servers (bei Nutzung von SSL)
  #   -----BEGIN CERTIFICATE-----
  #   ...
  #   -----END CERTIFICATE-----
  # serverAddress: "your-external-postgres-host:5432"
  # # Stelle sicher, dass 'postgresPassword' in prod.vault.yaml für den externen DB-Benutzer gesetzt ist
  # Ende von Option 2

# --- Ceph-Konfiguration ---
ceph:
  csiKubeletDir: /var/lib/k0s/kubelet # Optional, setzen falls kein k0s verwendet wird
  cephAdmSshKey:
    # Öffentlicher Schlüsselteil von 'ceph_id_rsa.pub', erzeugt in Abschnitt 3.1.1
    publicKey: >-
      ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC... ceph
  nodesSubnet: 10.50.0.0/25 # Subnetz, in dem sich die Ceph-Knoten befinden
  hosts:
  # Der tatsächliche Hostname der VM (durch Ausführen von 'hostname' überprüfen).
  # Hostnamen müssen nicht auflösbar sein (DNS), werden aber von Ceph geprüft
    - hostname: ceph-node-0
      ipAddress: 10.50.0.2 # Ersetzen mit der realen IP eines Ceph-Knotens
      isMaster: true # Nur ein Master erlaubt
    - hostname: ceph-node-1
      ipAddress: 10.50.0.3 # Ersetzen mit der realen IP eines weiteren Ceph-Knotens
      isMaster: false
    - hostname: ceph-node-2
      ipAddress: 10.50.0.4 # Ersetzen mit der realen IP eines weiteren Ceph-Knotens
      isMaster: false
  # OSD-Konfiguration (Object Storage Daemon). An deine Hardware anpassen.
  # 'dataDevices' darf nicht leer sein. Siehe Ceph-Dokumentation für die Syntax von 'size' und 'limit'.
  osds:
  - specId: default
    placement:
      host_pattern: '*' # Auf alle oben definierten Hosts anwenden
    dataDevices: # Geräte zur Datenspeicherung
      # Beispiel: alle verfügbaren Geräte, oder Angabe nach Größe, Modell etc.
      # all: true
      size: '300G:' # Festplatten mit 300 GB oder größer
      limit: 2      # Bis zu 2 solcher Festplatten pro Host für Daten verwenden
    dbDevices:   # Geräte für interne BlueStore-Metadaten (DB/WAL)
      size: '100G:200G' # Festplatten zwischen 100 GB und 200 GB
      limit: 1          # 1 solche Festplatte pro Host für Metadaten-DB verwenden

# --- Kubernetes-Konfiguration ---
# Wähle eine Option: "Neues Kubernetes installieren" ODER "Externes Kubernetes nutzen"
# kubernetes.managedByCodesphere sollte entsprechend gesetzt werden
kubernetes:
  # Option 1: Neues Kubernetes installieren (mit k0s)
  managedByCodesphere: true
  apiServerHost: 10.50.0.2 # Externe Adresse für die K8s-API (LB, DNS oder Control-Plane-IP)
  controlPlanes:
    - ipAddress: 10.50.0.2 # Reale IP des K8s-Control-Plane-Servers
  workers:
    - ipAddress: 10.50.0.2 # Kann Control-Plane und Worker sein
    - ipAddress: 10.50.0.3 # Reale IP eines K8s-Worker-Servers
    - ipAddress: 10.50.0.4 # Reale IP eines weiteren K8s-Worker-Servers
  # Ende von Option 1

  # Option 2: Externes Kubernetes nutzen
  managedByCodesphere: false
  podCidr: "100.96.0.0/11"    # Pod-Netzwerk-CIDR deines externen Clusters
  serviceCidr: "100.64.0.0/13" # Service-Netzwerk-CIDR deines externen Clusters
  # Stelle sicher, dass 'kubeConfig' für den externen Cluster in prod.vault.yaml gesetzt ist
  # Ende von Option 2

# --- Clusterweite Einstellungen (gilt für installiertes und externes k8s) ---
cluster:
  certificates: # CA für Dienste, auf die Codesphere-Benutzer zugreifen
    ca:
      algorithm: RSA
      keySizeBits: 2048
      # Inhalt von 'ca.pem' (oder deiner Ingress-CA-Zertifikat) aus Abschnitt 3.1.2
      certPem: |
        -----BEGIN CERTIFICATE-----
        ...
        -----END CERTIFICATE-----
  monitoring:
    prometheus:
      # optional, aktivieren, falls externes Monitoring durch Codesphere SRE vereinbart wurde
      remoteWrite:
        enabled: false
        clusterName: my-cluster-name
  gateway: # Für interne Codesphere-Dienste
    serviceType: "LoadBalancer" # oder "ExternalIP"
    # annotations: # Optional: für Cloud-Provider-spezifische LB-Konfiguration
      # Beispiel Azure:
      # service.beta.kubernetes.io/azure-load-balancer-ipv4: <IP>
      # service.beta.kubernetes.io/azure-load-balancer-resource-group: <rg>
    ipAddresses: # Erforderlich, falls serviceType "ExternalIP" ist
      - 10.51.0.2 # Beispiel-IP
      - 10.51.0.3 # Beispiel-IP
  publicGateway: # Für Benutzer-Workspaces
    serviceType: "LoadBalancer" # oder "ExternalIP"
    # annotations: {}
    ipAddresses: # Erforderlich, falls serviceType "ExternalIP" ist
      - 10.52.0.2 # Beispiel-IP
      - 10.52.0.3 # Beispiel-IP
  metallb:
    # Dies ist der Hauptschalter zum Aktivieren oder Deaktivieren der MetalLB-Integration.
    # Auf 'true' setzen, damit MetalLB installiert und konfiguriert wird.
    enabled: true

    # Definiert eine Liste von IP-Adresspools, die MetalLB nutzen kann. Einem Dienst
    # wird eine IP aus einem Pool zugewiesen, der entweder per L2 oder BGP angekündigt wird.
    pools:
      - # Ein eindeutiger Name zur Identifikation dieses IP-Adresspools.
        # Dieser Name wird in den L2- oder BGP-Advertisement-Abschnitten referenziert.
        name: "default-pool"
        # Eine Liste von IP-Adressen, die MetalLB verwalten kann.
        # Diese Bereiche bestimmen, welche IPs für deine LoadBalancer-Dienste verfügbar sind.
        ipAddresses:
          - "10.10.10.100-10.10.10.200"  # Ein IP-Bereich für allgemeine Dienste.
          - "192.168.5.0/24"             # Ein CIDR-Block für weitere Dienste.

      - # Du kannst mehrere Pools für unterschiedliche Zwecke definieren.
        name: "special-services-pool"
        ipAddresses:
          - "172.17.15.1-172.17.15.10" # Ein kleinerer, dedizierter Bereich für bestimmte Dienste.

    # (Optional) Konfiguriert Layer-2-Advertisement. Im L2-Modus kündigt ein Knoten
    # im Cluster die Dienst-IP im lokalen Netzwerk mittels ARP/NDP an.
    l2:
      - # Ein eindeutiger Name für diese L2-Advertisement-Konfiguration.
        name: "default-l2-advertisement"
        # Legt fest, welche IP-Adresspools diese L2-Konfiguration ankündigen soll.
        # Dies verknüpft den L2-Mechanismus mit den im Abschnitt 'pools' definierten IPs.
        pools:
          - "default-pool"
        # (Optional) Beschränkt, welche Knoten die IPs für diese L2-Konfiguration ankündigen dürfen.
        # Falls nicht definiert, sind alle Knoten im Cluster berechtigt.
        nodeSelectors:
          - matchLabels:
              # Dieser Selektor stellt sicher, dass nur Knoten mit dem Label 'role' auf 'frontend'
              # IPs aus dem 'default-pool' via L2 ankündigen.
              'role': 'frontend'

    # (Optional) Konfiguriert BGP-Advertisement (Border Gateway Protocol). Im BGP-Modus
    # peeren Knoten mit deinen Netzwerk-Routern, um Routen für die Dienst-IPs anzukündigen.
    bgp:
      - # Ein eindeutiger Name für diese BGP-Advertisement-Konfiguration.
        name: "main-bgp-advertisement"
        # Legt fest, welche IP-Adresspools diese BGP-Konfiguration ankündigen soll.
        # Hier kündigen wir einen anderen Pool über BGP an.
        pools:
          - "special-services-pool"
        # Details zur BGP-Peering-Konfiguration.
        config:
          # Die Autonomous System Number (ASN) deines Kubernetes-Clusters.
          myASN: 65001
          # Die Autonomous System Number (ASN) des externen BGP-Peers (deines Routers).
          peerASN: 65100
          # Die IP-Adresse des BGP-Peers, mit dem verbunden werden soll.
          peerAddress: "192.168.1.1"
          # (Optional) Der Name eines BFD-Profils für schnelle Fehlererkennung.
          # Dies müsste separat in der nativen MetalLB-Konfiguration eingerichtet werden.
          bfdProfile: "fast-detection"
        # (Optional) Beschränkt, welche Knoten diese BGP-Peering-Sitzung aufbauen dürfen.
        # Nützlich, wenn nur Randknoten mit dem Peering-Router verbunden sind.
        nodeSelectors:
          - matchLabels:
              # Dieser Selektor stellt sicher, dass nur Knoten mit dem Label 'kubernetes.io/hostname'
              # auf 'edge-node-01' mit 192.168.1.1 peeren.
              'kubernetes.io/hostname': 'edge-node-01'

# --- Codesphere-Anwendungskonfiguration ---
codesphere:
  domain: "codesphere.yourcompany.com" # Haupt-Domain für Codesphere UI/API
  workspaceHostingBaseDomain: "ws.yourcompany.com" # Basis-Domain für Workspaces (*.ws.yourcompany.com sollte auf publicGateway-IPs zeigen)
  # Eine primäre öffentliche IP für Workspaces (nutze eine aus publicGateway). Falls von einem LoadBalancer zugewiesen
  # und noch nicht bekannt, leer lassen und später ergänzen, sobald bekannt.
  publicIp: "10.52.0.2"
  customDomains:
    cNameBaseDomain: "custom.yourcompany.com" # Für benutzerdefinierte Domain-CNAMEs
  dnsServers: [] # z. B. ["1.1.1.1", "8.8.8.8"] IP-Adressen von DNS-Servern zur Auflösung benutzerdefinierter Domains
  experiments: [] # Liste der zu aktivierenden Codesphere-Experimentalfeatures
  features: # Map der aktivierten/deaktivierten Codesphere-Features. Siehe [Feature-Flags-Dokumentation](./feature-flags.mdx) für Details.
   standalone-teams: false # Auf false setzen, um eine strikte Organisationshierarchie durchzusetzen
   # email-signup: true
   # email-signin: true
   # billing: false
  extraCaPem: "" # Optional: PEM einer zusätzlichen benutzerdefinierten Root-CA, der Codesphere-Dienste/Workspaces vertrauen sollen
  extraWorkspaceEnvVars: {} # z. B. { "HTTP_PROXY": "[http://proxy.example.com:8080](http://proxy.example.com:8080)" }
  extraWorkspaceFiles: []
    # - path: /etc/custom-certs/my-ca.crt
    #   content: |
    #     -----BEGIN CERTIFICATE-----
    #     ...
    #     -----END CERTIFICATE-----
  # Optional: falls bestimmte metallb-Pools für die Workspace -> IP-Adress-Zuweisung verfügbar sein sollen
  # ipService:
    # loadBalancerKind: metallb
    # addressPools:
    # - "internal-pool"
  # Standard-Workspace-Images überschreiben. Kann nötig sein, wenn eigene Basis-Images verwendet werden
  # workspaceImages:
    # agent: optional
    #   bomRef:
    # agentGpu: optional
    #   bomRef:
    # server: optional
    #   bomRef:
    # vpn: optional
    #   bomRef:
  deployConfig:
    images:
      ubuntu-24.04:
        name: 'Ubuntu 24.04'
        supportedUntil: '2028-05-31'
        # Falls hier mehrere Images angegeben sind: Welches Image soll standardmäßig verwendet werden, wenn der Benutzer keines angibt
        default: true
        flavors:
          default:
            # Für benutzerdefinierte Images den vollständigen Image-Namen inklusive Registry angeben
            # Kein Tag hinzufügen, da der Tag von Codesphere verwaltet wird (siehe Anhang)
            # image: 'registry.corp42.net/codesphere-custom-images/workspace-agent-24.04-mycorp'
            image:
              # Für Standard-Basis-Images: muss einem Workspace-Image in der Installer-BOM entsprechen.
              # Bei Unsicherheit <deps.tar.gz>/bom.json prüfen
              bomRef: 'workspace-agent-24.04'
            pool:
              1: 1 # Anzahl der vorgehaltenen (warmen) Instanzen
  oauth:
    oidc:
      enabled: false
      type: oidc
      name: ""
      issuerUrl: ""
      scopes: ['openid', 'email', 'profile']  # Für Azure AD muss 'https://graph.microsoft.com/User.Read' enthalten sein
  plans: # Verfügbare Workspace- und Hosting-Pläne definieren
    hostingPlans:
      1: # ID muss eine Zahl sein
        cpuTenth: 10       # 1 CPU-Kern (10 Zehntel)
        gpuParts: 0        # GPU-Ressourcen
        memoryMb: 2048     # 2 GB RAM
        storageMb: 20480   # 20 GB persistenter Speicher
        tempStorageMb: 1024 # Temporärer Speicher
    workspacePlans:
      1: # ID muss eine Zahl sein
        name: "Standard Developer" # Anzeigename des Plans
        hostingPlanId: 1        # Verweist auf eine ID aus hostingPlans
        maxReplicas: 3          # Max. gleichzeitige Replikate für einen Workspace
        onDemand: true          # On-Demand-Workspaces erlauben (Start/Stopp)
# Optional, die tatsächlich angeforderten Ressourcen liegen um diesen Faktor unter den im Plan
# definierten, um die Auslastung zu verbessern. Standardwerte belassen, sofern keine besonderen Anforderungen bestehen.
#  underprovisionFactors:
#    cpu: 0.5
#    memory: 0.75
  gitProviders:
    github:
      enabled: false
      url: "https://github.com"
      api:
        baseUrl: "https://api.github.com"
      oauth:
        issuer: "https://github.com"
        authorizationEndpoint: "https://github.com/login/oauth/authorize"
        tokenEndpoint: "https://github.com/login/oauth/access_token"
    gitlab:
      enabled: false
      url: "https://gitlab.com" # Für selbstgehostet: "https://your-gitlab.example.com"
      api:
        baseUrl: "https://gitlab.com" # Für selbstgehostet nur die Basis-URL. "/api/v4" wird automatisch angehängt.
      oauth:
        issuer: "https://gitlab.com"
        authorizationEndpoint: "https://gitlab.com/oauth/authorize"
        tokenEndpoint: "https://gitlab.com/oauth/token"
    bitbucket:
      enabled: false # Bitbucket Server/Data Center
      url: "https://bitbucket.org" # URL deiner Bitbucket-Instanz
      api:
        baseUrl: "https://api.bitbucket.org/2.0" # Für Server: passende API-Basis verwenden
      oauth: # OAuth1 für Bitbucket Server, OAuth2 für Cloud
        issuer: "https://bitbucket.org"
        authorizationEndpoint: "https://bitbucket.org/site/oauth2/authorize"
        tokenEndpoint: "https://bitbucket.org/site/oauth2/access_token"
    azureDevOps:
      enabled: false
      url: "https://dev.azure.com"
      api:
        baseUrl: "https://dev.azure.com"
      oauth:
        issuer: "https://login.microsoftonline.com"
        authorizationEndpoint: "https://login.microsoftonline.com/common/oauth2/v2.0/authorize"
        tokenEndpoint: "https://login.microsoftonline.com/common/oauth2/v2.0/token"
        clientAuthMethod: 'client_secret_post'
        scope: 'openid offline_access https://app.vssps.visualstudio.com/vso.code_full'
  managedServices:
    # Managed Service Provider werden in diesem Abschnitt konfiguriert.
    # Siehe Anhang für detaillierte Konfigurationsoptionen
    # - name: postgres
    #   version: # ...

  # (Optional) Falls mehrere Cluster dieselbe Masterdata-Datenbank nutzen,
  # setze diese Scope-Variable, um Reconciliation-Konflikte zu vermeiden.
  # managedServiceScope: production-cluster-1

  # Managed Services, die ein Landscape-basiertes Backend nutzen, verwenden diese Plan-ID
  # Muss einem der Einträge in codesphere.plans entsprechen
  managedServiceWorkspacePlanId: 1

managedServiceBackends:
  # Falls du Provider unter codesphere.managedServices konfigurierst, musst du auch
  # die entsprechenden Backends in diesem Abschnitt bereitstellen.
  postgres: {
      # Für die Standardkonfiguration leer lassen
  }

Denke daran, die Platzhalterwerte durch deine tatsächliche Konfiguration zu ersetzen. Für detaillierte Informationen zur Konfiguration von plans und gitProviders (einschließlich der Erzeugung von OAuth-Zugangsdaten) siehe die entsprechenden Abschnitte am Ende dieser Anleitung bzw. den ursprünglichen Anhang.

Organisationen: Team-Strenge konfigurieren (standalone-teams)​

Für Private-Cloud-Deployments wird das Feature Organisationen über Konfigurationsflags in deiner config.yaml verwaltet. Administratoren haben die volle Kontrolle darüber, wie strikt Teams an eine Organisation gebunden sein müssen.

Du kannst entscheiden, ob Teams verpflichtend zu einer Organisation gehören müssen. Dieses Verhalten wird über das Feature-Flag standalone-teams unter codesphere.features gesteuert, sodass du organisatorische Governance entweder schrittweise einführen oder strikte Compliance-Regeln je nach internen Anforderungen erzwingen kannst.

Flexibler Modus (Flag auf true gesetzt):​

Wenn du das Feature standalone-teams aktivierst, erlaubt das System einen hybriden Ansatz:

• Benutzer können Teams erstellen, die formal einer Organisation zugeordnet sind.
• Entscheidend ist, dass Benutzer auch unabhängige, „freischwebende“ Teams erstellen dürfen, die keiner Organisation zugeordnet sind.

Strikter Modus (Flag auf false gesetzt oder ausgelassen):​

Wenn das Flag standalone-teams deaktiviert ist, erzwingt die Plattform eine strikte organisatorische Governance:

• Verpflichtende Zuordnung: Jedes neue Team muss innerhalb einer Organisation erstellt werden und ihr zugehören. Es ist nicht möglich, ein unabhängiges Team zu erstellen.
• Mitgliedschaftsprüfung: Ein Benutzer darf nur dann ein Team erstellen, wenn er bereits ein anerkanntes Mitglied der übergeordneten Organisation ist.

SOPS Secret Manager initialisieren (dateibasiert)​

Um zu vermeiden, dass Secrets remote im Klartext gespeichert werden, ist SOPS (Secrets OPerationS) in den Installer-Workflow integriert. Es nutzt Age als dateibasiertes Verschlüsselungswerkzeug.

Das Ziel, die Secrets-Datei (prod.vault.yaml) zu schützen, wird über diesen Workflow erreicht:

1. Stelle sicher, dass in prod.vault.yaml keine Kommentare vorhanden sind. Dies ist notwendig, da SOPS Kommentare nicht ignoriert und diese die Dateistruktur der verschlüsselten Version verändern.
2. Verschlüssele prod.vault.yaml auf deiner lokalen Maschine
3. Speichere nur die verschlüsselte Variante von prod.vault.yaml auf jeder entfernten Maschine
4. Kopiere den Entschlüsselungsschlüssel dort, wo nötig, nur temporär auf die entfernte Maschine
5. Alternativ kannst du SSH-Port-Forwarding nutzen, damit SOPS über HTTP auf den Entschlüsselungsschlüssel zugreifen kann (fortgeschritten, siehe 3.5)

Gehe wie folgt vor:

1. Installiere SOPS und Age auf deiner lokalen Maschine, z. B. unter macOS:

   brew install sops age
   

2. Erzeuge ein Age-Schlüsselpaar (privater + öffentlicher Schlüssel)

   age-keygen -o age_key.txt
   

   Dadurch wird age_key.txt erstellt, die sowohl den privaten als auch den öffentlichen Schlüssel enthält. Merke dir den öffentlichen Schlüssel (beginnt mit age1...). Du benötigst ihn für die Verschlüsselung. Der private Schlüsselteil ist durch AGE-SECRET-KEY-1... gekennzeichnet. Bewahre ihn äußerst sicher auf.
3. Verschlüssele die Secrets-Datei (prod.vault.yaml) lokal mit dem Age-Schlüsselpaar:

   # Öffentlichen Schlüssel abrufen
   age-keygen -y age_key.txt
   sops --encrypt --age <age1....> --in-place /home/<myuser>/secrets/prod.vault.yaml
   

   Dieser Befehl überschreibt die unverschlüsselte prod.vault.yaml direkt.
4. Initialisiere SOPS auf den entfernten Knoten (Multi-Node-Installer: nur auf dem Setup-Knoten erforderlich). Du kannst das Installer-Skript nutzen, um SOPS als Komponente zu installieren. Dazu muss deps.tar.gz zunächst entpackt werden, falls noch nicht erfolgt. Führe dann aus:

   # Falls noch nicht erfolgt
   tar -xvzf <INSTALLER-DIR>/deps.tar.gz -C <INSTALLER-DIR>/deps && cd <INSTALLER-DIR>/
   ./node ./install-components.js \
     --dependenciesDir=./deps \
     --config=/root/secrets/config.yaml \
     --component=sops
   

Um die verschlüsselte prod.vault.yaml-Datei später zu bearbeiten:

export SOPS_AGE_KEY_FILE=/path/to/your/age_key.txt # Zeige auf die Datei mit deinem privaten Schlüssel
sops /home/<myuser>/secrets/prod.vault.yaml

Dadurch wird die entschlüsselte Datei in deinem Standardeditor geöffnet. Speichern und schließen, um sie erneut zu verschlüsseln.

Sicherheitshinweis zum privaten Age-Schlüssel​

• Bewahre die age_key.txt (die den privaten Schlüssel enthält) äußerst sicher und privat auf. Speichere sie nicht dauerhaft auf einem entfernten Knoten.
• Multi-Node-Installer: Das Flag --privKey=/path/to/your/age_key.txt wird genutzt, um dem Haupt-Installationsskript den Schlüssel bereitzustellen.
• Single-Node-Installer / manuelle SOPS-Nutzung auf dem Server: Falls du den Schlüssel unbedingt auf einem Server verwenden musst (z. B. während der Single-Node-Komponenteninstallation), übertrage ihn sicher und entferne ihn sofort nach Gebrauch, oder nutze SSH-Port-Forwarding für temporären Zugriff, falls SOPS entfernte Schlüsseldateien über HTTP unterstützt (fortgeschritten).

Um die Secrets-Datei zu entschlüsseln, verwende:

# export SOPS_AGE_KEY_FILE=/path/to/temporarily/copied/age_key.txt
sops --decrypt /home/<myuser>/secrets/prod.vault.yaml

HTTP-Zugriff auf lokale age_key via SSH-Port-Forwarding​

1. Auf deiner lokalen Maschine (auf der age_key.txt liegt):

cd /path/to/keypair_directory
python3 -m http.server 8000

2. Verbinde dich von deiner lokalen Maschine per SSH mit dem entfernten Server und leite den Port weiter:

ssh -L 9000:localhost:8000 user@remote-host

3. Auf dem entfernten Server:

export SOPS_AGE_KEY_FILE_URL=http://localhost:9000/age_key.txt
sops --decrypt /home/<myuser>/secrets/prod.vault.yaml

Diese HTTP-Methode ist für temporären Zugriff gedacht und sollte mit Vorsicht verwendet werden. Bevorzuge, wenn möglich, die direkte Angabe des Schlüsseldateipfads.

Multi-Node-Installationsanleitung​

Dieser Installer nutzt SSH, um von einer zentralen Setup-Maschine aus Verbindungen zu den verschiedenen Hosts aufzubauen und die Komponenten Schritt für Schritt zu installieren.

Voraussetzungen (Zusammenfassung & Besonderheiten)​

• Alle globalen Voraussetzungen (Abschnitt 2) sind erfüllt.
• Installer-Maschine: OpenSSH-Client, scp, Node.js v22 (mit dem Installer geliefert).
• Ziel-Knoten: iptables, vi/nano, curl.
• SSH-Zugriff: root-Zugriff von der Installer-Maschine auf alle Ziel-Knoten.
• Abhängigkeiten: Das Skript private-cloud-installer.js und das Archiv deps.tar.gz liegen auf der Installer-Maschine.
• Konfiguration: config.yaml und die verschlüsselte prod.vault.yaml sind vorbereitet (Abschnitt 3, siehe auch unten).
• Privater Age-Schlüssel: Die Datei age_key.txt ist von der Installer-Maschine aus zugänglich.

Optionen zur Image-Verteilung​

Der Multi-Node-Installer bietet zwei unterschiedliche Optionen, um alle benötigten Container-Images an alle Ziel-Knoten zu verteilen.

Bei Nutzung einer externen Container-Registry lädt der Installer alle Images aus dem Archiv deps.tar.gz und pusht sie vom Verwaltungsknoten aus in die Registry. Dafür müssen registry.server in config.yaml sowie registryUsername und registryPassword in prod.vault.yaml korrekt gesetzt sein. Die angegebene Registry muss für alle Knoten erreichbar sein.

Wird keine Registry angegeben, werden die Images direkt auf dem Knoten aus deps.tar.gz geladen.

Synchronisation von Konfigurationsdateien und Secrets​

Der Multi-Node-Installer stellt sicher, dass die config.yaml, die verschlüsselte prod.vault.yaml und die zur Entschlüsselung benötigte age_key.txt mit allen Ziel-Knoten synchronisiert werden. Auf den Ziel-Knoten liegen sie unter /etc/codesphere/. Der Multi-Node-Installer ändert automatisch den Wert von secrets.baseDir in config.yaml, bevor die Dateien auf die Ziel-Knoten hochgeladen werden.

Vorinstallationsschritte auf den Ziel-Knoten​

Inotify-Watcher-Limits konfigurieren​

Siehe Globale Einrichtung – Abschnitt 2.5. Stelle sicher, dass dies auf allen Kubernetes-Knoten erfolgt.

Festplatten für Ceph vorbereiten​

Stelle sicher, dass die für Ceph-OSDs vorgesehenen Festplatten (Daten und Metadaten-DB) vollständig leer sind. Vorsicht: Dieser Befehl löscht die Daten auf der Festplatte sdx. Prüfe die Festplattenkennung sorgfältig. Für jede Ceph-Daten-/DB-Festplatte auf jedem Ceph-Knoten:

sudo dd if=/dev/zero of=/dev/sdx bs=1M count=100 conv=fsync # sdx ist deine Zielfestplatte, z. B. sdb, sdc
sudo wipefs -a /dev/sdx

Nach dem Bereinigen der Festplatten kann ein Neustart erforderlich sein, damit die Änderungen vom Betriebssystem vollständig erkannt werden.

sudo reboot

Synchronisierte Uhrzeiten​

Stelle sicher, dass die Uhrzeit auf allen Servern synchronisiert ist. Verwende NTP (Network Time Protocol).

sudo apt update
sudo apt install chrony -y
sudo systemctl enable chrony --now
sudo chronyc sources

Überprüfe, dass alle Knoten mit einer zuverlässigen Zeitquelle synchronisiert sind.

Installation durchführen​

Führe das Haupt-Installationsskript von deiner zentralen Setup-Maschine aus. Dieser Befehl installiert alle in deiner config.yaml definierten Komponenten.

node ./private-cloud-installer.js \
  --archive=./deps.tar.gz \
  --config=/home/<myuser>/secrets/config.yaml \
  --privKey=/path/to/your/age_key.txt

Der Installer arbeitet die Komponenten der Reihe nach ab: Docker, Postgres (falls konfiguriert), Ceph, Kubernetes (k0s), SetUpCluster und schließlich Codesphere.

Nach der Installation und Fehlerbehebung​

Besonderheiten bei Ceph​

• Bekanntes Problem: Manchmal initialisiert sich Ceph so, dass nur ein Monitor-Daemon vollständig gesund wird, was zu einer nicht-HA-fähigen (aber funktionalen) Monitor-Konfiguration führt. Der Installer versucht, mehrere zu konfigurieren.

• Fehlerbehebung bei Ceph: Bei Problemen mit Ceph kannst du dich in den Ceph-Admin-Container auf dem Ceph-Master-Knoten einloggen:

# Auf dem Ceph-Master-Knoten (wie in deiner config.yaml definiert)
sudo ./ceph/files/cephadm --image quay.io/ceph/ceph:v18.2 --docker \
shell ceph status

Wenn der Status nach manuellen Prüfungen oder Korrekturen gesund wird, kannst du möglicherweise den Installer neu starten, oder er setzt an der Stelle fort, an der er aufgehört hat (das Verhalten hängt von der Idempotenz des Installers für Ceph ab).

• Debugging des Ceph-Managers (mgr):

# Auf einem Ceph-Knoten, der einen Manager ausführt
systemctl list-units | grep ceph.*mgr
# Beispiel: [email protected]
sudo systemctl restart <ceph-mgr-service-name>
sudo journalctl -u <ceph-mgr-service-name> -r # -r für umgekehrte chronologische Reihenfolge (neueste zuerst)

• Debugging von Ceph-OSDs (osd): Liste laufende Docker-Container auf, um OSDs zu sehen:

# Auf einem Ceph-OSD-Knoten
sudo docker ps | grep ceph-osd

• Logs für einen bestimmten OSD-Container prüfen:

sudo docker logs <container_id_or_name_of_osd>

Bestimmte Installationsschritte überspringen​

In bestimmten Fällen, z. B. beim Beheben eines Fehlers in der config.yaml oder beim Ändern eines Secrets, können einige zeitintensive Installationsschritte übersprungen werden. Eine Liste aller unterstützten überspringbaren Schritte erhältst du mit:

./node ./private-cloud-installer.js -h

Ein oder mehrere zu überspringende Schritte können über das Flag --skipStep von prviate-cloud-installer.js gesetzt werden, zum Beispiel:

node ./private-cloud-installer.js \
  --archive=./deps.tar.gz \
  --config=/home/<myuser>/secrets/config.yaml \
  --privKey=/path/to/your/age_key.txt \
  --skipStep=copy-dependencies \
  --skipStep=extract-dependencies

Single-Node-Installationsanleitung​

Bei dieser Methode werden Installationsbefehle für jede Komponente manuell auf dem jeweiligen Ziel-Host ausgeführt. Du musst die Abhängigkeiten und Konfigurationsdateien auf jeden Host kopieren.

Voraussetzungen (Zusammenfassung & Besonderheiten)​

• Alle globalen Voraussetzungen (Abschnitt 2) sind erfüllt.
• Auf jedem Ziel-Knoten: iptables, vi/nano, curl. Das Skript install-components.js (aus deps.tar.gz) wird verwendet.
• SSH-Zugriff: Du verbindest dich per SSH mit jedem Knoten, um Befehle auszuführen. Für Befehle ist in der Regel root oder sudo erforderlich.
• Abhängigkeiten: deps.tar.gz muss auf jeden Host hochgeladen und entpackt werden.
• Konfiguration: config.yaml und die verschlüsselte prod.vault.yaml müssen auf jedem Host verfügbar sein, auf dem install-components.js ausgeführt wird.
• Privater Age-Schlüssel: age_key.txt muss zugänglich sein, wenn Befehle ausgeführt werden, die eine Secret-Entschlüsselung erfordern (z. B. für die meisten Schritte auf dem Control-Plane-Knoten).

Umgebung auf jedem Host einrichten​

1. Abhängigkeiten hochladen und entpacken: Für jeden Host (PostgreSQL-, Ceph-, Kubernetes-Knoten):

# Von deiner Verwaltungsmaschine
scp deps.tar.gz <user>@<host_ip>:./deps.tar.gz

# Per SSH mit dem Host verbinden
ssh <user>@<host_ip>
sudo mkdir /opt/codesphere_deps
sudo tar xf deps.tar.gz -C /opt/codesphere_deps
cd /opt/codesphere_deps

2. (Stelle sicher, dass sich install-components.js unter ./installer/files/ innerhalb des entpackten Verzeichnisses befindet)

3. Konfigurationsdateien hochladen: Lade config.yaml und die verschlüsselte prod.vault.yaml (erstellt in Abschnitt 3) auf jeden Host hoch, typischerweise in ein Verzeichnis wie /home/<user>/secrets/ oder /root/secrets/. Stelle auch age_key.txt sicher zur Verfügung, falls zur Entschlüsselung auf diesem Host benötigt.

# Von deiner Verwaltungsmaschine
scp /path/to/config.yaml <user>@<host_ip>:/root/secrets/config.yaml
scp /path/to/prod.vault.yaml <user>@<host_ip>:/root/secrets/prod.vault.yaml
# Falls direkter Schlüsselzugriff auf dem Host benötigt wird (mit Vorsicht verwenden):
# scp /path/to/age_key.txt <user>@<host_ip>:/root/secrets/age_key.txt

4. Passe Pfade in config.yaml (secrets.baseDir) entsprechend an, falls nicht /root/secrets verwendet wird.

5. Inotify-Watcher-Limits konfigurieren: (Beschrieben in Globale Einrichtung – Abschnitt 2.5. Stelle sicher, dass dies auf allen Kubernetes-Knoten erfolgt.)

Schrittweise Komponenteninstallation​

Alle nachfolgenden Befehle sollten im Allgemeinen als root oder mit sudo ausgeführt werden. Navigiere zu dem Verzeichnis, in das du die Abhängigkeiten entpackt hast (z. B. /opt/codesphere_deps). Der Pfad --privKey sollte auf deine age_key.txt verweisen.

Container-Engine einrichten (Docker)​

Führe dies auf jedem Host aus (Ceph, Kubernetes, jeder Knoten, der Container für Codesphere-Komponenten ausführt, falls nicht alles über K8s läuft). Das Dateisystem unter /var/lib/docker (oder das Äquivalent für deine Container-Engine) sollte mindestens 100–200 GB freien Speicher haben.

sudo ./installer/files/node ./installer/files/install-components.js \
  --dependenciesDir=. \
  --config=/root/secrets/config.yaml \
  --component=docker

# Benötigte Images in den lokalen Docker-Cache laden (hauptsächlich auf K8s-Knoten)
sudo ./installer/files/node ./installer/files/install-components.js \
  --dependenciesDir=. \
  --config=/root/secrets/config.yaml \
  --privKey=/root/secrets/age_key.txt \
  --component=loadContainerImages

Prüfen: sudo docker info und sudo docker image ls.

PostgreSQL installieren (falls kein externes verwendet wird)​

A. Primären PostgreSQL-Knoten installieren: Verbinde dich per SSH mit dem in deiner config.yaml festgelegten primären PostgreSQL-Server.

sudo ./installer/files/node ./installer/files/install-components.js \
  --dependenciesDir=. \
  --config=/root/secrets/config.yaml \
  --privKey=/root/secrets/age_key.txt \
  --component=postgresPrimary

Prüfen: sudo systemctl status codesphere-postgres.service

B. Replica-PostgreSQL-Knoten installieren: Verbinde dich per SSH mit dem/den festgelegten Replica-PostgreSQL-Server(n).

sudo ./installer/files/node ./installer/files/install-components.js \
  --dependenciesDir=. \
  --config=/root/secrets/config.yaml \
  --privKey=/root/secrets/age_key.txt \
  --component=postgresReplica

Prüfen: sudo systemctl status codesphere-postgres.service

Ceph installieren​

A. Knoten vorbereiten (Bereinigung & Synchronisation):​

• Festplatten bereinigen: (Abschnitt 4.3.2) Stelle auf jedem Ceph-Knoten sicher, dass die für OSDs vorgesehenen Festplatten komplett gelöscht sind.
• Synchronisierte Uhrzeiten: (Abschnitt 4.3.3) Stelle sicher, dass die Uhrzeit auf allen Ceph-Knoten synchronisiert ist.

B. Ceph installieren: Führe den Befehl zuerst auf allen Nicht-Master-Ceph-Knoten aus, und danach abschließend auf dem Ceph-Master-Knoten (wie in config.yaml definiert).

sudo ./installer/files/node ./installer/files/install-components.js \
  --dependenciesDir=. \
  --config=/root/secrets/config.yaml \
  --privKey=/root/secrets/age_key.txt \
  --component=ceph

Fehlerbehebung: Siehe Abschnitt 4.5.1 für Befehle zur Ceph-Fehlerbehebung.

Kubernetes installieren (k0s)​

A. Control-Plane-Knoten installieren: Verbinde dich per SSH mit dem/den festgelegten Kubernetes-Control-Plane-Knoten.

sudo ./installer/files/node ./installer/files/install-components.js \
  --dependenciesDir=. \
  --config=/root/secrets/config.yaml \
  --privKey=/root/secrets/age_key.txt \
  --component=kubernetes # Dies installiert die k0s-Control-Plane

Nachdem die erste Control-Plane läuft, beziehe ein Bootstrap-Token für Worker-Knoten:

sudo ./kubernetes/files/k0s token create --role=worker > /tmp/k0s_worker_token.txt

Kopiere diese Datei /tmp/k0s_worker_token.txt sicher auf alle geplanten Worker-Knoten.

B. Worker-Knoten installieren: Verbinde dich per SSH mit jedem festgelegten Kubernetes-Worker-Knoten. Dieser Schritt ist nicht erforderlich, wenn ein Knoten sowohl Control-Plane als auch Worker ist (Single-Node-K8s-Setup oder kombinierte Rollen).

# Stelle sicher, dass /tmp/k0s_worker_token.txt auf dem Worker-Knoten vorhanden ist
export K0S_TOKEN_FILE=/tmp/k0s_worker_token.txt # k0s erwartet diese Umgebungsvariable
sudo ./installer/files/node ./installer/files/install-components.js \
  --dependenciesDir=. \
  --config=/root/secrets/config.yaml \
  --privKey=/root/secrets/age_key.txt \
  --component=kubernetes # Dies installiert den k0s-Worker

Warte, bis alle Worker-Knoten bereit sind. Prüfe von einem Control-Plane-Knoten aus:

sudo ./kubernetes/files/k0s kubectl get nodes -o wide

Hinweis: Control-Plane-Knoten werden in kubectl get nodes möglicherweise nicht als „Knoten“ angezeigt, wenn sie nicht auch als Worker markiert (getainted) sind oder ausschließlich als Master fungieren.

Initiale Kubernetes-Ressourcen erstellen​

Führe diese Befehle auf einem Kubernetes-Control-Plane-Knoten aus:

1. Codesphere-Namespace erstellen:

sudo ./kubernetes/files/k0s kubectl create ns codesphere

3. Dummy-Fehlerseiten-Server erstellen (temporär): Dies ist ein Platzhalter, den setUpCluster benötigt, falls bestimmte Dienste noch nicht laufen.

sudo ./kubernetes/files/k0s kubectl -n codesphere create svc clusterip error-page-server --tcp=8080:8080

Grundlegende Komponenten installieren (setUpCluster)​

Führe dies auf einem Kubernetes-Control-Plane-Knoten aus:

sudo ./installer/files/node ./installer/files/install-components.js \
  --dependenciesDir=. \
  --config=/root/secrets/config.yaml \
  --privKey=/root/secrets/age_key.txt \
  --component=setUpCluster

Codesphere installieren​

A. Docker-Images aktualisieren (Optional – für Upgrades oder um die neuesten sicherzustellen): Falls du ein Update durchführst oder sicherstellen möchtest, dass die aktuellsten Images (gemäß deps.tar.gz) verwendet werden:

1. Images in den Docker-Cache auf K8s-Knoten laden: Auf jedem Kubernetes-Knoten (Control-Plane und Worker) ausführen:

sudo ./installer/files/node ./installer/files/install-components.js \
  --dependenciesDir=. \
  --config=/root/secrets/config.yaml \
  --privKey=/root/secrets/age_key.txt \
  --component=loadContainerImages

3. Neue Images für k0s verfügbar machen (falls k0s verwendet wird): Auf jedem Kubernetes-Knoten ausführen. Dies setzt Knoten vorübergehend auf „NotReady“.

sudo ./installer/files/node ./installer/files/install-components.js \
  --dependenciesDir=. \
  --config=/root/secrets/config.yaml \
  --privKey=/root/secrets/age_key.txt \
  --component=reloadKubernetesImages

4. Warte, bis alle Knoten wieder „Ready“ sind (ca. 5 Minuten). Prüfen mit: sudo ./kubernetes/files/k0s kubectl get nodes -o wide

B. Abschließende Installation: Führe dies auf einem Kubernetes-Control-Plane-Knoten aus:

1. Dummy-Fehlerseiten-Server löschen:

sudo ./kubernetes/files/k0s kubectl -n codesphere delete svc error-page-server

3. Codesphere-Anwendung installieren:

sudo ./installer/files/node ./installer/files/install-components.js \
  --dependenciesDir=. \
  --config=/root/secrets/config.yaml \
  --privKey=/root/secrets/age_key.txt \
  --component=codesphere

4. Deine Codesphere-Installation sollte nun abgeschlossen sein. Greife über die in codesphere.domain in deiner config.yaml angegebene Domain darauf zu.

Anhang​

Konfiguration der Codesphere-Pläne​

Pläne definieren die für Entwickler-Workspaces verfügbaren Ressourcen. Konfiguriere dies im Abschnitt codesphere.plans deiner config.yaml.

• hostingPlans: Definiert die rohen Ressourcenzuweisungen. IDs müssen Zahlen sein.
  • cpuTenth: CPU-Kerne in Zehnteln (z. B. 10 = 1 Kern, 25 = 2,5 Kerne).
  • gpuParts: GPU-Zuweisung (spezifisch für dein GPU-Setup).
  • memoryMb: Speicher in Megabyte.
  • storageMb: Persistenter Speicher für den Workspace in Megabyte.
  • tempStorageMb: Temporärer Speicher in Megabyte.
  • pooledInstances: Anzahl der vorgewärmten Instanzen dieses Plans, die bereitgehalten werden sollen.
• workspacePlans: Definiert vom Benutzer auswählbare Pläne, die auf hostingPlans verweisen. IDs müssen Zahlen sein.
  • name: Anzeigename des Plans.
  • hostingPlanId: Verweist auf eine ID in hostingPlans.
  • maxReplicas: Maximale Anzahl gleichzeitiger Instanzen für einen einzelnen Workspace mit diesem Plan.
  • onDemand: true, wenn Benutzer diese Workspaces starten/stoppen können, false für dauerhaft aktiv.

Beispiel: (bereits im Hauptbeispiel config.yaml enthalten)

codesphere:
  # ... weitere Codesphere-Einstellungen ...
  plans:
    hostingPlans:
      1:
        cpuTenth: 10
        gpuParts: 0
        memoryMb: 2048
        storageMb: 20480
        tempStorageMb: 1024
      2:
        cpuTenth: 20
        memoryMb: 4096
        storageMb: 51200
        tempStorageMb: 2048
    workspacePlans:
      1:
        name: "Basic"
        hostingPlanId: 1
        maxReplicas: 1
        onDemand: true
      2:
        name: "Pro"
        hostingPlanId: 2
        maxReplicas: 3
        onDemand: true

Konfiguration der Git-Anbieter​

Konfiguriere Git-Anbieter-Integrationen unter codesphere.gitProviders in config.yaml. Für jeden aktivierten Anbieter musst du außerdem die entsprechenden clientId- und clientSecret-Werte in deiner prod.vault.yaml-Secrets-Datei ergänzen (siehe Abschnitt 3.2).

Allgemeine Struktur für jeden Anbieter:

# providerName z. B. github, gitlab
# providerName:
#   enabled: true # oder false
#   url: "Basis-URL des Anbieters"
#   api:
#     baseUrl: "API-Basis-URL"
#   oauth:
#     issuer: "OAuth-Issuer-URL"
#     authorizationEndpoint: "OAuth-Autorisierungs-URL"
#     tokenEndpoint: "OAuth-Token-URL"
#     # Weitere anbieterspezifische OAuth-Einstellungen wie scope, clientAuthMethod

Zugangsdaten erzeugen (Beispiele):​

• GitLab:

  1. Gehe zu deiner GitLab-Gruppe (oder zu den Benutzereinstellungen für eine benutzerbezogene App) > Settings > Applications.
  2. Erstelle eine neue Anwendung (z. B. „Codesphere Git Integration“).
  3. Redirect URI / Callback URL: https://<codesphere.domain>/ide/auth/gitlab/callback (ersetze <codesphere.domain> durch deine Codesphere-Domain).
  4. Scopes: Wähle api, read_repository, write_repository. (Stelle sicher, dass auch openid, profile, email verfügbar/ausgewählt sind, falls für Benutzerprofilinformationen benötigt).
  5. Speichere die Anwendung. Du erhältst eine „Application ID“ (gitlabAppClientId) und ein „Secret“ (gitlabAppClientSecret).

• GitHub:

  1. Gehe zu deinen GitHub-Organisationseinstellungen > Developer settings > GitHub Apps > New GitHub App.
  2. Application name: z. B. „Codesphere Git Integration“
  3. Homepage URL: https://<your-codesphere.domain>
  4. Authorization callback URL: https://<your-codesphere.domain>/ide/auth/github/callback
  5. Du erhältst eine „Client ID“ (githubAppsClientId) und generierst ein „Client Secret“ (githubAppsClientSecret).
  6. Optional kannst du ein Bild als Logo hochladen.

• Bitbucket (Server/Data Center – üblicherweise Application Links für OAuth 1.0a oder OAuth 2.0, falls unterstützt):

  1. Admin Settings > System > Application Links.
  2. Erstelle einen neuen Link. Wähle „External Application“, „Incoming“.
  3. Redirect URL: https://<codesphere.domain>/ide/auth/bitbucket/callback
  4. Berechtigungen: Lese-/Schreibzugriff auf Repositorys.
  5. Du erhältst einen „Consumer Key“ (bitbucketAppsClientId) und ein „Consumer Secret“ (bitbucketAppsClientSecret) oder Ähnliches, abhängig von der OAuth-Version.

• Azure DevOps:

  1. Registriere eine Anwendung in Azure Active Directory.
  2. Redirect URI: https://<codesphere.domain>/ide/auth/azureDevOps/callback (stelle sicher, dass sie als Web-Redirect-URI hinzugefügt wird).
  3. Notiere die „Application (client) ID“ (azureDevOpsAppClientId).
  4. Gehe zu „Certificates & secrets“ -> „New client secret“, um azureDevOpsAppClientSecret zu erzeugen. Setze dir eine Erinnerung, dieses Secret zu rotieren, da es ein Ablaufdatum hat.
  5. API-Berechtigungen: Füge Berechtigungen für „Azure DevOps“ -> user_impersonation hinzu und stelle sicher, dass vso.code_full im Scope in config.yaml enthalten ist.

Denke daran, diese Client-IDs und Secrets in deine prod.vault.yaml-Datei einzutragen und sie zu verschlüsseln. Beispiel für Secret-Namen:

• githubAppsClientId, githubAppsClientSecret
• gitlabAppClientId, gitlabAppClientSecret
• bitbucketAppsClientId, bitbucketAppsClientSecret
• azureDevOpsAppClientId, azureDevOpsAppClientSecret

Konfiguration von Managed Services​

Jeder Dienst, der über den Bereich Managed Services angeboten wird, wird als einzelner Managed Service Provider im Array codesphere.managedServices in config.yaml konfiguriert. Die Konfiguration folgt einem spezifischen Schema.

Managed Service Provider können extern zu Codesphere sein, d. h. es wird eine externe API aufgerufen, es gibt aber auch eingebaute Managed Services, bei denen der Provider innerhalb von Codesphere läuft. In der aktuellen Version gibt es einen solchen Provider für PostgreSQL.

Codesphere kommt mit einer Reihe vorkonfigurierter Provider. Möchtest du einen dieser Provider aktivieren, gib einfach Name und Version an:

  managedServices:
    - name: postgres
      version: v1
    - name: babelfish
      version: v1
    - name: s3
      version: v1
    - name: virtualK8sV1
      version: v1

Wenn du einen dieser Provider nutzt, stelle bitte sicher, dass du auch das entsprechende Backend im Abschnitt managedServiceBackends aktivierst.

Es ist möglich, Eigenschaften der vorkonfigurierten Provider zu überschreiben oder sogar eigene Provider zu implementieren und hinzuzufügen (siehe Ein eigenes REST-Backend erstellen). Der folgende Ausschnitt zeigt eine beispielhafte vollständige Konfiguration des Postgres-Managed-Service-Providers.

  managedServices:
    - name: postgres
      version: v1
      backend:
        api:
          endpoint: "http://ms-backend-postgres.postgres-operator:3000/api/v1/postgres"
      author: Codesphere
      category: Database
      displayName: PostgreSQL
      iconUrl: /ide/assets/managed-services/postgresql.svg
      configSchema:
        type: object
        properties:
          version:
            type: string
            description: Version der Postgres-DB. Enthält vorinstallierte, mit dieser Version kompatible Erweiterungen. Erweiterungsversionen werden verwaltet und können nicht angepasst werden.
            enum:
              - '17.6'
              - '16.10'
            default: '17.6'
            readOnly: false
          userName:
            type: string
            default: app
            pattern: '^(?!postgres$)'
          databaseName:
            type: string
            default: app
        required: []
        additionalProperties: false
      detailsSchema:
        type: object
        properties:
          port:
            type: integer
          hostname:
            type: string
          dsn:
            type: string
          ready:
            type: boolean
        required:
          - port
          - hostname
          - dsn
          - ready
        additionalProperties: false
      secretsSchema:
        type: object
        properties:
          userPassword:
            type: string
            format: password
          superuserPassword:
            type: string
            format: password
        required:
          - userPassword
          - superuserPassword
        additionalProperties: false
      description: >-
        Open-Source-Datenbanksystem für effizientes Datenmanagement und
        Skalierbarkeit. In Codesphere über den CNPG-K8s-Operator bereitgestellt.
      plans:
        - id: 0
          description: 0.5 vCPU / 500 MB Speicher
          name: Small
          parameters:
            storage:
              pricedAs: storage-mb
              schema:
                description: Speicher (MB)
                type: integer
                default: 10000
                readOnly: false
            cpu:
              pricedAs: cpu-tenths
              schema:
                description: CPU-Zehntel
                type: number
                default: 5
                readOnly: true
            memory:
              pricedAs: ram-mb
              schema:
                description: Speicher (MB)
                type: integer
                default: 500
                readOnly: true
        - id: 1
          description: 1 vCPU / 1 GB Speicher
          name: Medium
          parameters:
            storage:
              pricedAs: storage-mb
              schema:
                description: Speicher (MB)
                type: integer
                default: 25000
                readOnly: false
            cpu:
              pricedAs: cpu-tenths
              schema:
                description: CPU-Zehntel
                type: number
                default: 10
                readOnly: true
            memory:
              pricedAs: ram-mb
              schema:
                description: Speicher (MB)
                type: integer
                default: 1000
                readOnly: true
        - id: 2
          description: 1 vCPU / 2 GB Speicher
          name: Medium High-Mem
          parameters:
            storage:
              pricedAs: storage-mb
              schema:
                type: integer
                default: 25000
                readOnly: false
            cpu:
              pricedAs: cpu-tenths
              schema:
                type: number
                default: 10
                readOnly: true
            memory:
              pricedAs: ram-mb
              schema:
                type: integer
                default: 2000
                readOnly: true
        - id: 3
          description: 2 vCPU / 4 GB Speicher
          name: Large
          parameters:
            storage:
              pricedAs: storage-mb
              schema:
                type: integer
                default: 50000
                readOnly: false
            cpu:
              pricedAs: cpu-tenths
              schema:
                type: number
                default: 20
                readOnly: true
            memory:
              pricedAs: ram-mb
              schema:
                type: integer
                default: 4000
                readOnly: true
        - id: 4
          description: 4 vCPU / 8 GB Speicher
          name: Extra Large
          parameters:
            storage:
              pricedAs: storage-mb
              schema:
                type: integer
                default: 150000
                readOnly: false
            cpu:
              pricedAs: cpu-tenths
              schema:
                type: number
                default: 40
                readOnly: true
            memory:
              pricedAs: ram-mb
              schema:
                type: integer
                default: 8000
                readOnly: true

Eigene Workspace-Basis-Images erstellen​

Das Standard-Basis-Image für Workspaces bringt bereits viele nützliche Tools und Bibliotheken mit. Du kannst jedoch auch eigene, benutzerdefinierte Basis-Images erstellen. Ein Grund, Basis-Images anzupassen, sind Pakete, die nicht über Nix verfügbar sind, aber über apt installiert werden müssen.

Die Codesphere OMS CLI bietet eine bequeme Möglichkeit, mit dem Erstellen eigener, benutzerdefinierter Basis-Images zu beginnen.

Voraussetzungen:

1. Installiere auf deinem Host Docker und das Buildx-Plugin (falls noch nicht installiert):
   sudo apt install docker.io docker-buildx
2. Installiere die OMS CLI wie unter https://github.com/codesphere-cloud/oms beschrieben
3. Nutze den Befehl extend baseimage in der OMS CLI, siehe
   oms-cli beta extend baseimage -h
4. Dieser Befehl extrahiert das Standard-Basis-Image aus dem Codesphere-Installer-Bundle, lädt es in deinen lokalen Docker-Image-Cache und erzeugt ein Dockerfile, das du erweitern kannst.
5. Bestätige mit docker image ls, dass das Basis-Image (ghcr.io/codesphere-cloud/codesphere-monorepo/workspace-agent-VERSION) lokal verfügbar ist.
6. Bearbeite das erzeugte Dockerfile, um deine benutzerdefinierten Abhängigkeiten hinzuzufügen.
7. Als Best Practice solltest du das Dockerfile in ein Unterverzeichnis legen, z. B. ./docker. Dadurch wird sichergestellt, dass beim folgenden Docker-Build-Befehl nur die notwendigen Dateien an den Docker-Daemon gesendet werden.
8. Ermittle den Basis-Image-Tag aus dem Dockerfile, z. B. codesphere-1-67-1-4dd9b346cc, und verwende denselben Tag für dein benutzerdefiniertes Image.
9. Baue das benutzerdefinierte Image mit folgendem Befehl:
   docker buildx build -f ./docker/custom.Dockerfile -t workspace-agent-24.04-mycorp:<TAG_TO_USE> --load ./docker
10. Taggen und pushe das Image mit demselben Tag wie das Original-Image in deine eigene Registry:
    docker tag workspace-agent-24.04-mycorp:<TAG_TO_USE> <YOUR_REGISTRY_URL>/workspace-agent-24.04-mycorp:<TAG_TO_USE>
docker login <YOUR_REGISTRY_URL> # falls noch nicht eingeloggt
docker push <YOUR_REGISTRY_URL>/workspace-agent-24.04-mycorp:<TAG_TO_USE>