‫Oke.
‫Waar u uw Docker ook uitvoert, we kunnen een enkele node-zwerm creëren voor onze eigen
‫testdoeleinden.
‫De manier waarop ik kan zien of Swarm is ingeschakeld of niet, ik kan gewoon een docker-info doen en je zult zien dat Swarm
‫inactief is.
‫We weten dus dat Swarm hier niet is ingeschakeld. Nogmaals, Docker schakelt standaard geen van
‫de Swarm-functies in.
‫Ik kan een docker swarm init uitvoeren om te initialiseren. Dat duurde ongeveer een halve seconde en we zijn klaar.
‫Wat we nu hebben, is een zwerm met één knooppunt met alle functies en functionaliteit die we uit de
‫doos halen.
‫Dus dat was waarschijnlijk de kortste demo van deze hele cursus.
‫Ik bedoel, wat is er net gebeurd? We typten een commando en magie. Was eigenlijk geen magie.
‫Het was een heleboel zeer snelle en efficiënte dingen in de Go-programmering van Docker, maar in wezen, direct uit
‫de
‫doos, doet het een heleboel PKI- en beveiligingsdingen. Het maakt een basiscertificaat voor de zwerm dat het zal gebruiken
‫om vertrouwen te vestigen en certificaten te ondertekenen voor alle knooppunten en alle managers. Er wordt een speciaal certificaat gemaakt
‫voor dit eerste managerknooppunt omdat het een manager versus een werknemer is.
‫Vervolgens maakt het deze tokens die we daadwerkelijk op andere knooppunten kunnen gebruiken om lid te worden van deze zwerm.
‫Dan een heleboel andere dingen op de achtergrond waar het de swarm API activeert en iets creëert dat de Raft
‫Consensus Database wordt genoemd, waar we het later in een productiedeel van de cursus over zullen hebben.
‫Voor de duidelijkheid: Raft is een protocol dat zorgt voor consistentie over meerdere knooppunten, en het is ideaal voor
‫gebruik in de cloud, waar we niet kunnen garanderen dat iets op elk moment beschikbaar
‫zal zijn.
‫Het creëert die database op schijf. Het slaat de configuratie van de zwerm
‫op, en die eerste manager, en versleutelt het feitelijk.
‫Ervan uitgaande dat je op versie 1 zit. 13 of nieuwer. Vervolgens wacht het op andere knooppunten voordat
‫het de database daadwerkelijk naar hen gaat repliceren.
‫Nogmaals, al dit verkeer dat het zou doen zodra we andere knooppunten hebben gemaakt, wordt allemaal versleuteld.
‫Een van de belangrijkste componenten van Swarm die het onderscheidde toen het voor
‫het eerst uitkwam, was dat we geen extra opslagsysteem met sleutelwaarden of een database-architectuur nodig hadden om het backend-configuratiebeheer
‫van onze zwerm te zijn.
‫Als je al jaren of decennia in de branche actief bent, is er typisch dit concept
‫van de config db, dit is dit afzonderlijke databasesysteem dat je meestal overbodig moet maken en dat alle
‫informatie over je orkestratie- en automatiseringssysteem zal opslaan. Swarm heeft dat rechtstreeks in Docker
‫ingebouwd, rechtstreeks in de daemon en handelt het voor ons af.
‫We hoeven eigenlijk nooit iets te doen. U hoeft zich geen zorgen te maken over wachtwoorden. Er zijn geen speciale diensten
‫om op te starten of iets dergelijks.
‫Dus terug naar de opdrachtregel.
‫Je zult hier merken dat het gaat over... als ik een werker aan de zwerm
‫wil toevoegen, moet ik dit echt knippen en plakken op de andere servers die ik zou toevoegen.
‫Later gaan we een zwerm met meerdere knooppunten bouwen, maar voorlopig houden we
‫dit bij een enkel knooppunt. Laten we eens kijken naar een paar van de commando's die eruit zullen komen.
‫Het eerste is dat we docker node ls kunnen doen. In dit geval zien we alleen het ene managerknooppunt dat we
‫hebben gemaakt.
‫U zult merken dat het is gemarkeerd als leider en dat er slechts één leider tegelijk kan zijn onder alle managers.
‫Nogmaals, aangezien we er maar één hebben, is het duidelijk de leider. We kunnen kijken naar help om
‫te zien welke andere opties we hier hebben. Echt, de nodes-commando's die worden gebruikt om uw servers in en
‫uit de zwerm te brengen, of ze te promoten van werknemers tot managers, of ze te degraderen van managers terug naar werknemers.
‫Als je even teruggaat naar het commando Dockers Swarm, zullen we merken dat het eigenlijk een heel smal bereik is om
‫te bevelen.
‫Het is echt gewoon om te initialiseren, ofwel toetreden of vertrekken.
‫Het nieuwe ontgrendelingscommando, waar we het in een latere lezing over kunnen hebben.
‫Laten we ons voorlopig concentreren op het opwindende nieuwe Docker-servicecommando.
‫Nogmaals, service in een zwerm vervangt de Docker-run.
‫Ik weet het niet zeker, maar ik denk echt dat dit was gecentreerd rond
‫het idee dat we de bestaande Docker-run-functionaliteit niet wilden breken, maar Docker-run is altijd vanaf de grond opgebouwd
‫als een enkele host-oplossing.
‫Het hele idee was om zich te concentreren op lokale containers op het systeem waarmee het praat. Terwijl, als we het over
‫een cluster hebben, we niet zoveel om individuele knooppunten geven.
‫We noemen ze waarschijnlijk niet echt. We behandelen ze als vee, als je ooit hebt
‫gehoord van de analogie van huisdieren versus vee, waar ze slechts een nummer zijn.
‫We gaan niet echt individueel naar elk knooppunt en starten een individuele container op.
‫We gooien gewoon vereisten naar de zwerm in de vorm van services en dan zal het orkestreren hoe het dat allemaal
‫moet opstellen, op welke knooppunten ze moeten zijn, en we weten
‫gewoon dat het onze rug heeft. docker service create is hoe
‫we het een aantal nieuwe orders geven. Laten we iets heel eenvoudigs doen.
‫Laten we het gewoon laten beginnen met het Alpine-beeld. Dan hebben we de Alpine-afbeelding gewoon ping gebruiken om
‫8 te raken. 8. 8. 8, wat eigenlijk een Google DNS-server is, maar we willen
‫hem gewoon iets te doen geven terwijl we onderzoeken wat er gebeurt.
‫Dan zul je zien dat Docker Run een ID terugspuugt, alleen dat is niet de container-ID. Dat is eigenlijk de
‫service-ID.
‫U zult zien dat we nu één service hebben vermeld. Net als bij ons docker run-commando, omdat we het
‫geen naam
‫hebben gegeven, heeft het een willekeurige naam gegeven. We kunnen zien dat het eigenlijk al is opgedraaid.
‫Die van één. Als je naar diensten kijkt, zie je dit nummer
‫altijd met een / in het midden. Dat vertegenwoordigt de ene aan de linkerkant is hoeveel er daadwerkelijk lopen.
‫En die aan de rechterkant is hoeveel je hebt opgegeven om het uit te voeren.
‫Het doel van de orkestrator is om deze nummers overeen te laten komen, wat daar ook voor nodig is.
‫Maar dit toont ons niet echt de echte container.
‫Dit toont ons eigenlijk alleen maar een lijst van onze services, zodat we wat verder kunnen inzoomen.
‫We doen een docker-service ps, en dan geven we het de naam of de ID van de service, en dat zal ons
‫de taken of containers voor deze service laten zien. Je zult zien dat het lijkt op de opdracht docker container
‫ls, maar het heeft nu deze knooppuntcomponent, want als je te maken hebt met scenario's met meerdere servers, moeten
‫we misschien weten op welke server het daadwerkelijk draait. U zult merken dat het het
‫een naam heeft gegeven van een increment op de servicenaam.
‫Als we teruggaan naar de opdracht docker container ls, werkt dat nog steeds.
‫In dit geval voegt de orkestratie van Swarm eigenlijk wat informatie toe aan de namen en aan de
‫daadwerkelijke afbeeldingen die worden uitgevoerd. We zullen later ook enkele van die subtiele verschillen bespreken.
‫Laten we voor nu die service nemen en opschalen. Daarvoor gebruiken we de docker-service-update en vervolgens de naam van
‫onze service, of de ID in dit geval, ik doe de ID. En ik wil een attribuut over de
‫service wijzigen.
‫In dit geval wil ik het aantal replica's wijzigen.
‫Dus als we weer een docker-service ls doen, zien we nu drie van de drie. Als we een docker-service ps doen, zien we
‫nu eigenlijk drie taken. U zult merken dat er twee seconden geleden zijn gemaakt.
‫Als we snel genoeg waren, en als we iets zouden inzetten dat groot genoeg was, zouden we de service ls kunnen uitvoeren en zien
‫dat het ons nul van drie laat zien. Een uit drie.
‫Het zal zelfs toenemen als de dingen opstarten. Toevallig zat Alpine al op deze machine, qua
‫imago, en het duurde niet lang om een ping-commando te starten.
‫We konden gewoon niet zo snel zijn.
‫Wat interessant is aan dat update-commando is dat je je het verschil kunt voorstellen tussen het
‫Docker run-commando dat je zou kunnen gebruiken op een enkele dev- of testserver of op je lokale
‫machine, en de productieproblemen om altijd iets zo veel mogelijk
‫beschikbaar te houden.
‫Dat is een van de ontwerpdoelen van Swarm. Die opdracht die we eigenlijk nog
‫niet hebben gebruikt, is de opdracht Docker-update. Dat was een opdracht voor de Docker-runcontainers waarmee we bepaalde
‫variabelen op onze actieve container konden bijwerken zonder deze te hoeven doden en opnieuw te starten.
‫Bijna al deze opties hebben betrekking op het beperken en controleren van het resourcegebruik voor die container.
‫Omdat dat een van de typische dingen is die je ziet als je een langetermijntoepassing
‫draait, is dat je de bronnen ervan moet veranderen, misschien omdat de databases groter zijn geworden en meer RAM nodig hebben.
‫Of misschien heb je een uit de hand gelopen proces dat teveel CPU opslokt en moet je het beperken.
‫Als we hulp bieden bij de opdracht docker-service-update, zul je zien dat we veel meer opties hebben.
‫Omdat het doel van een Swarm-service is dat het containers kan vervangen en wijzigingen in de service kan bijwerken zonder
‫het hele ding uit de lucht te halen.
‫Als je een service had met drie containers erin, zou je technisch gezien één voor één kunnen verwijderen om een wijziging aan te brengen en een soort van rollende update uit
‫te voeren, wat het blauwgroene patroon is waar we het over hadden. Daarom zien we hier veel meer opties, omdat
‫we deze opties kunnen wijzigen waarvoor mogelijk een herstart van de container nodig is, maar de
‫zwerm zal er intelligent voor zorgen dat de manier waarop we ze bijwerken in een patroon is
‫dat zorgt voor consistente beschikbaarheid.
‫Dus snel terug naar onze docker-containerlijst. Je zult merken dat we deze drie nu hebben,
‫en wat als ik naar binnen ging en, een beetje als een schurk, een havencontainer rm deed, en ik specificeerde een van
‫deze containers, en ik dwong het... laten we zeggen dat ik de eerste heb verslagen en hem eruit haal.
‫Oke.
‫Nu doe ik een havendienst ls, en zie je hoe het twee van drie laat zien?
‫Omdat ik achter de rug van Swarm naar binnen ging en ik een lopende container heb weggenomen,
‫zal het dat identificeren en binnen enkele seconden een nieuwe lanceren om degene te vervangen die naar
‫beneden ging.
‫Dus als ik een docker-service ps op frosty heb gedaan, zul je zien dat het de geschiedenis van de eerste taak hier in de lijst
‫laat zien, dat er een was die mislukte en 24 seconden geleden een nieuwe begon.
‫Dit is een van de verantwoordelijkheden van een containerorkestratiesysteem om ervoor te zorgen dat de services die u
‫hebt opgegeven altijd worden uitgevoerd, en als ze falen,
‫wordt het hersteld van die fout. Wat is heel anders dan Docker Run, toch? docker run zou
‫nooit een container opnieuw maken.
‫Dus dat is de reden waarom wanneer we een van deze Docker-serviceopdrachten uitvoeren, we niet rechtstreeks praten
‫met een actie zoals het maken van een container.
‫We vertellen eigenlijk een orkestratiesysteem, zet deze taak in je wachtrij.
‫Als je er bij kunt komen, voer dan de acties uit op de zwerm die ik hier heb gevraagd. Dat is een groot
‫verschil.
‫Het is subtiel in de opdrachtregel, maar het is een groot verschil omdat het betekent dat er terugdraaimogelijkheden zijn.
‫Er is faalbeperking en veel intelligentie ingebouwd.
‫Als ik in dit geval al deze containers zou willen
‫verwijderen, zou ik de service moeten verwijderen. Ik zou Docker Service rm moeten doen.
‫En dan de ijzige.
‫Als we een docker-service ls doen, zien we niets. Als we een
‫dockercontainer ls doen, zien we drie containers.
‫Oh en daar gaan we.
‫Dat laat precies zien hoe de automatisering in de backend plaatsvindt.
‫We konden snel laten zien dat we de service hadden verwijderd, maar het orkestratiesysteem had niet alle processen
‫voor het opschonen van de service en de taak erachter doorlopen. Deze concepten zouden vrij eenvoudig te begrijpen moeten zijn, omdat
‫ze gewoon een uitbreiding zijn van de Docker-runconcepten die we eerder in deze cursus
‫hebben gehad.
‫Laten we vervolgens een zwerm met meerdere knooppunten bouwen en onze containers gaan uitschalen.