Чтобы добить тему с Bitrix, поделюсь ещё некоторыми знаниями на тему запуска этой CMS в Kubernetes. Я давно и много работал с Bitrix. Когда

Чтобы добить тему с Bitrix, поделюсь ещё некоторыми знаниями на тему запуска этой CMS в Kubernetes. Я давно и много работал с Bitrix. Когда проходил обучение по Куберу, была идея научиться с ним работать и запускать там Битрикс. В итоге от этой идеи отказался, так как это всё нужно только в крупном бизнесе, с которым я не работаю и не хочу работать. И вообще с Кубером после обучения расхотелось иметь дел. Это не моё.

У Bitrix есть ряд особенностей, которые затрудняют её запуск в Kubernetes:

1️⃣ Много нюансов с Docker образом. Насколько я знаю, официального не существует. Соответственно, делать придётся самим или брать чьи-то костыли. А компонентов у Битрикса может быть много. Надо будет всё это связывать.

1️⃣ Особенность Битрикса такова, что код сайта можно править прямо через админку. Это ломает вообще всю конструкцию работы в Kubernetes. Этот момент надо будет решать отдельно. Либо просто запретить такие правки, либо что-то костылить. А как обновлять?

1️⃣ Где-то надо будет хранить общие файлы, сессии, чтобы все поды имели к ним доступ. Плюс отдельная БД. То есть по факту у вас в Кубере будет только php + веб сервер. Файлы отдельно, БД отдельно. Всё это тоже должно быть отказоустойчивым, чтобы в кубере был какой-то смысл, кроме масштабирования нагрузки на веб сервер.

1️⃣ В Bitrix надо обязательно включать встроенное кэширование и как-то это разруливать между подами.

Тем не менее, Bitrix в Kubernetes запускают. Есть аутсорсеры, которые предлагают эту услугу. Каждый костылит что-то своё, но в общем и целом делают примерно следующее:

◽ Файлы отправляют в S3 или Ceph.

◽ Кэш можно хранить в Memcached, либо в файлах, возможно локально на каждом поде или где-то в общем хранилище, но это медленнее.

◽ Сессии можно в Mysql убрать, но это медленно, либо в тот же Memcached.

◽ Самое трудное это разобраться с возможностью изменений исходников через админку. Тут нужны какие-то свои костыли, которые после каждого локального изменения файлов, будут коммитить и пушить изменения в общий git и оттуда раскатывать по остальным подам. Можно административно запретить кому-то лазить по админке с целью изменения исходников, но обновлять всё равно как-то надо движок. А он тоже обновляется через панель управления. Либо где-то вовне это делать, но хочется тестировать тут же, где идёт работа.

На выходе имеем вместо готового решения на базе промышленного стандартна в виде Kubernetes, набор костылей на базе Kubernetes, что немного не то, что ожидают от Кубера.

Когда в итоге будет оправдан запуск Bitrix в Kubernetes? Посчитать не трудно. Минимальные прикидки по железу:

- 3-4 сервера под сам Кубер в минимальном наборе

- 3 сервера под файловый кластер

- 3 сервера под кластер БД

Если серверов меньше, то ни о какой отказоустойчивости речи быть не может. Сюда ещё добавляем 1-2 сервера под хранение логов, мониторинг, ci/cd и git. Либо всё это покупаем как сервис у облачных провайдеров.

У кого-то есть опыт запуска и обслуживания Bitrix в Kubernetes?

#bitrix