Værktøjer til udviklere af applikationer, der kører på Kubernetes

Værktøjer til udviklere af applikationer, der kører på Kubernetes

En moderne tilgang til driften løser mange presserende forretningsproblemer. Containere og orkestratorer gør det nemt at skalere projekter af enhver kompleksitet, forenkler udgivelsen af ​​nye versioner, gør dem mere pålidelige, men samtidig skaber de yderligere problemer for udviklere. Programmøren bekymrer sig først og fremmest om sin kode: arkitektur, kvalitet, ydeevne, elegance - og ikke hvordan det vil fungere i Kubernetes, og hvordan man tester og fejlretter det efter at have foretaget selv minimale ændringer. Derfor er det også helt naturligt, at der aktivt udvikles værktøjer til Kubernetes, der hjælper med at løse problemerne for selv de mest "arkaiske" udviklere og giver dem mulighed for at fokusere på det vigtigste.

Denne anmeldelse giver kort information om nogle af de værktøjer, der gør livet lettere for en programmør, hvis kode kører i pod'axen af ​​en Kubernetes-klynge.

Simple hjælpere

Kubectl-debug

  • Bundlinjen: føj din beholder til en Pod og se, hvad der sker i den.
  • GitHub.
  • Kort GH-statistik: 715 stjerner, 54 commits, 9 bidragydere.
  • Sprog: Gå.
  • Licens: Apache License 2.0.

Dette plugin til kubectl giver dig mulighed for at oprette en ekstra container inde i poden af ​​interesse, som vil dele processens navneområde med andre containere. I den kan du fejlsøge pod'ens drift: tjek netværket, lyt til netværkstrafik, lav en oversigt over processen af ​​interesse osv.

Du kan også skifte til procesbeholderen ved at køre chroot /proc/PID/root - det kan være meget praktisk, når du skal have en rodskal i en beholder, som den er sat til i manifestet securityContext.runAs.

Værktøjet er enkelt og effektivt, så det kan være nyttigt for enhver udvikler. Vi skrev mere om det i separat artikel.

telepresence

  • Bundlinjen: overføre programmet til din computer. Udvikle og fejlsøge lokalt.
  • Site; GitHub.
  • Kort GH-statistik: 2131 stjerner, 2712 commits, 33 bidragydere.
  • Sprog: Python.
  • Licens: Apache License 2.0.

Ideen med denne snap-in er at starte en container med applikationen på den lokale brugercomputer og proxy for al trafik fra klyngen til den og tilbage. Denne tilgang giver dig mulighed for at udvikle lokalt ved blot at redigere filer i din foretrukne IDE: resultaterne vil være tilgængelige med det samme.

Fordelene ved at køre lokalt er bekvemmeligheden ved redigeringer og øjeblikkelige resultater, evnen til at fejlsøge applikationen på den sædvanlige måde. Ulempen er, at det er krævende for forbindelseshastigheden, hvilket især er mærkbart, når man skal arbejde med en applikation med ret høj RPS og trafik. Derudover har Telepresence problemer med volumenmonteringer på Windows, hvilket kan være en afgørende begrænsning for udviklere, der er vant til dette OS.

Vi har allerede delt vores erfaring med at bruge Telepresence her.

Ksync

  • Bundlinjen: næsten øjeblikkelig synkronisering af kode med containeren i klyngen.
  • GitHub.
  • Kort GH-statistik: 555 stjerner, 362 commits, 11 bidragydere.
  • Sprog: Gå.
  • Licens: Apache License 2.0.

Hjælpeprogrammet giver dig mulighed for at synkronisere indholdet af en lokal mappe med mappen i en container, der kører i klyngen. Sådan et værktøj er perfekt til udviklere i scripting programmeringssprog, hvis hovedproblem er at levere kode til en kørende container. Ksync er designet til at lindre denne hovedpine.

Når initialiseret én gang af kommandoen ksync init der oprettes et DaemonSet i klyngen, som bruges til at overvåge tilstanden af ​​filsystemet for den valgte container. På sin lokale computer kører udvikleren kommandoen ksync watch, som overvåger konfigurationer og kørsler syncthing, som direkte synkroniserer filer med klyngen.

Det eneste, der er tilbage, er at instruere ksync, hvad der skal synkroniseres med hvad. For eksempel denne kommando:

ksync create --name=myproject --namespace=test --selector=app=backend --container=php --reload=false /home/user/myproject/ /var/www/myproject/

... vil oprette en overvåger ved navn myprojectsom vil søge efter en pod med en etiket app=backend og prøv at synkronisere den lokale mappe /home/user/myproject/ med katalog /var/www/myproject/ ved den kaldede container php.

Problemer og noter om ksync fra vores erfaring:

  • Skal bruges på Kubernetes klynge noder overlay2 som lagerdriver til Docker. Værktøjet fungerer ikke sammen med andre.
  • Når du bruger Windows som et klient-operativsystem, fungerer filsystemovervågningen muligvis ikke korrekt. Denne fejl blev bemærket, når man arbejdede med store mapper - med et stort antal indlejrede filer og mapper. Vi skabte relevant problemstilling i synkroniseringsprojektet, men der er ingen fremskridt på det endnu (siden begyndelsen af ​​juli).
  • Brug fil .stignore for at angive stier eller filmønstre, der ikke skal synkroniseres (f.eks. mapper app/cache и .git).
  • Som standard genstarter ksync containeren, når filerne ændres. For Node.js er dette praktisk, men for PHP er det fuldstændig unødvendigt. Det er bedre at slå opcache fra og bruge flaget --reload=false.
  • Konfigurationen kan altid rettes i $HOME/.ksync/ksync.yaml.

Squash

  • Bundlinjen: debug processer direkte i klyngen.
  • GitHub.
  • Kort GH-statistik: 1154 stjerner, 279 commits, 23 bidragydere.
  • Sprog: Gå.
  • Licens: Apache License 2.0.

Dette værktøj er designet til at fejlfinde processer direkte i pods. Hjælpeprogrammet er enkelt og giver dig interaktivt mulighed for at vælge den ønskede debugger (se nedenunder) og navneområde + pod, i hvilken proces du skal gribe ind. Understøttet i øjeblikket:

  • dykke - til Go-applikationer;
  • GDB - via målfjernbetjening + portvideresendelse;
  • JDWP-portvideresendelse til debugging af Java-applikationer.

På IDE-siden er support kun tilgængelig i VScode (ved hjælp af udvidelse), dog inkluderer planer for det nuværende (2019) år Eclipse og Intellij.

For at fejlsøge processer kører Squash en privilegeret container på klynge noderne, så du skal først sætte dig ind i mulighederne sikker tilstand for at undgå sikkerhedsproblemer.

Fuldstændige løsninger

Lad os gå videre til det tunge artilleri - mere "storskala" projekter designet til straks at imødekomme mange af udviklernes behov.

NB: På denne liste er der selvfølgelig plads til vores Open Source-værktøj werf (tidligere kendt som dapp). Vi har dog allerede skrevet og talt om det mere end én gang, og derfor besluttede vi ikke at medtage det i anmeldelsen. For dem, der ønsker at blive mere fortrolige med dens muligheder, anbefaler vi at læse/lytte til rapporten "werf er vores værktøj til CI/CD i Kubernetes'.

DevSpace

  • Bundlinjen: for dem, der ønsker at begynde at arbejde i Kubernetes, men ikke ønsker at dykke dybt ind i dens jungle.
  • GitHub.
  • Kort GH-statistik: 630 stjerner, 1912 tilsagn, 13 bidragydere.
  • Sprog: Gå.
  • Licens: Apache License 2.0.

En løsning fra firmaet af samme navn, som leverer administrerede klynger med Kubernetes til teamudvikling. Værktøjet blev oprettet til kommercielle klynger, men fungerer godt med alle andre.

Når du kører kommandoen devspace init i projektkataloget vil du blive tilbudt (interaktivt):

  • vælg en fungerende Kubernetes-klynge,
  • bruge eksisterende Dockerfile (eller generer en ny) for at oprette en container baseret på den,
  • vælg et lager til opbevaring af containerbilleder osv.

Efter alle disse forberedende trin kan du starte udviklingen ved at køre kommandoen devspace dev. Det vil bygge containeren, uploade den til lageret, udrulle implementeringen til klyngen og starte portvideresendelse og synkronisering af containeren med den lokale mappe.

Du vil eventuelt blive bedt om at flytte terminalen til containeren. Du bør ikke nægte, for i virkeligheden starter beholderen med sleep-kommandoen, og for rigtig test skal applikationen startes manuelt.

Endelig holdet devspace deploy ruller applikationen og den tilhørende infrastruktur ud til klyngen, hvorefter alt begynder at fungere i kamptilstand.

Al projektkonfiguration er gemt i en fil devspace.yaml. Ud over indstillingerne for udviklingsmiljøet kan du også finde en beskrivelse af infrastrukturen i den, svarende til standard Kubernetes-manifester, kun meget forenklet.

Værktøjer til udviklere af applikationer, der kører på Kubernetes
Arkitektur og hovedstadier i arbejdet med DevSpace

Derudover er det nemt at tilføje en foruddefineret komponent (for eksempel en MySQL DBMS) eller et Helm-diagram til projektet. Læs mere i dokumentation - det er ikke kompliceret.

Skaffold

  • Site; GitHub.
  • Kort GH-statistik: 7423 stjerner, 4173 commits, 136 bidragydere.
  • Sprog: Gå.
  • Licens: Apache License 2.0.

Dette værktøj fra Google hævder at dække alle behovene hos en udvikler, hvis kode på en eller anden måde vil køre på en Kubernetes-klynge. At begynde at bruge det er ikke så let som devspace: ingen interaktivitet, sproggenkendelse og automatisk oprettelse Dockerfile de vil ikke tilbyde dig det her.

Men hvis dette ikke skræmmer dig, er her, hvad Skaffold tillader dig at gøre:

  • Spor ændringer i kildekoden.
  • Synkroniser den med pod-beholderen, hvis den ikke kræver samling.
  • Saml beholdere med kode, hvis sproget er fortolket, eller kompilér artefakter og pak dem i beholdere.
  • De resulterende billeder kontrolleres automatisk vha container-struktur-test.
  • Mærkning og upload af billeder til Docker Registry.
  • Implementer en applikation i en klynge ved hjælp af kubectl, Helm eller kustomize.
  • Udfør port forwarding.
  • Debug applikationer skrevet i Java, Node.js, Python.

Workflow i forskellige variationer er deklarativt beskrevet i filen skaffold.yaml. For et projekt kan du også definere flere profiler, hvor du helt eller delvist kan ændre monterings- og implementeringsstadierne. Angiv for eksempel til udvikling et basisbillede, der er praktisk for udvikleren, og til iscenesættelse og produktion - et minimum (+ brug securityContext containere eller omdefiner den klynge, hvori applikationen vil blive implementeret).

Docker-containere kan bygges lokalt eller eksternt: in Google Cloud Build eller i en klynge ved hjælp af Kaniko. Bazel og Jib Maven/Gradle understøttes også. Til tagging understøtter Skaffold mange strategier: ved git commit hash, dato/tid, sha256-sum af kilder osv.

Separat er det værd at bemærke muligheden for at teste beholdere. Den allerede nævnte container-struktur-testramme tilbyder følgende verifikationsmetoder:

  • Udførelse af kommandoer i sammenhæng med en container med sporing af exitstatusser og kontrol af kommandoens tekstoutput.
  • Kontrollerer tilstedeværelsen af ​​filer i containeren og matcher de angivne attributter.
  • Kontrol af filindhold ved hjælp af regulære udtryk.
  • Bekræftelse af billedmetadata (ENV, ENTRYPOINT, VOLUMES osv.).
  • Kontrol af licenskompatibilitet.

Synkronisering af filer med containeren udføres ikke på den mest optimale måde: Skaffold opretter blot et arkiv med kilderne, kopierer det og pakker det ud i containeren (tar skal være installeret). Derfor, hvis din hovedopgave er kodesynkronisering, er det bedre at se mod en specialiseret løsning (ksync).

Værktøjer til udviklere af applikationer, der kører på Kubernetes
Hovedstadier af Skaffold-drift

Generelt tillader værktøjet dig ikke at abstrahere fra Kubernetes-manifester og har ingen interaktivitet, så det kan virke svært at mestre. Men det er også dens fordel - større handlefrihed.

Have

  • Site; GitHub.
  • Kort GH-statistik: 1063 stjerner, 1927 commits, 17 bidragydere.
  • Sprog: TypeScript (det er planlagt at opdele projektet i flere komponenter, hvoraf nogle vil være i Go, og også lave et SDK til at lave tilføjelser i TypeScript/JavaScript og Go).
  • Licens: Apache License 2.0.

Ligesom Skaffold har Garden til formål at automatisere processerne for levering af applikationskode til K8s-klyngen. For at gøre dette skal du først beskrive projektstrukturen i en YAML-fil og derefter køre kommandoen garden dev. Hun vil gøre al magien:

  • Saml beholdere med forskellige dele af projektet.
  • Udfører integrations- og enhedstest, hvis nogen er beskrevet.
  • Ruller alle projektkomponenter ud til klyngen.
  • Hvis kildekoden ændres, genstarter den hele pipelinen.

Hovedfokus ved at bruge dette værktøj er at dele en fjernklynge med et udviklingsteam. I dette tilfælde, hvis nogle af bygge- og testtrinene allerede er udført, vil dette fremskynde hele processen betydeligt, da Garden vil være i stand til at bruge de cachelagrede resultater.

Et projektmodul kan være en beholder, en Maven-beholder, et Helm-diagram, et manifest for kubectl apply eller endda en OpenFaaS-funktion. Desuden kan et hvilket som helst af modulerne trækkes fra et eksternt Git-lager. Et modul kan definere tjenester, opgaver og tests. Tjenester og opgaver kan have afhængigheder, takket være hvilke du kan bestemme implementeringssekvensen for en bestemt tjeneste og organisere lanceringen af ​​opgaver og test.

Garden giver brugeren et smukt dashboard (i øjeblikket i eksperimentel tilstand), som viser projektgrafen: komponenter, samlingssekvens, udførelse af opgaver og test, deres forbindelser og afhængigheder. Lige i browseren kan du se logfilerne for alle projektkomponenter og tjekke, hvad en bestemt komponent udsender via HTTP (hvis der selvfølgelig er deklareret en indgangsressource for den).

Værktøjer til udviklere af applikationer, der kører på Kubernetes
Panel til haven

Dette værktøj har også en hot-reload-tilstand, som blot synkroniserer scriptændringer med containeren i klyngen, hvilket i høj grad fremskynder applikationsfejlretningsprocessen. Have har en god en dokumentation og ikke dårligt sæt eksempler, så du hurtigt kan vænne dig til det og begynde at bruge det. Forresten, for nylig har vi offentliggjort artiklens oversættelse fra dens forfattere.

Konklusion

Selvfølgelig er denne liste over værktøjer til udvikling og fejlretning af applikationer i Kubernetes ikke begrænset til. Der er mange flere meget nyttige og praktiske værktøjer, der er værdige, hvis ikke en separat artikel, så i det mindste en omtale. Fortæl os, hvad du bruger, hvilke problemer du stødte på, og hvordan du løste dem!

PS

Læs også på vores blog:

Kilde: www.habr.com

Tilføj en kommentar