Opmerking. vert.: Met Kubernetes-enthousiastelingen van het project we hebben elkaar ontmoet tijdens een recent evenement , waar ze een prettige indruk op ons maakten. Dit materiaal van hen, geschreven over een actueel technisch onderwerp en met een merkbaar gevoel voor humor, is hiervan een duidelijke bevestiging, en daarom hebben we besloten het te vertalen.
Hij praat over het belangrijkste (met dezelfde naam) bedrijf, wiens idee het is om workflows te automatiseren en de ontwikkeling van applicaties in Kubernetes te vereenvoudigen. Om dit te doen, kunt u met het hulpprogramma eenvoudig (letterlijk met één opdracht) nieuwe wijzigingen in de code implementeren in het ontwikkelcluster, en biedt het ook gedeelde bronnen/caches om het bouwen en testen van de code door het team te versnellen. Twee weken geleden was de Tuin gastheer , waarin het mogelijk werd om niet alleen een lokaal Kubernetes-cluster te gebruiken, maar ook een extern cluster: dit is de gebeurtenis waar dit artikel aan is gewijd.
Mijn minst favoriete bezigheid is werken met Kubernetes op mijn laptop. De "stuurman" vreet zijn processor en batterij op, zorgt ervoor dat koelers non-stop draaien en is moeilijk te onderhouden.
Stockfotografie in thema voor extra effect
Minikube, soort, k3s, Docker Desktop, microk8s, enz. - uitstekende tools gemaakt om het gebruik van Kubernetes zo gemakkelijk mogelijk te maken, en dankzij hen daarvoor. Ernstig. Maar hoe je het ook bekijkt, één ding is duidelijk: Kubernetes is niet geschikt om op mijn laptop te draaien. En de laptop zelf is niet ontworpen om te werken met een cluster van containers verspreid over lagen virtuele machines. Het arme ding doet zijn best, maar houdt duidelijk niet van deze activiteit. Hij toont zijn ontevredenheid over het gehuil van de koelers en probeert zijn dijen te verbranden als ik hem roekeloos op mijn knieën zet.
Laten we zeggen: laptop - laptop.
is een tool voor ontwikkelaars die dezelfde niche bezet als Skaffold en Draft. Het vereenvoudigt en versnelt het ontwikkelen en testen van Kubernetes-applicaties.
Vanaf het moment dat we aan Garden begonnen te werken, zo’n anderhalf jaar geleden, wisten we dat lokaal Gedistribueerde systeemontwikkeling is een tijdelijke oplossing, dus Garden heeft aanzienlijke flexibiliteit en een solide basis ingebouwd.
We zijn nu klaar om zowel lokale als externe Kubernetes-omgevingen te ondersteunen. Het werk is veel eenvoudiger geworden: assemblage, implementatie en testen kunnen nu in een extern cluster worden uitgevoerd.
In het kort:
Met Garden v0.10 kunt u een lokaal Kubernetes-cluster volledig vergeten en toch snel reageren op codewijzigingen. Dit alles is gratis en open source.
Geniet van dezelfde ervaring in lokale en externe omgevingen
Heb je je aandacht?
En daar ben ik blij om, want we hebben nog veel meer interessante functies! Het algemene gebruik van ontwikkelclusters heeft bredere implicaties, vooral voor samenwerkingsteams en CI-pijplijnen.
Hoezo?
Allereerst worden de intra-clustercollector (of het nu een standaard Docker-daemon of Kaniko is) en het intra-clusterregister gedeeld voor het gehele cluster. Uw team kan een ontwikkelcluster delen, waarbij buildcaches en images beschikbaar zijn voor alle ontwikkelaars. Omdat Garden afbeeldingen tagt op basis van bron-hashes, worden tags en lagen uniek en consistent gedefinieerd.
Dit betekent dat zodra een ontwikkelaar een afbeelding maakt, deze ook een afbeelding wordt beschikbaar voor het hele team. Dag na dag downloaden we dezelfde basisafbeeldingen en maken we dezelfde builds op onze computers. Benieuwd hoeveel verkeer en elektriciteit er wordt verspild?
Hetzelfde kan gezegd worden over tests: de resultaten ervan zijn beschikbaar voor het hele cluster en alle teamleden. Als een van de ontwikkelaars een bepaalde versie van de code heeft getest, is het niet nodig dezelfde test opnieuw uit te voeren.
Met andere woorden, het is niet alleen een kwestie van het niet uitvoeren van minikube. Deze sprong maakt de weg vrij voor uw team veel optimalisatiemogelijkheden - geen onnodige builds en testruns meer!
Hoe zit het met CI?
De meesten van ons zijn eraan gewend dat CI en lokale dev twee afzonderlijke werelden zijn die afzonderlijk moeten worden geconfigureerd (en dat ze geen cache delen). Nu kun je ze combineren en het teveel kwijtraken:
U kunt dezelfde opdrachten uitvoeren in CI en in het ontwikkelingsproces, evenals gebruik één omgeving, caches en testresultaten.
In wezen wordt uw CI een ontwikkelaarsbot die in dezelfde omgeving werkt als u.
Systeemelementen; naadloos ontwikkelen en testen
CI-pijplijnconfiguraties kunnen aanzienlijk worden vereenvoudigd. Om dit te doen, voert u gewoon Garden uit vanuit CI voor builds, tests en implementaties. Omdat u en het CI dezelfde omgeving gebruiken, is de kans veel kleiner dat u CI-problemen tegenkomt.
Het doorzoeken van talloze regels met configuraties en scripts, vervolgens duwen, wachten, hopen en eindeloze herhalingen... Dit alles behoort tot het verleden. Je doet gewoon aan ontwikkeling. Geen onnodige bewegingen.
En om de situatie ten slotte te verduidelijken: toen jij of een ander teamlid iets bouwde of testte met Garden, gebeurde hetzelfde voor CI. Als u niets heeft gewijzigd sinds de testuitvoeringen, hoeft u geen tests (of zelfs builds) voor CI uit te voeren. Garden doet alles zelf en gaat vervolgens verder met andere taken, zoals het organiseren van de pre-lanceringsomgeving, het pushen van artefacten, enz.
Klinkt verleidelijk. Hoe te proberen?
Welkom bij ! Installeer Garden en speel met de voorbeelden. Voor degenen die Garden al gebruiken of het beter willen leren kennen, bieden wij aan . Sluit je aan bij ons in het kanaal , als je vragen hebt, problemen hebt of gewoon even wilt kletsen. We staan altijd klaar om te helpen en verwelkomen feedback van gebruikers.
PS van vertaler
Binnenkort zullen we ook een overzicht publiceren van nuttige hulpprogramma's voor applicatie-ontwikkelaars die in Kubernetes werken, waarin naast Garden ook andere interessante projecten zijn opgenomen... Lees ondertussen ook op onze blog:
- «";
- «";
- «";
- «.
Bron: www.habr.com