azure-quickstart-templates: ARM-Vorlagen, Bicep-Regeln und die No-External-Links-Politik
Azure-Schnellstartvorlagen. Um dies zu beheben, verwenden Sie entweder Bicep mit Modulen und Dateifunktionen oder parametrisieren Sie Links zu externen Inhalten.
Auf einen Blick
- Was ist das?
- Das Community-Repository Azure/azure-quickstart-templates unter der Lupe: Vorlagensammlung mit durchsuchbarem Index, strikte Richtlinie gegen externe Links, Beitragsleitfaden und TTK-Releases aus dem Jahr 2019.
- Für wen ist es gedacht?
- Dieses Repository passt für Entwickler, die eine erprobte Ausgangsvorlage für eine Azure-Bereitstellung suchen und bereit sind, ARM- beziehungsweise Bicep-Syntax anzupassen. Wer aktuelle, gepflegte Vorlagen mit erkennbarem Release-Rhythmus sucht, sollte prüfen, ob der azure.com-Index aktuellere Beispiele listet, denn die gelisteten Releases datieren auf 2019.
- Darf ich es kommerziell nutzen?
- Ja. MIT ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 15 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Bicep, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 14. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Azure/azure-quickstart-templates: 14.867 Sterne für ARM-Vorlagen
Das Repository Azure/azure-quickstart-templates sammelt Azure Resource Manager Vorlagen, die von der Community beigesteuert wurden. Laut README enthält es alle derzeit verfügbaren ARM-Vorlagen dieser Art, ein durchsuchbarer Index wird auf azure.com unter documentation/templates gepflegt. Die Metadaten verzeichnen 14.867 Sterne und 16.207 Forks, die Zahl der Forks übersteigt die der Sterne, was für ein Vorlagenarchiv typisch ist, weil Nutzer häufig Kopien für eigene Anpassungen anlegen. Es stehen 990 offene Issues im Raum.
Als Hauptsprache listet die Metadaten Bicep, die deklarative Azure-Sprache für Ressourcenbereitstellungen. Die Lizenz ist MIT, der Standard-Branch heißt master, als Projekt-URL ist die Kurzform aka.ms/azqst eingetragen. Ein Detail verdient Beachtung: Die gelisteten Releases 0.0.0.3 mit dem Namen TTK Dogfood Release und 0.0.0.4 tragen Daten vom Juli respektive Oktober 2019, das Release marketplace enthält TTK-Skripte zur Vorlagenvalidierung. Das aktuelle README ist gegenüber diesen Releases auffällig schmal, was die Frage aufwirft, wo sich Nutzer über Struktur und Gebrauch der Sammlung informieren müssen.
TTK-Releases von 2019: Validierungsskripte und sparsames README
Die README selbst beschreibt keine Bereitstellungsbefehle, keine Verzeichnisstruktur und keinen Release-Zyklus. Sie verweist für Nutzung und Beiträge allein auf den Beitragsleitfaden unter 1-CONTRIBUTION-GUIDE/README.md. Wer wissen will, wie eine Vorlage eingesetzt oder eingereicht wird, kommt um dieses Dokument nicht herum, es ist die einzige im README genannte Referenz für solche Fragen.
Die Releases erzählen eine eigene Geschichte. Das Release marketplace vom Juli 2019 nennt TTK-Skripte zur Vorlagenvalidierung für den Marketplace, TTK steht hier für die Toolchain, mit der Vorlagen geprüft werden. Ein späteres Release 0.0.0.4 verweist mit dem Namen Updates and Bug Fixes see PRs ausdrücklich auf Pull Requests als Änderungsprotokoll. Die Metadaten zeigen einen letzten Push vom 31. Oktober 2019, während der Index auf azure.com als lebendige Suche positioniert wird. Wer die Sammlung produktiv nutzt, sollte also den GitHub-Stand nicht mit dem Stand des Webindex verwechseln.
No External Links: warum PRs mit S3-Buckets abgelehnt werden
Die markanteste Regel des Repositories ist die Policy No External Links. Beiträge und bestehende Beispiele, die Links auf nicht von Microsoft kontrollierte Ressourcen enthalten, werden abgelehnt beziehungsweise entfernt. Als Begründung nennt das README das Risiko von Domain-Spoofing oder einer feindlichen Übernahme solcher Ziele. Ausdrücklich genannt als Beispiele sind S3-Buckets, Azure-Speicherkonten, die nicht Microsoft gehören, und Git-Repositories außerhalb von Azure.
Für ARM-Vorlagen ist das ein reales Problem: Eine Vorlage, die Skripte oder Binärdateien von einem fremden Speicherort nachlädt, wird zur Angriffsfläche, sobald dieser Speicherort den Besitzer wechselt. Die Policy zwingt Beitragende also, Bereitstellungen ohne solche Abhängigkeiten zu bauen. Das macht die Vorlagen langfristig reproduzierbarer, auch wenn es den Aufwand für einfache Beispiele erhöht, die bisweilen tatsächlich ein fremdes Asset gebraucht hätten.
Bicep-Module und file functions als vorgesehene Lösung
Für die Frage, wie man den Verzicht auf externe Links praktisch löst, nennt das README zwei Wege. Der erste ist Bicep mit modules und file functions, also die Modularisierung der Vorlage und das Einbinden von Inhalten aus Dateien, die im Repository selbst liegen. Der zweite Weg ist das Parametrisieren von Links auf externe Inhalte, sodass der Nutzer den Speicherort erst zur Bereitstellungszeit angibt.
Diese Empfehlung passt zur Hauptsprache der Metadaten. Bicep-Module erlauben es, gemeinsame Bausteine auszulagern und innerhalb des Repositories zu referenzieren, File-Funktionen laden Dateiinhalte zur Kompilierungszeit ein. Wer eine Vorlage aus dem Index anpasst, findet damit das Muster vor, in dem die Community Abhängigkeiten handhabt. Verweise außerhalb der Microsoft-Kontrolle sind dort nach dieser Policy schlicht nicht Teil akzeptierter Beispiele.
Beitragen über 1-CONTRIBUTION-GUIDE und den Code of Conduct
Alle Hinweise zum Einreichen laufen auf den Beitragsleitfaden im Verzeichnis 1-CONTRIBUTION-GUIDE hinaus, das README wiederholt keine seiner Regeln an anderer Stelle. Das Projekt hat den Microsoft Open Source Code of Conduct übernommen, für Fragen nennt die README die Adresse opencode@microsoft.com sowie eine FAQ-Seite zum Kodex. Über Durchsetzungsmechanismen jenseits des Kodex sagt die README nichts.
Für einen Beitragenden ergibt sich damit eine klare Reihenfolge: Zuerst die Policy No External Links prüfen, dann die im Leitfaden beschriebene Vorlagenstruktur befolgen, schließlich mit den TTK-Skripten aus dem marketplace-Release eine Validierung vorbereiten. Die 990 offenen Issues zeigen, dass Rückfragen und Probleme im Repositorium landen, einen separaten Supportweg nennt die README nicht.
MIT-Lizenz und der Stand der Metadaten: was Nutzer wissen müssen
Die MIT-Lizenz erlaubt Nutzung, Kopieren, Änderung und Weiterverbreitung der Vorlagen, kommerzielle Nutzung eingeschlossen, bei Namensnennung des Urheberrechtsvermerks. Die Software wird ohne Gewährleistung bereitgestellt, jede Vorlage sollte also vor produktivem Einsatz geprüft werden, insbesondere bei Ressourcen mit Kostenrelevanz wie Skalierungsgruppen oder Netzwerkkomponenten.
Zum Zustand der Sammlung liefern die Metadaten die wichtigsten Anhaltspunkte: nicht archiviert, Standard-Branch master, letzte Push-Aktivität zum Stichtag der Metadaten im Oktober 2019, Hauptsprache Bicep. Der nicht archivierte Status bedeutet, dass Beiträge grundsätzlich weiter möglich sind, über die tatsächliche Pflegefrequenz sagt das aber nichts. Wer eine Vorlage für eine aktuelle Azure-Region oder ein neues Ressourcen-Feature braucht, sollte im azure.com-Index nachsehen, ob ein neueres Beispiel existiert, und sonst auf eigene Anpassung der hier liegenden Fassung setzen.
Redaktionelles Fazit
Dieses Repository passt für Entwickler, die eine erprobte Ausgangsvorlage für eine Azure-Bereitstellung suchen und bereit sind, ARM- beziehungsweise Bicep-Syntax anzupassen. Wer aktuelle, gepflegte Vorlagen mit erkennbarem Release-Rhythmus sucht, sollte prüfen, ob der azure.com-Index aktuellere Beispiele listet, denn die gelisteten Releases datieren auf 2019. Vor der Übernahme einer Vorlage lohnt der Blick in 1-CONTRIBUTION-GUIDE/README.md und ein Testlauf der eigenen Parameterdatei.
Community-Notizen