AKS einrichten und Jira mit Terraform in einem bestehenden Subnetz installieren

Am Ende dieses Blogbeitrags könnt ihr eine Jira-Instanz auf einem AKS-Cluster bereitstellen, der in einem bereits vorhandenen Subnetz in Azure eingerichtet ist.

Verwendete Tools und Tech-Stack

Jedes Tool spielt eine entscheidende Rolle bei der Verwaltung unterschiedlicher Aspekte des Deployment-Prozesses:

1. Bash, Terraform CLI, Helm CLI, Azure CLI, Visual Studio Code<br>Bash automatisiert Aufgaben, Terraform CLI stellt Infrastruktur bereit, Helm CLI deployt Jira auf Kubernetes, Azure CLI verwaltet Azure-Ressourcen und Visual Studio Code unterstützt bei der Bearbeitung von Skripten und Charts.

2. Terraform<br>Stellt Infrastruktur bereit und konfiguriert sie.

3. Azure<br>Stellt die Cloud-Ressourcen bereit.

4. Helm<br>Deployt und verwaltet Jira auf Kubernetes.

5. Jira<br>Bietet Funktionen für Projektmanagement und Issue-Tracking.

Wie sieht der Zielzustand aus?

Das Einrichten eines Azure Kubernetes Service (AKS)-Clusters ist recht unkompliziert. Mit nur wenigen Befehlszeilen in der Azure CLI ist er schnell erstellt. Sobald jedoch Konfigurationen wie Netzwerkeinstellungen oder verschiedene verwaltete Identitäten hinzukommen, wird es komplexer.

In diesem Praxisbeispiel erstellen wir in Azure einen AKS-Cluster mit einer Datenbank für Jira. Die Subnetze und die verwaltete Identität existieren jedoch bereits. Wahrscheinlich werdet ihr mit einem ähnlichen Szenario konfrontiert, da euer Team oder Kunde vermutlich über eine Infrastruktur mit einem bestimmten IP-Bereich und weiteren Anforderungen verfügt, in die der AKS-Cluster integriert werden soll.

Technisch bedeutet die Integration von AKS in ein bestehendes virtuelles Netzwerk (VNet), die Reihenfolge bei der Erstellung der Komponenten anzupassen und der verwalteten Identität vorab bestimmte Berechtigungen zu erteilen, damit das Terraform-Skript erfolgreich ausgeführt werden kann.

Unser Ziel ist es, so viel wie möglich zu automatisieren. Deshalb deployen und verwalten wir unsere Infrastruktur als Infrastructure as Code (IaC). Das hilft uns, die Live-Umgebung mit unserer Konfiguration abzugleichen und Abweichungen zu vermeiden. Daher erstellen wir alle Infrastrukturkomponenten mit Terraform.

Architektur

Die Komponenten der Ressourcengruppe rg-jira-fw01 auf der linken Seite sind bereits vorhanden.

Um unsere Ressourcen zu organisieren und Zugriffe zu verwalten, verwenden wir drei Ressourcengruppen: eine für AKS, eine für das Application Gateway und eine weitere für dessen Komponenten. Das Terraform-Skript deployt einen Node Pool mit zwei Nodes im bereits vorhandenen AKS-Subnetz, einen MSSQL-Server mit zwei Datenbanken (Jira und EazyBI) sowie ein Application Gateway mit einer öffentlichen IP-Adresse. Dieses dient als Ingress zum Terminieren eingehender SSL-Verbindungen. Das Application Gateway wird im AppGW-Subnetz deployt.

Die folgende Grafik zeigt außerdem die Komponenten für die Terraform-State-Datei (tfstate).

Repository

Das gesamte Projekt kann von https://github.com/eficode/aks2jira geklont werden.

Umgebung einrichten

Folgt diesen Schritten, um eure Umgebung für eine reibungslose Einrichtung vorzubereiten und eure Terraform-State-Datei remote zu speichern.

Tools/CLI

Wir überspringen die Installation der CLIs (siehe Verwendete Tools und Tech-Stack), da es zahlreiche Anleitungen für die Installation auf eurem Betriebssystem gibt.

tfstate remote speichern

Es wird empfohlen, euren Terraform-State remote zu speichern. Wenn ihr allein arbeitet, verursacht eine lokale Speicherung keine Probleme. Sobald jedoch ein zweiter Entwickler hinzukommt, solltet ihr ihn remote speichern (siehe Terraform-Dokumentation).

Daher müssen wir:

1. eine Ressourcengruppe erstellen.

2. einen Storage Account erstellen.

3. einen Blob-Container erstellen.

4. eine Umgebungsvariable festlegen (damit Terraform den Storage Account erkennt).

5. Terraform konfigurieren.

All diese Schritte werden ausgeführt, indem ihr das Bash-Skript ./scripts/create_tfstate_storage.ps1|sh startet, nachdem ihr euch bei eurem Azure-Konto angemeldet habt.

Einen Terraform-Workspace erstellen

Wir verwenden Workspaces, um verschiedene Umgebungen wie dev, int und prod zu erstellen. Die Namen dieser Workspaces verwendet Terraform später, um Komponentennamen in Azure zu definieren, zum Beispiel für die Ressourcengruppe.

Um einen Workspace zu erstellen, führt Folgendes aus:

Terraform-Skript konfigurieren

In variables.tf legen wir den Namen der zuvor erstellten Managed User ID und die Pod-CIDR entsprechend dem vom Kunden vorgegebenen IP-Bereich fest. Da wir eine neue Umgebung haben, müssen wir außerdem das Flag für deren VM-Größe erweitern.

Mithilfe von Datenblöcken im Modul network_aks können wir das vorhandene Managed-User-ID-Objekt sowie die beiden Subnetze für AKS und das Application Gateway abrufen, die sich im VNet namens vnet-jira befinden:

Die abgerufenen Variablen könnt ihr in eurem Terraform-Skript wie folgt verwenden:

Den AKS-Cluster erstellen

Die wichtigsten Änderungen basieren auf der Datei terraform/modules/aks/main.tf. Die AKS-Ressource enthält alle erforderlichen Informationen, um den Cluster mit den gewünschten Einstellungen zu erstellen. Da wir das vorhandene AKS-Subnetz abgerufen haben, muss dessen ID angegeben werden.

Berechtigungen festlegen

Da die Netzwerkinfrastruktur nicht vom AKS-Cluster selbst erstellt wird, müssen einige Berechtigungen festgelegt werden:

1. Der Ingress User des Application Gateway benötigt die Contributor-Rolle für das Application Gateway.

2. Der Ingress User des Application Gateway benötigt die Contributor-Rolle für die Ressourcengruppe, die das Application Gateway enthält.

3. Der Ingress User des Application Gateway benötigt die Network-Contributor-Rolle für das AKS-Subnetz.

4. Der Ingress User des Application Gateway benötigt die Managed-Identity-Operator-Rolle für den Managed User.

5. Der Ingress User des Application Gateway benötigt die Managed-Contributor-Rolle für den Managed User.

Application Gateway erstellen

Nachdem ihr die öffentliche Frontend-IP erstellt habt, müsst ihr das Application Gateway erstellen und dabei die Frontend-IP-Konfiguration angeben.

Infrastruktur erstellen

Ihr könnt die Infrastruktur erstellen, indem ihr diese Terraform-Befehle ausführt (auf eine Erklärung der Terraform-Befehle verzichten wir hier).

Jira installieren

Nachdem die Infrastruktur erstellt wurde, installieren wir die Anwendung Jira über das offizielle Helm Chart. Da wir eigene Einstellungen haben, können wir eine Values-Datei übergeben.

Hosts-Datei ändern

Wenn ihr noch keine eigene Domain habt, könnt ihr jede beliebige Domain testen, indem ihr die öffentliche IP-Adresse (des Application Gateway) zusammen mit einer beliebigen Domain, z. B. mydomain.com, in eurer Hosts-Datei eintragt.

Windows: C:\Windows\System32\Drivers\etc\hostsLinux: /etc/hosts<ip-of-appgw> jira.mydomain.comHelm-Values-Datei ändern

Die Konfiguration von Jira auf Anwendungsebene befindet sich in ./terraform/modules/jira/values-jira.yaml. Weitere Details findet ihr in der Atlassian-Dokumentation. Im Folgenden werden einige besonders wichtige Einstellungen erläutert.

Jira mit Helm installieren

Führt die folgenden Befehle aus, um das Helm Chart mit der geänderten Values-Datei zu installieren:

Dadurch wird das offizielle Atlassian-Repository lokal hinzugefügt und die Anwendung mit den Einstellungen aus euren Values-Dateien in einem Namespace namens Jira installiert.

Anwendungsarchitektur

Die Übersicht aus Anwendungsperspektive sieht wie folgt aus:

Wenn ihr diesem Leitfaden folgt, seid ihr nun bestens darauf vorbereitet, ähnliche Deployments umzusetzen und eure Infrastructure as Code sicher zu verwalten.