{"id":35581,"date":"2019-10-31T22:05:09","date_gmt":"2019-10-31T19:05:09","guid":{"rendered":"https:\/\/prohoster.info\/blog\/southbridge-v-chelyabinske-i-bitriks-v-kubernetes\/"},"modified":"2019-10-31T22:05:09","modified_gmt":"2019-10-31T19:05:09","slug":"southbridge-v-chelyabinske-i-bitriks-v-kubernetes","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/southbridge-v-chelyabinske-i-bitriks-v-kubernetes","title":{"rendered":"Southbridge a Chelyabinsk e Bitrix in Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

A Chelyabinsk si tengono i meet-up degli amministratori di sistema Sysadminka, e nell'ultimo di essi ho tenuto una relazione sulla nostra soluzione per far funzionare le applicazioni su 1C-Bitrix in Kubernetes.<\/p>\n

<\/p>\n

Bitrix, Kubernetes, Ceph: una miscela eccellente?<\/p>\n

<\/p>\n

Vi racconter\u00f2 come abbiamo raccolto tutto questo in una soluzione funzionante.<\/p>\n

<\/p>\n

Andiamo!<\/p>\n

<\/p>\n

\"Southbridge<\/p>\n

<\/a><\/noindex><\/p>\n

Il meet-up si \u00e8 svolto il 18 aprile a Chelyabinsk. Potete leggere dei nostri meet-up su Timepad<\/a><\/noindex> e guardarli su YouTube<\/a><\/noindex>.<\/p>\n

<\/p>\n

Se volete venire da noi con una presentazione o come ascoltatore \u2014 siete i benvenuti, scrivete a vadim.isakanov@gmail.com e su Telegram t.me\/vadimisakanov. <\/p>\n

<\/p>\n

La mia relazione<\/h2>\n

<\/p>\n

\"Southbridge<\/a><\/noindex><\/p>\n

<\/p>\n

Diapositive<\/a><\/noindex><\/p>\n

<\/p>\n

Soluzione 'Bitrix in Kubernetes, versione Southbridge 1.0'<\/h2>\n

<\/p>\n

Parler\u00f2 della nostra soluzione in un formato 'per principianti in Kubernetes', come \u00e8 stato presentato nel meet-up. Ma presumo che conoscete gi\u00e0 i termini Bitrix, Docker, Kubernetes e Ceph, almeno a livello di articoli su Wikipedia.<\/p>\n

<\/p>\n

Cosa c'\u00e8 di gi\u00e0 pronto per Bitrix in Kubernetes?<\/h4>\n

<\/p>\n

Su tutta Internet ci sono pochissime informazioni sul funzionamento delle applicazioni su Bitrix in Kubernetes.
\nHo trovato solo questi materiali:<\/p>\n

<\/p>\n

Relazione di Aleksandr Serbul, 1C-Bitrix, e Anton Tuzlukov di Qsoft: <\/p>\n

\n

\r\n \"Guarda\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

Ve lo consiglio.<\/p>\n

<\/p>\n

Sviluppo di una propria soluzione dal punto di vista dell'utente serkyron<\/a><\/noindex> In questo settore sono giunti anche i sistemi di intelligenza artificiale. Algoritmi intelligenti prevedono i guasti dei server analizzando il loro 'comportamento'. Ad esempio, l'azienda Litbit<\/a><\/noindex>.
\nHo trovato anche questa soluzione<\/a><\/noindex>.<\/p>\n

<\/p>\n

E insomma, tutto qui.<\/p>\n

<\/p>\n

Avviso che non abbiamo verificato la qualit\u00e0 delle soluzioni nei link sopra \ud83d\ude42
\nA proposito, durante la preparazione della nostra soluzione ho parlato con Aleksandr Serbul, e all'epoca la sua relazione non era ancora disponibile, quindi nelle mie slide c'\u00e8 un punto 'Bitrix non utilizza Kubernetes'.<\/p>\n

<\/p>\n

Tuttavia, esistono gi\u00e0 molti immagini Docker pronte per utilizzare Bitrix in Docker: https:\/\/hub.docker.com\/search?q=bitrix&type=image<\/a><\/noindex> <\/p>\n

<\/p>\n

\u00c8 sufficiente questo per creare una soluzione completa per Bitrix in Kubernetes?
\nNo. Ci sono molti problemi da risolvere.<\/p>\n

<\/p>\n

Quali sono i problemi con Bitrix in Kubernetes?<\/h4>\n

<\/p>\n

Il primo: le immagini pronte da Dockerhub non sono adatte per Kubernetes.<\/strong><\/p>\n

<\/p>\n

Se vogliamo costruire un'architettura a microservizi (e in Kubernetes di solito vogliamo farlo), l'applicazione in Kubernetes deve essere divisa in contenitori, e bisogna garantirsi che ogni contenitore svolga una piccola funzione (e la faccia bene). Perch\u00e9 solo una? In breve, pi\u00f9 \u00e8 semplice, pi\u00f9 \u00e8 affidabile.
\nSe volete approfondire, per favore guardate questo articolo e video: https:\/\/habr.com\/ru\/company\/southbridge\/blog\/426637\/<\/a><\/noindex> <\/p>\n

<\/p>\n

Le immagini Docker su Dockerhub sono principalmente costruite secondo il principio 'tutto in uno', quindi abbiamo dovuto comunque inventare la nostra bicicletta e persino creare le immagini da zero.<\/p>\n

<\/p>\n

Il secondo: il codice del sito viene modificato dalla dashboard di amministrazione.<\/strong><\/p>\n

<\/p>\n

Abbiamo creato una nuova sezione sul sito: il codice \u00e8 stato aggiornato (\u00e8 stata aggiunta una directory con il nome della nuova sezione).<\/p>\n

<\/p>\n

Abbiamo modificato le propriet\u00e0 del componente dal pannello di amministrazione: il codice \u00e8 cambiato.<\/p>\n

<\/p>\n

Kubernetes \u00abdi default\u00bb non sa lavorare cos\u00ec, i contenitori devono essere immutabili (Stateless).<\/p>\n

<\/p>\n

Motivo: ogni contenitore (pod) nel cluster gestisce solo una parte del traffico. Se si modifica il codice solo in un contenitore (pod), il codice sar\u00e0 diverso in diversi pod, il sito funzioner\u00e0 in modo diverso, diversi utenti vedranno diverse versioni del sito. Non si pu\u00f2 vivere cos\u00ec.<\/p>\n

<\/p>\n

Terzo: bisogna risolvere la questione del deployment.<\/strong><\/p>\n

<\/p>\n

Se abbiamo un monolite e un server \u00abclassico\u00bb, \u00e8 tutto molto semplice: implementiamo una nuova base di codice, eseguiamo la migrazione del DB, dirottiamo il traffico sulla nuova versione del codice. Il passaggio avviene istantaneamente.
\nSe il nostro sito \u00e8 in Kubernetes, suddiviso in microservizi, i contenitori con il codice sono molti: oh. Bisogna assemblare i contenitori con la nuova versione del codice, deployarli al posto dei precedenti, eseguire correttamente la migrazione del DB, e idealmente farlo in modo invisibile per i visitatori. Per fortuna, in questo Kubernetes ci aiuta, supportando una moltitudine di diversi tipi di deployment.<\/p>\n

<\/p>\n

Quarto: bisogna risolvere la questione dell'archiviazione della staticit\u00e0.<\/strong><\/p>\n

<\/p>\n

Se il tuo sito pesa \u00absolo\u00bb 10 gigabyte e decidi di deployarlo completamente in contenitori, otterrai contenitori dal peso di 10 gigabyte, che verranno deployati per un'eternit\u00e0.
\n\u00c8 necessario conservare le parti \u00abpi\u00f9 pesanti\u00bb del sito al di fuori dei contenitori, e sorge la questione di come farlo correttamente.<\/p>\n

<\/p>\n

Cosa non \u00e8 presente nella nostra soluzione.<\/h4>\n

<\/p>\n

Tutto il codice di Bitrix non \u00e8 suddiviso in microfunzioni\/microservizi (in modo tale che la registrazione sia separata, il modulo del negozio online separato, ecc.). Conserviamo l'intera base di codice in ciascun contenitore.<\/p>\n

<\/p>\n

Non archiviamo il database in Kubernetes (anche se ho implementato soluzioni con il database in Kubernetes per gli ambienti di sviluppo, ma non per la produzione).<\/p>\n

<\/p>\n

Gli amministratori del sito noteranno che il sito funziona in Kubernetes. La funzione \u00abverifica sistema\u00bb non funziona correttamente, per modificare il codice del sito dal pannello di amministrazione \u00e8 necessario prima cliccare sul pulsante \u00abvoglio modificare il codice\u00bb.<\/p>\n

<\/p>\n

Abbiamo identificato i problemi e la necessit\u00e0 di implementare la microservizi. L'obiettivo \u00e8 chiaro: creare un sistema operativo per le applicazioni su Bitrix in Kubernetes, mantenendo sia le funzionalit\u00e0 di Bitrix che i vantaggi di Kubernetes. Iniziamo l'implementazione.<\/p>\n

<\/p>\n

Architettura<\/h4>\n

<\/p>\n

Molti \"worker\" pod con server web.
\nUn pod con attivit\u00e0 cron (obbligatorio solo uno).
\nUn pod di aggiornamento per modificare il codice del sito dalla dashboard (anche questo soltanto uno \u00e8 obbligatorio).<\/p>\n

<\/p>\n

\"Southbridge<\/p>\n

<\/p>\n

Affrontiamo le seguenti questioni:<\/p>\n

<\/p>\n