Applications et versions

Apprenez les concepts et meilleures pratiques de versionnage et d'applications pour une compréhension approfondie.

📦 Applications

Les applications encapsulent des projets serveur. Cette séparation de contexte est particulièrement utile si vous :

• travaillez sur plusieurs jeux ou projets non liés au jeu (facturation consolidée),

• travaillez sur des projets externes en tant que co-développeur (transférer la propriété ultérieurement),

• dépendrez de plusieurs types de serveurs faiblement couplés avec des modèles ou exigences de montée en charge différents.

Vous pouvez gérer vos Applications sur Edgegap en utilisant nos plugins, tableau de bord, ou notre API.

Explorez notre référence de l'API Applications, ou lisez-en plus sur notre API de gestion.

🏷️ Versions d'application

Au fur et à mesure que vous développez votre application et produisez continuellement de nouvelles builds, vous devrez stocker chaque build en tant que version distincte afin de :

• maintenir la compatibilité entre vos clients et le serveur,

• comparer divers aspects de vos versions incrémentales (performances, ressenti des utilisateurs),

• tester plusieurs versions d'application simultanément (développement, assurance qualité, préproduction, bêta).

Chaque version d'application pointe vers un artefact de build de votre choix. Plusieurs versions peuvent pointer vers la même build.

Vous pouvez gérer vos versions d'application sur Edgegap en utilisant notre tableau de bord, ou notre API.

Explorez notre référence de l'API des versions d'application, ou lire davantage sur API.

Chaque version est identifiée de manière unique au sein de son Application parente par nom de la version d'application. Vous êtes libre de définir votre propre convention de nommage. Voici quelques exemples populaires pour inspirer votre choix :

• 2024.01.30-16.23.00-UTC - les horodatages permettent de conserver de nombreuses versions passées de manière transparente,

• 1.1.0 - versionnage sémantique est un excellent choix pour communiquer l'étendue des changements,

• dev , staging, qa, prod - ne conserver que la dernière version par environnement est très simple,

• blue, green - les versions peuvent être utilisées comme alias pour une stratégie de déploiement par basculement progressif.

Vous pouvez changer d'approche à tout moment, tant que vous maintenez la compatibilité client/serveur.

Vous pouvez désactiver toute application ou version dans notre tableau de bord pour prévenir les erreurs humaines (développeur).

Le niveau gratuit est limité à 2 Applications, 2 versions et 5 Go de stockage du registre de conteneurs.

Combiner les stratégies de versionnage

Souvent, la meilleure solution est un mélange de stratégies de versionnage, par exemple :

• utiliser des horodatages ou le versionnage sémantique pour les builds de dev, pour un suivi plus granulaire ;

• conserver staging, qa et prod des versions avec des paramètres spécifiques à l'environnement ;

• alterner blue et green versions comme alias pour mises à jour sans temps d'arrêt du matchmaking.

🧱 Paramètres requis

Ces paramètres fondamentaux doivent toujours être définis.

Exigences en ressources

En plus du nom de la version, plusieurs paramètres sont requis pour créer une nouvelle version :

• vCPU - combien d'unités CPU virtuelles votre application nécessite pour fonctionner (1024 unités = 1 vCPU),

  • la quantité minimale de vCPU autorisée est de 0,25 vCPU (256 unités),

  • ce paramètre ne peut pas être modifié sur une version d'application existante, vous devez créer une nouvelle version.

• Mémoire - combien de mégaoctets de RAM votre application nécessite pour fonctionner (1024MB = 1GB),

  • ce paramètre ne peut pas être modifié sur une version d'application existante, vous devez créer une nouvelle version.

• GPU - combien d'unités de traitement graphique votre application nécessite pour fonctionner,

  • cette fonctionnalité n'est pas encore disponible, veuillez nous contacter si vous êtes intéressé.

Les versions incluent automatiquement de la RAM selon un ratio RAM-vCPU de 2:1, permettant jusqu'à 512 Mo de RAM par 0,25 vCPU.

Nos machines serveurs utilisent des CPU AMD/Intel avec une fréquence de 2,4 à 3,2 GHz, variant selon la localisation. Pour garantir que votre serveur dispose des ressources suffisantes, contactez-nous sur Discord communautaire.

Détails de l'image

Ces paramètres aideront notre système à décider quelle build de votre serveur doit être démarrée plus tard :

• Registre - registry.edgegap.com si vous utilisez notre Registry de conteneurs,

  • pour utiliser un registre tiers, saisissez vos identifiants Docker du registre tiers,

  • le registre sert de service de stockage partagé pour vos dépôts et ceux d'autres utilisateurs.

• Dépôt d'images - fait référence au dépôt dédié de votre Application,

  • trouvez tous vos dépôts sur notre page du registre de conteneurs du tableau de bord,

  • chaque dépôt peut inclure plusieurs tags de votre image serveur.

• Tag - fait référence à un artefact de build (version) spécifique de votre image serveur,

  • nos plugins copient par défaut les valeurs de tag depuis les noms des versions d'application,

  • vous pouvez visualiser les tags stockés localement dans Docker Desktop Images ou en utilisant l'interface en ligne de commande docker.

❌ NE PAS - écraser les tags existants ou utiliser latest tag pour éviter de déployer des builds obsolètes (mis en cache). ✅ FAITES - augmentez toujours votre tag de version pour déployer la build souhaitée et prévenir les problèmes de publication.

• Registre privé - si l'accès à votre dépôt est protégé (dépôt privé), nous aurons également besoin de :

  • jeton d'utilisateur - votre nom d'utilisateur d'accès programmatique au registre,

  • jeton de mot de passe - votre mot de passe d'accès programmatique au registre,

  • pour Edgegap Registry de conteneurs, vous pouvez copier ces valeurs depuis notre tableau de bord,

  • ceux-ci ne sont pas requis pour les dépôts publics.

Les utilisateurs avancés peuvent être intéressés par Unity.

Dépannage et FAQ

J'ai reçu l'erreur 401 Non autorisé lors de la poussée de mon image serveur.

• Cela signifie que vous n'êtes pas connecté à votre registre de conteneurs. Voir le registre de conteneurs pour instructions du registre de conteneurs Edgegap, ou l'équivalent pour votre fournisseur de registre. Répéter votre dernière opération ne résoudra pas l'erreur.

---

J'ai reçu l'erreur 403 Interdit lors de la poussée de mon image serveur.

• Cela signifie soit que l'utilisateur du registre actuellement connecté n'a pas les permissions suffisantes (typiquement pour pousser une nouvelle image), soit que vous êtes connecté au mauvais fournisseur de registre. Essayez de vous déconnecter puis de vous reconnecter avec le fournisseur et l'utilisateur correct disposant des permissions suffisantes. Répéter votre dernière opération ne résoudra pas l'erreur.

---

Quelle est la différence entre un registre, un dépôt et un projet ?

• Considérez le registre comme une installation de stockage, le dépôt comme une unité de stockage, et le projet comme le numéro de l'unité de stockage. Chaque registre inclut généralement de nombreux dépôts, certains publics, d'autres privés pour des organisations et des utilisateurs.

• Exemple de registre : registry.edgegap.com .

• Exemple de dépôt : registry.edgegap.com/my-edgegap-org/my-game-server.

• Exemple de nom de projet : my-game-server .

---

Lorsque je pousse de nouveaux tags / builds, mes modifications ne se rechargent pas correctement.

• Assurez-vous que chaque fois que vous reconstruisez, vous poussez avec un nouveau tag d'image. Le système de cache interne d'Edgegap utilise les noms de tag et si vous écrasez la valeur d'un tag (par ex. latest) il ne détectera pas la nouvelle build.

---

Puis-je taguer le même artefact de build plusieurs fois ?

• Oui, vous pouvez taguer le même artefact plusieurs fois sans problème, servant d'alias multiples vers la même build. Continuez la lecture pour apprendre comment supprimer les tags plus tard.

---

Que se passe-t-il lorsque je supprime un tag ? Pourquoi ne puis-je pas supprimer un artefact spécifique en utilisant un hash ?

• La suppression d'un tag entraînera également la suppression de l'artefact de build associé, s'il n'existe pas d'autres tags associés à l'artefact au moment de la requête API.

• En raison des standards de l'API docker et pour assurer la meilleure expérience utilisateur possible, nous fournissons uniquement une interface pour supprimer des tags. Voir le point ci-dessus concernant la suppression des artefacts de build.

⚙️ Paramètres optionnels

Ces paramètres peuvent être configurés pour personnaliser davantage vos déploiements.

Variables injectées

Des variables d'environnement personnalisées seront injectées pour tous les déploiements sur cette version :

• exemples courants : arguments du moteur, secrets et points de terminaison tiers,

• voir Variables injectées pour comprendre les différentes façons dont les variables d'environnement peuvent être injectées selon le contexte du déploiement, en plus des variables de version d'application,

• chaque variable d'environnement peut contenir jusqu'à 4 Ko (kilooctets) de données sous forme de chaîne.

Assurez-vous de définir vos variables sensibles (secrets, jetons) comme cachées pour plus de sécurité !

Mise en cache active

🌟 Passez au forfait à l'utilisation pour débloquer un temps de déploiement de 0,5 seconde dans le monde entier !

Accélérez les déploiements et démarrez des serveurs en quelques secondes, sans serveurs en veille requis. L'image du serveur associée à cette version d'application sera préchargée automatiquement dans tous nos emplacements mondiaux.

La mise en cache prendra pleinement effet une fois que le niveau de mise en cache de votre version d'application atteindra 🟢 Bon.

Plusieurs versions d'application peuvent réutiliser le même tag d'image. Activer le cache pour une version l'activera automatiquement pour toutes les versions liées au même tag d'image, facilitant les déploiements paramétrés.

L'image est également mise en cache de manière passive lors du déploiement, uniquement sur la machine hôte où elle a été déployée.

Les images sont supprimées du cache si elles ne sont pas déployées pendant 72 heures consécutives.

Mapping de ports

Chaque serveur nécessite au moins un port afin d'accepter les connexions entrantes des clients :

• Port la valeur fait référence au port interne valeur, généralement issue de votre intégration netcode,

• Protocole dépendra du transport de votre intégration netcode,

• Nom est un identifiant lisible par l'humain pour vos besoins propres, peut être identique au Port,

• Vérifications peuvent être activées pour s'assurer que votre conteneur est initialisé avant d'être marqué READY.

La plupart des jeux nécessiteront seulement l'ajout d'un seul mapping de port UDP pour le port 7777.

Alors que les ports internes pour le processus serveur sont définis dans la version d'application, les ports externes sont attribués aléatoirement une fois qu'un déploiement est créé, afin qu'une partie potentiellement malveillante (hacker) soit ralentie et détectée avant de pouvoir causer des dommages.

Ajoutez plus de ports dans votre mapping de ports si votre serveur communique sur plusieurs protocoles.

Garde-fous de sécurité

Ces paramètres aident dans divers cas limites et pour le dépannage général du serveur :

• Contraintes temporelles - ces fonctionnalités peuvent vous aider à gérer le cycle de vie des ressources des déploiements :

  • Durée maximale de la partie peut être définie pour arrêter proprement vos serveurs après une période donnée, ou définie sur -1 avec création/édition de l'API de version d'application pour Persistance avec Flottes privées.

  • Temps maximal de déploiement peut vous aider à nettoyer les déploiements prenant trop de temps à démarrer.

• Stockage des journaux de conteneur - pour exporter les journaux du serveur après l'arrêt du déploiement, spécifiez un bucket compatible S3 préconfiguré pour exporter vos journaux de conteneur,

  • voir Stockage des points de terminaison pour des détails sur la configuration et l'utilisation.

Les journaux des versions sans stockage externe seront supprimés à la terminaison du déploiement.

Le niveau gratuit est limité à 2 Applications, 2 versions et 5 Go de stockage du registre de conteneurs.

⏩ Cohérence des mises à jour

Afin de garantir qu'aucun des paramètres ne change lorsque vous créez une nouvelle version d'application via notre tableau de bord, nous recommandons d'utiliser la Dupliquer fonctionnalité en haut à droite de la page du tableau de bord de votre précédente version d'application. Lors de la duplication, vous pouvez modifier n'importe quel paramètre avant d'enregistrer.

La duplication ou la modification de vos versions d'application ne nécessite pas de reconstruire votre image serveur.

Voir Mises à jour progressives du matchmaker pour plus d' automatisation des publications.