Небольшое расследование по формированию и изменению настроек 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