Azure CLI im Detail: az-Befehle, Exit-Codes und Telemetrie-Kontrolle

Azure/azure-cli: was hinter den 4.612 Sternen steckt

Das Repository Azure/azure-cli hostet Microsofts Befehlszeilenwerkzeug für Azure. Die Metadaten zeigen 4.612 Sterne, 3.469 Forks und 4.013 offene Issues, ein Umfang, der auf ein großes Nutzerfeld mit entsprechend vielen gemeldeten Problemen hindeutet. Die Codebasis ist überwiegend in Python geschrieben, steht unter der MIT-Lizenz und wird auf dem Standard-Branch dev gepflegt. Ein Stand vom 12. August 2026 zeigt die Version azure-cli-2.89.1 als aktuelle Veröffentlichung.

Das README positioniert das Werkzeug als plattformübergreifende Erfahrung der nächsten Generation und verweist für einen ersten Test auf Azure Cloud Shell im Portal. Wer es lokal betreibt, findet einen eigenen Abschnitt zur Entwicklerinstallation, zu Docker-Images und zu Edge-Builds. Diese drei Wege laufen parallel zum regulären Installationsleitfaden und richten sich an ein anderes Publikum als der Standardpfad.

az-Befehle aufbauen: Syntax, -h und Ausgabeformate

Die Grundform eines Aufrufs lautet az [ group ] [ subgroup ] [ command ] {parameters}. Hilfe gibt es über den Parameter -h, etwa mit az storage -h oder az vm create -h. Das README empfiehlt diesen Weg ausdrücklich, bevor man in die Online-Dokumentation abwandert, weil die Hilfe direkt die Parameter des installierten Release zeigt.

Standardmäßig gibt die CLI Daten im Tabellenformat aus. Mit az configure lässt sich ein anderes Voreinstellungsformat festlegen, json, table oder tsv stehen zur Auswahl. Für Skripte ist tsv der übliche Kandidat, weil es Klartextfelder ohne Dekoration liefert. Die offizielle Seite zu effektiver Nutzung behandelt zusätzlich das Weiterreichen von Werten zwischen Befehlen, asynchrone Vorgänge und Anführungszeichen-Probleme, die unter PowerShell und Bash unterschiedliche Quoting-Regeln haben.

--query mit JMESPath:_vm-Listen filtern wie in az vm list

Der Parameter --query akzeptiert JMESPath-Syntax und filtert die Ausgabe clientseitig. Das README zeigt ein Beispiel: az vm list --query "[?provisioningState=='Succeeded'].{ name: name, os: storageProfile.osDisk.osType }" liefert nur VMs mit erfolgreichem Provisioning und reduziert sie auf Name und Betriebssystemtyp. Statt ganze JSON-Bäume zu parsen, schneidet die Abfrage die Daten also schon in der CLI zurecht.

Kombiniert mit Tab-Vervollständigung ergibt sich ein akzeptabler Arbeitsfluss. Die Vervollständigung kennt Gruppen, Befehle und einige Parameter. Im README-Beispiel listet az vm show -g [tab][tab] die Ressourcengruppen AccountingGroup, RGOne und WebPropertiesRG auf, ein weiteres [tab][tab] nach -n zeigt dann die VM-Namen der gewählten Gruppe. Das spart Nachschlagen von Namen, setzt aber eine konfigurierte Shell-Integration voraus, deren Einrichtung im Installationsleitfaden beschrieben ist.

Exit-Codes 0 bis 3: was az-Skripte vom Raten abhält

Für Automatisierung dokumentiert das README vier Exit-Codes. Code 0 heißt Erfolg, Code 1 deckt allgemeine Fehler ab, etwa einen schlechten Statuscode vom Server oder eine fehlgeschlagene CLI-Validierung. Code 2 signalisiert einen Parserfehler, die Eingabe auf der Befehlszeile war also ungeeignet. Code 3 markiert eine fehlende ARM-Ressource und wird von show-Befehlen für Existenzprüfungen verwendet.

Diese Trennung hat praktischen Wert: Ein Skript kann mit if az vm show ...; then zwischen existenter Ressource und fehlgeschlagenem Aufruf unterscheiden, ohne die Ausgabe zu parsen. Wer bislang nur auf 0 oder 1 prüft, verpasst den Fall, dass eine Ressource nicht existiert, statt dass der Befehl falsch war. Das steht im README klar beschrieben und lässt sich mit zwei Zeilen Shell verifizieren.

az rest und az resource: die generischen Befehle jenseits der Dienste

Neben den dienstspezifischen Befehlsgruppen nennt der Leitfaden zur effektiven Nutzung zwei generische Bausteine. az resource erlaubt Operationen auf beliebigen ARM-Ressourcen, ohne dass für jeden Typ eine eigene Befehlsgruppe existiert. az rest schickt direkte REST-Aufrufe an die Azure-Verwaltungs-API und übernimmt dabei Authentifizierung und Tenant-Kontext der angemeldeten Sitzung.

Damit lässt sich abdecken, was die CLI noch nicht als eigenen Befehl anbietet, etwa neu veröffentlichte API-Features. Wer az rest nutzt, muss allerdings die REST-Dokumentation selbst lesen, die CLI fügt hier keine Komfortschicht hinzu. Die Kombination beider Befehle ist der typische Ausweg, wenn ein Ressourcentyp in der installierten Version noch unvollständig abgebildet ist.

Telemetrie: az config set core.collect_telemetry=no setzt nach

Das README erklärt in einem eigenen Abschnitt zur Datenerfassung, dass die Software Nutzungsinformationen an Microsoft senden kann. Telemetrie ist standardmäßig eingeschaltet. Deaktivieren lässt sie sich mit az config set core.collect_telemetry=no, ein Konfigurationsschlüssel, der im Repository dokumentiert ist. Die Datenschutzerklärung von Microsoft ist verlinkt.

Zwei Punkte verdienen Aufmerksamkeit. Erstens gilt die Einstellung pro Umgebung, sie sollte also in automatisierte Setup-Skripte aufgenommen werden, wenn Compliance das verlangt. Zweitens weist das README darauf hin, dass einige Features Daten von Nutzern eigener Anwendungen sammeln können; wer solche Features einsetzt, muss rechtliche Hinweispflichten gegenüber seinen eigenen Nutzern erfüllen. Diese Verpflichtung liegt beim Anwender, nicht bei der CLI.

Edge-Builds aus dem dev-Branch: mcr.microsoft.com/azure-cli und pip

Wer Fehlerkorrekturen testen will, bevor sie in ein Release wandern, findet drei Wege. Das Docker-Image mcr.microsoft.com/azure-cli:<version> läuft mit dem Befehl docker run -u $(id -u):$(id -g) -v ${HOME}:/home/az -e HOME=/home/az --rm -it mcr.microsoft.com/azure-cli:<version> unter der eigenen Benutzerkennung. Edge-Builds aus dem dev-Branch stehen als MSI für Windows, als Homebrew-Formel, als Ubuntu-deb-Pakete und als RPM für RHEL 8 oder CentOS Stream 8 bereit.

Jeder Pull Request, der über Azure DevOps Pipelines nach dev gemerged wird, erzeugt einen solchen Edge-Build. Alternativ beschreibt das README eine pip-Installation in einer virtuellen Umgebung für Entwickler, die am Code selbst arbeiten. Fehlermeldungen gehören in den Issues-Bereich des Repos, von der Befehlszeile aus nimmt az feedback Rückmeldungen entgegen. Die VS-Code-Erweiterung Azure CLI Tools rundet das Bild ab: Sie erkennt .azcli-Dateien und bietet IntelliSense, Snippets, Ausführung im integrierten Terminal sowie eine Statusleiste mit aktuellem Abonnement.

Redaktionelles Fazit

Azure CLI passt für Teams, die Azure-Ressourcen über Skripte und Pipelines verwalten und dabei JMESPath-Abfragen sowie dokumentierte Exit-Codes nutzen wollen. Wer nur gelegentlich Ressourcen prüft, kommt mit dem Portal oder Cloud Shell schneller ans Ziel. Vor dem Rollout lohnt ein Test von az vm show mit --query und eine Prüfung, ob Exit-Code 3 für Existenzprüfungen in den eigenen Skripten berücksichtigt ist.

Offizielle Quellen

1. Official README
2. Project repository
3. Release notes