Noat. transl.: Nei in resinte publikaasje oer pull- en push-metoaden yn GitOps seagen wy ynteresse yn dit model yn 't algemien, mar d'r wiene heul pear Russysketalige publikaasjes oer dit ûnderwerp (d'r binne gewoan gjin op Habré). Dêrom biede wy jo oandacht in oersetting fan in oar artikel oan - al is it hast in jier lyn! - fan Weaveworks, wêrfan it haad de term "GitOps" betocht. De tekst ferklearret de essinsje fan 'e oanpak en wichtige ferskillen fan besteande.
In jier lyn hawwe wy publisearre . Doe dielde wy hoe't it Weaveworks-team in SaaS lansearre folslein basearre op Kubernetes en in set fan prescriptive best practices ûntwikkele foar ynset, behear en tafersjoch yn in wolk native omjouwing.
It artikel blykte populêr te wêzen. Oare minsken begûnen te praten oer GitOps en begûnen nije ark te publisearjen foar , , , , ensafuorthinne. Ferskynd op ús webside publikaasjes en GitOps gebrûk gefallen. Mar guon minsken hawwe noch fragen. Hoe ferskilt it model fan it tradisjonele? en trochgeande levering ()? Is it nedich om Kubernetes te brûken?
Wy realisearre al gau dat in nije beskriuwing nedich wie, mei oanbieding:
- In grut tal foarbylden en ferhalen;
- Spesifike definysje fan GitOps;
- Fergeliking mei tradisjonele trochgeande levering.
Yn dit artikel hawwe wy besocht om al dizze ûnderwerpen te dekken. It biedt in bywurke ynlieding foar GitOps en in ûntwikkelders en CI / CD perspektyf. Wy rjochtsje ús primêr op Kubernetes, hoewol it model kin wurde generalisearre.
Moetsje GitOps
Stel jo Alice foar. Se rint Family Insurance, dy't sûnens-, auto-, hûs- en reisfersekering biedt oan minsken dy't it te drok hawwe om de yns en outs fan kontrakten sels út te finen. Har bedriuw begon as in sydprojekt doe't Alice wurke by in bank as datawittenskipper. Op in dei realisearre se dat se avansearre kompjûteralgoritmen koe brûke om gegevens effektiver te analysearjen en fersekeringspakketten te formulearjen. Ynvestearders finansierden it projekt, en no bringt har bedriuw mear as $ 20 miljoen yn 't jier en groeit hurd. Op it stuit wurkje der 180 minsken yn ferskate funksjes. Dit omfettet in technologyteam dat de webside, database ûntwikkelet, ûnderhâldt en de klantbasis analysearret. It team fan 60 minsken wurdt laat troch Bob, de technysk direkteur fan it bedriuw.
It team fan Bob set produksjesystemen yn 'e wolk yn. Har kearnapplikaasjes rinne op GKE, en profitearje fan Kubernetes op Google Cloud. Derneist brûke se ferskate gegevens- en analytyske ark yn har wurk.
Family Insurance wie net fan doel om konteners te brûken, mar rekke yn 'e Docker-entûsjasme. It bedriuw ûntduts al gau dat GKE it maklik makke om klusters yn te setten om nije funksjes te testen. Jenkins foar CI en Quay waarden tafoege om it kontenerregister te organisearjen, skripts waarden skreaun foar Jenkins dy't nije konteners en konfiguraasjes nei GKE skowe.
Wat tiid is foarby. Alice en Bob wiene teloarsteld mei de prestaasjes fan har keazen oanpak en har ynfloed op it bedriuw. De ynfiering fan konteners ferbettere de produktiviteit net sa folle as it team hie hope. Soms soe ynset brekke, en it wie ûndúdlik oft koade feroarings wiene de skuld. It die ek bliken lestich te wêzen om konfiguraasjewizigingen te folgjen. Faak wie it nedich om in nij kluster te meitsjen en applikaasjes nei it te ferpleatsen, om't dit de maklikste manier wie om de rommel te eliminearjen dy't it systeem wurden wie. Alice wie bang dat de situaasje slimmer wurde soe as de applikaasje ûntwikkele (dêrneist wie in nij projekt basearre op masine learen). Bob hie it measte fan it wurk automatisearre en begriep net wêrom't de pipeline noch ynstabyl wie, net goed skaalde, en periodyk manuele yntervinsje easke?
Doe learden se oer GitOps. Dit beslút blykte krekt te wêzen wat se nedich wiene om mei fertrouwen foarút te gean.
Alice en Bob hawwe jierrenlang heard oer Git, DevOps, en ynfrastruktuer as koade-workflows. Wat unyk is oan GitOps is dat it in set fan bêste praktiken bringt - sawol definityf as normatyf - foar it útfieren fan dizze ideeën yn 'e kontekst fan Kubernetes. Dit tema , ynklusyf yn .
Famyljefersekering beslút GitOps te ymplementearjen. It bedriuw hat no in automatisearre operaasjemodel dat kompatibel is mei Kubernetes en kombinearret faasje со stabiliteitomt sy:
- fûn dat de produktiviteit fan it team ferdûbele sûnder dat ien gek waard;
- stoppe mei it tsjinjen fan skripts. Ynstee, se kinne no rjochtsje op nije funksjes en ferbetterjen engineering metoaden - bygelyks, yntrodusearje kanaryske rollouts en ferbetterjen testen;
- wy hawwe it ynsetproses ferbettere sadat it selden brekt;
- krige de kâns om ynset te herstellen nei in part mislearrings sûnder hânmjittich yntervinsje;
- kocht brûktоMear fertrouwen yn leveringssystemen. Alice en Bob ûntdutsen dat se it team koene splitse yn mikroserviceteams dy't parallel wurkje;
- kin meitsje 30-50 feroarings oan it projekt alle dagen troch de ynspannings fan elke groep en besykje nije techniken;
- it is maklik om nije ûntwikkelders nei it projekt te lûken, dy't de kâns hawwe om updates nei produksje út te rollen mei help fan pull-oanfragen binnen in pear oeren;
- maklik trochjaan audit binnen it ramt fan SOC2 (foar it neilibjen fan tsjinstferlieners mei easken foar feilich gegevensbehear; lês mear, bygelyks, - ca. oerset.).
Wat is der bart?
GitOps is twa dingen:
- Operasjoneel model foar Kubernetes en cloud native. It biedt in set fan bêste praktiken foar it ynsetten, behearen en kontrolearjen fan containerisearre klusters en applikaasjes. Elegante definysje yn 'e foarm от :
- It paad nei it meitsjen fan in ûntwikkelderssintraal applikaasjebehearomjouwing. Wy tapasse de Git-workflow op sawol operaasjes as ûntwikkeling. Tink derom dat dit net allinich giet oer Git-push, mar oer it organisearjen fan de heule set fan CI / CD en UI / UX-ark.
In pear wurden oer Git
As jo net bekend binne mei ferzjekontrôlesystemen en Git-basearre workflow, riede wy tige oan om oer har te learen. Wurkje mei tûken en pull-oanfragen kin earst as swarte magy lykje, mar de foardielen binne de muoite wurdich. Hjir begjinne.
Hoe Kubernetes wurket
Yn ús ferhaal kearden Alice en Bob nei GitOps nei't se in skoft mei Kubernetes wurke hawwe. Ja, GitOps is nau besibbe oan Kubernetes - it is in operasjoneel model foar ynfrastruktuer en applikaasjes basearre op Kubernetes.
Wat jout Kubernetes brûkers?
Hjir binne guon haadfunksjes:
- Yn it Kubernetes-model kin alles yn deklarative foarm beskreaun wurde.
- De Kubernetes API-tsjinner nimt dizze deklaraasje as ynfier en besiket dan kontinu om it kluster yn 'e steat te bringen dy't beskreaun is yn 'e ferklearring.
- Deklaraasjes binne genôch om in breed ferskaat oan wurklasten te beskriuwen en te behearjen - "applikaasjes."
- As resultaat komme feroaringen yn 'e applikaasje en kluster foar troch:
- feroarings yn kontenerôfbyldings;
- feroarings oan 'e deklarative spesifikaasje;
- flaters yn 'e omjouwing - bygelyks container crashes.
Kubernetes' Grutte konverginsjemooglikheden
As in behearder konfiguraasjewizigingen makket, sil de Kubernetes-orkestrator se tapasse op it kluster salang't de steat is sil net komme tichtby de nije konfiguraasje. Dit model wurket foar elke Kubernetes-boarne en is út te wreidzjen mei Custom Resource Definitions (CRD's). Dêrom hawwe Kubernetes-implementaasjes de folgjende prachtige eigenskippen:
- Automatisearring: Kubernetes-updates jouwe in meganisme om it proses fan it tapassen fan wizigingen sierlik en op 'e tiid te automatisearjen.
- Konverginsje: Kubernetes sil trochgean mei it besykjen fan updates oant suksesfol.
- Idempotinsje: Werhelle tapassingen fan konverginsje liede ta itselde resultaat.
- Determinisme: Wannear't middels genôch binne, hinget de tastân fan it bywurke kluster allinich ôf fan 'e winske steat.
Hoe GitOps wurket
Wy hawwe genôch leard oer Kubernetes om út te lizzen hoe't GitOps wurket.
Litte wy weromgean nei de mikrotsjinstteams fan Family Insurance. Wat moatte se meastal dwaan? Sjoch nei de list hjirûnder (as ienige items dêryn frjemd of ûnbekend lykje, hâld dan asjebleaft op krityk en bliuw by ús). Dit binne gewoan foarbylden fan Jenkins basearre workflows. D'r binne in protte oare prosessen as jo wurkje mei oare ark.
It wichtichste is dat wy sjogge dat elke fernijing einiget mei wizigingen oan 'e konfiguraasjebestannen en Git-repositories. Dizze wizigingen oan Git soargje dat de "GitOps-operator" it kluster bywurkje:
1. Wurkproses: "Jenkins build - master branch".
Taaklist:
- Jenkins triuwt tagged bylden oan Quay;
- Jenkins triuwt config en Helm charts nei de master opslach emmer;
- De wolkfunksje kopiearret de konfiguraasje en diagrammen fan 'e master opslachbak nei it master Git repository;
- De GitOps-operator fernijt it kluster.
2. Jenkins build - release of hotfix branch:
- Jenkins triuwt untagged bylden oan Quay;
- Jenkins triuwt config- en Helm-kaarten nei de staging opslachbak;
- De wolkfunksje kopiearret de konfiguraasje en diagrammen fan 'e staging-opslachbak nei it staging Git-repository;
- De GitOps-operator fernijt it kluster.
3. Jenkins bouwe - ûntwikkelje of funksje branch:
- Jenkins triuwt untagged bylden oan Quay;
- Jenkins triuwt konfiguraasje- en Helm-kaarten yn 'e opslachbak foar ûntwikkeljen;
- De wolkfunksje kopiearret de konfiguraasje en diagrammen fan 'e ûntwikkel-opslachbak nei it ûntwikkeljen Git-repository;
- De GitOps-operator fernijt it kluster.
4. In nije klant tafoegje:
- De behearder of behearder (LCM/ops) ropt Gradle op om yn earste ynstânsje netwurk load balancers (NLB's) yn te setten en te konfigurearjen;
- LCM/ops set in nije konfiguraasje yn om de ynset foar fernijings ta te rieden;
- De GitOps-operator fernijt it kluster.
Koarte beskriuwing fan GitOps
- Beskriuw de winske steat fan it heule systeem mei deklarative spesifikaasjes foar elke omjouwing (yn ús ferhaal definiearret Bob's team de heule systeemkonfiguraasje yn Git).
- It Git-repository is de ienige boarne fan wierheid oangeande de winske steat fan it heule systeem.
- Alle wizigingen yn 'e winske steat wurde makke troch commits yn Git.
- Alle winske klusterparameters binne ek te observearjen yn it kluster sels. Op dizze manier kinne wy bepale oft se gearfalle (konvergearje, konvergearje) of ferskille (diverge, ôfwike) winske en waarnommen steaten.
- As de winske en waarnommen steaten ferskille, dan:
- D'r is in konverginsjemeganisme dat ier of letter automatysk it doel en de waarnommen steaten syngronisearret. Binnen it kluster docht Kubernetes dit.
- It proses begjint fuortendaliks mei in "feroaring ynsette" warskôging.
- Nei wat ynstelbere perioade kin in "ferskil" warskôging stjoerd wurde as de steaten oars binne.
- Op dizze manier feroarsaakje alle commits yn Git ferifieare en idempotinte updates foar it kluster.
- Rollback is konverginsje nei in earder winske steat.
- De konverginsje is definityf. It foarkommen wurdt oanjûn troch:
- Gjin ferskil warskôgings foar in bepaalde perioade fan tiid.
- "konvergearre" warskôging (bgl. webhook, Git writeback-evenemint).
Wat is diverginsje?
Litte wy nochris werhelje: alle winske kluster eigenskippen moatte wurde waarnommen yn it kluster sels.
Guon foarbylden fan diverginsje:
- Feroarje yn konfiguraasjetriem fanwege gearfoeging fan tûken yn Git.
- In feroaring yn it konfiguraasjetriem fanwege in Git-commit makke troch de GUI-kliïnt.
- Meardere feroarings oan 'e winske steat fanwege PR yn Git folge troch it bouwen fan it kontenerôfbylding en konfiguraasjewizigingen.
- In feroaring yn 'e steat fan it kluster fanwege in flater, boarne konflikt resultearret yn "min gedrach", of gewoan willekeurige ôfwiking fan de oarspronklike steat.
Wat is it meganisme fan konverginsje?
In pear foarbylden:
- Foar konteners en klusters wurdt it konverginsjemeganisme fersoarge troch Kubernetes.
- Itselde meganisme kin brûkt wurde foar it behearen fan Kubernetes-basearre applikaasjes en ûntwerpen (lykas Istio en Kubeflow).
- In meganisme foar it behearen fan de operasjonele ynteraksje tusken Kubernetes, ôfbyldingsrepositories en Git biedt , dat is diel .
- Foar basismasines moat it konverginsjemeganisme deklaratyf en autonoom wêze. Ut eigen ûnderfining kinne wy dat sizze tichtst by dizze definysje, mar noch fereasket minsklike kontrôle. Yn dizze sin wreidet GitOps de tradysje fan ynfrastruktuer as koade út.
GitOps kombinearret Git mei de treflike konverginsjemotor fan Kubernetes om in model te leverjen foar eksploitaasje.
GitOps lit ús sizze: Allinnich dy systemen dy't kinne wurde beskreaun en waarnommen kinne wurde automatisearre en kontrolearre.
GitOps is bedoeld foar de hiele wolk native stack (bygelyks Terraform, ensfh.)
GitOps is net allinich Kubernetes. Wy wolle dat it hiele systeem deklaratyf wurdt dreaun en konverginsje brûke. Mei it hiele systeem bedoele wy in samling omjouwings dy't wurkje mei Kubernetes - bygelyks "dev cluster 1", "produksje", ensfh Elke omjouwing omfettet masines, klusters, applikaasjes, en ek ynterfaces foar eksterne tsjinsten dy't gegevens, monitoring leverje. en ensfh.
Merk op hoe wichtich Terraform is foar it bootstrappingprobleem yn dit gefal. Kubernetes moat earne ynset wurde, en it brûken fan Terraform betsjut dat wy deselde GitOps-workflows kinne tapasse om de kontrôlelaach te meitsjen dy't Kubernetes en applikaasjes ûnderstipe. Dit is in nuttige bêste praktyk.
D'r is in sterke fokus op it tapassen fan GitOps-konsepten op lagen boppe op Kubernetes. Op it stuit binne d'r oplossingen fan GitOps-type foar Istio, Helm, Ksonnet, OpenFaaS en Kubeflow, lykas bygelyks foar Pulumi, dy't in laach meitsje foar it ûntwikkeljen fan applikaasjes foar cloud native.
Kubernetes CI / CD: GitOps fergelykje mei oare oanpak
Lykas sein, GitOps is twa dingen:
- It bestjoeringsmodel foar Kubernetes en wolk native hjirboppe beskreaun.
- It paad nei in ûntwikkelders-sintraal applikaasjebehearomjouwing.
Foar in protte is GitOps primêr in workflow basearre op Git-pushes. Wy fine him ek. Mar dat is net alles: lit ús no sjen nei CI/CD-pipelines.
GitOps makket trochgeande ynset (CD) foar Kubernetes mooglik
GitOps biedt in trochgeande ynsetmeganisme dat de needsaak foar aparte "ynsetbehearsystemen" elimineert. Kubernetes docht al it wurk foar jo.
- It bywurkjen fan de applikaasje fereasket bywurkjen yn Git. Dit is in transaksje-update nei de winske steat. "Ynset" wurdt dan dien binnen it kluster troch Kubernetes sels basearre op de bywurke beskriuwing.
- Fanwegen de aard fan hoe't Kubernetes wurket, binne dizze updates konvergent. Dit soarget foar in meganisme foar trochgeande ynset wêryn alle updates atoom binne.
- Tink derom: biedt in GitOps-operator dy't Git en Kubernetes yntegreart en lit CD wurde útfierd troch de winske en aktuele steat fan it kluster te fermoedsoenjen.
Sûnder kubectl en skripts
Jo moatte foarkomme dat jo Kubectl brûke om jo kluster te aktualisearjen, en foaral foarkomme dat jo skripts brûke om kubectl-kommando's te groepearjen. Ynstee, mei de GitOps-pipeline, kin in brûker har Kubernetes-kluster bywurkje fia Git.
Foardielen omfetsje:
- Rjochts. In groep updates kinne wurde tapast, konvergearre en úteinlik validearre, en bringt ús tichter by it doel fan atomyske ynset. Yn tsjinstelling, it brûken fan skripts jout gjin garânsje foar konverginsje (mear oer dit hjirûnder).
- Feiligens. Kelsey Hightower: "Beheine tagong ta jo Kubernetes-kluster ta automatisearringsark en behearders dy't ferantwurdlik binne foar it debuggen of ûnderhâlden." Sjoch ek oer feiligens en neilibjen fan technyske spesifikaasjes, lykas troch it stellen fan bewiisbrieven fan in achteleas skreaun Jenkins-skript.
- Brûkersûnderfining. Kubectl bleatret de meganika fan it Kubernetes-objektmodel, dy't frij kompleks binne. Ideal moatte brûkers ynteraksje mei it systeem op in heger nivo fan abstraksje. Hjir sil ik opnij ferwize nei Kelsey en oanbefelje om te sjen .
Ferskil tusken CI en CD
GitOps ferbetteret besteande CI / CD-modellen.
In moderne CI-tsjinner is in orkestraasjeark. Benammen is it in ark foar it orkestrearjen fan CI-pipelines. Dizze omfetsje bouwe, testen, fusearje nei trunk, ensfh. CI-tsjinners automatisearje it behear fan komplekse pipelines mei meardere stappen. In mienskiplike ferlieding is om in set fan Kubernetes-updates te skripten en it út te fieren as ûnderdiel fan in pipeline om wizigingen nei it kluster te triuwen. Yndie, dit is wat in protte saakkundigen dogge. Dit is lykwols net optimaal, en hjir is wêrom.
CI moat brûkt wurde om updates nei de romp te triuwen, en it Kubernetes-kluster moat himsels feroarje op basis fan dy updates om de CD yntern te behearjen. Wy neame it , Oars as it CI push-model. CD is diel runtime orkestraasje.
Wêrom CI-tsjinners gjin CD's moatte dwaan fia direkte updates yn Kubernetes
Brûk gjin CI-tsjinner om direkte updates nei Kubernetes te orkestrearjen as in set fan CI-banen. Dit is it anty-patroan wêr't wy it oer hawwe op dyn blog.
Litte wy werom nei Alice en Bob.
Hokker problemen kamen se tsjin? Bob's CI-tsjinner jildt de wizigingen op it kluster, mar as it yn it proses crasht, sil Bob net witte yn hokker steat it kluster is (of moat wêze) of hoe't it kin reparearje. Itselde is wier yn gefal fan sukses.
Litte wy oannimme dat it team fan Bob in nije ôfbylding boude en dan har ynset patched om de ôfbylding te setten (allegear fan 'e CI-pipeline).
As de ôfbylding normaal bouwt, mar de pipeline mislearret, sil it team moatte útfine:
- Is de fernijing útrol?
- Starte wy in nijbou? Sil dit liede ta ûnnedige side-effekten - mei de mooglikheid fan twa builds fan deselde ûnferoarlike ôfbylding?
- Moatte wy wachtsje op de folgjende fernijing foardat jo de build útfiere?
- Wat gie der krekt mis? Hokker stappen moatte wurde werhelle (en hokker binne feilich om te werheljen)?
It oprjochtsjen fan in Git-basearre workflow garandearret net dat it team fan Bob dizze problemen net sil tsjinkomme. Se kinne noch in flater meitsje mei de commit push, de tag, of in oare parameter; lykwols, dizze oanpak is noch folle tichter by in eksplisite alles-of-neat oanpak.
Om gearfetsje, hjir is wêrom CI-tsjinners net mei CD moatte omgean:
- Update skripts binne net altyd deterministysk; It is maklik om flaters yn harren te meitsjen.
- CI-tsjinners konvergearje net nei it deklarative klustermodel.
- It is lestich te garandearjen idempotency. Brûkers moatte de djippe semantyk fan it systeem begripe.
- It is dreger om te herstellen fan in partiel mislearjen.
Opmerking oer Helm: as jo Helm wolle brûke, riede wy oan om it te kombinearjen mei in GitOps-operator lykas . Dit sil helpe om konverginsje te garandearjen. Helm sels is noch deterministysk noch atoom.
GitOps as de bêste manier om Continuous Delivery foar Kubernetes te ymplementearjen
It team fan Alice en Bob ymplementearret GitOps en ûntdekt dat it folle makliker wurden is om te wurkjen mei softwareprodukten, hege prestaasjes en stabiliteit te behâlden. Litte wy dit artikel einigje mei in yllustraasje dy't toant hoe't har nije oanpak derút sjocht. Hâld der rekken mei dat wy it meast oer applikaasjes en tsjinsten prate, mar GitOps kin brûkt wurde om in folslein platfoarm te behearjen.
Operating model foar Kubernetes
Sjoch nei it folgjende diagram. It presintearret Git en it containerôfbyldingsrepository as dielde boarnen foar twa orkestrearre libbenssyklusen:
- In trochgeande yntegraasjepipeline dy't bestannen lêst en skriuwt nei Git en kin in repository fan kontenerôfbyldings bywurkje.
- In Runtime GitOps-pipeline dy't ynset kombineart mei behear en observabiliteit. It lêst en skriuwt bestannen nei Git en kin kontenerôfbyldings downloade.
Wat binne de wichtichste befinings?
- Skieding fan soargen: Tink derom dat beide pipelines allinich kinne kommunisearje troch it bywurkjen fan Git of it byldbewarplak. Mei oare wurden, d'r is in brânmuorre tusken CI en de runtime-omjouwing. Wy neame it de "ûnferoarlike firewall" (ûnferoarlike firewall), sûnt alle repository updates meitsje nije ferzjes. Foar mear ynformaasje oer dit ûnderwerp, ferwize nei dia 's 72-87 .
- Jo kinne elke CI- en Git-tsjinner brûke: GitOps wurket mei elke komponint. Jo kinne trochgean mei jo favorite CI- en Git-servers, ôfbyldingsrepositories en testsuites te brûken. Hast alle oare ark foar trochgeande levering op 'e merke fereaskje har eigen CI / Git-tsjinner as ôfbyldingsrepository. Dit kin in beheinende faktor wurde yn 'e ûntwikkeling fan wolk native. Mei GitOps kinne jo fertroude ark brûke.
- Eveneminten as in yntegraasje ark: Sadree't gegevens yn Git bywurke binne, meldt Weave Flux (as de Weave Cloud-operator) runtime. Elke kear as Kubernetes in wizigingset akseptearret, wurdt Git bywurke. Dit leveret in ienfâldich yntegraasjemodel foar it organisearjen fan workflows foar GitOps, lykas hjirûnder werjûn.
konklúzje
GitOps leveret de sterke updategarânsjes dy't nedich binne troch elk modern CI / CD-ark:
- automatisearring;
- convergence;
- idempotency;
- determinisme.
Dit is wichtich om't it in operasjoneel model biedt foar cloud-native ûntwikkelders.
- Tradysjonele ark foar it behearen en kontrolearjen fan systemen wurde assosjeare mei operaasjeteams dy't wurkje binnen in runbook (in set fan routine prosedueres en operaasjes - sawat oerset.), ferbûn oan in spesifike ynset.
- Yn cloud native management binne observabiliteitsark de bêste manier om de resultaten fan ynset te mjitten, sadat it ûntwikkelteam fluch kin reagearje.
Stel jo in protte klusters foar ferspraat oer ferskate wolken en in protte tsjinsten mei har eigen teams en ynsetplannen. GitOps biedt in skaal-invariant model foar it behearen fan al dizze oerfloed.
PS fan oersetter
Lês ek op ús blog:
- «";
- «";
- «".
Allinnich registrearre brûkers kinne meidwaan oan 'e enkête. , asjebleaft.
Wisten jo oer GitOps foardat dizze twa oersettingen op Habré ferskynden?
-
Ja, ik wist alles
-
Allinnich oerflakkich
-
gjin
35 brûkers stimden. 10 brûkers ûntholden har.
Boarne: www.habr.com