Cloud-Dienste sind aus der modernen IT-Welt nicht mehr wegzudenken. Allerdings gibt es noch immer viele Firmen und Projekte, die auf On-Premises-Infrastruktur setzen. Das kann unterschiedliche Gründe haben, sei es Aufgrund rechtlicher Bestimmungen, Datenschutz, oder um bereits bestehende Infrastruktur zu nutzen. Eine weitere Komplexität für die Verwaltung der IT-Infrastruktur bringt die Nutzung einer Multi-Cloud-Strategie. Dabei werden verschiedene Cloud-Provider, zum Beispiel Azure und AWS, genutzt, um Projekte zu realisieren. Das kann so sein, um die Ausfallsicherheit zu erhöhen oder weil ein benötigter Service nur bei einem bestimmten Anbieter vorhanden ist.

Die Implementierung einer Hybrid-Cloud- oder Multi-Cloud-Strategie wird schnell komplex und die Verwaltung aller verwendeter Dienste wird zu einer großen Herausforderung für die Administratoren.

Hierfür bietet Microsoft mit Azure Arc eine am Markt einzigartige Lösung an. Azure Arc ist eine Management-as-a-Service-Plattform, mit der Administratoren Infrastruktur mit Hilfe von Azure verwalten können. Dabei spielt es keine Rolle, ob diese on premises oder bei einem anderen Cloud-Anbieter gehostet sind. Sobald Azure Arc eingerichtet ist, kann die Infrastruktur auf die gleiche Weise verwaltet werden, als würde diese auf Azure laufen. Das ermöglicht auch die Verwendung von Azure-spezifischen Diensten wie zum Beispiel das Vergeben von Tags oder den Einsatz von Azure Policy. Azure Arc bietet dafür eine einheitliche Übersicht (englisch: Pane of Glass), in der alle Dienste dargestellt und verwaltet werden können.

Übersicht über die Azure Arc Services

Mit Hilfe von Azure Arc können eine Vielzahl unterschiedlichster Services verwaltet werden. Diese Services können den folgenden Kategorien zugeordnet werden:

• Azure-Arc-fähige Server

• Kubernetes mit Azure-Arc-Unterstützung

• Azure-Arc-fähige Anwendungsdienste

• Azure-Arc-fähige Datendienste

Abbildung 1 zeigt grafisch, wie Ressourcen von verschiedenen Anbietern und Orten zentral mit Azure Diensten verwaltet werden können.

Abb. 1: Übersicht über den Aufbau von Azure Arc

In den folgenden Abschnitten werden wir die Services der einzelnen Kategorien präsentieren und auf die darin enthaltenen Dienste eingehen.

Azure-Arc-fähige Server

Die Verwaltung von Servern, sowohl virtuelle Maschinen als auch physische Server, ist das älteste und am besten ausgereifte Feature von Azure Arc. Azure Arc erlaubt Administratoren, Server so zu verwalten, als würden sie auf Azure laufen. Dabei ist es egal, ob diese Server im eigenen Rechenzentrum oder bei einem anderen Cloud-Provider, zum Beispiel AWS, gehostet werden. Außerdem können Linux- und Windows-Server gleichermaßen verwaltet werden.

Um Server mit Azure Arc verwalten zu können, muss ein Skript auf dem jeweiligen Server ausgeführt werden, das den Azure Connected Machine Agent herunterlädt und konfiguriert. Dieser Agent stellt eine Verbindung mit Azure Arc her und verwaltet die verschlüsselte Kommunikation zwischen Azure und dem Server. Nachdem der Agent eingerichtet ist, ist der Server im Azure Arc Service sichtbar und kann genauso wie Azure VMs verwaltet werden. Dadurch können alle Azure Services zur Verwaltung von VMs verwendet werden. Dabei spielt es keine Rolle, ob der Server über das Internet erreichbar ist oder nicht. Der Server muss nur eine ausgehende Verbindung über Port 443 (HTTPS) mit dem Internet aufbauen können.

Eines der nützlichsten Features zur Verwaltung von Servern ist das Updatemanagement. Dieser Service ist komplett gratis und gibt Administratoren eine Übersicht über alle installierten Updates auf den von Azure Arc verwalteten Servern. Außerdem können auf diesen Servern mittels Azure Updates installiert werden. Dadurch können alle Azure-Arc-Server und Azure VMs mit den gleichen Tools verwaltet werden, wodurch der Verwaltungsaufwand deutlich gesenkt werden kann.

Neben der Verwaltung von Updates kann mit Hilfe von Azure Arc auch die Konfiguration der Server verwaltet und angepasst werden. Zusätzlich zur Verwaltung der Konfiguration kann eine Übersicht über die installierte Software pro Server erstellt werden. Das ist vor allem in Kombination mit der Verfolgung von Änderungen sehr nützlich. Dieses Feature zeichnet alle Änderungen der installierten Software, Windows- und Linux-Systemdateien oder Registry-Einträgen auf. Dadurch können Administratoren jederzeit sehen, welche Software bzw. welche Systemeinstellungen geändert wurden. Neben der Softwareverwaltung kann auch der Benutzerzugriff mit der gewohnten RBAC (Role-based Access Control) konfiguriert und überwacht werden.

In die gleiche Richtung wie die Verfolgung von Änderungen geht Azure Monitor. Mit Hilfe dieses Dienstes können die Azure Arc Server überwacht werden. Der Azure Monitor Agent auf dem Server sendet Informationen über die Ressourcenauslastung oder über den Zustand des Servers. Diese Informationen können dann mit Hilfe von Azure Monitor übersichtlich dargestellt werden und im Fall eines Problems kann eine zuständige Person oder das Team benachrichtigt werden.

Die letzten zwei Features, die wir hier kurz vorstellen möchten, sind Microsoft Defender für Cloud und Azure Policy. Beide Tools helfen, die Sicherheit der Server zu erhöhen. Der Microsoft Defender für Cloud überwacht den Sicherheitsstatus der Server und schützt vor Cyberangriffen. Mit Hilfe von Azure Policy können Administratoren Regeln vorgeben, die die Server einhalten müssen. Diese Regeln können zum Beispiel die Passwortkomplexität beinhalten oder auch, dass jeder Server Auditlogs erstellen muss.

Die Managementoberfläche für Azure Arc stellt Microsoft kostenlos zu Verfügung. Für die Verwendung von Azure Policy und der Überwachung der Änderung müssen 6 Dollar (in etwa 5,40 Euro) pro Server und Monat bezahlt werden.

Kubernetes mit Azure-Arc-Unterstützung

Neben der Verwaltung von Servern kann mit Azure Arc auch ein Kubernetes-Cluster verwaltet werden. Hierbei ist es wieder egal, wo dieser Cluster gehostet wird, on premises oder bei einem anderen Cloud-Anbieter. Außerdem wird jeder CNCF-zertifizierte Kubernetes-Cluster [1] unterstützt.

Um einen Kubernetes-Cluster mit Azure Arc verwalten zu können, muss man den Azure-Arc-Client mittels Azure-CLI-Befehl installieren. Außerdem benötigt man für die Installation die connectedk8s-Azure-CLI-Erweiterung. Der folgende Befehl zeigt, wie sie installiert und anschließend zur Installation des Azure Arc Agents genutzt wird. Die Azure-CLI-Befehle müssen an dem Kubernetes-Cluster ausgeführt werden, der zu Azure Arc hinzugefügt werden soll.

az extension add --name connectedk8s
az connectedk8s connect --name  --resource-group <RESOURCE GROUP>

Die Installation erstellt den neuen Namespace azure-arc und installiert dort den Azure Arc Agent und weitere Komponenten wie zum Beispiel einen Config Agent und Azure Active Directory Proxy. Abbildung 2 zeigt alle installierten Komponenten im azure-arc Namespace.

Abb. 2: Übersicht der Komponenten im azure-arc Namespace

Nachdem der Agent installiert ist, kann man den Kubernetes-Cluster im Service Kubernetes | Azure Arc im Azure Portal sehen. Dort sieht man die installierte Kubernetes-Version des Clusters, die Distribution sowie alle Ressourcen, die im Cluster laufen. Abbildung 3 zeigt den azure-arc Namespace und alle Pods des Namespace.

Abb. 3: Übersicht Azure Arc im Azure Portal

Außerdem sieht man auf der linken Seite von Abbildung 3, dass es die Möglichkeit gibt, Erweiterungen (Extensions) und Policies zu installieren sowie mit Hilfe von GitOps automatisierte Deployments beziehungsweise Continuous Deployments (CD) zu konfigurieren.Die Erweiterungen sind zum Beispiel Container Insights, Azure Key Vault als Secrets Provider und Microsoft Defender für Cloud. Container Insights sammelt Metriken der Pods im Cluster and sendet diese an Azure Monitor. Dort können sie grafisch dargestellt werden, um eine Übersicht über die Auslastung der Ressourcen zu bekommen. Azure Key Vault als Secrets Provider ist eine sehr interessante Erweiterung. Dieses Add-on erlaubt es, Kubernetes Secrets direkt im Azure Key Vault zu speichern. Dadurch sind die Secrets verschlüsselt und sicher gespeichert. Außerdem hat man so alle Azure Key Vault Features, wie zum Beispiel die Zugriffskontrolle und Auditierung der Zugriffe und Änderungen.Der Azure Arc Agent kommuniziert mit Azure über eine HTTPS-Verbindung. Dadurch ist die Verbindung verschlüsselt; zusätzlich braucht es keine offenen Ports auf der Firewall (außer Port 443 natürlich, der allerdings meistens nach außen offen ist). Da der Azure Arc Agent die Verbindung herstellt, muss nur die ausgehende Verbindung erlaubt werden und alle eingehenden Verbindungen können blockiert sein.

GitOps erlaubt es, automatisierte Deployments zu konfigurieren. Dafür wird ein Flux Agent im Cluster installiert, der über das Azure CLI oder das Azure Portal konfiguriert werden kann. Er prüft ein konfiguriertes Git-Repository auf Änderungen, und falls der Agent Änderungen feststellt, werden diese in den Cluster geladen und installiert.

Die Managementoberfläche für Azure Arc stellt Microsoft kostenlos zu Verfügung. Die Verwaltung der Kubernetes-Konfiguration ist für die ersten sechs vCPUs kostenlos und kostet für jede weitere vCPU 2 Dollar (in etwa 1,80 Euro) pro vCPU pro Monat.

Im nächsten Teil der Serie wird ein Proof-of-Concept eines Kunden vorgestellt. Dieser hat einen lokalen K3s-Cluster, der nicht über das Internet erreichbar ist. Dadurch war es ursprünglich nicht möglich, Anpassungen oder Deployments von außerhalb des Netzwerks, etwa von Azure DevOps aus, vorzunehmen. Mit Azure Arc war es möglich, weiterhin alle eingehenden Verbindungen zu blockieren und trotzdem sichere Deployments und Anpassungen außerhalb des Netzwerks durchzuführen.

Azure-Arc-fähige Anwendungsdienste

Anfang dieses Jahres hat Microsoft die Preview der Azure-Arc-fähigen Anwendungsdienste (Azure Arc-enabled Application Services) veröffentlicht. Mit diesem Dienst ist es erstmals möglich, bestimmte Azure Services wie zum Beispiel Azure App Service oder Azure Logic Apps außerhalb von Azure zu betreiben. Folgende Services sind aktuell verfügbar:

• Azure App Service

• Azure Functions

• Azure Logic Apps

• Azure API Management

• Azure Event Grid

Als Grundlage für diese Services wird ein Kubernetes-Cluster benötigt, der mit Azure Arc verbunden ist. Auf diesem Cluster kann dann eine Erweiterung für den gewünschten Service installiert werden. Wichtig zu beachten ist hierbei, dass diese Services sich in einer früher Phase der Preview befinden und viele Features der normalen Services noch nicht implementiert sind. Zum Beispiel können Azure App Services derzeit nur installiert werden, wenn sich die Azure-Arc-Instanz in East US oder West Europe befindet. Zusätzlich fehlt die Integration mit dem Azure Key Vault und die Möglichkeit, Managed Identities zu verwenden.

Als Benutzer eines dieser Dienste merkt man nicht, ob er auf Azure oder mits Azure Arc außerhalb betrieben wird. Eine neue Instanz eines Azure App Service kann wie gewohnt über das Azure Portal oder das Azure CLI erstellt werden. Zusätzlich zu den Azure-Regionen kann man selbst erstellte Regionen auswählen, die die Installation mittels Azure Arc darstellen. Wenn eine Azure-Arc-Region ausgewählt wurde, installiert Azure Arc einen neuen Namespace für den App Service im Kubernetes-Cluster und der Benutzer kann den Service wie gewohnt verwenden. Das bedeutet, dass der App Service mit einem öffentlichen URL und via HTTPS erreicht und bei Bedarf hinsichtlich der CPU- oder RAM-Auslastung skaliert werden kann.

Für die Verwaltung des App-Service-Diensts im Kubernetes-Cluster installiert Azure Arc die App-Service-Erweiterung. Zusätzlich kann optional KEDA (Kubernetes Event-driven Architecture [2]) installiert werden, um anhand von Events die Anwendung zu skalieren.

Da alle Dienste noch in der Preview sind, können sie derzeit kostenlos verwendet werden. Microsoft hat noch keine endgültigen Preise veröffentlicht.

Die Azure-Arc-fähigen Anwendungsdienste werden im dritten Teil dieser Serie detaillierter betrachtet.

SIE LIEBEN AZURE?

Entdecken Sie die BASTA! Tracks

Mehr erfahren

Azure-Arc-fähige Datendienste

Ein Grund, weshalb viele Organisationen sich gegen eine Cloud-Lösung entscheiden, ist die Datenhaltung auf fremder Infrastruktur. Mit Azure Arc besteht nun die Möglichkeit, die Datenhaltung auf der gewünschten Infrastruktur zu betreiben und trotzdem von den Vorteilen eines von der Cloud verwalteten Service zu profitieren. Zu den Vorteilen zählen automatische Updates, flexible Skalierung und eine zentralisierte Verwaltung der Datenbank. Durch automatisierte Updates müssen sich Administratoren nicht mehr darum kümmern. Zusätzlich können Datenbanken automatisch auf eine neue Version aktualisiert werden. Durch flexible Skalierung können die zur Verfügung stehenden Ressourcen dynamisch nach dem aktuellen Bedarf skaliert werden. Neben der Skalierung der Ressourcen können weitere Lesereplikate ohne Ausfallzeit hinzugefügt werden. Das kann automatisch mittels Skripten oder auch manuell erfolgen. Wie bei den anderen Azure-Arc-fähigen Services ist es auch hier möglich, die Datendienste durch Azure zentral und bequem mit den gewohnten Tools wie dem Azure Portal, Azure Data Studio oder Azure CLI zu verwalten.

Somit können Kunden Azure SQL Managed Instance und Azure PostgreSQL Hyperscale außerhalb von Azure betreiben. Im Gegensatz zu Azure-Arc-fähigen Anwendungsdiensten ist diese Kategorie ausgereifter und es stehen 16 Regionen, verteilt über die USA, Europa und Asien, zur Verfügung.

Wie schon bei den Azure-Arc-fähigen Anwendungsdiensten, beruhen auch die Azure-Arc-fähigen Datendienste auf der Grundlage von Kubernetes. Beide Datendienste, Azure SQL mit Azure-Arc-Unterstützung sowie PostgreSQL Hyperscale mit Azure-Arc-Unterstützung, laufen als containerisierte Applikationen. Um nun die erwähnten Vorteile von verwalteten Datendienste zu ermöglichen, erstellt und verwendet Azure Arc den Azure Arc Data Controller, der ebenfalls in einem Container im Kubernetes-Cluster läuft. Mittels Azure Arc Data Controller werden Verwaltungsfunktionalitäten wie Monitoring, Logging, Patching/Upgrading, Skalierung und Back-up ermöglicht. Weiter dient es dazu, den Austausch von Azure mit Identity Management, RBAC und Azure Policy sowie das Senden von Telemetriedaten zu gewährleisten. Dafür bietet Azure Arc mit der direkten und indirekten Verbindung zwischen Azure und Azure-Arc-fähigen Datendienste zwei Konnektivitätsmodi an. So kann mit der indirekten Verbindung die Menge an Daten, die an Azure gesendet werden, eingeschränkt werden. Jedoch bietet diese Option weniger Funktionalitäten, zum Beispiel nur noch halbautomatisierte Updates.

Abb. 4: Architektur des Azure-Arc-fähigen Datendiensts [3]

Um den Azure-Arc-fähigen Daten-Service zu verwenden, muss der Azure Arc Data Controller installiert werden. Abbildung 4 zeigt die Architektur und verdeutlicht nochmals, dass ein Kubernetes-Cluster als Basis für diesen Service benötigt wird. Die Installation kann entweder per Kommandozeile mittels Azure CLI oder über eine Benutzeroberfläche erfolgen.

Listing 1 zeigt alle benötigten Befehle, um den Azure Arc Data Controller auf dem Cluster zu installieren. Während der Installation muss der Administrator den Benutzernamen und das Passwort für den Adminbenutzer des Monitorings eingeben.

Listing 1
az provider register -n 'Microsoft.Kubernetes'
az provider register -n 'Microsoft.ExtendedLocation'
az extension add --name arcdata 
az extension add --name k8s-extension
az extension add --name customlocation
 
az customlocation create 
  --cluster-extension-ids <CLUSTER_EXTENSION_IDS> `
  --host-resource-id <KUBERNETES_RESOURCE_ID> `
  --name <CUSTOM_LOCATION_NAME > `
  --namespace <CUSTOM_LOCATION_NAMESPACE> `
  --resource-group <RESOURCE_GROUP> `
 
az arcdata dc create `
  --name <DATA_CONTROLLER_NAME> `
  --resource-group <RESOURCE_GROUP> `
  --cluster-name <CLUSTER_NAME> `
  --k8s-namespace <K8s_DATA_CONTROLLER_NAMESPACE> `
  --custom-location <CUSTOM_LOCATION_NAME> `
  --location <METADATA_LOCATION> `
  --connectivity-mode direct

Der Code in Listing 1 registriert zunächst die benötigten Provider mit Azure und installiert dann drei Azure-CLI-Erweiterungen. Anschließend wird eine Custom Location im Kubernetes-Cluster installiert. Dabei muss eine mit Abstand separierte Liste der IDs der installierten Erweiterungen angegeben werden und dann die ID des Kubernetes-Clusters. Die folgenden Parameter sollten selbsterklärend sein. Microsoft führt derzeit recht oft Anpassungen an den Parametern durch. Daher sollte vor der Verwendung die offizielle Dokumentation überprüft werden [4].

Nachdem die Custom Location erstellt ist, kann der Data Controller installiert werden. Dazu werden der Name der zuvor erstellten Custom Location und Informationen zum Kubernetes-Cluster benötigt, zum Beispiel der Name und in welchem Namespace der Data Controller installiert werden soll. Der Location Parameter gibt dabei die Region an, in der die Metadaten des Controllers gespeichert werden. Auch hier sollte die offizielle Dokumentation vor der Installation überprüft werden [5]. Die Installation kann je nach Konfiguration, Netzwerkgeschwindigkeit und der Anzahl an Nodes im Cluster eine längere Zeit in Anspruch nehmen.

Folgende Codezeile zeigt, wie man mit dem Kubernetes CLI kubectl überprüfen kann, ob die Installation abgeschlossen ist.

kubectl get pods --namespace <K8s_NAMESPACE>

Sobald die Installation erfolgreich abgeschlossen ist, kann mit der Provision einer Datenbankinstanz gestartet werden. Hierfür wird der in Listing 2 dargestellte Befehl ausgeführt. Um einen Datenbankadministrator anzulegen, wird hier während der Installation nach einem Benutzernamen und Passwort gefragt.

Listing 2
az sql mi-arc create `
  --name <DB_NAME> `
  --resource-group <RESOURCE_GROUP> `
  --admin-login-secret <SECRET_NAME_ADMIN_CREDENTIALS_KUBERNETES> `
  --custom-location <CUSTOM_LOCATION> `
  --location <METADATA_LOCATION>

Der location-Parameter gibt wie zuvor die Region an, in der die Metadaten der Datenbank in Azure gespeichert werden sollen. admin-login-secret konfiguriert den Namen eines Secrets in Kubernetes, in dem die Anmeldedaten des Administratoraccounts gespeichert sind. Weiterhin gibt es noch eine Unzahl an optionalen Parametern, die aus der offiziellen Dokumentation ersichtlich sind [6].

Sobald die damit erstellten Pods gestartet wurden, sind diese im Portal zu sehen. Abbildung 5 zeigt das Azure Portal, in dem der externe Endpunkt (die IP-Adresse und der Port) der Datenbank angezeigt wird. Mit diesem Endpunkt und den Anmeldedaten kann nun mittels Azure Data Studio oder auch SQL Server Management Studio auf die Datenbank zugegriffen werden.

Abb. 5: Sichtbarkeit der SQL-Instanz nach der erfolgreichen Installation

Tabelle 1: Preismodell für Azure-Arc-fähige SQL-Instanzen