Comments 14
Крутится у меня 5 сайтов на битриксе докеризированных. Не кубер конечно, но оно как бы и не надо.
Так вот основная проблема - хз что кидать в persistence. Контент, код, фронт и бэк - всё аккуратно смешано в кучу, замешано и завернуто. Его не то, что в CI - его и в гит-то положить проблематично.
Отдельная история с контентом, который тонким слоем размазан по всей папке проекта, и при этом редактируется из админки.
Чтобы понять всю боль - достаточно ответить на один вопрос - а какие именно артефакты у вас идут с билд-сервера для деплоя битрикса? Как мы не крутились, а в конечном итоге это оказался образ с php-fpm и скомпиленными модулями к нему, а весь код битрикса тупо осел в persistent volume.
Основная проблема Битрикса (имхо!) - это тот факт, что СУБД является и хранилищем пользовательских данных (не единственным, но обязательным), и источником конфигурации (не единственным, но обязательным). По этой причине изменения в конфигурации невозможно нормально версионировать.
В гит все кроме папки ядра и upload, их раскатывать на stage сервера только после обновления, условно раз в 3-и месяца.
Спасибо за информацию. Возможно, у Битрикса много проблем, но их нужно учиться решать. Ещё раз спасибо за статью. Го он!
А как в таком кластере обстоят дела с лицензированием? Насколько знаю у Битрикс политика - один ключ две установки ядра, одна из которых только для разработки. А тут получается несколько копий одного ядра с одним ключом. Или реплики копиями не считаются?
Мне, как занимающемуся битриксом, стало аж интересно, что это за лицензия за миллион рублей, которая кластер позволяет делать.
Для остальных: битрикс - это обычный PHP сайт, каких-то сакральных знаний не требует. а bitrixvm используется еще и потому, что саппорт относится гораздо лояльнее, а не "кто вам настраивал, к тому и идите"
Тот самый bitrix-кластер. Начало