‫Laat me je vertellen over dry runs en diff's, dat
‫is nieuw spul.
‫De laatste paar versies van Kubernetes beginnen met 1. 13 hebben
‫deze nieuwe optie waarmee we kunnen zien wat
‫we gaan veranderen voordat we het veranderen.
‫Dat hebben we eerder gezien.
‫Ik heb je eerder in de cursus een paar voorbeelden laten zien.
‫Maar deze methode om het te gebruiken
‫met de opdracht Apply is nieuw
‫en beter. Wat we in het verleden
‫hadden, was dat we een droge run hadden, maar het was
‫alleen op de klant. De client heeft niet echt
‫met de server gepraat om te zeggen he, zijn deze bronnen er al?
‫Moet ik ze opnieuw maken, of worden ze bijgewerkt of wat gaat
‫er gebeuren? Rechts.
‫Dat gebeurde niet eerder.
‫Nu is er een server-dry-run-optie die onze
‫YAML naar de server stuurt en vergelijkt, uitzoekt
‫wat er daadwerkelijk moet gebeuren en vervolgens aan
‫de opdrachtregel rapporteert wat er
‫gaat veranderen. Laten we dat in actie zien.
‫Ik ben in de K8s YAML-directory zoals ik eerder in een lezing heb
‫besproken, als je in de repo van Docker Mastery bent en je hebt deze
‫directory niet, dan moet je een
‫git-pull doen om de laatste updates te krijgen.
‫Dit is een bestand dat we hebben gezien
‫in een eerdere lezing, app. yml. Dit is een service,
‫plus een implementatie, in één bestand.
‫Technisch gezien zijn er twee bronnen gemaakt met
‫één toepassingsopdracht en ze zijn gerelateerd.
‫De service maakt gebruik van een selector, waar we het
‫nog niet over hebben gehad. Met selectors vindt een object
‫de bronnen waarmee het wil praten of iets mee
‫wil doen.
‫Een service moet met pods kunnen praten, dus het moet een manier vinden
‫om die te bereiken.
‫Het gebruikt selectors als in wezen patroonovereenkomst
‫om de labels met de sleutels en waarden
‫daar te matchen. Als ik hier de traditionele
‫test zou doen, dan zou de klant alleen maar naar de aanvraag kijken
‫en zeggen: ja, ik ga deze objecten maken.
‫Oke. Het komt altijd terug en zegt gemaakt.
‫Dat komt omdat de aanvraag niet erg
‫specifiek is. Als je een update-, of
‫een create- of een delete-opdracht gebruikte, wat weer volgens
‫mij niet een erg op DevOps gebaseerde workflow is.
‫Die commando's zouden gewoon een droge run doen en je weet
‫dat de update zou zeggen ja, ze
‫zullen allebei worden bijgewerkt. Maar het weet het niet echt
‫op uw cluster, toch. Het heeft niet met de server gesproken om dat uit te zoeken.
‫We willen de server-dry-run proberen die standaard is
‫ingeschakeld op alles 1. 13 en nieuwer.
‫Wanneer ik dat doe, zal het met de server gaan praten en
‫me een goed antwoord geven.
‫Laten we doorgaan en dit creëren.
‫Ik ga de server op de proef stellen.
‫Hiermee worden de twee bronnen, de implementatie en de
‫service gemaakt.
‫Als ik nu op de pijl omhoog druk en terugga naar de droge run
‫van de server, zul je zien dat er voor beide ongewijzigd staat.
‫Het vertelt me niet wat er is veranderd of of
‫er iets was dat zou veranderen
‫wat het zou zijn. Het vertelt me alleen dat een bron
‫zal worden gewijzigd of niet zal worden gewijzigd. Het is een soort schakelaar, ja of nee.
‫Hoe zit het met het verkrijgen van het werkelijke verschil tussen
‫wat we de server willen geven en wat de
‫huidige status is van onze bronnen.
‫Dat is de opdracht kubectl diff.
‫Als ik het gewoon een diff geef in plaats
‫van een toepassing, zal het de YAML die ik
‫heb vergelijken met de specificatie die op de servers staat
‫die nu worden uitgevoerd. die status komt terug, en het zal daar
‫een verschil in maken. Laten we dat doen.
‫Het zal niets zeggen omdat er geen verschil is.
‫Maar wat als we de YAML gaan veranderen?
‫Wat als ik de replica's in twee verander?
‫Dan voeg ik een label toe aan de metadata en geef ik
‫het zoiets als... zoiets als.
‫Servers dmz.
‫Ik heb het verzonnen. Maakt niet echt uit.
‫Dan hebben we de replica's van twee.
‫Als ik datzelfde diff doe, komt het terug met de
‫plussen en minnen.
‫Als je gewend bent om diff's te lezen, is
‫dit volkomen logisch voor jou. Als je niet gewend bent aan diff's,
‫betekent de min dat die regel zou verdwijnen.
‫Dan zouden deze regels worden toegevoegd.
‫Dan hier beneden, laat het je zien welke regel en
‫welk teken in de regel dit
‫wordt verwijderd.
‫Dit wordt toegevoegd.
‫Het behoudt de YAML-opmaak, wat leuk is.
‫Het laat ons weten dat er meerdere veranderingen plaatsvinden.
‫Geweldig. Dit is natuurlijk niet echt iets
‫doen als een kanarie, of testimplementatie of iets dergelijks.
‫Het is niet proberen om het ding te doen en dan zien
‫wat het resultaat is. Het is eigenlijk gewoon kijken
‫naar de specificatie die het heeft, en de specificatie die we op
‫onze schijf hebben. Kijk
‫voor meer informatie hierover op de bronnenlinks.
‫Het is een blogartikel van het Kubernetes-team over de
‫toekomst hiervan en hoe ze zullen uitpakken als ze
‫uit de bèta komen. Onthoud dat deze functies op dit moment bèta
‫zijn, in ieder geval in 1. 15 ze zijn.
‫Hopelijk kun je daarmee je eigen workflow creëren voor het helemaal
‫opnieuw maken van YAML's, het beheren van
‫de specificaties in die YAML's en vervolgens het toepassen van de opdracht
‫steeds opnieuw gebruiken om je wijzigingen aan te brengen.
‫Dat is een veel DevOps-vriendelijke infrastructuur als
‫een manier van coderen.
‫Alles wat je doet is gedocumenteerd, hopelijk in Git.
‫Dus hopelijk maak je een git-commit voor elke wijziging die je aanbrengt
‫in je YAML voordat je het op de server implementeert.
‫Dan heb je die mooie documentatie in Git, evenals de
‫documentatie wanneer je zoiets als een diff doet om te zien
‫wat je hebt versus wat er daadwerkelijk draait.