Hvordan lage en webhook i Kubernetes
Hva er webhooks?
Du har kanskje kommet over begrepet webhook i appens innstillinger. Du lurer kanskje på om en webhook er av noen nytte for deg eller ikke. Vel, svaret er et absolutt ja. Webhook er en måte å levere dataene til en applikasjon. Webhooks, med enkle ord, lar deg levere meldingene helt fra den ene appen til den andre. Hver gang en hendelse er fullført, sendes automatiserte meldinger til søknaden. Webhooks er hva disse automatiserte svarene er. Konseptet ligner veldig på SMS -varsler.
For eksempel eier du en PayPal -konto, og noen vil overføre pengene dine. For å vite om hendelsen er vellykket, trenger du noe varsel. Det er her webhooks spiller inn. Webhooken lar PayPal fortelle regnskapsappen din når systemet fullfører postanvisning. Tilsvarende varsler WooCommerce deg om ordrene dine i Slack via Webhooks.
La oss nå diskutere forutsetningene og trinn-for-trinn-prosessen for å lage en webhook i Kubernetes.
Forutsetninger:
Før opprettelsen av nettkroker, la oss se på forutsetningene. Du må sørge for at systemet ditt samsvarer med alle standardene før du kan bygge webhooken din:
- Ubuntu 20.04 eller noen annen siste versjon for å ha et Linux/Unix -miljø å jobbe
- Kubernetes Cluster
- Kubectl CLI for å bruke KUBECTL -kommandoer, klyngekommunikasjon og administrere utviklingsmiljøet
- Minikube eller noen annen Kubernetes lekeplass for å lage klyngene
Hvis du ikke har installert disse verktøyene, er det første trinnet ditt å installere dem umiddelbart. Når du har fått disse verktøyene, kan vi gå videre til neste del. La oss dykke rett inn i opprettelsen av webhooks, trinn for trinn.
Trinn 1: Konfigurasjonsfilformat
For HTTP -konfigurasjonsmodus krever WebHook en fil. Denne konfigurasjonsfilen bruker KubeConfig-filformatet og spesifiserer den med -autoriseringen-WebHook-Config-File = Some_Filename Flag. Filen inneholder to elementer - brukere og klynger. Brukere viser til API Server WebHook i filen, mens klynger viser til ekstern tjeneste.
Slik ser en enkel konfigurasjonsfil ut:
I vedlagte skjermbilde kan du se API -versjonen og typen API i de to første linjene. Etter det presenteres klyngene, brukerne og gjeldende kontekstinformasjon. Husk at Kubeconfig -filer trenger kontekst. Derfor må du gi en til API -serveren. Dette er hva vi oppnådde i forrige trinn, som du kan se fra forrige bilde.
Når HTTP -konfigurasjonen er gjort vellykket, kan vi gå videre til neste trinn som ber om nyttelasten.
Trinn 2: Be om nyttelast
API-serveren legger ut en JSON-serialisert autorisasjon.K8s.IO/V1beta1 emneAccessReviewObject når det er i ferd med å bli autorisert. Dette gjøres for å varsle om autorisasjonsbeslutningen. Dette objektet inneholder informasjon om feltet og ressursen. Ressursinformasjonen definerer egenskapene som ble åpnet eller bedt om, mens feltdetaljene identifiserer personen som prøver å komme med forespørselen.
Her er det en viktig ting å huske på at versjonsreglene ikke er forskjellige for WebHook API -objekter og er like lik Kubernetes API -objekter. Riktig deserialisering er avgjørende for oppretting av webhook. For å oppnå en presis deserialisering, bør implementererne alltid ta hensyn til to faktorer: Potensialet for Beta -objekts løsere kompatibilitetsløfter og behovet for å sjekke forespørselsens apiversionfelt. Dessuten må API -serveren aktivere autorisasjonen.K8s.IO/V1beta1API Extensions Group (-Runtime-Config = Autorization.K8s.io/v1beta1 = true).
Her er et eksempel på forespørselsorgan som vi har lagt ved for din hjelp:
Fjerntjeneste holdes ansvarlig for å tillate og ikke tillate tilgang, noe som gjøres ved å fylle ut statusfeltet. Vi vil diskutere begge typer svar trinn for trinn. Når du snakker om den tillatte responsorganets spesifikasjon, kan du la det være tomt eller utelate den helt. Det meste av tiden blir det ignorert. Et eksempel på å tillate tilgang er som følger:
Neste opp er den ikke tillatte tilgangen. Det er nå to metoder for å utføre en ikke tillate respons. Implementereren foretrekker vanligvis den første metoden i de fleste tilfeller. Denne metoden er avhengig av konfigurasjonen av autorisatorer. Autorisatorer har lov til å godkjenne forespørselen hvis de er konfigurert. I det motsatte scenariet, der det ikke er noen autorisatorer eller bare ikke tillater forespørselen, blir ikke forespørselen godkjent for å generere et tillatt svar. Følgende bilde viser et nektet svar:
Hvorfor bruke Kubernetes til webhooks?
Kubernetes er et open source-system for å administrere kommunikasjonen mellom programvare, skalering og automatisering. Når det gjelder backend -klyngehastighet og håndterbarhet, har Kubernetes betydelig avansert de siste årene. På grunn av sin fantastiske fleksibilitet, skalerbarhet og enkel drift, er det en av de beste programvarene for backend -klynger i dag. En av de viktigste funksjonene til Kubernetes er at den gir funksjoner for å sikre den sikre produksjonsmengden.
Forskjell mellom API og webhook
Både API og Webhooks brukes ofte i programvareverdenen daglig. Du kan bruke begrepene om hverandre. Siden de begge har en lignende operasjon, er forvirring ganske gyldig. De er imidlertid ikke de samme tingene. Den viktigste forskjellen mellom API og webhook er at APIer er manuelle, men netthooks er automatisert. Når det gjelder API -er, må de bli bedt om å få tilgang til eller nekte forespørslene. Imidlertid gjør Webhook det på egen hånd. Vi kan si at Webhook er et undergruppe av API. Derfor har de et mye begrenset omfang. Hovedpoenget er at APIer krever en brukers kommando for å utføre et svar, mens webhooks ikke er avhengig av noen slike brukerkommandoer.
Konklusjon
Denne artikkelen presenterte et fugleperspektiv av hva webhooks er og hvordan du lager dem på Kubernetes. I denne artikkelen lærte vi hvorfor Kubernetes er den mest populære programvaren for å bygge webhooks. Etter guiden som er oppgitt i denne artikkelen, vil vi hjelpe deg med å lage nettkrokene dine på kort tid, og med letthet.