‫Een van de grote beloften van containers is dat we onze apps gemakkelijk kunnen inzetten alsof we een platformdienst zijn, je weet
‫wel, zoals Heroku of zoiets. We kunnen dat op ieders hardware doen, of het nu op onze
‫hardware is, of het een cloudprovider is, of het nu virtueel of fysiek is. Met Docker kunnen onze apps hetzelfde draaien, of ze
‫nu een Amazon, Azure, DigitalOcean, Linode, Rackspace, Google Cloud of wat dan ook zijn. Hoe kunnen we zonder al die platformfuncties
‫eenvoudig onze tientallen, honderden of zelfs duizenden containers implementeren en onderhouden op
‫vele servers of instanties? Of knopen of druppels of wat dan ook.
‫Dat brengt een aantal echt nieuwe problemen met zich mee die voorheen geen problemen waren voor kleine organisaties.
‫We kennen allemaal Netflix en zulke grote organisaties die schalen naar duizenden en duizenden knooppunten,
‫en tienduizenden knooppunten, en ze hebben veel technici.
‫Maar als je maar een paar mensen in je team hebt, of als je gewoon een solo-ontwikkelaar bent, hoe pak je dan je
‫containers en schaal ze en ga je om met hun hele levenscyclus? Van ze implementeren, starten,
‫opnieuw opstarten, opnieuw maken, verwijderen en bijwerken en zo.
‫We beginnen vragen te stellen over hoe Docker dat precies doet of zelfs helemaal niet?
‫Sommige van de vragen die we onszelf stellen, zijn dingen als: hoe kunnen we uitschalen? Hoe schalen we op? Hoe zorgen we ervoor
‫dat onze containers opnieuw opstarten als ze defect raken?
‫Hoe vervangen we die containers als we er daadwerkelijk een update voor hebben? Dat heet tegenwoordig blue green deploy,
‫wat betekent dat je geen downtime hebt en servers uit de pool haalt
‫om nieuwe binnen te halen. Je hebt altijd iets beschikbaar, zodat
‫je nooit echt down bent als je update. Hoe weten we of we tientallen knooppunten hebben of zelfs maar drie
‫knooppunten waar we die containers zijn begonnen? Op welk knooppunt staat onze container? Hoe praten we over
‫die verschillende knooppunten of servers met ons netwerk in de containers?
‫Als het om beveiliging gaat, hoe weten we dan zeker dat onze containers alleen draaien op
‫de machines waarvoor we ze bedoelden?
‫Hoe slaan we de privé-informatie op die we nodig hebben voor onze containers, zoals geheimen
‫of wachtwoorden, nu we dingen verplaatsen en ze dynamisch en on-the-fly inzetten?
‫Dit brengt ons dus bij een belangrijke evolutie in de reikwijdte van wat Docker probeert op te lossen.
‫Als mensen met me praten en ze denken dat Docker slechts een container-runtime is, dan
‫noem ik eigenlijk alleen Swarm Mode, een gloednieuwe functie in 2016 die jarenlange kennis van de behoeften van containers samenbrengt
‫en hoe ze daadwerkelijk live kunnen worden uitgevoerd in de maak.
‫Dus in de kern is Swarm eigenlijk een serverclusteroplossing die verschillende besturingssystemen of hosts, of
‫knooppunten, of hoe
‫je ze ook wilt noemen, samenbrengt in een enkele beheersbare eenheid waarin je vervolgens de levenscyclus
‫van je containers kunt orkestreren. Voor alle duidelijkheid, we hebben het niet echt over Swarm,
‫dat ik Swarm Classic ga noemen, wat een add-on-component was voor Docker vóór 1. 12 kwam uit. Het was echt een container die in
‫Docker zou draaien, die
‫eigenlijk gewoon je Docker-run-opdrachten nam en ze naar meerdere servers herhaalde.
‫Het loste wel een paar problemen op, maar het was niet echt op de schaal die we nodig hadden om 80% van de gevallen echt op
‫te lossen voor hoe je je containers gaat gebruiken.
‫In de zomer
‫van 2016, tijdens dockercon 2016, kondigde Docker eigenlijk Swarm Kit aan, een set bibliotheken of een toolkit die betrekking had
‫op een hele reeks nieuwe Swarm-functies.
‫Toen stopten ze dat recht in de Docker-server. Al die tijd in deze cursus had u de functies
‫die voor u beschikbaar waren in de CLI en op uw server.
‫Nu kunnen we er eindelijk in duiken.
‫In januari 2017, 1. 13 kwam uit, en natuurlijk omdat Swarm
‫Mode nieuw was in 2016, zullen ze het de komende jaren blijven verbeteren.
‫In januari hebben ze extra functies toegevoegd, genaamd Stacks and Secrets, evenals andere bonussen waar
‫we het later over zullen hebben. Het is belangrijk op te merken dat Swarm niet standaard is ingeschakeld.
‫In feite zou u op uw computer deze commando's die hier op dit moment worden vermeld, niet kunnen gebruiken. Dat zou je eigenlijk een
‫foutmelding geven omdat Swarm moet worden ingeschakeld.
‫Dat was een van de ontwerpdoelen, dat geen van de Swarm-code de bestaande
‫Docker-daemon zou beïnvloeden, en dat alle tools en systemen die al op Docker vertrouwden, of
‫misschien hadden ze hun eigen orkestratie bovenop Docker, zouden blijven functioneren en niet worden gestoord
‫door
‫Swarm dat nu deel uitmaakt van Docker. Enkele echt basisconcepten voordat we erin gaan duiken, is dat
‫deze blauwe vakken die je bovenaan ziet, zijn wat we Manager Nodes noemen, en ze hebben een
‫lokale database die bekend staat als de Raft Database.
‫Het slaat hun configuratie op en geeft ze alle informatie die ze nodig hebben om de autoriteit binnen
‫een zwerm te zijn.
‫Dus wat we hier hebben, zijn drie verschillende managers die allemaal aan de zwerm zijn
‫toegevoegd, en ze houden allemaal een kopie van die database bij en versleutelen hun verkeer om de integriteit te waarborgen en het
‫vertrouwen te garanderen dat ze deze zwerm veilig kunnen beheren .
‫Hieronder in het groen hebben we feitelijk werknota's. Nu zie je in het concept van Swarm,
‫we hebben nu managers en arbeiders.
‫Elk van deze zou een virtuele machine zijn, of een fysieke host, waarop een distributie van een
‫Linux- of Windows-server draait.
‫Dit laat zien hoe ze eigenlijk allemaal communiceren over wat we het controlevlak noemen, dat is
‫hoe orders rond de zwerm worden gestuurd, deelnemend aan acties. In een iets gecompliceerdere weergave hebben we
‫deze Raft-consensusdatabase die ik noemde, die opnieuw wordt gerepliceerd tussen alle knooppunten.
‫Ze geven orders aan de arbeiders.
‫De managers zelf kunnen ook arbeiders zijn. Natuurlijk kunt u werknemers en managers degraderen en
‫promoveren in de twee verschillende rollen.
‫Als u aan een manager denkt, denkt u meestal aan een werknemer met machtigingen om de zwerm te besturen.
‫Nogmaals, de enige vereisten voor elk van deze servers is dat ze
‫dezelfde Docker gebruiken die u nu al gebruikt. Met dit concept van een zwerm, en deze managers, hebben we nu nieuwe concepten
‫van hoe onze containers eruit zien.
‫Dus met de Docker run-opdracht konden we maar één container echt implementeren.
‫Het zou gewoon een container maken.
‫Het was altijd op welke machine de Docker CLI ook sprak.
‫Dat is meestal uw lokale machine, of misschien een server waarop ze zijn ingelogd. Dat Docker-run-commando had geen concepten
‫over hoe uit te schalen of op te schalen.
‫We hadden dus nieuwe commando's nodig om daarmee om te gaan.
‫Dat is waar het Docker-servicecommando vandaan komt. In een zwerm vervangt het de
‫Docker run-opdracht en stelt het ons in staat om extra functies aan onze container toe te voegen wanneer we
‫het uitvoeren, zoals replica's om ons te vertellen hoeveel daarvan het wil uitvoeren.
‫Dat worden taken genoemd.
‫Een enkele service kan meerdere taken hebben en elk van die taken zal een container starten.
‫In dit voorbeeld hebben we een service gemaakt met behulp van docker-service create om een Nginx-service te starten met behulp van de
‫Nginx-afbeelding, zoals we al verschillende keren eerder hebben gedaan.
‫Maar we hebben gezegd dat we drie replica's willen.
‫Het zal dus de managerknooppunten gebruiken om te beslissen waar in de zwerm deze worden geplaatst. Standaard probeert het ze te
‫verspreiden.
‫Elk knooppunt zou zijn eigen exemplaar van de Nginx-container krijgen tot aan de drie replica's waarvan we zeiden dat
‫we ze nodig hadden.
‫Dit is een snel en basaal begrip van hoe de managers werken en wat ze op de achtergrond doen.
‫Al deze functies zijn nieuw.
‫Het is niet gewoon je commando nemen en het uitvoeren op een API zoals we zouden ervaren met
‫een Docker run-commando.
‫Er is hier eigenlijk een geheel nieuwe Swarm-API met een heleboel achtergrondservices, zoals de planner en de dispatcher, en de allocator
‫en orchestrator, die helpen bij het nemen van beslissingen over wat de werknemers op een
‫bepaald moment zouden moeten uitvoeren.
‫Dus de arbeiders melden zich constant bij de managers en vragen om nieuw werk.
‫De managers doen voortdurend nieuw werk en evalueren wat u hen hebt opgedragen te doen tegen wat
‫ze feitelijk doen.
‫Als er dan een verzoening plaatsvindt, zullen ze die wijzigingen aanbrengen, zoals misschien heb je het
‫verteld om nog drie replicataken in die service te starten.
‫Dus de orkestrator zal dat beseffen en vervolgens bevelen geven aan de arbeiders, enzovoort.
‫Met deze zwermmodus krijgen we een reeks functies boordevol functies uit de doos waarmee we de bestaande Docker-vaardigheden die we hebben al kunnen
‫gebruiken om onze containers op een betrouwbare manier op internet te zetten en veel problemen op
‫te lossen. problemen die we zouden hebben als we eenmaal
‫gaan produceren.