Lorsque vous hébergez votre application ou votre base de données avec Kinsta, vos projets s’exécutent sur l’infrastructure de premier ordre de Google Cloud Platform. Dans ce guide, nous allons plonger un peu dans les détails de notre infrastructure d’hébergement d’applications et de bases de données.
Déploiement
Dépôt Git
Le code de votre application est stocké dans un dépôt Git. Vous pouvez choisir parmi les options suivantes (ou toutes) :
MyKinsta Ajouter/Déployer une application
Dans MyKinsta, lorsque vous ajoutez une application, il se connecte au dépôt Git pour récupérer l’application.
MyKinsta Bot
Avec le déploiement automatique sur commit activé dans les réglages de votre application, si vous commettez une modification ou une fusion dans votre dépot, le robot MyKinsta le détecte, puis tire l’application depuis votre fournisseur de services Git et déploie la version mise à jour de l’application.
Google Cloud Build
MyKinsta envoie l’application à Google Cloud Build pour construire une image de l’application à partir du code. Il sait quelles applications ou quels modules installer pour l’application à partir des informations contenues dans les buildpacks ou le Dockerfile. Le résultat est une image qui peut être transformée en conteneur.
Registre Google Artifact
Ce registre stocke les images de conteneur prêtes à être déployées. Chaque application dispose d’une image unique qui peut être utilisée à chaque fois qu’elle doit être déployée.
Cluster Kubernetes
L’image du registre d’artefacts est poussée vers le cluster, qui est une machine virtuelle (VM) où plusieurs conteneurs peuvent fonctionner. Les clusters sont réglés pour s’assurer que la requête du registre d’artefacts trouve le bon conteneur, que les conteneurs fonctionnent et qu’ils disposent des bonnes ressources. S’il y a des problèmes avec un conteneur, l’application est redéployée dans un autre conteneur. Nous utilisons cri-o v1.23.x sur notre infrastructure ; cependant, cette version n’est pas statique et peut être mise à niveau au fur et à mesure que nous mettons à niveau les différents composants de la pile.
Notre infrastructure Kubernetes prend en charge une configuration multi-tenant, où chaque application est utilisée dans son propre environnement conteneurisé. L’isolation du réseau et la virtualisation multicouche garantissent la sécurité et empêchent tout accès non autorisé entre les applications. Cette conception vous fournit une plateforme d’hébergement fiable et sécurisée, vous activant sur votre cœur de métier pendant que nous nous occupons de l’infrastructure sous-jacente. Nous déployons au moins un cluster par région, avec la possibilité d’en ajouter d’autres en fonction du nombre d’applications dans chaque région. Ce système garantit une allocation des ressources et une évolutivité optimales pour répondre aux besoins croissants de nos clients.
Requêtes
Cloudflare
Lorsqu’un visiteur accède au site web d’une application, il accède d’abord à Cloudflare, qui sait quel cluster héberge le site web. Il envoie ensuite la demande d’accès au cluster correct.
Actuellement, pour l’hébergement d’applications et de bases de données, Cloudflare inclut les règles de pare-feu par défaut, la protection DDoS par défaut et d’autres valeurs par défaut.
Équilibrage de charge du cloud
Chaque cluster possède un équilibreur de charge qui reçoit la demande d’accès de Cloudflare et pousse de manière aléatoire un nœud de travail VM.
Ingress
Le nœud VM worker reçoit la demande sur le système Ingress, qui sait quel conteneur est responsable du nom d’hôte demandé. Le système Ingress envoie la demande au bon conteneur, et si le conteneur a une base de données attachée, il communique avec la base de données et envoie une réponse sur la même route.
Machines virtuelles (VM)
Une machine virtuelle (VM) peut contenir plusieurs conteneurs et plusieurs bases de données.
Conteneurs
Chaque conteneur ou application peut avoir plusieurs copies sur la VM. Dans ce cas, le système Ingress le sait et envoie de manière aléatoire par l’une des copies du même conteneur.