Applications et versions

Découvrez le versioning et les applications - concepts et bonnes pratiques pour une compréhension plus approfondie.

📦 Applications

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

• travaillez sur plusieurs jeux ou sur des projets hors jeu (facturation consolidée),

• travaillez sur des projets externes en tant que co-développeur (transfert de propriété ultérieur),

• dépendez de plusieurs types de serveurs faiblement couplés avec des modèles de mise à l'échelle ou des exigences différentes.

Vous pouvez gérer vos applications sur Edgegap à l'aide de nos plugins, tableau de bord, ou de notre API.

Découvrez notre référence de l'API des applications, ou apprenez-en davantage 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 pour :

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

• comparer différents aspects de vos versions incrémentales (performances, retour des utilisateurs),

• tester plusieurs versions de l'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 le même build.

Vous pouvez gérer les versions de votre application sur Edgegap à l'aide de notre tableau de bord, ou de notre API.

Découvrez notre référence de l'API des versions d'application, ou en savoir plus sur l'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 choisir 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 anciennes versions,

• 1.1.0 - le versioning sémantique est un excellent choix pour communiquer l'ampleur des changements,

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

• bleu, vert - les versions peuvent être utilisées comme alias pour une stratégie de déploiement progressif.

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

Vous pouvez désactiver n'importe quelle application ou version dans notre tableau de bord afin de vous protéger contre les erreurs humaines (dev).

Le niveau gratuit est limité à 2 applications, 2 versions et 5 Go de stockage Container Registry.

Combiner les stratégies de versioning

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

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

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

• en alternant bleu et vert les versions comme alias pour des mises à jour sans temps d'arrêt du matchmaking.

🧱 Paramètres requis

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

Exigences en matière de ressources

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

• vCPU - combien d'unités de CPU virtuel votre application a besoin pour fonctionner (1024 unités = 1 vCPU),

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

Vous avez besoin de moins de 0,25 vCPU par déploiement ? Contactez-nous pour explorer les options d'optimisation.

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

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

  • cette fonctionnalité n'est pas encore disponible, veuillez nous contacter si cela vous intéresse.

Les versions incluent automatiquement la RAM dans un ratio RAM-vCPU de 2:1, en accordant 512 Mo de RAM avec 0,25 vCPU.

Nos machines serveur utilisent des CPU AMD/Intel avec une vitesse d'horloge de 2,4 à 3,2 GHz, selon l'emplacement. Pour vous assurer que votre serveur dispose de suffisamment de ressources, contactez-nous sur Discord communautaire.

Détails de l'image

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

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

  • pour utiliser un registre tiers, saisissez les identifiants Docker de votre registre tiers,

  • le registre sert de service de stockage partagé pour vos référentiels et ceux des autres utilisateurs.

• Référentiel d'images - fait référence au référentiel dédié à votre application,

  • retrouvez tous vos référentiels sur la page du registre de conteneurs de notre tableau de bord,

  • chaque référentiel peut inclure plusieurs tags de l'image de votre serveur.

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

  • nos plugins copient par défaut les valeurs des tags à partir des noms des versions d'app,

  • vous pouvez voir les tags stockés localement dans Docker Desktop Images ou en utilisant l'interface CLI docker.

❌ À NE PAS FAIRE - écraser les tags existants ou utiliser latest comme tag pour éviter de déployer des builds obsolètes. ✅ À FAIRE - augmentez toujours le tag de votre version et déployez le nouveau build, en évitant un cache obsolète.

• Registre privé - si l'accès à votre référentiel est protégé (référentiel privé), nous aurons également besoin de :

  • Jeton de nom d'utilisateur - le nom d'utilisateur d'accès programmatique à votre registre,

  • Jeton de mot de passe - le mot de passe d'accès programmatique à votre 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 référentiels publics.

Dépannage et FAQ

J'ai reçu l'erreur 401 Unauthorized lors de l'envoi de l'image de mon serveur.

• Cela signifie que vous ne vous êtes pas connecté à votre registre de conteneurs. Consultez le registre de conteneurs pour obtenir les 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 Forbidden lors de l'envoi de l'image de mon serveur.

• Cela signifie que soit l'utilisateur actuellement connecté à votre registre n'a pas suffisamment de permissions (généralement 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 bon fournisseur et un utilisateur disposant de 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 référentiel et un projet ?

• Voyez le registre comme un espace de stockage, le référentiel comme une unité de stockage et le projet comme un numéro d'unité de stockage. Chaque registre comprend généralement de nombreux référentiels, certains publics, d'autres privés pour les organisations et les utilisateurs.

• Exemple de registre : registry.edgegap.com .

• Exemple de référentiel : registry.edgegap.com/my-edgegap-org/my-game-server.

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

---

Lors de l'envoi de nouveaux tags / builds d'image, mes changements ne se rechargent pas correctement.

• Assurez-vous qu'à chaque fois que vous reconstruisez, vous envoyez avec un nouveau tag d'image. Le système de cache interne d'Edgegap utilise les noms de tags et, si vous écrasez une valeur de tag (par ex. latest) il ne prendra pas en compte le nouveau build.

---

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

• Oui, vous pouvez taguer plusieurs fois le même artefact sans problème, en servant d'alias multiples vers le même build. Continuez à lire pour apprendre à 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 à l'aide d'un hash ?

• Vous devez supprimer tous les tags associés à un artefact spécifique afin de libérer de l'espace dans le registre.

• En raison des normes de l'API Docker et afin d'assurer la meilleure expérience utilisateur possible, nous ne fournissons qu'une interface pour supprimer les tags. Voir le point ci-dessus concernant la suppression des artefacts de build.

⚙️ Paramètres facultatifs

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 :

• les exemples courants incluent : 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 textuelles.

Assurez-vous de définir vos variables sensibles (secrets, jetons) comme masquées pour une sécurité renforcée !

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 lancez les serveurs en quelques secondes, sans serveur de 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 cache de votre version d'application atteindra 🟢 Bon.

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

L'image est également mise en cache passivement au moment 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.

Mappage des ports

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

• Port valeur fait référence à la 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 propres besoins, 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'auront besoin que d'ajouter un seul mappage de port UDP pour le port 7777.

Alors que les ports internes du 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'un éventuel acteur malveillant (pirate) soit ralenti et détecté avant de pouvoir causer des dommages.

Ajoutez davantage de ports dans votre mappage de ports si votre serveur communique via 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 de temps - ces fonctionnalités peuvent vous aider à gérer le cycle de vie des ressources des déploiements :

  • Durée maximale de jeu peut être définie pour arrêter proprement vos serveurs après une certaine période, ou être définie sur -1 avec création/modification via l'API des versions d'application pour Persistance avec Flottes privées.

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

• Politique de redémarrage du processus - contrôle le comportement du déploiement lorsque le processus de votre serveur s'arrête.

  • Toujours redémarrer (par défaut) - redémarrera en cas de code de sortie réussi (0) et de toute sortie en erreur.

  • Ne jamais redémarrer (recommandé) - le déploiement s'arrête en cas de code de sortie réussi et en cas de code de sortie d'erreur.

  • Redémarrer en cas de crash - redémarre uniquement en cas de codes de sortie d'erreur, utile pour les serveurs persistants.

Le niveau gratuit est limité à 2 applications, 2 versions et 5 Go de stockage Container Registry.

Stockage des journaux

Pour exporter les journaux du serveur après l'arrêt du déploiement, configurez Stockage des points de terminaison à l'aide d'un bucket S3.

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

⏩ 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 fonction en haut à droite de la page de tableau de bord de votre version d'application précédente. 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 matchmaking pour plus d' automatisation des mises en production.