Des réunions d'administrateurs système Sysadminka ont lieu à Chelyabinsk, et lors de la dernière, j'ai fait un rapport sur notre solution pour exécuter des applications sur 1C-Bitrix dans Kubernetes.
Bitrix, Kubernetes, Ceph – un bon mélange ?
Je vais vous expliquer comment nous avons élaboré une solution efficace à partir de tout cela.
Allons-y!
La rencontre a eu lieu le 18 avril à Chelyabinsk. Vous pouvez en savoir plus sur nos rencontres sur et regarde .
Si vous souhaitez venir nous voir avec un rapport ou en tant qu'auditeur, bienvenue, écrivez à [email protected] et sur Telegram t.me/vadimisakanov.
Mon rapport
Solution "Bitrix dans Kubernetes, version Southbridge 1.0"
Je parlerai de notre solution au format « pour les nuls en Kubernetes », comme cela a été fait lors du meetup. Mais je suppose que vous connaissez les mots Bitrix, Docker, Kubernetes, Ceph au moins au niveau des articles sur Wikipédia.
Qu'est-ce qui est prêt à l'emploi à propos de Bitrix dans Kubernetes ?
Il existe très peu d'informations sur l'ensemble d'Internet sur le fonctionnement des applications Bitrix dans Kubernetes.
Je n'ai trouvé que ces matériaux :
Rapport d'Alexander Serbul, 1C-Bitrix et Anton Tuzlukov de Qsoft :
Je recommande de l'écouter.
Développer votre propre solution à partir de l'utilisateur .
Trouvé plus .
Aaand... en fait, c'est tout.
Je vous préviens, nous n'avons pas vérifié la qualité des solutions dans les liens ci-dessus :)
À propos, lors de la préparation de notre solution, j'ai parlé avec Alexander Serbul, puis son rapport n'était pas encore paru, donc dans mes diapositives il y a un élément "Bitrix n'utilise pas Kubernetes".
Mais il existe déjà de nombreuses images Docker prêtes à l'emploi pour exécuter Bitrix dans Docker :
Est-ce suffisant pour créer une solution complète pour Bitrix dans Kubernetes ?
Non. Il y a un grand nombre de problèmes à résoudre.
Quels sont les problèmes avec Bitrix dans Kubernetes ?
Premièrement, les images prêtes à l'emploi de Dockerhub ne conviennent pas à Kubernetes
Si nous voulons créer une architecture de microservices (et nous le faisons habituellement dans Kubernetes), nous devons séparer notre application Kubernetes en conteneurs et demander à chaque conteneur d'exécuter une petite fonction (et de bien le faire). Pourquoi un seul ? Bref, plus c’est simple, plus c’est fiable.
Pour être plus précis, regardez cet article et cette vidéo, veuillez :
Les images Docker dans Dockerhub sont principalement construites sur le principe tout-en-un, nous devions donc toujours créer notre propre vélo et même créer des images à partir de zéro.
Deuxièmement - le code du site est modifié à partir du panneau d'administration
Nous avons créé une nouvelle section sur le site - le code a été mis à jour (un répertoire avec le nom de la nouvelle section a été ajouté).
Si vous modifiiez les propriétés d'un composant depuis le panneau d'administration, le code changeait.
Kubernetes « par défaut » ne peut pas fonctionner avec cela ; les conteneurs doivent être sans état.
Raison : Chaque conteneur (pod) du cluster ne traite qu'une partie du trafic. Si vous modifiez le code dans un seul conteneur (pod), le code sera différent dans différents pods, le site fonctionnera différemment et différentes versions du site seront présentées à différents utilisateurs. Tu ne peux pas vivre comme ça.
Troisièmement : vous devez résoudre le problème du déploiement
Si nous disposons d'un monolithe et d'un serveur « classique », tout est assez simple : nous déployons une nouvelle base de code, migrons la base de données, basculons le trafic vers la nouvelle version du code. La commutation se produit instantanément.
Si nous avons un site dans Kubernetes, découpé en microservices, il y a beaucoup de conteneurs avec du code - oh. Vous devez collecter des conteneurs avec une nouvelle version du code, les déployer à la place des anciennes, migrer correctement la base de données et, idéalement, le faire inaperçu des visiteurs. Heureusement, Kubernetes nous y aide, en prenant en charge tout un tas de types de déploiements différents.
Quatrièmement, vous devez résoudre le problème du stockage des statistiques
Si votre site ne fait « que » 10 Go et que vous le déployez entièrement dans des conteneurs, vous vous retrouverez avec des conteneurs de 10 Go dont le déploiement prend une éternité.
Il faut stocker les parties « les plus lourdes » du chantier en dehors des conteneurs, et la question se pose de savoir comment le faire correctement
Qu'est-ce qui manque à notre solution ?
L'ensemble du code Bitrix n'est pas divisé en microfonctions/microservices (de sorte que l'enregistrement est séparé, le module de boutique en ligne est séparé, etc.). Nous stockons l'intégralité de la base de code dans chaque conteneur.
Nous ne stockons pas non plus la base de données dans Kubernetes (j'ai quand même implémenté des solutions avec une base de données dans Kubernetes pour les environnements de développement, mais pas pour la production).
Les administrateurs du site remarqueront toujours que le site fonctionne sur Kubernetes. La fonction « vérification du système » ne fonctionne pas correctement ; pour modifier le code du site depuis le panneau d'administration, vous devez d'abord cliquer sur le bouton « Je souhaite modifier le code ».
Les problèmes ont été identifiés, la nécessité de mettre en œuvre des microservices a été déterminée, l'objectif est clair : obtenir un système fonctionnel pour exécuter des applications sur Bitrix dans Kubernetes, préservant à la fois les capacités de Bitrix et les avantages de Kubernetes. Commençons la mise en œuvre.
Architecture
Il existe de nombreux pods « fonctionnels » avec un serveur Web (workers).
Un sous avec des tâches cron (un seul est requis).
Une mise à niveau pour modifier le code du site à partir du panneau d'administration (une seule est également requise).
Nous résolvons les questions :
- Où stocker les séances ?
- Où stocker le cache ?
- Où stocker les statistiques, et non placer des gigaoctets de statistiques dans un tas de conteneurs ?
- Comment fonctionnera la base de données ?
Image Docker
Nous commençons par créer une image Docker.
L'option idéale est que nous ayons une image universelle, sur laquelle nous obtenons des pods de travail, des pods avec Crontasks et des pods de mise à niveau.
.
Il comprend nginx, apache/php-fpm (peut être sélectionné lors de la construction), msmtp pour l'envoi de courrier et cron.
Lors de l'assemblage de l'image, l'intégralité de la base de code du site est copiée dans le répertoire /app (à l'exception des parties que nous déplacerons vers un stockage partagé séparé).
Microservices, services
pods de travailleurs :
- Conteneur avec nginx + conteneur apache/php-fpm + msmtp
- Il n'a pas été possible de déplacer msmtp vers un microservice distinct, Bitrix commence à s'indigner de ne pas pouvoir envoyer de courrier directement
- Chaque conteneur possède une base de code complète.
- Interdiction de changer de code dans les conteneurs.
cron sous :
- conteneur avec apache, php, cron
- base de code complète incluse
- interdiction de changer de code dans les conteneurs
mise à niveau sous :
- conteneur nginx + conteneur apache/php-fpm + msmtp
- Il n'y a aucune interdiction de changer le code dans les conteneurs
stockage de session
Stockage du cache Bitrix
Autre chose importante : nous stockons les mots de passe pour nous connecter à tout, de la base de données au courrier, dans les secrets de Kubernetes. Nous obtenons un bonus : les mots de passe ne sont visibles que par ceux à qui nous donnons accès aux secrets, et non par tous ceux qui ont accès à la base de code du projet.
Stockage pour la statique
Vous pouvez utiliser n'importe quoi : ceph, nfs (mais nous ne recommandons pas nfs pour la production), le stockage réseau des fournisseurs de cloud, etc.
Le stockage devra être connecté dans des conteneurs au répertoire /upload/ du site et à d'autres répertoires à contenu statique.
База данных
Pour plus de simplicité, nous vous recommandons de déplacer la base de données en dehors de Kubernetes. La base dans Kubernetes est une tâche complexe distincte, elle rendra le système d'un ordre de grandeur plus complexe.
Stockage des sessions
Nous utilisons Memcached :)
Il gère bien le stockage de session, est clusterisé et est pris en charge « nativement » en tant que session.save_path en php. Un tel système a été testé à plusieurs reprises dans l'architecture monolithique classique, lorsque nous avons construit des clusters avec un grand nombre de serveurs Web. Pour le déploiement, nous utilisons helm.
$ helm install stable/memcached --name sessionphp.ini - ici l'image contient les paramètres de stockage des sessions dans Memcached
Nous avons utilisé des variables d'environnement pour transmettre des données sur les hôtes avec Memcached .
Cela vous permet d'utiliser le même code dans les environnements dev, stage, test, prod (les noms d'hôte memcached qu'ils contiennent seront différents, nous devons donc transmettre un nom d'hôte unique pour les sessions à chaque environnement).
Stockage du cache Bitrix
Nous avons besoin d'un stockage tolérant aux pannes sur lequel tous les pods peuvent écrire et lire.
Nous utilisons également Memcached.
Cette solution est recommandée par Bitrix lui-même.
$ helm install stable/memcached --name cachebitrix/.settings_extra.php - ici, dans Bitrix, il est spécifié où le cache est stocké
Nous utilisons également des variables d'environnement.
Krontaski
Il existe différentes approches pour exécuter Crontasks dans Kubernetes.
- déploiement séparé avec un pod pour exécuter Crontasks
- cronjob pour exécuter des tâches cront (s'il s'agit d'une application Web - avec wget , ou kubectl exec dans l'un des pods de travail, etc.)
- et ainsi de suite
Vous pouvez discuter de la plus correcte, mais dans ce cas, nous avons choisi l'option « déploiement séparé avec des pods pour Crontasks »
Comment c'est fait:
- ajouter des tâches cron via ConfigMap ou via le fichier config/addcron
- dans un cas, nous lançons un conteneur identique au pod de travail + permettons l'exécution de tâches de couronne dans celui-ci
- la même base de code est utilisée, grâce à l'unification, l'assemblage des conteneurs est simple
Quel bien nous obtenons :
- nous avons des Crontasks fonctionnels dans un environnement identique à l'environnement des développeurs (docker)
- Les crontâches n'ont pas besoin d'être « réécrites » pour Kubernetes, elles fonctionnent sous la même forme et dans la même base de code qu'avant
- les tâches cron peuvent être ajoutées par tous les membres de l'équipe disposant de droits de validation sur la branche de production, pas seulement par les administrateurs
Module Southbridge K8SDeploy et édition de code depuis le panneau d'administration
Nous parlions de mise à niveau ci-dessous ?
Comment y diriger le trafic ?
Hourra, nous avons écrit un module pour cela en PHP :) Il s'agit d'un petit module classique pour Bitrix. Il n'est pas encore accessible au public, mais nous prévoyons de l'ouvrir.
Le module est installé comme un module standard dans Bitrix :
Et ça ressemble à ça :
Il vous permet de définir un cookie qui identifie l'administrateur du site et permet à Kubernetes d'envoyer du trafic vers le pod de mise à niveau.
Lorsque les modifications sont terminées, vous devez cliquer sur git push, les modifications du code seront envoyées à git, puis le système construira une image avec une nouvelle version du code et la « déploiera » sur le cluster, en remplaçant les anciens pods. .
Oui, c'est un peu une béquille, mais en même temps, nous maintenons l'architecture des microservices et n'enlevons pas aux utilisateurs de Bitrix leur opportunité préférée de corriger le code depuis le panneau d'administration. En fin de compte, c'est une option : vous pouvez résoudre le problème de l'édition du code d'une manière différente.
Tableau de barre
Pour créer des applications sur Kubernetes, nous utilisons généralement le gestionnaire de packages Helm.
Pour notre solution Bitrix dans Kubernetes, Sergey Bondarev, notre principal administrateur système, a rédigé une charte Helm spéciale.
Il crée des pods Worker, Ugrade et Cron, configure les entrées, les services et transfère les variables des secrets Kubernetes vers les pods.
Nous stockons le code dans Gitlab et nous exécutons également la version Helm à partir de Gitlab.
Bref, ça ressemble à ça
$ helm upgrade --install project .helm --set image=registrygitlab.local/k8s/bitrix -f .helm/values.yaml --wait --timeout 300 --debug --tiller-namespace=productionHelm vous permet également d'effectuer une restauration « transparente » si soudainement quelque chose ne va pas pendant le déploiement. C'est bien quand on n'est pas paniqué « corrigez le code via FTP parce que la prod est tombée », mais Kubernetes le fait automatiquement, et sans temps d'arrêt.
Déployer
Oui, nous sommes fans de Gitlab & Gitlab CI, nous les utilisons :)
Lors de la validation dans Gitlab dans le référentiel du projet, Gitlab lance un pipeline qui déploie une nouvelle version de l'environnement.
Étapes:
- build (création d'une nouvelle image Docker)
- tester (tester)
- nettoyer (supprimer l'environnement de test)
- push (nous l'envoyons au registre Docker)
- déployer (nous déployons l'application sur Kubernetes via Helm).
Hourra, c'est prêt, mettons-le en œuvre !
Eh bien, ou posez des questions s'il y en a.
Alors qu'est ce qu'on a fait
D'un point de vue technique :
- Bitrix dockerisé ;
- « couper » Bitrix en conteneurs, dont chacun remplit un minimum de fonctions ;
- atteint l'état apatride des conteneurs ;
- résolu le problème de la mise à jour de Bitrix dans Kubernetes ;
- toutes les fonctions Bitrix ont continué à fonctionner (presque toutes) ;
- Nous avons travaillé sur le déploiement sur Kubernetes et le rollback entre les versions.
D'un point de vue commercial :
- tolérance aux pannes ;
- Outils Kubernetes (intégration facile avec Gitlab CI, déploiement transparent, etc.) ;
- mots de passe secrets (visibles uniquement par ceux qui ont directement accès aux mots de passe) ;
- Il est pratique de créer des environnements supplémentaires (pour le développement, les tests, etc.) au sein d’une seule infrastructure.
Source: habr.com