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.
Bitrix, Kubernetes, Ceph — una combinazione perfetta?
Vi racconterò come abbiamo assemblato una soluzione funzionante da tutto ciò.
Andiamo!
Il meetup si è svolto il 18 aprile a Chelyabinsk. Potete leggere di più sui nostri meetup in e guardarli su .
Se volete venire a farci una presentazione o come ascoltatore — siete i benvenuti, scrivete a vadim.isakanov@gmail.com e su Telegram t.me/vadimisakanov.
La mia presentazione
Soluzione 'Bitrix in Kubernetes, versione Southbridge 1.0'
Parlerò della nostra soluzione in un formato 'per principianti in Kubernetes', come è stato fatto nel meetup. Suppongo però che le parole Bitrix, Docker, Kubernetes, Ceph vi siano familiari, almeno a livello di articoli di Wikipedia.
Cosa c'è di pronto riguardo a Bitrix in Kubernetes?
In tutta internet c'è pochissima informazione sul funzionamento delle applicazioni Bitrix in Kubernetes.
Ho trovato solo questi materiali:
Presentazione di Aleksandr Serbul, 1C-Bitrix, e Anton Tuzlukov di Qsoft:
Consiglio di ascoltarlo.
Sviluppo di una soluzione personalizzata da un utente .
Ho trovato anche .
E… in effetti, è tutto.
Avviso che non abbiamo controllato la qualità delle soluzioni linkate sopra 🙂
A proposito, per preparare la nostra soluzione ho parlato con Alexander Serbul, il cui intervento non era ancora disponibile, quindi nelle mie diapositive c'è un punto che afferma «Bitrix non usa Kubernetes».
Tuttavia, ci sono già molti immagini Docker pronte per l'uso con Bitrix in Docker:
È sufficiente per creare una soluzione completa per Bitrix in Kubernetes?
No. Ci sono molteplici problemi da risolvere.
Quali sono i problemi con Bitrix in Kubernetes?
Il primo: le immagini pronte da Dockerhub non sono adatte per Kubernetes.
Se vogliamo costruire un'architettura a microservizi (ed è ciò 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é solo una? In breve, più è semplice, più è affidabile.
Se vuoi approfondire, ti invito a guardare questo articolo e video:
Le immagini Docker su Dockerhub sono per lo più costruite sul principio «tutto in uno», quindi abbiamo dovuto comunque costruire il nostro sistema e addirittura creare le immagini da zero.
Il secondo: il codice del sito viene modificato dalla pannello di amministrazione.
Abbiamo creato una nuova sezione sul sito — il codice è stato aggiornato (è stata aggiunta una directory con il nome della nuova sezione).
Sono state modificate le proprietà del componente dal pannello di amministrazione — il codice è cambiato.
Kubernetes non sa gestire questo ‘per impostazione predefinita’, i container devono essere immutabili (Stateless).
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à diverso, il sito funzionerà in modo diverso e a utenti diversi verranno mostrate versioni diverse del sito. Non è sostenibile.
Terzo — bisogna affrontare la questione del deployment.
Se abbiamo un monolite e un singolo server ‘classico’, tutto è 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.
Se abbiamo un sito in Kubernetes, suddiviso in microservizi, con molti container di codice — 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.
La quarta — è necessario affrontare la questione dello storage della statica
Se il tuo sito occupa "solo" 10 gigabyte e lo distribuisci interamente in contenitori, otterrai contenitori da 10 gigabyte che verranno distribuiti all'infinito.
È necessario memorizzare le parti più "pesanti" del sito al di fuori dei contenitori, e si pone la questione su come farlo correttamente
Cosa non è incluso nella nostra soluzione
Tutto il codice di Bitrix non è suddiviso in microfunzioni/microservizi (in modo che la registrazione sia separata, il modulo del negozio online separato, ecc.). L'intero codice sorgente è conservato in ogni contenitore nella sua interezza.
Non memorizziamo il database in Kubernetes (ho realizzato soluzioni con il database in Kubernetes per gli ambienti di sviluppo, ma non per la produzione).
Gli amministratori del sito noteranno che il sito è in esecuzione su Kubernetes. La funzione "controllo del sistema" non funziona correttamente e per modificare il codice del sito dalla dashboard di amministrazione è necessario prima premere il pulsante "voglio modificare il codice".
Abbiamo definito i problemi e la necessità di implementare la microservizialità; l'obiettivo è chiaro: creare un sistema funzionante per le applicazioni su Bitrix in Kubernetes, mantenendo sia le funzionalità di Bitrix che i vantaggi di Kubernetes. Iniziamo l'implementazione.
Architettura
Molti pod 'operativi' con server web (worker).
Un pod con cron job (obbligatoriamente solo uno).
Un pod di upgrade per modificare il codice del sito dal pannello di amministrazione (anche questo obbligatoriamente solo uno).
Affrontiamo le questioni:
- Dove conservare le sessioni?
- Dove conservare la cache?
- Dove conservare la staticità; non possiamo posizionare gigabyte di staticità in una miriade di contenitori?
- Come funzionerà il database?
Immagine Docker
Iniziamo con la creazione dell'immagine Docker.
L'opzione ideale è avere un'unica immagine universale, da cui otteniamo sia i pod worker che i pod con i cron job, e i pod di upgrade.
.
Include nginx, apache/php-fpm (puoi scegliere durante la costruzione), msmtp per l'invio della posta e cron.
Durante la creazione dell'immagine, l'intera base di codice del sito viene copiata nella directory /app (eccetto le parti che sposteremo in uno storage condiviso separato).
Microservizialità, servizi
Pod worker:
- Contenitore con nginx + contenitore apache/php-fpm + msmtp
- Non siamo riusciti a estrarre msmtp in un microservizio separato, Bitrix inizia a lamentarsi che non può inviare email direttamente.
- Ogni container ha l'intero codice sorgente.
- Divieto di modifica del codice nei container.
cron sotto:
- container con apache, php, cron
- viene fornito con l'intero codice sorgente
- divieto di modifica del codice nei container
upgrade sotto:
- container con nginx + container apache/php-fpm + msmtp
- non ci sono divieti di modifica del codice nei container
archivio delle sessioni
archivio della cache di Bitrix
È importante: le password per connettersi a tutto, dal database all'email, sono conservate nei segreti di Kubernetes. Otteniamo un vantaggio, le password sono visibili solo a chi diamo accesso ai segreti, non a tutti coloro che hanno accesso al codice sorgente del progetto.
Archiviazione per la staticità
Si può usare qualsiasi cosa: ceph, nfs (ma non raccomandiamo nfs per la produzione), storage di rete dai fornitori 'cloud', ecc.
Lo storage dovrà essere collegato nei container nella directory /upload/ del sito e nelle altre directory della staticità.
Database
Per semplicità, raccomandiamo di estrarre il database al di fuori di Kubernetes. Un database in Kubernetes è un compito complicato, renderà lo schema molto più complesso.
Archivio delle sessioni
Utilizziamo memcached 🙂
Gestisce bene lo storage delle sessioni, si clusterizza, ed è supportato «nativamente» come session.save_path in php. Questo sistema è stato collaudato molte volte anche nell'architettura monolitica classica, quando creavamo cluster con un gran numero di web server. Per il deployment utilizziamo helm.
$ helm install stable/memcached --name sessionphp.ini — qui sono impostate le configurazioni per lo storage delle sessioni in memcached
Abbiamo utilizzato le Environment Variables per trasmettere i dati sugli host di memcached .
Questo consente di utilizzare lo stesso codice negli ambienti dev, stage, test, prod (i nomi degli host di memcached saranno diversi in essi, quindi per ogni ambiente dobbiamo passare un nome host unico per le sessioni).
Cache storage di Bitrix
Abbiamo bisogno di uno storage resiliente su cui tutti i pod possano scrivere e da cui possano leggere.
Utilizziamo anche memcached.
Questa soluzione è raccomandata dallo stesso Bitrix.
$ helm install stable/memcached --name cachebitrix/.settings_extra.php — qui in Bitrix si specifica dove abbiamo memorizzato la cache
Utilizziamo anche le Environment Variables.
Cron jobs
Ci sono diversi approcci per eseguire cron jobs in Kubernetes.
- un deployment separato con un pod per l'esecuzione dei cron jobs
- cronjob per eseguire cron tasks (se si tratta di un'app web — con wget , oppure kubectl exec all'interno di uno dei pod worker, ecc.)
- ecc.
Si può discutere su quale sia il migliore, ma in questo caso abbiamo scelto l'opzione «deployment separato con pod per i cron tasks»
Come è fatto:
- aggiungiamo i cron tasks tramite ConfigMap o tramite il file config/addcron
- eseguiamo un contenitore in un'unica istanza, identico al pod worker + permettiamo l'esecuzione dei cron tasks in esso
- si utilizza la stessa base di codice, grazie all'unificazione, la creazione del contenitore è semplice
Cosa otteniamo di positivo:
- abbiamo cron tasks funzionanti in un ambiente identico a quello degli sviluppatori (docker)
- i cron tasks non devono essere «riscritti» per Kubernetes, funzionano nello stesso modo e con la stessa base di codice di prima
- tutti i membri del team con diritti di commit nel ramo di produzione possono aggiungere cron tasks, non solo gli admin
Modulo Southbridge K8SDeploy e modifica del codice dalla pannello amministrativo
Abbiamo parlato dell'upgrade del pod?
E come reindirizzare il traffico lì?
Evvia, abbiamo scritto un modulo per questo in php 🙂 È un piccolo modulo classico per Bitrix. Non è ancora disponibile pubblicamente, ma prevediamo di rilasciarlo.
Il modulo viene installato come un normale modulo in Bitrix:
E appare così:
Permette di impostare i cookie che identificano l'amministratore del sito e consentono a Kubernetes di inviare traffico al pod di aggiornamento.
Quando le modifiche sono complete, bisogna premere git push; le modifiche al codice verranno inviate in git, e successivamente il sistema compilerà un'immagine con la nuova versione del codice e la distribuirà nel cluster, sostituendo i vecchi pod.
Sì, è un po' un workaround, ma in questo modo manteniamo un'architettura a microservizi e non priviamo gli utenti di Bitrix della loro amata possibilità di modificare il codice dall'admin. Dopotutto, questa è solo un'opzione; il problema della modifica del codice può essere risolto in un altro modo.
Helm chart
Per la costruzione di applicazioni in Kubernetes, di solito utilizziamo il gestore di pacchetti Helm.
Per la nostra soluzione Bitrix in Kubernetes, Sergey Bondarev, il nostro principale amministratore di sistema, ha scritto un chart Helm speciale.
Questo si occupa della costruzione di worker, upgrade, cron pod, imposta ingress, servizi e trasferisce variabili dai segreti di Kubernetes ai pod.
Conserviamo il codice in Gitlab e avviamo anche la costruzione di Helm da Gitlab.
In breve, appare così
$ helm upgrade --install project .helm --set image=registrygitlab.local/k8s/bitrix -f .helm/values.yaml --wait --timeout 300 --debug --tiller-namespace=productionHelm offre anche la possibilità di effettuare un rollback "senza soluzione di continuità" nel caso in cui qualcosa vada storto durante il deployment. È bello quando non sei in preda al panico a "correggere il codice via FTP perché la produzione è crollata", ma è Kubernetes a farlo automaticamente, senza downtime.
Deploy
Sì, siamo fan di Gitlab & Gitlab CI, lo utilizziamo 🙂
Durante un commit su Gitlab, nel repository del progetto Gitlab avvia un pipeline che esegue il deployment della nuova versione dell’ambiente.
Fasi:
- build (creiamo una nuova immagine Docker)
- test (eseguiamo i test)
- clean up (eliminiamo l’ambiente di test)
- push (inviamo in Docker registry)
- deploy (deployiamo l’applicazione in Kubernetes tramite Helm).
Ecco fatto, procediamo!
Oppure poniamo delle domande, se ce ne sono.
Quindi, cosa abbiamo fatto
Dal punto di vista tecnico:
- abbiamo dockerizzato Bitrix;
- abbiamo "tagliato" Bitrix in container, ognuno dei quali esegue funzioni minime;
- abbiamo raggiunto lo stato stateless dei container;
- abbiamo risolto il problema dell’aggiornamento di Bitrix in Kubernetes;
- tutte le funzionalità di Bitrix continuano a funzionare (quasi tutte);
- abbiamo gestito il deployment in Kubernetes e il rollback tra le versioni.
Dal punto di vista commerciale:
- alta disponibilità;
- strumenti Kubernetes (integrazione semplice con Gitlab CI, deployment fluido, ecc);
- password nei segreti (visibili solo a coloro a cui è stato direttamente concesso l'accesso alle password);
- è comodo creare ambienti aggiuntivi (per sviluppo, test e altro) all'interno di un'unica infrastruttura.
Fonte: habr.com
