Cloud & Cabernet

Beobachtungen über IT und Wein

Fortgeschrittene Azure Policy Techniken #3: Von Endpunkten und Subresourcen

Im dritten Teil dieser Serie möchte ich erklären, wie wir feststellen können, wann eine Azure Richtlinie (Policy) tatsächlich eingesetzt werden kann bzw. eingesetzt werden sollte, um unsere vorgegebenen Ziele zu erreichen.

Zunächst in Erinnerung gerufen: Azure Policy arbeitet, indem es mit der Azure Resource Manager-API (ARM) kommuniziert. Daraus ergibt sich bereits die erste Einschränkung: Möchten wir ein Verhalten regulieren, das nicht über die ARM-API erreichbar ist, scheidet eine Policy als Mittel aus. Dazu zählen zum Beispiel

Fortgeschrittene Azure Policy Techniken #2: Nutzung der requestContext Funktion um spezifische API-Versionen anzusteuern

Im zweiten Beitrag dieser Serie möchte ich Ihnen ein Beispiel dafür zeigen, wie eine Funktion innerhalb einer Richtliniendefinition verwendet wird, um den Geltungsbereich einzuschränken. Basierend auf persönlichen Erfahrungen werden Richtlinienfunktionen oft etwas vernachlässigt, haben jedoch in den letzten Jahren eine erhebliche Weiterentwicklung erfahren. Wie Sie in der offiziellen Dokumentation sehen können, unterstützt Azure Policy eine Vielzahl von Funktionen, darunter:

  • copyIndex()
  • dateTimeAdd()
  • dateTimeFromEpoch
  • dateTimeToEpoch
  • deployment()
  • environment()
  • extensionResourceId()
  • listKeys()
  • listSecrets()
  • reference()
  • resourceId()

Viele dieser Funktionen sind auch für ARM-Vorlagen verfügbar, wie zum Beispiel copyIndex(), listKeys() und resourceId(), und sind sehr praktisch für Operationen, die auf komplexe Bereitstellungen mit mehreren, voneinander abhängigen Ressourcen abzielen. Eine Funktion, die jedoch möglicherweise weniger bekannt ist, nennt sich requestContext().

Fortgeschrittene Azure Policy Techniken #1: Arrays erweitern mittels DINE

Dies ist der erste Beitrag einer Reihe, in der wir einige fortgeschrittenere Azure-Policy-Techniken vorstellen, die nicht allzu häufig im Rampenlicht stehen, aber in bestimmten Situationen äußerst hilfreich sein können.

Ist Ihnen schon aufgefallen, dass bei Verwendung einer DINE-Policy (DeployIfNotExists), um eine Eigenschaft eines bestehenden Ressourcenobjekts zu aktualisieren, und diese Eigenschaft eine Liste (bzw. ein “Array”) ist, die bestehende Liste durch die in der DINE-Policy konfigurierte Liste überschrieben wird? Dieses Verhalten ist logisch, wenn man bedenkt, was eine DINE-Policy eigentlich tun soll — eine Ressource mithilfe einer Vorlage (bzw. eines Templates) aktualisieren.