.NET-Anwendungen in Google Cloud bereitstellen

Last reviewed 2022-01-19 UTC

Dieser Artikel bietet eine Übersicht über die Bereitstellung von .NET-Anwendungen in Google Cloud und 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 Core-Anwendungen unter Linux auszuführen, unterstützen .NET-Anwendungen 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 in Google Cloud gibt 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 Anwendung dagegen mit den von .NET Core unterstützten Funktionen ausgeführt werden kann, lässt sich die Anwendung unter Linux bereitstellen.

In diesem Artikel wird beschrieben, wie Sie .NET-Anwendungen ausführen und in Google Cloud bereitstellen 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.

Push-basierte Bereitstellungen

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:

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.

Unabhängig davon, ob Sie Linux oder Windows verwenden, die Sicherung der Kommunikation zwischen Deployment- und Anwendungsdatenservern erfordert Mechanismen, die von IAM getrennt sind. Die Verwendung mehrerer Mechanismen zur Steuerung des Zugriffs auf Systeme erhöht jedoch die Gesamtkomplexität und erhöht somit 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.

Autoscaling mit Push-basierten Bereitstellungen

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 Cloud bereitgestellten ö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. Nach dem Erstellen der neuen Version eines Bereitstellungsartefakts durch das CI-System wird dieses in einem Repository veröffentlicht. Das folgende Diagramm veranschaulicht diesen Ablauf.

Pull-basierte Bereitstellungen

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 den Google 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 Anwendung verwenden. In diesem Fall sollten Sie sicherstellen, dass ein neues Bereitstellungsartefakt für zwei separate Fälle erstellt und veröffentlicht werden kann. Zum einen geht es darum, wenn eine neue Anwendungsversion verfügbar ist. Der andere Fall betrifft die Veröffentlichung neuer Sicherheitsupdates für das Betriebssystem oder für andere Abhängigkeiten.

In Fällen, in denen das Bereitstellungsartefakt nur die Anwendungsdateien enthält, muss das Betriebssystem immer gesondert auf den neuesten Stand gebracht werden. Die Auswirkungen sind von daher die gleichen, die im Zusammenhang mit Push-basierten Bereitstellungen erläutert wurden.

Autoscaling

Das Abrufen von Bereitstellungsartefakten durch Anwendungsserver lässt sich gut mit dem Konzept des Autoscaling in Einklang bringen. Die Komplexität ist dabei wesentlich geringer als bei der Kombination von Autoscaling und Push-basierten Bereitstellungen. Wenn ein neuer Anwendungsserver aufgrund eines Autoscaling-Ereignisses gestartet wird, ruft der Server das neueste Bereitstellungspaket aus dem Repository ab und installiert es.

Wenn Sie VM- oder Docker-Images verwenden, werden die Mechanismen zum Abrufen von Images von Google Cloud bereitgestellt. Wenn Sie andere Pakete wie ZIP- oder NuGet-Archive nutzen, müssen Sie Nameserver so konfigurieren, dass nach dem Start eine Bereitstellung initiiert wird. Dazu passen Sie entweder das VM-Image entsprechend an oder verwenden Startskripts.

Bereitstellungsziele

In der Vergangenheit konnten .NET-Anwendungen nur unter Windows ausgeführt werden. Windows bot aber keine Unterstützung für Container an. Es gab so nur wenig Auswahl für die Umgebung, in der Ihre Anwendung ausgeführt werden konnte.

Mit der Einführung von .NET Core können Sie nun auswählen, ob Sie eine Anwendung unter Windows oder Linux ausführen. Da beide Betriebssysteme Container unterstützen, haben Sie jetzt mehrere Möglichkeiten für die Auswahl einer Umgebung.

Betriebssystem

Obwohl sich mit Mono seit vielen Jahren .NET-Anwendungen auf anderen Plattformen als Windows bereitstellen lassen, wurde Linux erst mit der Veröffentlichung von .NET Core zu einer komplett unterstützten Plattform für das Microsoft-Entwicklungspaket.

.NET Core bietet aber nur einen Teil der Funktionen von .NET Framework. Bei der Verwendung von .NET Core gelten deshalb gewisse Einschränkungen für Anwendungen. Für vorhandene Anwendungen besteht vor allem das Problem, dass die Portierung von .NET Framework auf .NET Core nicht immer einfach und nicht immer kostengünstig ist. In bestimmten Fällen ist dies sogar unmöglich.

Eine grundlegende Frage bei der Auswahl eines Bereitstellungsmodells und -ziels ist daher, welches Betriebssystem verwendet wird: Linux, für das .NET Core erforderlich ist, oder Windows, das entweder .NET Core oder .NET Framework unterstützt.

Das Ausführen von .NET-Anwendungen unter Linux bietet potenziell u. a. folgende Vorteile:

  • Sie können die flexible App Engine-Umgebung verwenden, die eine vollständig verwaltete Umgebung ist.
  • Sie können GKE verwenden – eine verwaltete Umgebung, die eine Container-Orchestrierung unterstützt.
  • Sie können die Zusatzkosten für Premium-Compute Engine-Images vermeiden, die mit der Windows-Lizenzierung verbunden sind.

Diesen Vorteilen stehen folgende mögliche Nachteile bei der Verwendung von .NET Core unter Linux gegenüber:

  • Der Aufwand für die Portierung einer vorhandenen .NET-Anwendung auf .NET Core kann die potenziellen Kosteneinsparungen wieder zunichtemachen. Im Extremfall ist es, wie bereits erwähnt, sogar unmöglich, eine vorhandene .NET-Anwendung auf .NET Core zu portieren.
  • Linux unterstützt IIS nicht. Kestrel, der .NET Core-Webserver, bietet eine sehr gute Leistung, jedoch nicht denselben Feature-Set wie IIS. Daher müssen Sie Kestrel möglicherweise in Verbindung mit einem Webserver wie Nginx verwenden.
  • Es gibt unter Linux kein direktes Äquivalent für einen Windows-Dienst. Auch wenn Sie Windows-Dienste in der Regel in Linux-Konsolenanwendungen konvertieren können, die als Daemon ausgeführt werden, ist diese Konvertierung oft nicht immer einfach.
  • Die Fehlerbehebung und das Debuggen von .NET Core-Anwendungen unter Linux erfordern andere Tools und Fähigkeiten als bei der Verwendung von .NET unter Windows. Dies kann zu einer Herausforderung für Teams werden, die nur wenig Erfahrung mit Linux haben.

Container

Container eignen sich besonders für Anwendungen, die in einem einzelnen Prozess ausgeführt werden. Hier einige Beispiele:

  • Windows-Dienste
  • Linux-Konsolenanwendungen, die als Daemons fungieren
  • Selbstgehostete WCF-Dienste
  • Von Kestrel gehostete ASP.NET MVC- oder Web-API-Anwendungen

Viele .NET-Apps sind auf IIS ausgerichtet. Es wird häufig verwendet, um mehrere Anwendungen in separaten virtuellen Verzeichnissen und App-Pools zu verwalten. Es entspricht daher möglicherweise nicht dem Muster mit einem einzelnen Prozess.

Wenn Sie eine IIS-basierte Installation in einen Container verschieben möchten, sind verschiedene Ansätze denkbar:

  • Verschieben Sie IIS mithilfe des microsoft/iis-Images als Basis mit allen virtuellen Verzeichnissen und Anwendungspools in ein einzelnes Windows-basiertes Docker-Image. Allerdings ist diese Methode nicht zu empfehlen, wenn die Anwendungen nicht eng miteinander verknüpft sind, da sie nicht separat aktualisiert und bereitgestellt werden können.
  • Verwenden Sie separate Windows-basierte Docker-Images für jede Anwendung, die jeweils IIS ausführt. Dadurch können Anwendungen unabhängig voneinander verwaltet werden. IIS verursacht allerdings einen nicht unerheblichen Aufwand, wenn Sie eine große Anzahl dieser Container betreiben müssen.
  • Migrieren Sie einige oder alle Anwendungen von IIS zu Kestrel. Da sich Kestrel entweder in einem Windows-basierten Container oder in einem Linux-basierten Docker-Container bereitstellen lässt, können Sie mit diesem Ansatz Container einzeln verwalten.

Mit IIS können mehrere Webanwendungen für eine einzige Website ausgeführt werden, wobei ein gemeinsamer Domainname verwendet wird. Wenn Sie Anwendungen in separate Container packen, ist dies auch mithilfe des inhaltsbasierten Load-Balancing möglich. Außerdem müssen Sie mit dem Google HTTP-Load-Balancer keinen benutzerdefinierten Reverse-Proxy vor Kestrel-Servern bereitstellen.

Die meisten Anwendungen können in Container verpackt werden. Dies ist nur in Ausnahmefällen nicht möglich. Bei einigen Szenarien containerisierter Anwendungen können jedoch spezielle Herausforderungen auftreten:

  • Für IIS-verwaltete Anwendungen ist es üblich, dass die Anwendungsbereitstellung automatisiert ist. Die Schritte zur Konfiguration von IIS, z. B. das Erstellen von Anwendungspools und Bindungen, werden jedoch manuell ausgeführt. Wenn Sie zu Containern wechseln, müssen Sie alle diese anfänglichen Schritte ebenso automatisieren.
  • Anwendungen, die auf Konfigurationsdateien oder auf Daten basieren, die sich auf Laufwerken befinden, erfordern unter Umständen Änderungen. Beispielsweise können Konfigurationsdaten aus Umgebungsvariablen abgerufen und relevante Dateien sowie Ordner als Volume bereitgestellt werden. Dadurch bleibt das Image zustandslos und frei von umgebungsspezifischen Konfigurationen.

Achten Sie bei Windows-basierten Docker-Containern darauf, dass Google Cloud derzeit Hyper-V nicht unterstützt und Hyper-V-Container damit nicht ausgeführt werden können. Daher können in Google Cloud nur Windows Server-Container bereitgestellt werden. Windows Server-Container sind einfacher als Hyper-V-Container und bieten eine andere Isolationsebene.

Einschränkungen für Bereitstellungen

Bestimmte Faktoren beim Erstellen von Anwendungen können zu Einschränkungen bei der Auswahl des verwendeten Bereitstellungsverfahrens führen. Diese Einschränkungen werden im folgenden Abschnitt erläutert.

Anwendungsarchitektur

Ein wichtiger Faktor bei der Auswahl des Bereitstellungsziels und -modells ist die Architektur der Anwendung. An einem Ende des Spektrums folgt eine Anwendung möglicherweise einem monolithischen Architekturmuster, bei dem die gesamte Anwendungslogik in einer einzigen Codebasis implementiert ist und in einem einzigen Prozess oder IIS-Anwendungspool ausgeführt wird. Am anderen Ende des Spektrums stehen Anwendungen, die in Form von Mikrodiensten entwickelt werden. Bei diesem Ansatz besteht die Anwendung aus einer Reihe von Diensten, die unabhängig in eigenständigen Prozessen, in separaten IIS-Anwendungspools oder als gesonderte Windows-Dienste ausgeführt werden.

Schließlich können Sie auch mehrere unabhängige Anwendungen nutzen, die mit einer einheitlichen Strategie bereitgestellt werden, wobei jede Anwendung selbst monolithisch sein kann. Für die Erläuterungen in diesem Artikel wird dieser Ansatz wie das Mikrodienstszenario behandelt.

In einer Mikrodienstarchitektur soll die Anwendung kostengünstig ausgeführt werden, wobei die Dienste isoliert und unabhängig verwaltet werden. Sie können jedem Dienst dedizierte VMs zuweisen. Damit ist gewährleistet, dass sich Dienste einzeln verwalten und bereitstellen lassen. Eine solche Vorgehensweise kann jedoch zu einer großen Anzahl nicht ausgelasteter VMs führen und unnötige Kosten verursachen. Für Anwendungen wie diese sind daher Bereitstellungsmodelle, die ein engeres Packen ermöglichen, insbesondere containerbasierte Modelle, vermutlich kostengünstiger.

Status und Zustandslosigkeit

Wenn Sie Anwendungen für die Cloud entwickeln, sollten Sie diese zustandslos halten und den Status extern mit einem Google Cloud-basierten Speicherdienst verwalten. Zustandslose Anwendungen bieten eine Reihe von Vorteilen:

  • Sie können redundant bereitgestellt werden, um Verfügbarkeit und Kapazität zu erhöhen.
  • Anfragen können frei zwischen Instanzen verteilt werden.
  • Sie eignen sich gut für das Autoscaling.
  • Im Falle eines Fehlers kann die Umgebung, ob Container oder VM, ohne das Risiko eines Datenverlusts einfach neu erstellt werden.

Das Erstellen von zustandslosen Anwendungen ist oft komplex. Aus diesem Grund wird bei vielen älteren Anwendungen darauf verzichtet. Dennoch lohnt es sich, zu analysieren, ob eine Anwendung zustandslos gemacht werden kann.

Sitzungsstatus

ASP.NET- und ASP.NET MVC-Anwendungen verwenden in der Regel Sitzungen für das Erfassen des Nutzerstatus. Dadurch wird die Anwendung zustandsorientiert. Es gibt jedoch mehrere Möglichkeiten, um die Auswirkungen von Sitzungen zu begrenzen:

  • Wenn nur wenige Sitzungsdaten vorhanden sind, können Sie den Status stattdessen in einem verschlüsselten oder signierten Cookie speichern.
  • Anstatt den standardmäßigen InProc-Sitzungszustandsanbieter zu nutzen, können Sie den SQLServer-Anbieter verwenden. Dies erfordert jedoch eine SQL Server-Instanz, die zusätzliche Kosten verursacht und die Latenz sowie die Verfügbarkeit der Anwendung beeinträchtigen kann.
  • Sie haben die Möglichkeit, die Vorteile der Sitzungsaffinität im Cloud Load Balancing zu nutzen. Mit diesem Feature wird sichergestellt, dass alle Anfragen von einem bestimmten Client an dieselbe Anwendungsinstanz weitergeleitet werden. Die Verwendung der Sitzungsaffinität kann sich allerdings negativ auf die gleichmäßige Verteilung der Lasten auswirken. Bestimmte Anwendungsinstanzen erhalten dann letztlich mehr Anfragen als andere. Darüber hinaus gehen, wenn eine Anwendungsinstanz aus einem beliebigen Grund beendet wird, alle Sitzungen verloren, die von der Instanz ausgeführt werden. Dies hat potenziell Auswirkungen auf den Endnutzer. Die Verwendung der Sitzungsaffinität ist daher keine ideale Lösung, oft aber ein praktikabler Kompromiss zwischen Robustheit und Kosten.

In-Memory-Caches

Anwendungen verwenden häufig In-Memory-Caches, um redundante Berechnungen oder Datenbanksuchvorgänge zu vermeiden. Dies wird dann problematisch, wenn mehrere Instanzen der Anwendung gleichzeitig ausgeführt werden. Caches können dann inkohärent werden.

Verwenden Sie zur Vermeidung von Inkohärenzen einen verteilten Cache, entweder direkt oder über die Schnittstelle IDistributedCache. Cache-Server wie Redis oder Memcached benötigen in der Regel relativ wenig Ressourcen, erhöhen jedoch die Komplexität der gesamten Einrichtung.

Speicherung

Daten in Form von Bildern, Anhängen oder Mediendateien werden normalerweise auf einem Laufwerk gespeichert. Das Verwenden eines nichtflüchtigen Speichers einer VM für diesen Zweck ist in der Regel keine sinnvolle Option. Dies verhindert, dass Daten von mehreren Maschinen gemeinsam genutzt werden können. Außerdem besteht das Risiko eines Datenverlusts, wenn eine VM-Instanz neu erstellt wird. Verwenden Sie stattdessen einen der folgenden Ansätze:

  • Verschieben Sie die Daten auf einen Dateifreigabeserver. Dadurch werden die Auswirkungen auf die App minimiert. Der Betrieb eines hochverfügbaren SMB- oder NFS-Servers ist jedoch mit zusätzlichen Kosten und Wartungsaufwand verbunden.
  • Verschieben Sie die Daten in Cloud Storage. Obwohl dies Änderungen an der Anwendung erfordert, ist Cloud Storage hochverfügbar, erheblich kosteneffizienter als die Ausführung eines Dateiservers und erfordert keine zusätzlichen Wartungsmaßnahmen.
  • Verschieben Sie die Daten auf Filestore-Dateiserver. Bei diesem Ansatz sind möglicherweise einige Änderungen an der Anwendung erforderlich. Nach der Bereitstellung können Sie die Kapazität Ihrer Instanzen jedoch ohne Ausfallzeiten anpassen. Filestore unterstützt auch mehrere gleichzeitige Anwendungsinstanzen, die gleichzeitig auf dasselbe Dateisystem zugreifen.
  • Verschieben Sie die Daten in den Cloud Volumes-Dienst. Mit dem Cloud Volumes-Dienst können Sie Ihre dateibasierten Anwendungen zu Google Cloud verschieben. Dabei werden NFS- und SMB-Volumes unterstützt. Sie müssen Ihre Anwendungen nicht umgestalten. Außerdem erhalten Sie dauerhaft viel Speicherplatz für Ihre Anwendungen.

Bereitstellungsstrategien

Wenn Sie die neue Version einer Anwendung bereitstellen, müssen Sie Risiken und Auswirkungen auf die Endnutzer möglichst gering halten. Die drei gängigsten Strategien hierfür sind Neuerstellung, Blau/Grün und Rollierende Bereitstellung.

Strategie der Neuerstellung

Die Strategie der Neuerstellung besteht darin, die laufende Anwendung auf allen Servern zu stoppen, eine neue Version bereitzustellen und die Anwendung zu starten. Diese Strategie hat den offensichtlichen Nachteil, dass sie eine Dienstunterbrechung verursacht. Sie vermeidet aber potenzielle Probleme bei der Verwendung zweier verschiedener Versionen einer Anwendung, die vorübergehend koexistieren und auf gemeinsame Daten zugreifen.

Blau/Grün-Strategie

Das Ziel der Blau/Grün-Strategie (auch als Rot/Schwarz-Strategie bezeichnet) besteht darin, eine neue Anwendungsversion auf einer neuen Gruppe von Servern bereitzustellen. Wenn die Bereitstellung abgeschlossen ist, wechseln Sie mit dem gesamten Traffic von der alten auf die neue Servergruppe. Dieser Ansatz erfordert vorübergehend die doppelte Anzahl von Servern für die Produktion, vermeidet jedoch Dienstunterbrechungen.

Diese Strategie setzt voraus, dass zwei Versionen einer Anwendung vorübergehend gleichzeitig vorhanden sein können und sich nicht gegenseitig stören. Für Anwendungen mit Zugriff auf Datenbanken muss dafür jede Iteration von Änderungen an Datenbankschemata abwärtskompatibel zu mindestens der vorherigen Version sein.

Strategie der rollierenden Bereitstellung

Bei der rollierenden Bereitstellung werden die Server nacheinander aktualisiert. Wie bei der Blau/Grün-Strategie sind dabei für eine bestimmte Zeit zwei verschiedene Versionen einer Anwendung gleichzeitig vorhanden. Anders als bei der Blau/Grün-Bereitstellung wird jedoch hier der Traffic schrittweise von der alten auf die neue Version verlagert. Je mehr Server aktualisiert werden, desto mehr Nutzer werden an die neue Version weitergeleitet, bis schließlich der letzte Server aktualisiert ist und alle Nutzer die neue Version verwenden. Ein wesentlicher Vorteil dieses Ansatzes besteht darin, dass potenzielle Probleme frühzeitig und noch bevor alle Nutzer betroffen sind erkannt werden können. Dies mindert das Gesamtrisiko.

Da für die rollierende Bereitstellung zwei Versionen der Anwendung gleichzeitig vorhanden sein müssen, ist für diese Strategie häufig auch die Konfiguration eines Load-Balancer erforderlich. So soll verhindert werden, dass Nutzer zwischen Versionen springen.

Optionen der Bereitstellung

Bisher wurden in diesem Artikel Bereitstellungsmodelle, -ziele und -strategien behandelt. In den folgenden Abschnitten werden spezielle Optionen der Bereitstellung von .NET-Anwendungen in Google Cloud beschrieben.

GKE (Windows oder Linux)

GKE stellt eine vollständig verwaltete Kubernetes-Umgebung zur Verfügung. Aufgrund der Orchestrierungsfunktionen von Kubernetes ist GKE besonders gut geeignet, um komplexe Mikrodienstanwendungen auszuführen, die aus vielen Containern bestehen. Aber auch für Anwendungen, die nicht in Form von Mikrodiensten entwickelt wurden, können Sie mit GKE viele Container in einer gemeinsam genutzten Infrastruktur auf eine ressourcenschonende und wartungsfreundliche Weise ausführen.

Für GKE müssen alle Elemente der Anwendung als Docker-Container gepackt sein. Linux-basierte Container erfordern die Verwendung von .NET Core und einer Linux-basierten Umgebung. Das Erstellen von Containern unter Linux kann sich dabei als schwierig erweisen, wenn Ihr CI-System auf Windows basiert. Sowohl Azure Pipelines/Team Foundation Server als auch Cloud Build unterstützen aber das Erstellen von .NET Core-Anwendungen und das Erstellen bzw. Veröffentlichen von Linux-basierten Container-Images.

GKE bietet die größte Flexibilität für zustandslose Anwendungen. Mithilfe von zustandsorientierten Sets und nichtflüchtigen Volumes können Sie auf GKE auch bestimmte Arten von zustandsorientierten Anwendungen ausführen.

Ein GKE-Cluster enthält eine Reihe von VM-Instanzen, Knoten genannt, auf denen Container verteilt sind. In einem Mehrzonen- oder regionalen Cluster kann GKE Knoten und Arbeitslasten über mehrere Zonen verteilen. Damit wird eine hohe Verfügbarkeit gewährleistet.

Die Preise hängen von der Anzahl der ausgeführten Knoten ab. GKE ist daher am kostengünstigsten, wenn Knoten gut ausgelastet sind. Sie können größere Arbeitslasten auf demselben Cluster ausführen oder die Anzahl der Knoten automatisch nach Bedarf skalieren lassen.

Pull-basierte Bereitstellung mithilfe von kubectl-Befehlen

Anwendungen werden in GKE in zwei Schritten bereitgestellt:

  1. Veröffentlichen von Docker-Images in Artifact Registry oder in einer externen Docker Registry mithilfe von docker push oder anderen Mitteln. Dieser Schritt wird in der Regel vom CI-System ausgeführt.
  2. Auslösen der Bereitstellung mithilfe von kubectl. Dieser Schritt kann entweder vom CI-System oder separat ausgeführt werden. Da die Bereitstellung per Remote-Zugriff initiiert wird, spielt es keine Rolle, ob kubectl unter Linux oder Windows ausgeführt wird.

GKE unterstützt die Strategien der Neuerstellung und der rollierenden Bereitstellung. Die Primitive zum Steuern von Bereitstellungen sind ausreichend flexibel, sodass Sie auch mit anderen Bereitstellungsstrategien arbeiten können. Allerdings sind dafür dann zusätzliche Tools oder Skripts erforderlich.

Pull-basierte Bereitstellung mithilfe von Spinnaker

Wenn die integrierten Funktionen von GKE zur Orchestrierung von Bereitstellungen für Ihren Zweck nicht ausreichen, können Sie GKE in Kombination mit Spinnaker einsetzen. Spinnaker bietet eine integrierte Unterstützung für GKE und ermöglicht das Implementieren von erweiterten Bereitstellungsstrategien, einschließlich Blau/Grün-Bereitstellungen.

Da Spinnaker kein verwalteter Dienst ist, müssen Sie ihn separat bereitstellen und verwalten. Sie können Spinnaker entweder auf separaten Linux VM-Instanzen oder in einem GKE-Cluster bereitstellen.

Knative und Cloud Run

Für Ihre zustandslosen .NET Core-Container bieten Knative und die verwaltete Version Cloud Run eine serverlose Containerumgebung. Serverlose Container bieten Vorteile wie Bereitstellung, Autoscaling und Load-Balancing ohne den mit der Infrastrukturverwaltung verbundenen Aufwand.

Zur Bereitstellung von Containern in einem Kubernetes-Cluster bietet Knative eine API-Oberfläche, die höher und kleiner als Kubernetes ist. Mit Knative können Sie die Komplexität von Kubernetes vermeiden und so die Container-Bereitstellung vereinfachen.

Cloud Run folgt der Knative API, wird jedoch in der Google-Infrastruktur ausgeführt, sodass keine Kubernetes-Cluster mehr vorhanden sind. Cloud Run bietet eine serverlose Option für Container. Standardmäßig werden Container in Cloud Run automatisch skaliert und für die Dauer der Anfrage in Rechnung gestellt. Die Bereitstellungszeit erfolgt in Sekunden. Cloud Run bietet außerdem nützliche Features wie Überarbeitungen und Traffic-Aufteilung.

Cloud Run for Anthos ist die flexiblere Version von Cloud Run, die die Einfachheit von Knative und Cloud Run mit der betrieblichen Flexibilität von Kubernetes bietet. Mit Cloud Run on Anthos können Sie beispielsweise zugrunde liegende Instanzen, die Ihre Container ausführen, GPUs hinzufügen oder Ihre Anwendung auf viele Container skalieren.

Cloud Run ist in andere Dienste wie Pub/Sub, Cloud Scheduler, Cloud Tasks und Back-Ends wie Cloud SQL integriert. Sie kann sowohl für automatisch skalierte Web-Front-Ends als auch für interne Mikrodienste verwendet werden, die durch Ereignisse ausgelöst werden.

Compute Engine (Windows oder Linux)

Mit Compute Engine können Sie VM-Instanzen erstellen und verwalten. Es unterstützt eine Reihe von Windows Server-Versionen und Linux-Distributionen sowie verschiedene Optionen für das Festlegen der Größe und die Konfiguration. Aufgrund dieser Flexibilität lassen sich Compute Engine-VM-Instanzen für eine breite Palette von Arbeitslasten verwenden.

Wenn Sie gewährleisten möchten, dass Anwendungen einzeln bereitgestellt und gewartet werden können, stellen Sie nur eine einzige Anwendung oder einen einzigen Dienst für jede VM-Instanz bereit. Für eine hohe Verfügbarkeit müssen Sie pro Anwendung mindestens zwei VM-Instanzen ausführen, die sich jeweils in einer anderen Zone befinden. Sie benötigen also unabhängig von der erwarteten Arbeitslast doppelt so viele VM-Instanzen wie bereitgestellte Anwendungen oder Dienste.

Compute Engine bietet eine einfache Möglichkeit zur Verwendung des Autoscaling über verwaltete Instanzgruppen. Verwaltete Instanzgruppen ermöglichen auch das Implementieren rollierender Bereitstellungen. Dies wird weiter unten in diesem Artikel beschrieben.

Da der Preis für Compute Engine pro VM-Instanz berechnet wird, kann man davon ausgehen, dass das Ausführen von Anwendungen in Compute Engine am kostengünstigsten ist, wenn Anwendungen eine erhebliche Arbeitslast übernehmen. Dies führt dann zu einer hohen Auslastung der VM-Instanzen. Wenn dagegen bei einer großen Anzahl von Diensten und Anwendungen die durchschnittliche Auslastung gering ist, sind andere Bereitstellungsoptionen wie etwa GKE oft wirtschaftlicher, da sie mehreren Anwendungen die Nutzung einer gemeinsamen Infrastruktur ermöglichen, ohne die Isolation der Arbeitslasten zu beeinträchtigen.

Für das Ausführen von Windows-VM-Instanzen benötigen Sie Premium-Images. Diese Images enthalten lizenzierte Kopien von Windows. Dadurch fallen zusätzliche Gebühren an. Windows-VMs sind daher in der Regel weniger kostengünstig als VMs mit Linux-Distributionen wie CentOS oder Debian. Für diese müssen keine Lizenzgebühren entrichtet werden.

Sie können mit SSH oder RDP eine VM-Instanz manuell einrichten, entweder, um eine Anwendung manuell bereitzustellen oder um eine Startkonfiguration anzuwenden, die zum Vorbereiten einer Maschine für die erste Bereitstellung erforderlich ist. Dies bedeutet jedoch eventuell, dass Maschinen mit speziellen Konfigurationen vorhanden sind, die sich von anderen VM-Instanzen unterscheiden. Auf Dauer kann das manuelle Einrichten einer VM-Instanz zu einer komplizierten und arbeitsintensiven Angelegenheit werden. Es ist daher empfehlenswert, den Prozess zu automatisieren und so wiederholbar zu machen.

Das Automatisieren von Anwendungsbereitstellungen in Compute Engine umfasst folgende Aufgaben:

  1. Bereitstellen und Vorbereiten von VM-Instanzen für eine erste Anwendungsbereitstellung
  2. Ausführen der Anwendungsbereitstellung
  3. Warten des Betriebssystems (durch Installation von Sicherheitsupdates)

In den folgenden beiden Abschnitten wird gezeigt, wie Sie alle drei Schritte einheitlich mithilfe eines Pull-basierten Bereitstellungsansatzes ausführen können. Während die Verfahren und Tools für die in diesen Abschnitten erläuterten Ansätze unterschiedlich sind, ähnelt die grundsätzliche Vorgehensweise der Bereitstellung einer containerbasierten Anwendung mithilfe von GKE.

Pull-basierte Bereitstellung mithilfe einer verwalteten Instanzgruppe

Verwaltete Instanzgruppen werden vor allem zur Implementierung des Autoscaling verwendet. Sie bieten jedoch auch eine Möglichkeit, rollierende Bereitstellungen auszuführen. Nach dem Erstellen einer Instanzvorlage, die auf die neue Version der Anwendung verweist, können Sie mit der Funktion der rollierenden Ersetzung VM-Instanzen, die die alte Vorlage verwenden, durch Instanzen ersetzen, die die neue Vorlage nutzen.

Voraussetzung dafür ist, dass die neue Version der Anwendung als Instanzvorlage zur Verfügung gestellt wird. Dies erreichen Sie auf zwei Arten:

  • Durch Definition einer Instanzvorlage, die ein öffentliches Betriebssystem-Image verwendet. Verwenden Sie ein Startskript zur Konfiguration des Systems und zur Installation der Anwendung aus einem Cloud Storage-Bucket, einem NuGet-Repository, einer Docker Registry oder einer anderen Quelle. Das folgende Diagramm veranschaulicht diesen Ansatz.

    Pull-basierte Bereitstellungen mit einer verwalteten Instanzgruppe und einem öffentlichen Image

  • Durch Erstellung eines benutzerdefinierten VM-Images als Teil des CI/CD-Prozesses. Dieser Prozess wird oft als Image-Verankerung bezeichnet. Bei diesem Ansatz verwenden Sie ein öffentliches Betriebssystem-Image, um eine neue VM-Instanz zu erstellen, die neueste Anwendung darauf zu installieren, ein VM-Image aus der Instanz zu erstellen und das Image im Google Cloud-Projekt zur Verfügung zu stellen. Der gesamte Prozess kann mit einem Tool wie Packer komplett automatisiert werden. Auf das damit erstellte Image lässt sich dann in einer Instanzvorlage verweisen. Das folgende Diagramm veranschaulicht diesen Ansatz.

    Pull-basierte Bereitstellungen mit einer verwalteten Instanzgruppe und einem benutzerdefinierten Image

Der Nachteil beim Erstellen eines benutzerdefinierten Images (dies ist die zweite Option) ist die lange Dauer des Vorgangs. Eine Image-Verankerung nimmt relativ viel Zeit in Anspruch, oft einige Minuten. Durch diese Vorgehensweise wird der CI-/CD-Prozess nicht nur komplexer, sondern auch langsamer. Auf der anderen Seite ist das Starten neuer VMs mit einem benutzerdefinierten Image ein einfacher und schneller Vorgang, für den sich die Verwendung des Autoscaling vorteilhaft auswirkt.

Das Einsetzen von Startskripts zur Bereitstellung der Anwendung (dies ist die erste Option) hat die gegenteiligen Auswirkungen. Es verursacht keinen zusätzlichen Aufwand im CI-/CD-Prozess durch Image-Verankerung, jedoch wird der Prozess zum Erstellen von VM-Instanzen verlangsamt. Wenn das Startskript nicht hundertprozentig zuverlässig ist oder wenn die Systeme, von denen die Binärdateien der Anwendung heruntergeladen werden, nicht hochverfügbar sind, kann diese Vorgehensweise zu einer geringeren Verfügbarkeit führen.

Der für Ihre Anwendung geeignetste Ansatz hängt von der Anwendung selbst und der Komplexität der Konfiguration ab. In einigen Szenarien ist es sogar am besten, beide Ansätze zu kombinieren:

  • Ein benutzerdefiniertes Image enthält alle Konfigurationen und Abhängigkeiten, jedoch nicht die tatsächlichen Binärdateien der Anwendung. Ein neues Image wird verankert, wenn sich die Konfiguration oder eine Abhängigkeit ändert, aber nicht für jede Anwendungsversion. Damit lässt sich die Verlangsamung der CI-/CD-Pipeline der Anwendung verhindern.
  • Die Anwendung wird mithilfe eines Startskripts installiert. Zur Minimierung des Risikos und zur Erhöhung der Ausführungsgeschwindigkeit sollte dieser Vorgang so einfach wie möglich gehalten werden.

In einem Szenario, in dem viele verschiedene Anwendungen oder Dienste mit einer gemeinsamen Basiskonfiguration bereitgestellt werden sollen, können Sie mit diesem hybriden Ansatz vermeiden, dass Dutzende oder Hunderte von nahezu identischen Images erstellt und verwaltet werden müssen.

Sie können mit verwalteten Instanzgruppen Bereitstellungen sowohl für Linux- wie für Windows-Arbeitslasten orchestrieren. Für Linux wird der Einsatz von verwalteten Instanzgruppen zur Bereitstellung von Docker-Containern auf VM-Instanzen von der Plattform unterstützt. Dies ist aber nur für stark ausgelastete Anwendungen zu empfehlen. In anderen Fällen bietet die Bereitstellung eines einzelnen Docker-Containers pro VM wenig Vorteile gegenüber der Verwendung von GKE oder der flexiblen App Engine-Umgebung.

Wenn Sie Windows Server-Container verwenden, gelten für das Ausführen der Container mithilfe von Compute Engine und verwalteten Instanzgruppen die folgenden Richtlinien:

  • Verwenden Sie entweder ein benutzerdefiniertes Image mit vorinstalliertem Docker oder eines der folgenden öffentlichen Images:
    • Windows Server 2019 Datacenter Core for Containers
    • Windows Server 2019 Datacenter for Containers
  • Verwenden Sie ein Startskript, um das Docker-Image abzurufen und es während des VM-Starts als Windows Server-Container zu starten. Sie können mit entsprechenden Portzuordnungen die Dienste ausweisen, die im Container ausgeführt werden.

Ein Startskript wird nicht unbedingt erst dann automatisch ausgeführt, wenn der Docker-Dienst gestartet wird. Wird das Skript ausgeführt, bevor Docker verfügbar ist, müssen Sie die entsprechende Wiederholungslogik in das Skript aufnehmen, damit es korrekt angewendet wird.

Wenn Sie Windows-basierte Images in einer Nicht-Cloud-Umgebung erstellen, können Sie dafür auch Microsoft Deployment Toolkit (MDT) oder Windows Deployment Services (WDS) verwenden. Das Verwalten von Images und das Erstellen von VM-Instanzen auf der Grundlage von benutzerdefinierten Images gehören aber zu den Kernfunktionen von Compute Engine. Die genannten Tools sind deshalb nicht erforderlich. Compute Engine unterstützt nicht nur Startskripts, sondern auch spezielle Skripts für Windows-basierte VM-Instanzen. Daher müssen Sie in der Regel nicht mit den benutzerdefinierten unattend.xml-Dateien arbeiten. Allerdings müssen Sie weiterhin dafür sorgen, dass eine Windows-Installation mithilfe von GCESysprep generalisiert wird, bevor Sie ein Image erstellen.

Pull-basierte Bereitstellung mithilfe von Spinnaker

Verwaltete Instanzgruppen bieten eine einfache und robuste Möglichkeit zur Implementierung von rollierenden Bereitstellungen. Die Funktionen verwalteter Instanzgruppen sind jedoch unter Umständen für bestimmte Anwendungen nicht ausreichend. Für komplexere Bereitstellungsstrategien und Pipelines können Sie deshalb Spinnaker verwenden.

Der Ansatz von Spinnaker zur Orchestrierung von Bereitstellungen in Compute Engine ähnelt der im vorherigen Abschnitt beschriebenen Vorgehensweise, d. h. er beruht auch auf der Image-Verankerung. Es gelten deshalb die gleichen Anforderungen.

Da Spinnaker kein verwalteter Dienst ist, müssen Sie ihn getrennt von der Anwendung bereitstellen und verwalten. Sie können Spinnaker entweder auf separaten Linux-VM-Instanzen oder in einem GKE-Cluster bereitstellen.

Push-basierte Remotebereitstellung

Die in den vorherigen Abschnitten beschriebenen Optionen für eine Pull-basierte Bereitstellung bieten eine Reihe von Vorteilen. Sie sind jedoch nicht für jede Art von Anwendung geeignet. Insbesondere zustandsorientierte Anwendungen eignen sich häufig nicht gut für diesen Ansatz und sind möglicherweise besser für einen Push-basierten Ansatz geeignet.

Beim Push-basierten Ansatz müssen die drei Aufgaben der Bereitstellung (Bereitstellung von VM-Instanzen, Ausführung der Anwendungsbereitstellung und Wartung des Betriebssystems) separat ausgeführt werden. Für alle drei Aufgaben kann ein einziges Tool verwendet werden. Sie können aber auch für jede Aufgabe ein spezielles Tool einsetzen.

Die VM-Instanzen des Anwendungsservers lassen sich auf die gleiche Weise wie andere Infrastrukturen mit Automatisierungstools wie Terraform bereitstellen. Mit Start- oder Spezialisierungsskripts können Sie die Tools installieren, die zur Automatisierung der Anwendungsbereitstellung jeweils erforderlich sind. Wenn Sie beispielsweise Puppet, Chef oder Octopus Deploy verwenden, müssen Sie dafür sorgen, dass die Agent-Software für diese Tools installiert ist.

Achten Sie zum Reduzieren der potenziellen Angriffsfläche aus Sicherheitsgründen darauf, dass die Kommunikation zwischen dem Bereitstellungsserver und allen Agents, die auf den VM-Instanzen des Anwendungsservers ausgeführt werden, über das interne Netzwerk erfolgt. Sorgen Sie außerdem dafür, dass die verwendeten Ports nicht im öffentlichen Internet zugänglich sind.

In einer Umgebung, in der kein Autoscaling verwendet wird, ist die Verknüpfung von Windows-basierten Anwendungsservern mit einer Active Directory-Domain eine sinnvolle Möglichkeit, um die Konfiguration zu zentralisieren. Mit Active Directory können Sie auch Verwaltungsaufgaben wie die Wartung des Betriebssystems steuern.

Bereitstellungsoption auswählen

Wie bereits am Anfang dieses Artikels erwähnt, gibt es nicht nur eine optimale Möglichkeit zur Bereitstellung einer .NET-Anwendung in Google Cloud. Die für Sie optimalen Bereitstellungsoptionen sind von der Anwendung und Ihren Anforderungen abhängig. Für die Auswahl des richtigen Modells müssen Sie als Erstes entscheiden, ob Sie .NET Core oder .NET Framework verwenden und ob Sie, abhängig davon, unter Linux oder Windows bereitstellen möchten. Nach der Festlegung des gewünschten Betriebssystems können Sie anhand der folgenden Entscheidungsbäume das für Sie geeignete Bereitstellungsmodell ermitteln.

Zur Bereitstellung von .NET Core-Anwendungen unter Linux:

Entscheidungsbaum für die Bereitstellung mit .NET Core und Linux

Zur Bereitstellung einer .NET Core- oder .NET Framework-Anwendung unter Windows:

Entscheidungsbaum für die Bereitstellung mit Windows

Nächste Schritte