CloudMonkey (cmk) in der Praxis: Apache CloudStack aus dem Terminal

WebDisk Blog · Kategorie: Public Cloud · Lesezeit: ~17 Minuten

Kurz gefasst:- cmk (CloudMonkey) ist der offizielle Befehlszeilenclient von Apache CloudStack — der Plattform, auf der WebDisk Cloud läuft. Panel und cmk rufen dieselbe API mit denselben Berechtigungen auf; das Terminal steuert Wiederholbarkeit und einen Eintrag in der Historie bei, das Panel gewinnt bei der Maschinenkonsole und beim ersten Umsehen.- Die Konfiguration besteht aus einem Profil und einem API-Schlüsselpaar aus dem Panel; den ersten sinnvollen Befehl (list virtualmachines) führen Sie in wenigen Minuten aus, und das Ergebnis in JSON oder CSV geht direkt in ein Skript oder eine Tabellenkalkulation.- Ehrlich gesagt: cmk ist kein Infrastructure as Code — es kennt keinen Zielzustand und macht keine Änderung rückgängig. Die Beschreibung einer Umgebung im Repository ist Terraform oder Ansible; cmk ist für Abfragen, einmalige Operationen und schnelle Automatisierung da. >Sie arbeiten nicht mit dem Terminal? Überspringen Sie die Befehlsblöcke — die Beschreibung der Plattform, der Vergleich der Verwaltungsmethoden und der Abschnitt über die Grenzen des Werkzeugs lassen sich auch ohne sie lesen.

Es ist Freitag, 17:40 Uhr. Bis zur Abschaltung übers Wochenende bleiben vierundzwanzig Testmaschinen — im Panel bedeutet das vierundzwanzigmal dieselbe Abfolge: suchen, Details, Menü, „Stop“, bestätigen. Am Montag dasselbe in die andere Richtung, nur dass jemand zwei Maschinen übersieht und sie das ganze Wochenende durchlaufen. Niemand hat einen Fehler gemacht — ein Werkzeug zum Betrachten und Entscheiden wurde für Fließbandarbeit eingesetzt.

Wir zeigen hier den zweiten Weg: die Cloud aus dem Terminal verwalten — vom Aufbau der CloudStack-API über cmk von der Installation bis zu Skripten und Fallstricken bis hin zu den ehrlichen Grenzen des Werkzeugs und einem Überblick über die lebenden Clients. Die Beispiele führen Sie auf jedem beliebigen CloudStack aus, auch in der WebDisk Public Cloud — der Umfang der Befehle hängt von der Rolle Ihres Kontos und von den Diensten des Betreibers ab.

Was Apache CloudStack ist und was der Kunde von dieser Architektur sieht

CloudStack ist ein IaaS-Orchestrator, kein Hypervisor. Es virtualisiert selbst nichts — es steuert Hypervisoren (die Software, die virtuelle Maschinen auf einem physischen Server ausführt): KVM, VMware vSphere, XenServer/XCP-ng. Es ergänzt eine Schicht, die Hypervisoren nicht mitbringen: Mandantenfähigkeit, Netzwerke, Speicher, Verbrauchserfassung und eine einheitliche API. Lizenz Apache 2.0, seit März 2013 ein vollwertiges Projekt der Apache Software Foundation — ohne Copyleft, ohne „Open Core“ eines einzelnen Herstellers.

Intern ist die Plattform hierarchisch aufgebaut: Region → Zone → Pod → Cluster → Host. Von dieser Leiter sieht der Kunde eine einzige Sprosse — die Zone, üblicherweise ein Rechenzentrum. Pods, Cluster und Hosts sieht nur der Administrator des Betreibers, und das ist Absicht: Sie wählen nicht den Server aus, auf dem Ihre Maschine landet.

Primary Storage hält die Volumes der Maschinen — der laufenden wie der gestoppten — und steht nah an den Hosts. Secondary Storage ist eine Ressource der gesamten Zone: Templates (Maschinenvorlagen), ISO-Abbilder, Snapshots. Deshalb dauert ein Volume-Snapshot seine Zeit (die Daten wandern zwischen den Speichern), und der erste Start einer Maschine aus einem frisch registrierten Template ist langsamer als jeder weitere.

Drei Typen von Systemmaschinen, mit denen der Kunde täglich zu tun hat, laufen im Hintergrund, ohne dass sie jemand bestellt. Die SSVM bedient den Secondary Storage. Der Console Proxy vermittelt zwischen Browser und Maschinenkonsole — ihm verdankt das Panel seine Funktion „Konsole“. Der Virtual Router (der Software-Router des Kundennetzwerks) erbringt die Netzwerkdienste: DHCP, DNS, Source NAT, Static NAT, Portweiterleitung, Load Balancing, Firewall- und ACL-Regeln, VPN sowie den Metadaten-Endpunkt für cloud-init. Architektonisch ist das wichtig: NAT, Portweiterleitung und Load Balancing sind keine eigenständigen Objekte — Sie steuern sie über dieselbe API wie die Maschinen. Wie sie abgerechnet werden, entnehmen Sie der Preisliste des Betreibers.

Die letzte Sache, die im CLI überrascht: Eigentümer der Ressourcen ist das Konto (account), nicht der Benutzer. Benutzer sind Anmeldewege; Limits, Abrechnung und Eigentum sitzen eine Etage höher. Einen eigenen Behälter bilden Projekte — mit eigenen Limits und eigenem Verbrauch, in der API über den Parameter projectid erreichbar. Wenn Sie im Panel im Kontext eines Projekts arbeiten, im Terminal aber projectid weglassen, sehen Sie eine andere Menge von Maschinen. WebDisk Cloud läuft auf CloudStack und KVM — über den Umzug von vSphere haben wir anlässlich der Migration von VMware zu WebDisk Cloud geschrieben.

Panel, API, CLI und IaC — vier Formen desselben Zugangs

Alles, was Sie mit CloudStack tun, läuft über einen einzigen Endpunkt: den Pfad /client/api auf dem Verwaltungsserver. Die Anfrage ist ein gewöhnliches HTTP GET oder POST mit dem Parameter command; die Antwort kommt standardmäßig als XML und nach Hinzufügen von response=json als JSON. Authentifiziert wird über eine HMAC-SHA1-Signatur, die mit dem geheimen Schlüssel über die sortierte und in Kleinbuchstaben umgewandelte Parameterkette gebildet wird. Alle übrigen Werkzeuge aus diesem Artikel sind Aufsätze auf genau dasselbe.

Die Befehlsnamen sind konsequent: Verb + Substantiv — deployVirtualMachine, listVirtualMachines, stopVirtualMachine, createNetwork, associateIpAddress, deleteSnapshot. Es gibt knapp neunhundert Befehle (der API-Schnappschuss in cmk 6.5.0 kennt 880, davon 370 asynchrone), ein gewöhnliches Konto sieht aber deutlich weniger — die Liste hängt von der Rolle und von der Version der Plattform ab. Das Schema ist so regelmäßig, dass man diese Namen nach einem Arbeitstag richtig errät. Zwei Dinge von Anfang an: Ein Teil der Befehle ist asynchron — er liefert sofort eine Job-Kennung (jobid) statt des Ergebnisses; und der API-Schlüssel erbt die Berechtigungen der Kontorolle, das CLI ist also kein Seiteneingang mit größeren Rechten.

Das Wichtigste: die grafische Oberfläche hat keinen privilegierten Kanal zur Plattform. Das Panel — welches auch immer — ist ein gewöhnlicher Client desselben /client/api und ermittelt die Funktionsliste mit dem Befehl listApis; derselbe Befehl treibt die Autovervollständigung in cmk an. Die Schlussfolgerung ist mitunter kontraintuitiv: Eine neue Fähigkeit der Plattform steckt zuweilen früher in der API, als sie ein eigenes Formular bekommt.

Daraus ergeben sich vier Verwaltungsmethoden — keine Stufen der Fortgeschrittenheit, sondern Formen desselben Zugangs:

• Panel — Auffindbarkeit und Kontext. Auswahllisten lösen die UUIDs für Sie auf, Formulare achten auf die Reihenfolge der Abhängigkeiten, und die Maschinenkonsole gibt es praktisch nur hier. Es skaliert nicht und hinterlässt keine Prozedur.
• Rohe API — volle Kontrolle, null Abhängigkeiten. Die Signatur allein sind einige Dutzend Zeilen Code; der Preis ist der Rest: Paginierung, asynchrone Jobs, Sichtbarkeitsbereich, Kodierung strukturierter Parameter.
• CLI (cmk und Verwandte) — Wiederholbarkeit, ohne einen Client zu schreiben; die Befehlshistorie ist ein kostenloses Protokoll dessen, was passiert ist.
• IaC (Terraform, Ansible) — Zielzustand im Repository, Änderungsprüfung im Pull Request, Wiederherstellung der Umgebung von null.

Zwei Mechanismen der Plattform sollten Sie kennen. Der Betreiber kann eine Begrenzung der API-Aufrufrate aktivieren — ein Skript, das den Server in einer Schleife abfragt, kann sie ausschöpfen. Neuere CloudStack-Releases haben Webhooks: Die Plattform verschickt bei Ereignissen wie einem Zustandswechsel einer Maschine selbst eine HTTP-Benachrichtigung, eine Integration muss also nicht auf Abfragen beruhen.

Was cmk ist und warum „cloudmonkey“ heute zwei verschiedene Werkzeuge bezeichnet

Das ist die erste Hürde, an der Leute eine Stunde verlieren: Zwei Werkzeuge tragen denselben Namen. Das ältere, cloudmonkey, ist in Python geschrieben und wird über pip installiert. Das neuere, cmk, ist eine von Grund auf neu geschriebene Portierung nach Go — eine einzelne ausführbare Datei, kompatibel mit CloudStack ab Version 4.9 aufwärts.

Die Python-Version sollte man heute nicht mehr installieren: Das letzte Release auf PyPI ist 5.3.3.1 vom 13. Oktober 2021 — fast fünf Jahre Stille. Ein Support-Ende hat niemand verkündet, aber die Paketbeschreibung verweist selbst auf die Go-Version. Das aktuelle Release von cmk ist 6.5.0 vom 26. August 2025 (Stand: August 2026); der Entwicklungszweig lebt, aber Releases erscheinen selten.

Bei der Portierung nach Go sind weggefallen: das XML-Ausgabeformat, das Protokollieren der Anfragen in eine Datei und die farbige Ausgabe. Dafür gibt es eine einzige Datei ohne Abhängigkeiten — auch für Windows — und ein Konfigurationsverzeichnis ~/.cmk, bewusst anders als in der alten Version. Das Versenden von Anfragen per POST kam für Passwort und Benutzerdaten in 6.4.0, und 6.5.0 verallgemeinerte es auf alle Anfragen und aktivierte es standardmäßig (postrequest). Hinzu kamen außerdem die Abfrage des Codes für die Zwei-Faktor-Authentifizierung, das Hochladen von Templates und ISOs sowie das umgekehrte Filtern mit dem Parameter exclude=.

Wie konfiguriert man cmk in fünf Minuten?

Der einfachste Weg ist der Download der Binärdatei aus den Releases des Projekts. Es gibt auch eine Homebrew-Formel (brew install cloudmonkey, der Befehl heißt cmk), ein Snap-Paket und ein Container-Image — in der CI heften Sie immer ein konkretes Tag an, denn latest auf Docker Hub ist seit Jahren veraltet.

# Linux x86-64: ins Arbeitsverzeichnis herunterladen, verifizieren, erst dann installieren
curl -fsSLO https://github.com/apache/cloudstack-cloudmonkey/releases/download/6.5.0/cmk.linux.x86-64
sha256sum cmk.linux.x86-64
sudo install -m 0755 cmk.linux.x86-64 /usr/local/bin/cmk
cmk version

Die SHA-256-Prüfsummen (und MD5) jeder Datei veröffentlicht das Projekt in den Release Notes — vergleichen Sie das Ergebnis von sha256sum damit, bevor Sie der Datei Ausführungsrechte geben und sie in ein Systemverzeichnis lassen. Es ist eine Binärdatei, die gleich Ihre API-Schlüssel bekommt. Schauen Sie bei der Gelegenheit auf der Release-Seite nach, ob es etwas Neueres als 6.5.0 gibt — die Versionsnummer steckt fest in der Download-Adresse.

Die API-Schlüssel erzeugen Sie selbst — das Paar „API-Schlüssel + geheimer Schlüssel“ und die Adresse des API-Endpunkts finden Sie im Panel von WebDisk Cloud, in den Einstellungen Ihres Benutzers. Der geheime Schlüssel ist ein Passwort: Wer ihn hat, kann in Ihrer Cloud, was Sie können — wir haben bereits geschrieben, warum langlebige statische Schlüssel ein Problem sind.

Setzen Sie die Konfiguration mit Befehlen, nicht mit dem Texteditor — warum, erklärt der erste Fallstrick.

cmk set profile moja-chmura # legt ein Profil dieses Namens an und aktiviert es
cmk set url <API-ENDPUNKT-ADRESSE> # endet üblicherweise auf /client/api
cmk set apikey <IHR-API-SCHLUESSEL>
cmk set secretkey <IHR-GEHEIMER-SCHLUESSEL>
cmk set output json # json | table | text | column | csv | default
cmk sync # holt die API-Liste vom Server

Ein Vorbehalt: cmk schreibt beide Schlüssel im Klartext nach ~/.cmk/, das Verzeichnis gehört also nie in ein Repository oder ein Container-Image — tragen Sie es in .gitignore ein. Die übrigen Konsequenzen, samt Schlüsselrotation, sammelt der sechste Fallstrick.

cmk sync ist keine Kosmetik: Es baut einen lokalen Befehls-Cache auf — daher die Autovervollständigung, die Parameterliste und das Wissen darüber, welche Befehle asynchron sind. Der Cache ist für jedes Profil eigenständig, machen Sie also nach dem Hinzufügen einer zweiten Cloud auch dort ein sync. Der erste Test:

cmk list zones filter=id,name,networktype
cmk list virtualmachines listall=true filter=name,state,zonename

Ohne Argumente startet cmk eine interaktive Shell: Historie, Rückwärtssuche über Strg+R, Autovervollständigung per Tabulatortaste. Tab auf einem Parameter, der auf id= endet, führt eine echte Abfrage an den Server aus und schlägt UUIDs samt Ressourcennamen vor — bequem beim Lernen, in einer großen Umgebung besser abzuschalten (set autocomplete false).

Wie startet man eine virtuelle Maschine mit einer einzigen Befehlsfolge?

In CloudStack identifizieren UUIDs alles, die Arbeit beginnt also mit der Erkundung. Unten der vollständige Weg: vier Abfragen, ein SSH-Schlüssel, die Maschine, eine öffentliche Adresse, eine Zugriffsregel.

# 1. Erkundung der Umgebung — hieraus nehmen Sie vier Kennungen
cmk list zones filter=id,name
cmk list serviceofferings filter=id,name,cpunumber,memory
cmk list templates templatefilter=executable zoneid=<ZONE-UUID> filter=id,name,ostypename
cmk list networks zoneid=<ZONE-UUID> filter=id,name,type,cidr

Der Parameter templatefilter in listTemplates ist verpflichtend — executable bedeutet „Templates, aus denen ich eine Maschine starten darf“.

# 2. Registrierung des öffentlichen SSH-Schlüssels (@ liest den Dateiinhalt ein)
cmk register sshkeypair name=laptop publickey=@/home/benutzer/.ssh/id_ed25519.pub

# 3. Start der Maschine; userdata muss base64-kodiert sein — cmk übernimmt das nicht für Sie
cmk deploy virtualmachine \
  name=web-01 displayname=web-01 \
  serviceofferingid=<SO-UUID> \
  templateid=<TPL-UUID> \
  zoneid=<ZONE-UUID> \
  networkids=<NET-UUID> \
  keypair=laptop \
  userdata=$(base64 -w0 cloud-init.yaml) \
  startvm=true

Achten Sie auf die Endung .pub: Sie senden den öffentlichen Schlüssel, der private verlässt Ihre Maschine nie. Und eine zweite Anmerkung: Der Inhalt von cloud-init.yaml landet in den Prozessargumenten und in der Shell-Historie; Passwörter und Token übergeben Sie deshalb über den Mechanismus des Zielsystems und nicht per Datei auf der Befehlszeile.

Welche Parameter deployVirtualMachine verlangt, hat sich zwischen den Releases geändert: Seit CloudStack 4.21 sind nur serviceofferingid und zoneid erforderlich (hinzu kamen volumeid und snapshotid, eine Maschine lässt sich also auch aus einem Volume oder einem Snapshot wiederherstellen), in 4.20 und älter ist templateid Pflicht. An Ihrer eigenen Cloud prüfen Sie das mit cmk deploy virtualmachine -h — der Befehl gibt Beschreibung und Feldliste direkt vom Server aus.

# 4. Öffentliche IP-Adresse und SSH-Zugang nur aus dem Büro
cmk associate ipaddress zoneid=<ZONE-UUID> networkid=<NET-UUID>

cmk create portforwardingrule ipaddressid=<IP-UUID> protocol=TCP \
  publicport=22 privateport=22 virtualmachineid=<VM-UUID> \
  networkid=<NET-UUID> openfirewall=false

cmk create firewallrule ipaddressid=<IP-UUID> protocol=TCP \
  startport=22 endport=22 cidrlist=203.0.113.10/32

Die Einstellung openfirewall=false ist bewusst gewählt: Die Firewall-Regel fügen Sie separat hinzu, mit einer konkreten Liste von Quelladressen, statt den Port für das gesamte Internet zu öffnen. Die fertige Maschine sollten Sie gleich mit einem Watchdog ausrüsten — auch das sind ein paar Befehle, nur eben innerhalb des Systems.

Der übrige Lebenszyklus sieht so aus, wie es die Intuition Verb + Substantiv nahelegt:

cmk stop virtualmachine id=<VM-UUID>
cmk start virtualmachine id=<VM-UUID>
cmk reboot virtualmachine id=<VM-UUID>
cmk scale virtualmachine id=<VM-UUID> serviceofferingid=<NEUE-SO-UUID>
cmk change serviceforvirtualmachine id=<VM-UUID> serviceofferingid=<NEUE-SO-UUID>
cmk create snapshot volumeid=<VOL-UUID> name=vor-dem-update quiescevm=true
cmk destroy virtualmachine id=<VM-UUID> expunge=true

scale virtualmachine betrifft eine laufende Maschine, change serviceforvirtualmachine eine gestoppte; die Verfügbarkeit beider hängt vom Hypervisor und vom Betreiber ab.

Der Befehl hat eine jobid zurückgegeben. Wie wartet man auf das Ende der Operation?

Die meisten zustandsverändernden Befehle sind asynchron: Der Server gibt eine Job-Kennung zurück und arbeitet im Hintergrund. Der Job-Status hat drei Werte: 0 — in Arbeit, 1 — erfolgreich, 2 — Fehler.

Standardmäßig erledigt cmk das für Sie: Die Einstellung asyncblock ist aktiviert, das Werkzeug fragt den Server also alle zwei Sekunden selbst ab und zeigt erst das Endergebnis — das fertige Maschinenobjekt statt der rohen jobid. Das Zeitlimit gibt die Einstellung timeout vor (standardmäßig 1800 Sekunden); nach ihrer Überschreitung bekommen Sie async API job query timed out.

Manchmal wollen Sie das Gegenteil: die Operation abfeuern und nicht warten.

cmk set asyncblock false
cmk deploy virtualmachine ... # gibt sofort die Job-Kennung zurück
cmk query asyncjobresult jobid=<JOB-UUID> filter=jobstatus,jobresultcode

Das ist zugleich die Antwort auf einen klassischen Anfängerfehler: ein Skript, das direkt nach deploy virtualmachine eine NAT-Regel setzt und einen Fehler bekommt, weil die Maschine noch nicht existiert. Bei asyncblock=true verschwindet das Problem; mit einem eigenen HTTP-Client schreiben Sie die Abfrageschleife selbst.

Wie Sie aus cmk ein Werkzeug für Berichte und Skripte machen

Zwei Mechanismen machen aus dem CLI eine Datenquelle. Der erste ist filter= — die Liste der Felder, die im Ergebnis bleiben — sowie das umgekehrte exclude= (das Filtern erfolgt lokal, Details im fünften Fallstrick). Der zweite ist das Ausgabeformat: global über set output, einmalig über die Option -o.

# Bericht für die Tabellenkalkulation: alle Maschinen des Kontos, ausgewählte Spalten, Format CSV
cmk -o csv list virtualmachines listall=true \
    filter=name,state,zonename,cpunumber,memory > maschinen.csv

# Dasselbe zur weiteren Verarbeitung in jq
cmk -o json list virtualmachines listall=true \
  | jq -r '.virtualmachine[] | [.name, .state, .zonename] | @tsv'

Der Parameter listall=true bedeutet „zeige alles, was ich sehen darf“; ohne ihn sehen Sie nur eigene Ressourcen. Das Freitagsfließband vom Anfang des Artikels sieht so aus:

#!/usr/bin/env bash
# Stoppen aller laufenden Maschinen, deren Name "test" enthält
set -euo pipefail # cmk-Fehler gehen nach stdout, nicht ins JSON — daher pipefail

ids=$(cmk -o json list virtualmachines listall=true state=Running keyword=test \
      | jq -r '.virtualmachine[].id')

for id in ${ids}; do
  printf 'stoppe %s ... ' "${id}"
  if cmk stop virtualmachine id="${id}" >/dev/null; then
    echo "ok"
  else
    echo "FEHLER" >&2
  fi
done

Bevor Sie die Schleife starten, sehen Sie sich die Liste der Kennungen selbst an: keyword passt auf einen Namensbestandteil, test fängt also auch latest-api oder protest-db ein — und das ist ein Skript, das fremde Maschinen stoppt. Sicherer ist es, nach einem Tag (tags) zu filtern als nach dem Namen, und den ersten Durchlauf mit einem echo vor cmk stop zu machen. Zwei Dinge sind Absicht: das Filtern auf Serverseite (state=Running keyword=test) statt in jq, weil der Server dann keine Daten schickt, die Sie ohnehin nicht verwenden, sowie das Prüfen des Exit-Codes statt des Feldes errortext — Grund und Vorbehalt stehen im zweiten Fallstrick.

Sechs cmk-Fallstricke, die in der offiziellen Dokumentation fehlen

1. Schreiben Sie ~/.cmk/config nicht von Hand. Das ist der teuerste Irrtum. Die globalen Einstellungen hält cmk in einem namenlosen Block oben in der Datei, ohne Überschrift. Ein in gutem Glauben ergänzter Abschnitt [core] ist nicht global — er landet in der Liste der Serverprofile. Die Folgen sind nicht offensichtlich: timeout beträgt dann null, jeder asynchrone Job endet also mit der Meldung async API job query timed out, und ein leerer Profilname ergibt trotz korrekter Schlüssel ein failed to authenticate to make API call. Abhilfe: Setzen Sie alles über cmk set ... und entfernen Sie die ergänzten Abschnitte.

2. Fehler gehen auf die Standardausgabe und sind kein JSON. Ein fehlgeschlagener Aufruf druckt gewöhnlichen Text und beendet den Prozess mit Code 1 — ein Skript, das das Feld errortext sucht, findet es nie. Dorthin geht auch die Ausgabe der Option -d, weshalb cmk -d ... | jq immer scheitert. Es gibt eine schmerzhafte Ausnahme: Weist cmk einen Befehl mit der eigenen Validierung zurück (Meldung Missing required parameters), endet es mit Code 0. Ein Tippfehler im Parameternamen oder ein veralteter Cache ergeben ein Skript, das „ok“ meldet, obwohl es nichts getan hat. Prüfen Sie bei kritischen Operationen also nicht nur den Exit-Code, sondern auch, ob die Antwort JSON ist.

3. set profile mit einem Tippfehler legt still ein neues Profil an — mit der Standardadresse localhost und den Zugangsdaten admin/password — und schaltet darauf um, was eine Reihe unverständlicher Verbindungsfehler ergibt. Der Befehl switch profile, der nur auf bestehende Profile umschaltet, wartet im Entwicklungszweig und fehlt in 6.5.0.

4. Die Parametervalidierung findet clientseitig statt, aus dem Cache. Ohne sync nutzt cmk den eingebauten Schnappschuss der API-Liste — in 6.5.0 entspricht er dem CloudStack-Release 4.21, der im Werkzeug verdrahteten Version und nicht der Version Ihrer Cloud — und bittet dann auf der Diagnoseausgabe um sync. Ein veralteter Cache kann einen korrekten Aufruf mit der Meldung Missing required parameters blockieren oder für einen existierenden Befehl unknown command or API requested melden. Machen Sie nach jedem Update Ihrer Cloud ein cmk sync.

5. filter= filtert lokal. Es verringert weder Transfer noch Serverlast, unterstützt keine verschachtelten Pfade und macht, zusammen mit exclude= angegeben, Letzteres unwirksam. Eine automatische Paginierung gibt es auch nicht: page und pagesize gibt man gemeinsam an, die Folgeseiten sammelt Ihr Skript ein.

6. Die Geheimnisse liegen im Klartext in Dateien. set apikey und set secretkey schreiben die Werte nach ~/.cmk/config, und in der interaktiven cmk-Shell eingegeben — auch nach ~/.cmk/history. Seit 6.5.0 haben beide Dateien die Rechte 0600, der Inhalt bleibt aber lesbar und wandert in jede Kopie des Heimatverzeichnisses. Über die Optionen -k/-s übergebene Schlüssel sieht man zusätzlich in der Shell-Historie und in der Prozessliste — löschen Sie einen solchen Eintrag oder stellen Sie dem Befehl ein Leerzeichen voran, wenn Sie HISTCONTROL=ignorespace aktiviert haben. Einen Schlüssel, der abgeflossen ist, machen Sie unwirksam, indem Sie im Panel einen neuen erzeugen — der alte funktioniert dann nicht mehr; tun Sie das bei jedem Verdacht ohne Zögern: Wechsel des Laptops, Ausscheiden einer Person aus dem Team, versehentlicher Commit. Bei einem Zertifikatsprüfungsfehler schalten Sie die Prüfung nicht über die Einstellung verifycert ab — reparieren Sie das Vertrauen zur Zertifizierungsstelle; ohne sie lassen sich Ihre Schlüssel unterwegs abfangen. Und eine Kleinigkeit: cmk signiert die Anfrage mit dem Parameter expires, der fünfzehn Minuten in die Zukunft gesetzt wird (signatureversion=3), eine falsch gehende Uhr ergibt also einen Authentifizierungsfehler, der wie ein falscher Schlüssel aussieht — prüfen Sie die Zeit, bevor Sie neue Schlüssel erzeugen.

Wann das Terminal eine schlechte Idee ist und was cmk nicht leistet

Ohne Ausflüchte: Es kommt vor, dass das CLI langsamer und riskanter ist als das Klicken.

• Exploratives Arbeiten. Die Frage „was habe ich hier eigentlich?“ ist im Panel ein Blick auf die Liste mit den Statusanzeigen; im Terminal sind es drei Abfragen und zusammengekniffene Augen.
• Eine Operation, einmal ausgeführt. Das Profil einzurichten und drei UUIDs zu suchen dauert länger als fünf Klicks.
• Die Maschinenkonsole. Kein Terminal rendert sie — wobei cmk create consoleendpoint virtualmachineid=<VM-UUID> eine Adresse zum Öffnen im Browser liefert. Eine kaputte fstab, wegen der das System nicht hochkommt, reparieren Sie ohnehin erst im Konsolenfenster.
• Unumkehrbare Operationen. destroy virtualmachine ... expunge=true fragt nicht „wirklich?“. Das Panel fragt.
• Komplexe Konstrukte mit Abhängigkeiten. Bei einer VPC mit mehreren Schichten, ACL-Listen und einem VPN-Tunnel erzwingt das Formular die richtige Reihenfolge; das CLI lässt Sie das falsch bauen, und Sie erfahren es später.
• Eine Umgebung, die reproduzierbar sein soll. Hier lautet die Antwort Terraform oder Ansible: cmk führt Befehle aus, es pflegt keine Deklaration. Diesen Weg haben wir separat beschrieben — Apache CloudStack mit Terraform verwalten, von der Provider-Konfiguration bis zum Kubernetes-Cluster aus Code. Ein Bash-Skript, das „fast“ Infrastructure as Code ist, ist die schlechteste aller möglichen Welten.

Es gibt außerdem eine Grenze auf unserer Seite: Die Rolle eines Kundenkontos umfasst keine administrativen Befehle des Betreibers. Hosts, Adresspools, Service Offerings (die vom Betreiber vorgegebenen Ressourcenprofile) oder die Parameter der Zone sehen Sie über die API nicht — hier bleibt die Anfrage an uns, und kein CLI verkürzt das.

Und eine Grenze des Geltungsbereichs: cmk verwaltet die Ressourcen der Plattform — Maschinen, Volumes, Netzwerke, Adressen, Templates —, aber nicht die Daten darin. Den S3-kompatiblen Objektspeicher steuern Sie mit den Werkzeugen des S3-Ökosystems (aws CLI, rclone, s5cmd), nicht mit CloudMonkey. Das Innere des Betriebssystems ist eine Aufgabe für cloud-init und Ansible.

Womit verwaltet man CloudStack sonst noch? Der Stand des Ökosystems im August 2026

cmk ist der Referenzclient, aber nicht der einzige. Die Daten stammen aus den Repositories und Paketregistern, denn in diesem Ökosystem sind „existiert“ und „wird gepflegt“ zwei verschiedene Dinge:

• cs (Python) — Bibliothek und CLI in einem, Konfiguration in ~/.cloudstack.ini, behandelt asynchrone Jobs selbst. Die Standardwahl für Skripte in Python; Release vom Juni 2026. Harte Abhängigkeit der Ansible-Collection.
• cloudstack-cli (Ruby) — ein Betreiberwerkzeug mit Operationen höherer Ebene: eine Maschine samt Weiterleitungsregeln in einem Befehl, deklarative „Stacks“, Berichte. Von einer Einzelperson entwickelt, aber regelmäßig; Release vom April 2026.
• apache/cloudstack-go — das offizielle SDK in Go und das Fundament des restlichen Ökosystems (Terraform-Provider, Kubernetes-Controller), die lebendigste der Bibliotheken. Das archivierte xanzy/go-cloudstack sollten Sie in neuem Code nicht verwenden.
• Apache Libcloud (Python) — wenn der Code zwischen CloudStack und anderen Clouds portabel sein soll. Die Abstraktion verliert allerdings die Besonderheiten der Plattform: Projekte, Domänen, VPC, Offerings.
• Java, PHP, Node.js, .NET — klar gesagt: keine lebenden Clients. Jclouds ist 2025 ins Apache-Archiv gewandert, der Rest steht auf Commits von vor Jahren. Es bleibt ein eigener dünner Client auf der rohen API oder der Aufruf von cmk von außen.
• Terraform und OpenTofu — der Provider cloudstack/cloudstack, stabile Version 0.6.0 vom Oktober 2025 (in ihr sind die Ressourcen für Kubernetes-Cluster erschienen), Kandidat 0.7.0-rc1 vom August 2026 mit der Migration auf das Plugin Framework. Entwickelt unter dem Dach von Apache. Er liest die Konfigurationsdatei von CloudMonkey, was lokal bequem ist — in der CI übergeben Sie die Schlüssel aber über Umgebungsvariablen, statt eine Datei mit Geheimnissen neben den Code zu kopieren.
• Ansible — die Collection ngine_io.cloudstack, nach einem Jahr Stille kräftig aufgefrischt: Release 3.0.0 im Oktober 2025 und drei weitere allein im August 2026. Achtung: In 3.0.0 haben die Module das Präfix cs_ verloren. Es gibt auch das Modul api_request — eine Hintertür für einen beliebigen API-Aufruf ohne Berechnen der Signatur.
• Kubernetes — der Cluster API Provider CloudStack für das deklarative Anlegen von Clustern, der Cloud Controller Manager für Load Balancer und Node-Labels, der CSI-Treiber für persistente Volumes. Letzterer ist ein Community-Projekt und keines der Apache Foundation — anders als apache/cloudstack-go.
• Packer und Vagrant — eine ehrliche Warnung: Das Packer-Plugin steht auf einem Release von 2022, das Vagrant-Plugin ist seit 2019 verwaist. Bauen Sie das Image mit irgendetwas anderem und registrieren Sie es mit dem Befehl register template.
• Pulumi — einen nativen Provider gibt es nicht, und nichts deutet darauf hin; der einzige Weg führt über die Brücke zum Terraform-Provider.

Häufige Fragen

Was ist cmk und wodurch unterscheidet es sich vom alten cloudmonkey? Das sind zwei Generationen desselben Werkzeugs. Das über pip installierte cloudmonkey in Python hat seit dem 13. Oktober 2021 kein Release mehr, und die Paketbeschreibung verweist selbst auf den Nachfolger. cmk ist die Portierung in die Sprache Go, verteilt als einzelne Binärdatei, aktuelle Version 6.5.0. Sie haben getrennte Konfigurationsverzeichnisse (~/.cmk) und können daher koexistieren — neue Installationen machen Sie aber ausschließlich mit cmk.

Woher bekomme ich den API-Schlüssel und den geheimen Schlüssel für WebDisk Cloud? Sie erzeugen sie selbst im Panel von WebDisk Cloud, in den Einstellungen Ihres Benutzers. Dort finden Sie auch die Adresse des API-Endpunkts, die Sie in das cmk-Profil eintragen. Die Schlüssel haben exakt die Berechtigungen, die Ihr Konto hat.

Wie nutzt man cmk in der CI, ohne Schlüssel in einer Datei zu hinterlassen? Halten Sie Schlüssel und Geheimnis in den geschützten und maskierten Variablen Ihres CI-Systems, tragen Sie das Verzeichnis ~/.cmk/ in .gitignore ein und packen Sie es nie in ein Container-Image. Richten Sie für die Automatisierung ein eigenes Konto oder ein eigenes Projekt mit minimaler Rolle ein — ein Schlüssel hat keine engeren Berechtigungen als das Konto, zu dem er gehört. Das Container-Image mit cmk heften Sie an ein konkretes Tag; latest auf Docker Hub ist Jahre alt.

Welche Parameter sind bei deploy virtualmachine verpflichtend? Seit CloudStack 4.21 formal nur serviceofferingid und zoneid — das Template wurde optional, weil sich eine Maschine auch aus einem Volume oder einem Snapshot wiederherstellen lässt. In 4.20 und älter ist templateid Pflicht. In der Praxis geben Sie zusätzlich networkids, name und keypair an. Die endgültige Antwort für Ihre Cloud liefert cmk deploy virtualmachine -h, ausgeführt nach einem vorherigen cmk sync.

Der Befehl hat jobid zurückgegeben und sonst nichts. Was jetzt? Das bedeutet, dass asyncblock bei Ihnen abgeschaltet ist. Fragen Sie den Job mit dem Befehl cmk query asyncjobresult jobid=<UUID> ab und prüfen Sie das Feld jobstatus: 0 heißt Arbeit läuft, 1 Erfolg, 2 Fehler. Das voreingestellte set asyncblock true sorgt dafür, dass cmk für Sie wartet und erst das Ergebnis zeigt; die Obergrenze ist dann set timeout, standardmäßig 1800 Sekunden.

Kann ich über cmk einen Kubernetes-Cluster anlegen? Ja. In WebDisk Cloud ist der Cluster-Dienst verfügbar — das prüfen Sie mit dem Befehl cmk list kubernetessupportedversions, und die Einzelheiten des Angebots beschreibt die Seite Kubernetes. Formal verlangt create kubernetescluster nur name und zoneid, in der Praxis geben Sie aber auch kubernetesversionid, serviceofferingid und size an; die Skalierung ist cmk scale kubernetescluster id=<UUID> size=5. Den Cluster selbst verwalten Sie von innen selbstverständlich über kubectl, deklarativ von außen über die Cluster API. Auf anderen CloudStacks hängt die Verfügbarkeit dieses Dienstes vom Betreiber ab.

curl, cmk, Terraform oder Ansible — wann was? curl nur dann, wenn Sie die Signaturschicht debuggen oder Ihre Sprache keinen lebenden Client hat. cmk für Abfragen, einmalige Operationen und schnelle Skripte. Ansible, wenn Sie Maschinen imperativ in Playbooks konfigurieren. Terraform, wenn die Umgebung im Repository beschrieben und von null reproduzierbar sein soll. Alle vier treffen denselben Endpunkt mit denselben Berechtigungen — Sie wählen die Form der Arbeit, nicht die Zugriffsebene.

Beginnen Sie mit einer einzigen Abfrage

Der billigste erste Schritt ist nicht die Migration von Prozessen in Skripte, sondern ein einziger Befehl: Laden Sie die Binärdatei herunter, prüfen Sie die Prüfsumme, setzen Sie das Profil, machen Sie ein cmk sync und schreiben Sie Ihre Maschinen in eine CSV-Datei. Eine Viertelstunde später wissen Sie, ob das Terminal zu Ihrer Arbeitsweise passt — und das Freitagsfließband verwandelt sich in die Schleife aus diesem Artikel, die man im Repository ansehen und aus einem Zeitplan heraus starten kann. Das Panel bleibt dort, wo es wirklich gut ist: bei der Maschinenkonsole, beim ersten Umsehen und bei Operationen, die Sie einmal machen.

Hinter WebDisk Cloud steht die Mazura sp. z o.o., eine Gesellschaft polnischen Rechts: Die Daten bleiben in Europa, und der Support antwortet auf Polnisch. Wenn Sie die Kosten abschätzen: Die Konfigurationen Cloud PAYG beginnen bei €6 netto monatlich für Small (2 vCPU, 4 GB RAM, 50 GB NVMe und eine öffentliche IP-Adresse) — Stand August 2026, und die Nutzung der gekauften Ressourcen, einschließlich der Bandbreite, berechnen wir nicht zusätzlich. Schreiben Sie uns, wenn Sie ein Automatisierungsszenario besprechen möchten.