In meinen letzten zwei Projekten durfte ich die Azure-Infrastrukturen unserer Kunden weiterentwicklen. In beiden Fällen wurde die Infrastruktur in der Azure UI zusammengestellt.
Bei einem Projekt ging es darum, die gesamte Konfiguration als Code zu definieren. Beim anderen ging es um eine Optimierung des Networkings, allerdings ohne «Infrastructure as Code».
In beiden Fällen gibt es drei Umgebungen: DEV, TEST, PROD. In beiden Fällen ist der Code auf Azure DevOps gehostet. Die CI/CD-Pipelines laufen ebenfalls über Azure DevOps.
In diesem Beitrag möchte ich diese beiden Erfahrungen vergleichen und dabei das Prinzip «Infrastructure as Code» beurteilen. Welchen Nutzen hat es für unsere Kunden respektive für Tech-Teams? Wie hoch sind die Kosten?
Azure (und andere Cloud-Anbieter) bieten viel. Oft wirken die Services einfach, doch häufig dauert die Implementierung länger als angenommen. Vor allem dann, wenn man Einstellungen anpassen möchte, also der Standard nicht gut genug ist.
In der UI kann man schnell Ressourcen hochfahren und miteinander kombinieren. Die Iterations-Geschwindigkeit ist akzeptabel, jedoch muss auf den Abschluss der Deployments gewartet werden. Jedenfalls ist das Feedback einigermassen unmittelbar.
Man muss häufig experimentieren, bis das gewünschte Verhalten beobachtbar ist. Wenn es am Ende funktioniert, muss man ggf. die Schritte dokumentieren (z.B. auf Confluence oder in einem README, manchmal lokal in seinen eigenen Notizen) — oder sich zumindest gut daran erinnern. Schliesslich plant man die Umsetzung auf den höheren Umgebungen (TEST und PROD). Bei der Umsetzung arbeitet man einen Change nach dem anderen ab. Häufig gibt es Abhängigkeiten zwischen den Ressourcen. Werte von der einen Ressource muss man kopieren und bei der Erstellung der nächsten Ressource einfügen.
Bei Infrastructure as Code (IaC) ist es ebenfalls möglich zunächst über die UI zu experimentieren, bis man weiss, wie die verschiedenen Ressourcen zusammenspielen. Wenn man eine Konfiguration gefunden hat, die funktioniert, definiert man sie schliesslich als Code.
Die Cloud-Anbieter machen ihre Funktionalität via API verfügbar. Ein IaC-Tool wie Terraform oder Pulumi bietet ein einfacheres Interface zur Umfangreicheren Cloud-API.
Es folgen zwei Beispiele, eins in Terraform, das andere in Pulumi, die ein Gefühl von IaC vermitteln sollen.
Terraform
Eine der bekanntesten «Infrastructure as Code»-Technologien ist Terraform. Terraform verwendet eine eigene Konfigurationssprache: HCL — Hashicorp Configuration Language. Sie ist vergleichbar mit YAML oder JSON, bietet aber auch Konstrukte aus Programmiersprachen an wie Loops oder If-Else-Controlflows.
Hier ist ein Beispiel von Terraform Code:
resource "random_password" "postgres_password" {
length = 21
special = true
}
resource "azurerm_postgresql_flexible_server" "main" {
resource_group_name = azurerm_resource_group.main.name
location = azurerm_resource_group.main.location
name = "workid--psql--${var.env_token}"
zone = "1"
administrator_login = "postgres"
administrator_password = random_password.postgres_password.result
sku_name = var.postgres_flexible_server_sku
create_mode = "Default"
version = "16"
public_network_access_enabled = false
delegated_subnet_id = azurerm_subnet.postgres.id
private_dns_zone_id = azurerm_private_dns_zone.postgres.id
storage_mb = 32768
storage_tier = "P30"
depends_on = [azurerm_private_dns_zone_virtual_network_link.postgres]
}
resource "azurerm_subnet" "postgres" {
resource_group_name = azurerm_resource_group.main.name
name = "workid--snet-psql--${var.env_token}"
virtual_network_name = azurerm_virtual_network.main.name
address_prefixes = ["10.0.2.0/24"]
service_endpoints = ["Microsoft.Storage"]
delegation {
name = "fs"
service_delegation {
name = "Microsoft.DBforPostgreSQL/flexibleServers"
actions = [
"Microsoft.Network/virtualNetworks/subnets/join/action",
]
}
}
}
data "azurerm_key_vault" "global" {
name = "kunde"
resource_group_name = "kunde--rg-super--global"
}
resource "azurerm_key_vault_secret" "db_pw" {
name = "${var.env_token}--postgres--admin-password"
value = random_password.postgres_password.result
key_vault_id = data.azurerm_key_vault.global.id
}
Im Beispiel erkennt man: Was man in der UI in das entsprechende Formular-Feld eintragen würde, definiert man in Terraform als Property. Anstatt einen Wert in die Maske einzugeben, definiert man den Wert im Text.
Dabei kann man Konstrukte verwenden, die die UI nicht anbietet. Im Beispiel oben wird ein random-Passwort erstellt und dann gleich übergeben. (administrator_password = random_passwort.postgres_password.result)
Pulumi
Pulumi, ein weiteres Tool für Infrastructure as Code, bietet die Definition der Ressourcen in Programmiersprachen an, beispielsweise in Go, C#, Python, oder TypeScript. Das hat den Vorteil, das man sein gewohntes Umfeld nutzen kann, und z.B. für Control Flow keine neue Syntax lernen muss.
Ein Pulumi-Beispiel in C# aus den Docs:
using System.Collections.Generic;
using System.Linq;
using Pulumi;
using Azure = Pulumi.Azure;
return await Deployment.RunAsync(() =>
{
var example = new Azure.Core.ResourceGroup("example", new()
{
Name = "example-resources",
Location = "West Europe",
});
var exampleFlexibleServer = new Azure.PostgreSql.FlexibleServer("example", new()
{
Name = "example-psqlflexibleserver",
ResourceGroupName = example.Name,
Location = example.Location,
Version = "12",
AdministratorLogin = "psqladmin",
AdministratorPassword = "H@Sh1CoR3!",
StorageMb = 32768,
SkuName = "GP_Standard_D4s_v3",
});
var exampleFlexibleServerConfiguration = new Azure.PostgreSql.FlexibleServerConfiguration("example", new()
{
Name = "backslash_quote",
ServerId = exampleFlexibleServer.Id,
Value = "on",
});
});
Infrastructure as Code bietet viel, doch wie viele Engineering-Entscheidungen, soll man Kosten und Nutzen abwägen. Die folgende Auflistung von Vor- und Nachteilen soll bei dieser Einschätzung helfen.
Values von anderen Ressourcen oder Variabeln verwenden.
Mit Infrastructure as Code kann man Werte von anderen Ressourcen verwenden und muss sie nicht von Hand kopieren und in ein Web-Formular einfüllen.
Konkrete Instanzen vom Terraform-Beispiel oben:
Die Dokumentation erfolgt bereits im Code.
Wenn man die Syntax versteht und sich im Code navigieren kann, dient der Code als Dokumentation. Dabei kann es viel übersichtlicher sein, eine Cloud-Architektur zu erfassen. Code-Editoren bieten darüber hinaus Tools, um die Navigation zu vereinfachen.
Einzelne Umgebungen sind leicht zu verwalten.
Mit Modulen und Variabeln kann man in unterschiedlichen Umgebungen gut verwalten. Man kann gleich lassen, was gleich sein soll, und ändern, was anders sein soll.
Das folgende Beispiel zeigt, wie das Backend von DEV weder ein Application Gateway noch eine Web Application Firewall verwendet, PROD aber schon:
# dev:
module "backend" {
source = "../../modules/backend/"
resource_group_name = "kunde--rg-main--dev"
env_token = "dev"
use_application_gateway = false
use_web_application_firewall = false
enable_basic_auth_for_ui = true
}
# prod:
module "backend" {
source = "../../modules/backend/"
resource_group_name = "kunde--rg-main--prod"
env_token = "prod"
use_application_gateway = true
use_web_application_firewall = true
enable_basic_auth_for_ui = false
}
Informationen von den Ressourcen können automatisiert der Applikation überreicht werden.
Im Beispiel unten werden die DB-Connection-Strings direkt an die Azure App Service via App configuration übergeben. So müssen die Passwörter nie mehr in der DevOps-Pipeline oder sonst wo gemanaged werden, und auch nicht mehr individuell für einzelne Umgebungen.
resource "azurerm_linux_web_app" "main" {
resource_group_name = azurerm_resource_group.main.name
location = azurerm_resource_group.main.location
name = "webapp--app-backend--${var.env_token}"
service_plan_id = azurerm_service_plan.main.id
public_network_access_enabled = var.use_application_gateway ? false : true
https_only = var.use_application_gateway ? false : true
virtual_network_subnet_id = azurerm_subnet.app.id
app_settings = merge(local.app_settings, var.additional_app_settings)
...
}
locals {
db_addr = azurerm_postgresql_flexible_server.main.fqdn
db_pw = random_password.postgres_password.result
db_user = azurerm_postgresql_flexible_server.main.administrator_login
app_settings = {
WEBSITES_PORT = 8080
ConnectionStrings__SkillsManagerDatabase = join(";", [
"Server=${local.db_addr}",
"Database=webapp",
"Port=5432",
"User Id=${local.db_user}",
"Password=${local.db_pw}",
"Ssl Mode=Require;",
])
AllowedOriginsSplittable = join(";", [
"https://${azurerm_static_web_app.main.default_host_name}",
"https://${var.dns_zone_webapp}",
"https://api.${var.dns_zone_webapp}",
])
}
}
Wiederverwendbarkeit und Fast Recovery.
Eine Umgebung mit 40 verschiedenen Ressourcen kann man ganz leicht per terraform deploy ausrollen. Von Hand würde das vermutlich mehrere Tage dauern.
Minimale Downtimes.
Wenn Änderungen auf der DEV eingerichtet sind, kann man sie mit einem einzigen Kommando auf PROD ausrollen. Das führt zur geringsten möglichen Downtime.
Tooling und Security Scanning. Tools wie Terraform oder Pulumi sind open-source. Sie haben eine riesige Community. Entsprechend gibt es viele Tools, die die Arbeit erleichtern. Ausserdem können Security-Scanner eingebunden werden, die den Code analysieren. So können unnötige Risiken früh erkannt und vermieden werden.
Viel zusätzliches Know-how erforderlich.
Es ist schon schwierig genug, das erforderliche Azure Know-how aufzubauen oder anzuwenden. Wenn das Backend mit der Datenbank über das interne Netzwerk kommunizieren soll, sind einige Änderungen notwendig (z.B. VNet integrations, Subnet-Einstellungen mit Delegations, Private Endpoints, usw.). Wenn man in seinen Tech-Stack IaC-Technologien einführt, müssen bereits Grundkenntnisse mit der Kommando-Zeile vorhanden sein sowie eine neue Sprache lernen.
Nicht zu unterschätzen ist auch, dass die Komplexität im System zunimmt.
Man muss sich auskennen, um von der Dokumentation profitieren zu können.
Nicht jedes Mitglied des Teams arbeitet mit Programm-Codes. Während es für einen Entwickler übersichtlich ist, kann es für viele schwierig sein den Code zu verstehen oder die Infrastruktur als Ganzes zu erfassen.
Die Iterationsgeschwindigkeit verlangsamt sich.
Es reicht nicht mehr, die Änderungen einfach vorzunehmen. Man muss den Code schreiben, reviewen, dann ausrollen, was entsprechend Zeit benötigt.
Es gibt keine UI, die Vorschläge macht.
Die Dokumentation von Terraform ist sehr gut und umfangreich, aber deckt auch nicht alles ab. Die Azure UI macht Vorschläge oder bietet Drop-Downs an. Bei Terraform muss man häufig nachschlagen oder ausprobieren.
Infrastructure as Code (IaC) bringt klare Vorteile in Bezug auf Wiederverwendbarkeit, Nachvollziehbarkeit und Automatisierung – insbesondere bei komplexen Infrastrukturen mit mehreren Umgebungen wie DEV, TEST und PROD. Im Vergleich zum manuellen Aufbau über die Azure UI erlaubt IaC eine präzisere Kontrolle, konsistentere Deployments und eine effektivere Verwaltung von Abhängigkeiten und Konfigurationen. Gerade bei Teams mit hohem technischem Reifegrad und langfristigen Projekten lohnt sich der Mehraufwand.
Allerdings ist der Einstieg nicht trivial: IaC erfordert tiefgreifendes technisches Know-how, ein gutes Verständnis der Cloud-Architektur sowie Vertrautheit mit Kommandozeile und Code. Auch die Entwicklungszyklen können sich durch Review- und Testprozesse verlängern. Für kleinere Projekte oder schnelle Prototypen kann der Weg über die Azure UI daher effizienter sein.
Kurz gesagt: Wer bereit ist, in das Know-how zu investieren, wird mit höherer Skalierbarkeit, Stabilität und Transparenz belohnt – für Teams mit begrenzten Ressourcen oder geringer IaC-Erfahrung bleibt die UI eine praktikable Alternative.
Schreiben Sie einen Kommentar