{"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 svolgono i meetup degli amministratori di sistema Sysadminka, e all'ultimo di questi ho tenuto una presentazione sulla nostra soluzione per eseguire applicazioni su 1C-Bitrix in Kubernetes.<\/p>\n

<\/p>\n

Bitrix, Kubernetes, Ceph \u2014 una combinazione perfetta?<\/p>\n

<\/p>\n

Vi racconter\u00f2 come abbiamo assemblato una soluzione funzionante da tutto ci\u00f2.<\/p>\n

<\/p>\n

Andiamo!<\/p>\n

<\/p>\n

\"Southbridge<\/p>\n

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

Il meetup si \u00e8 svolto il 18 aprile a Chelyabinsk. Potete leggere di pi\u00f9 sui nostri meetup in Timepad<\/a><\/noindex> e guardarli su YouTube<\/a><\/noindex>.<\/p>\n

<\/p>\n

Se volete venire a farci 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 presentazione<\/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 fatto nel meetup. Suppongo per\u00f2 che le parole Bitrix, Docker, Kubernetes, Ceph vi siano familiari, almeno a livello di articoli di Wikipedia.<\/p>\n

<\/p>\n

Cosa c'\u00e8 di pronto riguardo a Bitrix in Kubernetes?<\/h4>\n

<\/p>\n

In tutta internet c'\u00e8 pochissima informazione sul funzionamento delle applicazioni Bitrix in Kubernetes.
\nHo trovato solo questi materiali:<\/p>\n

<\/p>\n

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

\n

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

Consiglio di ascoltarlo.<\/p>\n

<\/p>\n

Sviluppo di una soluzione personalizzata da un utente serkyron<\/a><\/noindex> su Habr\u00e9<\/a><\/noindex>.
\nHo trovato anche questa soluzione<\/a><\/noindex>.<\/p>\n

<\/p>\n

E\u2026 in effetti, \u00e8 tutto.<\/p>\n

<\/p>\n

Avviso che non abbiamo controllato la qualit\u00e0 delle soluzioni linkate sopra \ud83d\ude42
\nA proposito, per preparare la nostra soluzione ho parlato con Alexander Serbul, il cui intervento non era ancora disponibile, quindi nelle mie diapositive c'\u00e8 un punto che afferma \u00abBitrix non usa Kubernetes\u00bb.<\/p>\n

<\/p>\n

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

<\/p>\n

\u00c8 sufficiente per creare una soluzione completa per Bitrix in Kubernetes?
\nNo. Ci sono molteplici 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 (ed \u00e8 ci\u00f2 che generalmente vogliamo in Kubernetes), l'applicazione in Kubernetes deve essere suddivisa in contenitori e dobbiamo assicurarci che ogni contenitore esegua una piccola funzione (e la esegua bene). Perch\u00e9 solo una? In breve, pi\u00f9 \u00e8 semplice, pi\u00f9 \u00e8 affidabile.
\nSe vuoi approfondire, ti invito a guardare questo articolo e video: https:\/\/habr.com\/ru\/company\/southbridge\/blog\/426637\/<\/a><\/noindex> <\/p>\n

<\/p>\n

Le immagini Docker su Dockerhub sono per lo pi\u00f9 costruite sul principio \u00abtutto in uno\u00bb, quindi abbiamo dovuto comunque costruire il nostro sistema e addirittura creare le immagini da zero.<\/p>\n

<\/p>\n

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

<\/p>\n

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

<\/p>\n

Sono state modificate le propriet\u00e0 del componente dal pannello di amministrazione \u2014 il codice \u00e8 cambiato.<\/p>\n

<\/p>\n

Kubernetes non sa gestire questo \u2018per impostazione predefinita\u2019, i container devono essere immutabili (Stateless).<\/p>\n

<\/p>\n

Motivo: ogni container (pod) nel cluster gestisce solo una parte del traffico. Se si modifica il codice solo in un container (pod), allora nei diversi pod il codice sar\u00e0 diverso, il sito funzioner\u00e0 in modo diverso e a utenti diversi verranno mostrate versioni diverse del sito. Non \u00e8 sostenibile.<\/p>\n

<\/p>\n

Terzo \u2014 bisogna affrontare la questione del deployment.<\/strong><\/p>\n

<\/p>\n

Se abbiamo un monolite e un singolo server \u2018classico\u2019, tutto \u00e8 piuttosto semplice: distribuiamo una nuova base di codice, eseguiamo la migrazione del database, reindirizziamo il traffico alla nuova versione del codice. Il passaggio avviene istantaneamente.
\nSe abbiamo un sito in Kubernetes, suddiviso in microservizi, con molti container di codice \u2014 beh. Dobbiamo costruire i container con la nuova versione del codice, distribuirli al posto dei precedenti, eseguire correttamente la migrazione del database, e idealmente farlo senza che i visitatori se ne accorgano. Fortunatamente, in questo Kubernetes ci aiuta, supportando una serie di diversi tipi di deployment.<\/p>\n

<\/p>\n

La quarta \u2014 \u00e8 necessario affrontare la questione dello storage della statica<\/strong><\/p>\n

<\/p>\n

Se il tuo sito occupa \"solo\" 10 gigabyte e lo distribuisci interamente in contenitori, otterrai contenitori da 10 gigabyte che verranno distribuiti all'infinito.
\n\u00c8 necessario memorizzare le parti pi\u00f9 \"pesanti\" del sito al di fuori dei contenitori, e si pone la questione su come farlo correttamente<\/p>\n

<\/p>\n

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

<\/p>\n

Tutto il codice di Bitrix non \u00e8 suddiviso in microfunzioni\/microservizi (in modo che la registrazione sia separata, il modulo del negozio online separato, ecc.). L'intero codice sorgente \u00e8 conservato in ogni contenitore nella sua interezza.<\/p>\n

<\/p>\n

Non memorizziamo il database in Kubernetes (ho realizzato 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 \u00e8 in esecuzione su Kubernetes. La funzione \"controllo del sistema\" non funziona correttamente e per modificare il codice del sito dalla dashboard di amministrazione \u00e8 necessario prima premere il pulsante \"voglio modificare il codice\".<\/p>\n

<\/p>\n

Abbiamo definito i problemi e la necessit\u00e0 di implementare la microservizialit\u00e0; l'obiettivo \u00e8 chiaro: creare un sistema funzionante 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

\u041c\u043d\u043e\u0433\u043e \u00ab\u0440\u0430\u0431\u043e\u0447\u0438\u0445\u00bb \u043f\u043e\u0434\u043e\u0432 \u0441 \u0432\u0435\u0431\u0441\u0435\u0440\u0432\u0435\u0440\u043e\u043c (worker’\u044b).
\nUn pod con cron job (obbligatoriamente solo uno).
\nUn pod di upgrade per modificare il codice del sito dal pannello di amministrazione (anche questo obbligatoriamente solo uno).<\/p>\n

<\/p>\n

\"Southbridge<\/p>\n

<\/p>\n

Affrontiamo le questioni:<\/p>\n

<\/p>\n