{"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\/et\/blog\/administrirovanie\/nashi-vyvody-za-god-migraczii-gitlab-com-na-kubernetes","title":{"rendered":"Meie j\u00e4reldused GitLab.com migratsiooni aastast Kubernetesile.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

M\u00e4rkus t\u00f5lke kohta.<\/b>: Kubernetes'i rakendamine GitLab'is peetakse \u00fcheks kahest peamisest tegurist, mis soodustavad ettev\u00f5tte kasvu. Siiski, kuni hiljutise ajani oli GitLab.com'i veebiteenuse infrastruktuur rajatud virtuaalmasinatele ning migratsioon K8s-i algas alles umbes aasta tagasi ning pole siiani l\u00f5ppenud. Oleme r\u00f5\u00f5msad, et saame esitleda t\u00f5lget GitLabi SRE-inseneri hiljutisest artiklist selle kohta, kuidas see k\u00e4ib ja milliseid j\u00e4reldusi teevad projekti kaasavad insenerid.<\/i><\/p>\n

\"Meie
\n
\nJuba aasta olen pidanud meie infrastruktuuri osakond k\u00f5iki teenuseid, mis t\u00f6\u00f6tavad GitLab.com-is, Kubernetesesse \u00fcle viima. Selle aja jooksul oleme silmitsi seisnud probleemidega, mis on seotud mitte ainult teenuste liikumisega Kubernetesesse, vaid ka h\u00fcbriidse juurutamise haldamisega \u00fclemineku ajal. K\u00e4esolevas artiklis r\u00e4\u00e4gime v\u00e4\u00e4rtuslikest \u00f5ppetundidest, mida oleme saanud.<\/a><\/noindex><\/p>\n

Alates GitLab.com'i loomisest t\u00f6\u00f6tasid selle serverid pilves virtuaalmasinatel. Nende virtuaalmasinate \u00fcle haldab Chef ning nende paigaldamine toimub meie ametliku Linuxi paketi<\/a><\/noindex>. Installeerimisstrateegia<\/a><\/noindex> rakenduse uuendamiseks seisneb serverite pargi koordineeritud j\u00e4rjestikku ajakohastamises CI-pipeline'i abil. See meetod \u2014 kuigi aeglane ja veidi igav<\/a><\/noindex> \u2014 garanteerib, et GitLab.com rakendab samu paigaldus- ja konfigureerimismeetodeid nagu iseseisvad (self-managed)<\/i> GitLabi paigaldused, mis kasutavad selleks meie Linuxi pakette.<\/p>\n

Kasutame seda meetodit, kuna on \u00e4\u00e4rmiselt oluline tunda omal nahal kogemusi ja r\u00f5\u00f5me, millega kogukonna tavalised liikmed silmitsi seisavad, kui nad installivad ja seadistavad oma GitLabi koopiad. See l\u00e4henemine toimis m\u00f5nda aega h\u00e4sti, kuid kui projektide arv GitLab'is \u00fcletas 10 miljoni piiri, m\u00f5istsime, et see ei rahulda enam meie vajadusi skaleerimise ja deploy'imise osas.<\/p>\n

Esimesed sammud Kubernetes'i ja cloud-native GitLab'i suunas<\/h2>\n

\n2017. aastal loodi projekt GitLab Charts<\/a><\/noindex> GitLabi ettevalmistamiseks pilves kasutamiseks ja selleks, et anda kasutajatele v\u00f5imalus installida GitLab Kubernetesi klastritesse. Siis teadsime, et GitLabi \u00fcleviimine Kubernetesesse suurendab SaaS-platvormi skaleerimisv\u00f5imalusi, lihtsustab kasutuselev\u00f5tteid ja parandab arvutusressursside efektiivsust. Samal ajal s\u00f5ltus palju meie rakenduse funktsioone monteeritud NFS-osade kasutamisest, mis aeglustas \u00fcleminekut virtuaalmasinatelt.<\/p>\n

P\u00fc\u00fcd cloud native ja Kubernetesi suunas v\u00f5imaldas meie inseneridel planeerida j\u00e4rkj\u00e4rgulist \u00fcleminekut, mil me loobusime m\u00f5nest rakenduse s\u00f5ltuvusest v\u00f5rguhoiust, j\u00e4tkates samal ajal uute funktsioonide arendamist. Alates sellest ajast, kui me hakkasime migratsiooni planeerima 2019. suvel, on paljusid neist piirangutest eradud ja GitLab.com'i \u00fcleviimine Kubernetesesse k\u00e4ib n\u00fc\u00fcd t\u00e4ie hooga!<\/p>\n

GitLab.com-i t\u00f6\u00f6mudeli erip\u00e4rad Kuberneteses<\/h2>\n

\nGitLab.comi jaoks kasutame \u00fchte piirkondlikku GKE klastri, mis haldab kogu rakenduse liiklust. Et v\u00e4hendada migratsiooni keerukust (mis on niigi keeruline), keskendume teenustele, mis ei s\u00f5ltu kohalikest salvestustest v\u00f5i NFS-ost. GitLab.com kasutab peamiselt monoliitset koodibaasi Railsiga ja suuname liiklust vastavalt t\u00f6\u00f6koormuse omadustele erinevatesse l\u00f5pp-punktidesse, mis on isoleeritud oma node\u2019ide basseinidesse.<\/p>\n

Eesliidete puhul jagatakse need t\u00fc\u00fcbid veebip\u00e4ringuteks, API, Git SSH\/HTTPS ja Registery jaoks. Tagapool jagame t\u00f6\u00f6\u00fclesandeid reas erinevate omaduste j\u00e4rgi s\u00f5ltuvalt eelnevalt m\u00e4\u00e4ratud ressursipiirangutele<\/a><\/noindex>, mis v\u00f5imaldavad meil seada teenindustaseme eesm\u00e4rke (Service-Level Objectives, SLOs) erinevate koormuste jaoks.<\/p>\n

K\u00f5ik need GitLab.com teenused on seadistatud muudetud Helm'i kaardi abil. Konfiguratsioon toimub alakaardil, mis v\u00f5ivad olla valikuliselt aktiveeritud, kui me j\u00e4rk-j\u00e4rgult viime teenused klastrisse. Isegi arvestades, et on otsustatud mitte kaasata m\u00f5ned meie stateful-teenused, nagu Redis, Postgres, GitLab Pages ja Gitaly, v\u00f5imaldab Kubernetes radikaalselt v\u00e4hendada Chef'i haldavat VM-i arvu.<\/p>\n

Kubernetes'i l\u00e4bipaistvus ja konfiguratsiooni haldamine<\/h2>\n

\nK\u00f5ik seaded hallatakse GitLab-i enda poolt. Selleks kasutatakse kolme konfiguratsiooniprojekti, mis p\u00f5hinevad Terraformil ja Helm\u2019il. P\u00fc\u00fcame k\u00f5ikjal, kus v\u00f5imalik, kasutada GitLab-i, et k\u00e4ivitada GitLab-i, kuid operatiivsete \u00fclesannete jaoks t\u00f6\u00f6tab meil eraldi GitLab-i installatsioon. See on vajalik, et mitte s\u00f5ltuda GitLab.com-i k\u00e4ttesaadavusest GitLab.com-i juurutuste ja v\u00e4rskenduste tegemisel.<\/p>\n

Kuigi meie Kubernetes klastrite torujuhtmed t\u00f6\u00f6tavad eraldi GitLabi installatsioonil, on koodirepositooriumidel peeglid, mis on avalikult saadaval j\u00e4rgmistel aadressidel:<\/p>\n