{"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\/it\/blog\/administrirovanie\/nashi-vyvody-za-god-migraczii-gitlab-com-na-kubernetes","title":{"rendered":"Le nostre conclusioni dopo un anno di migrazione di GitLab.com su Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Nota di traduzione.<\/b>: l'adattamento di Kubernetes in GitLab \u00e8 considerato uno dei due principali fattori che contribuiscono alla crescita dell'azienda. Tuttavia, fino a poco tempo fa, l'infrastruttura del servizio online GitLab.com era costruita su macchine virtuali, e solo circa un anno fa \u00e8 iniziata la sua migrazione a K8s, che non \u00e8 ancora terminata. Siamo lieti di presentare la traduzione di un recente articolo di un ingegnere SRE di GitLab su come sta avvenendo questo e quali conclusioni traggono gli ingegneri coinvolti nel progetto.<\/i><\/p>\n

\"Le
\n
\nDa circa un anno, il nostro dipartimento infrastrutturale si occupa della migrazione di tutti i servizi operanti su GitLab.com in Kubernetes. Durante questo periodo, abbiamo affrontato problemi non solo legati al trasferimento dei servizi in Kubernetes, ma anche alla gestione del deployment ibrido durante la transizione. Gli insegnamenti preziosi che abbiamo appreso saranno oggetto di questo articolo.<\/a><\/noindex><\/p>\n

Sin dall'inizio, i server di GitLab.com hanno funzionato nel cloud su macchine virtuali. Queste macchine virtuali sono gestite da Chef, e la loro installazione avviene tramite il nostro pacchetto ufficiale per Linux<\/a><\/noindex>. La strategia di distribuzione<\/a><\/noindex> nel caso in cui sia necessario aggiornare l'applicazione consiste in un semplice aggiornamento del parco server in modo coordinato e sequenziale tramite un pipeline CI. Questo metodo \u2014 sebbene lento e un po' noioso<\/a><\/noindex> \u2014 garantisce che GitLab.com utilizzi gli stessi metodi di installazione e configurazione degli utenti delle installazioni autonome (self-managed)<\/i> di GitLab, utilizzando per questo i nostri pacchetti per Linux.<\/p>\n

Utilizziamo questo metodo poich\u00e9 \u00e8 estremamente importante vivere tutte le gioie e i dolori che i membri della comunit\u00e0 affrontano quando installano e configurano le proprie copie di GitLab. Questo approccio ha funzionato bene per un certo periodo, tuttavia quando il numero di progetti su GitLab ha superato i 10 milioni, abbiamo capito che non soddisfaceva pi\u00f9 le nostre esigenze di scalabilit\u00e0 e distribuzione.<\/p>\n

I primi passi verso Kubernetes e GitLab cloud-native<\/h2>\n

\nNel 2017 \u00e8 stato creato il progetto GitLab Charts<\/a><\/noindex> per preparare GitLab al deployment nel cloud e per dare agli utenti la possibilit\u00e0 di installare GitLab in cluster Kubernetes. Allora sapevamo che il trasferimento di GitLab in Kubernetes avrebbe aumentato le capacit\u00e0 di scalabilit\u00e0 della piattaforma SaaS, semplificato i deployment e migliorato l'efficienza nell'uso delle risorse computazionali. Allo stesso tempo, molte funzionalit\u00e0 della nostra applicazione dipendevano da partizioni NFS montate, il che rallentava il passaggio dalle macchine virtuali.<\/p>\n

L'aspirazione al cloud native e Kubernetes ha permesso ai nostri ingegneri di pianificare una transizione graduale, durante la quale abbiamo ridotto alcune dipendenze dell'applicazione da archiviazioni di rete, continuando a sviluppare nuove funzionalit\u00e0. Da quando abbiamo iniziato a pianificare la migrazione nell'estate del 2019, molte di queste limitazioni sono state eliminate, e il processo di migrazione di GitLab.com su Kubernetes \u00e8 ora a tutto ritmo!<\/p>\n

Caratteristiche del funzionamento di GitLab.com in Kubernetes<\/h2>\n

\nPer GitLab.com utilizziamo un'unica cluster regionale GKE che gestisce tutto il traffico dell'applicazione. Per minimizzare la complessit\u00e0 (gi\u00e0 complessa) della migrazione, ci concentriamo sui servizi che non dipendono da storage locale o NFS. GitLab.com utilizza principalmente una base di codice monolitica su Rails, e indirizziamo il traffico in base alle caratteristiche del carico di lavoro su vari endpoint, isolati in propri pool di nodi.<\/p>\n

Nel caso del frontend, questi tipi si suddividono in richieste a web, API, Git SSH\/HTTPS e Registry. Per quanto riguarda il backend, suddividiamo i job in coda in base a diverse caratteristiche a seconda di limiti di risorse predefiniti<\/a><\/noindex>, che ci consentono di stabilire obiettivi di livello di servizio (Service-Level Objectives, SLOs) per diversi carichi.<\/p>\n

Tutti questi servizi di GitLab.com sono configurati utilizzando un Helm chart di GitLab non modificato. La configurazione avviene tramite subchart, che possono essere selettivamente attivati man mano che trasferiamo gradualmente i servizi nel cluster. Anche se \u00e8 stata presa la decisione di non includere nella migrazione alcuni dei nostri servizi stateful, come Redis, Postgres, GitLab Pages e Gitaly, l'uso di Kubernetes consente di ridurre drasticamente il numero di VM gestite da Chef attualmente.<\/p>\n

Trasparenza e gestione della configurazione di Kubernetes<\/h2>\n

\nTutte le impostazioni sono gestite dallo stesso GitLab. A tal fine, utilizziamo tre progetti di configurazione basati su Terraform e Helm. Cerchiamo di utilizzare GitLab in ogni modo possibile per eseguire GitLab, ma per compiti operativi abbiamo un'installazione separata di GitLab. Questa \u00e8 necessaria per non dipendere dalla disponibilit\u00e0 di GitLab.com durante i deployment e gli aggiornamenti di GitLab.com.<\/p>\n

Sebbene i nostri pipeline per il cluster Kubernetes funzionino su un'installazione separata di GitLab, i repository di codice hanno specchi, accessibili pubblicamente ai seguenti indirizzi:<\/p>\n