Bieden Docker en Kubernetes de 'beste architectuur' aan?

Hallo daar, ik ben terug met een ander artikel. Maar deze keer ben ik in de stemming om enkele mythen op te lossen.

De wereld verandert elke seconde, evenals de technologie. Wat Docker en Kubernetes betreft, moet u naar veel dingen luisteren. Vooral de vergelijking tussen hun architectuur. Veel mensen vragen zich af welke beter is?

Er zijn veel andere vragen en ik noem ze allemaal. Waarom? De enige reden is dat het u zal helpen Kubernetes en Docker te begrijpen. Hoe hebben Docker en Kubernetes de softwareontwikkeling veranderd? Biedt een van hen een sterke architectuur? Is het mogelijk om ontwikkelings- en integratieprocessen te verenigen? Zo ja, wat zijn de beperkingen? Zal dit complicaties voor ontwikkelaars verminderen?

Begrijp allereerst dat een vergelijking tussen Docker en Kubernetes niet zo eenvoudig is als u denkt. Wat is beter? Docker of Kubernetes? Ik geloof dat er "niet beter" is omdat ze allebei verschillend zijn. Docker is de bus terwijl Kubernetes de buspoort is. Dus wat is belangrijk? Beide zijn zeker belangrijk. Je hebt ze allebei nodig.

Dus in dit artikel gaan we van het echte leven naar de ontwikkelingsprocessen naar de architectuur en terug naar het echte leven.

Verder zullen we verschillende componenten en principes identificeren die deel uitmaken van de architectuur. Uiteindelijk zal de conclusie je misschien verbazen of behagen. Het hangt af van uw perceptie en ervaring met Docker en Kubernetes.

De eerste stap van real-life naar ontwikkelingsworkflows

Weet jij waarom de ontwikkelingsprocessen belangrijk zijn? Als er geen ontwikkelingsprocessen zijn, is er geen goed gerichte algemene aanpak. Een ontwikkelingsproces verkort de tijd tussen de geboorte van een idee en de levering ervan. Het vereenvoudigt het proces en behoudt de kwaliteit.

Er zijn twee soorten ideeën, de ene is goed en de andere is slecht. Er is geen derde type van een tussenliggend idee in ontwikkeling. Het idee kan goed of slecht zijn, maar het kan alleen worden gemeten door de implementatie. Als het een slecht idee is, implementeer en rol terug! Als het een goed idee is, ga je gewoon door. Het terugdraaien wordt bestuurd door een robot, d.w.z. automatisering.

Uit dit alles is een continu integratie- en leveringssysteem naar voren gekomen als een redder in nood. Het heeft dingen gemakkelijker gemaakt. Als je een idee en de code hebt, voer het dan uit! Maar er is een klein probleempje met het integratie- en bezorgsysteem. Het proces is moeilijk te formaliseren los van de technologie en bedrijfsprocessen die specifiek zijn voor uw bedrijf.

Dus hoe werd dit probleem opgelost?

Nu werd dit probleem opgelost met behulp van Docker en Kubernetes. Beiden verschenen als Messias. Het abstractieniveau en de ideologische benadering hebben bijna 80% van het probleem opgelost. Maar goed, 80% is een zeer goed percentage in de ontwikkelingssector. De 20% is er nog steeds en je moet een creatief genie zijn om het op te lossen. Het hangt af van het type toepassing en de manier waarop u het oplost.

Docker lost het probleem van de ontwikkelingsworkflow op. Docker biedt een eenvoudig proces en is voldoende voor de meeste werkomgevingen.

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

Met behulp van deze aanpak kan men alles automatiseren en verenigen.

Inleiding tot de ontwikkelomgeving

Allereerst moet het project een docker-compose.yml-bestand bevatten. Het voordeel van dit bestand is dat het de last van het uitvoeren van de applicatie / service op de lokale machine wegneemt. De ontwikkelaar hoeft er niet over na te denken. In feite is slechts een eenvoudige opdracht voor het samenstellen van een docker voldoende om uw toepassing te starten. De opdracht zorgt ook voor de afhankelijkheden, het vullen van de database met fixtures, het uploaden van de lokale code in de container, het inschakelen van codetracering en reageren op de verwachte poort.

Bovendien hoeft u zich geen zorgen te maken over het starten, doorvoeren van wijzigingen, het selecteren van een kader, enz. Alles wordt vooraf beschreven in de standaardinstructies. Het wordt bepaald door de servicesjablonen volgens de instellingen zoals frontend, backend en werknemer.

Tijd voor het geautomatiseerde testen

Heb je gehoord over de "Black Box"? Het registreert alles, zelfs de laatste seconden vóór een vliegtuigcrash. Wat is er gebeurd? Hoe is het gebeurd? Dit alles wordt verkregen uit de zwarte doos. Evenzo is hier een zwarte doos.

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

Net als de originele zwarte doos, bewaart onze container zwarte doos alles. Alle binaire gegevens, 1 of 0, enz. Worden opgeslagen in de zwarte doos. Dus hoe automatisering gebeurt er? Het is eenvoudig, u hebt een set opdrachten en de docker-compose.yml beschrijft al zijn afhankelijkheden. Dit leidt tot automatisering en uniforme testen. Het is niet nodig om u te concentreren op de implementatiedetails.

De systeemlevering

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

De locatie en het tijdstip voor het installeren van uw project doen er niet toe. Er is geen verschil welk deel van het hele ecosysteem u gaat installeren. Het resultaat van het installatieproces zal altijd hetzelfde zijn. Het ding dat het belangrijkst is, is "idempotence". Geef van uw kant de variabelen op die de installatie besturen.

Er is een algoritme voor dit alles. Laten we het stapsgewijs vermelden.

(1) Verzamel afbeeldingen van Dockerfiles.

(2) Gebruik een metaproject om de afbeeldingen te leveren. Ze moeten Kubernetes worden geleverd via Kube API. De vereiste invoerparameters zijn:

(a) Een Kube API-eindpunt

(b) Een geheim object dat varieert voor verschillende contexten (lokaal / showroom / enscenering / productie)

Systeemnamen en de tags van de Docker-afbeeldingen voor deze systemen.

Overweeg bijvoorbeeld een metaproject dat uit alle systemen en diensten bestaat. Dit betekent dat het project de indeling van het ecosysteem beschrijft en ook beschrijft hoe updates eraan worden geleverd. Hiervoor gebruik ik Ansible-playbooks voor integratie met de Kube API. Maar er zijn ook andere opties! Over het algemeen moet u in een gecentraliseerde richting denken voor het beheer van de architectuur. Zodra u er zeker van bent, kunt u de services / systemen gemakkelijk beheren.

De installatie van een omgeving is vereist in de showroom (voor handmatige controles en foutopsporing van het systeem), enscenering (voor bijna-live omgevingen en integratie) en productie (de werkelijke omgeving voor de eindgebruiker).

Continue levering en integratie

U bent een gelukkig persoon als u een uniforme manier volgt om de Docker-afbeeldingen te testen. Het zal je helpen om feature-branch naadloos te integreren in de upstream of master branches van de git repository. Het enige waar voor moet worden gezorgd, is het handhaven van de volgorde van integratie en levering. Als er geen releases zijn, hoe zou u dan de 'race condition' op één systeem met meerdere parallelle functietakken voorkomen?

Dus wat is de oplossing? Het proces zou moeten beginnen wanneer er geen concurrentie is.

De stappen:

(1) Update de functietak naar stroomopwaarts.

(2) Afbeeldingen maken.

(3) Test de ingebouwde afbeeldingen.

(4) Start en wacht tot stap 2 is voltooid en de afbeeldingen zijn afgeleverd.

(5) Als stap 4 mislukt, rolt u het ecosysteem terug naar de vorige stap.

(6) Combineer functietak stroomopwaarts. Stuur het naar de repository.

Als een van de bovenstaande stappen mislukt, wordt het leveringsproces onmiddellijk beëindigd. De taak wordt teruggestuurd naar de ontwikkelaar totdat deze niet is opgelost. Hetzelfde proces kan werken met meer dan één repository. Elk van de stappen moet op dezelfde manier worden uitgevoerd, maar voor elke repository. Bijvoorbeeld stap 1 voor repository A en stap voor repository B, enzovoort.

Kubernetes geeft u de vrijheid om updates in delen uit te rollen. Talrijke AB-tests kunnen worden uitgevoerd en risicoanalyses ondergaan. Kubernetes scheidt intern services en applicaties.

De rollback-systemen

Uit enkele van de belangrijkste mogelijkheden van een sterk architecturaal kader is er een mogelijkheid om terug te draaien. Er zijn een aantal expliciete en impliciete nuances. Laten we ze eens bekijken:

(1) De service moet zijn omgeving kunnen instellen en ook terugdraaien.

(2) Als terugdraaien niet mogelijk is, moet de service polymorf zijn. Het moet zowel de oude als de nieuwe versie van de code ondersteunen.

(3) Er moet een achterwaartse compatibiliteit zijn voor elke service na de terugdraaiing.

In het Kubernetes-cluster is het eenvoudig om statussen terug te draaien. Maar het zal alleen werken als uw metaproject informatie van deze momentopname bevat. Complexe rollback-algoritmen voor levering worden afgeraden, maar zijn noodzakelijk.

Dus onder welke omstandigheden moet het terugdraaimechanisme worden geactiveerd?

(1) Wanneer het percentage toepassingsfouten hoog is na de release.

(2) Zodra u signalen van belangrijke controlepunten begint te ontvangen.

(3) Wanneer rookproeven mislukken.

(4) Het kan handmatig worden gedaan.

Veiligheids maatregelen

Het ecosysteem kogelvrij maken is niet eenvoudig. Het kan niet door slechts één workflow te volgen. Het architecturale kader moet veilig genoeg zijn om problemen aan te pakken. Kubernetes wordt geleverd met een aantal goede ingebouwde mechanismen voor toegangscontrole, netwerkbeleid, de audit van evenementen, enz. Er zijn enkele hulpmiddelen voor de informatiebeveiliging en ze zijn uitstekend gebleken in termen van bescherming.

De volgende stap, van ontwikkelingsworkflows tot de architectuur

Een architecturaal kader dat flexibiliteit, schaalbaarheid, beschikbaarheid, betrouwbaarheid, bescherming tegen bedreigingen, enz. Biedt, is bijna verplicht. Dit is cruciaal. In feite leidde deze behoefte tot een nieuw concept. Durft iemand een poging te wagen? Ja, DevOps. Het leidde tot het complete concept van automatisering en optimalisatie-infrastructuur.

Nu was het tijd om de architectuur te veranderen van Monolithisch naar Microservices. Het biedt enorme voordelen van een servicegeoriënteerde architectuur. Tenminste voor Docker en Kubernetes is het ideologisch verkeerd om een ​​monolithische architectuur te gebruiken. Ik zal zeker enkele punten van de microservices-architectuur bespreken. Lees dit artikel over DevOps voor uitgebreide kennis over DevOps.

Nu zullen we snel de belangrijkste kritieke componenten en de oplossingen van een goede architectuur bespreken.

De kritische componenten

Nummer 1- Identiteitsservice:

Identiteit microservice verwijst naar de "identiteit als een microservice". De services zijn licht van gewicht. Het biedt modulariteit en maakt de toepassing flexibel. De identiteitsmicroservice is krachtig en heeft toegang tot alle profielgegevens. Het is in staat om alles te bieden dat nodig is in de kern van alle applicaties.

Als u de klant wilt zijn van grote zakelijke platforms zoals IBM, Google, Microsoft, enz., Wordt de toegang geregeld door de services van de leverancier. Maar wat als u uw eigen oplossing wilt? De lijst in de komende sectie zal u helpen om het te beslissen.

Nummer 2- De geautomatiseerde dienstverlening:

De gebouwde services zijn onafhankelijk van elkaar. Dit leidt tot eenvoudige ontwikkeling en minder fouten. Het helpt ook bij het zoeken naar andere services in een dynamisch en geautomatiseerd patroon.

Kubernetes vermindert de behoefte aan extra componenten. Maar toch moet men de toevoeging van nieuwe machines automatiseren. Hier is een lijst met tools:

(1) KOPS - Helpt u bij het installeren van een cluster op AWS of GCE.

(2) Teraform - Helpt u bij het beheren van de infrastructuur voor elke omgeving.

(3) Ansible - Biedt automatisering van welke aard dan ook.

Persoonlijk raad ik Ansible aan, omdat het je helpt met zowel servers als Kubernetes-objecten te werken.

Nummer 3- Git repository en taken volgen:

Met Git-opslagplaatsen kunnen de taken gemakkelijk worden uitgevoerd. Het basisidee is om een ​​kleine repository te hebben. Het dient als omgevingstracker. De inhoud bevat welk type versies moet worden gebruikt voor verschillende services. Het voorkeursbronbesturingssysteem hiervoor is "git".

Er moet een goede werkplek zijn voor teamwerk en code-opslag voor alle belangrijke discussies. Als je een gratis service wilt, kies dan voor Redmine. Anders is Jira een betaalde dienst en is behoorlijk nuttig. Voor de coderepository is Gerrit een geweldige gratis keuze!

Nummer 4- Het Docker-register:

Het docker-register is een type opslag- en inhoudafleveringssysteem. Het bevat de naam van Docker-afbeeldingen en is beschikbaar in verschillende getagde versies. Voor interactie met een register moet de gebruiker push- en pull-opdrachten activeren.

Het beeldbeheersysteem van de docker is behoorlijk belangrijk. Het systeem moet ook toegang voor gebruikers en een groep gebruikers ondersteunen. Kies hiervoor een cloudoplossing of een particuliere gehoste service. Een goede optie is Vmware Harbor.

Nummer 5- CI / CD en servicelevering:

Alleen een continue integratie en bezorgservice verbindt de eerder besproken componenten. Continue levering verwijst naar een eenvoudige service zonder enige logica. De CI / CD-service moet alleen reageren op gebeurtenissen in de buitenwereld zoals veranderingen in de git-repository, enz.

De integratieservice is verantwoordelijk voor automatische servicetests, servicelevering, terugdraaien, serviceverwijdering en het opbouwen van afbeeldingen.

Nummer 6 - Verzameling en analyse van logboeken:

In elke microservice-toepassing is het volgen van het probleem belangrijk. Volgen is mogelijk met behulp van logboekregistratie. Dus loggen en monitoren geven u een holistisch beeld van het systeem.

Logboeken worden toegankelijk gemaakt door ze naar STDOUT of STDERR van het rootproces te schrijven. De logboekgegevens moeten beschikbaar zijn wanneer dat nodig is. Het moet ook records uit het verleden bevatten.

Nummer 7 - Tracing, Monitoring en Alert:

Tools zoals Opentracing en Zipkin helpen je de fout te begrijpen. Zoals waar ben je fout gegaan? Deze tools helpen u dergelijke vragen te beantwoorden. Mislukkingen gebeuren en het traceren ervan is belangrijk.

Verder is monitoring onderverdeeld in drie niveaus. Dit zijn het fysieke niveau, clusterniveau en serviceniveau. Er is geen ruimte voor fouten in de monitoring. Tools zoals Prometheus en OpsGenie zijn zeer nuttig gebleken voor monitoring. OpsGenie waarschuwt en waarschuwt ook voor problemen op alle niveaus. Dus tracing, monitoring en waarschuwingen mogen nooit lichtvaardig worden opgevat. Ze vormen het defensieve deel van de applicatie.

Nummer 8- API-gateway met eenmalige aanmelding:

In microservices zouden alle oproepen alleen via de API Gateway moeten gaan. Het helpt de beveiliging te handhaven. Het is ook verantwoordelijk voor het routeren van de API-aanvragen. Dus de API Gateway is een toegangspunt voor al zijn respectieve microservices. Eenmalige aanmelding verwijst naar een sessie. Het is een soort gebruikersauthenticatieservice. Volgens de naam worden de inloggegevens een of een keer ingesteld. Het kan vervolgens worden gebruikt voor toegang tot meerdere applicaties.

Men heeft een betrouwbare service nodig voor het afhandelen van taken zoals autorisatie, authenticatie, gebruikersregistratie, eenmalige aanmelding, enz. De service integreert met de API Gateway en alles wordt ermee afgehandeld.

Nummer 9- De evenementenbus:

Als het ecosysteem honderden services heeft, moeten deze met zorg worden behandeld. Interservice-communicatie is een must en er is geen ruimte voor fouten. De gegevensstroom moet gestroomlijnd zijn. Een evenementenbus verwijst naar een goed gerichte stroom evenementen van de ene microservice naar de andere.

Nummer 10- Databases en stateful services:

In een op microservices gebaseerde applicatie zijn er meestal talloze services. De vereisten voor gegevensopslag voor iedereen zijn anders, volgens de servicerollen. Dus sommige services zijn goed met een relationele database en anderen hebben misschien een NoSQL-database nodig, zoals MongoDB.

Docker heeft de spelregels gewijzigd. Database neemt de centrale ruimte van belang in de opslagwereld in. Wat de oplossing ook is, deze moet gemakkelijk in een Kubernetes-omgeving kunnen werken.

Terug naar de realiteit, van architectuur tot het echte leven

Ik zal heel eerlijk met je zijn als ik mijn mening deel. Ik geloof dat in de toekomst alle architecturen als mislukkingen worden beschouwd. De ontwerpprincipes, de fundamenten, enz. Alles verandert! Maar je moet wel op de hoogte blijven. Hiervoor integreren in de professionele gemeenschap. Vroeg of laat zult u zich aan deze veranderingen moeten aanpassen. Waarom dan niet nu zelf beginnen?

Er zijn veel mogelijkheden, maar alleen als je jezelf bijwerkt met de nieuwe technologische updates.

Nu terugkomend op de titel van dit artikel. Docker en Kubernetes hebben de beste architectuur? Voor nu zeker "Ja". Maar dit is misschien voorlopig alleen de beste architectuur. Streven naar meer, streven naar het bouwen van een betere architectuur, beter dan de beste!

Ik deel een paar nuttige links met jullie allemaal.

Docker-artikel: Docker-zelfstudie: containers, VM's en Docker voor beginners

Docker Video Tutorial: Docker Video Tutorial Series

Kubernetes-artikel: De Kubernetes-Bijbel voor beginners en ontwikkelaars

Kubernetes Video Tutorial: Kubernetes Video Tutorial Series