Verwaltung von GameLift Amazon-Hosting-Ressourcen mit AWS CloudFormation

Sie können es verwenden AWS CloudFormation , um Ihre GameLift Amazon-Ressourcen zu verwalten. In erstellen Sie eine Vorlage AWS CloudFormation, die jede Ressource modelliert, und verwenden dann die Vorlage, um Ihre Ressourcen zu erstellen. Um Ressourcen zu aktualisieren, nehmen Sie die Änderungen an Ihrer Vorlage vor und verwenden AWS CloudFormation sie, um die Aktualisierungen zu implementieren. Sie können Ihre Ressourcen in logische Gruppen, sogenannte Stacks und Stack-Sets, organisieren.

Die Verwendung AWS CloudFormation zur Verwaltung Ihrer GameLift Amazon-Hosting-Ressourcen bietet eine effizientere Möglichkeit, AWS Ressourcensätze zu verwalten. Sie können die Versionskontrolle verwenden, um Vorlagenänderungen im Zeitverlauf zu verfolgen und Aktualisierungen von mehreren Teammitgliedern zu koordinieren. Sie können Vorlagen auch wiederverwenden. Wenn Sie beispielsweise ein Spiel in mehreren Regionen bereitstellen, können Sie dieselbe Vorlage verwenden, um identische Ressourcen in jeder Region zu erstellen. Sie können diese Vorlagen auch verwenden, um dieselben Ressourcensätze in einer anderen Partition bereitzustellen.

Weitere Informationen zu AWS CloudFormation finden Sie im AWS CloudFormation Benutzerhandbuch. Informationen zu Vorlagen für GameLift Amazon-Ressourcen finden Sie in der Referenz zum GameLift Amazon-Ressourcentyp.

Bewährte Methoden

Eine ausführliche Anleitung zur Verwendung AWS CloudFormation finden Sie in den AWS CloudFormation Best Practices im AWS CloudFormation Benutzerhandbuch. Darüber hinaus sind diese Best Practices für Amazon von besonderer Bedeutung GameLift.

• Verwalten Sie Ihre Ressourcen konsequent durch AWS CloudFormation. Wenn Sie Ihre Ressourcen außerhalb AWS CloudFormation Ihrer Ressourcen ändern, werden sie nicht mehr mit Ihren Ressourcenvorlagen synchronisiert.

• Verwenden Sie AWS CloudFormation Stacks und Stack-Sets, um mehrere Ressourcen effizient zu verwalten.

  • Verwenden Sie Stacks, um Gruppen verbundener Ressourcen zu verwalten. Zum Beispiel ein Stack, der einen Build enthält, eine Flotte, die auf den Build verweist, und einen Alias, der auf die Flotte verweist. Wenn Sie Ihre Vorlage aktualisieren, um einen Build zu ersetzen, werden die mit dem Build verbundenen Flotten AWS CloudFormation ersetzt. AWS CloudFormation aktualisiert dann die vorhandenen Aliase so, dass sie auf die neuen Flotten verweisen. Weitere Informationen finden Sie unter Arbeiten mit Stacks im AWS CloudFormation Benutzerhandbuch.

  • Verwenden Sie AWS CloudFormation Stack-Sets, wenn Sie identische Stacks in mehreren Regionen oder AWS Konten bereitstellen. Weitere Informationen finden Sie im AWS CloudFormation Benutzerhandbuch unter Arbeiten mit Stack-Sets.

• Wenn Sie Spot-Instances verwenden, schließen Sie eine On-Demand-Flotte als Alternative ein. Wir empfehlen, Ihre Vorlagen mit zwei Flotten in jeder Region, einer Flotte mit Spot-Instances und einer Flotte mit On-Demand-Instances einzurichten.

• Gruppieren Sie Ihre standortspezifischen Ressourcen und globalen Ressourcen in separaten Stacks, wenn Sie Ressourcen an mehreren Standorten verwalten.

• Platzieren Sie Ihre globalen Ressourcen in der Nähe der Dienste, die sie verwenden. Ressourcen wie Warteschlangen und Matchmaking-Konfigurationen erhalten in der Regel eine große Anzahl von Anfragen von bestimmten Quellen. Indem Sie Ihre Ressourcen in der Nähe der Quelle dieser Anfragen platzieren, minimieren Sie die Reisezeit für Anfragen und können die Gesamtleistung verbessern.

• Platzieren Sie Ihre Matchmakingkonfiguration in derselben Region wie die Spielsitzungswarteschlange, die von ihr verwendet wird.

• Erstellen Sie für jede Flotte im Stack einen separaten Alias.

Verwendung von AWS CloudFormation Stacks

Wir empfehlen, beim Einrichten von AWS CloudFormation Stacks für GameLift Amazon-Ressourcen die folgenden Strukturen zu verwenden. Ihre optimale Stack-Struktur hängt davon ab, ob Sie Ihr Spiel an einem oder an mehreren Standorten einsetzen.

Stapel für einen einzelnen Standort

Um GameLift Amazon-Ressourcen an einem einzigen Standort zu verwalten, empfehlen wir eine Struktur mit zwei Stacks:

• Support-Stack — Dieser Stack enthält Ressourcen, von denen Ihre GameLift Amazon-Ressourcen abhängen. Dieser Stack sollte mindestens den S3-Bucket enthalten, in dem Sie Ihren benutzerdefinierten Spieleserver oder Echtzeit-Skriptdateien speichern. Der Stack sollte auch eine IAM Rolle enthalten, die Amazon die GameLift Erlaubnis erteilt, Ihre Dateien aus dem S3-Bucket abzurufen, wenn Sie eine GameLift Amazon-Build- oder Skriptressource erstellen. Dieser Stack kann auch andere AWS Ressourcen enthalten, die mit Ihrem Spiel verwendet werden, wie DynamoDB-Tabellen, Amazon Redshift Redshift-Cluster und Lambda-Funktionen.

• GameLift Amazon-Stack — Dieser Stack enthält all Ihre GameLift Amazon-Ressourcen, einschließlich des Build oder Skripts, einer Reihe von Flotten, Aliasnamen und der Warteschlange für Spielsitzungen. AWS CloudFormation erstellt eine Build- oder Skriptressource mit Dateien, die im S3-Bucket-Speicherort gespeichert sind, und stellt den Build oder das Skript auf einer oder mehreren Flottenressourcen bereit. Für jede Flotte sollte ein entsprechender Alias vorhanden sein. Die Spielsitzungswarteschlange verweist auf einige oder alle Flottenaliase. Wenn Sie FlexMatch für das Matchmaking verwenden, enthält dieser Stapel auch eine Matchmaking-Konfiguration und einen Regelsatz.

Das folgende Diagramm zeigt eine Struktur mit zwei Stacks für die Bereitstellung von Ressourcen in einer einzigen Region. AWS

Stacks für mehrere Regionen

Beachten Sie bei der Bereitstellung Ihres Spiels in mehr als einer Region, wie Ressourcen in Regionen interagieren können. Einige Ressourcen, wie z. B. GameLift Amazon-Flotten, können nur auf andere Ressourcen in derselben Region verweisen. Andere Ressourcen, wie z. B. eine GameLift Amazon-Warteschlange, sind regionsunabhängig. Um GameLift Amazon-Ressourcen in mehreren Regionen zu verwalten, empfehlen wir die folgende Struktur.

• Regionale Support-Stacks — Diese Stacks enthalten Ressourcen, von denen Ihre GameLift Amazon-Ressourcen abhängig sind. Dieser Stack muss den S3-Bucket enthalten, in dem Sie Ihren benutzerdefinierten Spieleserver oder Echtzeit-Skriptdateien speichern. Es kann auch andere AWS Ressourcen für Ihr Spiel enthalten, wie DynamoDB-Tabellen, Amazon Redshift Redshift-Cluster und Lambda-Funktionen. Viele dieser Ressourcen sind regionsspezifisch, sodass Sie sie in jeder Region erstellen müssen. Amazon benötigt GameLift auch eine IAM Rolle, die den Zugriff auf diese Support-Ressourcen ermöglicht. Da eine IAM Rolle regionsunabhängig ist, benötigen Sie nur eine Rollenressource, die in einer beliebigen Region platziert ist und auf die in allen anderen Support-Stacks verwiesen wird.

• Regionale GameLift Amazon-Stacks — Dieser Stack enthält die GameLift Amazon-Ressourcen, die in jeder Region vorhanden sein müssen, in der Ihr Spiel bereitgestellt wird, einschließlich des Build oder Skripts, einer Reihe von Flotten und Aliasnamen. AWS CloudFormation erstellt eine Build- oder Skriptressource mit Dateien an einem S3-Bucket-Speicherort und stellt den Build oder das Skript für eine oder mehrere Flottenressourcen bereit. Für jede Flotte sollte ein entsprechender Alias vorhanden sein. Die Spielsitzungswarteschlange verweist auf einige oder alle Flottenaliase. Sie können eine Vorlage verwalten, um diese Art von Stack zu beschreiben und sie verwenden, um identische Sätze von Ressourcen in jeder Region zu erstellen.

• Globaler GameLift Amazon-Stack — Dieser Stapel enthält Ihre Warteschlange für Spielsitzungen und Matchmaking-Ressourcen. Diese Ressourcen können sich in jeder beliebigen Region befinden und werden normalerweise in derselben Region platziert. Die Warteschlange kann Flotten oder Aliase referenzieren, die sich in beliebigen Regionen befinden. Um zusätzliche Warteschlangen in verschiedenen Regionen zu platzieren, erstellen Sie zusätzliche globale Stacks.

Die folgenden Diagramme veranschaulichen eine Multistack-Struktur für den Einsatz von Ressourcen in mehreren AWS Regionen. Das erste Diagramm zeigt eine Struktur für eine einzelne Spielsitzungs-Warteschlange. Das zweite Diagramm zeigt eine Struktur mit mehreren Warteschlangen.

Builds werden aktualisiert

GameLift Amazon-Builds sind unveränderlich, ebenso wie die Beziehung zwischen einem Build und einer Flotte. Wenn Sie Ihre Hosting-Ressourcen aktualisieren, um einen neuen Satz von Spiele-Build-Dateien zu verwenden, müssen Sie Folgendes tun:

• Erstellen Sie einen neuen Build mit dem neuen Satz von Dateien (Ersatz).

• Erstellen Sie einen neuen Satz von Flotten, um den neuen Spiel-Build (Ersatz) bereitzustellen.

• Leiten Sie Aliase um, um auf die neuen Flotten zu verweisen (Aktualisierung ohne Unterbrechung).

Weitere Informationen finden Sie unter Verhalten beim Aktualisieren von Stack-Ressourcen im AWS CloudFormation Benutzerhandbuch.

Stellen Sie Build-Updates automatisch bereit

Bei der Aktualisierung eines Stacks, der zugehörige Build-, Flotten- und Alias-Ressourcen enthält, werden diese Schritte standardmäßig AWS CloudFormation automatisch nacheinander ausgeführt. Sie lösen dieses Update aus, indem Sie zuerst die neuen Build-Dateien an einen neuen S3-Speicherort hochladen. Anschließend ändern Sie Ihre AWS CloudFormation Build-Vorlage so, dass sie auf den neuen S3-Speicherort verweist. Wenn Sie Ihren Stack mit dem neuen S3-Speicherot aktualisieren, löst dies die folgende AWS CloudFormation -Sequenz aus:

1. Ruft die neuen Dateien von S3 ab, validiert die Dateien und erstellt einen neuen GameLift Amazon-Build.

2. Aktualisiert die Build-Referenz in der Flottenvorlage, wodurch eine neue Flottenerstellung ausgelöst wird.

3. Wenn die neuen Flotten aktiv sind, wird der Flottenverweis im Alias so aktualisiert, dass der Alias auf die neuen Flotten verweist.

4. Löscht die alte Flotte.

5. Löscht den alten Build.

Wenn Ihre Spielsitzungs-Warteschlange Flottenaliase verwendet, wird der Spielerverkehr automatisch auf die neuen Flotten umgeschaltet, sobald die Aliase aktualisiert werden. Die alten Flotten werden schrittweise von Spielern entfernt, wenn Spielsitzungen enden. Auto Scaling übernimmt die Aufgabe, Instances aus jeder Gruppe von Flotten hinzuzufügen und zu entfernen, wenn der Spielerverkehr schwankt. Alternativ können Sie eine anfängliche Anzahl der gewünschten Instance angeben, um eine schnelle Umstellung und Auto Scaling zu einem späteren Zeitpunkt zu ermöglichen.

Sie können Ressourcen auch AWS CloudFormation beibehalten lassen, anstatt sie zu löschen. Weitere Informationen finden Sie RetainResourcesin der AWS CloudFormation APIReferenz.

Stellen Sie Build-Updates manuell bereit

Wenn Sie mehr Kontrolle darüber haben möchten, wann neue Flotten für Spieler live gehen, bieten sich Ihnen einige Möglichkeiten. Sie können wählen, ob Sie Aliase manuell über die GameLift Amazon-Konsole oder die CLI verwalten möchten. Anstatt Ihre Build-Vorlage zu aktualisieren, um den Build und die Flotten zu ersetzen, können Sie auch einen zweiten Satz von Build- und Flottendefinitionen zur Vorlage hinzufügen. Wenn Sie die Vorlage aktualisieren, AWS CloudFormation erstellt eine zweite Build-Ressource und entsprechende Flotten. Da die vorhandenen Ressourcen nicht ersetzt werden, werden sie nicht gelöscht und die Aliase verweisen weiterhin auf ursprüngliche Flotten.

Der Hauptvorteil bei diesem Ansatz ist, dass er Ihnen Flexibilität verleiht. Sie können separate Ressourcen für die neue Version Ihres Builds erstellen, die neuen Ressourcen testen und kontrollieren, wann die neuen Flotten für Spieler live gehen. Ein potenzieller Nachteil besteht darin, dass in jeder Region für einen kurzen Zeitraum doppelt so viele Ressourcen benötigt werden.

Das folgende Diagramm veranschaulicht diesen Prozess.

Wie funktionieren Rollbacks

Wenn bei einem Ressourcen-Update ein Schritt nicht erfolgreich durchgeführt wurde, löst AWS CloudFormation automatisch ein Rollback aus. Dieser Prozess kehrt jeden Schritt in Folge um und löscht die neu erstellten Ressourcen.

Wenn Sie ein Rollback manuell auslösen müssen, setzen Sie den S3-Speicherortschlüssel der Vorlage auf den ursprünglichen Speicherort zurück und aktualisieren Sie den Stack. Ein neuer GameLift Amazon-Build und eine neue Flotte werden erstellt, und der Alias wird auf die neue Flotte umgestellt, nachdem die Flotte aktiv ist. Wenn Sie Aliase separat verwalten, müssen Sie sie so umschalten, dass sie auf die neuen Flotten verweisen.

Weitere Informationen zum Umgang mit einem fehlgeschlagenen oder hängengebliebenen Rollback finden Sie unter Fortfahren des Rollbacks eines Updates im AWS CloudFormation Benutzerhandbuch.