Docker Swarm, Kubernetes og Mesos er de mest populære containerorkestreringsrammer. I sin tale sammenligner Arun Gupta følgende aspekter af Docker, Swarm og Kubernetes:
- Lokal udvikling.
- Implementeringsfunktioner.
- Multi-container applikationer.
- Service opdagelse.
- Skalering af tjenesten.
- Run-one opgaver.
- Integration med Maven.
- "Rullende" opdatering.
- Oprettelse af en Couchbase-databaseklynge.
Som et resultat vil du få en klar forståelse af, hvad hvert enkelt orkestreringsværktøj har at tilbyde, og lære at bruge disse platforme effektivt.
Arun Gupta er chefteknolog for open source-produkter hos Amazon Web Services, som har udviklet udviklerfællesskaberne Sun, Oracle, Red Hat og Couchbase i over 10 år. Har stor erfaring med at lede tværgående teams, der udvikler og implementerer strategi for marketingkampagner og programmer. Han ledede teams af Sun-ingeniører, er en af grundlæggerne af Java EE-teamet og skaberen af den amerikanske afdeling af Devoxx4Kids. Arun Gupta er forfatter til mere end 2 indlæg i it-blogs og har holdt foredrag i mere end 40 lande.
Linje 55 indeholder en COUCHBASE_URI, der peger på denne databasetjeneste, som også blev oprettet ved hjælp af Kubernetes-konfigurationsfilen. Hvis du ser på linje 2, kan du se type: Service er den service jeg opretter kaldet couchbase-service, og det samme navn er angivet på linje 4. Nedenfor er nogle porte.
Nøglelinjerne er 6 og 7. I tjenesten siger jeg: "Hey, det er de etiketter, jeg leder efter!", og disse etiketter er intet andet end variable parnavne, og linje 7 peger på min couchbase-rs-pod Ansøgning. Følgende er de porte, der giver adgang til de samme etiketter.
På linje 19 opretter jeg en ny type ReplicaSet, linje 31 indeholder navnet på billedet, og linje 24-27 peger på metadataene forbundet med min pod. Det er præcis, hvad tjenesten leder efter, og hvad forbindelsen skal oprettes til. I slutningen af filen er der en form for forbindelse mellem linje 55-56 og 4, der siger: "brug denne tjeneste!"
Så jeg starter min service, når der er et replikasæt, og da hvert replikasæt har sin egen port med den tilsvarende etiket, er den inkluderet i tjenesten. Fra en udviklers synspunkt ringer du blot til tjenesten, som så bruger det sæt replikaer, du har brug for.
Som et resultat har jeg en WildFly pod, der kommunikerer med databasens backend via Couchbase Service. Jeg kan bruge frontenden med flere WildFly-pods, som også kommunikerer med couchbase-backend gennem couchbase-tjenesten.
Senere vil vi se på, hvordan en tjeneste, der er placeret uden for klyngen, kommunikerer gennem sin IP-adresse med elementer, der er placeret inde i klyngen og har en intern IP-adresse.
Så statsløse containere er fantastiske, men hvor godt er det at bruge stateful containere? Lad os se på systemindstillingerne for stateful eller persistente containere. I Docker er der 4 forskellige tilgange til datalagringslayout, som du bør være opmærksom på. Den første er Implicit Per-Container, hvilket betyder, at når du bruger couchbase, MySQL eller MyDB mættede containere, starter de alle med standard Sandbox. Det vil sige, at alt, hvad der er gemt i databasen, bliver gemt i selve containeren. Hvis beholderen forsvinder, forsvinder dataene sammen med den.
Den anden er Explicit Per-Container, når du opretter et specifikt lager med docker-volumenet oprette kommando og gemmer data i det. Den tredje Per-Host tilgang er forbundet med lagerkortlægning, når alt, der er gemt i containeren, samtidig duplikeres på værten. Hvis containeren fejler, forbliver dataene på værten. Sidstnævnte er brugen af flere Multi-Host-værter, hvilket er tilrådeligt i produktionsstadiet af forskellige løsninger. Lad os sige, at dine containere med dine applikationer kører på værten, men du vil gemme dine data et sted på internettet, og til dette bruger du automatisk kortlægning for distribuerede systemer.
Hver af disse metoder bruger en specifik lagerplacering. Implicit og eksplicit Per-Container gemmer data på værten på /var/lib/docker/volumes. Ved brug af Per-Host metoden monteres lageret inde i containeren, og selve containeren monteres på værten. Til multihosts kan løsninger som Ceph, ClusterFS, NFS osv. bruges.
Hvis en vedvarende beholder fejler, bliver lagerbiblioteket utilgængeligt i de første to tilfælde, men i de sidste to tilfælde opretholdes adgangen. I det første tilfælde kan du dog få adgang til depotet gennem en Docker-vært, der kører på en virtuel maskine. I det andet tilfælde vil data heller ikke gå tabt, fordi du har oprettet et eksplicit lager.
Hvis værten fejler, er lagerbiblioteket utilgængeligt i de første tre tilfælde; i det sidste tilfælde afbrydes forbindelsen til lageret ikke. Endelig er den delte funktion helt udelukket til opbevaring i det første tilfælde og er mulig i resten. I det andet tilfælde kan du dele lagerplads afhængigt af om din database understøtter distribueret lagerplads eller ej. I tilfælde af Per-Host er datadistribution kun mulig på en given vært, og for en multihost leveres den ved klyngeudvidelse.
Dette bør tages i betragtning ved oprettelse af stateful containere. Et andet nyttigt Docker-værktøj er Volume-plugin, som fungerer efter princippet om "batterier til stede, men skal udskiftes." Når du starter en Docker-container, siger den: "Hey, når du først starter en container med en database, kan du gemme dine data i denne container!" Dette er standardfunktionen, men du kan ændre den. Dette plugin giver dig mulighed for at bruge et netværksdrev eller noget lignende i stedet for en containerdatabase. Den inkluderer en standarddriver til værtsbaseret lagring og tillader containerintegration med eksterne lagringssystemer såsom Amazon EBS, Azure Storage og GCE Persistent-diske.
Det næste dias viser arkitekturen af Docker Volume plugin.
Den blå farve repræsenterer Docker-klienten forbundet med den blå Docker-vært, som har en lokal lagringsmotor, der giver dig containere til lagring af data. Grøn angiver Plugin Client og Plugin Daemon, som også er forbundet til værten. De giver mulighed for at gemme data i netværkslager af den type Storage Backend du har brug for.
Docker Volume plugin kan bruges med Portworx storage. PX-Dev-modulet er faktisk en container, du kører, der forbinder til din Docker-vært og giver dig mulighed for nemt at gemme data på Amazon EBS.
Portworx-klienten giver dig mulighed for at overvåge status for forskellige lagerbeholdere, der er forbundet til din vært. Hvis du besøger min blog, kan du læse, hvordan du får mest muligt ud af Portworx med Docker.
Konceptet med opbevaring i Kubernetes ligner Docker og er repræsenteret af mapper, der er tilgængelige for din container i en pod. De er uafhængige af enhver containers levetid. De mest almindelige tilgængelige lagertyper er hostPath, nfs, awsElasticBlockStore og gsePersistentDisk. Lad os tage et kig på, hvordan disse butikker fungerer i Kubernetes. Typisk består processen med at forbinde dem af 3 trin.
Den første er, at nogen på netværkssiden, normalt en administrator, giver dig vedvarende lagring. Der er en tilsvarende PersistentVolume-konfigurationsfil til dette. Dernæst skriver applikationsudvikleren en konfigurationsfil kaldet PersistentVolumeClaim, eller en PVC-lagringsanmodning, som siger: "Jeg har 50 GB distribueret lager klargjort, men for at andre mennesker også kan bruge dens kapacitet, fortæller jeg denne PVC, at jeg pt. behøver kun 10 GB". Endelig er det tredje trin, at din anmodning er monteret som lager, og den applikation, der har poden, eller replikasættet eller noget lignende, begynder at bruge det. Det er vigtigt at huske, at denne proces består af de 3 nævnte trin og er skalerbar.
Det næste dias viser Kubernetes Persistence Container i AWS-arkitekturen.
Inde i det brune rektangel, der repræsenterer Kubernetes-klyngen, er der en hovedknude og to arbejderknudepunkter, angivet med gult. En af arbejderknuderne indeholder en orange pod, opbevaring, en replika-controller og en grøn Docker Couchbase-beholder. Inde i klyngen, over knudepunkterne, angiver et lilla rektangel, at tjenesten er tilgængelig udefra. Denne arkitektur anbefales til lagring af data på selve enheden. Hvis det er nødvendigt, kan jeg gemme mine data i EBS uden for klyngen, som vist på næste slide. Dette er en typisk model til skalering, men der er et økonomisk aspekt at overveje, når du bruger det - at gemme data et sted på netværket kan være dyrere end på en vært. Når man vælger containeriseringsløsninger, er dette et af de tungtvejende argumenter.
Ligesom med Docker kan du bruge vedvarende Kubernetes-beholdere med Portworx.
Dette er det, der i den nuværende Kubernetes 1.6-terminologi kaldes et "StatefulSet" - en måde at arbejde med Stateful-applikationer på, der behandler hændelser om at stoppe Pod'en og udføre Graceful Shutdown. I vores tilfælde er sådanne applikationer databaser. I min blog kan du læse, hvordan du opretter et StatefulSet i Kubernetes ved hjælp af Portworx.
Lad os tale om udviklingsaspektet. Docker har som sagt 2 versioner - CE og EE, i det første tilfælde taler vi om en stabil version af Community Edition, som opdateres en gang hver 3. måned, i modsætning til den månedligt opdaterede version af EE. Du kan downloade Docker til Mac, Linux eller Windows. Når det er installeret, vil Docker automatisk opdatere, og det er meget nemt at komme i gang.
For Kubernetes foretrækker jeg Minikube-versionen – det er en god måde at komme i gang med platformen ved at lave en klynge på en enkelt node. For at skabe klynger af flere noder er valget af versioner bredere: disse er kops, kube-aws (CoreOS+AWS), kube-up (forældet). Hvis du ønsker at bruge AWS-baserede Kubernetes, anbefaler jeg at deltage i AWS SIG, som mødes online hver fredag og udgiver en række interessante materialer om at arbejde med AWS Kubernetes.
Lad os se på, hvordan rullende opdatering udføres på disse platforme. Hvis der er en klynge af flere noder, så bruger den en bestemt version af billedet, for eksempel WildFly:1. En rullende opdatering betyder, at billedversionen sekventielt erstattes med en ny på hver node, den ene efter den anden.
For at gøre dette bruger jeg kommandoen docker service update (tjenestenavn), hvor jeg angiver den nye version af WildFly:2-billedet og opdateringsmetoden update-parallelism 2. Tallet 2 betyder, at systemet vil opdatere 2 applikationsbilleder på samme tid, derefter en 10-sekunders opdateringsforsinkelse 10s, hvorefter de næste 2 billeder vil blive opdateret på yderligere 2 noder mv. Denne enkle rullende opdateringsmekanisme leveres til dig som en del af Docker.
I Kubernetes fungerer en rullende opdatering sådan. Replikeringscontrolleren rc opretter et sæt replikaer af samme version, og hver pod i denne webapp-rc er forsynet med en etiket placeret i etcd. Når jeg har brug for en pod, bruger jeg Application Service til at få adgang til etcd-lageret, som giver mig pod'en ved hjælp af den angivne etiket.
I dette tilfælde har vi 3 pods i replikeringscontrolleren, der kører applikationen WildFly version 1. Ved opdatering i baggrunden oprettes en anden replikeringscontroller med samme navn og indeks i slutningen - - xxxxx, hvor x er tilfældige tal, og med de samme mærker. Nu har Application Service tre pods med den gamle version af programmet og tre pods med den nye version i den nye replikeringscontroller. Herefter slettes de gamle pods, replikeringscontrolleren med de nye pods omdøbes og sættes i drift.
Lad os gå videre til overvågning. Docker har mange indbyggede overvågningskommandoer. For eksempel giver docker container stats kommandolinjegrænsefladen dig mulighed for at vise information om containernes tilstand til konsollen hvert sekund - processorbrug, diskbrug, netværksbelastning. Docker Remote API-værktøjet giver data om, hvordan klienten kommunikerer med serveren. Den bruger simple kommandoer, men er baseret på Docker REST API. I dette tilfælde betyder ordene REST, Flash, Remote det samme. Når du kommunikerer med værten, er det en REST API. Docker Remote API giver dig mulighed for at få flere oplysninger om at køre containere. Min blog skitserer detaljerne i brugen af denne overvågning med Windows Server.
Overvågning af docker-systemhændelser, når du kører en multi-host-klynge, gør det muligt at indhente data om et værtsnedbrud eller et containernedbrud på en specifik vært, skaleringstjenester og lignende. Startende med Docker 1.20 inkluderer det Prometheus, som integrerer endepunkter i eksisterende applikationer. Dette giver dig mulighed for at modtage metrics via HTTP og vise dem på dashboards.
En anden overvågningsfunktion er cAdvisor (en forkortelse for container advisor). Den analyserer og leverer data om ressourceforbrug og ydeevne fra kørende containere, hvilket giver Prometheus-metrics lige ud af boksen. Det specielle ved dette værktøj er, at det kun leverer data for de sidste 60 sekunder. Derfor skal du kunne indsamle disse data og lægge dem ind i en database, så du kan overvåge en langsigtet proces. Det kan også bruges til at vise dashboard-metrik grafisk ved hjælp af Grafana eller Kibana. Min blog har en detaljeret beskrivelse af, hvordan man bruger cAdvisor til at overvåge containere ved hjælp af Kibana-dashboardet.
Det næste dias viser, hvordan Prometheus-endepunktoutputtet ser ud, og de metrik, der er tilgængelige for visning.
Nederst til venstre ser du metrics for HTTP-anmodninger, svar osv., til højre er deres grafiske visning.
Kubernetes inkluderer også indbyggede overvågningsværktøjer. Dette dias viser en typisk klynge, der indeholder en master- og tre arbejdsknudepunkter.
Hver af arbejdsknuderne indeholder en automatisk lanceret cAdvisor. Derudover er der Heapster, et ydelsesovervågnings- og metrikindsamlingssystem, der er kompatibelt med Kubernetes version 1.0.6 og nyere. Heapster giver dig mulighed for at indsamle ikke kun præstationsmålingerne for arbejdsbelastninger, pods og containere, men også hændelser og andre signaler genereret af hele klyngen. For at indsamle data taler den med hver pods Kubelet, gemmer automatisk oplysningerne i InfluxDB-databasen og udsender dem som metrics til Grafana-dashboardet. Husk dog, at hvis du bruger miniKube, er denne funktion ikke tilgængelig som standard, så du bliver nødt til at bruge tilføjelser til overvågning. Så det kommer helt an på, hvor du kører containerne, og hvilke overvågningsværktøjer du kan bruge som standard, og hvilke du skal installere som separate tilføjelser.
Det næste dias viser Grafana-dashboards, der viser kørestatus for mine containere. Der er ret mange interessante data her. Selvfølgelig er der mange kommercielle Docker- og Kubernetes-procesovervågningsværktøjer, såsom SysDig, DataDog, NewRelic. Nogle af dem har en gratis prøveperiode på 30 år, så du kan prøve at finde den, der passer dig bedst. Personligt foretrækker jeg at bruge SysDig og NewRelic, som integreres godt med Kubernetes. Der er værktøjer, der integreres lige godt i både Docker og Kubernetes platforme.
Nogle annoncer 🙂
Tak fordi du blev hos os. Kan du lide vores artikler? Vil du se mere interessant indhold? Støt os ved at afgive en ordre eller anbefale til venner, , en unik analog af entry-level servere, som blev opfundet af os til dig: (tilgængelig med RAID1 og RAID10, op til 24 kerner og op til 40 GB DDR4).
Dell R730xd 2 gange billigere i Equinix Tier IV datacenter i Amsterdam? Kun her i Holland! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - fra $99! Læse om
Kilde: www.habr.com