Tilbyr Docker og Kubernetes den "beste arkitekturen"?

Hei, jeg er tilbake med en annen artikkel. Men denne gangen er jeg i humør til å løse noen myter.

Verden forandrer seg hvert sekund, og det samme er teknologien. Når det gjelder Docker og Kubernetes, må du lytte til mange ting. Spesielt sammenligningen mellom deres arkitektur. Mange lurer på at hvilken som er bedre?

Det er mange andre spørsmål, og jeg nevner dem alle. Hvorfor? Den eneste grunnen er at det vil hjelpe deg å forstå Kubernetes og Docker. Så hvordan Docker og Kubernetes har endret programvareutviklingen? Har noen av dem en sterk arkitektur? Er det mulig å forene utviklings- og integrasjonsprosesser? Hvis ja, hva er begrensningene? Vil dette redusere komplikasjoner for utviklere?

For det første, forstå at en sammenligning mellom Docker og Kubernetes ikke er så enkel som du tror. Hva er bedre? Docker eller Kubernetes? Jeg tror det ikke er noe bedre fordi de begge er forskjellige. Docker er buss mens Kubernetes er bussport. Så hva er viktig? Visst er begge deler viktige. Du trenger dem begge.

Så i denne artikkelen vil vi reise fra det virkelige liv til utviklingsprosessene til arkitekturen og tilbake til det virkelige liv.

Videre vil vi identifisere forskjellige komponenter og prinsipper som er en del av arkitekturen. Til slutt kan konklusjonen overraske deg eller glede deg. Det avhenger av din oppfatning og erfaring med Docker og Kubernetes.

Den første overgangen fra det virkelige livet til arbeidsflyten

Vet du hvorfor utviklingsprosessene er viktige? Hvis det ikke er noen utviklingsprosesser, er det ingen godt rettet generalisert tilnærming. En utviklingsprosess reduserer tiden mellom fødselen av en idé til levering. Det forenkler prosessen og opprettholder kvaliteten.

Det er to typer ideer, den ene er god og den andre er dårlig. Det er ingen tredje type mellomide i utvikling. Ideen kan være god eller dårlig, men den kan bare måles med implementeringen. Hvis det er en dårlig idé, implementerer og ruller du tilbake! Hvis det er en god idé, fortsetter du bare. Tilbakekjøringen styres av en robot, dvs. automatisering.

Av alt dette har kontinuerlig integrasjons- og leveringssystem vist seg som en livredder. Det har gjort ting enklere. Hvis du har en idé og koden, implementer den! Men det er ett lite problem med integrasjons- og leveringssystem. Prosessen er vanskelig å formalisere isolert fra teknologi og forretningsprosesser, spesifikke for din bedrift.

Så hvordan ble dette problemet løst?

Nå ble dette problemet løst ved hjelp av Docker og Kubernetes. Begge fremsto som Messiaser. Abstraksjonsnivået og den ideologiske tilnærmingen løste nesten 80% av problemet. Husk at 80% er en veldig god prosentandel i utviklingssektoren. De 20% er fremdeles der, og man må være et kreativt geni for å løse det. Det avhenger av type søknad og hvordan du løser det.

Docker løser problemet med utviklingsarbeidsflyt. Docker tilbyr en enkel prosess og er tilstrekkelig for de fleste arbeidsmiljøer.

Bildekilde: https://cdn-images-1.medium.com/max/800/0*nDrc_jeOKTMS7akB.

Ved hjelp av denne tilnærmingen kan man automatisere og forene alt.

Introduksjon til utviklingsmiljøet

Først av alt må prosjektet bestå av en docker-compose.yml-fil. Fordelen med denne filen er at den vil fjerne byrden ved å kjøre applikasjonen / tjenesten på den lokale maskinen. Utvikleren trenger ikke å tenke på det. Faktisk er bare en enkel docker-komponere-kommando nok til å starte applikasjonen. Kommandoen tar også vare på avhengighetene, fyller databasen med inventar, laster opp den lokale koden inne i beholderen, aktiverer kodesporing og svarer på den forventede porten.

I tillegg til alt dette, trenger du heller ikke bekymre deg for å starte, utføre endringer, valg av rammeverk, etc. Alt og alt er beskrevet i standardinstruksjonene på forhånd. Det er diktert av servicemaler i henhold til oppsettene som frontend, backend og arbeider.

Tid for den automatiserte testen

Har du hørt om “Black Box”? Den registrerer alt, også de siste sekundene før et flyulykke. Hva skjedde? Hvordan skjedde det? Alt dette er hentet fra den svarte boksen. Tilsvarende er det en svart boks her.

Bildekilde: https://cdn-images-1.medium.com/max/800/0*B5Qn9D5W4lscB86h.

Som den originale, svarte boksen, lagrer vår containersvarte boks alt. Alle binære data, 1 eller 0 osv. Lagres i den svarte boksen. Så hvordan automatisering skjer? Det er enkelt, du har et sett med kommandoer, og docker-compose.yml beskriver alle avhengigheter. Dette fører til automatisering og enhetlig testing. Det er ikke nødvendig å fokusere på implementeringsdetaljene.

Systemleveransen

Bildekilde: https://cdn-images-1.medium.com/max/800/0*DC5Ubn7Y5seJPeSO.

Plasseringen og tidspunktet for installering av prosjektet ditt spiller ingen rolle. Det er ingen forskjell på hvilken del av hele økosystemet du skal installere. Resultatet av installasjonsprosessen vil alltid være det samme. Det som betyr mest er "idempotens". Angi variablene som kontrollerer installasjonen fra din side.

Det er en algoritme for alt dette. La oss liste det ned trinnvis.

(1) Samle bilder fra Dockerfiles.

(2) Bruk et metaprosjekt for å levere bildene. De skal leveres Kubernetes via Kube API. Inngangsparametrene som kreves er:

(a) Et Kube API-sluttpunkt

(b) Et hemmelig objekt som varierer for forskjellige kontekster (lokal / showroom / iscenesettelse / produksjon)

Systemnavn og tagger for Docker-bildene for disse systemene.

Vurder for eksempel et metaprosjekt som består av alle systemer og tjenester. Dette betyr at prosjektet beskriver arrangementet av økosystemet, og det beskriver også hvordan oppdateringer leveres til det. For dette vil jeg bruke Ansible spillbøker for integrasjon med Kube API. Men det er andre alternativer også! Totalt sett må du tenke i en sentralisert retning for å styre arkitekturen. Når du er trygg på det, kan du enkelt administrere tjenestene / systemene.

Installasjon av et miljø er nødvendig i utstillingslokalet (for manuell kontroll og feilsøking av systemet), iscenesettelse (for nærmest levende miljøer og integrasjon) og produksjon (det faktiske miljøet for sluttbrukeren).

Kontinuerlig levering og integrasjon

Du er en lykkelig person hvis du følger en enhetlig måte å teste Docker-bildene på. Det vil hjelpe deg sømløst å integrere funksjonsgrener i oppstrøms eller mestre grener av git-depotet. Det eneste som skal tas vare på er å opprettholde sekvensen for integrering og levering. Hvis det ikke er noen utgivelser, hvordan vil du forhindre "løpskondisjon" på ett system med flere parallelle funksjoner grener?

Så hva er løsningen? Prosessen skal starte når det ikke er konkurranse.

Stegene:

(1) Oppdater funksjonsgrenen til oppstrøms.

(2) Bygg bilder.

(3) Test de innebygde bildene.

(4) Start og vent til trinn-2 er fullført og bildene blir levert.

(5) Hvis trinn 4 mislykkes, kan du rulle tilbake økosystemet til forrige trinn.

(6) Kombiner funksjonsgren i oppstrøms. Send den til depotet.

Hvis noen av trinnene ovenfor mislykkes, avsluttes leveringsprosessen umiddelbart. Oppgaven blir returnert til utvikleren til den ikke er løst. Den samme prosessen kan fungere med mer enn ett depot. Hvert av trinnene bør gjøres på en lignende måte, men for hvert depot. For eksempel trinn 1 for depot A og trinn for depot B, og så videre.

Kubernetes gir deg friheten til å rulle ut oppdateringer i deler. Tallrike AB-tester kan rulle ut og gjennomgå risikoanalyse. Kubernetes skiller internt tjenester og applikasjoner.

Rollback-systemene

Av noen av de viktigste evnene til et sterkt arkitektonisk rammeverk, er en evne til å rulle sammen. Det er en rekke eksplisitte og implisitte nyanser. La oss se på dem:

(1) Tjenesten skal være i stand til å sette opp miljøet og også tilbakestilling.

(2) Hvis tilbaketrekning ikke er mulig, bør tjenesten være polymorf. Den skal støtte både de gamle og de nye versjonene av koden.

(3) Det skal være en bakoverkompatibilitet for enhver tjeneste etter tilbakekoblingen.

I Kubernetes-klyngen er det enkelt å tilbakestille tilstander. Men det vil bare fungere hvis metaprosjektet ditt inneholder informasjon om dette øyeblikksbildet. Komplekse leveringsrulleringsalgoritmer frarådes, men er nødvendige.

Så under hvilke omstendigheter skal tilbaketrekningsmekanismen utløses?

(1) Når prosentandelen av applikasjonsfeil er høy etter utgivelsen.

(2) Når du begynner å motta signaler fra viktige overvåkingspunkter.

(3) Når røykprøvene mislykkes.

(4) Det kan gjøres manuelt.

Sikkerhetstiltak

Å gjøre økosystemet skuddsikker er ikke enkelt. Det kan ikke gjøres ved å bare følge en enkelt arbeidsflyt. Det arkitektoniske rammeverket skal være sikkert nok til å takle eventuelle problemer. Kubernetes kommer med noen gode innebygde mekanismer for tilgangskontroll, nettverkspolitikk, revisjon av hendelser, etc. Det er noen verktøy for informasjonssikkerheten, og de har vist seg å være utmerkede når det gjelder beskyttelse.

Det neste trinnet, fra utviklingsarbeidsflyter til arkitekturen

Et arkitektonisk rammeverk som tilbyr fleksibilitet, skalerbarhet, tilgjengelighet, pålitelighet, beskyttelse mot trusler osv. Er nesten obligatorisk. Dette er en avgjørende ting. Faktisk førte dette behovet til et nytt konsept. Noen gjetninger? Ja, DevOps. Det førte til det komplette automatiserings- og optimaliseringsinfrastrukturkonseptet.

Nå var det på tide å endre arkitekturen fra monolitisk til mikroservices. Det gir enorme fordeler med en serviceorientert arkitektur. I det minste for Docker og Kubernetes er det ideologisk galt å bruke en monolitisk arkitektur. Jeg vil helt sikkert diskutere noen punkter i mikroservicearkitekturen. For inngående kunnskap om DevOps, kan du lese denne artikkelen på DevOps.

Nå vil vi raskt diskutere de viktigste kritiske komponentene og løsningene til en god arkitektur.

De kritiske komponentene

Nummer 1- Identitetstjeneste:

Identity microservice refererer til “identiteten som en mikroservice”. Tjenestene er lette. Det gir modularitet og muliggjør fleksibilitet i applikasjonen. Identitetsmikroservice er kraftig og har tilgang til alle profildataene. Den er i stand til å tilby alt som trengs i kjernen av alle applikasjonene.

Hvis du vil være klient for større bedriftsplattformer som IBM, Google, Microsoft osv., Vil tilgangen bli håndtert av leverandørens tjenester. Men hva hvis du vil ha din egen løsning? Listen i den kommende delen vil hjelpe deg med å bestemme den.

Nummer 2- Den automatiserte tjenesteleveransen:

Tjenestene som er bygget er uavhengige av hverandre. Dette fører til enkel utvikling og færre feil. Det hjelper også med å søke andre tjenester i et dynamisk og automatisert mønster.

Kubernetes reduserer behovet for tilleggskomponenter. Men likevel må man automatisere tillegget til nye maskiner. Her er en liste over verktøy:

(1) KOPS - Hjelper deg med å installere en klynge på AWS eller GCE.

(2) Teraform - Hjelper deg med å administrere infrastrukturen for ethvert miljø.

(3) Ansible - Tilbyr automatisering av noe slag.

Jeg personlig anbefaler Ansible fordi det hjelper deg å jobbe med både servere og Kubernetes-objekter.

Nummer 3- Git-lager og oppgavesporing:

Med Git-lagringsplasser kan oppgavene takles enkelt. Den grunnleggende ideen er å ha et lite depot. Det fungerer som en miljøspor. Innholdet inkluderer hvilken type versjoner som skal brukes til forskjellige tjenester. Det foretrukne kildekontrollsystemet for dette er "git".

Det skal være et skikkelig arbeidssted for teamarbeid og kodelager for alle viktige diskusjoner. Hvis du vil ha en gratis tjeneste, kan du gå til Redmine. Ellers er Jira en betalt tjeneste og er ganske nyttig. For kodelageret er Gerrit et godt valg, gratis!

Nummer 4- Docker-registeret:

Dockerregistret er en type lagrings- og innholdsleveringssystem. Den har navnet på Docker-bilder og er tilgjengelig i forskjellige taggede versjoner. For å samhandle med et register, bør brukeren skyte og dra kommandoer.

Bildebehandlingssystemet for docker er ganske viktig. Systemet skal også støtte tilgang for brukere og en gruppe brukere. For dette velger du en skyløsning eller en privat vertstjeneste. Et godt alternativ er Vmware Harbor.

Nummer 5- CI / CD og levering av tjenester:

Bare kontinuerlig integrasjon og leveringstjeneste kobler komponentene diskutert tidligere. Kontinuerlig levering viser til at tjenesten er enkel og fratas enhver logikk. CI / CD-tjenesten skal bare reagere på omverdenen som forandringer i git-depotet, etc.

Integrasjonstjenesten er ansvarlig for automatisk tjenestetesting, tjenestelevering, tilbakeringing, fjerning av tjenester og bildebygging.

Nummer 6- Loggsamling og analyse:

I enhver mikroservice-applikasjon er sporing av problemet viktig. Sporing er mulig ved hjelp av logging. Så logging og overvåking gir deg et helhetlig syn på systemet.

Logger blir gjort tilgjengelige ved å skrive dem til STDOUT eller STDERR for rotprosessen. Loggdataene skal være tilgjengelige ved behov. Den skal også inneholde poster fra fortiden.

Nummer 7- Sporing, overvåking og varsling:

Verktøy som Opentracing og Zipkin hjelper deg med å forstå feilen. Som hvor gikk du galt? Disse verktøyene vil hjelpe deg med å svare på slike spørsmål. Svikt skjer og det er viktig å spore dem.

Videre er overvåking delt inn i tre nivåer. Dette er det fysiske nivået, klyngenivået og servicenivået. Det er ikke rom for feil i overvåkningen. Verktøy som Prometheus og OpsGenie har vist seg å være ganske nyttige for overvåking. OpsGenie varsler og varsler også om problemer på alle nivåer. Så sporing, overvåking og varsler bør aldri tas lett. De er den defensive delen av søknaden.

Nummer 8- API-gateway med enkelt pålogging:

I mikroservices skal alle samtalene kun gå via API Gateway. Det hjelper med å opprettholde sikkerheten. Det er også ansvarlig for ruting av API-forespørsler. Så API Gateway er et inngangspunkt for alle sine respektive mikroservices. Enkelt pålogging refererer til en økt. Det er en slags brukerautentiseringstjeneste. Når det gjelder navnet, settes innloggingsopplysningene én gang eller en gang. Den kan deretter brukes til å få tilgang til flere applikasjoner.

Man trenger en pålitelig tjeneste for å håndtere oppgaver som autorisasjon, autentisering, brukerregistrering, enkel pålogging, etc. Tjenesten integreres med API Gateway og alt håndteres gjennom den.

Nummer 9- Arrangementsbussen:

Hvis økosystemet har hundrevis av tjenester, må de behandles med omhu. Interservice-kommunikasjon er et must, og det er ikke rom for feil. Dataflyten skal strømlinjeformes. En hendelsesbuss refererer til en godt rettet strøm av hendelser fra en mikroservice til den andre.

Nummer 10- Databaser og stateful tjenester:

I en mikroservicebasert applikasjon er det vanligvis mange tjenester. Kravene til datalagring for alle er forskjellige, i henhold til tjenerrollene. Så noen tjenester er bra med en relasjonsdatabase, og andre trenger kanskje en NoSQL-database som MongoDB.

Docker har endret spillereglene. Database inntar det sentrale rommet av betydning i lagringsverdenen. Så hva løsningen er, den skal kunne arbeide i et Kubernetes-miljø med letthet.

Tilbake til virkeligheten, fra arkitektur til det virkelige liv

Jeg vil være ganske ærlig med deg når jeg deler mine synspunkter. Jeg tror at hele arkitekturene i fremtiden vil bli betraktet som feil. Designprinsippene, det grunnleggende osv. Alt endrer seg! Men du må være på topp av spillet. For dette integreres i det profesjonelle samfunnet. Før eller siden må du tilpasse deg disse endringene. Så hvorfor ikke begynne nå selv?

Det er mange muligheter, men bare hvis du oppdaterer deg med de nye teknologiske oppdateringene.

Nå kommer tilbake til tittelen på denne artikkelen. Docker og Kubernetes har den beste arkitekturen? For nå, absolutt "Ja". Men dette er kanskje bare den beste arkitekturen for tiden. Streber etter mer, streber etter å bygge en bedre arkitektur, bedre enn de beste!

Jeg deler noen nyttige lenker med dere alle.

Docker-artikkel: Docker-opplæring: containere, VM-er og Docker for nybegynnere

Docker Video Tutorial: Docker Video Tutorial Series

Kubernetes-artikkel: Kubernetes-bibelen for nybegynnere og utviklere

Kubernetes Video Tutorial: Kubernetes Video Tutorial Series