Concevez une flotte de GameLift conteneurs Amazon

Cette documentation concerne une fonctionnalité en version préliminaire publique. Elle est susceptible d’être modifiée.

Ces rubriques présentent les principales décisions que vous prendrez lors de la configuration d'une flotte de GameLift conteneurs Amazon. Vos décisions ont un impact sur la façon dont vous configurez les paramètres des conteneurs, des groupes de conteneurs et des flottes.

Architectez la structure de votre flotte de conteneurs

Dans un premier temps, identifiez les logiciels et les ressources nécessaires pour héberger votre serveur de jeu, notamment les suivants :

• Votre application de serveur de jeu. L'application doit être intégrée aux GameLift fonctionnalités d'Amazon pour l'hébergement, y compris le SDK du serveur version 5+. veuillez consulter Intégrez votre jeu à Amazon GameLift.

• L' GameLift agent Amazon. Cet agent informatique assure la communication avec le GameLift service Amazon et gère le cycle de vie de tous les processus du serveur de jeu. Pour en savoir plus, consultez Les serveurs de jeu et l' GameLiftagent Amazon.

• Logiciels et ressources supplémentaires selon les besoins. Cela peut inclure les logiciels nécessaires pour exécuter les applications de votre serveur de jeu. Les logiciels de support courants sont utilisés pour la journalisation et la surveillance, la sécurité, la diffusion de contenu et la synchronisation des données.

Ensuite, déterminez comment structurer votre logiciel et vos ressources pour une flotte de GameLift conteneurs Amazon. Amazon GameLift utilise des groupes de conteneurs pour organiser les conteneurs. Une flotte possède toujours un groupe de conteneurs répliques et peut éventuellement comporter une flotte de conteneurs daemon. Pour en savoir plus, consultez Composants du parc de conteneurs.

• Commencez par concevoir votre groupe de répliques de conteneurs. Considérez les directives suivantes :

  • Regroupez votre application de serveur de jeu et l' GameLift agent Amazon dans le même conteneur. Faites de ce conteneur le seul conteneur essentiel du groupe de répliques.

  • Organisez tous les autres logiciels de votre serveur de jeu dans des conteneurs. Vous pouvez choisir de tout placer dans un seul conteneur du groupe de répliques. Vous pouvez également choisir de créer un ou plusieurs conteneurs de sidecar. Voici quelques raisons d'utiliser les sidecars :

    • Pour configurer une séquence de démarrage/arrêt pour un logiciel individuel. Vous pouvez y parvenir en plaçant les logiciels dans des conteneurs distincts et en configurant des dépendances entre eux.

    • Pour définir des limites d'utilisation de la mémoire et du processeur spécifiques au conteneur.

    • Pour spécifier différents paramètres de configuration de conteneur pour chaque conteneur, tels qu'une commande de lancement, un point d'entrée, un répertoire de travail, des variables d'environnement ou des contrôles de santé.

• Décidez si vous avez besoin d'un groupe de conteneurs daemon pour votre flotte. Éléments à prendre en compte :

  • Les conteneurs Daemon sont généralement utilisés pour exécuter des processus d'arrière-plan ou de surveillance.

  • Les conteneurs d'un groupe de démons ne sont pas répliqués sur une instance de flotte. Cela signifie que les conteneurs d'un groupe de démons ne s'adaptent pas au même rythme que le groupe de conteneurs de répliques.

  • Un groupe de démons peut avoir plusieurs conteneurs. Vous pouvez désigner n'importe quel conteneur d'un groupe de démons comme essentiel.

Définissez des limites de ressources

Pour chaque groupe de conteneurs, déterminez la quantité de mémoire et de processeur dont le groupe a besoin pour exécuter son logiciel. Amazon GameLift s'appuie sur ces informations pour gérer les ressources du groupe de conteneurs. Il utilise également ces informations pour calculer le nombre de répliques de groupes de conteneurs qu'une image de flotte peut contenir. Vous pouvez également définir des limites pour des conteneurs individuels.

Définissez des limites facultatives pour les conteneurs

La définition de limites de ressources spécifiques aux conteneurs vous permet de mieux contrôler la manière dont les conteneurs individuels peuvent utiliser les ressources du groupe. Si vous ne définissez pas de limites spécifiques aux conteneurs, tous les conteneurs du groupe partagent les ressources du groupe. Le partage offre une plus grande flexibilité pour utiliser les ressources là où elles sont nécessaires. Cela augmente également le risque de concurrence entre les processus et d'entraîner une défaillance des conteneurs.

Définissez l'une des ContainerDefinition propriétés suivantes pour n'importe quel conteneur.

• SoftLimit(mémoire) — Réservez une quantité minimale de mémoire pour l'usage exclusif du conteneur. Le conteneur dispose toujours de la quantité réservée. Il peut dépasser ce minimum à tout moment, si des ressources supplémentaires sont disponibles.

• HardLimit(mémoire) — Définissez une limite de mémoire maximale pour le conteneur. Si le conteneur dépasse cette limite, cela entraîne un redémarrage.

• Cpulimite — Réservez un minimum de ressources CPU à l'usage exclusif du conteneur. Le conteneur dispose toujours de la quantité réservée. Il peut dépasser ce minimum à tout moment, si des ressources supplémentaires sont disponibles. (1024 unités de processeur équivalent à 1 vCPU.)

Définir des limites de ressources totales pour un groupe de conteneurs

Indiquez à Amazon GameLift la quantité de mémoire et de ressources CPU dont chaque groupe de conteneurs a besoin. L'objectif est d'allouer suffisamment de ressources pour optimiser les performances du serveur de jeu. Amazon GameLift utilise ces limites pour calculer comment regrouper des groupes de conteneurs de répliques sur une instance de flotte. Vous les utiliserez également lorsque vous choisirez un type d'instance pour un parc de conteneurs.

Calculez la mémoire totale et le processeur nécessaires pour tous les processus de chaque conteneur d'un groupe. Éléments à prendre en compte :

• Quels processus s'exécutent dans tous les conteneurs du groupe de conteneurs ? Additionnez les ressources nécessaires à ces processus.

• Combien de processus de serveur de jeu simultanés prévoyez-vous d'exécuter dans chaque groupe de conteneurs ? Vous définissez cette valeur dans le cadre de la configuration d'exécution d'une flotte, mais vous devez prévoir suffisamment de mémoire pour cette flotte ici (voir Optimisation de la configuration d'exécution).

Sur la base de votre estimation des exigences relatives aux groupes de conteneurs, définissez les ContainerGroupDefinition propriétés suivantes :

• TotalMemoryLimit— Définissez une limite de mémoire maximale pour le groupe de conteneurs. Tous les conteneurs du groupe partagent la mémoire allouée. Si vous définissez des limites de conteneur individuelles, la limite de mémoire totale doit être :

  • égal ou supérieur à la somme de toutes les limites de mémoire logicielle du conteneur

  • égal ou supérieur à la limite de mémoire dure la plus élevée pour un conteneur du groupe

• TotalCpuLimit — Définissez une limite maximale de CPU pour le groupe de conteneurs. Tous les conteneurs du groupe partagent les ressources CPU allouées. Si vous définissez des limites de conteneur individuelles, la limite totale du processeur doit être :

  • égal ou supérieur à la somme de toutes les limites du processeur du conteneur. Il est recommandé de définir cette valeur pour doubler la somme des limites du processeur du conteneur.

Exemple de scénario

Supposons que nous définissions un groupe de répliques contenant les trois conteneurs suivants :

• Le conteneur A est notre réplique de conteneur essentielle. Il exécute les processus du serveur de jeu et l' GameLift agent Amazon. Nous estimons les besoins en ressources d'un serveur de jeu à 512 MiB et 1024 CPU. Nous prévoyons de faire exécuter 10 processus serveur par le conteneur. Comme ce conteneur exécute nos logiciels les plus critiques, nous avons défini une réserve de mémoire logicielle de 6 144 MiB et aucune limite de mémoire dure ni limite de réserve du processeur.

• Le conteneur B exécute des logiciels de support dont les besoins en ressources sont estimés à 1 024 Mo et 1 536 processeurs. Nous avons défini une limite de réserve de mémoire logicielle de 1 024 Mo, une limite de mémoire dure de 2 048 Mo et une limite de réserve du processeur de 1 024 Mo de processeur.

• Le conteneur C exécute des utilitaires de journalisation non critiques et d'autres utilitaires de surveillance. Nous avons défini une limite de mémoire dure de 512 Mo et une limite de réserve du processeur de 512 processeurs.

À l'aide de ces informations, nous avons défini les limites totales suivantes pour le groupe de conteneurs :

• Limite de mémoire totale : 7680 MiB. Cette valeur dépasse (1) la somme des limites de mémoire logicielle (6144+1024 Mo) et (2) la limite de mémoire dure la plus élevée (1024 Mo).

• Limite totale du processeur : 13312 processeurs. Cette valeur dépasse la somme de la limite du processeur (1024+512 processeurs).

Désignez les contenants essentiels

Pour chaque contenant, désignez le contenant comme étant essentiel ou non essentiel. Tous les groupes de conteneurs doivent comporter au moins un contenant essentiel. Le conteneur essentiel effectue le travail essentiel du groupe de conteneurs, comme l'hébergement de vos serveurs de jeu. On s'attend à ce que le contenant essentiel fonctionne toujours. En cas d'échec, l'ensemble du groupe de conteneurs redémarre.

• Le groupe de répliques de conteneurs de votre flotte peut contenir exactement un conteneur essentiel. Ce conteneur exécute l' GameLift agent Amazon et les processus du serveur de jeu qu'il gère.

• Si votre flotte possède un groupe de conteneurs daemon, vous pouvez désigner plusieurs conteneurs essentiels. Rendez un conteneur de démons essentiel si vous souhaitez qu'une défaillance de conteneur entraîne le redémarrage d'un groupe de conteneurs.

Définissez la ContainerDefinition propriété Essential sur true ou false pour chaque conteneur.

Configuration des connexions réseau

Vous pouvez établir un accès au réseau pour permettre au trafic externe de se connecter à n'importe quel conteneur d'une flotte de conteneurs. Par exemple, vous devez établir des connexions réseau avec le conteneur qui exécute les processus de votre serveur de jeu, afin que les clients du jeu puissent rejoindre votre jeu et y jouer. Les clients de jeu se connectent aux serveurs de jeux à l'aide de ports et d'adresses IP.

Dans une flotte de conteneurs, la connexion entre un client et un serveur n'est pas directe. En interne, un processus dans un conteneur écoute sur un port à conteneurs. En externe, le trafic entrant se connecte à une instance de flotte via un port de connexion. Amazon GameLift gère les mappages entre les ports de conteneurs internes et les ports de connexion externes, afin que le trafic entrant soit acheminé vers le processus approprié sur l'instance.

Amazon GameLift fournit un niveau de contrôle supplémentaire pour vos connexions réseau. Chaque flotte de conteneurs dispose d'un paramètre d'autorisations entrantes, qui vous permet de contrôler l'accès à chaque port de connexion externe. Vous ne pouvez pas modifier les configurations portuaires d'une flotte existante, mais vous pouvez autoriser ou restreindre l'accès selon les besoins en ajustant les autorisations entrantes. Par exemple, vous pouvez supprimer les autorisations pour tous les ports de connexion afin de bloquer tout accès aux conteneurs de la flotte.

Définissez les plages de ports pour conteneurs

Configurez une définition de conteneur avec suffisamment de ports de conteneur pour tout processus nécessitant un accès externe. Certains conteneurs n'auront pas besoin de ports. Les autres doivent disposer de suffisamment de ports pour en attribuer un à chaque processus qui en a besoin.

Votre groupe de répliques de conteneurs essentiel, qui gère vos serveurs de jeu, a besoin d'un port pour chaque processus de serveur de jeu exécuté simultanément (tel que configuré dans celui de la flotteRuntimeConfiguration). Le processus du serveur de jeu écoute le port attribué et le signale à Amazon GameLift.

Lorsque vous créez une définition de groupe de conteneurs, définissez une plage de ports de conteneurs pour chaque conteneur nécessitant un accès au réseau (voir  ContainerDefinitionInput: PortConfiguration). Assurez-vous que la plage est suffisamment grande pour attribuer un port à chaque processus qui en a besoin. Les processus doivent se voir attribuer des numéros de port dans la configuration des ports du conteneur.

Définissez les plages de ports de connexion

Configurez votre flotte de conteneurs avec un ensemble de ports de connexion. Les ports de connexion fournissent un accès externe aux instances de flotte qui exécutent vos conteneurs. Amazon GameLift attribue des ports de connexion et les mappe aux ports de conteneurs selon les besoins.

Lorsque vous créez un parc de conteneurs, définissez une plage de ports de connexion (voir  ContainerGroupsConfiguration: ConnectionPortRange). Assurez-vous que la plage possède suffisamment de ports pour être mappée à tous les ports de conteneurs d'une instance de flotte. Pour calculer le nombre minimal de ports de connexion nécessaires, utilisez la formule suivante :

[Total number of container ports defined for containers in the replica container group] * [Number of replica container groups per instance] + [Total number of container ports defined for containers in the daemon container group]

Il est recommandé de doubler le nombre minimum de ports de connexion.

Note

Le nombre de ports de connexion peut potentiellement limiter le nombre de groupes de conteneurs de répliques par instance. Si une flotte ne dispose que de suffisamment de ports de connexion pour un seul groupe de conteneurs de répliques par instance, Amazon ne GameLift déploiera qu'un seul groupe de conteneurs de répliques, même si les instances disposent d'une puissance de calcul suffisante pour plusieurs groupes de conteneurs de répliques.

Définir les autorisations de trafic entrant

Les autorisations entrantes contrôlent l'accès externe à une flotte de conteneurs en spécifiant les ports de connexion à ouvrir pour le trafic entrant. Vous pouvez utiliser ce paramètre pour activer ou désactiver l'accès au réseau d'une flotte selon vos besoins.

Lorsque vous créez une flotte de conteneurs, définissez un ensemble d'autorisations entrantes (voir : CreateFleet EC2). InboundPermissions Définissez les propriétés du port d'autorisation entrant pour inclure certaines ou toutes les valeurs dans les paramètres des ports de connexion de la flotte. Pour modifier les autorisations entrantes sur une flotte de conteneurs existante, appelez UpdateFleetPortSettings.

Exemple de scénario

Cet exemple montre comment définir les trois propriétés de connexion réseau.

• Le groupe de répliques de conteneurs de notre flotte comprend 1 conteneur, qui exécute les processus du serveur de jeu. La confirmation d'exécution indique au conteneur d'exécuter 10 processus de serveur de jeu simultanés.

  Dans la définition du groupe de conteneurs de répliques, nous avons défini le PortConfiguration paramètre de ce conteneur comme suit :

  "PortConfiguration": {
    "ContainerPortRanges": [ { "FromPort": 10, "ToPort": 20, "Protocol": "TCP"} ]  } 

• Notre flotte possède également un groupe de conteneurs daemon avec 1 conteneur. Il a 1 processus qui nécessite un accès au réseau. Dans la définition du groupe de conteneurs daemon, nous avons défini le PortConfiguration paramètre de ce conteneur comme suit :

  "PortConfiguration": {
    "ContainerPortRanges": [ { "FromPort": 25, "ToPort": 25, "Protocol": "TCP"} ]  }

• Notre flotte est configurée avec 3 groupes de conteneurs répliques par instance de flotte. À partir de ces informations, nous pouvons utiliser la formule pour calculer le nombre de ports de connexion dont nous avons besoin :

  • Minimum : 31 ports [10 ports de conteneurs répliques* 3 groupes de conteneurs de répliques par instance + 1 port de conteneur de daemon]

  • Meilleure pratique : 62 ports [ports minimum* 2]

  Lors de la création de la flotte de conteneurs, nous avons défini le ConnectionPortRange paramètre ContainerGroupsConfiguration comme suit :

  "ConnectionPortRange": { "FromPort": 1010, "ToPort": 1071 }

• Nous voulons autoriser l'accès à tous les ports de connexion disponibles. Lors de la création de la flotte de conteneurs, nous avons défini le EC2InboundPermissions paramètre comme suit :

  "EC2InboundPermissions": [ 
    {"FromPort": 1010, "ToPort": 1071, "IpRange": "10.24.34.0/23", "Protocol": "TCP"} ]

Configurez des contrôles de santé pour les conteneurs

Un conteneur redémarre automatiquement en cas de panne du terminal et cesse de fonctionner. Si le conteneur est essentiel, l'ensemble du groupe de conteneurs redémarre.

Vous pouvez définir des critères personnalisés supplémentaires pour mesurer l'état du conteneur et utiliser un bilan de santé pour tester ces critères. Pour configurer un contrôle de l'état d'un conteneur, vous pouvez le définir dans une image de conteneur docker ou dans la définition de votre conteneur. Si vous définissez un contrôle de santé dans la définition du conteneur, celui-ci remplace tous les paramètres de l'image du conteneur.

Définissez les contrôles de santé facultatifs en fonction du type de conteneur comme suit :

• Pour un conteneur de répliques essentiel, ne configurez pas les contrôles de santé. L' GameLiftagent Amazon gère automatiquement les rapports sur l'état de santé de ce conteneur.

• Pour les conteneurs de répliques non essentiels et les conteneurs de démons, vous pouvez éventuellement définir des paramètres de contrôle de santé.

Définissez les ContainerDefinition propriétés suivantes pour le contrôle de l'état d'un conteneur :

• Command— Fournissez une commande qui vérifie certains aspects de l'état du conteneur. C'est vous qui décidez des critères à utiliser pour mesurer l'état de santé. La commande doit générer une valeur de sortie de 1 (malsain) ou 0 (sain).

• StartPeriod— Spécifiez un délai initial avant que les échecs du bilan de santé ne commencent à être comptabilisés. Ce délai donne au conteneur le temps de démarrer ses processus.

• Interval— Décidez à quelle fréquence exécuter la commande de contrôle de santé. À quelle vitesse souhaitez-vous détecter et résoudre une panne de conteneur ?

• Timeout— Décidez du temps à attendre en cas de succès ou d'échec avant de réessayer la commande de contrôle de santé. Combien de temps la commande de contrôle de santé doit-elle prendre pour s'exécuter ?

• Retries— Combien de fois la commande de contrôle de santé doit-elle être réessayée avant d'enregistrer un échec ?

Définir les dépendances des conteneurs

Au sein de chaque groupe de conteneurs, vous pouvez définir des dépendances entre les conteneurs en fonction de l'état du conteneur. Une dépendance a un impact sur le moment où le conteneur dépendant peut démarrer ou s'arrêter en fonction de l'état d'un autre conteneur.

L'un des principaux cas d'utilisation des dépendances consiste à créer des séquences de démarrage et d'arrêt pour le groupe de conteneurs.

Par exemple, vous souhaiterez peut-être que le conteneur A démarre en premier et se termine correctement avant le démarrage des conteneurs B et C. Pour ce faire, créez d'abord une dépendance entre le conteneur B et le conteneur A, à condition que le conteneur A soit terminé avec succès. Créez ensuite une dépendance pour le conteneur C sur le conteneur A avec la même condition. Les séquences de démarrage se produisent dans l'ordre inverse de l'arrêt.

Configuration d'une flotte de conteneurs

Lorsque vous créez une flotte de conteneurs, prenez en compte les points de décision suivants. La plupart de ces points dépendent de l'architecture et de la configuration de votre conteneur.

Décidez où vous souhaitez déployer votre flotte

En général, vous souhaitez déployer vos flottes géographiquement à proximité de vos joueurs afin de minimiser le temps de latence. Vous pouvez déployer votre flotte de conteneurs sur n'importe quel Each Région AWS pris GameLift en charge par Amazon. Si vous souhaitez déployer le même serveur de jeu dans d'autres zones géographiques, vous pouvez ajouter des sites distants à la flotte, notamment Régions AWS des Zones Locales. Dans le cas d'un parc multisite, vous pouvez ajuster la capacité indépendamment de chaque emplacement du parc. Pour plus d'informations sur les emplacements de flotte pris en charge, consultezSites GameLift d'hébergement Amazon.

Choisissez un type et une taille d'instance pour votre flotte

Amazon GameLift prend en charge un large éventail de types d'instances Amazon EC2, qui sont tous disponibles pour une utilisation avec un parc de conteneurs. La disponibilité et le prix du type d'instance varient en fonction de l'emplacement. Vous pouvez consulter la liste des types d'instances pris en charge, filtrée par emplacement, dans la GameLift console Amazon (sous Ressources, Instance et quotas de service).

Lorsque vous choisissez un type d'instance, considérez d'abord la famille d'instances. Les familles d'instances offrent différentes combinaisons de capacités de processeur, de mémoire, de stockage et de mise en réseau. Obtenez plus d'informations sur les familles d'instances EC2. Au sein de chaque famille, vous avez le choix entre différentes tailles d'instance. Tenez compte des problèmes suivants lors de la sélection d'une taille d'instance :

• Quelle est la taille d'instance minimale capable de prendre en charge votre charge de travail ? Utilisez ces informations pour éliminer les types d'instances trop petits.

• Quelles tailles de type d'instance conviennent le mieux à votre architecture de conteneur ? Idéalement, vous devez choisir une taille qui puisse accueillir plusieurs copies de votre groupe de conteneurs de répliques avec un minimum d'espace perdu.

• Quelle granularité de mise à l'échelle convient le mieux à votre jeu ? L'augmentation de la capacité du parc implique l'ajout ou la suppression d'instances, et chaque instance représente la capacité d'héberger un nombre spécifique de sessions de jeu. Déterminez la capacité que vous souhaitez ajouter ou supprimer pour chaque instance. Si la demande des joueurs varie de plusieurs milliers d'une minute à l'autre, il peut être judicieux d'utiliser de très grandes instances pouvant héberger des centaines ou des milliers de sessions de jeu. En revanche, vous préférerez peut-être un contrôle de mise à l'échelle plus précis avec des types d'instances plus petits.

• Des économies sont-elles possibles en fonction de la taille ? Il se peut que le coût de certains types d'instances varie en fonction de la situation géographique en raison de la disponibilité.

Optimisez la configuration de votre environnement d'exécution

La configuration d'exécution d'une flotte est un ensemble d'instructions expliquant comment exécuter les processus du serveur pour l'hébergement de sessions de jeu. Ces instructions sont mises en œuvre par l' GameLift agent Amazon dans chaque groupe de répliques de conteneurs de la flotte.

La configuration d'exécution d'une flotte détermine le nombre de processus de serveur exécutés simultanément dans chaque groupe de conteneurs de répliques. Ce paramètre a un impact sur la façon dont vous calculez les limites de ressources de votre groupe de conteneurs et sur la manière dont vous choisissez un type d'instance pour votre flotte. Vous devez équilibrer ces trois éléments lors de la conception de votre flotte.

Pour plus d'informations sur l'utilisation des configurations d'exécution, consultezGérez la façon dont Amazon GameLift lance ses serveurs de jeux.

Définissez d'autres paramètres de flotte facultatifs

Vous pouvez utiliser les fonctionnalités optionnelles suivantes lors de la configuration d'une flotte de conteneurs :

• Configurez vos serveurs de jeu pour accéder à d'autres AWS ressources. veuillez consulter Communiquez avec les autres AWS ressources de vos flottes.

• Empêchez les sessions de jeu avec des joueurs actifs de se terminer prématurément lors d'un événement à réduction progressive.

• Limitez le nombre de sessions de jeu qu'une personne peut créer dans la flotte dans un laps de temps limité.