Construire un serveur Minecraft dans le cloud pour 2 $ par mois | par Joseph Durant

L’histoire de la façon dont nous avons réduit le prix total de 17 $ à 2 $ par mois

Le défi : mon ami Adam et moi étions en voyage nostalgique et voulions jouer à Minecraft ensemble, comme nous l’avions fait il y a 10 ans après l’école.

La plupart des personnes qui ont exécuté un serveur de jeu à partir de leur ordinateur personnel attesteront à quel point c’est ennuyeux – obligeant l’hôte à être en ligne en même temps, pour que quiconque puisse se connecter. Quelque chose qui ne s’alignerait pas autant maintenant que nous avons tous les deux des responsabilités d’adulte. Nous voulions donc payer pour l’hébergement et éviter cela.

Nous sommes bon marché et Minecraft Realms (l’offre de serveur propriétaire de Mojang) coûte 5,59 £ par mois au Royaume-Uni. En utilisant nos compétences AWS/JS, nous avons pensé que nous pouvions le rendre moins cher.

L’architecture que nous avons imaginée :

Le serveur tourne sur un t3.small Instance EC2, avec les ports requis ouverts au niveau du groupe de sécurité et de la NACL, pour que les utilisateurs puissent communiquer avec elle depuis l’Internet public.

Voici le premier problème : AWS EC2 est facturé pour le temps d’exécution du serveur — pour la région de Londres, un t3.small coûte 0,0236 $ de l’heure, ce qui signifie que si le serveur fonctionnait en permanence, le prix total serait d’environ 17 $ par mois. Nous devions arrêter le serveur lorsqu’il n’était pas utilisé pour réduire les coûts.

Pour ce faire, nous avions besoin que l’exécutable du serveur Minecraft démarre automatiquement au démarrage de l’instance elle-même. Nous avons utilisé un systemd service, qui exécute simplement le server.jar fichier au démarrage, avec la quantité de mémoire requise allouée.

À partir de ce moment, nous aurions pu nous connecter à AWS Management Console chaque fois que nous voulions jouer et démarrer l’instance, mais nous avons imaginé une solution plus élégante.

Adam construit une interface Web avec React, qui déclenche une demande à une fonction Lambda. Cette fonction Lambda, écrite en Python, utilise boto3 pour démarrer l’instance, et à partir de là, le service Linux démarre l’exécutable Java.

Ceux d’entre vous qui sont plus expérimentés avec AWS remarqueront qu’il manque quelque chose ici – les instances EC2 changent bien sûr leur adresse IP lorsqu’elles sont arrêtées et démarrées, à moins qu’une adresse IP Elastic (le nom AWS pour une adresse IP statique) ne leur soit attribuée.

Cela a conduit à notre problème suivant : les adresses IP élastiques ne génèrent des frais que lorsqu’elles ne sont pas affectées à une instance en cours d’exécution. Avec notre utilisation d’EC2, la plupart du temps, l’instance ne fonctionnerait pas. Cela signifierait une charge entre 6 $ et 7 $ par mois, nous plaçant au-dessus de l’objectif de battre Realms sur le prix.

Pour contourner ce problème, nous avons mis à jour Lambda pour renvoyer l’adresse IP publique de l’instance au démarrage, afin qu’elle soit clairement affichée sur le front-end :

Avons-nous donc réussi à battre Realms sur le coût ? Oui.

À son apogée, le coût total du compte n’a atteint que 2,33 $ en un mois. Le serveur est passé à environ 5 à 6 joueurs, et l’instance t3.small pouvait tout gérer sans ralentissement évident. Cependant, c’était pendant la période de niveau gratuit de ce compte, donc votre kilométrage peut varier.

Cela a été construit et testé en même temps – plus un prototype qu’une plate-forme polie. Pour cette raison, tout a été configuré manuellement. J’aimerais vraiment revoir ce projet et le faire reposer sur des instances éphémères, en déconnectant les fonctions lambda de l’arrêt et du démarrage d’une instance spécifique.

Au lieu de cela, il mettrait fin à une instance lors de son arrêt, en lancerait une toute nouvelle et récupérerait les fichiers du serveur à partir d’un volume EBS conservé ou d’un compartiment S3.

Une autre fonctionnalité pratique serait la mise à jour automatique de l’image du serveur – lorsqu’une nouvelle version de Minecraft est publiée, la nouvelle server.jar Le fichier serait automatiquement installé à la place de l’ancien, au lieu d’avoir à le télécharger manuellement.

Les sauvegardes automatisées sont une progression naturelle de ce système, avec une sauvegarde S3 rudimentaire ayant lieu avant l’arrêt de l’instance, dans la conception actuelle.

Pour réaliser tout cela et faciliter la mise à jour, je l’intégrerais également dans un modèle CloudFormation, permettant de suivre les modifications de code via le contrôle de code source et de gérer les modifications à partir d’une seule source faisant autorité.

La gestion manuelle des ressources cloud est pénible et n’évolue pas, ne le faites pas.