GitHub-teamet lærte at implementere Kubernetes-klynger i et fysisk miljø ikke er let; nogle endte med at køre en Kubernetes-klynge derhjemme.
GitHub på onsdag er deler detaljerne af den massive tekniske indsats, dets ingeniører gik igennem for at migrere infrastrukturen, der driver github.com og api.github.com -- nogle af dets mest kritiske arbejdsbelastninger -- fra et sæt manuelt konfigurerede fysiske servere til Kubernetes-klynger, der kører applikationer containere.
GitHub er overbevist om, at flytningen vil give mulighed for hurtigere innovation på online-kodedelings- og udviklingsplatformen.
"Vi har givet vores ingeniører et bedre miljø, hvor de kan eksperimentere og køre koden, der driver github.com," sagde Jesse Newland, GitHubs primære site reliability engineer, til ZDNet. "Vi er virkelig glade for at se innovationshastigheden stige hos GitHub og forhåbentlig bruge det til at bringe bedre software og tjenester til alle rundt om i verden - og som et resultat af det have en positiv indvirkning på softwareindustrien som en hel."
Efter flere års drift af en stort set statisk gruppe af servere, der drev applikationen, der betjener webanmodninger, var tiden kommet for GitHub til at flytte til et system med mere fleksibilitet. Nye tjenester kan tage dage, uger eller endda måneder at implementere.
"Vi var nødt til at bygge små miljøer at eksperimentere i, for at tillade ingeniører at bygge nye ting," sagde Newland. "Vi havde også brug for at reagere hurtigere på ændringer i efterspørgslen. Vores trafik vokser, og det skal vi altid forholde os til, og vi ser også regelmæssige dale i vores trafik."
Holdet henvendte sig til Kubernetes for dets stærke open source-fællesskab, der understøtter projektet, GitHubs første kørsel erfaring med det, og på grund af det væld af tilgængelige informationer om oplevelsen, der motiverede det design.
En af GitHubs største forhindringer var imidlertid manglen på dokumentation for udrulningen af Kubernetes-klynger i et fysisk datacentermiljø. Faktisk er meget af den relevante dokumentation, der findes om emnet, fokuseret på hjemmebrugere, sagde Newland.
Som et resultat har "flere af os, der arbejdede på projektet, en skabs-Kubernetes-klynge i vores hus," sagde Newland, "som er fantastisk til eksperimentering."
Mens GitHub har nået milepælen med at migrere applikationen, der kører github.com, er den stadig ved at forfine, hvordan den kører Kubernetes i et fysisk miljø. Til sidst, sagde Newland, vil hans team dele denne oplevelse "og forsøge at forbedre dokumentation af Kubernetes, så andre mennesker, der sigter mod at gøre det samme i fremtiden, har det bedre erfaring."
Teamet tog også en risiko ved at vælge at starte sin migrering med en af dets mest kritiske arbejdsbelastninger.
"Vi gjorde det meget bevidst," sagde Newland. "Vi vidste, at den arbejdsbyrde er særdeles godt forstået af et stort antal mennesker rundt omkring i virksomheden. Du kan finde ethvert hjørne af den applikation og finde folk med stor erfaring i den pågældende del af den. Hver gang vi stødte på et problem, var vi i stand til at opspore ingeniører, der virkelig var eksperter på området."
Selvom dette var den applikation, GitHub oprindeligt var målrettet mod, var det ikke den første applikation, holdet kørte på Kubernetes - de havde brug for at køre andre understøttende tjenester. Alligevel er dette, hvad holdet betragtede som deres første bemærkelsesværdige succes.
"Jeg har set, både hos GitHub og andre organisationer, når et migreringsforsøg udføres ved at bruge et legetøj eller en mindre tjeneste som det store første skridt," sagde Newland. "Det kan ofte være ekstremt vellykket - og det kan ofte gå i stå der. Det var det, vi søgte at undgå. Vi ønskede ikke at komme halvvejs og derefter flytte til en anden måde at bygge applikationer på."
For at sikre, at Kubernetes ville fungere godt i forhold til dets behov, byggede GitHub-teamet et præproduktions-staging-miljø kaldet "review lab."
"Vi var i stand til at præsentere noget for ingeniører internt, som gjorde det muligt for os på en måde næsten at crowdsource valideringen af denne platforms funktionalitet og vores brug af den," forklarede Newland. "Det eksperimenterende miljø med lav risiko var virkelig virkningsfuldt og gjorde det muligt for folk at bevæge sig hurtigt med et high stakes-projektet, fordi de på en måde havde dette isolerede miljø, hvor eksplosionsradiusen for ethvert problem var begrænset."
Efter at have set de positive resultater af denne migrering, arbejder GitHub på at give sine ingeniører en måde at implementere nye applikationer til Kubernetes på en selvbetjeningsmåde. Allerede, sagde Newland, "vi har set en stigning i hastigheden af innovation og nye ideer og softwareprojekter, der ikke kun eksisterer og fungerer på din bærbare computer, men eksisterer og fungerer i produktionen."
Relateret dækning:
- Linux Foundation tilbyder gratis introduktion til Kubernetes-klassen
- Amazon hopper med på Kubernetes-vognen
- GitHub open sources OctoDNS, nyt værktøj til styring af DNS-poster