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

In Chelyabinsk, Sysadminka system administrator meetups are taking place, and at the last one, I presented our solution for running applications on 1C-Bitrix in Kubernetes.<\/p>\n

<\/p>\n

Bitrix, Kubernetes, Ceph \u2014 a great mix?<\/p>\n

<\/p>\n

I'll explain how we assembled a working solution from all this.<\/p>\n

<\/p>\n

Let's go!<\/p>\n

<\/p>\n

\"Southbridge<\/p>\n

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

The meetup took place on April 18 in Chelyabinsk. You can read about our meetups on Timepad<\/a><\/noindex> and watch on YouTube.<\/a><\/noindex>.<\/p>\n

<\/p>\n

If you want to come and present or attend as a listener \u2014 you are welcome, write to vadim.isakanov@gmail.com and on Telegram t.me\/vadimisakanov. <\/p>\n

<\/p>\n

My presentation<\/h2>\n

<\/p>\n

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

<\/p>\n

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

<\/p>\n

The solution \"Bitrix in Kubernetes, version Southbridge 1.0\"<\/h2>\n

<\/p>\n

I will talk about our solution in a \"for beginners in Kubernetes\" format, as it was done at the meetup. But I assume you are at least familiar with the terms Bitrix, Docker, Kubernetes, and Ceph at the level of Wikipedia articles.<\/p>\n

<\/p>\n

What is available about Bitrix in Kubernetes?<\/h4>\n

<\/p>\n

There is very little information on the internet about running applications on Bitrix in Kubernetes.
\nI only found the following materials:<\/p>\n

<\/p>\n

Presentation by Alexander Serbul, 1C-Bitrix, and Anton Tuzlukov from Qsoft: <\/p>\n

\n

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

I recommend listening to it.<\/p>\n

<\/p>\n

Development of a custom solution from the user serkyron<\/a><\/noindex> On Habr\u00e9<\/a><\/noindex>.
\nI also found such a solution<\/a><\/noindex>.<\/p>\n

<\/p>\n

And... that's all.<\/p>\n

<\/p>\n

I warn you, we haven't verified the quality of the solutions linked above \ud83d\ude42
\nBy the way, during the preparation of our solution, I spoke with Alexander Serbul, and at that time his presentation was not available yet, so my slides include a point saying \"Bitrix does not use Kubernetes.\"<\/p>\n

<\/p>\n

But there are already many ready-made Docker images for running Bitrix in Docker: https:\/\/hub.docker.com\/search?q=bitrix&type=image<\/a><\/noindex> <\/p>\n

<\/p>\n

Is this enough to create a full-fledged solution for Bitrix in Kubernetes?
\nNo. There are many problems that need to be solved.<\/p>\n

<\/p>\n

What are the problems with Bitrix in Kubernetes?<\/h4>\n

<\/p>\n

The first \u2014 ready-made images from Dockerhub are not suitable for Kubernetes.<\/strong><\/p>\n

<\/p>\n

If we want to build a microservices architecture (and usually we do in Kubernetes), the application in Kubernetes needs to be split into containers, and we must ensure that each container performs one small function (and does it well). Why only one? In short \u2014 the simpler, the more reliable.
\nIf you want more details \u2014 please check this article and video: https:\/\/habr.com\/ru\/company\/southbridge\/blog\/426637\/<\/a><\/noindex> <\/p>\n

<\/p>\n

Docker images in Dockerhub are mainly built on the principle of \"everything in one,\" so we had to create our bicycle and even build images from scratch.<\/p>\n

<\/p>\n

The second \u2014 the site code is adjusted from the admin panel.<\/strong><\/p>\n

<\/p>\n

A new section has been created on the site \u2014 the code has been updated (a directory with the name of the new section has been added).<\/p>\n

<\/p>\n

The properties of the component were changed from the admin panel \u2014 the code has been modified.<\/p>\n

<\/p>\n

Kubernetes does not support this by default; containers must be immutable (Stateless).<\/p>\n

<\/p>\n

The reason: each container (pod) in the cluster processes only part of the traffic. If the code is changed in just one container (pod), different pods will have different code, the site will function inconsistently, and different users will see different versions of the site. This is not sustainable.<\/p>\n

<\/p>\n

Third \u2014 we need to address the deployment issue.<\/strong><\/p>\n

<\/p>\n

If we have a monolith and a single 'classic' server, it's straightforward: we deploy a new codebase, perform a database migration, and switch the traffic to the new version of the code. The switch happens instantaneously.
\nIf our site is on Kubernetes, split into microservices, and has many containers with code \u2014 then it gets complicated. We need to build containers with the new version of the code, deploy them instead of the old ones, perform the database migration correctly, and ideally do this unnoticed by visitors. Fortunately, Kubernetes helps us with this, supporting a whole array of different types of deployment.<\/p>\n

<\/p>\n

Fourth \u2014 we need to address the static storage issue.<\/strong><\/p>\n

<\/p>\n

If your site weighs 'only' 10 gigabytes and you deploy it entirely in containers, you will end up with containers weighing 10 gigabytes that take an eternity to deploy.
\nWe need to store the 'heaviest' parts of the site outside of containers, and the question arises of how to do this properly.<\/p>\n

<\/p>\n

What is not in our solution.<\/h4>\n

<\/p>\n

The entire Bitrix code is not broken down into microservices\/microfunctions (so that registration is separate, the online store module is separate, etc.). We store the entire codebase in each container.<\/p>\n

<\/p>\n

We also do not store the database in Kubernetes (I have implemented solutions with a database in Kubernetes for development environments, but not for production).<\/p>\n

<\/p>\n

Site administrators will still notice that the site operates in Kubernetes. The 'system check' function does not work correctly, and to edit the site's code from the admin panel, you first have to click the 'I want to edit the code' button.<\/p>\n

<\/p>\n

We have resolved the issues, determined the necessity of implementing microservices, and our objective is clear \u2014 to create a functioning system for running Bitrix applications on Kubernetes while preserving both Bitrix capabilities and Kubernetes advantages. We are beginning the implementation.<\/p>\n

<\/p>\n

Architecture<\/h4>\n

<\/p>\n

Many \"worker\" pods with a web server.
\nOne pod with cron jobs (definitely only one).
\nOne upgrade pod for editing the site code from the admin panel (again, definitely only one).<\/p>\n

<\/p>\n

\"Southbridge<\/p>\n

<\/p>\n

We are addressing the questions:<\/p>\n

<\/p>\n