{"id":94977,"date":"2020-09-24T07:43:00","date_gmt":"2020-09-24T05:43:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/nashi-vyvody-za-god-migraczii-gitlab-com-na-kubernetes"},"modified":"2020-09-24T07:43:00","modified_gmt":"2020-09-24T05:43:00","slug":"nashi-vyvody-za-god-migraczii-gitlab-com-na-kubernetes","status":"publish","type":"post","link":"https:\/\/prohoster.info\/hr\/blog\/administrirovanie\/nashi-vyvody-za-god-migraczii-gitlab-com-na-kubernetes","title":{"rendered":"Na\u0161i zaklju\u010dci nakon godine migracije GitLab.com na Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Napomena za prijevod.<\/b>: adaptacija Kubernetes u GitLabu smatra se jednim od dva glavna faktora koji pridonose rastu tvrtke. Me\u0111utim, do nedavno je infrastruktura online servisa GitLab.com bila izgra\u0111ena na virtualnim ma\u0161inama, a migracija u K8s, koja jo\u0161 uvijek nije zavr\u0161ena, zapo\u010dela je prije otprilike godine. U\u017eivajte u prijevodu nedavne \u010dlanka SRE in\u017eenjera GitLaba o tome kako sve to izgleda i koje zaklju\u010dke donose in\u017eenjeri uklju\u010deni u projekt.<\/i><\/p>\n

\"Na\u0161i
\n
\nVe\u0107 gotovo godinu dana na\u0161e infrastrukturno odjeljenje radi na migraciji svih usluga s GitLab.com na Kubernetes. Tijekom tog vremena suo\u010dili smo se s problemima vezanim ne samo za premje\u0161tanje usluga u Kubernetes, ve\u0107 i za upravljanje hibridnim raspore\u0111ivanjem tijekom prijelaza. O vrijednim lekcijama koje smo nau\u010dili bit \u0107e govora u ovom \u010dlanku.<\/a><\/noindex><\/p>\n

Od samog po\u010detka GitLab.com njegovi su serveri radili u oblaku na virtualnim ma\u0161inama. Ove virtualne ma\u0161ine upravlja Chef, a njihova instalacija se vr\u0161i pomo\u0107u na\u0161eg slu\u017ebenog Linux paketa<\/a><\/noindex>. Strategija razmjene<\/a><\/noindex> za slu\u010daj da je potrebno a\u017eurirati aplikaciju, sastoji se u jednostavnom a\u017euriranju parka servera koordiniranim uzastopnim redom pomo\u0107u CI pipelinea. Ova metoda \u2014 iako spora i pomalo dosadna<\/a><\/noindex> \u2014 jam\u010di da GitLab.com primjenjuje iste metode instalacije i konfiguracije kao i korisnici samostalnih (self-managed)<\/i> instalacija GitLaba, koriste\u0107i za to na\u0161e Linux pakete.<\/p>\n

Koristimo ovu metodu jer je izuzetno va\u017eno iskusiti sve brige i radosti koje prolaze obi\u010dni \u010dlanovi zajednice kada instaliraju i postavljaju svoje kopije GitLaba. Ovaj pristup dobro je funkcionirao tijekom odre\u0111enog vremena, no kada je broj projekata na GitLabu pre\u0161ao 10 milijuna, shvatili smo da vi\u0161e ne zadovoljava na\u0161e potrebe za skaliranjem i implementacijom.<\/p>\n

Prvi koraci ka Kubernetes i cloud-native GitLab<\/h2>\n

\nU 2017. godini pokrenut je projekt GitLab Charts<\/a><\/noindex> za pripremu GitLaba za implementaciju u oblaku, kao i za pru\u017eanje korisnicima mogu\u0107nosti instalacije GitLaba u Kubernetes klastere. Tada smo znali da \u0107e premje\u0161tanje GitLaba u Kubernetes pove\u0107ati mogu\u0107nosti skaliranja SaaS platforme, pojednostaviti implementacije i pove\u0107ati efikasnost kori\u0161tenja ra\u010dunalnih resursa. U isto vrijeme, mnoge funkcije na\u0161e aplikacije su ovisile o montiranim NFS particijama, \u0161to je usporavalo prelazak sa virtualnih ma\u0161ina.<\/p>\n

Te\u017enja ka cloud native i Kubernetes omogu\u0107ila je na\u0161im in\u017eenjerima da planiraju postepeni prelazak, tijekom kojeg smo se odrekli nekih zavisnosti aplikacije od umre\u017eenih skladi\u0161ta, istovremeno nastavljaju\u0107i s razvojem novih funkcija. Otkako smo zapo\u010deli s planiranjem migracije ljeta 2019., mnoga od tih ograni\u010denja su otklonjena, a proces prelaska GitLab.com na Kubernetes sada te\u010de punom brzinom!<\/p>\n

Karakteristike rada GitLab.com u Kubernetesu<\/h2>\n

\nZa GitLab.com koristimo jedinstveni regionalni GKE klaster koji obra\u0111uje sav promet aplikacije. Kako bismo umanjili slo\u017eenost (ionako komplicirane) migracije, usredoto\u010dujemo se na usluge koje ne ovise o lokalnom pohranjivanju ili NFS-u. GitLab.com uglavnom koristi monolitnu kodnu bazu na Rails-u, a promet usmjeravamo prema razli\u010ditim endpoint-ima, izoliranim u vlastitim skupinama \u010dvorova, ovisno o karakteristikama radnog optere\u0107enja.<\/p>\n

U slu\u010daju frontend-a, ovi tipovi dijele se na zahtjeve za web, API, Git SSH\/HTTPS i Registry. U slu\u010daju backend-a, razdvajamo poslove u redu prema raznim karakteristikama ovisno o predodre\u0111enim granicama resursa<\/a><\/noindex>, \u0161to nam omogu\u0107ava postavljanje ciljanih metrika razine usluge (Service-Level Objectives, SLOs) za razli\u010dita optere\u0107enja.<\/p>\n

Sve te usluge GitLab.com su konfigurirane pomo\u0107u nemodificiranog Helm chart-a GitLab. Konfiguracija se provodi u subchartovima koji se mogu selektivno uklju\u010divati kako postepeno premje\u0161tamo usluge u klaster. \u010cak i uz ulaganje da se ne uklju\u010de u migraciju neki od na\u0161ih stateful usluga, kao \u0161to su Redis, Postgres, GitLab Pages i Gitaly, kori\u0161tenje Kubernetes omogu\u0107ava radikalno smanjenje broja VM-ova kojima trenutno upravlja Chef.<\/p>\n

Transparentnost i upravljanje konfiguracijom Kubernetes<\/h2>\n

\nSve postavke upravlja sam GitLab. Za to se koriste tri konfiguracijska projekta temeljena na Terraformu i Helmu. Trudimo se posvuda koristiti sam GitLab za pokretanje GitLab-a, ali za operativne zadatke imamo odvojenu instalaciju GitLab-a. Ona je potrebna da bismo bili neovisni o dostupnosti GitLab.com tijekom provo\u0111enja raspore\u0111ivanja i a\u017euriranja GitLab.com.<\/p>\n

Iako na\u0161i paketi za Kubernetes klaster rade na zasebnoj instalaciji GitLab-a, repozitoriji koda imaju zrcala, javno dostupna na sljede\u0107im adresama:<\/p>\n