{"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\/nl\/blog\/administrirovanie\/southbridge-v-chelyabinske-i-bitriks-v-kubernetes","title":{"rendered":"Southbridge in Chelyabinsk en Bitrix in Kubernetes","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

In Tsjeljabinsk worden Sysadminka meetups voor systeembeheerders gehouden, en tijdens de laatste heb ik een presentatie gegeven over onze oplossing voor het draaien van applicaties op 1C-Bitrix in Kubernetes.<\/p>\n

<\/p>\n

Bitrix, Kubernetes, Ceph \u2014 een geweldige combinatie?<\/p>\n

<\/p>\n

Ik zal uitleggen hoe we dit alles hebben samengevoegd tot een werkende oplossing.<\/p>\n

<\/p>\n

Laten we beginnen!<\/p>\n

<\/p>\n

\"Southbridge<\/p>\n

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

De meetup vond plaats op 18 april in Tsjeljabinsk. Over onze meetups kun je lezen op Timepad<\/a><\/noindex> en kijken op YouTube<\/a><\/noindex>.<\/p>\n

<\/p>\n

Als je naar ons wilt komen met een presentatie of als luisteraar \u2014 welkom, schrijf naar vadim.isakanov@gmail.com en op Telegram t.me\/vadimisakanov. <\/p>\n

<\/p>\n

Mijn presentatie<\/h2>\n

<\/p>\n

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

<\/p>\n

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

<\/p>\n

Oplossing \u2018Bitrix in Kubernetes, versie Southbridge 1.0\u2019<\/h2>\n

<\/p>\n

Ik zal ons product bespreken in de stijl van \u2018voor leken in Kubernetes\u2019, zoals het tijdens de meetup werd gepresenteerd. Maar ik neem aan dat de woorden Bitrix, Docker, Kubernetes, Ceph wel tenminste op het niveau van Wikipedia-artikelen bij je bekend zijn.<\/p>\n

<\/p>\n

Wat is er \u00fcberhaupt bekend over Bitrix in Kubernetes?<\/h4>\n

<\/p>\n

Er is heel weinig informatie op het internet over het draaien van applicaties op Bitrix in Kubernetes.
\nIk heb alleen de volgende materialen gevonden:<\/p>\n

<\/p>\n

De presentatie van Alexander Serbul, 1C-Bitrix, en Anton Tuzlukov van Qsoft: <\/p>\n

\n

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

Ik raad aan om deze te beluisteren.<\/p>\n

<\/p>\n

Ontwikkeling van een eigen oplossing door een gebruiker serkyron<\/a><\/noindex> Mythen en realiteit<\/a><\/noindex>.
\nIk vond nog zo'n oplossing<\/a><\/noindex>.<\/p>\n

<\/p>\n

Ennn... dat is eigenlijk alles.<\/p>\n

<\/p>\n

Ik waarschuw je, we hebben de kwaliteit van de oplossingen in de bovenstaande links niet gecontroleerd \ud83d\ude42
\nOverigens sprak ik tijdens de voorbereiding van onze oplossing met Alexander Serbul, zijn presentatie was er toen nog niet, daarom zit er een punt in mijn slides dat zegt \u2018Bitrix maakt geen gebruik van Kubernetes\u2019.<\/p>\n

<\/p>\n

Maar er zijn al veel kant-en-klare Docker-images voor het draaien van Bitrix in Docker: https:\/\/hub.docker.com\/search?q=bitrix&type=image<\/a><\/noindex> <\/p>\n

<\/p>\n

Is dit voldoende voor het cre\u00ebren van een volledige oplossing voor Bitrix in Kubernetes?
\nNee. Er zijn een groot aantal problemen die opgelost moeten worden.<\/p>\n

<\/p>\n

Wat zijn de problemen met Bitrix in Kubernetes?<\/h4>\n

<\/p>\n

De eerste \u2014 kant-en-klare images van Dockerhub zijn niet geschikt voor Kubernetes.<\/strong><\/p>\n

<\/p>\n

Als we een microservices-architectuur willen bouwen (en dat willen we meestal in Kubernetes), moet de applicatie in Kubernetes worden opgesplitst in containers en moet ervoor worden gezorgd dat elke container \u00e9\u00e9n kleine functie uitvoert (en dit goed doet). Waarom maar \u00e9\u00e9n? Kort gezegd \u2014 hoe eenvoudiger, hoe betrouwbaarder.
\nAls je het langer wilt houden \u2014 kijk alstublieft naar dit artikel en de video: https:\/\/habr.com\/ru\/company\/southbridge\/blog\/426637\/<\/a><\/noindex> <\/p>\n

<\/p>\n

Docker-images op Dockerhub zijn meestal gebouwd volgens het \u2018alles-in-\u00e9\u00e9n\u2019 principe, dus we moesten toch onze eigen \u2018fiets\u2019 maken en zelfs de images vanaf nul bouwen.<\/p>\n

<\/p>\n

De tweede \u2014 de code van de site wordt aangepast vanuit het beheerpaneel.<\/strong><\/p>\n

<\/p>\n

We hebben een nieuw deel op de website gecre\u00eberd - de code is bijgewerkt (er is een directory toegevoegd met de naam van het nieuwe deel).<\/p>\n

<\/p>\n

We hebben de eigenschappen van de component vanuit het beheerderspaneel gewijzigd - de code is veranderd.<\/p>\n

<\/p>\n

Kubernetes kan hier standaard niet mee omgaan, containers moeten onveranderlijk zijn (Stateless).<\/p>\n

<\/p>\n

Reden: elke container (pod) in de cluster verwerkt slechts een deel van het verkeer. Als je de code in slechts \u00e9\u00e9n container (pod) wijzigt, zal de code in verschillende pods verschillend zijn, de website zal anders functioneren, en verschillende gebruikers zullen verschillende versies van de website zien. Zo kan het niet doorgaan.<\/p>\n

<\/p>\n

De derde - we moeten het probleem van de deployment oplossen<\/strong><\/p>\n

<\/p>\n

Als we een monolithische structuur hebben en \u00e9\u00e9n 'klassieke' server, is alles heel eenvoudig: we zetten de nieuwe codebasis op, voeren de database-migratie uit, en schakelen het verkeer over naar de nieuwe codeversie. De overschakeling gebeurt onmiddellijk.
\nAls we een website in Kubernetes hebben, verdeeld in microservices, met veel containers met code - oeps. We moeten containers met de nieuwe codeversie bouwen, ze in plaats van oude uitrollen, de database-migratie correct uitvoeren, en idealiter moet dit onopgemerkt blijven voor bezoekers. Gelukkig helpt Kubernetes ons hierbij en ondersteunt het verschillende soorten deployments.<\/p>\n

<\/p>\n

De vierde - we moeten het probleem van de opslag van statische bestanden oplossen<\/strong><\/p>\n

<\/p>\n

Als je website 'slechts' 10 gigabyte groot is en je het geheel in containers uitrolt, krijg je containers van 10 gigabyte die een eeuwigheid zullen worden gedeployed.
\nWe moeten de 'zwaarste' delen van de website buiten de containers opslaan, en de vraag is hoe we dit het beste kunnen doen.<\/p>\n

<\/p>\n

Wat ontbreekt in onze oplossing<\/h4>\n

<\/p>\n

De volledige Bitrix-code is niet opgesplitst in microfuncties\/microservices (dus, registratie apart, module voor de webwinkel apart, enz.). We bewaren de hele codebasis in elke container.<\/p>\n

<\/p>\n

We bewaren de database in Kubernetes ook niet (ik heb wel oplossingen met een database in Kubernetes gerealiseerd voor ontwikkelomgevingen, maar niet voor productie).<\/p>\n

<\/p>\n

Beheerders van de website zullen echter opmerken dat de website in Kubernetes draait. De functie 'systeemcontrole' werkt niet correct, om de code van de website vanuit het beheerderspaneel te bewerken, moet je eerst op de knop 'ik wil de code bewerken' drukken.<\/p>\n

<\/p>\n

We have addressed the issues, clarified the need for microservices, and have a clear goal \u2014 to create a functioning system for running Bitrix applications on Kubernetes, preserving both Bitrix's capabilities and the advantages of Kubernetes. We are starting the implementation.<\/p>\n

<\/p>\n

Architectuur<\/h4>\n

<\/p>\n

Veel \u2018worker\u2019 pods met een webserver.
\nOne pod with cron tasks (only one is required).
\nOne upgrade pod for editing the site's code from the admin panel (also, only one is required).<\/p>\n

<\/p>\n

\"Southbridge<\/p>\n

<\/p>\n

We are solving the following issues:<\/p>\n

<\/p>\n