Skip to main content
Die CLI führt dich durch separate Befehle: Auswahl speichern, prüfen, das Deployment prüfen, anwenden und untersuchen, was noch Aufmerksamkeit braucht. Jeder Befehl hat seine eigene Hilfe. Die CLI läuft nicht automatisch durch das gesamte Deployment und wählt auch kein Kit für dich aus. Dieser Walkthrough beschreibt die native CLI, wie sie im aktuellen öffentlichen Release ausgeliefert wird. Der Standard Mode funktioniert ohne kombify-Konto und ohne Techstack. Lokale Owner-Schlüssel und Deployment-Nachweise bleiben in deinem Workspace.

​
Deinen Startpunkt wählen

Führe den Basement-Bootstrap nur auf dem Host aus, den du konfigurieren willst. Für einen ersten Blick auf die CLI ohne Dienste zu installieren, wähle den Toolchain-Pfad. Windows-Nutzer können die CLI aus dem ZIP des öffentlichen Releases beziehen; das macht Windows nicht zu einem unterstützten nativen Basement-Runtime-Ziel. Prüfe die OS-Kompatibilitätsreferenz für das Installationsziel.

​
1. Die CLI prüfen und einen Workspace anlegen

Öffne nach der Installation der Toolchain ein Terminal:
Die Hilfe gruppiert Befehle in Einrichtung, laufende Pflege und Referenz; die CLI-Referenz listet jeden Befehl mit seinen Flags und Beispielen. Behalte in diesem Walkthrough ein einziges Deployment-Verzeichnis. Nutze für ein Experiment ein frisches Verzeichnis, statt eine bestehende Konfiguration zu ersetzen.

​
2. Deine Auswahl speichern

Für ein Basement Kit mit seinen Katalog-Defaults:
init erstellt stack-spec.yaml und die lokale Owner-Verwahrung. Es gibt den Pfad der gespeicherten Konfiguration und die nächsten Befehle validate und generate aus. Es hat keine Dienste installiert. Katalog-Defaults werden als ausdrückliche Entscheidungen erfasst. Erforderliche Eingaben werden abgefragt, wenn das gewählte Kit sie braucht. Um den Foto-Workload des Kits in einen neuen Workspace aufzunehmen, nutze dies anstelle des vorherigen init-Befehls:
Der Foto-Workload ist an dieser Stelle eine Auswahl, keine laufende Fotobibliothek. Prüfe Speicherpfade, Domain, ausgewählte Anwendungen und Node-Einstellungen in der gespeicherten Datei. Siehe Eine StackSpec konfigurieren. Füge für Skripte --non-interactive zu init hinzu. Fehlende erforderliche Eingaben führen dann zu einem Fehler statt zu einer Rückfrage. Dieses Flag genehmigt keine späteren Deployment-Aktionen. stackkit init --help dokumentiert die verfügbaren Optionen; als Legacy-Kompatibilität markierte Flags liegen außerhalb dieses nativen Walkthroughs.

​
3. Validieren, generieren und prüfen

Die Validierung prüft die Konfiguration gegen den Kit-Vertrag. Die Generierung schreibt Deployment-Artefakte und Nachweise. Mit dem Plan kannst du ausgewählte Workloads, Pfade und Bereitschaft prüfen, bevor du den Host änderst. Prüfe readiness.generation.status und readiness.apply.status und lies alle Blocker. Korrigiere bei Bedarf die Konfiguration und generiere erneut. Ein bereitgestellter Plan bedeutet nicht, dass Anwendungen schon laufen.

​
4. Das Ziel prüfen und anwenden

Auf dem unterstützten Zielhost, mit demselben Workspace:
Auf dem nativen CLI-Pfad prüft prepare Host-Voraussetzungen wie Docker, Compose, Speicher und Ports. Es installiert keine fehlenden Host-Pakete. Löse gemeldete Voraussetzungen, bevor du anwendest. apply ändert den Host. Prüfe die Freigabeabfrage und die beabsichtigten Änderungen. Folge Prüfen, anwenden und verifizieren für die detaillierten Lifecycle-Prüfungen. Wenn du den Basement-Bootstrap verwendet hast, ist das erste Apply bereits erfolgt; wiederhole es nicht nur, um eine Tour abzuschließen.

​
5. Herausfinden, was nutzbar ist

verify prüft die Stack-Spec, den Deployment-Zustand, den Docker-Daemon, die StackKit-Container und ihre Gesundheit sowie mit --http die Routen aus der generierten Zugriffsübersicht. Jede fehlgeschlagene Prüfung nennt ihren Grund. Eine konfigurierte Adresse allein belegt nicht, dass eine Anwendung erreichbar ist; eine bestandene HTTP-Prüfung tut das. Folge der Einrichtungsanleitung der Anwendung, wenn noch ein Konto konfiguriert werden muss. Nutze stackkit setup --help für die unterstützten Einrichtungsaktionen. Öffne zum Abschluss die Anwendung und führe eine kleine echte Aufgabe aus, etwa ein Testfoto in deine Fotobibliothek hinzuzufügen. Der Erfolg der CLI-Installation allein belegt nicht, dass diese Aufgabe funktioniert.

​
6. Fortsetzen und Fehler beheben

Kehre zum selben Deployment-Verzeichnis zurück:
drift detect vergleicht die laufende Compose-Runtime mit dem aufgelösten Plan, den generierten Artefakten und dem signierten Apply-Nachweis, ohne etwas zu ändern, und logs get liest das strukturierte Log eines Laufs aus logs list. Nutze den gemeldeten Grund und die nächste Aktion, um weiterzumachen. Bewahre den Workspace, wenn eine Operation fehlschlägt; starte nicht mit init neu und bearbeite keine generierten Dateien, um einen Blocker zu umgehen. Halte Owner-Schlüssel und Zugriffsprotokolle privat und prüfe Diagnoseausgaben, bevor du sie teilst. Für die laufende Pflege nutze Day-2-Operationen und Sichern und wiederherstellen. Die Kit-Auswahl und die geführte Konfigurationserfahrung in Techstack sind eine optionale Fortsetzung; für diesen lokalen CLI-Ablauf sind sie nicht erforderlich.