View a markdown version of this page

Personnalisez un GameLift Serveurs Amazon flotte de conteneurs - GameLift Serveurs Amazon
Définissez des limites de ressourcesComprenez l'allocation de mémoire d'une flotte de conteneursConfiguration de l'accès au disque NVMeDésignez les contenants essentielsConfiguration des connexions réseauMettre en place des contrôles de santé pour les conteneursDéfinition des dépendances des conteneursConfiguration d'une flotte de conteneurs

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Personnalisez un GameLift Serveurs Amazon flotte de conteneurs

Les rubriques de cette section décrivent certaines fonctionnalités facultatives pour les conteneurs Amazon GameLift Servers gérés. Vous pouvez choisir d'utiliser l'une ou l'ensemble de ces fonctionnalités.

Définissez des limites de ressources

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

Vous pouvez définir une limite maximale de mémoire et de puissance de calcul pour un groupe de conteneurs. Par défaut, ces ressources sont partagées par tous les conteneurs du groupe. Vous pouvez personnaliser davantage la gestion des ressources en définissant des limites pour chaque conteneur.

Définissez des limites facultatives pour les contenants individuels

La définition de limites de ressources spécifiques aux conteneurs vous permet d'exercer un meilleur contrôle sur 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 que les processus entrent en concurrence les uns avec les autres et entraînent la défaillance des conteneurs.

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

  • MemoryHardLimitMebibytes— Définissez une limite de mémoire maximale pour le conteneur. Si le conteneur dépasse cette limite, il en résulte un redémarrage.

  • Vcpulimite : réservez une quantité minimale de ressources vCPU pour l'usage exclusif du conteneur. Le contenant dispose toujours de la quantité réservée. Il peut dépasser ce minimum à tout moment, si des ressources supplémentaires sont disponibles. (1 024 unités de processeur équivalent à 1 processeur virtuel.)

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

Si vous définissez des limites pour des conteneurs individuels, vous devrez peut-être modifier la quantité de mémoire et de ressources vCPU dont le groupe de conteneurs a besoin. L'objectif est d'allouer suffisamment de ressources pour optimiser les performances des serveurs de jeu. Amazon GameLift Serversutilise ces limites pour calculer comment regrouper des groupes de conteneurs de serveurs de jeu sur une instance de flotte. Vous les utiliserez également lorsque vous choisirez un type d'instance pour une flotte de conteneurs.

Calculez la quantité totale de mémoire et de processeur virtuel nécessaires pour un groupe de conteneurs. Éléments à prendre en compte :

  • Quels sont les processus qui s'exécutent sur tous les conteneurs du groupe de conteneurs ? Additionnez les ressources nécessaires à ces processus. Prenez note de toutes les limites spécifiques au conteneur.

  • Combien de processus de serveur de jeu simultanés prévoyez-vous d'exécuter dans chaque groupe de conteneurs ? Vous pouvez le déterminer dans l'image du conteneur de votre serveur de jeu.

Sur la base de votre estimation des besoins en matière de groupes de conteneurs, définissez les ContainerGroupDefinition propriétés suivantes :

  • TotalMemoryLimitMebibytes— 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 conteneurs individuels, la limite de mémoire totale doit être égale ou supérieure à la limite de mémoire spécifique au conteneur la plus élevée.

  • TotalVcpuLimit— Définissez une limite maximale de processeurs virtuels pour le groupe de conteneurs. Tous les conteneurs du groupe partagent les ressources CPU allouées. Si vous définissez des limites de conteneurs individuels, la limite de processeur totale doit être égale ou supérieure à la somme de toutes les limites de processeur spécifiques au conteneur. Il est recommandé de définir cette valeur pour qu'elle double la somme des limites du processeur du conteneur.

Exemple de scénario

Supposons que nous définissions un groupe de conteneurs de serveurs de jeu avec les trois conteneurs suivants :

  • Le conteneur A est le conteneur de notre serveur de jeu. Nous estimons les besoins en ressources d'un serveur de jeu à 512 Mo et 1 024 processeurs. Nous prévoyons de faire exécuter un processus serveur par le conteneur. Comme ce conteneur exécute nos logiciels les plus critiques, nous ne fixons aucune limite de mémoire ou de réserve de vCPU.

  • Le conteneur B est un conteneur de support dont les besoins en ressources sont estimés à 1 024 Mo et 1 536 processeurs. Nous avons défini une limite de mémoire de 2 048 Mo et une limite de réserve de 1 024 processeurs.

  • Le conteneur C est un autre conteneur de support. 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 Mo. Cette valeur dépasse la limite de mémoire la plus élevée (1 024 Mo).

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

Comprenez l'allocation de mémoire d'une flotte de conteneurs

Lorsque vous Amazon GameLift Servers déployez des groupes de conteneurs sur une instance de flotte, la mémoire de l'instance n'est pas entièrement disponible pour vos conteneurs. Amazon GameLift Serversréserve une partie de la mémoire d'instance au système d'exploitation, à l'agent Amazon ECS et à d'autres services de support. La quantité de mémoire réservée varie en fonction de la mémoire totale du type d'instance. Comprendre cette surcharge vous permet de configurer les définitions de vos groupes de conteneurs afin d'utiliser pleinement les ressources disponibles.

Formule de surcharge de mémoire

Amazon GameLift Serverscalcule la mémoire disponible pour vos groupes de conteneurs en suivant les étapes suivantes :

  1. Déterminez le pourcentage de mémoire tampon. Amazon GameLift Serversréserve un pourcentage de la mémoire totale de l'instance en fonction des niveaux suivants :

    Mémoire d'instance (MiB) Pourcentage réservé
    Moins de 5 000 8 %
    5 000 à 9 999 6 %
    10 000 et 89 999 5 %
    90 000 et 199 999 4 %
    200 000 ou plus 3 %

  2. Calculez la mémoire disponible. Soustrayez la mémoire réservée de la mémoire totale de l'instance :

    AvailableMemory = InstanceMemory - round(InstanceMemory × BufferPercentage)

  3. Soustrayez la mémoire du groupe de conteneurs par instance. Si votre flotte utilise un groupe de conteneurs par instance, soustrayez-le TotalMemoryLimitMebibytes de la mémoire disponible. Un groupe de conteneurs par instance s'exécute sur chaque instance de flotte.

    AvailableMemory = AvailableMemory - PerInstanceCGD.TotalMemoryLimitMebibytes

  4. Tenez compte de la surcharge du routeur Log. Si la journalisation est activée pour la flotte, Amazon GameLift Servers réserve 50 Mo supplémentaires par groupe de conteneurs de serveurs de jeu pour le routeur de journalisation.

  5. Calculez le nombre maximum de groupes de conteneurs de serveurs de jeu. Le nombre maximum de groupes de conteneurs de serveurs de jeu pouvant être placés sur l'instance en termes de mémoire est le suivant :

    MaxGroupsByMemory = floor(AvailableMemory / (GameServerCGD.TotalMemoryLimitMebibytes + LogRouterMemory))

    Où LogRouterMemory est 50 Mo si la journalisation est activée, ou 0 si la journalisation est désactivée.

Note

La mémoire n'est qu'un des facteurs qui déterminent le nombre de groupes de conteneurs de serveurs de jeu pouvant contenir une instance. Amazon GameLift Serversprend également en compte la capacité du processeur virtuel et les ports de connexion disponibles, et utilise le minimum des trois calculs.

Exemple de calcul de mémoire

Prenons l'exemple d'une flotte utilisant une c5.xlarge instance (8 192 Mo de mémoire totale) dont la journalisation est activée :

  1. La mémoire d'instance est de 8 192 Mo, ce qui se situe entre 5 000 et 9 999 (6 % de mémoire tampon)

  2. Mémoire réservée = ronde (8 192 × 0,06) = 492 MiB

  3. Mémoire disponible = 8 192 - 492 = 7 700 MiB

  4. Si vous utilisez un groupe de conteneurs par instance TotalMemoryLimitMebibytes de 512 : mémoire disponible = 7 700 - 512 = 7 188 MiB

  5. Si chaque groupe de conteneurs de serveurs TotalMemoryLimitMebibytes de jeu en compte 1 024 : MaxGroupsByMemory = étage (7 188/(1 024 + 50)) = étage (7 188/1 074) = 6

Mémoire disponible par type d'instance

Le tableau suivant indique la mémoire totale et la mémoire disponible (après la mémoire Amazon GameLift Servers tampon) pour les types d'instances couramment utilisés. Utilisez ces valeurs comme point de départ lorsque vous configurez les définitions de vos groupes de conteneurs. La colonne Mémoire disponible indique la mémoire disponible pour tous les groupes de conteneurs de l'instance, avant de soustraire tout groupe de conteneurs par instance ou la surcharge du routeur de journaux.

Type d’instance Mémoire totale (MiB) Pourcentage de mémoire tampon Mémoire disponible (MiB)
c5.large 4 096 8 % 3 768
c5.xlarge 8 192 6 % 7 700
c5.2xlarge 16 384 5 % 15 565
c5.4xlarge 32 768 5 % 31 130
c5.9xlarge 73 728 5 % 70 042
c5.12xlarge 98 304 4 % 94 372
c5.18xlarge 147 456 4 % 141 558
c5.24xlarge 196 608 4 % 188 744
m5.large 8 192 6 % 7 700
m5.xlarge 16 384 5 % 15 565
m5.2xlarge 32 768 5 % 31 130
m5.4xlarge 65 536 5 % 62 259
m5.8xlarge 131 072 4 % 125 829
m5.12xlarge 196 608 4 % 188 744
r5.large 16 384 5 % 15 565
r5.xlarge 32 768 5 % 31 130
r5.2xlarge 65 536 5 % 62 259
r5.4xlarge 131 072 4 % 125 829
c6i.large 4 096 8 % 3 768
c6i.xlarge 8 192 6 % 7 700
c6i.2xlarge 16 384 5 % 15 565
c6i.4xlarge 32 768 5 % 31 130
c6i.8xlarge 65 536 5 % 62 259
c7i.large 4 096 8 % 3 768
c7i.xlarge 8 192 6 % 7 700
c7i.2xlarge 16 384 5 % 15 565
c7i.4xlarge 32 768 5 % 31 130
c7i.8xlarge 65 536 5 % 62 259
m7i.large 8 192 6 % 7 700
m7i.xlarge 16 384 5 % 15 565
m7i.2xlarge 32 768 5 % 31 130
m7i.4xlarge 65 536 5 % 62 259
m7i.8xlarge 131 072 4 % 125 829
m7i.12xlarge 196 608 4 % 188 744
r7i.large 16 384 5 % 15 565
r7i.xlarge 32 768 5 % 31 130
r7i.2xlarge 65 536 5 % 62 259
r7i.4xlarge 131 072 4 % 125 829
c8a.medium 2 048 8 % 1 884
c8a.large 4 096 8 % 3 768
c8a.xlarge 8 192 6 % 7 700
c8a.2xlarge 16 384 5 % 15 565
c8i.large 4 096 8 % 3 768
c8i.xlarge 8 192 6 % 7 700
c8i.2xlarge 16 384 5 % 15 565
m8a.medium 4 096 8 % 3 768
m8a.large 8 192 6 % 7 700
m8a.xlarge 16 384 5 % 15 565
m8a.2xlarge 32 768 5 % 31 130
m8i.large 8 192 6 % 7 700
m8i.xlarge 16 384 5 % 15 565
m8i.2xlarge 32 768 5 % 31 130
c9g.medium 2 048 8 % 1 884
c9g.large 4 096 8 % 3 768
c9g.xlarge 8 192 6 % 7 700
c9g.2xlarge 16 384 5 % 15 565
m9g.large 8 192 6 % 7 700
m9g.xlarge 16 384 5 % 15 565
m9g.2xlarge 32 768 5 % 31 130

Pour les types d'instances non répertoriés ici, vous pouvez calculer la mémoire disponible à l'aide de la formule décrite ci-dessus. Consultez la documentation sur les types d'instance Amazon EC2 pour connaître la mémoire totale du type d'instance que vous avez choisi.

Configuration de l'accès au disque NVMe

Sur les instances de type D, le lecteur NVMe est automatiquement monté dans le /data répertoire lors du démarrage de l'hôte. Pour permettre aux conteneurs d'accéder au stockage SSD, définissez la ContainerGroupDefinition propriété suivante MountPoints :

  • InstancePath— Réglez pour /data faire référence au lecteur NVMe monté automatiquement sur l'instance hôte.

  • AccessLevel— Choisissez le niveau d'accès adapté aux besoins de votre conteneur (par exemple, READ_ONLY ou READ_WRITE).

  • ContainerPath— (Facultatif) Spécifiez le chemin où le chemin de l'instance sera monté à l'intérieur du conteneur. S'il n'est pas spécifié, il utilise par défaut le chemin de l'instance.

Pour plus d'informations sur les points de montage, consultez ContainerMountPoint le manuel Amazon GameLift Servers API Reference.

Désignez les contenants essentiels

Pour un groupe de conteneurs par instance, désignez chaque conteneur comme essentiel ou non essentiel. Per-instance les groupes de conteneurs doivent comporter au moins un contenant de support essentiel. Le contenant essentiel fait le travail essentiel du groupe de conteneurs. On s'attend à ce que le contenant essentiel soit toujours en état de marche. En cas d'échec, l'ensemble du groupe de conteneurs redémarre.

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

Configuration des connexions réseau

Vous pouvez personnaliser l'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 puissent rejoindre votre jeu et y jouer. Les clients de jeu se connectent aux serveurs de jeu à 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 Serversgère les mappages entre les ports de conteneur internes et les ports de connexion externes, afin que le trafic entrant soit acheminé vers le processus approprié sur l'instance. Pour récupérer les mappages de ports actuels pour un groupe de conteneurs spécifique, appelez l'DescribeContainerGroupPortMappingsopération. Pour plus d'informations sur l'affichage des mappages de ports, consultezAfficher les mappages des ports à conteneurs.

Amazon GameLift Serversfournit 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. Par exemple, vous pouvez supprimer les autorisations pour tous les ports de connexion afin de fermer tout accès aux conteneurs de la flotte.

Vous pouvez mettre à jour les autorisations entrantes, les ports de connexion et les ports à conteneurs d'une flotte.

Avertissement

Si vous fournissez une valeur personnalisée InstanceConnectionPortRange ou InstanceInboundPermissions si Amazon GameLift Servers vous ne gérez plus aucune des deux valeurs pour votre flotte. Vous devez définir les deux champs pour éviter tout comportement indéfini.

Définir des plages de ports pour conteneurs

Configurez des plages de ports de conteneur dans le cadre de chaque définition de conteneur. Il s'agit d'un paramètre obligatoire pour la définition d'un groupe de conteneurs. Vous devez configurer suffisamment de ports pour prendre en charge tous les processus en cours d'exécution simultanée nécessitant un accès externe. Certains conteneurs n'auront pas besoin de ports.

Le conteneur de votre serveur de jeu, qui gère vos serveurs de jeu, a besoin d'un port pour chaque processus de serveur de jeu exécuté simultanément. Le processus du serveur de jeu écoute le port attribué et le signale àAmazon GameLift Servers.

Définir des plages de ports de connexion

Configurez votre parc de conteneurs à l'aide d'un ensemble de ports de connexion. Les ports de connexion fournissent un accès externe aux instances de flotte qui gèrent vos conteneurs. Amazon GameLift Serversattribue des ports de connexion et les mappe aux ports de conteneurs selon les besoins.

Par défaut, Amazon GameLift Servers calcule le nombre de ports requis pour tous les groupes de conteneurs et définit une plage de ports pour les accueillir. Nous vous recommandons vivement d'utiliser des valeurs Amazon GameLift Servers calculées, qui sont mises à jour lorsque vous déployez des mises à jour d'une définition de groupe de conteneurs. Si vous devez personnaliser les plages de ports de connexion, suivez les instructions suivantes.

Lorsque vous créez une flotte de conteneurs, définissez une plage de ports de connexion (voir ContainerFleet:InstanceConnectionPortRange). Assurez-vous que la plage comporte suffisamment de ports pour correspondre à tous les ports de conteneurs définis pour tous les conteneurs des deux groupes de conteneurs de la 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 game server container group] * [Number of game server container groups per instance] + [Total number of container ports defined for containers in the per-instance 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 serveurs de jeu par instance. Si une flotte ne dispose que de suffisamment de ports de connexion pour un groupe de conteneurs de serveurs de jeu par instance, elle ne Amazon GameLift Servers déploiera qu'un seul groupe de conteneurs de serveurs de jeu, même si les instances disposent d'une puissance de calcul suffisante pour plusieurs groupes de conteneurs de serveurs de jeu.

Définir les autorisations de réception

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 et désactiver l'accès réseau d'une flotte selon vos besoins.

Par défaut, Amazon GameLift Servers calcule le nombre de ports requis pour tous les groupes de conteneurs et définit une plage de ports pour les accueillir. Nous vous recommandons vivement d'utiliser des valeurs Amazon GameLift Servers calculées, qui sont mises à jour lorsque vous déployez des mises à jour d'une définition de groupe de conteneurs. Si vous devez personnaliser les plages de ports de connexion, suivez les instructions suivantes.

Lorsque vous créez une flotte de conteneurs, définissez un ensemble d'autorisations entrantes (voir ContainerFleet:InstanceInboundPermissions). Les ports d'autorisation entrants doivent correspondre aux plages de ports de connexion de la flotte.

Note

Étant donné que les ports à conteneurs sont sélectionnés au hasard parmi les InstanceConnectionPortRange, afin de garantir la possibilité d'établir des connexions de session, tous les ports InstanceConnectionPortRange entrants doivent être couverts par des ports InstanceInboundPermissions

Exemple de scénario

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

  • Le groupe de conteneurs de serveurs de jeu de notre flotte comprend 1 conteneur, qui exécute 1 processus de serveur de jeu.

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

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

  • Notre flotte dispose également d'un groupe de conteneurs par instance avec 1 conteneur. Il dispose d'un processus qui nécessite un accès réseau. Dans la définition du conteneur par instance, nous définissons le PortConfiguration paramètre de ce conteneur comme suit :

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

  • Notre flotte est configurée avec 20 groupes de conteneurs de serveurs de jeu par instance de flotte. Sur la base de ces informations, nous pouvons utiliser la formule pour calculer le nombre de ports de connexion dont nous avons besoin :

    • Minimum : 21 ports [1 port conteneur de serveur de jeu * 20 groupes de conteneurs de serveurs de jeu par instance + 1 port conteneur par instance]

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

    Lors de la création de la flotte de conteneurs, nous définissons le InstanceConnectionPortRange paramètre comme suit :

    "InstanceConnectionPortRange": { "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 définissons le InstanceInboundPermissions paramètre comme suit : 

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

Mettre en place des contrôles de santé pour les conteneurs

Un conteneur redémarre automatiquement s'il rencontre une panne de terminal et s'arrête de fonctionner. Si un conteneur est considéré comme essentiel, il invite l'ensemble du groupe de conteneurs à redémarrer.

Tous les conteneurs des serveurs de jeu sont automatiquement considérés comme essentiels. Les conteneurs de soutien peuvent être considérés comme essentiels, mais ils doivent être dotés d'un mécanisme permettant de signaler leur état de santé. Vous pouvez également définir des contrôles de santé pour les conteneurs de support non essentiels.

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 votre définition de conteneur. Si vous définissez un bilan de santé dans la définition du conteneur, il remplace tous les paramètres de l'image du conteneur.

Définissez les SupportContainerDefinition 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 donner une valeur de sortie égale à 1 (mauvaise qualité) ou 0 (mauvaise qualité).

  • StartPeriod— Spécifiez un délai initial avant que les échecs du bilan de santé ne commencent à compter. Ce délai donne au conteneur le temps d'amorcer ses processus.

  • Interval— Décidez à quelle fréquence exécuter la commande de vérification de l'état de santé. À quelle vitesse souhaitez-vous détecter et résoudre une panne de conteneur ?

  • Timeout— Décidez combien de temps vous devez attendre en cas de succès ou d'échec avant de réessayer la commande de contrôle de santé. Combien de temps faut-il pour exécuter la commande de vérification de l'état de santé ?

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

Définition des dépendances des conteneurs

Au sein de chaque groupe de conteneurs, vous pouvez définir des dépendances entre les conteneurs en fonction de leur état. 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, à la condition que le conteneur A se termine correctement. 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 la latence. Vous pouvez déployer votre flotte de conteneurs sur tous ceux Région AWS qui le Amazon GameLift Servers souhaitent. Si vous souhaitez déployer le même serveur de jeu sur d'autres sites géographiques, vous pouvez ajouter des sites distants à la flotte, y compris Régions AWS des zones locales. Pour une flotte multi-sites, vous pouvez ajuster la capacité indépendamment de chaque emplacement de flotte. Pour plus d'informations sur les emplacements de flotte pris en charge, consultezGameLift Serveurs Amazon points de service.

Envisagez Balises de ping UDP de collecter des données de latence du réseau dans différentes zones géographiques afin d'anticiper la latence entre les appareils des joueurs et les emplacements potentiels de la flotte. Ces points de terminaison spéciaux acceptent les messages UDP au lieu des pings ICMP traditionnels, fournissant des mesures de latence précises pour vous aider à sélectionner les emplacements de flotte optimaux.

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

Amazon GameLift Serversprend en charge un large éventail de types d'instances Amazon EC2, qui peuvent toutes être utilisées avec une flotte de conteneurs. La disponibilité et le prix des types d'instances varient en fonction de l'emplacement. Vous pouvez consulter la liste des types d'instances pris en charge, filtrés par emplacement, dans la Amazon GameLift Servers console (sous Ressources, Quotas d'instances et de services).

Lorsque vous choisissez un type d'instance, considérez d'abord la famille d'instances. Les familles d'instances proposent différentes combinaisons de fonctionnalité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 pouvez choisir parmi différentes tailles d'instances. Lorsque vous sélectionnez une taille d'instance, tenez compte des points suivants :

  • Quelle est la taille d'instance minimale qui peut prendre en charge votre charge de travail ? Utilisez ces informations pour éliminer tout type d'instance trop petit.

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

  • Quelle granularité de mise à l'échelle convient le mieux à votre jeu ? La capacité de la flotte d'échelle 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 de coûts sont-elles possibles en fonction de la taille ? Vous constaterez peut-être que le coût de certains types d'instances varie en fonction de l'emplacement en raison de la disponibilité.

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 :