Applications et versions

Découvrez la gestion des versions et des applications - concepts et bonnes pratiques pour une compréhension approfondie.

📦 Applications

Les applications encapsulent les 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é plus tard),

• dépendrez de plusieurs types de serveurs faiblement couplés avec des modèles ou exigences d'échelle 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 comme une version séparée afin de :

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

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

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

Chaque version d’App 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’App sur Edgegap en utilisant notre tableau de bord, ou notre API.

Explorez notre référence de l’API des versions d’App, ou lire plus sur API.

Chaque version est identifiée de manière unique au sein de son Application parente par nom de la version d’App. 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 sont transparents pour conserver de nombreuses versions passées,

• 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 mise à jour continue.

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

Vous pouvez désactiver toute App ou Version dans notre tableau de bord vers filet de sécurité contre les erreurs humaines (dev).

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

Combiner des 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 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 les 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’App existante, vous devez créer une nouvelle version.

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

  • ce paramètre ne peut pas être modifié sur une version d’App 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 la RAM selon un ratio RAM-vCPU de 2:1, autorisant jusqu’à 512 Mo de RAM par 0,25 vCPU.

Nos serveurs utilisent des CPU AMD/Intel avec une fréquence de 2,4 - 3,2 GHz, variable selon l’emplacement. Pour garantir que votre serveur dispose de 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 ultérieurement :

• Registre - registry.edgegap.com si vous utilisez notre Registre 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 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 à partir des noms de version d’App,

  • vous pouvez afficher les tags stockés localement dans Docker Desktop Images ou en utilisant le CLI docker.

❌ NE PAS - écraser des tags existants ni utiliser latest tag pour éviter de déployer des builds obsolètes (en cache). ✅ FAITES - incrémentez toujours le tag de votre version pour déployer la build prévue et éviter des problèmes de release.

• 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 pour l’accès programmatique au registre,

  • Jeton de mot de passe - votre mot de passe pour l’accès programmatique au registre,

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

  • ces éléments ne sont pas requis pour les dépôts publics.

Dépannage et FAQ

J’ai reçu l’erreur 401 Non autorisé lorsque je pousse mon image serveur.

• Cela signifie que vous n’êtes pas connecté à votre registre de conteneurs. Voir 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 lorsque je pousse mon image serveur.

• Cela signifie soit que l’utilisateur enregistré actuellement sur le registre 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 et de vous reconnecter avec le fournisseur et l’utilisateur correct ayant 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 comprend typiquement 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 : mon-serveur-de-jeu .

---

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

• Assurez-vous qu’à chaque reconstruction 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 une valeur de 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 de multiples alias vers la même build. Continuez à lire 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’y a pas d’autres tags associés à l’artefact au moment de la requête API.

• En raison des normes de l’API docker et pour garantir la meilleure expérience utilisateur possible, nous fournissons uniquement une interface pour supprimer des tags. Voir le point ci‑dessus concernant la suppression d’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 manières dont les variables d’environnement peuvent être injectées selon le contexte du déploiement, en plus des variables de version d’app,

• chaque variable d’environnement peut contenir jusqu’à 4 Ko (kilooctets) de données 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 niveau Pay as You Go 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 les serveurs en quelques secondes, sans serveurs en veille requis. L’image serveur associée à cette version d’app sera préchargée automatiquement dans tous nos emplacements mondiaux.

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

Plusieurs versions d’app 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 retirées du cache si elles ne sont pas déployées pendant 72 heures consécutives.

Mappage de ports

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

• Port la valeur fait référence au port interne valeur, généralement depuis 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 ne nécessiteront qu’un seul mappage de port UDP pour le port 7777.

Alors que les ports internes pour le processus serveur sont définis comme faisant partie de la version d’app, les ports externes sont attribués au hasard une fois qu’un déploiement est créé, afin qu’une partie potentiellement malveillante (pirate) soit ralentie et détectée avant qu’elle ne puisse causer des dommages.

Ajoutez plus de ports dans votre mappage de ports si votre serveur communique via plusieurs protocoles.

Garde-fous de sécurité

Ces paramètres aident pour divers cas limites et le dépannage général des serveurs :

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

  • Durée maximale du jeu peuvent être définies pour arrêter gracieusement vos serveurs après une période donnée, ou être définies à -1 avec création/édition de l’API de version d’app pour Persistance avec Flottes privées.

  • Temps maximum de déploiement peut vous aider à nettoyer les déploiements qui prennent trop de temps à démarrer.

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

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

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

Le palier 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 paramètre ne change lorsque vous créez une nouvelle version d’App via notre tableau de bord, nous recommandons d’utiliser la Dupliquer fonction en haut à droite de la page du tableau de bord de votre version d’App précédente. Lors de la duplication, vous pouvez modifier n’importe quel paramètre avant d’enregistrer.

Dupliquer ou modifier vos versions d’App ne nécessite pas de reconstruire votre image serveur.

Voir Mises à jour progressives du matchmaker pour davantage d’automatisation des releases.