odx CLI
Odinex Cloud im Terminal und in Skripten verwalten.
odx ist der Kommandozeilen-Client für Odinex Cloud. Benannte Kontexte enthalten Projekt-API-Tokens, einheitliche
Ressourcenbefehle zeigen Ressourcen an, listen sie auf, erstellen, ändern und löschen sie, und
lang laufende Vorgänge warten auf ihre Aktion und zeigen den Fortschritt an.
Installation
Unter Linux und macOS (x86-64 und ARM):
curl -fsSL https://odinex.cloud/install.sh | shDas Skript prüft den Download anhand seiner SHA-256-Prüfsumme und installiert odx nach
/usr/local/bin oder, falls dieses Verzeichnis nicht beschreibbar ist, nach ~/.local/bin (mit ODX_INSTALL_DIR
legen Sie das Ziel selbst fest). Führen Sie es erneut aus, um zu aktualisieren.
Sie können eine Binärdatei auch direkt herunterladen: Linux x86-64, Linux ARM64, macOS Intel, macOS Apple Silicon, Windows x86-64 (Prüfsummen).
Shell-Vervollständigung:
source <(odx completion bash) # bash
odx completion zsh > "${fpath[1]}/_odx" # zsh
odx completion fish | source # fishAuthentifizierung mit einem Kontext
odx verwendet ein Projekt-API-Token (odx_…). Erstellen Sie eines in der
Console unter Projects → Ihr Projekt → API tokens und legen Sie dann einen Kontext an; das Token wird über eine
verdeckte Eingabe abgefragt:
$ odx context create my-project
Token: ********
Context my-project created and activated
$ odx context list
ACTIVE NAME ENDPOINT
* my-project https://api.odinex.cloud/v1
$ odx context use staging # switch
$ odx context active # print the active context
$ odx context delete stagingKontexte werden in ~/.config/odx/config.toml mit dem Dateimodus 0600 gespeichert.
Einstellungen werden aus diesen Quellen gelesen, die höchste Priorität zuerst:
| Einstellung | Quellen |
|---|---|
| Kontext | --context, ODX_CONTEXT, der aktive Kontext |
| Token | ODX_TOKEN, das Token des Kontexts |
| Endpunkt | --endpoint, ODX_ENDPOINT, der Endpunkt des Kontexts, https://api.odinex.cloud/v1 |
| Konfigurationsdatei | --config, ODX_CONFIG, ~/.config/odx/config.toml |
ODX_TOKEN=odx_… odx server list funktioniert also ganz ohne Konfigurationsdatei – praktisch in CI-Pipelines.
Beispiele
# Catalog
odx location list
odx server-type list
odx image list --type system
# SSH key and server
odx ssh-key create --name laptop --public-key-from-file ~/.ssh/id_ed25519.pub
odx server create --name web-1 --type s2 --image ubuntu-24.04 --location fra1 \
--ssh-key laptop --label role=web --user-data-from-file cloud-init.yaml
odx server list -l role=web
odx server describe web-1
odx server ssh web-1 # runs: ssh -l root <ipv4>
odx server metrics --type cpu web-1 # min/avg/max/last of the last hour
odx server poweroff web-1 && odx server change-type --type s4 --upgrade-disk web-1
odx server create-image --description "before upgrade" web-1
odx server set-rdns --hostname web-1.example.com web-1
# Volume attached to the server
odx volume create --name data --size 10 --server web-1
odx volume resize --size 20 data
# Firewall applied by label
cat > rules.json <<'JSON'
[{"direction": "in", "protocol": "tcp", "port": "22", "source_ips": ["198.51.100.0/24"], "description": "SSH from the office"}]
JSON
odx firewall create --name web --rules-file rules.json
odx firewall add-rule --direction in --protocol tcp --port 443 --source-ips 0.0.0.0/0,::/0 web
odx firewall apply-to-resource --type label_selector --label-selector role=web web
# Floating IP
odx floating-ip create --type ipv4 --name ip-1 --location fra1
odx floating-ip assign ip-1 web-1
# Load balancer with a label target
odx load-balancer create --name lb-1 --type lb11 --location fra1
odx load-balancer add-service --protocol http --listen-port 80 --destination-port 8080 lb-1
odx load-balancer add-target --label-selector role=web lb-1
# Clean up
odx load-balancer delete lb-1
odx floating-ip delete ip-1
odx volume detach data && odx volume delete data
odx server delete web-1Ressourcen können per Name oder ID angegeben werden. Alle Befehle finden Sie in der Befehlsreferenz.
Ausgabe
Listenbefehle geben eine Tabelle aus. Das Format ändern Sie mit dem wiederholbaren Flag -o:
odx server list -o columns=id,name,ipv4,labels # pick columns (see odx server list --help)
odx server list -o noheader -o columns=id # for scripts
odx server list -o json # API objects as JSON
odx server describe web-1 -o yaml-l / --selector filtert nach Labels: env=prod, env!=prod, env, !env; Kommas bedeuten UND.
Aktionen und Warten
Befehle, die eine Aktion starten (Erstellen, Ein-/Ausschalten, Anhängen, …), fragen GET /actions/{id} ab und zeigen
auf stderr eine Fortschrittszeile an, bis die Aktion abgeschlossen ist. Mit --no-wait kehrt der Befehl direkt nach der
Anfrage zurück; odx action list und odx action describe <id> zeigen den Status später an. Eine fehlgeschlagene
Aktion beendet den Befehl mit Exit-Code 1 und gibt Fehlercode und Meldung der Aktion aus.
Fehler und Exit-Codes
Fehler werden als error: <message> (<code>) auf stderr ausgegeben. Die Codes sind dieselben wie in der API.
| Exit-Code | Bedeutung |
|---|---|
| 0 | Erfolg |
| 1 | API-Fehler, fehlgeschlagene Aktion, Netzwerk- oder Dateifehler |
| 2 | Bedienfehler: unbekannter Befehl oder unbekanntes Flag, ungültiges Argument, fehlendes Token |
--debug gibt jede HTTP-Anfrage und -Antwort einschließlich der Header zur Ratenbegrenzung
auf stderr aus. Antwortet die API mit 429, wartet odx die in Retry-After angegebene Zeit ab (höchstens 60 Sekunden)
und versucht es bis zu 3-mal erneut.