Het volgende artikel zal je helpen: Flask en Celery uitvoeren met Kubernetes
IN Gorgias we hebben onlangs de onze veranderd fles & selderij applicaties van virtuele machines van Google Cloud die zijn ingericht met behulp van Textiel voor gebruik havenarbeider Met Kubernetes (k8s). Dit is een bericht over onze ervaringen hiermee.
‍
Opmerking: Ik neem aan dat je een beetje bekend bent met Docker.
‍
Docker-structuur
Het geweldige kenmerk van Docker voor ons is dat we hiermee binaire afbeeldingen op meerdere niveaus van onze applicatie kunnen maken. Dit betekent dat u kunt beginnen met een minimale basisimage, vervolgens een Python-image daarbovenop kunt bouwen, vervolgens een applicatie-image bovenop de Python-image, enzovoort.
‍
Hier is de hiërarchie van onze docker-images:
- gorgia/basis – we gebruiken phusie/basisafbeelding als de initiĂ«le basisafbeelding.
- gorgias/pgbouncer
- gorgia/konijnmq
- gorgia’s/nginx – breidt gorgias/base uit en installeert NGINX
- gorgia’s/python – Installeert pip, python3.5 – ja, gebruikt het in productie.
- gorgia’s/app – Hiermee worden alle systeemafhankelijkheden geĂŻnstalleerd: libpq, libxml, enz. en vervolgens pip install -r vereisten.txt
- gorgia’s/web – hiermee wordt uWSGI geĂŻnstalleerd en wordt onze flask-app gestart
- gorgia’s / werker – Selderijwerker
‍
Advies: Als u uw applicatie eerder met supervisord hebt uitgevoerd, raad ik u aan de verleiding te vermijden om hetzelfde te doen met docker, laat uw container gewoon falen en laat k8s het afhandelen.
‍
Nu kunnen we de bovenstaande afbeeldingen uitvoeren met: docker-componeren, havenarbeiderszwerm, k8s, Mesosenzovoort…
‍
Wij hebben ook voor Kubernetes gekozen
Eten Goede post over de verschillen tussen containerimplementaties die ook geschikt zijn voor k8’s.
‍
Ik ga er ook gewoon van uit dat je je huiswerk al hebt gedaan en van plan bent k8s te gebruiken. Maar om nog meer gegevens toe te voegen:
‍
De belangrijkste reden: we gebruiken Google Cloud al en biedt een kant-en-klaar Kubernetes-cluster in hun cloud.
‍
Dit is erg belangrijk omdat we het k8s-cluster niet hoeven te beheren en ons in plaats daarvan kunnen concentreren op het implementeren van onze applicaties in productie.
‍
Laten we beginnen met het maken van een lijst van wat we nodig hebben om onze applicatie in productie te laten draaien:
- Database (Postgres)
- Berichtenwachtrij (RabbitMQ)
- Applicatieservers (uWSGI met Flask)
- Webservers (NGINX-proxy’s uWSGI en serveert statische bestanden)
- Werknemers (selderij)
‍
Waarom opnieuw Kubernetes?
We hebben het bovenstaande in een normale virtuele omgeving uitgevoerd. Waarom hebben we k8’s nodig? Om dit te begrijpen, gaan we wat dieper in op wat k8s te bieden heeft:
- A peul is een groep containers (docker, rtk, lxc…) die draait op Knoop. Dit is een groep omdat je soms meerdere containers naast elkaar wilt laten draaien. We draaien uWSGI en NGINX bijvoorbeeld in dezelfde pod (op dezelfde virtuele machine, en ze gebruiken hetzelfde IP-adres, dezelfde poorten, enz.).
- A Knoop dit is de machine (virtuele machine of metal) waarop de k8s-daemon (minion) draait die de modules uitvoert.
- De knooppunten worden beheerd door de k8s-master (die in ons geval wordt beheerd door de containerengine van Google).
- Replicatiecontroller of kortweg radiografisch bestuurbare vertelt k8s hoeveel modules van een bepaald type moeten worden uitgevoerd. Merk op dat u k8s niet vertelt waar ze moeten worden uitgevoerd; het is de taak van de host om ze te plannen. Ze worden ook gebruikt voor rolling updates en automatisch schalen. Puur geweldig.
- Diensten neem de open poorten van uw modules en publiceer ze (meestal in het publieke domein). Het mooie van de service is dat deze de verbindingen met uw pods kan balanceren, zodat u uw HAProxy of NGINX niet hoeft te beheren. Het gebruikt labels om erachter te komen welke modules in de pool moeten worden opgenomen.
- Etiketten: k8s CSS-selectors – gebruik ze overal!
- ‍
Er zijn ook concepten als volumes, vereisten, geheimen, maar laten we ons daar voorlopig geen zorgen over maken.
‍
Postgres
We gebruiken Postgres als onze hoofdopslag en wij zonder het met Kubernetes uit te voeren.
‍
Nu draaien we postgres in k8s (1 hot spare + pghoard), je kunt de rest van deze paragraaf negeren.
De reden hiervoor is dat we Postgres wilden uitvoeren met ingerichte SSD’s en instanties met veel geheugen. We hadden met deze machinetypen een cluster met alleen postgres kunnen maken, maar dat leek overdreven.
De k8s-filosofie is dat je je cluster moet ontwerpen met het idee dat de pods/nodes van je cluster willekeurig zullen sterven. Ik weet niet hoe ik Postgres moet configureren om aan deze beperking tegemoet te komen. Dus we beginnen het gewoon te repliceren met een hot spare en maken er back-ups van muur-e voor nu. Als je dit met k8s wilt proberen, is er een tutorial Hier. En vertel ons er zeker over.
‍
KonijnMQ
RabbitMQ (gebruikt als berichtenmakelaar voor Celery) draait op k8s omdat het eenvoudiger is (dan Postgres) om een ​​cluster te maken. Ik zal niet in details treden. Het maakt gebruik van een replicatiecontroller om 3 peulen uit te voeren met konijnmq-instanties. Deze gids heeft geholpen: https://www.rabbitmq.com/clustering.html
‍
UWSGI en NGINX
Zoals ik eerder al zei, gebruiken we een replicatiecontroller om 3 modules uit te voeren, die elk twee uWSGI- en NGINX-containers bevatten: gorgias/web en gorgias/nginx. Hier is de configuratie van onze replicatiecontroller web-rc.yaml:
‍
apiVersion: v1type: replicatiecontroller metadata: naam: netwerkspecificatie: replica’s: 3 # hoeveel exemplaren van de onderstaande sjabloon hebben we nodig om selector uit te voeren: applicatie: webtemplate: metadata: labels: applicatie: webspec: containers: – naam: netwerkimage: gcr .io/your-project/ web:latest # de afbeelding die u naar de Google Container Registry hebt gepusht met behulp van gcloud docker pushports: # dit zijn de open poorten van uw pods die later worden gebruikt door de k8s-service – containerPort: 3033 naam: “uvsgi ” – containerPort: 9099Name: “stats” – naam: nginximage: gcr.io/uw-project/nginx:latestports:– containerPort: 8000name: “http”– containerPort: 4430name: “https”volumeMounts: # Dit is waar onze SSL sleutels worden opgeslagen voor gebruik met nginx. Ik heb geen manier gevonden om de http-load balancer van Google met k8s te gebruiken. – titel: “geheimen” mountPath: “/pad/naar/geheimen” Alleen-lezen: waarheidvolume: – titel: “geheimen” geheim: secretName: “ssl-geheim” En nu web-service.yaml: apiVersion: v1 weergave: metagegevens van de service:naam: netwerkspecificatie:poorten:– poort: 80doelpoort: 8000naam: “http”protocol: TCP–poort: 443doelpoort: 4430naam: “https”protocol: TCPselector:applicatie: webtype: LoadBalancer
‍
Dit type: LoadBalancer aan het einde is erg belangrijk omdat het k8s vertelt om het openbare IP-adres op te vragen en het netwerk naar de pods te routeren met behulp van selector=app:web. Als u een rolling update uitvoert of uw pods gewoon opnieuw opstart, hoeft u dat niet te doen. U hoeft de service niet te wijzigen. Er wordt gezocht naar modules die overeenkomen met deze tags.
‍
Selderij
Ook een replicatiecontroller die 4 modules uitvoert die Ă©Ă©n container bevatten: gorgias/worker, maar die geen service nodig heeft omdat deze alleen dingen verbruikt. Hier is onze worker-rc.yaml:
‍
apiVersion: v1type: metagegevens van de replicatiecontroller: naam: werkspecificatie: replica’s: 2 selector: toepassing: werksjabloon: metagegevens: labels: toepassing: werkspecificatie: containers: – naam: werkerimage: gcr.io/uw-project/werknemer: laatste
‍
‍
Een aantal tips
- Het duurt lang voordat sommige Python-deps zijn geĂŻnstalleerd, voor zaken als numpy, scipy, enz., probeer ze in de naamruimte/container van uw toepassing te installeren met behulp van pip, en voer dan nog een pip-installatie uit in een container die deze uitbreidt, bijvoorbeeld: naamruimte/web, op deze manier hoeft u niet elke keer dat u een pakket bijwerkt of alleen uw toepassing bijwerkt, alle afhankelijkheden opnieuw op te bouwen.
- Besteed wat tijd aan het spelen met gcloud en kubectl. Dit is de snelste manier om meer te leren over Google cloud en k8s.
- Het kiezen van een basisafbeelding is belangrijk. Ik heb phusion/baseimage en ubuntu/core geprobeerd. Gestopt bij phusion/baseimage omdat het het initialisatiegedeelte beter lijkt af te handelen dan de ubuntu-kernel. Ze voelen nog steeds te zwaar aan. phusion/basisimage is 188 MB.
‍
‍
Conclusie
Met Kubernetes werd Docker voor mij eindelijk logisch. Dit is geweldig omdat het geweldige kant-en-klare tools biedt voor het implementeren van webapplicaties. Replicatiecontrollers, services (inclusief LoadBalancer), persistente volumes, interne DNS. Het zou alles moeten hebben wat u nodig heeft om snel een fouttolerante webapplicatie te maken.
Bij Wix bouwen we aan een helpdesk van de volgende generatie die twee keer zo snel reageert op veelvoorkomende klantverzoeken. Het hebben van een snelle, betrouwbare infrastructuur is van cruciaal belang om onze doelen te bereiken.
Als je geĂŻnteresseerd bent om met dit soort dingen te werken (vooral om ze te verbeteren): We zijn aan het huren!
