klops CLI
Alles, was die Oberfläche kann, aus dem Terminal oder aus einem Skript.
Auf dieser Seite
Was das ist
klops ist die Kommandozeile von klickops. Sie spricht dieselbe REST-API wie die Oberfläche, alles Klickbare ist also skriptbar. Es gibt keinen zweiten Funktionsumfang und nichts, was die Oberfläche kann und die CLI nicht.
Sie spricht mit klickops und sonst mit nichts. Kein kubeconfig, keine direkten Datenbankverbindungen, kein kubectl auf deinem Rechner. Das ist Absicht: Zugriffskontrolle, Audit und TLS bleiben an einer Stelle, und dein Laptop braucht keine Cluster-Zugangsdaten.
Wann du das brauchst
- Ein Deployment aus einem Skript oder aus deinem eigenen CI.
- Logs lesen oder eine Abfrage laufen lassen, ohne den Browser zu öffnen.
- Dasselbe über zehn Projekte hinweg tun, ohne zwanzigmal zu klicken.
Anmelden
klops auth login --server https://klickops.example.com
Das schreibt ~/.klickops/config.yaml mit den Rechten 0600 und verweigert das Lesen, wenn die Rechte weiter stehen. Im CI lässt du die Anmeldung weg und setzt stattdessen KLICKOPS_SERVER und KLICKOPS_TOKEN, mit einem API-Token statt deinem eigenen Konto.
Wie ein Befehl aussieht
Befehle lesen sich als Substantiv, dann Verb.
klops apps list --project shop
klops apps logs web --project shop --follow
klops db query orders-db --project shop -c "select count(*) from orders"
klops apps deploy web --image nginx:1.27-alpine --port 80 --project shop
Jeder lesende Befehl nimmt -o, und genau das macht ihn skriptbar:
| Format | Wofür |
|---|---|
table | Zum Lesen. Der Standard. |
json | Zum Weiterreichen an jq. |
yaml | Zum Vergleichen oder Weiterverarbeiten. |
name | Nur die Namen, für eine Shell-Schleife. |
wide | Zum Lesen, mit mehr Spalten. |
Farbe fällt automatisch weg, sobald die Ausgabe kein Terminal ist. klops apps list -o json \| jq sieht also nie Escape-Sequenzen.
Woher die Einstellungen kommen
Flag schlägt Umgebungsvariable schlägt Konfigurationsdatei schlägt Standard. Ein --project auf der Kommandozeile gewinnt also gegen KLICKOPS_PROJECT, und das gegen den aktuellen Kontext in ~/.klickops/config.yaml.
| Variable | Setzt |
|---|---|
KLICKOPS_SERVER | Mit welchem klickops gesprochen wird |
KLICKOPS_TOKEN | Das Token zur Anmeldung |
KLICKOPS_ORG | Standard-Organisation |
KLICKOPS_PROJECT | Standard-Projekt |
Exit-Codes
Skripte hängen daran, deshalb bleiben sie stabil.
| Code | Bedeutet |
|---|---|
0 | Erfolg |
1 | Etwas ist schiefgelaufen |
2 | Der Befehl wurde falsch benutzt |
3 | Nicht angemeldet, oder das Token ist abgelaufen |
4 | Angemeldet, aber nicht berechtigt |
5 | Nicht gefunden |
6 | Existiert bereits |
Der nützliche Unterschied: 3 und 4 sind zwei verschiedene Fragen. Eine 3 im CI heisst, das Token muss erneuert werden. Eine 4 heisst, es braucht mehr Rechte.
Grenzen und Fallstricke
- Es gibt keinen Cache. Jeder Befehl fragt den Server, denn veralteter Zustand tut mehr weh als ein Netzwerkaufruf.
- Die Konfigurationsdatei wird bei zu weiten Rechten abgelehnt. Sie enthält ein Token, eine für alle lesbare Datei gilt deshalb als Versehen und nicht als Wunsch.
- Ein Token gehört einer Organisation, nicht dir. Skripte sollten eines nutzen statt deiner persönlichen Sitzung, damit eine Kündigung nicht die Pipeline bricht. Siehe API-Tokens.
Verwandt
- API-Tokens zum Anmelden eines Skripts.
- MCP-Server, falls klickops von einem KI-Assistenten statt von einem Skript bedient wird.