‫Service-updates. Je hebt waarschijnlijk altijd aangenomen dat er een manier is om je services bij te werken,
‫ook al hebben we ons daar nog niet op gefocust.
‫Laten we erover praten, want updates hebben een heleboel dingen onder de dekens. De updatefunctionaliteit van Swarm is gecentreerd rond
‫een rollend updatepatroon voor je replica's. Wat betekent dat als je een service hebt met meer
‫dan één replica, en hopelijk heb je dat, het er standaard één voor één doorheen gaat en
‫elke container bijwerkt door deze te vervangen door de nieuwe instellingen die je in de update
‫plaatst opdracht.
‫Veel mensen zullen zeggen dat orchestrators downtime in updates voorkomen, maar ik ga niet zeggen
‫dat dit downtime voorkomt.
‫Ik ga zeggen dat het de downtime beperkt. Omdat het voorkomen van downtime in elk systeem de taak is van testen.
‫U moet echt gaan testen hoe u uw updates uitvoert en bepalen, heeft dit invloed op mijn gebruikers?
‫Heeft het updaten van een database invloed op mijn webapplicatie? Waarschijnlijk wel.
‫Elke toepassing waarvoor u een service heeft, wordt geüpdatet en heeft een andere invloed op de andere
‫dingen eromheen.
‫Dat is niet de taak van een orkestrator.
‫Een orkestrator kan niet bepalen dat dit een databaseprotocol is, en dit is een eenvoudig
‫REST-toepassingsprotocol.
‫Dat worden dus verschillende, gecompliceerde dingen waar je mee om moet gaan.
‫In het geval van service-updates, als het gewoon een REST API is of een webfrontend die niets bijzonders doet,
‫zoals websockets of lange polling, als het iets heel eenvoudigs is zoals dat of een statische website, heb
‫je waarschijnlijk een gemakkelijke update en het zal geen probleem zijn.
‫Maar andere services zoals databases of permanente opslag of iets dat een permanente verbinding vereist...
‫die zullen altijd een uitdaging zijn, wat je ook probeert te updaten.
‫Dus test vroeg en test vaak.
‫Zoals ik al eerder zei, zal dit zeker containers in de meeste updates vervangen. Tenzij u een label of
‫een andere metadata bijwerkt met de service, zal
‫deze doorrollen en elke container vervangen door een geheel nieuwe.
‫Wees daar maar op voorbereid. Het heeft veel opties. In feite, de laatste
‫die ik telde, waren er minstens 77 opties voor het update-commando. Maar zo ongeveer alles wat u wilt
‫doen, kan worden aangepast.
‫Veel van de opties in het update-commando zijn eigenlijk creatie-opties die alleen een -rm
‫en een -add aan het einde hebben. Want als het een optie is die voor meerdere waarden kan
‫worden gebruikt, laten we zeggen een port om te publiceren of een omgevingsvariabele, dan kun je er veel van gebruiken.
‫Rechts?
‫U moet dus het update-commando kunnen vertellen welke u toevoegt en welke u verwijdert.
‫Die zullen we zo zien.
‫Dit omvat ook opties voor terugdraaien en gezondheidscontrole.
‫U moet de opties hiervoor bekijken en zien of hun standaardwaarden niet ideaal zijn voor uw toepassing en verschillende
‫instellingen testen om te zien of het een update gemakkelijker maakt voor u en uw systeem.
‫Je zult ook zien dat we hier schaal- en terugdraaiopties hebben die nu hun eigen commando's zijn.
‫Vroeger waren het opties die je moest specificeren met de --rollback of --scale, maar zoveel mensen
‫hebben die zo vaak gebruikt dat Docker ze nu een soort eersteklas burgers maakt in
‫de commandoregel.
‫In de toekomst zullen ze er misschien meer van toevoegen.
‫Ten slotte, voordat we naar enkele voorbeelden gaan, als je stapels doet, is een stapel die naar dezelfde stapel wordt geïmplementeerd
‫een update.
‫In feite is er geen aparte optie voor stack-updates.
‫U voert gewoon een stack-implementatie uit met hetzelfde bestand dat is bewerkt.
‫Vervolgens werkt het met de serviceopdrachten en de netwerken, en al het andere dat het doet. Het zal met hen
‫samenwerken om ervoor te zorgen dat eventuele wijzigingen worden toegepast.
‫Laten we enkele snelle voorbeelden bekijken en dan komen we bij de opdrachtregel.
‫Dit is waarschijnlijk het meest voorkomende voorbeeld dat u zult gebruiken, namelijk het wijzigen van het imago van
‫een service.
‫Elke keer dat u uw app bijwerkt en een nieuwe afbeelding maakt, moet
‫u een service-updateopdracht uitvoeren, met de afbeeldingsnaam en vervolgens de servicenaam.
‫Dus in dit geval had ik misschien mijn aanvraag met een tag van 1. 2. 0.
‫En in dit geval pas ik nu een 1 toe. 2. 1 afbeelding, en de service
‫zal bepalen, ah ja, dat is een andere afbeelding dan
‫ik in mijn service heb, en we zullen ze gaan bijwerken. In deze volgende laten we zien hoe je meerdere dingen tegelijk kunt
‫doen binnen een enkele update-opdracht.
‫U kunt een omgevingsvariabele toevoegen met de env-add, en vervolgens kunt u een poort verwijderen met
‫de publish -rm.
‫We kunnen ook omgevingsvariabelen toevoegen en verwijderen en poorten publiceren in
‫hetzelfde update-commando zoveel we willen. Bij deze laatste laat dit zien hoe we deze
‫nieuwe schaal- en terugdraaiopdrachten op meerdere services tegelijkertijd kunnen gebruiken. Wat een van de voordelen is van het gebruik
‫ervan ten opzichte van de update-opdracht, is dat ze op meerdere services kunnen worden toegepast.
‫In dit geval ga ik het aantal replica's van het web en de
‫API-services tegelijkertijd wijzigen.
‫Zoals ik een tijdje geleden al zei, heb je in de Swarm-updates geen ander deploy-commando.
‫Het is gewoon dezelfde docker-stack die wordt geïmplementeerd, met het bestand dat u hebt bewerkt, en het is de taak om
‫met alle andere delen van de API te werken om te
‫bepalen of er wijzigingen nodig zijn, en deze vervolgens uit te rollen met een service-update.
‫Oke. Laten we beginnen met het maken van een service, zodat we deze kunnen manipuleren met enkele update-opdrachten.
‫docker-service create -p 8088 80 name web, en we zullen Nginx gebruiken, en we gaan een versie specificeren zoals
‫we altijd zouden moeten in productie.
‫Het is leuk, nu we in de laatste helft van 2017 de detach-optie hebben met onze service-opdrachten voor maken
‫en bijwerken, kunnen we dit in realtime synchroon zien gebeuren.
‫Dit is dus goed voor update-opdrachten om te zien hoe updates daadwerkelijk via de opdrachtregel worden uitgerold.
‫Oke. Als we nu een docker-service ls doen, zien we dat onze service
‫actief is en dat deze 1 van de 1 replica's heeft, dus het is goed om te gaan.
‫Laten we nu onze service opschalen, zodat we wat meer replica's hebben om mee te werken. docker-serviceschaal Web=5.
‫En je zag net dat een daarvan al liep, en de andere 4 moesten starten. Het ging vrij snel voorbij op de mijne omdat ik
‫de afbeelding al had gedownload, maar die van jou kan een paar minuten duren terwijl ze in afwachting zijn terwijl de afbeelding op de
‫andere knooppunten wordt gedownload.
‫Oke.
‫Laten we een rollende update doen door de afbeelding van die Nginx te wijzigen.
‫Je zult hier zien dat ik een oudere afbeelding heb gekozen.
‫Het maakt Docker niet uit wat de afbeelding eigenlijk is.
‫Het kan een heel andere
‫toepassing zijn voor alles wat het kan. Het weet gewoon dat ik het in deze service in een ander beeld verander.
‫Onthoud dat het hier standaard één voor één doorheen gaat.
‫Het zal het eerst verwijderen, een nieuwe maken, en als die klaar is om te gaan, en
‫het ziet er gezond uit, zal het in de volgende beginnen. In het volgende voorbeeld gaan we de gepubliceerde poort
‫wijzigen.
‫Maar je kunt een poort niet wijzigen.
‫Je moet ze eigenlijk tegelijkertijd toevoegen en verwijderen.
‫Dus in dit geval, omdat we het voor het eerst met een 8088 hebben gepubliceerd, moeten we
‫een docker-service-update rm 8088 publiceren. Ik hoef de waarde niet op te geven. Ik hoef alleen de sleutel te specificeren. Dan gaan
‫we de nieuwe, 9090, publiceren. Dan de waarde, in dit geval 80. U zult zien dat
‫het hetzelfde updateproces zal uitvoeren als voorheen.
‫Het laatste voorbeeld waar ik het over wil hebben is een soort tip. Omdat je vaak een uitdaging hebt met
‫iets dat herbalanceren wordt genoemd. Of als je het aantal knooppunten verandert of als je veel dingen verplaatst, als je veel
‫containers in je zwerm hebt, zul je merken dat ze niet echt gelijk zijn. Je hebt misschien een aantal
‫knooppunten die vrij licht zijn over het aantal containers dat
‫wordt uitgevoerd en andere die veel hebben. Als er veel dingen veranderen, zal Swarm de dingen niet verplaatsen om alles in
‫evenwicht te houden in termen van het aantal gebruikte bronnen.
‫Maar wat u wel kunt doen, is dat u een update van een service kunt forceren, zelfs zonder iets in die service te wijzigen.
‫Vervolgens zal het taken opnieuw uitgeven, en in dat geval zal het de minst gebruikte knooppunten kiezen, wat een vorm van herbalanceren is.
‫Vaak in een kleinere zwerm, wanneer ik iets groots verplaats, of een aantal knooppunten toevoeg, heb ik plotseling een stel
‫lege servers die niets doen en ik moet eraan werken.
‫Dus wat ik zal doen is een of twee van mijn services nemen, en ik zal een docker-service-update
‫doen - forceren, en in dit geval gaat het door en vervangt het de taken volledig.
‫Natuurlijk zal het de standaardinstelling van het schema gebruiken om te zoeken naar knooppunten met het minste
‫aantal containers en het minste aantal gebruikte bronnen.
‫Dat is een soort truc om een ongelijke hoeveelheid werk op uw knooppunten te omzeilen.
‫Vergeet niet op te ruimen door de service te verwijderen die we in deze lezing hebben gemaakt.