Bemærk. overs.: Med Kubernetes-entusiaster fra projektet vi mødtes ved et nyligt arrangement , hvor de gjorde et behageligt indtryk på os. Dette deres materiale, skrevet om et aktuelt teknisk emne og med en mærkbar sans for humor, er en klar bekræftelse på dette, og derfor besluttede vi at oversætte det.
Han taler om det vigtigste (af samme navn) virksomhed, hvis idé er at automatisere arbejdsgange og forenkle applikationsudvikling i Kubernetes. For at gøre dette giver værktøjet dig mulighed for nemt (bogstaveligt talt med én kommando) at implementere nye ændringer foretaget i koden til dev-klyngen, og det giver også delte ressourcer/caches for at fremskynde opbygningen og testningen af koden af teamet. For to uger siden var Haven vært , hvor det blev muligt at bruge ikke kun en lokal Kubernetes-klynge, men også en fjern: dette er den begivenhed, som denne artikel er viet til.
Min mindst foretrukne ting at gøre er at arbejde med Kubernetes på min bærbare computer. "Rorsmanden" æder sin processor og batteri op, får kølere til at rotere nonstop og er svær at vedligeholde.
Lagerfotografering i tema for ekstra effekt
Minikube, kind, k3s, Docker Desktop, microk8s osv. - fremragende værktøjer skabt til at gøre brugen af Kubernetes så bekvem som muligt, og tak til dem for det. Helt seriøst. Men uanset hvordan man ser på det, er én ting klar: Kubernetes er ikke egnet til at køre på min bærbare computer. Og selve den bærbare computer er ikke designet til at fungere med en klynge af containere spredt ud over lag af virtuelle maskiner. Den stakkel gør sit bedste, men kan tydeligvis ikke lide denne aktivitet, viser sin utilfredshed med hylen fra kølerne og forsøger at brænde hans lår, når jeg hensynsløst lægger ham på knæ.
Lad os sige: bærbar - bærbar.
er et værktøj til udviklere, der indtager samme niche som Skaffold og Draft. Det forenkler og fremskynder udvikling og test af Kubernetes-applikationer.
Fra det øjeblik, vi begyndte at arbejde på Garden, for omkring 18 måneder siden, vidste vi det lokal Distribueret systemudvikling er en midlertidig løsning, så Garden bygget i betydelig fleksibilitet og et solidt fundament.
Vi er nu klar til at understøtte både lokale og fjerntliggende Kubernetes-miljøer. Arbejdet er blevet meget lettere: montering, implementering og test kan nu udføres i en fjernklynge.
Kort sagt:
Med Garden v0.10 kan du helt glemme alt om en lokal Kubernetes-klynge og stadig få hurtig respons på kodeændringer. Alt dette er gratis og open source.
Nyd den samme oplevelse på tværs af lokale og fjerntliggende miljøer
Fik du din opmærksomhed?
Og jeg er glad for dette, for vi har mange flere interessante funktioner! Den generelle brug af udviklerklynger har bredere implikationer, især for samarbejdshold og CI-pipelines.
Hvordan så?
Først og fremmest deles intra-cluster-samleren - det være sig en standard Docker-dæmon eller Kaniko - såvel som intra-cluster-registret for hele klyngen. Dit team kan dele en udvikler-klynge med build-caches og billeder tilgængelige for alle udviklere. Fordi Garden mærker billeder baseret på kildehash, er tags og lag defineret unikt og konsekvent.
Det betyder, at når først en udvikler skaber et billede, bliver det det tilgængelig for hele holdet. Dag efter dag downloader vi de samme basisbilleder og laver de samme builds på vores computere. Er du nysgerrig efter, hvor meget trafik og strøm der går til spilde?
Det samme kan siges om tests: deres resultater er tilgængelige for hele klyngen og alle teammedlemmer. Hvis en af udviklerne har testet en bestemt version af koden, er der ingen grund til at køre den samme test igen.
Det er med andre ord ikke kun et spørgsmål om ikke at køre minikube. Dette spring baner vejen for dit team mange optimeringsmuligheder - ikke flere unødvendige builds og testkørsler!
Hvad med CI?
De fleste af os er vant til, at CI og lokal dev er to separate verdener, der skal konfigureres separat (og de deler ikke en cache). Nu kan du kombinere dem og slippe af med det overskydende:
Du kan udføre de samme kommandoer i CI og i udviklingsprocessen, samt bruge et enkelt miljø, caches og testresultater.
Grundlæggende bliver din CI en udvikler-bot, der arbejder i det samme miljø som dig.
Systemelementer; problemfri udvikling og test
CI-pipeline-konfigurationer kan forenkles betydeligt. For at gøre dette skal du bare køre Garden fra CI til builds, tests og implementeringer. Da du og CI bruger det samme miljø, er det meget mindre sandsynligt, at I støder på CI-problemer.
At grave gennem utallige linjer med konfigurationer og scripts, derefter skubbe, vente, håbe og endeløse gentagelser... Alt dette er fortid. Du laver bare udvikling. Ingen unødvendige bevægelser.
Og for til sidst at afklare situationen: da du eller et andet teammedlem byggede eller testede noget med Garden, skete det samme for CI. Hvis du ikke har ændret noget siden testkørslerne, behøver du ikke at køre test (eller endda builds) for CI. Garden gør alt selv og går derefter videre til andre opgaver såsom at organisere pre-launch miljøet, skubbe artefakter osv.
Lyder fristende. Hvordan prøver man?
Velkommen til ! Installer Garden og leg med eksemplerne. Til dem, der allerede bruger Garden eller gerne vil lære den bedre at kende, tilbyder vi . Slut dig til os på kanalen , hvis du har spørgsmål, problemer eller bare vil chatte. Vi er altid klar til at hjælpe og modtager gerne feedback fra brugere.
PS fra oversætteren
Snart vil vi også offentliggøre en gennemgang af nyttige værktøjer til applikationsudviklere, der opererer i Kubernetes, som omfatter andre interessante projekter ud over Garden... I mellemtiden kan du læse også på vores blog:
- «";
- «";
- «";
- «'.
Kilde: www.habr.com