Azure Standard Test Deployments (Teil 2)

Im ersten Teil der Serie haben wir die Namenskonventionen definiert für alle Ressourcen, die wir erzeugen wollen. Im zweiten Teil (diesem hier) werden wir die Ressourcengruppe, das VNet und die NSG anlegen.

Dies ist der zweite von fünf Artikeln zu diesem Thema. Die anderen sind:

  • Teil 1 legt die Namenskonvention fest.
  • Teil 2 (dieser hier) behandelt Ressourcengruppe, VNet und NSG
  • Teil 3 handelt von der VM und zugehörigen Ressourcen
  • Teil 4 fasst das alles in einem PowerShell Skript zusammen
  • Teil 5 macht noch ein paar Bemerkungen dazu.

Anlegen der Ressourcengruppe

Wie wir in Teil 1 gesehen haben, leitet sich der Name für Netzwerk und Sicherheitsgruppe vom Namen der Ressourcengruppe ab. Und wir denken auch noch daran, dass der Name auch irgendwie sinnvoll und „sprechend“ sein soll, oder?

Ob man das jetzt mit PowerShell oder CLI macht, ist eigentlich egal, ich bevorzuge PowerShell, daher die weiteren Beispiele damit. Wir fangen an, einen PowerShell Script zu schreiben, den wir nach und nach ausbauen werden. Zuerst ganz einfach:

Param(
    [parameter(mandatory=$true)][string]$resourcegroup
)

$to_be_deleted="{0:ddMMyyyy}" -f (get-date).AddDays(7)
$default_tags= @{"delete"=$to_be_deleted}

New-AzResourceGroup -Name $resourcegroup -Location northeurope -Tags $default_tags

Meine Demos liegen immer in der selben Location, daher ist das kein Parameter, den ich irgendwie übergeben müsste. Alle folgenden Templates verwenden für die jeweiligen Ressourcen einfach die gleiche Region wie die der Ressourcengruppe. Wir wollten es einfach haben, wir erinnern uns?

Wir hatten schon im ersten Teil besprochen, dass Tags ganz sinnvoll sind. Ich erzeuge hier zuerst einen String mit dem Datum von heute +7 Tagen. Die nächste Zeile baut die Hashtable für den Tag, und beim Erstellen der Gruppe geben wir diesen Tag mit an. Warum? Hatte ich in ersten Teil schon erklärt: Ab und zu läuft einfach ein Script durch meine Ressourcengruppen und löscht alle mit dem Tag „delete“ und einem überschrittenen Verfallsdatum…

Der Scriptaufruf wäre dann:

deploy-test.ps1 -resourcegroup blogdemo

Netzwerk und Security Group

Aus Gründen der Wiederverwendbarkeit hatten wir uns im ersten Teil auf Templates geeinigt (naja, ich hatte mich geeinigt…). Gehen wir mal das JSON Template für VNet und NSG durch.

Wir benötigen keine Parameter, sowohl VNet als auch NSG sind nur vom Namen der Ressourcengruppe abhängig. Damit vereinfacht sich der Parameter-Block drastisch, und es bleibt nur noch der Variablen-Block übrig. Hier folgen wir der Namenskonvention aus Teil 1 und erzeugen die Ressourcennamen:

{
    "$schema": "http://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
    },
    "variables": {
        "location": "[resourceGroup().location]",
        "nsgName":  "[concat(resourceGroup().name,'nsg1')]",
        "vnetName": "[concat(resourceGroup().name,'vnet1')]",
        "subnetName": "[concat(resourceGroup().name,'vnet1sub1')]",

        "nsgId":  "[resourceId(resourceGroup().name, 'Microsoft.Network/networkSecurityGroups', variables('nsgName'))]",

        "addressPrefix": "10.0.0.0/16",
        "subnetPrefix": "10.0.0.0/24"
    },

Alles klar soweit? In Zeile 7 übernehmen wir die Region der Gruppe, in den Zeilen 8-10 bauen wir die Namen zusammen. Wer andere Netzadressen bevorzugt, der muss sie hier in Zeile 14 und 15 ändern.

Nun zu den Ressourcen selbst. Zuerst die NSG:

    "resources": [
        {   "type": "Microsoft.Network/networkSecurityGroups",
            "name": "[variables('nsgName')]",
            "apiVersion": "2018-08-01",
            "location": "[variables('location')]",
            "properties": {
                "securityRules": [
                    {
                        "name": "all-in-from-home",
                        "properties": {
                            "description": "needs modification by script",
                            "protocol": "Tcp",
                            "sourcePortRange": "*",
                            "destinationPortRange": "*",
                            "sourceAddressPrefix": "127.0.0.1/32",
                            "destinationAddressPrefix": "*",
                            "access": "Allow",
                            "priority": 100,
                            "direction": "Inbound"
                        }
                    }
                ]
            }
        },

Die sieht auf den ersten Blick etwas merkwürdig aus, zugegeben. Die einzige erlaubte Adresse (Zeile 31) ist die 127.0.0.1. Ich verwende immer einen weiteren PowerShell Script, um diese Regel „all-in-from-home“ zu modifizieren und setze dort meine eigene aktuelle IP-Adresse als „SourceAddressPrefix“ rein. Standardmäßig (also direkt nach dem Deployment) ist aber erst mal keine Verbindung möglich. Wer das anders haben möchte, zum Beispiel weil man über eine feste IP-Adresse verfügt, oder weil man nur einzelne Ports freigeben möchte, hier ist die Stelle für die Anpassungen.

Als nächstes noch das VNet und der Rest des Templates:

        {   "type": "Microsoft.Network/virtualNetworks",
            "apiVersion": "2018-10-01",
            "name": "[variables('vnetName')]",
            "location": "[variables('location')]",
            "dependsOn": ["[concat('Microsoft.Network/networkSecurityGroups/', variables('nsgName'))]"],
            "properties": {
                "addressSpace": {
                    "addressPrefixes": [
                        "[variables('addressPrefix')]"
                    ]
                },
                "subnets": [
                    {
                        "name": "[variables('subnetName')]",
                        "properties": {
                            "addressPrefix": "[variables('subnetPrefix')]",
                            "networkSecurityGroup": {
                                "id": "[variables('nsgId')]"
                            }
                        }
                    }
                ]
            }
        }
    ],
    "outputs": {
    }
}

Durch das „dependsOn“ in Zeile 45 wird automatisch zuerst die NSG angelegt, dann folgt das Vnet und das Subnet und dort dann die Bindung der NSG an das Subnet.

Das war es auch schon. Wer mehrere Subnets haben möchte, der kann den Teil zwischen Zeile 53 und 61 duplizieren und entsprechende Variablen definieren. Oder natürlich mit count arbeiten.

Fahren wir mal fort mit dem Anlegen der restlichen Ressourcen im nächsten Teil…

4 Kommentare zu „Azure Standard Test Deployments (Teil 2)

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Google Foto

Du kommentierst mit Deinem Google-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s