Beaucoup de choses ont été écrites sur l'histoire des conteneurs au fil des ans, et il est toujours surprenant pour moi que beaucoup de personnes avec qui nous parlons dans l'industrie du jeu n'aient pas encore commencé à chercher des moyens de les utiliser dans leurs efforts pour la scalabilité et l'automatisation. Cependant, c'est compréhensible : ils se concentrent sur ce qui compte pour eux, à savoir leurs jeux, le plaisir des joueurs et la gestion des opérations.

Entre-temps, cependant, les développeurs d'applications et de sites Web ont pleinement utilisé le potentiel de scalabilité et d'économies de coûts de cette technologie. Je vais présenter ma (très humble) perspective sur l'histoire des conteneurs, et pourquoi tout cela est sur le point de changer pour les studios de jeux dans les mois à venir.

L'histoire des conteneurs commence avec la virtualisation

Le concept de virtualisation est une excellente idée. Créer une couche d'abstraction pour utiliser les ressources physiques de manière plus efficace. J'en ai entendu parler pour la première fois en 2003 lorsque j'étais chez Bell Mobility, envisageant de lancer EVDO, par un représentant de Sun Microsystems qui avait cette « nouvelle technologie » qu'il voulait montrer. C'était VMWare, une entreprise que nous ne connaissions pas, qui venait de lancer Virtual Center & Vmotion.

En tant que passionnés de technologie, nous étions très intéressés par cette technologie, mais toute l'équipe d'ingénierie avait des doutes significatifs. Ces doutes étaient justifiés puisque nous poussions déjà notre matériel à sa limite. Le trafic CDMA explosait, les gens commençaient à utiliser des téléphones pour les données, et nous devions nous développer à un rythme fou. Utiliser une petite partie de cette précieuse ressource pour « les diviser » en plusieurs VM n'apportait pas beaucoup de valeur. De plus, les fournisseurs d'applications nous empêchaient de passer à la VM pour des « raisons de support ». Cela n'avait pas beaucoup de sens et avait peu de valeur à l'époque.

Défis des machines virtuelles

Nous savons maintenant ce qui est arrivé à VMWare et à de telles technologies. SDN/NFV, Openstack, etc. sont devenus la norme. Cela a permis une gestion des « applications » beaucoup plus flexible grâce à cette couche abstraite. Un grand merci à l'ingénieur d'Amazon qui a vu cette vague arriver. Les machines virtuelles nous ont facilité la tâche, et ont apporté une pléthore d'outils pour faciliter la vie des SysAdmin, développeurs et DevOps. Les serveurs sont devenus beaucoup plus puissants, donc tout à coup, le tas de ressources nécessaires à la virtualisation n'était pas aussi nuisible que les avantages qu'il pouvait apporter.

Un problème persistait avec cette couche virtuelle : « Le système opérationnel ». Pour chaque machine virtuelle, nous avons été contraints d'emballer le système d'exploitation selon les exigences de l'application. Même pour la même application, pour chaque instance, il fallait stocker deux fois le système d'exploitation, exécuter deux fois chaque composant pour ce système d'exploitation, et ajouter encore une autre couche d'éléments inutiles pour l'utilisateur final. Résoudre ce problème est le prochain chapitre de l'histoire des conteneurs.

La solution

Trois ans après avoir entendu parler pour la première fois de VMware, des gars intelligents de Google ont commencé à travailler sur quelque chose appelé Cgroup. Leur objectif était d'isoler les ressources des applications. Ce travail, en liaison avec l'isolement de l'espace de noms, a créé ce que nous appelons maintenant des conteneurs.

Un des principaux avantages des conteneurs est d'empêcher la duplication d'un système d'exploitation entier pour chaque instance d'une application donnée. Cela vous permet d'utiliser les ressources CPU et mémoire de manière optimisée, vous évitant de payer pour des éléments qui ne sont pas destinés à améliorer votre service. En plus des économies de coûts, cela apporte de nombreux autres avantages, tels que le déploiement rapide, la facilité d'utilisation pour les développeurs, des tests plus rapides (+ automatisation avec pipeline), une migration presque illimitée, et bien d'autres.

Qu'est-ce qu'un conteneur ?

Pensez à un conteneur comme une recette de cuisine. Vous listez ce dont vous avez besoin pour que votre application fonctionne, et le service final, ce qui vous importe, sera opérationnel. « J'ai besoin de ce type de système d'exploitation, de cette version spécifique, merci d'inclure ces paquets, de changer X et Y, d'ajouter mon application, et de l'exécuter comme ça. » Une fois votre recette complétée, vous pouvez créer un conteneur en cours d'exécution.

La nature d'un conteneur est d'être sans état. C'est essentiel pour comprendre comment les utiliser. L'analogie typique entre VM et conteneur est « chat contre bétail ». Si une VM est un chat, et que votre chat est malade, vous l'emmènerez chez le vétérinaire pour un contrôle (de la même manière que vous vous connecterez à votre VM pour le réparer).  Si un conteneur plante, comme une vache dans une grande ferme, vous ne pourrez peut-être pas le sauver et choisirez de le remplacer par un plus jeune.

La nature sans état des conteneurs

C'est là que la nature sans état entre en jeu. Stocker des informations dans un conteneur est soutenu par divers mécanismes (que ce soit mapper un volume à état à l'intérieur d'un conteneur, extraire/pousser les données à l'extérieur, etc.). Si vous écrivez quoi que ce soit dans le conteneur sans ces mécanismes, une fois le conteneur tué en raison d'un redémarrage, vous perdrez cette information.

Les conteneurs ne sont généralement pas « redémarrés », ils sont arrêtés, et un nouveau est démarré une fois que vous souhaitez récupérer le service. Nous avons eu des clients qui écrivaient des fichiers journaux dans leurs machines virtuelles et les récupéraient quotidiennement pour des analyses. Les convertir en une solution basée sur des conteneurs nécessitait de changer ce processus pour que ces journaux soient poussés en temps réel afin d'éviter de les perdre. Ce n'était pas un changement significatif et a apporté quelques avantages en plus de profiter des conteneurs, mais cela montre que parfois, ce qui peut être considéré comme une promenade de santé peut nécessiter un peu de planification.

L'histoire des conteneurs est encore en train d'être écrite

Cette nouvelle technologie a apporté de nouvelles capacités en matière de mobilité et de scalabilité, ce qui a créé un tout nouvel écosystème. Kubernetes a été un sujet brûlant ces dernières années, et nous avons maintenant une pléthore de solutions et d'alternatives autour de cela.

Notez que je n'ai pas encore parlé de Docker. La raison en est que Docker est l'une des nombreuses technologies utilisant des conteneurs. Ici à Edgegap, nous utilisons généralement Docker car c'est le plus populaire, mais nous avons dû nous occuper d'autres comme LXC, ContainerD et Rkt. Chacune a ses avantages et ses inconvénients, et nous avons vu que certains marchés spécifiques « préfèrent » l'un par rapport à l'autre. Chez Edgegap, nous avons utilisé Docker pour des éléments de jeu avec beaucoup de succès. Ces clients qui utilisaient déjà des conteneurs tiraient principalement parti de la puissance de Docker.

Le débat sur l'espace utilisateur contre l'espace noyau

Tout ne tourne pas autour des conteneurs. Nous avons entendu quelques objections ces deux dernières années. L'une des préoccupations que nous entendons souvent concerne le cœur de la technologie. Les conteneurs fonctionneront dans l'espace utilisateur contre l'espace noyau. L'espace noyau est l'endroit où le cœur de votre système d'exploitation fonctionnera, où des ressources comme la mémoire sont gérées, etc. L'espace utilisateur est l'endroit où les applications fonctionneraient généralement. Il y a un risque perçu à le faire, surtout lorsque vous avez deux applications de clients différents dans un environnement partagé.

Cela peut être vrai si l'environnement n'est pas configuré correctement. Que ce soit à partir d'une ressource partagée mal allouée (quota non appliqué), exécutée avec des droits d'utilisateur supérieurs à ce qui est nécessaire (racine encore?), gestion d'images, ou d'une perspective de réseau virtuel, il existe une série de meilleures pratiques qui doivent être suivies. Edgegap est fier d'affirmer que nous soutenons cela et suivons activement le marché pour nous assurer de corriger les attaques de 0 jour et d'utiliser les meilleures pratiques.

Des conteneurs pour les jeux ?

Les grands studios de jeux utilisent depuis des années des machines virtuelles Windows. Certains d'entre eux sont passés à des systèmes basés sur Linux, mais continuent d'utiliser des VM. Que ce soit une infrastructure basée sur VMWare, ou une infrastructure basée sur Openstack, les jeux de plus de deux ans seront principalement exécutés sur des VM. Cela a été le cas aussi longtemps que les fournisseurs de cloud sont sur le marché.

De nombreux outils ont émergé au fil des ans pour gérer ces machines virtuelles. Par exemple, AWS Gametech dispose d'un outil pour ajuster vos besoins en VM, en fonction du trafic passé. Cela exploite leurs centres de données hautement centralisés et peut être vu comme une solution à un problème qui existe depuis des années.

L'histoire des conteneurs pour les jeux ne fait que commencer

Google a créé un projet appelé Agones pour créer un plugin au-dessus de Kubernetes pour l'utiliser en tant que gestionnaire de serveurs de jeux. C'est un pas dans la bonne direction, car cela aide les studios à passer aux conteneurs tout en tirant parti des infrastructures existantes comme les systèmes de matchmaking.

Le flux de communication reste le même avec les allocations de jeux, les clusters, etc. L'inconvénient est que vous devez encore utiliser des « clusters », c'est-à-dire un environnement hautement centralisé. Vous ne pouvez pas vous rapprocher de vos joueurs et offrir une latence plus faible. Vous devrez « réserver » des ressources et en payer certaines même lorsqu'elles ne sont pas utilisées.

Le véritable pouvoir d'un conteneur est d'être démarré uniquement lorsque cela est nécessaire, arrêté lorsqu'il n'est plus utilisé et déplacé comme s'il s'agissait d'un simple petit bloc LEGO. Oubliez « échauffement à chaud/froid » pour les machines virtuelles, démarrer un conteneur prend quelques secondes, voire des millisecondes.

Tous les studios que nous avons rencontrés au cours des deux dernières années nous ont dit qu'ils étaient intéressés par les avantages des technologies basées sur des conteneurs. La question n'est pas « si » c'est le moment pour les conteneurs d'être ajoutés à l'ensemble d'outils des développeurs de jeux multijoueurs dans le monde, mais « quand ».

Besoin d'aide ?

Chez Edgegap, nous sommes spécialisés dans les solutions basées sur des conteneurs comme les micro-services. Notre plateforme et notre équipe aident les studios à offrir une expérience en ligne améliorée aux joueurs du monde entier pour augmenter la rétention et la monétisation des jeux de service en direct. Nous sommes là pour vous aider à migrer vos services vers une solution basée sur des conteneurs et à tirer parti de la force de notre plateforme pour tirer le meilleur parti de la nouvelle valeur que les conteneurs peuvent apporter à votre studio.