Небольшое расследование по формированию и изменению настроек mysql на веб сервере с bitrix env. Там не все так просто. Если кратко, основные параметры формируются динамически при загрузке сервера в зависимости от доступной оперативной памяти. Это делает невозможной корректную работу на виртуальных машинах с динамической оперативной памятью.
https://serveradmin.ru/gde-hranyatsya-nastroyki-mysql-v-bitrix-env-i-kak-ih-izmenyat/

#совет #bitrix

В очередной раз пришлось повозиться с настройкой Bitrixenv и сайта на нем. В какой-то момент bitrix сайт стал сыпать 500-е ошибки на некоторые операции. По логам было видно, что не хватает памяти для работы некоторых скриптов, хотя раньше хватало. Пришлось заняться расследованием и оптимизацией потребления памяти bitrix сайтом.
https://serveradmin.ru/bitrixenv-optimizacziya-nastroek-servera-pod-sajt-na-bitrix/

#статья #bitrix #webserver

Небольшой пример деплоя кода сайта на примере bitrix с помощью gitlab. После commit в репозиторий, код автоматически приезжает на целевой сервер через штатный механизм webhook в gitlab.
https://serveradmin.ru/deploj-deploy-obychnogo-sajta-cherez-gitlab-na-primere-bitrix/

#статья #bitrix #gitlab #devops

Написал небольшую заметку на тему совместной работы над сайтом от bitrix. Подход древнючий с прямой правкой файлов. Но по факту до сих пор много кто работает так над сайтами, а с битриксом особенно, так как там есть объективные сложности при работе через git, с которыми не все умеют справляться.
https://serveradmin.ru/dobavlenie-polzovatelya-sftp-dlya-dostupa-k-bitriks-v-bitrixenv/

#статья #bitrix

​​Ранее обещал написать про плюсы Bitrix и сейчас делаю это. Сразу предупреждаю, что не претендую на истину. Это мое частное мнение, основанное на нескольких годах поддержки различных проектов на Битриксе. В основном магазины, но есть большой сайт для управления медицинскими центрами и коробочные версии crm.

Рассматривать буду в первую очередь со стороны владельца бизнеса, заказывающего себе проект на Битрикс. Лично для админа плюсов не вижу :) Но я всегда на стороне бизнеса и эффективности. Руководствуюсь в первую очередь этим, а не своими предпочтениями.

1️⃣ Битрикс предлагает большой типовой функционал из коробки. Если он вас устраивает и вы не собираетесь изменять его, дорабатывать, то запуск в работу будет простой и быстрый. Интернет магазин сможет запустить даже сам владелец без посторонней помощи, пользуясь только админкой.

2️⃣ Bitrixenv отличное решение для разворачивания такого многофункционального продукта. Оно (окружение) реально упрощает запуск в работу и поддержку типового проекта. У многих хостеров можно сразу заказать себе виртуалку с bitrixenv и запустить сайт.

3️⃣ Встроенные проверки производительности и наличия ошибок позволяют заказчику выполнить базовую проверку своего проекта при заказе настройки где-то на стороне. Это не позволит выполнить работу совсем халтурно. Явные проблемы всплывут при подобных проверках.

4️⃣ Я нахожу полезными и эффективными настройки безопасности и кэширования, доступные в админке. Разобраться и настроить сможет не специалист.

В общем, мое резюме такое. Как готовый коробочный продукт с типовым функционалом Битрикс не плох. Если не ждать от него чудес, завяленных в рекламе, и не пытаться его доработать, то скорее всего он не создаст вам больших проблем. Интернет магазин будет продавать за минимум начальных вложений.

Как только вы начнете расти, в том числе по нагрузке и будете пробовать разрабатывать что-то свое на базе Битрикс, дорабатывать его, хлебнете проблем по полной. Они начнутся уже на этапе поиска программистов и первых доработок от них. В этот момент я советую подумать о переходе на что-то другое.

#bitrix

Помните, я на днях делал заметку про настройку анализа логов веб сервера с помощью elasticsearch? Проблему в итоге решили, но не с помощью логов. По ним стало понятно, что нет проблем с dos или какими-то другими паразитными нагрузками.

Стали еще раз внимательно смотреть мониторинг. Я с высокой точностью указал на дату, когда начались проблемы. Существенно выросла нагрузка на CPU. Стали внимательно вспоминать, кто и что делал в это время.

В итоге вспомнили, что примерно в эти дни начали использовать какой-то новый модуль для bitrix. Он на каждый хит выполнял какие-то действия. Я сам не вникал в эти подробности. Ну а в сумме это всё привело к серьезной нагрузке на сервер.

Таким образом, чтобы успешно администрировать любой веб проект, обязательно нужен мониторинг и анализатор логов. Вместе они позволяют даже не погружаясь глубоко в технические потроха, решить проблему. Не будь мониторинга, пришлось бы профилирование php и mysql делать. А это очень сложная техническая задача, так как у каждого веб приложения свои нюансы и профиль нагрузки. К примеру, я, глядя на запросы в mysql, которые генерирует битрикс, не смогу разобраться, в чем причина высокой нагрузки на базу.

А когда у тебя настроены вспомогательные инструменты, лезть глубоко в дебри не обязательно. Помимо мониторинга и анализа логов, так же эффективно помогают хорошие инкрементные бэкапы. Очень часто проблемы решаются банальным сопоставлением изменений в исходниках за какие-то даты. Сразу видно, кто и что менял в коде. На основе этого много раз решались похожие проблемы.

Так что настраиваем Zabbix, ELK, бэкапы и спим спокойно.

#webserver #bitrix

Технический пост, который уже давно нужно было сделать, но всё руки не доходили. На канале много содержательных заметок по различным темам. Иногда сам через поиск ищу то, о чём писал. Ниже набор наиболее популярных тэгов по которым можно найти что-то полезное (и не очень).

#remote - все, что касается удалённого управления компьютерами
#helpdesk - обзор helpdesk систем
#backup - софт для бэкапа и некоторые мои заметки по теме
#zabbix - всё, что касается системы мониторинга Zabbix
#мониторинг - в этот тэг иногда попадает Zabbix, но помимо него перечислено много различных систем мониторинга
#управление #ITSM - инструменты для управления инфраструктурой
#devops - в основном софт, который так или иначе связан с методологией devops
#kuber - небольшой цикл постов про работу с kubernetes
#chat - мои обзоры на популярные чат платформы, которые можно развернуть у себя
#бесплатно - в основном подборка всяких бесплатностей, немного бесплатных курсов
#сервис - сервисы, которые мне показались интересными и полезными
#security - заметки, так или иначе связанные с безопасностью
#webserver - всё, что касается веб серверов
#gateway - заметки на тему шлюзов
#mailserver - всё, что касается почтовых серверов
#elk - заметки по ELK Stack
#mikrotik - очень много заметок про Mikrotik
#proxmox - заметки о популярном гипервизоре Proxmox
#terminal - всё, что связано с работой в терминале
#bash - заметки с примерами полезных и не очень bash скриптов или каких-то команд. По просмотрам, комментариям, сохранениям самая популярная тематика канала.
#windows - всё, что касается системы Windows
#хостинг - немного информации и хостерах, в том числе о тех, кого использую сам
#vpn - заметки на тему VPN
#perfomance - анализ производительности сервера и профилирование нагрузки
#курсы - под этим тэгом заметки на тему курсов, которые я сам проходил, которые могу порекомендовать, а также некоторые бесплатные курсы
#игра - игры исключительно IT тематики, за редким исключением
#совет - мои советы на различные темы, в основном IT
#подборка - посты с компиляцией нескольких продуктов, объединённых одной тематикой
#отечественное - обзор софта из реестра отечественного ПО
#юмор - большое количество каких-то смешных вещей на тему IT, которые я скрупулезно выбирал, чтобы показать вам самое интересное. В самом начале есть шутки, которые придумывал сам, проводил конкурсы.
#мысли - мои рассуждения на различные темы, не только IT
#разное - этим тэгом маркирую то, что не подошло ни под какие другие, но при этом не хочется, чтобы материал терялся, так как я посчитал его полезным
#дети - информация на тему обучения и вовлечения в IT детей
#развитие_канала - серия постов на тему развития данного telegram канала

Остальные тэги публикую общим списком без комментариев, так как они про конкретный софт, понятный из названия тэга:
#docker #nginx #mysql #postgresql #gitlab #asterisk #openvpn #lxc #postfix #bitrix #икс #debian #hyperv #rsync #wordpress #zfs #grafana #iptables #prometheus #1с #waf #logs #netflow

​​Мне часто приходится поддерживать сайты на популярном в РФ движке Bitrix. Решил написать небольшой список настроек, на которые стоит обратить внимание при настройке рабочего окружения и самого сайта. Список основан на личном опыте и не претендует на истину.

📌 Сбалансируйте потребление оперативной памяти на сервере, чтобы её всегда хватало. Bitrix тяжёлый и неповоротливый движок. Его часто запускают на apache с php в качестве бэкенда. Так что надо как минимум между MySQL и Apache разделить ресурсы, чтобы в пике они не съели их все. У меня есть статья на эту тему.

📌 Обратите внимание на настройки php: max_execution_time и memory_limit. В Bitrix много тяжёлых запросов, особенно если настроены обмены с внешними ресурсами. Часто эти параметры приходится увеличивать до высоких значений, с которыми в других движках вам вряд ли приходилось иметь дело (например max_execution_time = 300 и memory_limit = 512M).

📌 Когда разворачиваете новый сайт, обязательно выбирайте кодировку UTF8. До сих пор можно выбрать CP1251. Много старых сайтов встречал с этой кодировкой. Они нормально работают, но я всё же рекомендую конвертнуть их в UTF8. Вот статья с инструкцией и скриптом.

📌 В настройках Главного модуля есть параметр "Использовать горячие клавиши". Чаще всего их никто не использует, лучше отключить. Под них таблица в базе b_hot_keys может разрастаться до огромных значений.

📌 Иногда разработчики включают логирование SQL запросов и забывают их отключить. Все запросы пишутся в базу. Она растёт с огромной скоростью. Отключить: Настройки ⇨ Настройки продукта ⇨ Настройки модулей ⇨ Монитор производительности ⇨ Вести журнал SQL запросов ⇨ Галочку снять.

📌 Если разворачиваете копию сайта для теста, обязательно пометьте её как версию для разработки в настройках Главного модуля, на вкладке с обновлениями. И отключите все кроны, особенно если там есть какие-то обмены. Всё, что вам надо, потом либо отдельно включите, либо запустите вручную. И про почту не забудьте, если есть какие-то рассылки, оповещения для пользователей.

📌 Все кроны сайта запускайте через системный cron, а не на хитах. При создании сайта установщик спрашивает об этом, но по дефолту вроде бы хиты предлагает. Надо не упустить этот момент, иначе под нагрузкой сайт будет сильно тормозить.

📌 Битрикс очень медленный движок, так что надо кэшировать всё, что можно. Обязательно делайте на этом акцент, когда будете беседовать с разработчиками. Если они не понимают и не хотят нормально настраивать кэширование, обращайтесь к руководству. В его интересах, чтобы сайт работал быстро, а без кэширования это невозможно.

📌 Никогда не обновляйте Bitrix сразу на проде. Всегда тестируйте обновления. Очень часто что-то ломается. Особенно если есть интеграции и обмены.

📌 Внимательно заполните gitignore. На сайте очень много того, что в git грузить не надо. Тут нет универсальных советов, так как зависит от конкретного сайта. В поиске много информации по этой теме, по аналогии не проблема сделать. Главное не забыть.

📌 Отправку почты битриксом можно настроить через утилиту msmtp (быстрее и проще, идёт в комплекте с bitrixenv), либо через postfix (чуть сложнее и дольше настройка). Если использовать postfix, то проще работать с логами, делать мониторинг, подсчёт статистики и т.д., так как это стандартное решение.

📌 Хороший CI/CD для Bitrix сделать трудно. Я не умею, так как не работал с большими проектами, а на маленьких всё по понятиям разработчиков делается. Один из вариантов, с которым работал, описывал в статье. Вот ещё пример с сайта самого битрикса.

📌 Bitrix успешно запускают в Kubernetes, хотя это не очень просто. Я видел выступление на конференции по этой теме. В общих чертах, как это может выглядеть описано в обзорной заметке от southbridge (аутсорсер).

В целом, всё, из того, что вспомнил, когда писал заметку. Тому, кто не работает с Битриксом, она не нужна. А если работаете или планируете, имеет смысл сохранить.

#bitrix

​​Недавно затрагивал тему настройки CMS Bitrix. В комментариях видел обсуждение Bitrixenv. Хочу немного развить эту тему, так как очень хорошо с ней знаком.

Для тех, кто не в курсе, поясню. Bitrixenv - это преднастроенное рабочее окружение для движка Bitrix. Он работает на обычном веб сервере на базе php + mysql. Bitrixenv автоматически настраивает полностью рабочий веб сервер с управлением через меню в консоли сервера. Реализовано управление через плейбуки Ansible.

Я лично считаю хорошим решением компании Битрикс разработать и поддерживать это окружение. Оно позволяет очень быстро и просто настроить веб сервер и запустить сайт. Специальных знаний не требуется. Достаточно научиться подключаться по SSH, чтобы запустить там вот это:
# wget https://repo.bitrix.info/yum/bitrix-env.sh \
&& chmod +x bitrix-env.sh \
&& ./bitrix-env.sh

При этом работать всё будет нормально. Никаких скрытых проблем или нерешаемых ситуаций с этим окружением в процессе эксплуатации не будет. Как я уже сказал, всё управляется через Ansible. В крайнем случае всегда можно зайти и руками поправить любой конфиг.

Bitrixenv умеет:
◽ управлять виртуальными хостами, добавлять, удалять новые сайты
◽ получать и автоматически обновлять сертификаты let's encrypt
◽ управлять версиями php, mysql
◽ настраивать мониторинг на базе munin
◽ устанавливать и настраивать memcached, sphinx
◽ подстраивать настройки софта под ресурсы сервера (по памяти и cpu)

Это основное, что я сам использовал. Там много всяких настроек. Можно сервером управлять - обновлять пакеты, настраивать время, менять пароль учётки bitrix и т.д. В общем, не зная в подробностях Linux, им можно худо-бедно управлять. Я так понимаю, что заточено это в первую очередь на разработчиков, чтобы они не тратили время на настройку веб серверов, а могли в несколько кликов всё запустить и начать разрабатывать.

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

Разговоры о том, что Bitrixenv это какая-то пустая поделка, которая больше вредит и мешает, только разговоры. На деле это вполне рабочий инструмент, который успешно решает поставленные задачи. Нужен ли он конкретно вам - отдельный вопрос. Я иногда его ставил, чтобы быстро запустить на время какой-то сайт на php. Ведь это готовый веб сервер за 5 минут.

#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

​​⚡️ Хочу предостеречь тех, у кого сайты на Bitrix. Как я понял, сейчас идёт волна взломов этого движка. У меня пострадал сайт одного из клиентов. Подробный бюллетень с описанием уязвимости ещё в июле публиковал НКЦКИ (ссылка на pdf). Там и вероятные пути попадания зловреда, его признаки, рекомендации по устранению последствий и рекомендации по защите.

У меня частично совпали признаки заражения с тем, что опубликовано в бюллетени, но не полностью. Модуля Vote не было, заражение прилетело через какую-то другую уязвимость. И особых разрушений на сайте тоже не было. Подменили пару файлов, добавили один новый, вставили вредоносную ссылку в код. Дату изменения файлов подделали (❗️), так что привычный поиск изменённых недавно файлов не поможет. Но не поменяли дату изменения директории, где этот фай лежал, так что теоретически можно найти следы, но сложно.

Код зловреда хитрый, поэтому его долго не замечали. Открывал фоном ссылку на сторонний сайт только один раз в день и только тем, кто пришёл на сайт из поиска. Постоянные пользователи не замечали ничего, как и администрация. Онлайн сканеры антивирусов, как и браузеры со своими встроенными проверками тоже не видели никаких проблем.

Мне устранить последствия удалось достаточно просто, потому что в стандартных бэкапах сайтов всегда храню все изменения файлов в течении дня. То есть прошёл день, я сравниваю вчерашний бэкап и сегодняшний. Все изменившиеся файлы кладу в отдельную папку с именем в виде даты. И такую историю изменений храню очень долго. Первое заражение сайта было ещё в июле, в августе один раз меняли ссылку. Мне удалось найти все изменённые файлы ещё с июля и заменить их оригиналами. Без этого не знаю, сколько времени пришлось бы ковыряться и всё равно наверняка бы не узнал, всё ли вычистил. А тут сразу все изменения файлов перед глазами. Подробно такая схема бэкапа описана у меня на сайте в статье про rsync. Рекомендую к обычным полным или инкрементным бэкапам добавлять такие, разностные по каждому дню.

Сайт доработанный, так что просто взять и обновить его нельзя. Нанимаются отдельно разработчики и выполняют обновление. Сразу предупредил владельца, чтобы оперативно проводил обновление. Других вариантов надёжной защиты не знаю. Пока выполнил рекомендации из бюллетеня и постоянно слежу, не повторился ли взлом. Если повторится, постараюсь подробно изучить, как именно он выполняется. Повторного заражения пока не было.

Проверил другие сайты, тоже давно не обновлявшиеся. Не нашёл следов заражения. Скорее всего используется какой-то модуль, который установлен не везде, либо отдельная редакция подвержена заражению.

Если сталкивались последнее время со взломом Битрикса, то какие меры для защиты приняли, помимо обновления до последней версии?

#bitrix

​​Столкнулся на днях с историей, когда не заработал LXC контейнер в Proxmox 7.4. Попросили развернуть один свежий сайт на Bitrix из бэкапа для дальнейшей разработки. У Bitrix в этом плане удобно сделано. Разворачиваешь в пару действий их окружение BitrixENV (набор скриптов, плейбуков и костылей для поднятия LAMP и других сервисов), закидываешь бэкап в корень сайта и дальше всё само происходит, а на выходе получаешь рабочую копию сайта.

Но есть одна значительная проблема. BitrixENV до сих пор работает на Centos 7. И я нигде не видел информации, что они с этим собираются делать. Поддержка этой системы скоро закончится, но уже сейчас возникают проблемы с её использованием.

В Proxmox 7 и 8 запустить Centos 7, как и Ubuntu 16 в LXC не получится. Начиная с 7-й версии Proxmox, обновился механизм контейнеризации до cgroupv2. Указанные системы его не поддерживают. Подробнее об этом можно почитать тут:
⇨ CGroup Version Compatibility
⇨ Old Container and CGroupv2

Пришлось разворачивать виртуалку и запускать сайт там. Если у кого-то есть информация, как разработчики Bitrix собираются решать вопрос с Centos 7, дайте знать. Меня очень напрягает этот момент. Переносить сайты на другую систему очень не хочется. С BitrixENV реально удобно.

Я всегда использовал это окружение, в первую очередь из-за того, что упрощается взаимодействие с разработчиками. Все работают в одной и той же среде. Она легко переносится, настраивается. Да и пользоваться ей удобно. Разработчик пилит сайт на своём компе или сервере с этим окружением и потом без проблем отдаёт его заказчикам, где они его разворачивают.

У меня так и было с этим сайтом. Разработчики дали доступ к админке сайта. Я зашёл, сделал бэкап, получил там же на него прямую ссылку. Установил Centos 7, развернул BitrixENV, добавил через менюшку новый сайт, зашёл на него браузером, запустил режим восстановления из бэкапа, указал ссылку на бэкап с сайта разработчиков. Ну и всё. Получил копию сайта на своём сервере. Даже в консоль сервера разработчиков идти не пришлось. Да и они сами ничего не делали.

Удобный механизм. Несмотря на все недостатки Битркса, в нём очень много преимуществ. Надеюсь, разработчики как-то решат вопрос со своим окружением и устаревшей Centos 7. Интересно, какую систему выберут и сохранят ли вообще это окружение.

#bitrix

У сайтов на Bitrix существует одна особенность. Специально выделил жирным, потому что это такая особенность, что всем особенностям особенность. В админке можно править исходники сайта прямо наживую, в том числе и служебные файлы .htaccess. Любой, кто имеет доступ к админке, может грохнуть сайт. И это время от времени случается.

Вчера грохнули сайт по похожей схеме. Сеошник добавлял редиректы правкой .htaccess через админку. Редиректов там сотни. Сайт очень старый. Его развивали и поддерживали за последние лет 10 несколько разных компаний и программистов. Правку файлов тоже на постоянной основе делают несколько человек - как минимум сеошник и контент менеджер.

Из-за ошибки в .htaccess апач на каждый запрос отдавал 500-ю ошибку. Это я уже потом узнал. Сначала зашёл на сервер, сразу посмотрел изменения за последние сутки:

# find /home/bitrix/ext_www/site01 -mtime -1 -ls

Когда увидел в списке файлов .htaccess сразу на него подумал. Сходил на бэкап сервер, забрал оттуда предыдущую версию файла. Он очень большой, так что глазами разницу не видно. Сравнил так:

# sdiff /root/restored/.htaccess /home/bitrix/ext_www/site01/.htaccess

Увидел много изменений. Сразу вернул прошлую версию файла. Сайт ожил. Я посмотрел на внесённые изменения. Сходил, проверил синтаксис через публичный сервис:

⇨ http://www.htaccesscheck.com (полезный, стоит сохранить)

Забавное вступительное слово у сервиса:

"Sick of one silly typo in a .htaccess file causing your entire site to be broken?" - "Устали, что банальная опечатка в .htaccess, роняет весь сайт?"

Это такая фишка Апача. И плюс, и минус одновременно.

Сервис показал ошибку. Один url, куда был направлен 301 редирект, был некорректный по формату. Из-за этого Apache на все запросы возвращал 500-ю ошибку. Я удивился от этого. Не припоминаю, что сталкивался с этим раньше. Как-то нелогично. Одно дело давать ошибку на конкретный редирект, а другое руинить всю свою работу из-за него.

В общем, файл починил, сеошнику отправил ссылку на сервис, чтобы проверял свои редиректы, прежде чем добавлять их в .htaccess. Как защититься от этого, не знаю. Это уже не первый раз, когда прямой правкой сайта через админку ломают его работу. Теоретически, я конечно знаю, как это можно исправить. Но для масштаба текущего бизнеса это будет неоправданно большой бюджет. Простой даже в несколько часов некритичен и проблем не создаёт. Напрягает это только меня, что приходится вручную решать проблемы. Но, собственно, я для этого туда и нанят.

#bitrix #webserver #apache

​​На прошлой неделе мне нужно было поднять новый сервер для сайта на движке Bitrix. Практически всё время до этого я и все известные мне разработчики разворачивали готовое окружение от авторов фреймворка - BitrixVM. Это готовый инструмент с TUI управлением. В целом, всё было удобно и функционально. Не без отдельных проблем, но это частности. Главное, что актуальность всего совместимого ПО поддерживали сами разработчики Битрикса. И оно было у всех идентичное, что упрощало разработку и перенос сайтов.

BitrixVM построено на базе Centos 7, которая через пару недель прекратит свою поддержку. В итоге встал вопрос, а какое окружение ставить? Я бегло поискал, но не нашёл никакой конкретики на этот счёт. К чему в итоге пришли разработчики и какое окружение они рекомендуют использовать? Я хз.

В итоге потратил кучу времени и поднял всё вручную на базе Debian 12. Установил и связал между собой все необходимые компоненты. Вместо Nginx взял сразу Angie, чтобы удобнее было мониторинг настроить. Да и в целом он мне больше Nginx нравится. Решил написать эту заметку, чтобы получить обратную связь. У кого-то есть конкретика по этой теме?

Судя по всему, все решают эту задачу кто во что горазд. Я нашёл несколько репозиториев с настройкой окружения для Bitrix. Вот они:

🔥https://gitlab.com/bitrix-docker/server
⇨ https://github.com/bitrixdock/bitrixdock
⇨ https://github.com/bestatter/bitrix-docker
⇨ https://github.com/paskal/bitrix.infra

Не захотелось во всём этом разбираться, поэтому настроил сам. Там ничего особенного, просто компонентов побольше, чем у обычного веб сервера на php. И конфиги немного понавороченней из-за особенностей Битрикса. Не хотелось бы всё это поддерживать теперь самостоятельно. И сейчас думаю, либо писать статью, подбивать все конфиги и как-то это упаковывать в ansible или docker. Либо всё-таки подождать какое-то решение от разработчиков.

В процессе настройки нашёл у Битрикса скрипт, который позволяет проверить соответствие хостинга требованиям движка. Раньше не видел его, да и необходимости не было. Забирайте, кто будет решать такую же задачу, пригодится:

⇨ Скрипт bitrix_server_test

Там заметка старая, но скрипт регулярно обновляется. Текущая версия от 29.02.2024.

#bitrix

Пока я был в отпуске, пропустил важную для меня новость. Ну как важную. Была важной, а теперь уже не очень. В общем, компания Битрикс наконец-то выпустила обновление своего окружения VMBitrix 9.0.0. И как вы думаете, на базе какой операционной системы? .... Барабанная дробь .... CentOS Stream 9 😱.

Этим они меня удивили. Самый неудачный выбор, который только можно придумать. Напомню, что до этого окружение было на базе Centos 6 и 7. 7-я версия уже EOL, так что они переехали на Stream. Как я понял, просто поленились и пошли по самому простому пути. Я ни разу ни у кого не видел в проде Centos Stream. Соответственно, не понятно, для кого они это выпустили. Ожидал увидеть Debian или Ubuntu, на худой конец Rocky или Alma, но надеялся на Docker образы.

Поясню, что VMBitrix это готовое преднастроенное окружение для запуска сайтов на базе Bitrix, а так же CRM Bitrix24. Сам сайт, в принципе, всё равно на чём запускать. Он заработает практически на любом хостинге на базе Nginx + Apache + PHP. А вот с Bitrix24 посложнее, потому что там пуши. Настраивать самостоятельно хостинг под него утомительно. Не хочется тратить на это время. Готовое окружение эффективно решает эту задачу, плюс некоторые другие типа многосайтовости, получение сертификатов и т.д. В целом, пользоваться удобно, потому что, во-первых, экономит время, а во-вторых, у всех одинаковое окружение. Это упрощает разработку и перенос продукта.

Я для себя эту задачу уже решил и настроил всё в Debian 12 на базе Angie вместо Nginx. Настройки уже обкатаны, веб сервер работает пару месяцев. Планировал статью написать, но не знаю как по времени сложится. Особо некогда. Если вы работаете с Ubuntu, то рекомендую вот этот материал:

⇨ CRM Битрикс-24 на веб-окружении под Ubuntu 24.04, c поддержкой PUSH и многосайтовости

Это сайт хорошего специалиста. Я с ним пересекался на одном проекте. Если вам нужен проект на Битриксе, рекомендую. По стоимости будет недёшево, но и результат будет хороший в отличие от многих других вариантов. Мне есть с чем сравнивать, так как с Битриксами работаю последние лет 10. Сейчас уже сильно меньше, а лет 5 назад постоянно был вовлечён в разработку. Буквально на днях обращался человек, просил посоветовать кого-нибудь для разработки под Битрикс, потому что уже намучался и отчаялся найти хорошего исполнителя. Это типичная история для тех, кто ввязался в разработку на базе Bitrix. Абсолютно (без преувеличения) все, с кем я пересекался по этой теме, просили посоветовать хорошего разработчика.

Вот, кстати, сама новость про VMBitrix 9.0.0:
⇨ https://dev.1c-bitrix.ru/community/forums/forum32/topic159152/
Там есть все технические подробности.

Можно считать, что VMBitrix больше нет. Не знаю, кто будет себе разворачивать его в прод на базе Centos Stream. Для разработки программистам, наверное, сойдёт, но потом встанет вопрос с переносом в прод. Предвижу истории, когда разработчик будет говорить, что у него всё работает, а на проде будут ошибки. Я сам уже сталкивался с такими моментами, потому что много мелких нюансов по настройке веб сервера, прав доступа, хранения сессий, передачи заголовков, IP адресов и т. д. Если разработчики совсем не понимают в администрировании, то они нормально перенести не смогут.

#bitrix