‫In de laatste video heb ik het gehad over Dwingend vs.
‫declaratief. We spraken over de bijzonderheden in Kubernetes van
‫de een of de ander.
‫Echt, als je naar de Kubernetess-documentatie kijkt, leent
‫het zich voor drie verschillende stijlen.
‫Er is een subtiel verschil, maar ze zitten echt in een
‫spectrum van helemaal op imperatief aan de ene kant en helemaal
‫declaratief aan de andere kant.
‫Dan deze leuke, kleine optie in het midden als je er toch voor
‫kiest om hem te gebruiken. In deze
‫cursus heb ik je tot nu toe de
‫strikte, dwingende CLI-commando's bijgebracht. Dat omvat rennen, blootstellen.
‫Misschien hebben we schaal.
‫We hebben de bewerking niet behandeld, maar het doet precies wat
‫je denkt dat het zou doen. Het bewerkt een bron in realtime.
‫Of maak een implementatie, wat de nieuwe manier is om een run uit te voeren.
‫Deze zijn echt het beste om te
‫leren hoe dingen werken. Het leren van de soorten bronnen en
‫wat ze doen, en persoonlijke projecten en echt kleine opstellingen waar
‫jij misschien de enige verantwoordelijke bent. Je probeert
‫niet te automatiseren. Je probeert niet een volledige productieworkflow uit te
‫bouwen, en CICD, toch.
‫Dat is geweldig voor hen.
‫Dan is er een mooie
‫middenweg die Kubernetes je biedt met de create-commando's die
‫je ofwel de create-commando's zelf kunt gebruiken, maar je
‫kunt die ook gebruiken met een YAML-bestand.
‫Je kunt create -f gebruiken, en je kunt het een
‫van die specificaties geven zoals we eerder zagen.
‫Je kunt het een specificatie geven en het zal elk van de objecten maken
‫die je daar hebt. U kunt meerdere
‫objecten in dat bestand hebben. Je zou daar een
‫implementatie kunnen hebben, plus een service.
‫Misschien wat opslagbehoeften die je hebt, netwerkinstellingen, wat
‫dan ook. Je zou al dat ene mooie bestand kunnen hebben.
‫Als je dan iets daarin zou moeten vervangen, zou
‫je het bestand kunnen bewerken en dan de opdracht vervangen kunnen gebruiken,
‫die we nog niet hebben behandeld, maar het doet wat je
‫denkt dat het doet. Dan is er het delete-commando,
‫dat we hebben gebruikt, dat doet wat je denkt dat het ook doet.
‫Het leuke hier is dat het een soort middenweg is, toch.
‫Het dwingt je om YAML te gebruiken, zodat je hebt gedocumenteerd wat
‫je doet, en je hebt dit wijzigingsrecord als je zoiets
‫als git gebruikt.
‫Hopelijk gebruik je git.
‫Het voordeel daar is echter voor ons mensen,
‫we gebruiken het creëren, of het vervangen,
‫of het verwijderen. Het geeft ons dus dit
‫expliciete werkwoord om te gebruiken, zodat we weten dat we niet per
‫ongeluk iets verwijderen wanneer we een create-opdracht gebruiken.
‫En we weten dat we niet per ongeluk iets verwijderen als
‫we de opdracht Replace gebruiken.
‫Dus dat helpt, toch.
‫Dat is een goede middenweg, aangezien je je
‫voeten nat maakt in de YAML-specificaties die
‫je zult moeten gebruiken als je bij het volledige,
‫declaratieve objectmodel komt. Dat is waar ik het eerder over had.
‫Dat is waar je alleen YAML gebruikt en alleen
‫de opdracht Apply.
‫Er zijn andere commando's om je te helpen bij het toepassen,
‫zoals de diff, die je de veranderingen laat zien die je gaat maken.
‫Maar toepassen is simpelweg het bewerken van YAML en het
‫uitvoeren van de toepassing.
‫Bewerk nog wat YAML, voer de toepassing uit.
‫Dit is vergelijkbaar met Swarm waar we Swarm-stacks hadden.
‫Als je het je herinnert, is er een docker
‫stack deploy-opdracht en om die bij te werken, gebruik je
‫dezelfde opdracht steeds opnieuw.
‫Dat is dezelfde stijl hier met hun
‫volledige declaratieve objecten. Het is fijn dat ze
‫documentatie hebben, en je zult dit zien in de
‫bronnenlinks voor deze lezing, een zeer gedetailleerde pagina over deze drie verschillende soorten.
‫Ik moedig je aan om dat eens te bekijken.
‫De echte regel die ik aan dit
‫hele ding ga geven, zelfs als je de bronnenpagina erover gaat
‫lezen, is om de drie benaderingen gewoon niet te mixen.
‫Het is belangrijker dat u deze drie niet combineert
‫als u echte productie-afhankelijkheden hebt.
‫In productie ga ik er echt voor
‫pleiten dat je zo vroeg mogelijk in je
‫volwassenheidsmodel probeert vast te houden aan het volledige
‫declaratieve model met behulp van de YAML-bestanden met de
‫opdracht Apply.
‫Hoe eerder je je daarmee op je gemak voelt, hoe
‫eerder je gewend bent om dat in YAML te documenteren en het op
‫te slaan in een git-commit elke keer dat je
‫het verandert, dat proces zal je later echt ten goede komen.
‫Als iemand wijzigingen wil zien die je hebt, kunnen ze
‫gaan kijken naar de git-log. De meesten van ons doen vandaag
‫waarschijnlijk iets in git, dus het zal niet veel moeite voor je
‫zijn om nog een git-repo te maken om deze
‫YAML's op te slaan, toch. Zelfs als je git
‫lokaal op je machine doet, kan git local je in
‫principe helpen de geschiedenis van wijzigingen te zien die je aan
‫deze YAML's hebt gedaan, zodat wanneer je over zes maanden vergeet
‫wat je drie maanden geleden hebt veranderd, je kunt gaan terug en kijk
‫en kijk wat je daar doet.
‫Dat gaat je echt veel tijd schelen.
‫De belangrijkste regel is dat je de benaderingen niet door elkaar haalt.
‫Als u iets maakt met uitvoeren, wordt het later
‫moeilijker om de toepassing te gebruiken om die bron te beheren.
‫Er zijn kleine kneepjes van het vak die je kunt omzeilen
‫met sommige van deze commando's om te proberen objecten later te bewerken
‫zonder ze te verknoeien.
‫Maar echt, als je productie gaat
‫doen, moet je waarschijnlijk niet beginnen met die
‫run-commando's op je productieserver. U moet waarschijnlijk op lange termijn denken
‫en bij de YAML blijven. Mijn vier tips hier zijn om
‫de opdrachtregel te leren zoals jij dat doet.
‫Leer die dwingende opdrachtregel zodat u deze
‫lokaal kunt gebruiken. En je hebt die commando's
‫soms nodig voor het oplossen van problemen en testen, en ook voor servers.
‫Om u vervolgens voor te bereiden op uw eerste
‫productie, is Kubernetes het zo snel mogelijk leren van het
‫apply-commando, het diff-commando, de
‫YAML-specificatie voor alle resourcetypen die u gaat gebruiken.
‫Dan opslaan in git zoals ik zeg.
‫Zelfs als het alleen lokale git of git repo's zijn die
‫je team kan gebruiken.
‫Onthoud dat deze methode van het bewerken van
‫de YAML, het opslaan van de wijziging in git, het toepassen
‫ervan met kubectl van toepassing is, het vervolgens opnieuw opslaan en het opslaan
‫van wijzigingen in git.
‫Dit proces zal je op weg helpen naar DevOps-automatisering
‫en naar die git-ops die ik eerder noemde,
‫en ik denk dat sommige van deze
‫tools beginnen te gaan. Waar we git-centrisch zijn.
‫We brengen wijzigingen aan in een git-repo, net zoals softwarecodeerders
‫dat doen..
‫We doen hetzelfde met deze DevOps-workflow.
‫We passen de manier waarop ze hun veranderingswerk doen in
‫een team toe voor onze eigen operaties en tooling.