Zum Hauptinhalt springen
Version: Weekly Build

Private Cloud Installer Config Referenz

config.yaml wird von oms init install-config erzeugt (siehe Jumpbox vorbereiten und Konfiguration generieren) und von oms install codesphere verwendet. Sie besitzt zwölf Top-Level-Keys.

dataCenter​

Identifiziert diese Installation.

dataCenter:
id: 1
name: dev
city: Karlsruhe
countryCode: DE

Eine Installation, die sich über mehrere Rechenzentren erstreckt, hat eine Konfiguration pro Rechenzentrum und zwei weitere Top-Level-Keys, dataCenters und defaultDataCenterId — siehe Mehrere Rechenzentren: Konfiguration.

secrets​

secrets:
baseDir: /etc/codesphere/secrets

baseDir ist das Verzeichnis, das den Vault enthält (prod.vault.yaml). Es sollte mit dem Verzeichnis übereinstimmen, das beim Ausführen von oms install codesphere an --vault übergeben wird.

registry​

registry:
server: ghcr.io
replaceImagesInBom: false
loadContainerImages: false

server ist die Container-Registry, von der Nodes Images beziehen. loadContainerImages lädt Image-Tarballs, die im (veralteten) vollständigen Installer-Paket enthalten sind, statt sie von server abzurufen; lasse dies bei Verwendung des Lite-Pakets auf false. Siehe Den Installer ausführen.

postgres​

postgres:
mode: install # or external
primary:
ip: 10.10.0.20
hostname: postgres-1

mode: install lässt den Installer PostgreSQL auf einem selbst bereitgestellten Host über primary (und optional replica) verwalten. mode: external erfordert stattdessen serverAddress, das auf eine selbst betriebene Datenbank verweist; serverAddress muss leer sein, wenn mode: install gesetzt ist. Bei mode: external muss der Superuser der Datenbank postgres heißen — dies ist nicht konfigurierbar — und die Verbindung erfolgt immer über TLS, daher muss das von der Datenbank präsentierte Zertifikat vertrauenswürdig sein (bei einem Managed-Database-Dienst wie AWS RDS bedeutet dies, das tatsächliche CA-Bundle dieses Dienstes zu verwenden).

ceph​

ceph:
csiKubeletDir: /var/lib/k0s/kubelet # /var/lib/kubelet for most non-k0s clusters
nodesSubnet: 10.10.0.0/20
hosts:
- hostname: ceph-1
ipAddress: 10.10.0.31
isMaster: true
osds:
- specId: default
dataDevices:
size: "240G:300G"
dbDevices:
size: "120G:150G"

hosts muss mindestens einen Ceph-Host auflisten, von denen genau einer der Master ist. csiKubeletDir muss mit dem Kubelet-Verzeichnis der verwendeten Kubernetes-Distribution übereinstimmen — siehe Einen bestehenden Kubernetes-Cluster verwenden. osds[].dataDevices/dbDevices wählen Festplatten anhand eines Größenbereichs aus; um anzugeben, "es gibt keine separate DB/WAL-Platte", setze einen Größenbereich, der auf keine der Festplatten des Nodes passt.

kubernetes​

kubernetes:
managedByCodesphere: true # false to bring your own cluster
apiServerHost: 10.10.0.11
controlPlanes:
- ipAddress: 10.10.0.11
workers:
- ipAddress: 10.10.0.14

Wenn managedByCodesphere auf false steht, werden apiServerHost/controlPlanes/workers nicht verwendet; setze stattdessen podCidr und serviceCidr auf die tatsächlichen Netzwerkbereiche des bestehenden Clusters (beide erforderlich, keine Standardwerte) und stelle die kubeConfig des Clusters als Vault-Secret bereit. Siehe Einen bestehenden Kubernetes-Cluster verwenden.

cluster​

Infrastruktur auf Cluster-Ebene: Zertifikate, Monitoring und die beiden Gateway-Dienste. Siehe Optionen für Cluster-Ingress-CA, Gateway und Load Balancing und Cluster-Monitoring für die jeweiligen Unterabschnitte (cluster.certificates, cluster.gateway, cluster.publicGateway, cluster.monitoring).

metallb​

metallb:
enabled: false

Standardmäßig deaktiviert. Siehe Gateway und Load Balancing für die Konfiguration von Pool und Advertisement, wenn aktiviert.

codesphere​

Der größte Abschnitt: Plattform-Domains, Zertifikatsaussteller, Feature Flags, Pläne, Git- und Identity-Provider sowie Managed Services.

codesphere:
domain: example.com
workspaceHostingBaseDomain: dc1.example.com
certIssuer:
type: self-signed
internal: []
preview: {}
features: {}

domain ist die reine Basis-Domain und löst zum Plattform-Gateway auf. workspaceHostingBaseDomain ist der rechenzentrumsspezifische Hostname, der per Wildcard auf das Workspace-Gateway zeigt.

vpn.leftPeerId ist ein optionales Feld, das die lokale Peer-Identität (leftid) festlegt, die von Workspace-VPN-Tunneln während der IKE-Authentifizierung gesendet wird. Wird es weggelassen, verwendet strongSwan die lokale/private IP-Adresse des Workspace als Identität. Viele VPN-Gateways erwarten stattdessen die öffentliche Egress-IP-Adresse des Workspace. Setze vpn.leftPeerId, wenn dein Gateway dies oder eine andere bestimmte Identität erfordert, um mit seiner Verbindungsrichtlinie übereinzustimmen. Akzeptierte Formate folgen der strongSwan-Identitätssyntax: eine IPv4-Adresse (203.0.113.1), ein vollqualifizierter Domainname (vpn.example.com), eine E-Mail-Adresse ([email protected]) oder ein Distinguished Name (C=DE, O=Example, CN=vpn.example.com).

codesphere:
vpn:
leftPeerId: vpn.example.com

email​

Konfiguriert einen benutzerdefinierten SMTP-Server für transaktionale E-Mails:

codesphere:
email:
provider: smtp
smtp:
host: smtp.example.com
port: 587
secure: false
username: codesphere

provider muss smtp sein; host, ein positiver Integer-Wert für port sowie der Boolesche Wert secure sind erforderlich. username ist optional. Speichere das zugehörige Passwort als optionales smtpPassword-Vault-Secret, nicht in config.yaml.

Das Vault-Secret sendGridApiKey ist eine Alternative zu diesem Block. Es wählt automatisch das SMTP-Relay von SendGrid aus und hat Vorrang, wenn beide Optionen konfiguriert sind. Ist keine der beiden Optionen konfiguriert, läuft die Plattform ohne E-Mail-Zustellung. Siehe E-Mail-Zustellung für Beispiele und Migrationsverhalten.

pcApps​

Freie Helm-Values, die an das Argo-CD-Chart pc-applications durchgereicht werden (siehe Architektur). Nur verwenden, wenn eine bestimmte pc-apps- Komponente einen vom Standard abweichenden Wert benötigt. oms init install-config generiert diesen Abschnitt nicht; füge ihn bei Bedarf manuell hinzu.

managedServiceBackends​

Aktiviert die Backend-Implementierung für jeden unter codesphere.managedServices aktivierten Managed Service. Siehe Managed Services. Für Überschreibungen wie Unterprovisionierung siehe Workload-Unterprovisionierung.

operations​

operations:
skip:
- load-container-images

Speichert Installer-Schritte dauerhaft, die bei jedem Durchlauf übersprungen werden sollen, zusätzlich zu dem, was mit --skip-steps übergeben wird. Siehe Installationsschritte und Profile.