Når du hoster din applikation eller database hos Kinsta, kører dine projekter på Google Cloud Platforms førsteklasses infrastruktur. I denne vejledning dykker vi lidt ned i detaljerne om vores infrastruktur for applikationshosting og databasehosting.
Implementering
Git Repository
Din applikations kode er gemt i et Git-repository. Du kan vælge mellem en hvilken som helst (eller alle) af følgende:
MyKinsta Tilføj/udrulning af applikation
Når du tilføjer en applikation i MyKinsta, opretter den forbindelse til Git-repositoriet for at hente applikationen.
MyKinsta Bot
Med Automatisk implementering ved commit aktiveret i din applikations indstillinger, hvis du foretager en ændring eller fletning til dit lager, registrerer MyKinsta-botten dette, trækker derefter applikationen fra din Git-tjenesteudbyder og implementerer den opdaterede version af applikationen.
Google Cloud Build
MyKinsta sender applikationen til Google Cloud Build for at opbygge et image af applikationen ud fra koden. Den ved, hvilke programmer eller moduler der skal installeres til applikationen ud fra oplysningerne i buildpacks eller Dockerfile. Output er et image, der kan omdannes til en container.
Google Artifact Registry
Dette gemmer de containerimages, der er klar til at blive distribueret. Hver applikation har et enkelt image, der kan bruges, når den skal implementeres.
Kubernetes Cluster
Billedet fra artefaktregistret skubbes til klyngen. Dette er en virtuel maskine (VM), hvor flere containere kan køre. Klyngerne er indstillet til at sikre, at anmodningen fra artefaktregistret finder den rigtige container, at containerne kører, og at de har de rigtige ressourcer. Hvis der er problemer med en container, bliver programmet omplaceret til en anden container. Vi bruger cri-o v1.23.x på vores infrastruktur; denne version er dog ikke statisk og kan blive opgraderet, da vi opgraderer forskellige komponenter i stakken.
Vores Kubernetes-infrastruktur understøtter en multi-tenant-opsætning, hvor hver applikation kører i sit eget containermiljø. Netværksisolering og multi-lags virtualisering sikrer sikkerhed og forhindrer uautoriseret adgang mellem applikationer. Dette design giver dig en pålidelig og sikker hostingplatform, så du kan fokusere på din kerneforretning, mens vi håndterer den underliggende infrastruktur. Vi implementerer mindst én klynge pr. region, med potentiale for yderligere klynger baseret på antallet af applikationer i hver region. Dette system sikrer optimal ressourceallokering og skalerbarhed for at imødekomme vores kunders voksende behov.
Anmodninger
Cloudflare
Når en besøgende får adgang til webstedet for et program, får den først adgang til Cloudflare, som ved, hvilken klynge der er host for webstedet. Den sender derefter adgangsanmodningen til den korrekte klynge.
I øjeblikket omfatter Cloudflare for applikationshosting og databasehosting standardfirewallreglerne, standard DDoS-beskyttelse og andre standardindstillinger.
Lastudligning i skyen
Hver klynge har en load balancer, der modtager adgangsforespørgslen fra Cloudflare og tilfældigt skubber en VM-worker node.
Indgang
VM-arbejderknuden modtager anmodningen på Ingress-systemet, som ved, hvilken container der er ansvarlig for det hostnavn, der anmodes om. Ingress-systemet sender anmodningen til den korrekte container, og hvis containeren har en database tilknyttet, kommunikerer den med databasen og sender et svar ad samme rute.
Virtuelle maskiner (VM)
En virtuel maskine (VM) kan indeholde flere containere og flere databaser.
Containere
Hver container eller applikation kan have flere kopier på den virtuelle maskine. I dette tilfælde ved Ingress-systemet dette og sender tilfældigt gennem en af kopierne af den samme container.
Persistent Storage
Du kan tilføje persistent storage til en webproces eller baggrundsprocesser. Dette tilføjer en lagervolumen, der er knyttet til VM’en (virtuel maskine) til din applikation og bevarer data, selvom applikationen genstartes eller ominstalleres.