Clusters gérés

Découvrez les Managed Clusters et commencez rapidement avec des solutions backend personnalisées.

✔️ Introduction

Les Managed Clusters facilitent et accélèrent l'hébergement de services de jeu auto-gérés et de backends personnalisés. 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, ...
compute serverless - géré fonctions en tant que service (alt. cloudscript, lambda), ...

Voir Matchmaking et Navigateur de serveurs pour commencer à intégrer le client de jeu.

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

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

Niveau

Niveau Hobbyist

Niveau Studio

Niveau Enterprise

Idéal pour

passionnés, développeurs solo

versions commerciales

lancements à fort trafic

Ressources

1 vCPU + 2 Go de RAM

6 vCPU + 12 Go de RAM

18 vCPU + 48 Go de RAM

Redondance

1x nœud virtuel

3x nœuds virtuels

Limite de débit (req/s)

200

750

2,000

Prix, horaire

$0.0312

$0.146

$0.548

Prix, 30 jours (utilisation continue)

$22.464

$105.12

$394.56

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

🛠️ Outils pour développeurs

Si vous voyez une opportunité d'amélioration, veuillez nous le faire savoir dans notre Community Discord.

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 pour garantir que toutes les dépendances de votre 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. Considérez 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 d'applications conteneurisées (images Docker). Il regroupe les conteneurs qui constituent une application en unités logiques pour une gestion et une découverte faciles.

Les Edgegap Managed Clusters fournissent une API Kubernetes pour des besoins d'administration.

K8s Lens

Avec plus d'un million d'utilisateurs, K8s Lens est l'IDE Kubernetes le plus populaire au monde. Connectez-vous aux clusters, explorez, obtenez des informations, apprenez et prenez des mesures lorsque nécessaire. Lens fournit toutes les informations de vos workloads 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 IDE Kubernetes.

Gestionnaire de paquets Helm

Helm est le meilleur moyen 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 du CLI Helm fournit aux développeurs une interface simple pour gérer leurs packages de cluster.

🚀 Pour commencer

☑️ Inscrit pour votre compte Edgegap gratuit et passez au niveau pay-as-you-go pour débloquer les Clusters.

☑️ Naviguez vers Managed Clusters page.

☑️ Cliquez sur Create 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.

☑️ Passez en revue le coût estimé et cliquez Create 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 de Lens : importez votre fichier kubeconfig.

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

kubectl get nodes
NAME                            STATUS   ROLES    AGE    VERSION
lke334087-533013-294dcfe70000   Ready    <none>   10m   v1.31.0
lke334087-533013-4e69edc10000   Ready    <none>   10m   v1.31.0
lke334087-533013-50bf39880000   Ready    <none>   10m   v1.31.0

🙌 Félicitations, vous avez terminé la configuration du Managed Cluster ! Vous pouvez maintenant installer vos services.

📦 Nakama par Heroic Labs

Voir Clusters gérés avant de configurer vos services sur des 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 Nakama Game Backend sur Managed Clusters :

☑️ 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.

☑️ Rédiger un Cluster Issuer fichier, n'oubliez pas de 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 client et les transmettre aux services dans le 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 en utilisant 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éployez 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 Nakama Game Backend auto-hébergé !

Mises à jour du service

Suivez ces étapes pour mettre à jour votre service hébergé dans le Managed Cluster :

☑️ 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 fera que le nouveau chart helm sera utilisé après que nous redémarrions automatiquement les pods.

Ceci cette mise à jour entraînera une courte interruption de service pendant le redémarrage des pods.

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

👷 Matchmaker avancé

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

Suivez ces étapes pour héberger votre OpenMatch sur un Managed Cluster.

☑️ 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.

☑️ Rédiger un Cluster Issuer fichier, n'oubliez pas de 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 client et les transmettre aux services dans le 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 en utilisant DNSchecker.

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

isProductionEnvironment: false

director:
  credential:
    registry: <YOUR_DIRECTOR_REGISTRY>
    username: <YOUR_DIRECTOR_REGISTRY_USERNAME>
    password: <YOUR_DIRECTOR_REGISTRY_PASSWORD>
  image: <DIRECTOR_IMAGE>
  env: {
    "KEY": "VALUE"
  }

mmf:
  credential:
    registry: <MATCHMAKER_FUNCTION_REGISTRY>
    username: <MATCHMAKER_FUNCTION_REGISTRY_USERNAME>
    password: <MATCHMAKER_FUNCTION_REGISTRY_PASSWORD>
  image: <MATCHMAKER_FUNCTION_IMAGE>
  env: {
    "KEY": "VALUE"
  }

frontend:
  credential:
    registry: <FRONTEND_REGISTRY>
    username: <FRONTEND_REGISTRY_USERNAME>
    password: <FRONTEND_REGISTRY_PASSWORD>
  externalHostName: <YOUR_CLOUDFLARE_HOST_NAME> # ex. exemple.test.com
  image: <FRONTEND_IMAGE>
  env: {
    "KEY": "VALUE"
  }

# Configurations globales visibles par tous les subcharts
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éployez 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 Managed Cluster :

☑️ 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 fera que le nouveau chart helm sera utilisé après que nous redémarrions automatiquement les pods.

Ceci cette mise à jour entraînera une courte interruption de service pendant le redémarrage des pods.

🙌 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"  # Modifiez ceci si vous avez changé 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érifiez si la commande wait a réussi. Sinon, quittez 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), redimensionnez les pods à leur nombre initial
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 entraînera une courte interruption de service pendant le redémarrage des pods.

Validation du certificat Letsencrypt (C#)

Pour certains clients, la validation recommandée du certificat Letsencrypt 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 gestionnaire de certificat :

```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 valeur EXPECTED_CERT 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é

Modifications du 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 partager vos remarques, veuillez rejoindre notre Community Discord.

PrécédentRegistre de conteneurs SuivantRelais (P2P)

Mis à jour il y a 14 jours

Ce contenu vous a-t-il été utile ?