> For the complete documentation index, see [llms.txt](https://docs.edgegap.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.edgegap.com/fr/learn/orchestration/application-and-versions.md). # Applications et versions Découvrez le versionnement et les applications - concepts et bonnes pratiques pour mieux comprendre en profondeur. ## 📦 Applications Les applications encapsulent des projets serveur. Cette séparation des contextes est particulièrement utile si vous : * travaillez sur plusieurs jeux ou des projets non liés au jeu (facturation consolidée), * travaillez sur des projets externes en tant que co-développeur (transfert de propriété ultérieur), * dépendiez de plusieurs types de serveurs faiblement couplés avec des schémas ou des exigences de mise à l’échelle différents. Vous pouvez gérer vos applications sur Edgegap à l’aide de nos plugins, [tableau de bord](https://app.edgegap.com/application-management/applications/list), ou via notre API. {% hint style="success" %} Découvrez notre [référence de l’API Applications](https://docs.edgegap.com/api/#tag/Applications), ou en savoir plus sur notre [API de gestion](https://docs.edgegap.com/api/). {% endhint %} ## 🏷️ Versions d’application À 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 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). {% hint style="info" %} Chaque version d’application pointe vers un artefact de build de votre choix. Plusieurs versions peuvent pointer vers la même build. {% endhint %} Vous pouvez gérer vos versions d’application sur Edgegap à l’aide de notre [tableau de bord](https://app.edgegap.com/application-management/applications/list), ou via notre API. {% hint style="success" %} Découvrez notre [référence de l’API des versions d’application](https://docs.edgegap.com/api/#tag/Applications/operation/app-version-post), ou en savoir plus sur [l’API](https://docs.edgegap.com/api/). {% endhint %} Chaque version est identifiée de manière unique au sein de son application parente par **nom de 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 sont transparents pour conserver de nombreuses versions passées, * `1.1.0` - [le versionnement sémantique](https://semver.org/) est un excellent choix pour communiquer l’ampleur des changements, * `dev` , `préproduction`, `assurance qualité`, `prod` - ne conserver que la dernière version par environnement est très facile, * `bleu`, `vert` - les versions peuvent servir d’alias pour une stratégie de déploiement par mise à jour progressive. {% hint style="success" %} Vous pouvez modifier votre approche à tout moment, tant que vous maintenez la compatibilité client/serveur. {% endhint %} {% hint style="info" %} Vous pouvez désactiver toute application ou version dans notre [tableau de bord](https://app.edgegap.com/application-management/applications/list) afin de **vous prémunir contre les erreurs humaines (dev)**. {% endhint %} {% hint style="info" %} Le niveau gratuit est limité à 2 applications, 2 versions et 5 Go de stockage Container Registry. {% endhint %} ### Combiner les stratégies de versionnement Souvent, la meilleure solution est un mélange de stratégies de versionnement, par exemple : * utiliser des horodatages ou le versionnement sémantique pour les builds de dev, pour un suivi plus granulaire ; * conserver `préproduction`, `assurance qualité` et `prod` les versions avec des paramètres spécifiques à l’environnement ; * alterner `bleu` et `vert` les versions comme alias pour [des mises à jour sans temps d’arrêt du matchmaking](https://docs.edgegap.com/docs/gen2-matchmaker#rolling-updates-ab-tests). ## 🧱 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 de CPU virtuelles votre application a besoin 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. {% hint style="info" %} Besoin de moins de 0,25 vCPU par déploiement ? [Contactez-nous pour explorer davantage d’options.](mailto:info@edgegap.com) {% endhint %} * **Mémoire** - combien de mégaoctets de RAM votre application a besoin pour fonctionner (1024 Mo = 1 Go), * 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 a besoin pour fonctionner, * cette fonctionnalité n’est pas encore disponible, veuillez nous contacter si vous êtes intéressé. {% hint style="success" %} Les versions incluent automatiquement la RAM selon un ratio RAM:vCPU de 2:1, **permettant jusqu’à 512 Mo de RAM par 0,25 vCPU**. {% endhint %} {% hint style="info" %} Nos machines serveur utilisent des CPU AMD/Intel avec une vitesse d’horloge de 2,4 à 3,2 GHz, variable selon l’emplacement. Pour vous assurer que votre serveur dispose de ressources suffisantes, contactez-nous sur [Discord communautaire](https://discord.gg/MmJf8fWjnt). {% endhint %} ### Détails de l’image Ces paramètres aideront notre système à décider quelle build de votre serveur devra être lancée ultérieurement : * **Registre** - `registry.edgegap.com` si vous utilisez notre [Container Registry](https://docs.edgegap.com/docs/container/edgegap-container-registry), * pour utiliser un registre tiers, saisissez les identifiants Docker de votre registre tiers, * le registre sert de service de stockage partagé pour vos dépôts et ceux des autres utilisateurs. * **Dépôt d’images** - désigne le dépôt dédié à votre application, * retrouvez tous vos dépôts sur notre [page Container Registry du tableau de bord](https://app.edgegap.com/registry-management/repositories/list), * chaque dépôt peut inclure plusieurs tags de votre image serveur. * **Tag** - désigne un artefact de build spécifique (version) de votre image serveur, * nos plugins copient par défaut les valeurs des tags à partir des noms de version d’application, * vous pouvez consulter les tags stockés localement dans Docker Desktop Images ou via la CLI Docker. {% hint style="danger" %} :x: **À NE PAS FAIRE - écraser les tags existants ou utiliser `latest` tag** afin d’éviter de déployer des builds obsolètes (en cache).\ :white\_check\_mark: **À FAIRE - incrémentez toujours votre tag de version** pour déployer la build prévue et éviter des problèmes de publication. {% endhint %} * **Registre privé** - si l’accès à votre dépôt est protégé (dépôt privé), nous aurons aussi besoin de : * **Jeton de nom d’utilisateur** - le nom d’utilisateur d’accès programmatique de votre registre, * **Jeton de mot de passe** - le mot de passe d’accès programmatique de votre registre, * pour Edgegap [Container Registry](https://docs.edgegap.com/docs/container/edgegap-container-registry), vous pouvez [copier ces valeurs depuis notre tableau de bord](https://app.edgegap.com/registry-management/repositories/list), * ceux-ci ne sont pas requis pour les dépôts publics.
Dépannage et FAQ J’ai reçu l’erreur `401 Non autorisé` lors de l’envoi de mon image serveur. * Cela signifie que vous n’êtes pas connecté à votre registre de conteneurs. Consultez Container Registry pour [les instructions du Container Registry Edgegap](https://docs.edgegap.com/docs/container/edgegap-container-registry#getting-your-credentials), 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 l’envoi de mon image serveur. * Cela signifie soit que l’utilisateur actuellement connecté à votre registre ne dispose pas de permissions suffisantes (généralement pour envoyer 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 dépôt et un projet ? * Imaginez le registre comme un entrepôt, le dépôt comme une unité de stockage, et le projet comme le numéro de l’unité de stockage. Chaque registre comprend généralement de nombreux dépôts, certains publics, d’autres privés pour les organisations et les 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 d’image, mes modifications ne se rechargent pas correctement. * Assurez-vous qu’à chaque rebuild, 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 la valeur d’un tag (par ex. `latest`) il ne prendra pas en compte la nouvelle 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, cela servant de multiples alias vers la 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 ? * La suppression d’un tag entraînera également la suppression de l’artefact de build associé, s’il n’y a aucun autre tag associé à l’artefact au moment de [la requête API](https://docs.edgegap.com/api/#tag/Container-Registry/operation/image-tag-delete). * En raison des standards de l’API Docker et afin d’assurer la meilleure expérience utilisateur possible, nous fournissons uniquement 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 de cette version : * les exemples courants incluent : les arguments du moteur, les secrets et points de terminaison tiers, * voir [Déploiements](/fr/learn/orchestration/deployments.md#injected-environment-variables) 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. {% hint style="warning" %} Veillez à **définir vos variables sensibles (secrets, jetons) comme masquées** pour plus de sécurité ! {% endhint %} ### Mise en cache active :star2: [**Passez au niveau Paiement à l’utilisation**](https://app.edgegap.com/user-settings?tab=memberships) **pour débloquer un temps de déploiement de 0,5 seconde dans le monde entier !** **Accélérez les déploiements et lancez des serveurs en quelques secondes, sans serveur de veille requis.** L’image serveur associée à cette version d’application sera préchargée automatiquement dans tous nos emplacements dans le monde. La mise en cache prendra pleinement effet une fois que le niveau de cache de votre version d’application atteindra 🟢 Bon. {% hint style="success" %} 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**, ce qui facilite les déploiements paramétrés. {% endhint %} {% hint style="info" %} L’image est également mise en cache passivement lors du déploiement, uniquement sur la machine hôte où elle a été déployée. {% endhint %} {% hint style="warning" %} **Les images sont retirées du cache si elles ne sont pas déployées pendant 72 heures consécutives.** {% endhint %} ### 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 besoins, peut être identique au Port, * **Vérifications** peuvent être activées pour garantir que votre conteneur est initialisé avant d’être marqué READY. {% hint style="success" %} La plupart des jeux nécessiteront seulement l’ajout d’un mappage de port UDP unique pour le port `7777`. {% endhint %} 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 le déploiement créé**, afin qu’un éventuel acteur malveillant (pirate) soit ralenti et détecté avant de pouvoir causer des dommages.
{% hint style="info" %} Ajoutez davantage de ports dans votre mappage de ports si votre serveur communique via plusieurs protocoles. {% endhint %} ### Garde-fous de sécurité Ces paramètres aident à traiter divers cas particuliers et 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 partie** peut être défini pour arrêter proprement vos serveurs après une période donnée, ou défini sur `-1` avec [création/modification de l’API de version d’application](/fr/docs/api/gestion-des-versions.md#post-v1-app-app_name-version) pour [Persistance](/fr/learn/orchestration/persistance.md) avec [Fleets privées](/fr/learn/orchestration/fleets-privees.md). * **Temps maximal 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 votre processus 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 codes de sortie de succès et d’erreur. * Redémarrer en cas de plantage - redémarre uniquement en cas de codes de sortie d’erreur, utile pour les serveurs persistants. {% hint style="info" %} Le niveau gratuit est limité à 2 applications, 2 versions et 5 Go de stockage Container Registry. {% endhint %} ### Stockage des journaux Pour exporter les journaux du serveur après l’arrêt du déploiement, configurez [Stockage des points de terminaison](/fr/docs/endpoint-storage.md) à l’aide d’un bucket S3. {% hint style="warning" %} Les journaux des versions sans stockage externe seront supprimés à la fin du déploiement. {% endhint %} ## ⏩ Cohérence des mises à jour Afin de garantir qu’aucun paramètre ne change lorsque vous créez une nouvelle version d’application via notre [tableau de bord](https://app.edgegap.com/application-management/applications/list), nous recommandons d’utiliser la **Dupliquer** fonctionnalité en haut à droite de la page du 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. {% hint style="success" %} **Dupliquer ou modifier vos versions d’application ne nécessite pas de reconstruire votre image serveur.** {% endhint %} {% hint style="info" %} Voir [Mises à jour progressives du matchmaker](https://docs.edgegap.com/docs/gen2-matchmaker#rolling-updates-ab-tests) pour davantage **d’automatisation des publications**. {% endhint %}