Clusters gérés

En savoir plus sur les clusters gérés et commencer rapidement avec des solutions back-end personnalisées.

✔️ Introduction

Les clusters gérés facilitent et accélèrent l'hébergement de services de jeu autogérés et de backends de jeu. Vous préparez l'image du service et nous fournissons un environnement cloud résilient et à haute disponibilité pour les exécuter :

• authentification des joueurs,

• stockage de données - comptes, progression, inventaire, récompenses, ...

• services sociaux - chat, clans, tableaux de classement, tournois, ...

• matchmaking personnalisé - en utilisant Clusters gérés, Clusters gérés, ...

• calcul sans serveur - géré fonctions en tant que service (alt. cloudscript, lambda), ...

Voir Appariement et Navigateur de serveurs pour commencer avec l'intégration du client de jeu.

Les clusters privés garantissent que vos services disposent de des ressources de calcul dédiées pour servir vos joueurs 24/7.

Nous proposons actuellement 3 niveaux de cluster privé pour répondre aux besoins de chacun :

Niveau	Niveau Hobbyiste	Niveau Studio	Niveau Entreprise
Le mieux adapté pour	les passionnés, les développeurs solo	les lancements commerciaux	les lancements à fort trafic
Ressources	1 vCPU + 2 Go de RAM	6 vCPU + 12 Go de RAM	18 vCPU + 48 Go de RAM
Redondance	1 nœud virtuel	3 nœuds virtuels	3 nœuds virtuels
Limite de débit (req/s)	200	750	2,000
Prix, à l’heure	$0.0312	$0.146	$0.548
Prix, sur 30 jours (utilisation sans interruption)	$22.464	$105.12	$394.56

Nos machines de cluster utilisent des CPU AMD/Intel avec une fréquence de 2,4 - 3,2 GHz. Contactez-nous sur Discord Communautaire pour coordonner les tests de charge et pour vous assurer que votre serveur dispose des ressources suffisantes disponibles.

🛠️ Outils pour développeurs

Si vous voyez une opportunité d'amélioration, veuillez nous en informer dans notre Discord Communautaire.

Nous espérons que vous apprécierez une expérience fluide. 🚀

Docker

Pour aider à rendre votre serveur fiable, nous utilisons Docker - un logiciel de virtualisation garantissant que toutes les dépendances du code serveur jusqu'au niveau du système d'exploitation seront toujours exactement les mêmes, peu importe comment ou où le serveur est lancé.

Nous recommandons de regarder "Ne jamais installer localement" (vidéo). Vous N'AVEZ PAS besoin d'utiliser Dockerhub avec Docker. Docker ≠ Dockerhub. Pensez à Docker comme à un moteur de programmation et à Dockerhub comme à son App Store.

Kubernetes (K8s)

Kubernetes, également connu sous le nom de K8s, est un système open source pour automatiser le déploiement, la mise à l'échelle et la gestion des applications conteneurisées (images Docker). Il regroupe les conteneurs qui composent une application en unités logiques pour une gestion et une découverte faciles.

Les clusters gérés Edgegap fournissent une API Kubernetes à des fins d'administration.

K8s Lens

Avec plus d'un million d'utilisateurs, K8s Lens est l'EDI Kubernetes le plus populaire au monde. Connectez-vous aux clusters, explorez, obtenez des informations, apprenez et agissez si nécessaire. Lens fournit toutes les informations de vos charges de travail et ressources en temps réel, toujours dans le bon contexte.

L'API Kubernetes du cluster Edgegap peut être utilisée via Lens ou d'autres EDI Kubernetes.

Gestionnaire de paquets Helm

Helm est la meilleure façon de trouver, partager et utiliser des logiciels conçus pour Kubernetes. Helm vous aide à gérer les applications Kubernetes - les Helm Charts vous aident à définir, installer et mettre à niveau même les applications Kubernetes les plus complexes. Les charts sont faciles à créer, versionner, partager et publier - alors commencez à utiliser Helm et arrêtez le copier-coller.

Installation de l'interface CLI Helm fournit aux développeurs une interface simple pour gérer leurs packages de cluster.

🚀 Démarrage

☑️ Inscrit pour votre compte Edgegap gratuit et passez au niveau paiement à l'utilisation pour débloquer les clusters.

☑️ Accédez à Clusters gérés page.

☑️ Cliquez sur Créer un cluster d'abord, puis saisissez :

• Étiquette pour votre cluster afin de le retrouver facilement plus tard,

• Taille du cluster - voir ✔️ Introduction.

Nous recommandons fortement de créer des clusters séparés pour vos environnements de développement et de production.

☑️ Vérifiez le coût estimé et cliquez Créer un cluster pour démarrer votre nouveau cluster.

☑️ Une fois le cluster prêt, cliquez sur Kubeconfig pour télécharger votre configuration et vos identifiants pour vous connecter et administrer votre nouveau cluster.

☑️ Déplacez votre fichier kubeconfig pour kubectl pour le trouver.

☑️ Utilisateurs Lens : importez votre fichier kubeconfig.

☑️ Testez la connexion à votre cluster avec la commande kubectl get nodes :

kubectl get nodes
NOM                             STATUT   RÔLES    ÂGE    VERSION
lke334087-533013-294dcfe70000   Prêt     <aucun>   10m   v1.31.0
lke334087-533013-4e69edc10000   Prêt     <aucun>   10m   v1.31.0
lke334087-533013-50bf39880000   Prêt     <aucun>   10m   v1.31.0

🙌 Félicitations, vous avez terminé la configuration du cluster géré ! Vous pouvez maintenant installer vos services.

📦 Nakama par Heroic Labs

Voir Clusters gérés avant de configurer vos services sur les clusters gérés.

Intégrez Edgegap avec plugin Nakama + plugin Unity! Contactez-nous pour d'autres plateformes/fonctionnalités.

Suivez ces étapes pour héberger votre propre Backend de jeu Nakama sur des clusters gérés :

☑️ Installer un Gestionnaire de certificats pour prendre en charge l'utilisation des requêtes HTTPS depuis les clients de jeu :

helm repo add jetstack https://charts.jetstack.io --force-update;
helm upgrade --install cert-manager jetstack/cert-manager \
  --namespace cert-manager --create-namespace \
  --version v1.16.1 --set crds.enabled=true;

☑️ Lens : vérifier l'installation dans la section Services / Réseau, cert-manager devrait être en cours d'exécution.

☑️ Écrire un Cluster Issuer fichier, pensez à remplacer <YOUR_EMAIL> ci-dessous :

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-staging
  namespace: cert-manager
spec:
  acme:
    server: https://acme-staging-v02.api.letsencrypt.org/directory
    email : <YOUR_EMAIL>
    privateKeySecretRef:
      name : letsencrypt-staging
    solvers:
    - http01:
        ingress:
          class: nginx
          

Utilisez letsencrypt-prod pour votre cluster de production privateKeySecretRef.

☑️ Créez un Cluster Issuer en ligne de commande :

kubectl create -f <FILE_PATH>/issuer.yaml

☑️ Lens : vérifier l'installation dans la section Custom Resources / cert-manager.io - cluster issuer créé.

☑️ Installer le Ingress nginx pour recevoir les requêtes des clients et les transmettre aux services du cluster :

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm upgrade --install ingress-nginx ingress-nginx/ingress-nginx \
  --namespace ingress-nginx --create-namespace

☑️ Lens : vérifier l'installation dans la section Services / Réseau, nginx devrait être en cours d'exécution.

☑️ Créez un enregistrement DNS de type A chez votre fournisseur DNS (par ex. Cloudflare), notez l'URL pour plus tard. Votre IP externe pour l'enregistrement DNS peut être trouvée dans Lens sous Services / ingress-nginx-controller .

☑️ Vérifiez que votre DNS est correctement configuré en effectuant une recherche à l'aide de DNSchecker.

☑️ Créez un fichier nommé values.yaml avec le contenu suivant (utilisez vos propres valeurs) :

isProductionEnvironment: true

# Le nom d'hôte externe pour le serveur Nakama - enregistrement DNS de l'étape précédente
externalHostName: <DNS_A_RECORD_URL>

nakama:
  # La version de Nakama à déployer.
  # Voir https://hub.docker.com/r/heroiclabs/nakama/tags pour les versions disponibles.
  version: 3.26.0
  # Nom d'utilisateur et mot de passe pour la console Nakama
  username: <USERNAME>
  password: <PASSWORD>

Remplacez <VALUES> ci-dessus par vos propres valeurs dans le fichier ci-dessus.

☑️ Déployer le chart helm Nakama :

helm upgrade --install \
  --namespace nakama --create-namespace -f <FILE_PATH>/values.yaml \
  --version 1.0.0 <RELEASE_NAME> oci://registry-1.docker.io/edgegap/heroiclabs-nakama

☑️ Lens : vérifiez l'installation dans la section Workloads / Deployments, nakama devrait être en cours d'exécution.

✅ Connectez-vous à votre console Nakama avec l'URL et les identifiants du values.yaml fichier.

🙌 Félicitations, vous avez terminé la configuration du backend de jeu Nakama auto-hébergé !

Mises à jour du service

Suivez ces étapes pour mettre à jour votre service hébergé dans le cluster géré :

☑️ Mettez à jour votre value.yaml fichier avec les nouveaux fichiers.

☑️ Mettez à jour votre chart helm en utilisant cette commande :

helm upgrade --reuse-values \
  --namespace nakama -f <FILE_PATH>/values.yaml \
  --version 1.0.0 <RELEASE_NAME> oci://registry-1.docker.io/edgegap/heroiclabs-nakama

☑️ Rechargez vos modifications en fermant les pods mis à jour, ce qui provoquera l'utilisation du nouveau chart helm après que nous redémarrions automatiquement les pods.

Ceci cette mise à jour provoquera un court temps d'arrêt pendant que les pods redémarrent.

🙌 Félicitations, vous avez terminé la mise à jour du cluster Nakama !

👷 Matchmaker avancé

Voir Clusters gérés avant de configurer vos services sur les clusters gérés.

Suivez ces étapes pour héberger votre OpenMatch sur un cluster géré.

☑️ Installer un Gestionnaire de certificats pour prendre en charge l'utilisation des requêtes HTTPS depuis les clients de jeu :

helm repo add jetstack https://charts.jetstack.io --force-update;
helm upgrade --install cert-manager jetstack/cert-manager \
  --namespace cert-manager --create-namespace \
  --version v1.16.1 --set crds.enabled=true;

☑️ Lens : vérifier l'installation dans la section Services / Réseau, cert-manager devrait être en cours d'exécution.

☑️ Écrire un Cluster Issuer fichier, pensez à remplacer <YOUR_EMAIL> ci-dessous :

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-staging
  namespace: cert-manager
spec:
  acme:
    server: https://acme-staging-v02.api.letsencrypt.org/directory
    email : <YOUR_EMAIL>
    privateKeySecretRef:
      name : letsencrypt-staging
    solvers:
    - http01:
        ingress:
          class: nginx
          

Utilisez letsencrypt-prod pour votre cluster de production privateKeySecretRef.

☑️ Créez un Cluster Issuer en ligne de commande :

kubectl create -f <FILE_PATH>/issuer.yaml

☑️ Lens : vérifier l'installation dans la section Custom Resources / cert-manager.io - cluster issuer créé.

☑️ Installer le Ingress nginx pour recevoir les requêtes des clients et les transmettre aux services du cluster :

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm upgrade --install ingress-nginx ingress-nginx/ingress-nginx \
  --namespace ingress-nginx --create-namespace

☑️ Lens : vérifier l'installation dans la section Services / Réseau, nginx devrait être en cours d'exécution.

☑️ Créez un enregistrement DNS de type A chez votre fournisseur DNS (par ex. Cloudflare), notez l'URL pour plus tard. Votre IP externe pour l'enregistrement DNS peut être trouvée dans Lens sous Services / ingress-nginx-controller .

☑️ Vérifiez que votre DNS est correctement configuré en effectuant une recherche à l'aide de DNSchecker.

☑️ Créez un fichier nommé values.yaml avec le contenu suivant (utilisez vos propres valeurs) :

isProductionEnvironment: false

director:
  credential:
    registry: <VOTRE_REGISTRY_DIRECTOR>
    username: <VOTRE_USERNAME_REGISTRY_DIRECTOR>
    password: <VOTRE_MOT_DE_PASSE_REGISTRY_DIRECTOR>
  image: <IMAGE_DIRECTOR>
  env: {
    "KEY": "VALUE"
  }

mmf:
  credential:
    registry: <REGISTRY_MATCHMAKER_FUNCTION>
    username: <USERNAME_REGISTRY_MATCHMAKER_FUNCTION>
    password: <MOT_DE_PASSE_REGISTRY_MATCHMAKER_FUNCTION>
  image: <IMAGE_MATCHMAKER_FUNCTION>
  env: {
    "KEY": "VALUE"
  }

frontend:
  credential:
    registry: <REGISTRY_FRONTEND>
    username: <USERNAME_REGISTRY_FRONTEND>
    password: <MOT_DE_PASSE_REGISTRY_FRONTEND>
  externalHostName: <VOTRE_NOM_D_HOTE_CLOUDFLARE> # par ex. exemple.test.com
  image: <IMAGE_FRONTEND>
  env: {
    "KEY": "VALUE"
  }

# Configurations globales visibles par tous les sous-charts
global:
  kubernetes:
    resources:
      requests:
        memory: 100Mi
        cpu: 100m
      limits:
        memory: 100Mi
        cpu: 100m

Remplacez <VALUES> ci-dessus par vos propres valeurs dans le fichier ci-dessus.

☑️ Ajoutez le dépôt Edgegap à votre liste de dépôts :

helm repo add edgegap-public https://registry.edgegap.com/chartrepo/edgegap-public

☑️ Déployer le chart helm du matchmaker avancé :

helm upgrade --install \
  --namespace matchmaker --create-namespace -f <FILE_PATH>/values.yaml \
  --version 1.0.1 <RELEASE_NAME> edgegap-public/open-match-edgegap

🙌 Félicitations, vous avez terminé la configuration du Matchmaker avancé !

Mises à jour du service

Suivez ces étapes pour mettre à jour votre service hébergé dans le cluster géré :

☑️ Mettez à jour votre value.yaml fichier avec les nouveaux fichiers.

☑️ Mettez à jour votre chart helm en utilisant cette commande :

helm upgrade --reuse-values \
  --namespace matchmaker -f <FILE_PATH>/values.yaml \
  --version 1.0.1 <RELEASE_NAME> edgegap-public/open-match-edgegap

☑️ Rechargez vos modifications en fermant les pods mis à jour (director, mmf, frontend), ce qui provoquera l'utilisation du nouveau chart helm après que nous redémarrions automatiquement les pods.

Ceci cette mise à jour provoquera un court temps d'arrêt pendant que les pods redémarrent.

🙌 Félicitations, vous avez terminé la mise à jour du Matchmaker avancé !

Déploiement continu

Automatisez la mise à jour de vos services en ajoutant ce script shell à votre pipeline de déploiement :

#!/bin/bash

RELEASE_NAME="<RELEASE_NAME>"
NAMESPACE="matchmaker"  # Changez ceci si vous avez modifié le namespace.

helm upgrade --reuse-values -f <FILE_PATH>/value.yaml --namespace $NAMESPACE --version 1.0.1 $RELEASE_NAME edgegap-public/open-match-edgegap

echo "Installation de redis-tools"
apt-get update
apt-get install -y redis-tools

DIRECTOR_DEPLOYMENT_NAME="$RELEASE_NAME-director"
MMF_DEPLOYMENT_NAME="$RELEASE_NAME-mmf"
CUSTOM_FRONTEND_DEPLOYMENT_NAME="$RELEASE_NAME-custom-frontend"
REDIS_HOST="$RELEASE_NAME-redis-master"

declare -A replicas

# Pour chaque déploiement (director, mmf, custom-frontend) arrêtez les pods
for deployment in $DIRECTOR_DEPLOYMENT_NAME $MMF_DEPLOYMENT_NAME $CUSTOM_FRONTEND_DEPLOYMENT_NAME
do
  echo "Arrêt des pods pour le déploiement : $deployment"
  replicas[$deployment]=$(kubectl get deployment $deployment -o=jsonpath='{.spec.replicas}' --namespace $NAMESPACE)
  kubectl scale deployment/$deployment --replicas=0 --namespace $NAMESPACE
done

# Attendre que les pods soient terminés
for deployment in $DIRECTOR_DEPLOYMENT_NAME $MMF_DEPLOYMENT_NAME $CUSTOM_FRONTEND_DEPLOYMENT_NAME
do

  echo "Attente de la terminaison des pods pour le déploiement : $deployment"
  kubectl wait --for=delete pod -l app=$deployment --timeout=60s --namespace $NAMESPACE

  # Vérifier si la commande wait a réussi. Sinon, quitter le script
  if [ $? -ne 0 ]; then
    echo "Échec de l'attente de la terminaison des pods pour le déploiement : $deployment"
    exit 1
  fi
done

# Nettoyer la base de données redis
echo "Nettoyage de la base de données redis"
redis-cli -h $REDIS_HOST flushall

# Pour chaque déploiement (director, mmf, custom-frontend) restaurez l'échelle des pods à leur nombre d'origine
for deployment in $DIRECTOR_DEPLOYMENT_NAME $MMF_DEPLOYMENT_NAME $CUSTOM_FRONTEND_DEPLOYMENT_NAME
do
  echo "Redimensionnement des pods à ${replicas[$deployment]} pour le déploiement : $deployment"
  kubectl scale deployment/$deployment --replicas=${replicas[$deployment]} --namespace $NAMESPACE
done

Ceci cette mise à jour provoquera un court temps d'arrêt pendant que les pods redémarrent.

Validation du certificat Letsencrypt (C#)

Pour certains clients, la validation de certificat Letsencrypt recommandée peut échouer avec l'erreur :

Erreur Curl 60 : Échec de la vérification du certificat. Le certificat a expiré. Code d'erreur UnityTls : 7

La mise à jour de votre système d'exploitation peut résoudre les problèmes liés à une autorité de certification racine obsolète.

En dernier recours, les clients de jeu peuvent implémenter une fonction personnalisée de gestion des certificats :

```csharp
public class CustomCertificateHandler : CertificateHandler
{
  private readonly string EXPECTED_CERT = "-----BEGIN CERTIFICATE-----<key>-----END CERTIFICATE-----\r\n";
  protected override bool ValidateCertificate(byte[] certificateData)
  {
    X509Certificate2 certificate = new X509Certificate2(certificateData);
    X509Certificate2 expectedCert = new X509Certificate2(Encoding.ASCII.GetBytes(EXPECTED_CERT));

    using (SHA256 sha256 = SHA256.Create())
    {
      Debug.Log("certificate.Thumbprint: " + certificate.Thumbprint);
      Debug.Log("expectedCert.Thumbprint: " + expectedCert.Thumbprint);

      return certificate.Thumbprint == expectedCert.Thumbprint;
    }
  }
}
```

Utilisation :

UnityWebRequest request = UnityWebRequest.Get(...);
request.certificateHandler = new BypassCertificateHandler();
request.SendWebRequest();
request.certificateHandler.Dispose();

Nous recommandons de stocker la EXPECTED_CERT valeur dans votre propre stockage de fichiers, et de la récupérer à l'exécution, afin de pouvoir la mettre à jour sans publier une mise à jour du client de jeu.

🟢 Opérations et observabilité

Changements de niveau de cluster

Préparez-vous au succès et optimisez après le lancement, afin de ne pas bloquer vos joueurs le jour de la sortie.

Changer la taille du cluster nécessite d'arrêter votre cluster. Voir déploiement blue/green pour des mises à jour sans interruption.

Support et mises à jour futures

Votre succès est notre priorité. Si vous souhaitez envoyer des demandes personnalisées, demander des fonctionnalités critiques manquantes, ou exprimer toute remarque, veuillez nous contacter dans notre Discord Communautaire.