Installationsschritte und Profile
Installationsschritte
Skip-Steps machen den Installer fortsetzbar und ermöglichen es ihm, mit Voraussetzungen zu arbeiten, die bereits installiert oder außerhalb von OMS verwaltet werden. Sie sind auch nützlich, wenn nach einer Konfigurationsänderung nur eine spätere Phase erneut ausgeführt wird. Ein übersprungener Schritt wird von OMS nicht validiert oder ersetzt, überspringe ihn also nur, wenn sein Ergebnis bereits vorhanden oder absichtlich unnötig ist; das Überspringen einer erforderlichen Voraussetzung kann einen späteren Schritt scheitern lassen.
Verwende --skip-steps für einen einzelnen Aufruf, mit mehreren durch Kommas
getrennten Namen. Um Skips über zukünftige Läufe hinweg dauerhaft zu machen,
füge sie zu config.yaml hinzu:
operations:
skip:
- load-container-images
Die unterstützten Skip-Namen sind:
| Schritt | Was das Überspringen umgeht |
|---|---|
copy-dependencies | Das Kopieren der gepackten Installationsabhängigkeiten auf die Zielhosts |
extract-dependencies | Das Extrahieren der gepackten Abhängigkeiten auf den Zielhosts |
load-container-images | Das Laden der im veralteten vollständigen Installer-Paket gebündelten Images; aktuelle Lite-Pakete beziehen Images von GHCR, überspringe diesen Schritt daher |
sops | Das Installieren der SOPS-Abhängigkeit für verschlüsselte Installations-Secrets |
docker | Das Installieren und Konfigurieren von Docker auf den Zielhosts |
postgres | Das Installieren und Konfigurieren der in der Installationskonfiguration beschriebenen PostgreSQL-Instanz |
ceph | Das Installieren und Konfigurieren des Ceph-Clusters und der OSDs |
kubernetes | Das Installieren und Konfigurieren des Codesphere-verwalteten k0s-Clusters |
argocd | Der Argo-CD-Bootstrap-Teil der Phase der Cluster-Abhängigkeiten |
set-up-cluster | Das Konfigurieren von Cluster-Abhängigkeiten, nachdem die Basisinfrastruktur bereit ist |
ms-backends | Das Installieren der Managed-Service-Backend-Komponenten |
codesphere | Das Bereitstellen der Codesphere-Plattform selbst |
warnung
Das vollständige Installer-Paket ist veraltet. Aktuelle Installationen sollten
installer-lite.tar.gz verwenden und load-container-images überspringen.
Der Schritt bleibt nur aus Kompatibilitätsgründen mit älteren vollständigen
Paketen verfügbar.
Phasen
Der kombinierte Befehl oms install codesphere installiert in dieser
Reihenfolge:
- Kopiert und extrahiert Abhängigkeiten.
- Überspringt das Laden gebündelter Container-Images, da die Knoten sie von GHCR beziehen.
- Installiert SOPS und die Container-Laufzeitabhängigkeiten.
- Installiert oder konfiguriert PostgreSQL.
- Installiert und konfiguriert Ceph.
- Installiert und konfiguriert k0s, wenn Kubernetes Codesphere-verwaltet ist.
- Installiert Argo CD, Cluster-Abhängigkeiten und Managed-Service-Backends.
- Installiert die Codesphere-Plattform.
Die Installation kann auch als separate Phasen infra, dependencies und
platform ausgeführt werden, wenn die betriebliche Änderungskontrolle
eigenständige Prüfpunkte erfordert — siehe oms install codesphere infra --help, oms install codesphere dependencies --help und oms install codesphere platform --help.
Installationskonfigurationsprofile
Das Profil steuert den standardmäßigen Codesphere-Software-Fußabdruck, sodass sich die Installation an unterschiedlich große Infrastruktur anpassen lässt. Es stellt keine Maschinen bereit und entscheidet nicht automatisch, wie viele PostgreSQL-, Ceph-, Control-Plane- oder Worker-Knoten verwendet werden. Der Assistent oder die Befehlsflags müssen weiterhin die tatsächliche Topologie und IP-Adressen beschreiben.
Die Profile verhalten sich derzeit wie folgt:
| Profil | Vorgesehene Verwendung | Monitoring | Kubernetes-Ressourcenverhalten | Weitere Unterschiede |
|---|---|---|---|---|
dev oder development | Kleine Entwicklungs- und Sandbox-Installationen | Loki, Grafana und Grafana Alloy sind deaktiviert | Wendet das unten beschriebene Ressourcenprofil noRequests an | Data-Center-Name ist standardmäßig dev |
minimal | POC-Installationen, die den normalen Monitoring-Stack mit reduziertem Scheduling-Fußabdruck benötigen | Loki, Grafana und Grafana Alloy sind aktiviert | Wendet dasselbe Ressourcenprofil noRequests an | Data-Center-Name ist standardmäßig dev; CloudNativePG-Operator, Barman-Cloud-Plugin und RGW-Lastverteiler sind aktiviert |
prod oder production | Produktionsinstallationen | Loki, Grafana und Grafana Alloy sind aktiviert | Wendet die reduzierten Ressourcen-Overrides nicht an; Charts behalten ihre normalen Ressourcen- und Replica-Standardwerte | Data-Center-Name ist standardmäßig production |
Das von dev und minimal verwendete Ressourcenprofil noRequests entfernt
CPU- und Memory-Requests von Codesphere-Diensten und unterstützenden Charts.
Es reduziert außerdem mehrere unterstützende Komponenten auf eine Replica,
einschließlich Ingress-Controllern, Loki-Komponenten, RGW-Lastverteiler und
Managed-Service-Backends. Ausgewählte Kern-Codesphere-Dienste behalten zwei
Replicas, ihre Ressourcenanfragen werden jedoch auf null gesetzt. Dies lässt
den Kubernetes-Scheduler einen kleineren Cluster akzeptieren, entfernt aber
Ressourcengarantien und verringert die Ausfalltoleranz. Interpretiere
erfolgreiches Scheduling mit diesem Profil nicht als Beweis dafür, dass die
Hosts unter Last über genügend reale CPU oder Memory verfügen.
Alle Profile starten mit denselben gemeinsamen Infrastruktur-Standardwerten,
einschließlich Codesphere-verwaltetem Kubernetes, installiertem PostgreSQL,
Ceph, LoadBalancer-Gateways, deaktiviertem MetalLB und
Platzhalter-Localhost-Adressen. Sie starten außerdem mit den
Standard-Workspace- und Hosting-Plan-Vorgaben. Ersetze alle
Platzhalter-Werte für Topologie, Domain, Registry und Secrets während des
Assistenten oder der Konfigurationsüberprüfung.
Verwende production für die
Produktions-Baseline
und minimal für die
POC-Topologie. Verwende
dev nur, wenn das Deaktivieren der mitgelieferten Monitoring-Komponenten
angemessen ist.