.NET-Apps in Google Cloud bereitstellen

Auf dieser Seite finden Sie eine Übersicht über die Bereitstellung von .NET-Anwendungen inGoogle Cloud sowie Anleitungen zur Auswahl der richtigen Vorgehensweise bei der Bereitstellung einer Anwendung.

Einführung

Das Microsoft .NET Framework enthält eine umfangreiche Sammlung von Tools und Bibliotheken für die Anwendungsentwicklung. Mit der Einführung der Docker-Unterstützung für Windows und der Möglichkeit, .NET-Apps unter Linux auszuführen, unterstützen .NET-Apps jetzt auch eine Vielzahl von Bereitstellungszielen.

Für eine effiziente Entwicklung und für effiziente Tests ist es hilfreich, die Anwendungsbereitstellung zu automatisieren und diese in die Pipeline der kontinuierlichen Integration/Bereitstellung (Continuous Integration/Continuous Delivery, CI/CD) zu integrieren. Damit Sie aber die richtigen Tools auswählen und eine CI/CD-Pipeline erstellen können, müssen Sie zuerst festlegen, wie die Anwendung in der Produktion ausgeführt wird und welche Art der Bereitstellung Sie durchführen möchten.

Für die Bereitstellung einer .NET-Anwendung auf Google Cloudgibt es nicht nur eine optimale Möglichkeit. Die für Sie optimalen Bereitstellungsoptionen sind von der Anwendung und Ihren Anforderungen abhängig. Wenn Ihre Anwendung beispielsweise das komplette .NET Framework benötigt oder auf IIS ausgeführt werden muss, ist Windows die Basis für Ihre Bereitstellung. Wenn Ihre App dagegen mit den von .NET unterstützten Funktionen ausgeführt werden kann, lässt sich die App unter Linux bereitstellen.

Auf dieser Seite wird beschrieben, wie Sie .NET-Anwendungen ausführen und in Google Cloudbereitstellen können, einschließlich der Bedingungen für die Eignung der einzelnen Optionen. Am Ende werden Ihre Bereitstellungsoptionen in einem Entscheidungsbaum zusammengefasst. Damit können Sie entscheiden, welche Google Cloud -Komponenten und Vorgehensweisen für Ihre .NET-Anwendung am besten geeignet sind.

Bereitstellungsmodelle

Es gibt zwei grundlegende Vorgehensweisen für die automatisierte Bereitstellung einer Anwendung. Das Bereitstellungspaket wird entweder per Push an die Anwendungsserver übertragen oder die Anwendungsserver rufen das Anwendungspaket von einem bekannten Speicherort per Pull ab. In den folgenden Abschnitten werden die Unterschiede zwischen diesen beiden Modellen erläutert.

Push-basierte Bereitstellungen

Bei einer Push-basierten Bereitstellung ist das Bereitstellungsartefakt – eine ZIP-Datei, ein NuGet-Paket oder ein anderes Artefakt – anfänglich nur für einen Bereitstellungsserver verfügbar. Dieser Bereitstellungsserver kann eine dedizierte Maschine oder eine Rolle sein, auf das sich das CI-System bezieht.

Zum Bereitstellen wird von einem Prozess auf dem Bereitstellungsserver eine Verbindung zum Anwendungsserver hergestellt, das Bereitstellungsartefakt kopiert und die Installation gestartet. Gibt es mehr als einen Anwendungsserver, wird dieser Prozess parallel oder, was häufiger der Fall ist, nacheinander für jeden Anwendungsserver wiederholt, bis diese Artefakte auf allen Anwendungsservern bereitgestellt sind.

Das folgende Diagramm veranschaulicht diesen Ablauf.

Zum Automatisieren von Bereitstellungen in dieser Form gibt es eine Vielzahl von Tools zur Konfigurationsverwaltung. Einige dieser Tools verwenden einen imperativen Ansatz, bei dem die Reihenfolge der Bereitstellungsschritte wie mit einem Skript definiert wird. Dabei handelt es sich um einen intuitiven Ansatz, der aber anfällig für Konfigurationsabweichungen ist. Nach einer gewissen Zeit sind möglicherweise die Status mehrerer Maschinen nicht mehr identisch oder sie entsprechen nicht komplett dem gewünschten Status. Viele Tools ermöglichen daher die Definition des gewünschten Status und ermitteln dann automatisch die erforderlichen Schritte zur Realisierung dieses Status.

Für ein solches Bereitstellungsmodell werden unter Windows in der Regel folgende Tools verwendet:

• Microsoft Web Deploy: Ein kostenloses Tool zur Remotebereitstellung von Webanwendungen auf IIS-Servern.
• Octopus Deploy: Eine kommerzielle Software, mit der sich Bereitstellungen flexibel für mehrere Maschinen orchestrieren lassen.
• Microsoft Team Foundation Server- oder Azure Pipelines-Agents: Diese sind direkt in die Funktionen zur Releaseverwaltung von TFS oder Azure Pipelines integriert.
• Windows PowerShell Desired State Configuration (DSC): Eine integrierte Funktion von Windows Server 2012 R2 und höheren Versionen.

Zu beliebten Open-Source-Tools zählen auch Ansible, Chef Infra und Puppet. Obwohl diese Tools in erster Linie für Linux konzipiert sind, können Sie damit auch Windows-Ziele bereitstellen.

Sicherheit

Damit der Bereitstellungsserver eine Bereitstellung an einen Anwendungsserver per Push übertragen kann, muss ein Backchannel vorhanden sein. Web Deploy und Octopus Deploy verwenden für diese Aufgabe beispielsweise ein benutzerdefiniertes Protokoll und einen benutzerdefinierten Port. Ansible nutzt dafür SSH.

Unabhängig davon, welches Protokoll das Tool verwendet, muss die Kommunikation sicher sein. Es muss verhindert werden, dass Angreifer über den Backchannel schädliche Anwendungen einschleusen können. Vor allem aber erfordert eine sichere Kommunikation, dass der Bereitstellungsserver sich beim Anwendungsserver authentifizieren kann.

Für SSH kann die Authentifizierung über einen öffentlichen Schlüssel erfolgen. Mit einer entsprechenden IAM-Konfiguration lässt sich festlegen, dass Google Cloud automatisch den öffentlichen Schlüssel für SSH an die Anwendungsserver verteilt. Wenn Sie IAM jedoch nicht verwenden, kann Google Cloud den Schlüssel nicht für Sie verwalten und Sie müssen diese Aufgabe selbst übernehmen.

Eine Option ist Active Directory. Wenn sowohl der Bereitstellungsserver als auch der Anwendungsserver Windows ausführen und Mitglieder einer Active Directory-Domain sind, erfolgt die Authentifizierung mithilfe von Kerberos. Zum Ausführen einer fehlertoleranten Active Directory-Umgebung sind jedoch mindestens zwei zusätzliche VM-Instanzen zum Ausführen von Domaincontrollern erforderlich. Wenn in Ihrer Konfiguration das Autoscaling verwendet wird, müssen alle Server auch dynamisch mit der Domain verknüpft werden. Dadurch wird das Hochfahren eines Servers verlangsamt. Das Autoscaling kann auch dazu führen, dass veraltete Computerobjekte im Verzeichnis zunehmen und zusätzlich eine Bereinigung erfordern. Wenn Sie Active Directory in einer cloudbasierten Umgebung verwenden, müssen Sie auch diese Faktoren berücksichtigen.

Ohne Active Directory muss die Authentifizierung entweder mit NTLM oder auf andere Weise, z. B. mit der HTTP-Standardauthentifizierung, erfolgen. Bei beiden Vorgehensweisen ist es erforderlich, dass Anmeldedaten zwischen dem Bereitstellungsserver und den Anwendungsservern synchronisiert und sicher gespeichert werden. Beide Aufgaben können sich als schwierig erweisen.

Sowohl für Linux wie für Windows müssen Sie die Sicherheit der Kommunikation zwischen Bereitstellungs- und Anwendungsservern unabhängig von IAM gewährleisten. Das Verwenden mehrerer Verfahren zum Steuern des Zugriffs auf Systeme erhöht aber die Gesamtkomplexität und dadurch auch das Risiko einer versehentlichen Fehlkonfiguration.

Betriebssystemupdates

Neue Versionen von Anwendungspaketen müssen effizient auf Anwendungsservern bereitgestellt werden können. Genauso wichtig ist jedoch die Wartung des zugrunde liegenden Betriebssystems auf diesen Servern. Dazu gehört das Installieren von Sicherheitspatches. Bei größeren Serverfarmen ist es empfehlenswert, diesen Vorgang so zu automatisieren, dass Risiken und die Anzahl der Server minimiert werden, die während der Aktualisierung nicht zur Verfügung stehen.

Sie können Betriebssysteme auch mit einem Push-Ansatz aktualisieren, bei dem der Bereitstellungsserver ein Betriebssystemupdate auf den Anwendungsservern auslöst. Unter Linux ist die Verwendung von SSH für die Remoteausführung von Aktualisierungsbefehlen üblich. Unter Windows wird häufig PowerShell-Remoting (das auf WinRM basiert) verwendet. Bei beiden Verfahren müssen Sie in der Lage sein, Anmeldedaten sicher zu authentifizieren und sicher zu speichern.

Autoscaling

In einer statischen Umgebung, in der sich die Anzahl der Anwendungsserver nicht ändert, sind für den Bereitstellungsserver alle Bereitstellungsziele im Voraus bekannt. In einer Cloudumgebung ist es oft vorteilhaft, die Anzahl der Anwendungsserver automatisch hoch- oder herunterskalieren zu lassen. Für Push-basierte Bereitstellungen entstehen dadurch zwei spezielle Anforderungen:

• Wenn ein neuer Anwendungsserver hinzugefügt wird, registrieren Sie ihn beim Bereitstellungsserver. Dadurch wird gewährleistet, dass der neue Server in zukünftigen Bereitstellungen enthalten ist.
• An den neuen Server muss eine erste Bereitstellung übertragen werden.

Ein Autoscaling-Ereignis wird nicht vom Bereitstellungsserver ausgelöst. Stattdessen wird es von der zugrunde liegenden verwalteten Instanzgruppe initiiert, die eine Ebene unterhalb des Bereitstellungsservers wirksam ist.

Bevor der neue Anwendungsserver Anfragen verarbeiten kann, muss sich die neue Instanz des Anwendungsservers selbst beim Bereitstellungsserver anmelden und eine Bereitstellung auslösen. Im folgenden Diagramm wird dieser Vorgang veranschaulicht.

Für ein solches Vorgehen reicht es nicht aus, dass nur der Bereitstellungsserver mit Anwendungsservern Kontakt aufnehmen und sich bei diesen authentifizieren kann. Die Anwendungsserver müssen ebenfalls den Bereitstellungsserver kontaktieren und sich bei ihm authentifizieren.

Schließlich müssen auf dem neu gestarteten Server auch die neuesten Sicherheitspatches für das Betriebssystem installiert sein. Eine Aktualisierung während des Autoscalings würde den Prozess erheblich verzögern. Daher müssen die Updates für das Image, von dem die Anwendungsserver-VM erstellt wird, bereits installiert sein. Dafür haben Sie die folgenden beiden Möglichkeiten:

• Verwenden Sie die von Google Cloudbereitgestellten öffentlichen Images, die von Google auf dem neuesten Stand gehalten werden. Da diese Images nur das Betriebssystem enthalten, müssen Sie alle Anpassungen (Anwendungscode, Dienstprogramme und Betriebssystemkonfigurationen) mithilfe von Startskripts oder als Teil der Anwendungsbereitstellung selbst vornehmen.
• Verwenden Sie ein benutzerdefiniertes Betriebssystem-Image und halten Sie es auf dem neuesten Stand. Sie können so Anpassungen für das Image vornehmen. Allerdings wird damit die allgemeine Komplexität bei der Verwaltung Ihrer Bereitstellungen erhöht.

Das Ausführen von Push-basierten Bereitstellungen ist intuitiv, kann jedoch bei Berücksichtigung der Sicherheit durch Betriebssystemupdates und Autoscaling sehr komplex werden. Der nächste Abschnitt behandelt die Pull-basierte Bereitstellung, bei der es sich um eine mehr cloudorientierte Methode der Bereitstellung handelt.

Pull-basierte Bereitstellungen

Bei Pull-basierten Bereitstellungen werden Bereitstellungen auf indirekte Weise ausgeführt. Nachdem das CI-System eine neue Version eines Bereitstellungsartefakts erstellt hat, wird das Artefakt in einem Repository veröffentlicht. Das folgende Diagramm veranschaulicht diesen Ablauf.

Wenn eine Bereitstellung ausgeführt wird, was sowohl unmittelbar nach der Veröffentlichung des Artefakts als auch später erfolgen kann, löst der Bereitstellungsserver die eigentliche Bereitstellung aus. Der Bereitstellungsserver kann, wie bereits erwähnt, ein eigenes System oder eine Rolle sein, auf die sich das CI-System bezieht. Damit die Bereitstellung ausgelöst wird, muss eine Verbindung zum Anwendungsserver hergestellt werden, von dem das Bereitstellungsartefakt vom zentralen Repository abgerufen und installiert wird.

Auch wenn die Unterschiede zwischen einem Push- und einem Pull-basierten Modell auf den ersten Blick vielleicht gering sind, hat eine Pull-basierte Bereitstellung einige spezielle Auswirkungen:

• Der Abruf eines Bereitstellungsartefakts durch einen Anwendungsserver muss nicht auf Anwendungs- oder Betriebssystemebene ausgelöst werden. Stattdessen kann der Bereitstellungsserver den Pull-Vorgang auslösen, indem Compute Engine die VM neu startet oder ersetzt. Dadurch lassen sich Sicherheitsrisiken vermeiden, die mit Push-basierten Bereitstellungen verbunden sind.
• Das Bereitstellungsartefakt muss nicht unbedingt nur Anwendungsdateien enthalten. Es kann sich auch um ein Docker- oder ein VM-Image handeln. Damit lässt sich das Ausführen von Anwendungs- und Betriebssystemupdates vereinheitlichen.

Sicherheit

Der Bereitstellungsserver muss für bestimmte Arten der Bereitstellung nicht mit dem Anwendungsserver interagieren. Beispielsweise ist für folgende Bereitstellungsartefakte keine Interaktion erforderlich:

• Ein VM-Image
• Ein Docker-Image, das in Google Kubernetes Engine bereitgestellt wird
• Ein Paket, das in App Engine bereitgestellt wird

Der Bereitstellungsserver muss stattdessen zur Initiierung der Bereitstellung nur mit denGoogle Cloud APIs interagieren. Dies bedeutet wiederum, dass beim Bereitstellungsvorgang auf die Authentifizierungsverfahren von IAM zurückgegriffen werden kann. Dadurch müssen keine Schlüssel oder Anmeldedaten mehr verwaltet werden.

Wenn Sie Bereitstellungsartefakte wie ZIP- oder NuGet-Pakete verwenden, die nur die Anwendungsdateien und Binärdateien enthalten, können Sie eine Bereitstellung auf folgende Arten auslösen:

• Wenn der Server für den Abruf und die Installation des neuesten Bereitstellungsartefakts beim Start des Betriebssystems konfiguriert ist, können Sie ein Update über den Neustart der VM durch Google Cloud auslösen. Auch wenn ein Neustart unter Umständen unnötig zeitaufwendig erscheint, muss der Bereitstellungsserver dadurch nicht beim Anwendungsserver authentifiziert werden.
• Wie bei Push-basierten Bereitstellungen kann der Bereitstellungsserver die Aktualisierung remote über einen Backchannel auslösen. Diese Vorgehensweise beinhaltet jedoch die gleichen Sicherheitsrisiken und potenziellen Probleme beim Verwalten von Anmeldedaten, die für Push-basierte Bereitstellungen gelten.
• Der Bereitstellungsserver kann einen Agent ausführen, der das Repository auf neue Bereitstellungsartefakte prüft. Wenn ein neues Artefakt ermittelt wird, besteht die Möglichkeit, dass der Server es automatisch anwendet. Ein Problem entsteht, wenn mehrere Anwendungsserver gleichzeitig Updates installieren und daher nicht verfügbar sind. Zur Vermeidung einer solchen Situation hat der Agent die Möglichkeit, den Serverstatus im Repository zu erfassen und mit diesen Serverstatusinformationen Updates auf kontrollierte Weise auszuführen.

In allen diesen Fällen müssen Sie dafür sorgen, dass der Schreibzugriff auf das Repository kontrolliert erfolgt. Damit kann verhindert werden, dass Server schädliche Pakete abrufen und installieren.

Betriebssystemupdates

Wenn als Bereitstellungsartefakte Docker- oder VM-Images verwendet werden, sind in diesen Artefakten Anwendungsdateien und Abhängigkeiten kombiniert. So können Sie denselben Bereitstellungsmechanismus für die Aktualisierung des Betriebssystems und der App verwenden. In diesem Fall sollten Sie dafür sorgen, dass ein neues Bereitstellungsartefakt für zwei separate Fälle erstellt und veröffentlicht werden kann. Dies trifft u. a. zu, wenn eine neue App-Version verfügbar ist. Der andere Fall betrifft die Veröffentlichung neuer Sicherheitsupdates für das Betriebssystem oder für andere Abhängigkeiten.