Verktøy for utviklere av applikasjoner som kjører på Kubernetes

Verktøy for utviklere av applikasjoner som kjører på Kubernetes

En moderne tilnærming til drift løser mange presserende forretningsproblemer. Beholdere og orkestratorer gjør det enkelt å skalere prosjekter av enhver kompleksitet, forenkler utgivelsen av nye versjoner, gjør dem mer pålitelige, men samtidig skaper de ytterligere problemer for utviklere. Programmereren bryr seg først og fremst om koden sin: arkitektur, kvalitet, ytelse, eleganse - og ikke hvordan den vil fungere i Kubernetes og hvordan den skal teste og feilsøke den etter å ha gjort selv minimale endringer. Derfor er det også ganske naturlig at verktøy for Kubernetes aktivt utvikles, som hjelper til med å løse problemene til selv de mest "arkaiske" utviklerne og lar dem fokusere på det viktigste.

Denne anmeldelsen gir kort informasjon om noen av verktøyene som gjør livet enklere for en programmerer hvis kode kjører i pod'axen til en Kubernetes-klynge.

Enkle hjelpere

Kubectl-debug

  • Poenget: legg beholderen til en Pod og se hva som skjer i den.
  • GitHub.
  • Kort GH-statistikk: 715 stjerner, 54 forpliktelser, 9 bidragsytere.
  • Språk: Gå.
  • Lisens: Apache License 2.0.

Denne plugin for kubectl lar deg lage en ekstra beholder inne i poden av interesse, som vil dele prosessnavneområdet med andre beholdere. I den kan du feilsøke podens operasjon: sjekk nettverket, lytt til nettverkstrafikk, gjør en oversikt over prosessen av interesse, etc.

Du kan også bytte til prosessbeholderen ved å kjøre chroot /proc/PID/root - dette kan være veldig praktisk når du trenger å få et rotskall i en beholder som det er satt til i manifestet securityContext.runAs.

Verktøyet er enkelt og effektivt, så det kan være nyttig for alle utviklere. Vi skrev mer om det i separat artikkel.

Telepresence

  • Poenget: overføre applikasjonen til datamaskinen din. Utvikle og feilsøke lokalt.
  • Området; GitHub.
  • Kort GH-statistikk: 2131 stjerner, 2712 forpliktelser, 33 bidragsytere.
  • Språk: Python.
  • Lisens: Apache License 2.0.

Ideen med denne snap-in er å starte en container med applikasjonen på den lokale brukerdatamaskinen og proxy all trafikk fra klyngen til den og tilbake. Denne tilnærmingen lar deg utvikle lokalt ved ganske enkelt å redigere filer i din favoritt-IDE: resultatene vil være tilgjengelig umiddelbart.

Fordelene med å kjøre lokalt er praktiske redigeringer og umiddelbare resultater, muligheten til å feilsøke applikasjonen på vanlig måte. Ulempen er at det er krevende for tilkoblingshastighet, noe som merkes spesielt når du skal jobbe med en applikasjon med ganske høy RPS og trafikk. I tillegg har Telepresence problemer med volummonteringer på Windows, noe som kan være en avgjørende begrensning for utviklere som er vant til dette operativsystemet.

Vi har allerede delt vår erfaring med bruk av Telepresence her.

Ksync

  • Poenget: nesten øyeblikkelig synkronisering av kode med beholderen i klyngen.
  • GitHub.
  • Kort GH-statistikk: 555 stjerner, 362 forpliktelser, 11 bidragsytere.
  • Språk: Gå.
  • Lisens: Apache License 2.0.

Verktøyet lar deg synkronisere innholdet i en lokal katalog med katalogen til en beholder som kjører i klyngen. Et slikt verktøy er perfekt for utviklere i skriptprogrammeringsspråk, hvis hovedproblem er å levere kode til en kjørende container. Ksync er designet for å lindre denne hodepinen.

Når initialisert én gang med kommandoen ksync init et DaemonSet opprettes i klyngen, som brukes til å overvåke tilstanden til filsystemet til den valgte beholderen. På sin lokale datamaskin kjører utvikleren kommandoen ksync watch, som overvåker konfigurasjoner og kjører syncthing, som direkte synkroniserer filer med klyngen.

Alt som gjenstår er å instruere ksync hva som skal synkroniseres med hva. For eksempel denne kommandoen:

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

... vil opprette en overvåker som heter myprojectsom vil søke etter en pod med en etikett app=backend og prøv å synkronisere den lokale katalogen /home/user/myproject/ med katalog /var/www/myproject/ ved containeren kalt php.

Problemer og merknader om ksync fra vår erfaring:

  • Må brukes på Kubernetes-klyngenoder overlay2 som lagringsdriver for Docker. Verktøyet vil ikke fungere med andre.
  • Når du bruker Windows som et klient-OS, kan det hende at filsystemovervåkingen ikke fungerer som den skal. Denne feilen ble lagt merke til når du jobbet med store kataloger - med et stort antall nestede filer og kataloger. Vi skapte relevant problemstilling i synkroniseringsprosjektet, men det er ingen fremgang på det ennå (siden begynnelsen av juli).
  • Bruk fil .stignore for å spesifisere baner eller filmønstre som ikke trenger å synkroniseres (for eksempel kataloger app/cache и .git).
  • Som standard vil ksync starte beholderen på nytt når filene endres. For Node.js er dette praktisk, men for PHP er det helt unødvendig. Det er bedre å slå av opcache og bruke flagget --reload=false.
  • Konfigurasjonen kan alltid korrigeres i $HOME/.ksync/ksync.yaml.

squash

  • Poenget: feilsøke prosesser direkte i klyngen.
  • GitHub.
  • Kort GH-statistikk: 1154 stjerner, 279 forpliktelser, 23 bidragsytere.
  • Språk: Gå.
  • Lisens: Apache License 2.0.

Dette verktøyet er designet for å feilsøke prosesser direkte i pods. Verktøyet er enkelt og interaktivt lar deg velge ønsket debugger (se nedenfor) og navneområde + pod, i prosessen som du må gripe inn. Støttes for øyeblikket:

  • dykke - for Go-applikasjoner;
  • GDB - via målfjernkontroll + portvideresending;
  • JDWP-portvideresending for feilsøking av Java-applikasjoner.

På IDE-siden er støtte bare tilgjengelig i VScode (ved hjelp av utvidelse), men planene for inneværende (2019) år inkluderer Eclipse og Intellij.

For å feilsøke prosesser kjører Squash en privilegert beholder på klyngenodene, så du må først gjøre deg kjent med egenskapene sikkerhetsmodus for å unngå sikkerhetsproblemer.

Integrerte løsninger

La oss gå videre til det tunge artilleriet - mer "storskala" prosjekter designet for umiddelbart å møte mange av behovene til utviklere.

NB: I denne listen er det selvfølgelig en plass for vårt Open Source-verktøy werf (tidligere kjent som dapp). Vi har imidlertid allerede skrevet og snakket om det mer enn en gang, og bestemte oss derfor for ikke å inkludere det i anmeldelsen. For de som ønsker å bli mer kjent med dens evner, anbefaler vi å lese/lytte til rapporten "werf er vårt verktøy for CI/CD i Kubernetes'.

DevSpace

  • Poenget: for de som vil begynne å jobbe i Kubernetes, men ikke ønsker å dykke dypt inn i jungelen.
  • GitHub.
  • Kort GH-statistikk: 630 stjerner, 1912 forpliktelser, 13 bidragsytere.
  • Språk: Gå.
  • Lisens: Apache License 2.0.

En løsning fra selskapet med samme navn, som gir administrerte klynger med Kubernetes for teamutvikling. Verktøyet ble laget for kommersielle klynger, men fungerer utmerket med alle andre.

Når du kjører kommandoen devspace init i prosjektkatalogen vil du bli tilbudt (interaktivt):

  • velg en fungerende Kubernetes-klynge,
  • bruk eksisterende Dockerfile (eller generer en ny) for å lage en beholder basert på den,
  • velg et depot for lagring av beholderbilder osv.

Etter alle disse forberedende trinnene kan du starte utviklingen ved å kjøre kommandoen devspace dev. Den vil bygge beholderen, laste den opp til depotet, rulle ut distribusjonen til klyngen og starte portvideresending og synkronisering av beholderen med den lokale katalogen.

Eventuelt vil du bli bedt om å flytte terminalen til containeren. Du bør ikke nekte, for i virkeligheten starter beholderen med dvalekommandoen, og for reell testing må applikasjonen startes manuelt.

Endelig laget devspace deploy ruller ut applikasjonen og tilhørende infrastruktur til klyngen, hvoretter alt begynner å fungere i kampmodus.

All prosjektkonfigurasjon lagres i en fil devspace.yaml. I tillegg til utviklingsmiljøinnstillingene, kan du også finne en beskrivelse av infrastrukturen i den, lik standard Kubernetes-manifester, bare sterkt forenklet.

Verktøy for utviklere av applikasjoner som kjører på Kubernetes
Arkitektur og hovedstadier i arbeidet med DevSpace

I tillegg er det enkelt å legge til en forhåndsdefinert komponent (for eksempel en MySQL DBMS) eller et Helm-diagram til prosjektet. Les mer i dokumentasjon – det er ikke komplisert.

Skaffold

  • Området; GitHub.
  • Kort GH-statistikk: 7423 stjerner, 4173 forpliktelser, 136 bidragsytere.
  • Språk: Gå.
  • Lisens: Apache License 2.0.

Dette verktøyet fra Google hevder å dekke alle behovene til en utvikler hvis kode på en eller annen måte vil kjøre på en Kubernetes-klynge. Å begynne å bruke det er ikke så enkelt som devspace: ingen interaktivitet, språkgjenkjenning og automatisk opprettelse Dockerfile de vil ikke tilby det til deg her.

Men hvis dette ikke skremmer deg, er dette hva Skaffold lar deg gjøre:

  • Spor endringer i kildekoden.
  • Synkroniser den med podbeholderen hvis den ikke krever montering.
  • Samle beholdere med kode, hvis språket er tolket, eller kompiler artefakter og pakk dem inn i beholdere.
  • De resulterende bildene kontrolleres automatisk ved hjelp av beholder-struktur-test.
  • Merking og opplasting av bilder til Docker Registry.
  • Distribuer en applikasjon i en klynge ved å bruke kubectl, Helm eller kustomize.
  • Utfør portvideresending.
  • Feilsøke applikasjoner skrevet i Java, Node.js, Python.

Arbeidsflyt i ulike varianter er deklarativt beskrevet i filen skaffold.yaml. For et prosjekt kan du også definere flere profiler der du helt eller delvis kan endre monterings- og distribusjonsstadiene. For eksempel, for utvikling, spesifiser et basisbilde som er praktisk for utvikleren, og for iscenesettelse og produksjon - et minimum (+ bruk securityContext beholdere eller redefinere klyngen der applikasjonen skal distribueres).

Docker-containere kan bygges lokalt eller eksternt: in Google Cloud Build eller i en klynge ved hjelp av Kaniko. Bazel og Jib Maven/Gradle støttes også. For tagging støtter Skaffold mange strategier: ved git commit hash, dato/klokkeslett, sha256-sum av kilder, etc.

Separat er det verdt å merke seg muligheten for å teste beholdere. Det allerede nevnte beholder-struktur-testrammeverket tilbyr følgende verifiseringsmetoder:

  • Utføre kommandoer i sammenheng med en beholder med sporing av utgangsstatuser og sjekke tekstutgangen til kommandoen.
  • Kontrollerer tilstedeværelsen av filer i beholderen og samsvarer med de spesifiserte attributtene.
  • Kontroll av filinnhold ved hjelp av regulære uttrykk.
  • Verifisering av bildemetadata (ENV, ENTRYPOINT, VOLUMES etc.).
  • Sjekker lisenskompatibilitet.

Synkronisering av filer med containeren utføres ikke på den mest optimale måten: Skaffold lager ganske enkelt et arkiv med kildene, kopierer det og pakker det ut i containeren (tar må være installert). Derfor, hvis hovedoppgaven din er kodesynkronisering, er det bedre å se mot en spesialisert løsning (ksync).

Verktøy for utviklere av applikasjoner som kjører på Kubernetes
Hovedfaser i Skaffold-driften

Generelt lar verktøyet deg ikke abstrahere fra Kubernetes-manifester og har ingen interaktivitet, så det kan virke vanskelig å mestre. Men dette er også dens fordel - større handlefrihet.

Hage

  • Området; GitHub.
  • Kort GH-statistikk: 1063 stjerner, 1927 forpliktelser, 17 bidragsytere.
  • Språk: TypeScript (det er planlagt å dele opp prosjektet i flere komponenter, hvorav noen vil være i Go, og også lage en SDK for å lage tillegg i TypeScript/JavaScript og Go).
  • Lisens: Apache License 2.0.

I likhet med Skaffold har Garden som mål å automatisere prosessene med å levere søknadskode til K8s-klyngen. For å gjøre dette må du først beskrive prosjektstrukturen i en YAML-fil, og deretter kjøre kommandoen garden dev. Hun vil gjøre all magien:

  • Samle containere med ulike deler av prosjektet.
  • Gjennomfører integrasjon og enhetstester, hvis noen er beskrevet.
  • Ruller ut alle prosjektkomponenter til klyngen.
  • Hvis kildekoden endres, vil den starte hele rørledningen på nytt.

Hovedfokuset ved å bruke dette verktøyet er å dele en ekstern klynge med et utviklingsteam. I dette tilfellet, hvis noen av bygge- og testtrinnene allerede er utført, vil dette fremskynde hele prosessen betydelig, siden Garden vil kunne bruke de hurtigbufrede resultatene.

En prosjektmodul kan være en beholder, en Maven-beholder, et Helm-diagram, et manifest for kubectl apply eller til og med en OpenFaaS-funksjon. Dessuten kan alle modulene hentes fra et eksternt Git-lager. En modul kan eller ikke definere tjenester, oppgaver og tester. Tjenester og oppgaver kan ha avhengigheter, slik at du kan bestemme distribusjonssekvensen til en bestemt tjeneste og organisere lanseringen av oppgaver og tester.

Garden gir brukeren et vakkert dashbord (for øyeblikket inne eksperimentell tilstand), som viser prosjektgrafen: komponenter, monteringssekvens, utførelse av oppgaver og tester, deres forbindelser og avhengigheter. Rett i nettleseren kan du se loggene til alle prosjektkomponenter og sjekke hva en bestemt komponent sender ut via HTTP (hvis, selvfølgelig, en inngående ressurs er deklarert for den).

Verktøy for utviklere av applikasjoner som kjører på Kubernetes
Panel for hage

Dette verktøyet har også en hot-reload-modus, som ganske enkelt synkroniserer skriptendringer med beholderen i klyngen, noe som gjør applikasjonsfeilsøkingsprosessen betydelig raskere. Hagen har en god en dokumentasjonen og ikke dårlig sett med eksempler, slik at du raskt kan venne deg til det og begynne å bruke det. Forresten, nylig publiserte vi artikkeloversettelse fra forfatterne.

Konklusjon

Selvfølgelig er denne listen over verktøy for utvikling og feilsøking av applikasjoner i Kubernetes ikke begrenset til. Det er mange flere veldig nyttige og praktiske verktøy som er verdig, om ikke en egen artikkel, så i det minste en omtale. Fortell oss hva du bruker, hvilke problemer du har møtt og hvordan du løste dem!

PS

Les også på bloggen vår:

Kilde: www.habr.com

Legg til en kommentar