> 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

Fonctionnement des applications et versions Edgegap, avec les bonnes pratiques pour versionner les builds de serveurs de jeu et séparer les environnements.

Découvrez le versioning et les applications — concepts et bonnes pratiques pour mieux comprendre.

## 📦 Applications

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

* travaillez sur plusieurs jeux ou 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 schémas de montée en charge ou des exigences 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 de notre API.

{% hint style="success" %}
Découvrez notre [documentation 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

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

* **maintenir la compatibilité** entre vos clients et le serveur,
* comparer différents 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).

{% 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 de notre API.

{% hint style="success" %}
Découvrez notre [documentation de l'API des versions d'application](https://docs.edgegap.com/api/#tag/Applications/operation/app-version-post), ou en savoir plus sur [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 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 sont pratiques pour conserver de nombreuses versions passées,
* `1.1.0` - [le versioning sémantique](https://semver.org/) 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,
* `bleu`, `vert` - les versions peuvent être utilisées comme 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 n'importe quelle application ou version dans notre [tableau de bord](https://app.edgegap.com/application-management/applications/list) à **protection contre les erreurs humaines (dev)**.
{% endhint %}

{% hint style="info" %}
Le niveau gratuit est limité à 2 applications, 2 versions et 10 Go de stockage du registre de conteneurs.
{% endhint %}

### 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, pour un suivi plus granulaire ;
* conserver `staging`, `qa` et `prod` des versions avec des paramètres spécifiques à l'environnement ;
* alterner `bleu` et `vert` des 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 obligatoires

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 virtuel votre application a besoin pour fonctionner (1024 unités = 1 vCPU),
  * **la quantité minimale de vCPU autorisée est 0,25 vCPU (256 unités),**

{% hint style="info" %}
Besoin de moins de 0,25 vCPU par déploiement ? [Contactez-nous pour explorer les options d'optimisation.](mailto:info@edgegap.com)
{% endhint %}

* **Mémoire** - combien de mégaoctets de RAM votre application nécessite pour fonctionner (1024 Mo = 1 Go),
* **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é.

{% hint style="success" %}
Les versions incluent automatiquement de la RAM selon un ratio RAM-vCPU de 2:1, **offrant 512 Mo de RAM avec 0,25 vCPU**.
{% endhint %}

{% hint style="info" %}
Nos serveurs utilisent des CPU AMD/Intel avec une fréquence allant jusqu'à 3,7 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 démarré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'image** - désigne le dépôt dédié à votre application,
  * retrouvez tous vos dépôts sur notre [page Registre de conteneurs du tableau de bord](https://app.edgegap.com/registry-management/repositories/list),
  * chaque dépôt peut inclure plusieurs tags de votre image de serveur.
* **Tag** - désigne un artefact de build spécifique (version) de votre image de serveur,
  * nos plugins copient par défaut les valeurs des tags à partir des noms des versions d'application,
  * vous pouvez voir les tags stockés localement dans Docker Desktop Images ou à l'aide de l'interface CLI Docker.

{% hint style="danger" %}
:x: **NE PAS - écraser les balises existantes ou utiliser `latest` balise** - cela déploiera un cache obsolète.\
:white\_check\_mark: **FAITES - augmentez toujours votre balise de version** et déployez la nouvelle build.
{% endhint %}

* **Registre privé** - si l'accès à votre dépôt est protégé (dépôt privé), nous aurons également besoin de :
  * **Jeton d'identifiant** - 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),
  * elles ne sont pas requises pour les dépôts publics.

<details>

<summary>Dépannage et FAQ</summary>

J'ai reçu l'erreur `401 Non autorisé` lors de l'envoi de mon image de serveur.

* Cela signifie que vous ne vous êtes pas connecté à votre registre de conteneurs. Consultez Registre de conteneurs pour [les instructions du Registre de conteneurs 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 de serveur.

* Cela signifie soit que l'utilisateur actuellement connecté à votre registre ne dispose pas des autorisations 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 d'autorisations 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 ?

* Voyez le registre comme un entrepôt de stockage, le dépôt comme une unité de stockage, et le projet comme un numéro d'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 j'envoie de nouveaux tags / builds d'image, mes modifications ne se rechargent pas correctement.

* Assurez-vous que 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. `dernier`) il ne prendra pas en compte la nouvelle build.

***

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

* Oui, vous pouvez taguer le même artefact plusieurs fois sans problème, en servant d'alias multiples 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 à 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 standards de l'API Docker et afin d'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.

</details>

## ⚙️ 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 : arguments du moteur, secrets et points de terminaison tiers,
* voir [Déploiements](/fr/learn/orchestration/deployments.md#injected-environment-variables) pour comprendre les différentes façons d'injecter des variables d'environnement 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" %}
Assurez-vous de **définir vos variables sensibles (secrets, jetons) comme masquées** pour plus de sécurité !
{% endhint %}

### Cache actif

:star2: [**Passez à l'offre 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 démarrez 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 dans le monde.

Le 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. **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.
{% endhint %}

{% hint style="info" %}
L'image est également mise en cache passivement lors du déploiement, uniquement sur la machine hôte sur laquelle elle a été déployée.
{% endhint %}

{% hint style="warning" %}
**Les images sont supprimé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** la valeur désigne 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 à Port,
* **Vérifications** peuvent être activées pour garantir que votre conteneur est initialisé avant d'être marqué PRÊT.

{% hint style="success" %}
La plupart des jeux nécessiteront seulement l'ajout d'un seul mappage de port UDP 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 qu'un déploiement est créé**, afin qu'une éventuelle partie malveillante (pirate) soit ralentie et détectée avant de pouvoir causer des dégâts.

<figure><img src="https://3008966946-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FsR0dHSFv9ymoC0DO5G8J%2Fuploads%2FXfDDoCk7J4O9qtkkjurh%2Fimage.png?alt=media&amp;token=a509cc92-a410-4658-9dcd-b032497debb5" alt=""><figcaption></figcaption></figure>

{% hint style="info" %}
Ajoutez d'autres ports dans votre mappage de ports si votre serveur communique via plusieurs protocoles.
{% endhint %}

### Garde-fous de sécurité

Ces paramètres aident à gérer divers cas limites 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 la partie** peut être définie pour arrêter proprement vos serveurs après une période donnée, ou réglée sur `-1`  avec [création/modification de l'API des versions d'application](/fr/docs/api/gestion-des-versions.md#post-v1-app-app_name-version) pour [Persistance](/fr/learn/orchestration/persistance.md) avec [Flottes privées](/fr/learn/orchestration/flottes-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 réussis et en erreur.
  * Redémarrer en cas de plantage - redémarre uniquement en cas de codes de sortie en erreur, utile pour les serveurs persistants.

{% hint style="info" %}
Le niveau gratuit est limité à 2 applications, 2 versions et 10 Go de stockage du registre de conteneurs.
{% 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 des paramètres 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 quels paramètres avant d'enregistrer.

{% hint style="success" %}
**La duplication ou la modification de vos versions d'application ne nécessite pas de reconstruire votre image de serveur.**
{% endhint %}

{% hint style="info" %}
Voir [Mises à jour progressives du matchmaking](https://docs.edgegap.com/docs/gen2-matchmaker#rolling-updates-ab-tests) pour une **automatisation des mises en production**.
{% endhint %}
