0  /  276

Курс для хостеров

Содержание

Bitrix Framework и хостинг

  Производительность сайта

Обладая большим арсеналом возможностей и наличием готовых компонентов почти под любую задачу, продукты на основе Bitrix Framework занимают на диске от 100 Мб и больше. Сложная структура страницы требует для ее обработки определенного объема памяти.

Однако, благодаря своей архитектуре платформа Bitrix Framework позволяет легче переносить большие нагрузки, а для малых нагрузок достаточно самого обычного хостинга (в варианте «виртуальный сервер»), не загруженного другими клиентами «под завязку».

Производительность сайта - комплексное явление. Для приемлемых результатов должно быть состыкованы:

  1. ресурсы сервера;
  2. настройка серверного ПО;
  3. программная платформа (БУС);
  4. прикладная разработка на платформе.

Без понимания каждой составляющей из этого списка невозможно настроить производительность. Сложность работы хостинга как услуги заключается в том, что конечные пользователи предъявляют претензии, как правило, к ТП хостинга, хотя проблемы могут быть на любом из названных выше этапов.

Типовая реакция неквалифицированного сотрудника ТП хостинга: проверка настроек сервера с проблемным сайтом и, в случае их соответствия локальным стандартам, "перевод стрелок" на программную платформу. Однако Bitrix Framework имеет свои особенности в настройке серверного ПО, что и нужно учитывать.

  Хостинг Bitrix Framework

Bitrix Framework имеет свои особенности в плане хостинга:

  • Наличие достаточного места на диске для создания большого количества файлов. Сегодня минимальное требование для проекта с большим числом картинок — от 300 Mбайт. (Важно помнить, что каждая картинка также занимает место на диске, а в большом проекте таких картинок может быть очень много.)

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

  • Наличие необходимых ресурсов на сервере - памяти, выделяемой скриптом, некоторых других настроек. Необходимо как минимум 128 Мбайт памяти, выделяемой для PHP, чтобы могли работать серьезные проекты (например, интернет-магазины). Она расходуется на построение структуры данных и выполнение кода при вызове каждой страницы сайта.
  • Желательность двухуровневой архитектуры для работы сайтов с высокой посещаемостью или серверов с высокой загрузкой. Для этого устанавливается дополнительный веб-сервер (обычно NGINX), который принимает все запросы. Это позволяет стабилизировать использование памяти за счет ограничения числа процессов Apache и получить отказоустойчивую систему.
  • Достаточно быстрый сервер баз данных. Для работы сайтов необходимо, чтобы сервер баз данных успевал обрабатывать запросы за короткое время.
  • Желательность работы PHP и FTP/SSH от одного и того же пользователя. При разработке сайта обычно работают с файлами по FTP/SFTP-протоколу. Вместе с тем при работе в самой системе она создает файлы от имени того пользователя, под которым работает PHP. При несовпадении этих пользователей могут возникнуть серьезные проблемы в работе сайта или в возможностях его модификации.

  Для успешной установки

Для успешной установки и полноценной работы продукта необходимо следующее:

  • Установка может быть сделана только в корневую папку веб сервера.
  • Необходимо использовать веб сервер Apache 2.0 и выше.
  • Хостер должен разрешать использование .htaccess.
  • Необходимо использовать PHP не ниже версии 8.0 (Рекомендуется 8.1 и выше).
  • safe_mode должен быть отключен (инсталлятор блокирует установку продукта в этом режиме).
  • short_open_tag включён.
  • memory_limit не ниже 32 Мб для редакции "Старт", не менее 64 Мб для редакции "Бизнес".
  • Наличие функций работы с сокетами для обновления продукта.
  • Наличие библиотек: Zlib (компрессия - для модуля компрессии и ускорения загрузки обновлений), GD lib (отображение графиков), Free Type (работа CAPTCHA).
  • Версия MySQL 5.7 и выше.
  • Рекомендуется использование акселератора PHP (поддерживается акселератор OPcache).
  • режим работы PHP как модуля Apache предпочтительнее (CGI настоятельно не рекомендуется, так как он не поддерживает работу акселератора. Лучше использовать FastCGI)
Примечание: не рекомендуется использовать модуль suhosin или mod_security т.к. в ряде случаев эти модули препятствуют нормальной работе продуктов.

Продукты Bitrix Framework поставляются в исходных кодах. Поэтому нет необходимости в модулях zend optimizer или zend guard loader.

Соответствие сервера требованиям системы, уже после установки сайта, можно протестировать модулем Монитор производительности.


Скрипт bitrix_server_test

Компания "1С-Битрикс" рекомендует клиентам и разработчикам проверять потенциальный хостинг специальным скриптом bitrix_server_test. Скрипт постоянно обновляется под выявляемые проблемы и обновления системы:

Нажмите на рисунок, чтобы увеличить

Хостерам рекомендуется периодически скачивать обновленную версию теста и проверять свои сервера по тестируемым параметрам.



Основные сведения о системе

В главе опишем основные сведения о системе, дадим глоссарий терминов и схему работы продукта.

Модульная структура

  Видеоурок

Продукты "1С-Битрикс: Управление сайтом" и "Битрикс24" имеют модульную структуру.

  Что такое модуль?

Модуль - объёмная часть программного кода, отвечающая за определённый функционал на сайте. Каждый модуль отвечает за управление определенными элементами и параметрами портала: информационным наполнением и структурой, форумами, рекламой, рассылкой, распределением прав между группами пользователей, сбором статистики посещений, оценкой эффективности рекламных кампаний и так далее.
Возможности редакции (лицензии) продукта, что она может, а что - нет, определяется набором модулей. Проверить состав вашей редакции можно на странице Лицензии.

Модули системы, главным образом, работают независимо друг от друга. Но есть и зависимости, функционал одних модулей основан на возможностях других. Например:

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

  Список модулей

Список используемых модулей выводится на странице Управление модулями (Настройки > Настройки продукта > Модули) в административном разделе системы:

Нажмите на рисунок, чтобы увеличить

Таблица содержит название и описание модулей, информацию о версии и дате последнего обновления, а также текущий статус в системе:

  • Установлен – модуль и его элементы [dw]доступны для использования[/dw][di]Если какой-то модуль не используется, то его можно удалить для экономии дискового пространства. Дистрибутив модуля остаётся в системе, и он в любое время может быть снова установлен.

    При деинсталляции некоторых модулей система предлагает сохранить накопленные модулем данные (таблицы модуля). Если вы в дальнейшем планируете использовать эти данные, то при удалении модуля необходимо отметить соответствующую опцию.[/di].
  • Не установлен – модуль не доступен для использования в системе.

  Функционал модулей

Функционал установленных модулей виден в соответствующей секции [ds]административного меню[/ds][di]Интерфейс административного раздела системы Bitrix Framework логически разграничен на области, обеспечивающие доступ к функциональным возможностям системы.

Подробнее ...[/di] системы.

Для некоторых из них данные в меню загружаются динамически. Например:

  • в Информационных блоках выполняется динамическая загрузка списка типов инфоблоков;
  • в Веб-формах выполняется динамическая загрузка списка веб-форм;
  • в Управлении структуры выполняется динамическая загрузка файловой структуры.

В зависимости от прав на доступ к модулям системы не всем доступен тот или иной функционал модуля. [ds]Управление уровнем прав[/ds][di]Настройка прав доступа к модулям системы позволяет определить диапазон допустимых действий пользователя
над модулем и его контентом.

Форма настройки параметров модуля

Подробнее ...[/di] пользователей на доступ к модулям системы осуществляется отдельно для каждого из них на странице его настроек.

  Настройка модулей

Страница настроек модуля имеет различное число вкладок и полей, в зависимости от его функционала. Перейти к этой странице можно следующими способами:

  • с помощью административного меню: Настройки > Настройки продукта > Настройки модулей > имя_модуля;
  • с помощью кнопки Настройки Кнопка, расположенной на административной панели. По этой кнопке вы перейдете к настройкам модуля, страницы (формы) которого открыты в текущий момент в основной рабочей области.

Документация по теме



Схема работы продукта

Визуальное представление работы продукта

Ознакомьтесь с общей схемой работы продукта.



[dw][/dw][di]Курсы по теме:
  1. Виртуальная машина BitrixVM
  2. Курс для хостеров
  3. Администратор. Базовый
  4. Технология Композитный сайт
  5. Разработка и эксплуатация высоконагруженных проектов
[/di]
[dw][/dw][di]Курсы по теме:
  1. Контент-менеджер
  2. Продвижение сайта и Маркетинг
[/di]
[dwi include_public_area]Сайт 1[/dwi] ... Сайт 3 ... Сайт N
[dw]Шаблон 1[/dw][di]Шаблон дизайна — это внешний вид сайта, в котором определяется расположение различных элементов на сайте, художественный стиль и способ отображения страниц.
Подробнее...[/di]
Шаблон 2 Шаблон 3 ... Шаблон N
[dw]Многосайтовый диспетчер[/dw][di]Многосайтовость - это возможность системы "1С-Битрикс: Управление сайтом" управлять разными сайтами из единой Панели управления.
Подробнее...[/di]
[dw]Журналирование[/dw][di]На странице Журнал событий (Настройки > Инструменты > Журнал событий) вы можете просмотреть события сайта.
Подробнее...[/di] и [dw]статистика[/dw][di]Страница Сводная статистика (Аналитика > Сводная статистика) позволяет увидеть и оценить суммарные данные по посещаемости и разным срезам статистики посещений.
Подробнее...[/di]
[dw]Система авторизации и разграничения доступа[/dw][di]За работу с пользователями (добавление и авторизация) отвечает Главный модуль системы. Пользователи добавляются с Публичного раздела самостоятельно, либо с Административного раздела вручную администратором или автоматически через разные виды импорта. Авторизация в системе также возможна через модуль AD/LDAP.
Подробнее...[/di]
[dw]Битрикс Framework[/dw][di]Bitrix Framework - это созданная на основе PHP платформа для разработки веб-приложений. На этой платформе компанией «1C-Битрикс» созданы два популярных продукта: «1C-Битрикс: Управление сайтом» и «1С-Битрикс: Корпоративный портал».
Курс Разработчик Bitrix Framework.[/di]
Компоненты, написанные на [dw]API[/dw][di]Документация по работе с API:
  1. API документация
  2. API D7 документация
  3. REST API документация
[/di]
[dwi include_admin_area]Административный раздел[/dwi] Индивидуальная бизнес-логика [dw]Компоненты пользователей[/dw][di]Фактически, на сегодняшний момент свой компонент нужно писать лишь тогда, когда нужен абсолютно новый функционал для сайта. Тем не менее, приходит время, когда разработчик должен научиться создавать свои компоненты.
Подробнее...[/di]
API
[dw]Модули[/dw][di]Курсы по теме:
  1. Администратор. Модули - администрирование модулей не относящихся к коммерческой деятельности;
  2. Администратор. Бизнес - администрирование модулей при организации торговых операций через Интернет.
[/di]
[dw]Главный модуль[/dw][di]Главный модуль задаёт параметры работы системы в целом. Форма настройки находится на странице Настройки > Настройки продукта > Настройки модулей > Главный модуль.
Подробнее...[/di]
[dw]Управл. структурой[/dw][di]Сайт в системе "1С-Битрикс: Управление сайтом" обладает логической и физической структурой.
Подробнее...[/di]
[dw]Интернет-магазин[/dw][di]Для создания интернет-магазина предназначен модуль Интернет-магазин, позволяющий осуществлять продажу товаров и услуг с сайта.
Подробнее...[/di]
[dw]Рекламные баннеры[/dw][di]Система «1С-Битрикс: Управление сайтом» позволяет организовать показ баннеров на сайте, подключив код внешней баннерной системы, либо за счет внутренней ротации баннеров в пределах сайта.
Подробнее...[/di]
[dw]Информ.блоки[/dw][di]Модуль Информационные блоки предназначен для управления различными блоками однородной информации. (на базе информационных блоков можно реализовать каталоги товаров, блоки новостей, справочники и т.д.). Познакомьтесь с описанием элементов модуля, а также примерами создания и настройки различных информационных блоков.
Подробнее...[/di]
[dw]Веб-формы[/dw][di]Модуль организует работу с произвольными веб-формами, позволяет хранить и фильтровать данные заполненных форм.
Подробнее...[/di]
[dw]Документооборот[/dw][di]Модуль Документооборот используется для организации цепочки движения документа от момента создания до момента публикации. Этот механизм используется если документ (новость, товар, страница сайта) должен быть проверен перед выпуском редактором или кем-то ещё.
Подробнее...[/di]
[dw]Торговый каталог[/dw][di]Главная составляющая интернет-магазина на CMS «1С-Битрикс: Управление сайтом» - каталог товаров. Его легко организовать, если использовать инструменты модуля Торговый каталог.
Подробнее...[/di]
[dw]Почта[/dw][di]Модуль Почта предназначен для получения и обработки почтовых сообщений.
Подробнее...[/di] и т.д.
[dw]Валюты[/dw][di]Вся работа по управлению валютами ведется в модуле Валюты. Этот модуль необходим для работы модулей Торговый каталог, Интернет-магазин, используется для отчетов в CRM, необходим при работе с финансовыми параметрами в рекламных кампаниях и событиях в Веб-аналитике.
Подробнее...[/di]
[dw]Статистика[/dw][di]Модуль Веб-аналитика используется для сбора и анализа информации о посетителях веб-сайтов. На основании этих данных определяется веб-аудитория и изучается её поведение для принятия решений по развитию веб-ресурса.
Подробнее...[/di]
[dw]Свои модули[/dw][di]Основа работ по созданию собственных продуктов для Маркетплейс - создание собственных модулей. В курсе Маркетплейс Bitrix Framework рассказано, как расширять функционал проектов на основе Bitrix Framework с помощью сторонних модулей и решений.
Подробнее...[/di]
Интерфейс к БД Интерфейс работы
c внешними источниками
[dw]Базы данных[/dw][di]Минимальным техническим требованием является использование версии MySQL 5.6. Рекомендуемая версия MySql - 5.7 и выше.
Подробнее...[/di]

MySQL
XML, Excel, [dw]1C[/dw][di]Курс Интеграция с 1Спредназначен для базовой подготовки пользователей, осуществляющих интегрирование продуктов «1С-Битрикс» с торговыми конфигурациями компании «1С».
Подробнее...[/di],
[dw]Платежные системы[/dw][di]Под платежными системами понимаются любые способы оплаты заказа: как платежные системы, принимающие платежи online, так и банковские переводы. В системе может быть создано любое их количество.
Подробнее...[/di],
Складские системы,
ERP и другие
[dw]Дисковая подсистема[/dw][di]Забота о свободном дисковом пространстве - одна из задач администратора сайта. Для решения этих задач в в Bitrix Framework есть несколько инструментов.

Подробнее в курсе Администратор. Базовый.[/di]


Установка и настройка

Раздел Установка и настройка описывает процедуры:

  • установки ознакомительной и коммерческой версии продукта;
  • процесс регистрации продукта на сайте компании "1С-Битрикс" и загрузки исходных текстов для получения полнофункциональной системы с открытыми текстами;
  • установка системы на виртуальную машину;
  • другие вопросы, связанные с установкой системы.

Для специалистов, выполняющих настройку веб-серверов (Apache, IIS) самостоятельно, рекомендуется дополнительно изучить документацию по настройке соответствующего программного обеспечения.

Вендор рекомендует устанавливать продукты на Виртуальную машину BitrixVM или использовать веб-окружение (BitrixEnv). Подробнее о них можно узнать в специальном курсе.

Необходимые настройки при использовании других окружений описаны в главе Установка БУС/КП на другие окружения.

Карта установки

Продукт «1C-Битрикс: Управление сайтом» имеет много способов и вариантов установки. Конкретный способ зависит от её целей, имеющегося на компьютере ПО, выбранного решения. Карта установки позволит вам выбрать для себя оптимальный вариант процедуры из множества возможных.

  • Ознакомление с продуктом на локальном компьютере

    Для ознакомления с продуктом на локальном компьютере можно использовать Windows-инсталлятор продукта, либо установку на Виртуальную машину (рекомендуется). (Установка с помощью Windows-инсталлятора в данном курсе не рассматривается.)

  • Установка на удаленный сервер

    Для установки на удаленный сервер мы рекомендуем использовать скрипт BitrixSetup. Также в этой ситуации можно воспользоваться установкой продукта с помощью архива .tar.gz или .zip.

  • Перенос сайта между разными площадками

    Для копирования сайта с локального компьютера на удаленный сервер или наоборот, а также для переезда с одного сервера на другой, воспользуйтесь уроком Перенос продукта.

Системные требования

В силу больших возможностей системы и наличия готовых компонентов почти для любой задачи «1С-Битрикс:Управление сайтом» занимает на диске от 100 Мбайт и больше, а сложная структура страницы может потребовать для ее обработки определенного объема памяти. Но благодаря своей архитектуре, платформа Bitrix Framework позволяет серверу легче переносить большие нагрузки.

В главе указываются основные технические требования к серверному программному обеспечению, сведения о поддержке стандартов и технологий, а также требования к программному обеспечению пользователя продуктом «1C-Битрикс: Управление сайтом». Современное аппаратное обеспечение перекрывает потребности системы практически в любом случае.

Необходимые настройки при использовании других окружений описаны в главе Установка БУС/КП на другие окружения.

Требования к серверному программному обеспечению

Веб-сервер

Apache (рекомендуется) работа на этом сервере оптимальна. Версия сервера не ниже 2.0.

Для "1С-Битрикс: Управление сайтом" (не для "Битрикс24 в коробке") возможно использование:

IIS (Internet Information Server)(возможна установка) – работа продукта возможна с IIS 5, IIS 6 и IIS 7 и 7.5. Требуется дополнительная настройка для корректной работы с продуктом.

Eserv (возможна установка) – продукт тестировался для совместной работы с веб-сервером.

Теоретически работа продуктов возможна на любом веб-сервере, который может выполнять PHP приложения. Но детальные тестирования не проводились, поэтому использование серверов не из списка возможно лишь на ваш риск.

PHP

Для работы продукта требуется наличие PHP версии не ниже [dw]8.0.0[/dw][di]С 01.02.2023[/di]. Рекомендуемая версия PHP – 8.1 и выше. Выбор PHP-версии зависит от требований, предъявляемых вашим хостинг-провайдером, либо от установленной версии PHP на локальном компьютере. Рекомендуется использовать самую последнюю стабильную версию PHP, чтобы исключить возможность появления ошибок, связанных с PHP, а также для большей безопасности проекта на сервере.

Для корректной работы продукта требуется наличие следующих расширений PHP:

  • GD – библиотека для работы с изображениями, требуется для построения графиков и диаграмм для модулей статистики, рекламы, техподдержки. Используется для работы механизма CAPTCHA.
  • PHP XML – используется для работы системы обновлений. Библиотека по умолчанию включена в стандартной установке PHP. Для версии под Windows – поддержка встроенная.
  • FreeType – библиотека необходима для корректной работы механизма CAPTCHA.
  • Поддержка регулярных выражений (POSIX и Perl-compatible) – необходима для корректной работы внутренних механизмов продукта.
  • Zlib compression – библиотека компрессии, используется при работе системы обновлений для уменьшения количества передаваемых данных от сервера к клиенту.
  • PHP openssl – библиотека используется для упаковки (шифрования) и распаковки (расшифровывания) данных.
  • PHP-акселератор – крайне рекомендуется наличие PHP-акселератора, например OPcache или XCache, для значительного ускорения работы PHP-приложений (рекомендуется OPcache, он доступен сразу «из коробки» в PHP v.5.5+).

    Внимание: eAccelerator не совместим с PHP v5.3+ и больше не поддерживается в продуктах «1C-Битрикс» с версии ядра 15.0.13. Подробнее см. в блоге разработчиков.

До версии 20.100.0 модуля main

Поддержка серверов баз данных

MySQL – минимальным техническим требованием является использование версии [dw]MySQL 5.6[/dw][di]С 30 июня 2019 года.[/di]. Рекомендуемая версия MySQL – 5.7 и выше.

Для работы с СУБД MySQL требуется установленная поддержка MySQL для PHP.

Внимание! С 1 января 2017 года прекращена поддержка продуктов «1С-Битрикс» на базах данных Oracle Database и MS SQL Server. Для установок, использующих эти БД, недоступны обновления и возможности новых релизов.

Примечание: Кодировка MySQL utf8mb4 не поддерживается.

Настройки PHP

Для корректной работы продукта необходимо установить следующие параметры PHP:

  1. memory_limit = 64M; Максимальный объем памяти в байтах, который разрешается использовать для работы PHP ядру продукта (в данном случае – 64 Мб).

    Обратите внимание: указанный параметр может быть изменен
    • непосредственно в файле php.ini;
    • из скрипта с помощью [dw]функции[/dw][di]Такая строка добавляется в файле /bitrix/php_interface/dbconn.php в момент установки, значение задается пользователем. [/di]: ini_set("memory_limit", "64M");
    • в файле .htaccess с использованием директивы: php_value memory_limit 64M
    • в файле httpd.conf с использованием директивы: php_admin_value memory_limit 64M

    Обратите внимание: установка параметров PHP из .htaccess возможна только при выполнении следующих условий:
    • используется веб-сервер Apache или совместимый с ним (IIS не является совместимым сервером);
    • файлы .htaccess обрабатываются веб-сервером, т.е. в настройках веб-сервера (httpd.conf) установлена директива: AllowOverride All или другое значение, отличное от None;
    • PHP установлен как модуль Apache (в случае, если PHP работает как CGI, все необходимые значения следует учесть и установить при сборке PHP)
  2. file_uploads = On; Параметр определяет возможность загрузки на сервер файлов. Дополнительно к указанному параметру устанавливаются значения следующих параметров:
    • upload_tmp_dir = <[dw]имя каталога[/dw][di]Необходимо, чтобы указанный каталог существовал и на него были права на запись для пользователя, под которым работает веб-сервер. Параметр upload_tmp_dir может быть закомментирован в php.ini по умолчанию. [/di]>
    • upload_max_filesize = <достаточный размер>

  3. Необходимо, чтобы была корректно настроена работа с сессиями в PHP. Рекомендуется проверить [dw]наличие пути[/dw][di]Если параметр session.save_path не настроен в файле php.ini, то по умолчанию будет использовано значение /tmp.[/di] для сохранения файлов сессий.
    В случае, если в параметрах URL на сервере появляется PHPSESSID=..., отключить его можно следующим образом:
    • В файле php.ini установить: session.use_trans_sid = 0
    • В файле .htaccess установить: php_flag session.use_trans_sid off
      Для демонстрационного сайта строка включена в указанный файл, требуется только раскомментировать ее.

    Важно! C целью безопасности необходимо обязательно указывать отдельную папку хранения сессий для каждого пользователя хостинга.

Выбор ОС

Вендор рекомендует устанавливать продукты на Виртуальную машину BitrixVM или использовать веб-окружение BitrixEnv. Подробнее о них можно узнать в специальном курсе Виртуальная машина BitrixVM:

  • Запуск виртуальной машины BitrixVM – «1C-Битрикс: Виртуальная машина» специально сконфигурирована для быстрого исполнения программных продуктов «1С-Битрикс»: разворачивается за минуты и сразу же готова к работе! На виртуальную машину можно не только установить ознакомительные версии продуктов «1С-Битрикс», но и перенести уже готовые проекты;
  • Установка «1С-Битрикс: Веб-окружение» – Linux (BitrixEnv) – позволяет быстро и с минимальными затратами развернуть оптимальное окружение для работы продуктов и решений «1С-Битрикс» на Linux-платформе CentOS 6/7 (x86_64).

Необходимые настройки окружения при использовании других ОС описаны в главе Установка БУС/КП на другие окружения:


Поддержка стандартов и технологий. Требования к клиентскому программному обеспечению

Система «1С-Битрикс: Управление сайтом» разработана с использованием и поддержкой следующих технологий:

HTML/XHTML – система не накладывает ограничений на использование шаблонов, разработанных с использованием HTML/XHTML.

JavaScript – система не накладывает ограничений на использование JavaScript в шаблонах сайта, шаблонах меню и на страницах сайта.

AJAX – технология используется в публичном интерфейсе продукта, компонентах 2.0, административной панели управления для ускорения работы с информацией сайта и уменьшения количества передаваемых данных от сервера к клиенту. Система не накладывает ограничений на использование технологии AJAX в публичных разделах сайта.

CSS – система предполагает использование различных таблиц каскадных стилей для каждого шаблона сайта. Отдельные таблицы стилей могут быть использованы для настройки представления публичных компонентов и шаблонов отдельных модулей (например, модули форума, техподдержки, опросов). Административная панель управления разработана с учетом возможности создания своих «визуальных тем», которые основаны на разработке отдельных таблиц стилей.

RSS – продукт поддерживает стандарт RSS версий 0.92 и 2.0. RSS используется для организации обмена информацией между модулями Информационные блоки, Блоги и Форум.

CommerceML – система реализована с поддержкой стандарта CommerceML версии 1.0. Поддержка стандарта позволяет обеспечить обмен информацией между «1C-Битрикс: Управление сайтом» и системой программ «1C: Предприятие» версий 7.7 и 8.х.

CSV – система использует стандарт CSV для организации обмена данными модуля информационных блоков с другими системами.

Поддержка браузеров – программный продукт разработан с учетом поддержки наиболее распространенных браузеров. Административная часть оптимизирована для работы с ними. Показ публичной части сайта не зависит от типа браузера.



Примечания:
  • Работа визуального редактора может функционально отличаться при использовании браузеров различных типов.
  • Некоторые функции API могут производить HTML-код, не соответствующий стандарту XHTML, и не полностью проходить проверку соответствия стандарту, указанному в объявлении типа документа <!DOCTYPE>.



Установка продуктов «1С-Битрикс»

В главе описаны предварительные шаги для установки продуктов компании "1С-Битрикс", шаги мастера установки, а также выбор и первоначальная настройка решений для быстрого развертывания своего проекта. Пример даётся на основе "1С-Битрикс: Управление сайтом", при установке "Битрикс24 в коробке" действия практически аналогичные. Отличается установка "Битрикс24 в коробке" незначительно в деталях в которых можно легко разобраться с помощью инструкций в "Мастере установки Битрикс24".

Решения — это дистрибутивы, адаптированные под различные типовые потребности пользователей.

Предварительные операции

Продукт «1С-Битрикс: Управление сайтом» поставляется в виде архивов .zip и .tar.gz для версий PHP 5.

  • Для начала установки загрузите архивные файлы продукта «1C-Битрикс: Управление сайтом» на сервер (или локальный компьютер).
  • Распакуйте архив в корневой каталог вашего сайта. Для распакованных файлов продукта вам потребуется примерно 60-120 Мб свободного дискового пространства в зависимости от редакции продукта. Для оценки полного размера необходимо дополнительно прибавить размер самого архива.

Внимание! Установка и дальнейшая корректная работа программы возможна только в корневой папке вашего сайта на хостинге.

Для начала процесса установки продукта выполните следующее:

  • Откройте страницу http://<ваш_сайт>/index.php в браузере, заменив фразу <ваш_сайт> на реальный адрес вашего сайта.
  • Следуйте инструкциям Мастера установки.

Мастер установки «1C-Битрикс: Управление сайтом»

Подробно рассмотрим как установить продукт «1С-Битрикс: Управление сайтом» и решение на демо-примере «Интернет-магазин».

Примечание: Количество шагов в Мастере установки продукта может отличаться в зависимости от вариантов установки. В частности, при установке на BitrixVM нет шага - [dw]приветствия[/dw][di]Первое окно - информация о начале процесса инсталляции и знакомство с основной
информацией о продукте.

[/di]. Этот шаг опущен и в описании установки.

Примечание: Запустив мастер c параметром clear_db=Y (например, http://localhost/?clear_db=Y), перед установкой продукта в базе данных будут удалены все таблицы и связанные с ними сущности.

Внимание! Используйте эту опцию, только если вы полностью осознаете последствия ваших действий.

Первый шаг

Первый шаг установки (лицензионное соглашение)

  • Внимательно ознакомьтесь с текстом Лицензионного соглашения. Если вы согласны с его условиями, то установите флаг в поле Я принимаю лицензионное соглашение.
  • Для продолжения установки нажмите кнопку Далее.

Второй шаг

  Лицензионный ключ

  • Регистрация лицензионного ключа
  • Выбор типа установки
  • Выбор кодировки сайта

  Регистрация продукта

В поле Лицензионный ключ введите полученный при покупке лицензионный ключ продукта.

Примечание: При установке демонстрационной версии продукта будет доступна опция [dw]Я хочу зарегистрировать свою копию продукта и получать обновления[/dw][di][/di]. Заполните регистрационные поля и получите право на обновление продукта в течение демо-периода.

В противном случае продукт будет установлен, но обновления будут недоступны. После установки демо-версии, всегда можно зарегистрировать демо-версию и получить демо-ключ для обновлений (подробнее см. в разделе Регистрация пробной (DEMO) версии продукта).

  Установка для разработки

Начиная с версии 16.5.7 и старше, в продукте «1С-Битрикс» появилась возможность пометить новую или существующую установку программного продукта специальным маркером, который не будет влиять на блокировку системы обновлений, и как следствие - на возникновение ошибки [dw]ERROR_WRONG_CODE[/dw][di]Система обновлений продукта привязывается к конкретной установке и "запоминает" состояние системы после очередного обновления. Ошибка ERROR_WRONG_CODE возникает в том случае, если текущее состояние не соответствует тому, которое было на момент последнего обновления.
Подробнее...[/di].

На Установке для разработки можно проводить тестирование, не устанавливая продукт локально. Этот функционал поможет решить проблему коллективного доступа к одной установке продукта. Ещё эта функция будет полезна, если разработчиков несколько и всем им нужна своя установка продукта для тестирования.

Примечание: Подробнее о данном режиме установки можно прочитать тут.

  Кодировка сайта

Установкой флажка задаётся установка с использованием кодировки UTF-8.

UTF-8 (от англ. Unicode Transformation Format — формат преобразования Юникода) — распространенная кодировка, реализующая представление Юникода, совместимое с 8-битным кодированием текста.

На данный момент для кодировки HTML-документа выбор стоит между WIN-1251 и UTF-8.

Использование кодировки WIN-1251 целесообразно со старыми версиями MySQL (до версии 4.х), которые некорректно работали с UTF-8. Эти недостатки отсутствуют в современных версиях СУБД MySQL.

Для достижения наибольшей универсальности и полноты использования существующих символов рекомендуется использовать кодировку UTF-8.

Для продолжения установки нажмите кнопку Далее.



Третий шаг

Примечание: Если продукт устанавливается на Виртуальной машине BitrixVM, то этот шаг будет пропущен.

Третий шаг установки (предварительная проверка)

Проверка системы на:

  • соответствие [dwi include_requirement]минимальным техническим требованиям[/dwi] продукта;
  • права доступа к диску;
  • рекомендуемые установки.

Результаты проверки выводятся разными цветами:

С версии 20.100.0 Главного модуля (main) требуется удаление настройки PHP mbstring.func_overload. Эта опция более не требуется и не поддерживается платформой.

Обязательные параметры

Нажмите на рисунок, чтобы увеличить

Проверка доступа к диску

Рекомендуемые установки

Не рекомендуется продолжать установку продукта до устранения несовместимости.

Технически установка возможна, но после установки приведите систему в соответствие с рекомендованными настройками. Иначе есть вероятность, что сайт работать не будет.

В дальнейшем проверить настройки системы можно в административном разделе на странице [dw]Проверка системы[/dw][di]

Подробнее... [/di] (Настройки > Инструменты > Проверка системы).

Для продолжения установки нажмите кнопку Далее.



Четвёртый шаг

Примечание: Если продукт устанавливается на Виртуальной машине BitrixVM, то этот шаг будет пропущен.

  Создание базы данных MySQL

Создаётся конфигурационный файл соединения с базой данных и производится загрузка данных в базу.

  Локальная установка

При инсталляции на локальный компьютер с уже установленными приложениями для его корректной работы (Apache, PHP, MySQL) заполните поля следующим образом:

  • Сервер: сервер, на котором работает система управления базами данных (СУБД), в данном случае MySQL. Для локального компьютера этот параметр обычно имеет значение localhost с портом, на котором работает MySQL, в формате localhost:[номер_порта]. Номер порта можно найти в конфигурационных файлах MySQL.
  • Пользователь базы данных: выберите создать нового пользователя;
  • Имя пользователя: введите произвольное имя (логин) пользователя СУБД для доступа к базе данных.
  • Пароль: пароль пользователя для доступа к базе данных.
  • База данных: создать новую базу.
  • Имя базы данных: имя создаваемой базы данных. Любое имя на латинице, возможно использование цифр и символа подчеркивания.
  • Тип таблиц базы данных: для большинства случаев подойдет тип стандартный. Возможен выбор из двух вариантов:
    • Стандартный. Стандартным типом таблиц в MySQL является тип MyISAM, который не является ориентированным на транзакции. Для таблиц типа MylSAM все данные сохраняются в одном файле, следовательно, максимальный размер файла одновременно является максимальным размером таблицы.

      Операционные системы налагают свои ограничения на максимальный размер файла. Обычно он составляет от 2 до 4 Гбайт. Таблицы MylSAM являются платформо-независимыми. Табличные файлы можно перемещать между компьютерами разных архитектур и разными операционными системами без всякого преобразования.

    • Innodb. Таблицы InnoDB в MySQL снабжены обработчиком таблиц, обеспечивающим безопасные транзакции с возможностями фиксации транзакции, отката и восстановления после сбоя.

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

      InnoDB предназначается для получения максимальной производительности при обработке больших объемов данных. По эффективности использования процессора этот тип намного превосходит другие модели реляционных баз данных с памятью на дисках.

  • Далее выберите Создать новую базу данных. Появится дополнительная группа: [dw]Пароль и логин администратора базы данных[/dw][di][/di].
    • В поле Логин введите root.
    • Поле Пароль оставьте пустым.

  Удалённый сервер

При установке на удаленном сервере данные для полей параметров базы данных вам надо запросить у службы поддержки удаленного сервера и заполнить поля:

  • Сервер: укажите сервер, на котором работает система управления базами данных (СУБД).
  • Пользователь базы данных: переключатель определяет, создавать ли нового пользователя базы данных в процессе установки или использовать данные существующего пользователя.
  • Имя пользователя: имя (логин) пользователя СУБД для доступа к базе данных.
  • Пароль: пароль пользователя для доступа к базе данных.
  • База данных: переключатель определяет: создавать ли новую базу данных в процессе установки или использовать существующую.
  • Имя базы данных: имя базы данных, в которую будет установлен продукт.
  • Тип таблиц базы данных: выбор между различными типами таблиц для базы данных.

Внимание! В большинстве случаев подойдет стандартный тип таблиц. Для сайтов с повышенными требованиями к нагрузке, например, интернет-магазинов, для базы данных MySQL предпочтительнее тип InnoDB.

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

  Дополнительные параметры

Эти параметры определяют права доступа к файлам сайта (для всех типов баз данных).

Заполните поля:

  • Права на доступ к файлам сайта: права, с которыми будут создаваться файлы. Права должны быть достаточными для доступа веб-сервера на запись. По умолчанию имеет значение 0644;
  • Права на доступ к папкам сайта: права, с которыми будут создаваться каталоги. Права должны быть достаточными для доступа веб-сервера на запись. По умолчанию имеет значение 0755.

Примечание: Ручную установку параметров соединения с базой данных (в том числе и максимальный объем памяти для выполнения скрипта) вы можете выполнить в файлах /bitrix/php_interface/dbconn.php и /bitrix/.settings.php. Файлы будут созданы после завершения установки.

Для продолжения установки нажмите кнопку Далее.



Пятый шаг

Пятый шаг установки (устанавливаем продукт)

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



Шестой шаг

Шестой шаг установки

На этом этапе выполняется настройка сайта и создание учетной записи администратора, которому будут доступны все функции настройки и управления сайтом.

Поля, отмеченные *, обязательны для заполнения.

  • Логин: логин (имя) администратора для входа в административный раздел. Логин должен быть не короче трех символов. Используйте в логине только латинские буквы и цифры.
  • Пароль: пароль администратора для входа в административный раздел. Используйте в пароле только латинские буквы и цифры.

    Важно! настоятельно рекомендуется использовать сложный пароль, длиной более 6 символов.

  • Подтверждение пароля: пароль вводится еще раз для проверки правильности набора.
  • E-Mail: адрес электронной почты администратора сайта (e-mail).
  • Имя: имя администратора сайта.
  • Фамилия: фамилия администратора сайта.

Для продолжения установки нажмите кнопку Далее.



Седьмой шаг

Седьмой шаг установки (выбор решения)

Выберите подходящее вам решение и запустите один из мастеров создания сайта:

  • Корпоративный сайт производственной компании на примере сайта мебельного производства – решение, подходящее производственным организациям и компаниям для создания корпоративного проекта.
  • Корпоративный сайт услуг на примере сайта банка – решение для организаций и компаний в сфере услуг для создания корпоративного проекта.
  • Демо-сайт для разработчиков.
  • 1С-Битрикс: Сайт сообщества – это решение создает основу сайта социального сообщества: клуб любителей кофе, рыбалки, велотуризма и т.д.
  • 1С-Битрикс: Персональный сайт – подойдет пользователю, который хочет создать свой сайт-визитку в Интернете и продвигать себя.
  • Интернет-магазин – это решение для тех, кто создает свою торговую площадку в Интернете.
  • Информационный портал – решение создает сайт СМИ со своей социальной сетью и сообществами.
  • если нужного решения нет в списке, то можно Загрузить из Marketplace – найти подходящее решение в каталоге.

Примечание: При выборе Загрузить из Marketplace будет осуществлен переход к восьмому шагу Выбор модуля Мастера установки.

Дополнительно




Восьмой шаг

Восьмой шаг установки

Примечание: Переход к странице выбора модулей осуществляется, если на седьмом шаге установки выбрано решение Загрузить из Marketplace.

  • Выберите необходимый сторонний модуль (мастер создания сайта) для загрузки из Marketplace.

  • Нажмите кнопку Далее.


Девятый шаг

Девятый шаг установки (загрузка модуля)

Примечание: Переход к этому этапу мастера осуществляется только если выбрано решение Загрузить из Marketplace на седьмом шаге установки.

Автоматический шаг, на котором происходит загрузка выбранного вами решения (мастера). Отслеживание процесса можно вести по графическому индикатору

  • После завершения процесса система автоматически перейдет к Мастеру создания сайта выбранного решения.


Установка демо-сайта для разработчиков

Примечание: Переход к этому мастеру осуществляется, только если былo выбрано решение Демо-сайт для разработчиков на седьмом шаге установки.

  Мастер установки демо-сайта

Выбор кнопки [dw]Далее[/dw][di][/di] запустит Мастер создания демо-сайта для разработчиков.

Примечание: В случае выбора кнопки Отмена продукт будет установлен в "чистом" виде, без демо-данных. То есть, будет выведена страница с приветственным текстом. Эта функция предназначена для разработчиков проектов. Если цель – ознакомление с продуктом, то пользоваться этой кнопкой не рекомендуется.

  Первый шаг

Выберите шаблон дизайна для сайта. Шаблоны отличаются внешним оформлением, представленной информацией на главной странице сайта, а также базовыми настройками.

  Второй шаг

Укажите предпочтительную цветовую схему для выбранного на первом шаге шаблона дизайна сайта. Для разных типов шаблонов предлагаются разные цветовые схемы.

  Третий шаг

Задайте название вашего сайта, слоган и логотип.

  • Заполните поля Название компании и Слоган компании.
  • Примечание: Если использование названия и слогана компании не предполагается, то эти поля можно оставить пустыми.

  • С помощью кнопки Обзор можно выбрать логотип компании для загрузки на сайт.

    Внимание! Размер загружаемого файла логотипа не должен превышать 1,5 Мб, формат файлов должен быть: GIF, JPG, PNG.

  Четвертый шаг

Выберите необходимые сервисы для создаваемого сайта.

Примечание. Если снять флажки со всех сервисов, то будет установлена только Главная страница, страница авторизации и поиск. Впоследствии через Административную панель можно запустить Мастер повторно и установить нужные сервисы, а также сменить шаблон сайта.

Для изменения настроек предназначена кнопка Назад, для запуска процесса установки - кнопка Установить.

Ход установки отображается с помощью графического индикатора.

  Окончание работы мастера

После завершения установки выводится информация об успешном завершении работы Мастера создания сайта.

Для выхода из мастера нажмите кнопку Перейти на сайт. Откроется публичный раздел созданного демо-сайта.

Установка продукта завершена.

  Дополнительная настройка

  • Чтобы отключить подстановку идентификатора сессии в ссылки на сайте, необходимо добавить в находящийся в корне сайта файл .htaccess директиву php_flag session.use_trans_sid off.
    Установка этой директивы может не поддерживаться установленной текущей версией Apache.
  • Чтобы включить кеширование изображений, необходимо добавить в находящийся в корне сайта файл .htaccess директивы:
    ExpiresActive on
    ExpiresByType image/jpeg "access plus 3 day" 
    ExpiresByType image/gif "access plus 3 day" 
    
    Установка этих директив может не поддерживаться установленной текущей версией Apache.

    Примечание: Включение кеширования изображений рекомендуется производить уже после всех отладочных работ на сайте.



Установка решения «1C-Битрикс: Управление сайтом» версии 16.5.х и выше

Внимание! Количество шагов в Мастере создания сайта может быть разным и зависит от конкретного решения.

Мастер установки решения

В качестве примера установки решения рассмотрим создание сайта онлайн-магазина (решение Интернет-магазин).

Примечание: Переход к этому мастеру осуществляется, только если выбрано решение Интернет-магазин на седьмом шаге установки.

Первый шаг мастера (выбор шаблона)

Первое окно информирует о начале работы мастера. Выберите [dw]шаблон дизайна[/dw][di] [/di] для вашего сайта. Шаблоны отличаются внешним оформлением, а также базовыми настройками.

Второй шаг мастера (выбор темы)

На этом шаге работы мастера выбирается цветовая тема для выбранного на первом шаге шаблона дизайна сайта. Для разных шаблонов предлагаются разные [dw]цветовые схемы[/dw][di][/di].

Третий шаг мастера (информация о сайте)

Задайте [dw]данные о компании[/dw][di] [/di].

Четвертый шаг мастера (настройка каталога)

Произведите [dw]настройки каталога[/dw][di][/di].

Пятый шаг мастера (информация о магазине)

Укажите [dw]служебные данные[/dw][di] [/di] о компании: Локализацию магазина (физическое местоположение магазина), Информацию о магазине и Банковские реквизиты

Шестой шаг мастера (типы плательщиков)

Задайте [dw]типы плательщиков магазина[/dw][di] [/di], которые будут использоваться на сайте.

Седьмой шаг мастера (оплата и доставка)

Определите [dw]способы оплаты, доставки[/dw][di] [/di] товара и Местоположение магазина, которые будут использоваться на сайте.

Восьмой шаг мастера (установка решения)

Автоматический шаг, на котором устанавливаются все настройки решения. Отслеживание процесса можно вести по [dw]графическому индикатору[/dw][di][/di]. После завершения процесса установки система автоматически перейдет к следующему шагу.

Девятый шаг мастера (завершение настройки)

Установка и настройка решения [dw]завершена[/dw][di][/di].

Нажмите кнопку Перейти на сайт для перехода на главную страницу сайта.



Внешний вид и особенности решений для установки

Видеоурок

В видео показана дополнительная необязательная информация, для расширения представлений о возможностях CMS Битрикс.

Демонстрируется, какие готовые решения предлагаются для установки в продукте Битрикс Управление сайтом и чем они отличаются. То есть, что вы получите, выбрав то или иное решение.



Установка стороннего решения из Marketplace

Стороннее решение из MarketPlace можно поставить как на этапе установки продукта «1C-Битрикс: Управление сайтом», так и после запуска проекта.

Внимание! Компания «1С-Битрикс» не несет ответственности за разработки партнеров. По всем вопросам, связанным с работой сторонних решений, а также в случаях нарушения работы сайта, вызванного некорректной работой сторонних решений, обращайтесь к партнерам-разработчикам.

В продукт включена защита от манипуляций с переустановкой стороннего решения с целью получить "бесконечный триал". Физическое удаление модуля (удаление папки модуля) независимо от срока действия триала приведёт к тому, что установить заново триальную версию станет невозможно. Установится только версия с купленной лицензией.

Внимание! Установка решений из MarketPlace допускается только на сайты с активной лицензией. При использовании демо-версии продукта для установки решения необходимо получить пробный лицензионный ключ.

До установки продукта

Примечание: Переход на этот шаг осуществляется, только если былo выбрано Загрузить из Marketplace на седьмом шаге установки.

Мастер установки решения

В качестве примера установки любого стороннего решения из Marketplace рассмотрим создание типового сайта лечебных учреждений, клиник (решение Сайт медицинской клиники).

Внимание! Количество шагов в Мастере создания сайта может быть разным и зависит от конкретного решения.

Первый шаг мастера (выбор шаблона)

Первое окно информирует о начале работы мастера. Выберите [dw]шаблон дизайна[/dw][di] [/di] для вашего сайта. Шаблоны отличаются внешним оформлением, а также базовыми настройками.

Второй шаг мастера (выбор темы)

Выберите цветовую тему для выбранного на первом шаге шаблона дизайна сайта. Для разных шаблонов предлагаются разные [dw]цветовые схемы[/dw][di] [/di].

Третий шаг мастера (настройка решения)

Задайте данные о компании в [dw]полях формы[/dw][di] [/di].

Четвертый шаг мастера (установка решения)

Автоматический шаг, на котором устанавливаются все настройки решения. Отслеживание процесса можно вести по [dw]графическому индикатору[/dw][di][/di]. После завершения процесса установки система автоматически перейдет к следующему шагу.

Пятый шаг мастера (завершение установки)

Установка и настройка решения [dw]завершена[/dw][di][/di].

Нажмите кнопку Перейти на сайт для перехода на главную страницу сайта.



После установки продукта

  Установка стороннего решения

Установить стороннее решение из Marketplace после установки продукта «1C-Битрикс: Управление сайтом» можно двумя способами:

  1. В [dwi include_public_area]публичной части[/dwi], нажав на кнопку [dw]Протестировать новое решение[/dw][di][/di] на панели управления. Далее выполните действия аналогичные установке стороннего решения до установки продукта.

  2. В [dwi include_admin_area]административной части[/dwi], найдя нужное решение в Каталоге решений (Marketplace > Каталог решений):

  • Выбрав подходящее решение из списка в Marketplace, вы перейдете на страницу этого продукта:

    На странице решения выполните одно из действий:
    • Купить - товар добавится в Корзину на сайте Marketplace, и вы перейдете к выбору оплаты и покупки;
    • Онлайн-Демо - вы перейдете в демо-раздел на сайте разработчика, чтобы в реальном времени попробовать функционал в действии;
    • Тестировать - вы перейдете в раздел обновлений Marketplace для скачивания и установки демо-версии на ваш сайт.
    • Установить - вы перейдете в раздел обновлений Marketplace для скачивания и установки решения на ваш сайт (этот вариант доступен при бесплатном распространении решения).
  • После выбора вариантов Тестировать или Установить вы перейдете в раздел Обновление решений (Marketplace > Обновление решений). Нажав кнопку [dw]Загрузить[/dw][di][/di], необходимо принять лицензионное соглашение, далее начнется загрузка.
  • После загрузки решения нажмите кнопку [dw]Установить[/dw][di][/di] для установки модуля.
  • Установить решение можно и в разделе Доступные решения (Marketplace > Установленные решения), выбрав в меню действий пункт [dw]Установить[/dw][di][/di]нужного мастера установки решения.
  • Дальнейшие шаги работы мастера установки аналогичны описанным в уроке по установке стороннего решения до установки продукта.

  Обновление решения

Для обновления стороннего решения необходимо перейти в Установка обновлений (Marketplace > Обновление решений):

По ссылке Посмотреть список обновлений осуществляется переход на закладку [dw]Список обновлений[/dw][di][/di], где указывается какое решение можно обновить.

  Активация купона

Купон - это своего рода лицензионный ключ, позволяющий легально использовать стороннее коммерческое решение, но при этом не спрашивать у него код ключа самого продукта «1C-Битрикс».

На закладке Активация купона (Marketplace > Обновление решений) осуществляется регистрация стороннего решения с помощью ввода кода купона:

Обратите внимание, купон нельзя активировать на демо-версии продукта.


Установка продукта с помощью BitrixSetup

Установка «1С-Битрикс: Управление сайтом» на удаленный сервер возможна посредством загрузки дистрибутива по протоколу FTP или с помощью скрипта BitrixSetup.

Для загрузки по FTP достаточно скачать и распаковать на локальном компьютере коммерческую или пробную версию. Затем с помощью любого FTP-клиента загрузить дистрибутив в корневую папку веб-сервера, либо закачать архив на удаленный сервер и распаковывать уже там.

Во избежание возможных ошибок при загрузке, а так же частой проблемы с различием прав доступа пользователя FTP и пользователя сервера Apache настоятельно рекомендуется использовать специально созданный скрипт BitrixSetup.

С помощью скрипта BitrixSetup вы сможете загрузить дистрибутив пробной или коммерческой версии продукта с сайта www.1c-bitrix.ru непосредственно на ваш сайт, минуя промежуточную загрузку дистрибутива на локальный компьютер. Кроме того, скрипт позволяет автоматически распаковать дистрибутив при отсутствии возможности доступа к сайту по SSH или с помощью внешних программ.

  • Перейдите по ссылке http://www.1c-bitrix.ru/download/cms.php на страницу с дистрибутивами продукта.
  • Перейдите на закладку BitrixSetup.

  • Нажмите ссылку Скачать.
  • В открывшемся диалоговом окне выберите вариант Сохранить.
  • Сохраните загружаемый файл с именем bitrixsetup.php.
  • Установите FTP соединение с сервером, на котором планируется размещение сайта.
  • Загрузите сохраненный на локальном компьютере файл bitrixsetup.php в корневую директорию вашего сайта на сервере.

    Внимание! Установка и дальнейшая корректная работа продукта возможна только в корневой папке сайта на сервере.

  • Откройте страницу http://<ваш сайт>/bitrixsetup.php в браузере, заменив строку <ваш сайт> на реальный адрес вашего сайта. В браузере отобразится страница загрузки дистрибутива.

    Внимание! Убедитесь, что веб-сервер обладает достаточными правами для создания и записи файлов на хостинге.
  • В поле Выбор дистрибутива выберите Управление сайтом и с помощью выпадающего списка укажите редакцию продукта, которую вы хотите установить.
  • Укажите версию продукта, которая вам необходима: демонстрационная или коммерческая.

    Если вы выбрали коммерческую версию, то введите лицензионный ключ в поле Лицензионный ключ.

    Примечание: Установка коммерческой версии без лицензионного ключа невозможна. Установка демоверсии возможна как с демонстрационным ключом, полученным на сайте компании «1С-Битрикс», так и без ключа вообще.

  • Нажмите кнопку Загрузить. Начнется процесс загрузки дистрибутива на сайт.

С помощью скрипта BitrixSetup будет установлено соединение вашего сервера непосредственно с сервером компании «1C-Битрикс». Дистрибутив выбранной редакции продукта будет скопирован в корневую директорию сайта на сервере, автоматически распакован, а затем в браузере откроется окно Мастера установки продукта.

С помощью кнопки Назад можно вернуться в раздел Выбор дистрибутива, чтобы изменить значения параметров загрузки (например, редакцию дистрибутива).

Важно! В целях безопасности скрипт bitrixsetup.php из корневого каталога сайта автоматически удаляется после распаковки дистрибутива.

Быстрая установка (Short install)

  Быстрая установка

Быстрая установка позволяет в упрощенном виде установить продукт «1C-Битрикс». Во время такой установки мастером пропускаются шаги лицензионного соглашения, предварительной проверки хостинга, выбора и настройки базы данных и т.п.

Таким образом, быстрая установка начнется с Пятого шага мастера установки продукта.

Все необходимые данные для установки содержатся в файлах /bitrix/php_interface/dbconn.php (до версии 20.900.0) и /bitrix/.settings.php (с версии 20.900.0), которые нужно создать и поместить в необходимые директории устанавливаемого дистрибутива.

  Пример файла
/bitrix/php_interface/dbconn.php

<? 
define("SHORT_INSTALL", true);
define("SHORT_INSTALL_CHECK", true);

define("MYSQL_TABLE_TYPE", "INNODB");
define("BX_UTF", true);

define("DBPersistent", false);
$DBType = "mysql";
$DBHost = "127.0.0.1:31007";
$DBName = "sitemanager";
$DBLogin = "user";
$DBPassword = "123456";
$DBDebug = false;
$DBDebugToFile = false;

define("BX_FILE_PERMISSIONS", 0664);
define("BX_DIR_PERMISSIONS", 0775);
@umask(~BX_DIR_PERMISSIONS);

define("BX_USE_MYSQLI", true);
define("DELAY_DB_CONNECT", true);
define("CACHED_menu", 3600);
define("CACHED_b_file", 3600);
define("CACHED_b_file_bucket_size", 10);
define("CACHED_b_lang", 3600);
define("CACHED_b_option", 3600);
define("CACHED_b_lang_domain", 3600);
define("CACHED_b_site_template", 3600);
define("CACHED_b_event", 3600);
define("CACHED_b_agent", 3660);

?>

Рассмотрим каждую строку подробнее:

  • SHORT_INSTALL - если указано значение true, то запускается упрощенный мастер установки.
  • SHORT_INSTALL_CHECK - проверка параметров окружения (права доступа к файлам, БД и т.п). Если такой константы нет, проверка будет выполнена на первом хите. После этого в начало dbconn.php запишется define("SHORT_INSTALL_CHECK", true);
  • MYSQL_TABLE_TYPE - выбор типа таблиц MySQL: MyISAM или InnoDB.
  • BX_UTF - выбор кодировки сайта: true - UTF8, false - CP1251.
  • DBPersistent - если данная константа инициализирована значением true, то будет создаваться постоянное соединение с базой, иначе - обычное.

    Примечание: При создании соединения с базой в памяти создается дескриптор данного соединения. Если соединение обычное, то после отработки скрипта этот дескриптор удаляется. Если соединение постоянное, дескриптор остается и может быть использован другими процессами при необходимости. Достоинством постоянного соединения является то, что, как правило, времени на него требуется меньше, но в то же время есть недостаток - количество открытых постоянных соединений ограничивается в настройках базы данных и при превышении этого лимита посетитель не сможет зайти на сайт пока не освободятся новые соединения.

  • $DBType - указывается тип базы: mysql.
  • $DBHost - указывается адрес и порт сервера базы данных MySQL (например, localhost или 192.168.3.155:31007, если БД находится на другом хосте и на нестандартном порту).
  • $DBName - указывается имя базы MySQL (например, sitemanager).

    Примечание: База данных должна быть заранее создана на хостинге. Например, для кодировки сайта в UTF8 при создании MySQL-базы collation для нее должно быть utf8_unicode_ci, в CP1251 - cp1251_general_ci.

  • $DBLogin - логин пользователя для доступа в базу данных.
  • $DBPassword - пароль пользователя для доступа в базу данных.
  • $DBDebug - если данная переменная будет равна true, то в случае ошибки при создании соединения с базой или в любом SQL-запросе, сообщение об ошибке и полный текст этой ошибки будет отображаться в браузере. В противном случае - полный текст ошибки будет показан только администратору сайта.
  • $DBDebugToFile - если данная переменная будет равна true, то все SQL-запросы к базе данных и время их выполнения будут записываться в лог-файл /mysql_debug.sql . Данная возможность используется, как правило, для получения данных о скорости выполнения SQL-запросов к базе данных.

    Внимание: Ведение подобного лога может серьезно замедлить работу сайта, поэтому пользоваться этим стоит кратковременно.

  • BX_FILE_PERMISSIONS - права, с которыми будут создаваться файлы. Права должны быть достаточными для доступа веб-сервера на запись (по умолчанию - 0644).
  • BX_DIR_PERMISSIONS - права, с которыми будут создаваться каталоги. Права должны быть достаточными для доступа веб-сервера на запись (по умолчанию - 0755).
  • @umask(~BX_DIR_PERMISSIONS) - возвращает права на директории, созданные в процессе установки продукта, к принятым по умолчанию на хостинге (без вывода ошибок).
  • BX_USE_MYSQLI - использование расширения mysqli (в версии ядра 14.5.2 и выше).

    Внимание: В PHP должно быть установлено расширение mysqli, дополнительные проверки на наличие расширения не производятся! Включать mysqli нужно отдельно для старого (dbconn.php) и нового (.settings.php) ядра.

  • DELAY_DB_CONNECT - подключение к базе данных будет автоматически устанавливаться при первом запросе через API-функции.
  • CACHED_menu - указывается время жизни управляемого кеша меню в секундах. Если константа равна false, то кеширование меню отключено.
  • CACHED_b_lang, CACHED_b_option, CACHED_b_lang_domain, CACHED_b_site_template, CACHED_b_event, CACHED_b_agent - указывается время жизни управляемого кеша языковых файлов, настроек, шаблона сайта, событий и агентов в секундах. Если константа равна false, то кеширование отключено.

  Пример файла
/bitrix/.settings.php

<?php
return array (
  'utf_mode' =>
  array (
    'value' => true,
    'readonly' => true,
  ),
  'cache_flags' =>
  array (
    'value' =>
    array (
      'config_options' => 3600,
      'site_domain' => 3600,
    ),
    'readonly' => false,
  ),
  'cookies' =>
  array (
    'value' =>
    array (
      'secure' => false,
      'http_only' => true,
    ),
    'readonly' => false,
  ),
  'exception_handling' =>
  array (
    'value' =>
    array (
      'debug' => false,
      'handled_errors_types' => 4437,
      'exception_errors_types' => 4437,
      'ignore_silence' => false,
      'assertion_throws_exception' => true,
      'assertion_error_type' => 256,
      'log' => array (
          'settings' =>
          array (
            'file' => '/var/log/php/exceptions.log',
            'log_size' => 1000000,
        ),
      ),
    ),
    'readonly' => false,
  ),
  'connections' =>
  array (
    'value' =>
    array (
      'default' =>
      array (
        'className' => '\\Bitrix\\Main\\DB\\MysqlConnection',
        'host' => 'localhost',
        'database' => 'sitemanager0',
        'login' => 'root',
        'password' => '',
        'options' => 2,
      ),
    ),
    'readonly' => true,
  )
);

Примечание: Некоторые секции файла настроек содержат параметр readonly. Если он принимает значение true, то данные настройки нельзя изменить через API.

  • utf_mode - отвечает за кодировку сайта, значения value:
    • true - UTF8;
    • false - CP1251.
  • cache_flags - флаги кэширования:
    • config_options - время жизни кэша настроек сайта в секундах;
    • site_domain - время жизни кэша настроек домена в секундах.
  • cookies - отвечает за cookies на сайте.
  • exception_handling - секция отвечает за обработку ошибок.
  • connections - секция отвечает за параметры соединения с базой данных и другими источниками данных.


Регистрация продукта

Перед началом использования коммерческой версии системы вам необходимо произвести активацию лицензионного ключа.

Лицензионный ключ - последовательность символов, подтверждающая право на использование копии продукта.

Внимание! С использованием одного и того же лицензионного ключа продукт «1C-Битрикс» можно установить не более двух раз, причем публичный доступ к одной из этих двух установок должен быть ограничен (одна из установок должна использоваться только для разработки и тестирования). Количество установок засчитывается при активации системы. При получении ошибки о превышении допустимого количества установок продукта необходимо обратиться в Техподдержку «1C-Битрикс».

Если установка не имеет доступа из сети и используется для разработки, то рекомендуется использовать опцию настройки главного модуля Установка для разработки. В этом случае установки для разработки при обновлении учитываются отдельно от публичных установок.

Переоформление лицензии с одного владельца на другого выполняется через Техподдержку компании 1С-Битрикс. При этом не имеет значения, имеется ли на момент переоформления у клиента активная ТП или нет.

Исходный код и демоверсии

Все коммерческие версии продуктов "1C-Битрикс" всегда поставлялись в исходных текстах. Таким образом предоставляется клиентам контроль над продуктом. Лицензия также предусматривает право на изменение исходных текстов.

Пробные версии кодировались с помощью Zend Optimizer, и это создавало проблемы:

  • необходимость установки Zend Optimizer на сервер,
  • пробные версии работали существенно медленнее, чем коммерческие версии в исходных текстах,
  • закодированный код не компилировался оптимизаторами PHP кода.

Начиная с версии 9.1, в продуктах "1C-Битрикс" для обеспечения 30-дневного демо-периода и защиты решений партнеров используется собственный обфускатор PHP кода, который защищает несколько важных системных файлов в пробных версиях продуктов «1C-Битрикс», а также автоматически защищает решения партнеров. В коммерческих версиях по-прежнему все файлы остались в свободном исходном коде.


Регистрация коммерческого продукта

  Зачем регистрировать?

Зарегистрировав продукт, вы получите доступ к бесплатным обновлениям системы, а также приоритетный доступ к службе Технической поддержки компании «1С-Битрикс» на период активности лицензии. Для неактивной лицензии техническая поддержка также осуществляется, но по менее строгому регламенту.

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

Продукт "1C-Битрикс" может быть временно установлен на дополнительный компьютер (ЭВМ) для разработки, тестирования и/или наполнения сайта при условии отсутствия любого "внешнего" доступа к ней (в том числе из сети Интернет или извне локальной сети пользователя). Такая установка должна быть немедленно удалена после завершения этих работ. При получении ошибки о превышении допустимого количества установок продукта необходимо обратиться в Техподдержку «1C-Битрикс».

Внимание! С использованием одного и того же лицензионного ключа продукт «1C-Битрикс» можно установить не более двух раз, причем публичный доступ к одной из этих двух копий должен быть ограничен (одна из копий должна использоваться только [ds]для разработки и тестирования[/ds][di]Начиная с версии 16.5.7 и старше, в продуктах «1С-Битрикс» можно пометить новую или существующую установку продукта специальным маркером Установка для разработки. Маркер позволяет проводить тестирование, не устанавливая продукт локально.

Подробнее ...[/di]).

  Регистрация продукта

  • В [dwi include_admin_area]Административном разделе[/dwi] перейдите на страницу Marketplace > Обновление платформы. Откроется форма для получения обновлений и секции для активации ключа и регистрации продукта.

  • По кнопке Активировать ключ откроется форма следующего вида:

    Заполните поля:
    • Полное юридическое название компании-владельца продукта или ФИО частного лица: укажите название организации, которая является [dw]владельцем ключа[/dw][di]Если по каким-то причинам указали не то ЮЛ, то сменить его можно будет через Партнёрский отдел компании "1С-Битрикс".[/di]. В случае если владельцем ключа является частное лицо, в данном поле указывается его имя.
    • Список адресов, включая тестовые, по которым будет доступна данная копия продукта "1С-Битрикс: Управление сайтом": укажите адреса сайтов, управление которыми будет осуществляться с помощью системы с данным лицензионным ключом. Адреса вводятся через запятую.
    • Телефон владельца данной копии продукта: укажите номер контактного телефона вместе с кодом города владельца продукта.
    • E-mail владельца для связи по вопросам лицензирования и использования программного продукта: укажите адрес электронной почты, по которому, в случае необходимости, сотрудники компании «1С-Битрикс» смогут связаться с вами.
    • Контактное лицо, ответственное за использование данной копии программного продукта: укажите ФИО ответственного контактного лица.
    • E-mail контактного лица: укажите адрес электронной почты контактного лица клиента.
    • Телефон контактного лица: укажите телефон контактного лица.
    • Прочая контактная информация: в данном поле вы можете указать дополнительную контактную информацию: адреса электронной почты, почтовый адрес, номера контактных телефонов и т.д.
    • У меня нет аккаунта на сайте www.1с-bitrix.ru, я хочу создать новый: если вы не являетесь зарегистрированным пользователем на сайте компании «1С-Битрикс», то установите флаг в данное поле. После активации лицензионного ключа вы будете зарегистрированы на сайте компании с указанными в нижеследующих полях регистрационными данными. Используя указанные регистрационные данные, вы можете обратиться в службу Технической поддержки компании «1С-Битрикс», а также получить доступ к закрытому форуму на сайте компании.
    • Я зарегистрирован на сайте…: отметьте эту опцию, если вы зарегистрированы на сайте www.1с-bitrix.ru и укажите ваш логин.
  • Нажмите Активировать ключ. Лицензия активируется.

  • Далее необходимо получить полнофункциональную версию системы без ограничения по времени работы. Нажмите [dw]Зарегистрировать продукт[/dw][di][/di]. Продукт будет зарегистрирован на указанные при активации данные.

Примечание: Если по каким-либо причинам лицензионный ключ уже был ранее активирован, то вам предложат только зарегистрировать продукт в системе обновлений.

После выполнения всех этих действий станет доступна информация о лицензии:


Регистрация демо-версии коммерческим ключом

Демо-версию можно перевести в статус коммерческих, если имеется коммерческий лицензионный ключ.

Сделать это можно двумя способами:

  1. на закладке Установка обновлений (Marketplace > Обновление платформы), нажав на кнопку Ввести лицензионный ключ

  2. либо

  3. на закладке Система обновлений страницы настроек Главного модуля (Настройки > Настройки продукта > Настройки модулей > Главный модуль) в поле Лицензионный ключ

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

Ограниченная лицензия

Внимание! C 14 марта 2022 года произошли изменения в лицензировании коробочной версии Битрикс24. Срок действия лицензии – 12 месяцев. С подробностями можно ознакомиться в статье. Спустя 15 дней после окончания срока действия лицензии работа вашей коробочной версии Битрикс24 будет отключена полностью, и работать с ней станет возможно только после [ds]продления лицензии[/ds][di] В уроке описываются способы продления лицензии и до истечения её срока действия, и после истечения срока.

Подробнее...[/di] на следующие 12 месяцев.

Если же лицензия была куплена до 14 марта 2022 года и вы не продлили её согласно новым условиям лицензирования, то после окончания срока действия лицензионного ключа коробочная версия Битрикс24 продолжит работать в режиме ограниченной лицензии.

Если по окончании срока действия лицензии Вы приняли решение не продлевать лицензию, то работа продукта 1С-Битрикс: Управление сайтом перейдет в ограниченный режим, т.е. часть функций станут недоступны.

Ограниченный режим актуален для продукта Битрикс24 Коробочная версия, если этот продукт приобретён до 14 марта 2022 года и вы не продлили лицензию согласно новым условиям лицензирования.

Какие возможности станут недоступны

  1. Обновления продукта и получение новых версий;
  2. Техническая поддержка;
  3. Каталог Marketplace и Приложения24;
  4. Переход на другую редакцию.

Какой функционал будет недоступен

Для 1С-Битрикс: Управление сайтом и Битрикс24 Коробочная версия (приобретённая до 14 марта 2022 года и не продлённая согласно новым условиям лицензирования):

ФункцияМодуль
Сайты 24 (доступ к опубликованным ранее сайтам есть, но опубликовать новый или после редактирования нельзя). Также перестанут создаваться новые CRM формы.landing
Мобильное приложение администратора магазина (для редакций «Малый бизнес» и «Бизнес»)main
Защита от DDoS*, а также анализ скорости сайта.main
Ускорение загрузки сайта CDNbitrixcloud
Резервное копирование сайта в облако 1С-Битриксbitrixcloud
Инспектор сайтовbitrixcloud
Автобюджет контекста в Яндекс.Директ, в том числе публикация рекламы на рекламных площадкахseo
BigData: Персонализацияcatalog
Сервис служб доставки (ограничено использование обработчиков доставок СДЭК, Почта России, DPD)sale
Отключится облачный Push&Pull. Можно настроить локальный сервер Push&Pull в VMBitrix.pull

* Сервис временно недоступен.

Только в [ds]Битрикс24 Коробочная версия[/ds][di]После окончания действия лицензионного ключа «Битрикс24 в коробке» вы сможете пользоваться порталом, но с некоторыми ограничениями.
Функциональные возможности, недоступные в ограниченной лицензии:
Подробнее...[/di](приобретённая до 14 марта 2022 года и не продлённая согласно новым условиям лицензирования):

ФункцияМодуль
Автозаполнение реквизитов по ИНН, подключение рекламных кабинетов в сквозной аналитике, а также подключение к CRM-формам страниц ВКонтакте.crm
Открытые линии (viber, facebook*, и остальные), кроме Онлайн-чата.imopenlines
Сервис конвертирования файловtransformer
Работа телефонии, в том числе SIP-коннектор.voximplant
Чат-бот платформа, в том числе чат-бот Марта.imbot
Распознавание лиц.faceid
Использование REST методов и событий (кроме входящих веб-хуков), а также прекращение работы установленных приложений из Маркетплейс24.rest
Сервис просмотра и редактирования документов Битрикс24.Документы.disk
Расчет вероятности успеха для лидов и сделок CRM (скоринг в CRM).ml

* Социальная сеть признана экстремистской и запрещена на территории Российской Федерации.



Продление лицензии коробочной версии Битрикс24

Внимание! C 14 марта 2022 года произошли изменения в лицензировании коробочной версии Битрикс24. Срок действия лицензии – 12 месяцев. С подробностями можно ознакомиться в статье.

Если же лицензия была куплена до 14 марта 2022 года и вы не продлили её согласно новым условиям лицензирования, то после окончания действия лицензионного ключа коробочная версия Битрикс24 продолжит работать в режиме [ds]ограниченной лицензии[/ds][di] В уроке перечислены функции, недоступные в ограниченном режиме. Ограниченный режим актуален для продукта Битрикс24 Коробочная версия, если этот продукт приобретен до 14 марта 2022 года и вы не продлили её согласно новым условиям лицензирования.

Подробнее...[/di].

Чтобы продолжить использование коробочной версии Битрикс24, необходимо [dw]заранее[/dw][di] Продлить лицензию можно за 60 дней до истечения срока действия текущей лицензии. [/di] приобрести продление действия лицензии на следующие 12 месяцев. Стоимость продления составляет 25% от стоимости лицензионного ключа.

После окончания срока действия лицензии через 15 дней коробочная версия Битрикс24 будет отключена.

  • При своевременном продлении срока действия лицензии вы увидите [dw]всплывающее окно[/dw][di]Если вы не успели заранее приобрести продление, то в течение 15 дней после окончания срока
    действия лицензии всплывающее окно будет выглядеть так:

    [/di] с выбором способа продления:

    • Продлить лицензию – при клике на кнопку вы попадёте на страницу корзины сайта 1с-bitrix.ru.

      После оплаты ваша лицензия будет автоматически продлена. На email, указанный при оформлении заказа, придёт соответствующее письмо об успешной активации.

      Всё, что вам останется сделать – это [dw]обновить систему SiteUpdate[/dw][di] Нажмите на рисунок, чтобы увеличить [/di] на странице Система обновлений (Marketplace > Обновление платформы).

    • Обратиться к партнёру (если лицензия приобреталась через компанию-партнёра 1С-Битрикс) – при выборе этого варианта вы попадёте в административный раздел портала и сможете заполнить и отправить [dw]заявку[/dw][di] Нажмите на рисунок, чтобы увеличить [/di] партнёру.
  • Если вы не продлили лицензию, то спустя 15 дней после окончания срока действия лицензии работа вашей коробочной версии Битрикс24 будет отключена полностью, и вы увидите следующее окно блокировки:

    Для возобновления работы нужно продлить лицензию, выбрав один из вариантов:

    • Продлить лицензию – при клике на кнопку вы попадёте на страницу корзины сайта 1с-bitrix.ru.

      После оплаты ваша лицензия будет автоматически продлена. На email, указанный при оформлении заказа, придёт соответствующее письмо об успешной активации.

    • Обратиться к партнёру (если лицензия приобреталась через компанию-партнёра 1С-Битрикс) – при выборе этого варианта откроется [dw]форма заявки[/dw][di] [/di] партнёру.

Важно! Если ваш Битрикс24 используется только в локальной сети и недоступен извне, то продление не произойдёт автоматически – вам нужно будет ввести [dw]код активации[/dw][di] [/di].



Система обновлений

В 1С-Битрикс: Управление сайтом система обновлений, как и техподдержка, осуществляется в течение года после регистрации приобретенной лицензии. Для получения в дальнейшем права на обновления необходимо оформить продление техподдержки и обновлений.

Коробочная версия Битрикс24 ограничена [ds]по сроку действия[/ds][di]C 14 марта 2022 года произошли изменения в лицензировании коробочной версии Битрикс24. Срок действия лицензии – 12 месяцев.

Подробнее на helpdesk.bitrix24.ru.[/di]. Спустя 15 дней после окончания срока действия лицензии работа вашей коробочной версии Битрикс24 будет отключена полностью, и работать с ней станет возможно только после [ds]продления лицензии[/ds][di] В уроке описываются способы продления лицензии и до истечения её срока действия, и после истечения срока.

Подробнее...[/di] на следующие 12 месяцев.

Примечание: Для получения обновлений демо-версии продукта, установленной на локальный компьютер, необходимо иметь доступ в Интернет.

Общие сведения

  Термины

Ядро продукта - каталог /bitrix/modules/, а также файлы системных компонентов: /bitrix/components/bitrix/ (пути везде задаются относительно корневой папки). Часто в понятие ядра продукта включается также структура базы данных продукта.

Служебная область - все подкаталоги каталога /bitrix/, за исключением ядра продукта и каталога /bitrix/updates/. Часто в понятие служебной области включаются также данные служебных таблиц базы данных.

Каталог системы обновлений - каталог /bitrix/updates/. Этот каталог предназначен исключительно для работы системы обновлений и не может использоваться в других целях.

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

Регистрация копии продукта - снятие с данной копии продукта ограничений, которые имеет демонстрационная версия (например, ограничение по времени работы).

Лицензионный ключ - последовательность символов, которая подтверждает право на использование копии продукта.

Купон на дополнительный сайт - последовательность символов, которая подтверждает право на создание одного дополнительного сайта в рамках данной копии продукта.

Сервер обновлений - сервер, который отдает обновления продукта системе обновлений. Адрес сервера обновлений задается на странице глобальных настроек главного модуля (должен иметь значение www.1c-bitrix.ru или www.bitrixsoft.com).

  Как работает система

Система обновлений не собирает и не передает никаких конфиденциальных данных копии продукта, на которой она работает. Она обменивается с сервером обновлений только техническими данными, необходимыми для корректной работы системы обновлений (например, текущие версии модулей или дата последнего обновления системы помощи).

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

Важно! Если вы самостоятельно изменили хотя бы один файл ядра продукта или структуру базы данных, то автоматическая установка обновления может иметь непредсказуемый результат.

Система обновлений производит технически сложную серьезную модификацию ядра продукта. Если эта модификация будет произведена с ошибками, то сайты, работающие на этом ядре, могут оказаться неработоспособными. Перед установкой обновлений рекомендуется убедиться в наличии резервной копии как базы данных, так и скриптов ядра продукта и служебной области. Рекомендуется для проведения процедуры обновления выбирать время, когда нагрузка на сервер минимальна. При возникновении проблем с установкой обновления вам необходимо незамедлительно обратиться в службу технической поддержки компании «1С-Битрикс».

  Страница системы обновлений

Установка обновлений выполняется со страницы Система обновлений (Marketplace > Обновление платформы).

Нажмите на рисунок, чтобы увеличить

Если на странице вывелось сообщение о том, что лицензионный ключ не верен (или лицензия не найдена), то установка не лицензирована и её надо зарегистрировать.

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

Если выводится сообщение о том, что доступно обновление самой системы обновлений, то необходимо установить это обновление. До установки этого обновления остальной функционал системы будет недоступен.

Если в систему введен валидный активный лицензионный ключ и установлено последнее обновление самой системы обновлений, то на странице системы обновлений доступны следующие действия:

  • Просмотреть и загрузить обновления модулей системы.
  • Просмотреть и загрузить языковые файлы.
  • Выполнить загрузку исходных текстов продукта, если позволяет лицензия. Перед загрузкой исходных текстов ядро продукта должно быть обновлено до последней версии (т.е. никакие обновления ядра продукта не должны быть доступны). Обратите внимание, что в случае медленного канала или большой загрузки сервера загрузка исходных текстов может занять некоторое время.
  • Выполнить активацию купона на продление технической поддержки, на добавление дополнительных сайтов или на переход на другую редакцию.
  • Включить или отключить установку бета-версий обновлений модулей.
  • Просмотреть журнал установки обновлений. Журнал содержит информацию о последних установленных обновлениях, включая информацию по статусам и ошибкам установки.

   Предупреждение об ошибке ERROR_WRONG_CODE

Ошибка ERROR_WRONG_CODE

Если обновление на текущем сервере повлечет за собой нарушение лицензионного соглашения, то на странице Система обновлений (Marketplace > Обновление платформы) до начала процедуры обновления появится сообщение [dw]ERROR_WRONG_CODE[/dw][di]Система обновлений продукта привязывается к конкретной установке и "запоминает" состояние системы после очередного обновления. Ошибка ERROR_WRONG_CODE возникает в том случае, если текущее состояние не соответствует тому, которое было на момент последнего обновления.
Подробнее...[/di]:

Нажмите на рисунок, чтобы увеличить

Для устранения ошибки необходимо обратиться в Техподдержку. Техническая поддержка по данному вопросу осуществляется в рабочие дни с 9 до 20 часов московского времени, кроме выходных и праздничных дней (по календарю праздничных дней РФ).

Как заранее узнать, возникнет ли при обновлении ошибка ERROR_WRONG_CODE?

Чтобы заранее узнать о невозможности проведения обновления на текущем сервере, рекомендуем в настройках Главного модуля (Настройки > Настройки продукта > Настройки модулей > Главный модуль) включить опцию Автоматически проверять наличие обновлений и установить временной интервал:

В случае невозможности установки обновлений появится соответствующее [dw]уведомление системы.[/dw][di] [/di]

Важно! Опция Автоматически проверять наличие обновлений на [ds]всех тестовых установках[/ds][di] Начиная с версии 16.5.7 и старше, в продуктах «1С-Битрикс» можно пометить новую или существующую установку продукта специальным маркером Установка для разработки. Маркер позволяет проводить тестирование, не устанавливая продукт локально. Этот функционал поможет решить проблему коллективного доступа к одной установке разработчиков продукта без возникновения ошибки ERROR_WRONG_CODE. Также эта функция будет полезна, если разработчиков несколько, и всем им нужна своя установка продукта для тестирования.

Подробнее...[/di] должна быть отключена. Исключение может быть сделано (но не рекомендуется) только для установки, используемой для тестирования обновлений перед их установкой на "боевой" (основной) сайт. В противном случае во время обновления основного сайта может возникнуть ошибка ERROR_WRONG_CODE, а установка обновлений будет прервана.

  Дополнительная информация



Настройки системы обновлений

Настройки системы обновлений осуществляются на вкладке Система обновлений страницы настроек Главного модуля (Настройки > Настройки продукта > Настройки модулей > Главный модуль)

syst_renew.png

  • Лицензионный ключ – указывается лицензионный ключ продукта. Если коммерческая версия была уже зарегистрирована, то в этом поле будет уже указан лицензионный ключ.
  • Установка для разработки – специальная опция для разработчиков, позволяющая устанавливать продукт без блокировки системы обновлений во время разработки.
  • Имя сервера, содержащего обновления – указывается адрес сервера. По умолчанию поле уже заполнено.
  • Использовать защищенное соединение https – при включении этой опции соединение с сервером обновлений будет производиться по защищенному протоколу.
  • Для настройки обновления продукта через прокси-сервер необходимо заполнить соответствующие поля:
    • Адрес прокси для системы обновлений;
    • Порт прокси для системы обновлений;
    • Имя пользователя прокси;
    • Пароль прокси.
  • Усиленная проверка корректности установки обновлений. Использование этой функции системы несколько замедляет процесс установки, но позволяет получить информацию об успешности копирования тех или иных файлов. В случае некорректной установки будет выведено сообщение с описанием ошибки.
  • Загружать только стабильные обновления – аналог опции Включить установку только стабильных версий на вкладке Дополнительно страницы Системы обновлений (Marketplace > Обновление платформы). Если эта опция выключена, то будут загружаться бета-версии.

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

  • Автоматически проверять наличие обновлений – система будет автоматически проверять выход новых обновлений с выбранной периодичностью.
  • Остановить автоматическую проверку при возникновении ошибок – при отмеченной опции при возникновении ошибок автоматическая проверка будет остановлена.
  • Использовать архиватор – при отмеченной опции файлы с обновлениями будут архивироваться.
  • Продолжительность шага пошаговой загрузки обновления (сек) – указывается продолжительность шага загрузки в секундах для пошаговой загрузки файлов.
Примечание: Для получения обновлений демо-версии продукта, установленной на локальный компьютер, необходимо иметь доступ в Интернет.

Дополнительная информация



Обновление ядра продукта

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

Для загрузки обновлений модулей системы выполните следующие действия:


  • Перейдите на страницу Система обновлений (Marketplace > Обновление платформы).
  • Для установки всех – нажмите кнопку [dw]Установить рекомендуемые обновления[/dw][di][/di].

Если вы не хотите устанавливать все обновления сразу, то на вкладке Список обновлений отметьте только те, что необходимо, и нажмите кнопку Установить обновления.

Важно! Обновления некоторые модулей имеют зависимости на обновления других модулей. Например, новый функционал модуля Торговый каталог может быть увязан с новинками модулей Валюты или Интернет-магазин. В этом случае, для частичного обновления, выбирайте все связанные модули, либо ни один из них. Удаление из списка одного связанного модуля приводит к автоматическому удалению всех остальных.

Если вы выполняете обновление модулей поочередно, а не всех сразу, то после установки каждой «порции» модулей вам необходимо воспользоваться кнопкой Проверить обновления и затем установить выбранные модули.


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

Примечание: Если обновление на текущем сервере повлечет за собой нарушение лицензионного соглашения, то на странице Система обновлений (Marketplace > Обновление платформы) до начала процедуры появится сообщение [dw]ERROR_WRONG_CODE[/dw][di] [/di] (подробнее читайте [ds]в уроке[/ds][di] Чтобы заранее узнать о невозможности проведения обновления на текущем сервере, рекомендуем в настройках Главного модуля (Настройки > Настройки продукта > Настройки модулей > Главный модуль) включить опцию Автоматически проверять наличие обновлений и установить временной интервал

Подробнее...[/di]).



Просмотр и загрузка языковых файлов

С помощью системы обновлений вы можете установить дополнительные [dwi include_lang]языковые файлы[/dwi] интерфейса. Для этого выполните следующее:

  • Перейдите на закладку [dw]Список обновлений[/dw][di][/di].
  • В секции опциональных обновлений отметьте необходимые языковые файлы.
  • Нажмите кнопку Установить обновления.

Контролировать процесс установки вы сможете по полосе прогресса. В результате будет выведено сообщение об успешной установке либо о возникших ошибках.


Примечание: Подробнее про установку и загрузку языков в систему смотрите в уроке Управление языками курсов Администратор. Базовый или Администратор сервиса Битрикс24 (коробочная версия).


Активация купона

  Дополнительные сайты

Система «1C-Битрикс: Управление сайтом» позволяет создавать несколько сайтов с применением одной копии (лицензии) продукта, размещая ядро и базу данных системы в единственном экземпляре на сервере. Максимальное количество сайтов на одной копии продукта ограничено лицензией только для редакции "Старт". На данный момент - это 2 сайта. Если необходимо создать дополнительные сайты сверх этих двух, то приобретите лицензии на дополнительные сайты.

  Смена редакции

Если вы уже используете «Старт», «Стандарт» или другую редакцию продукта 1C-Битрикс: Управление сайтом, то вы можете расширить возможности вашего сайта, осуществив переход на более высокую редакцию продукта. Для этого вам необходимо приобрести купон для перехода на нужную вам редакцию.

При смене редакции «Битрикс24» в коробке добавляется не только функционал, но и число пользователей.

  Продление лицензии

Чтобы всегда иметь доступ к последним обновлениям продукта и технической поддержке в 1С-Битрикс: Управление сайтом, необходимо по окончании периода активности обновлений приобрести купон на продление технической поддержки и получение обновлений.

Коробочная версия Битрикс24 ограничена [ds]по сроку действия[/ds][di]C 14 марта 2022 года произошли изменения в лицензировании коробочной версии Битрикс24. Срок действия лицензии – 12 месяцев.

Подробнее на helpdesk.bitrix24.ru.[/di]. Спустя 15 дней после окончания срока действия лицензии работа вашей коробочной версии Битрикс24 будет отключена полностью, и работать с ней станет возможно только после [ds]продления лицензии[/ds][di] В уроке описываются способы продления лицензии и до истечения её срока действия, и после истечения срока.

Подробнее...[/di] на следующие 12 месяцев.

  Как активировать купон

Купон активируется на закладке Активация купона страницы Система обновлений (Marketplace > Обновление платформы):



Типичные ошибки

При попытке обновления выдаётся ошибка "Ошибка соединения с сервером обновлений: [110] Connection timed out."

Ошибка свидетельствует о том, что скрипт обновления не может подключиться к серверу обновлений www.bitrixsoft.com на порт 80. Причины могут быть следующие:

  • недоступны функции работы с сокетами, в частности, fsockopen();
  • на сервере запрещены исходящие соединения к 80 порту;
  • недостаточный объем памяти на сервере (Часто проявляется на VPS с виртуализацией OpenVZ и 256 Мб RAM.);
  • проблема в работе сети.

Вам необходимо обратиться к администратору сервера, предоставив описание ошибки.


Ошибка при обновлении: [SITE_LICENSE_VIOLATION] Превышено количество лицензированых сайтов

Эта ошибка свидетельствует о том, что в системе либо не зарегистрировано ни одного сайта, либо все сайты деактивированы, либо превышено количество активных сайтов, разрешенных текущей лицензией.

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


Ошибка при обновлении [ERROR_WRONG_CODE]

Система обновлений продукта привязывается к конкретной установке и "запоминает" состояние системы после очередного обновления. Ошибка возникает в том случае, если текущее состояние не соответствует тому, которое было на момент последнего обновления. Этот механизм призван пресечь попытки обновления на одном лицензионном ключе неограниченного количества установок продукта.

Согласно лицензионному соглашению, на каждый лицензионный ключ допускается две установки системы: одна публичная и одна локальная (для разработчика), но недоступная из Интернета. С учетом этого система настроена так, что сохраняет данные о двух установках. При этом, если не переносить копию с локальной машины на сервер и назад - можно обновлять независимо обе копии, проблем не возникнет. Если же вам необходимо переносить продукт на локальную машину, то следует обновлять только одну копию из двух: либо на сервере, либо локальную (зависит от ваших предпочтений).

Аналогичным образом следует поступать при переносе сайта на новый сервер: скопировать структуру файлов и БД на новый сервер, после этого, не обновляя продукт на старом, удалить его сразу после обновления DNS.


Ошибка Class 'CUpdateExpertMode' not found

Ошибка на странице обновлений:

Class 'CUpdateExpertMode' not found (0)
/app/www/bitrix/modules/main/admin/update_system.php:50
#0: require_once /app/www/bitrix/admin/update_system.php:2

При этом класс CUpdateExpertMode определен в /bitrix/modules/main/classes/general/update_client.php.

Ситуация связана с влиянием OpCache. Параметр opcache.validate_timestamps (/etc/php.d/opcache.ini) имеет значение 0, должно быть: On.


Перенос продукта

Особенности платформы Bitrix Framework в плане хостинга

  • Наличие достаточного места на диске для создания большого количества файлов. Сегодня минимальное требование для проекта с большим числом картинок — от 300 Мбайт. (Важно помнить, что каждая картинка также занимает место на диске, а в большом проекте таких картинок может быть очень много.)
  • Наличие необходимых ресурсов на сервере — памяти, выделяемой скриптом, наличие акселератора PHP и некоторых других настроек. Необходимо как минимум 128 Мбайт памяти, выделяемой для PHP, чтобы могли работать серьезные проекты (например, интернет-магазины). Она расходуется на построение структуры данных и выполнение кода при вызове каждой страницы сайта.
  • Желательность двухуровневой архитектуры для работы сайтов с высокой посещаемостью или серверов с высокой загрузкой. Для этого устанавливается дополнительный веб-сервер (обычно NGINX), который принимает все запросы. Это позволяет стабилизировать использование памяти за счет ограничения числа процессов Apache и получить отказоустойчивую систему.
  • Достаточно быстрый сервер баз данных. Для работы сайтов необходимо, чтобы сервер баз данных успевал обрабатывать запросы за короткое время.
  • Желательность работы PHP и FTP/SSH от одного и того же пользователя. При разработке сайта обычно работают с файлами по FTP/SFTP-протоколу. Вместе с тем при работе в самой системе она создает файлы от имени того пользователя, под которым работает PHP. При несовпадении этих пользователей могут возникнуть серьезные проблемы в работе сайта или в возможностях его модификации.

Во многом соответствие сервера требованиям системы можно протестировать модулем Монитор производительности.

Для успешной установки и полноценной работы продукта необходимы следующее:

  • Установка может быть сделана только в корневую папку веб сервера.
  • Необходимо использовать веб сервер Apache 2.0 и выше.
  • Хостер должен разрешать использование .htaccess.
  • Необходимо использовать PHP не ниже версии 8.0 (Рекомендуется 8.1 и выше).
  • safe_mode должен быть отключен (инсталлятор блокирует установку продукта в этом режиме).
  • short_open_tag включён.
  • memory_limit не ниже 32 Мб для редакции "Старт", не менее 64 Мб для редакции "Бизнес".
  • Наличие функций работы с сокетами для обновления продукта.
  • Наличие библиотек: Zlib (компрессия - для ускорения загрузки обновлений), GD lib (отображение графиков), Free Type (работа CAPTCHA).
  • Версия MySQL 5.7 и выше.
  • Обязательно использование акселератора PHP (поддерживается акселератор OPcache).
  • режим работы PHP как модуля Apache предпочтительнее (CGI настоятельно не рекомендуется, так как он не поддерживает работу акселератора. Лучше использовать FastCGI.)
Примечание: не рекомендуется использовать модуль suhosin или mod_security т.к. в ряде случаев эти модули препятствуют нормальной работе продуктов.

Продукты Bitrix Framework поставляются в исходных кодах. Поэтому нет необходимости в модулях zend optimizer или zend guard loader.

Протестировать конфигурацию сервера можно специальным скриптом bitrix_server_test.php, который необходимо запустить на своём сервере.

Примечание: Можно ознакомиться с примером анализа производительности PHP.

Рекомендуется ознакомиться с отзывами клиентов о хостингах в группе Черный и белый список хостингов социальной сети компании "1С-Битрикс".

Перенос продукта «1C-Битрикс»

  Предварительная подготовка

Для переноса сайта с локальной машины на удаленный хостинг или с одного удаленного хостинга на другой при помощи встроенной функции резервного копирования и специального скрипта restore.php, необходимо предварительно:

  • Проверить:
    • соответствие удаленного хостинга минимальным техническим требованиям продукта;
    • наличие прав не ниже (0644 – для файлов и 0755 для папок) на все файлы в корне сайта у пользователя, под которым работает Apache (PHP).
  • При наличии активной лицензии настоятельно рекомендуется обновить исходную копию продукта до последней версии.

  Архив сайта

Следующий шаг - создание архива сайта. Выполнить действия по созданию архива можно на странице Резервное копирование (Настройки > Инструменты > Резервное копирование). Подробнее о создании архива сайта см. в уроках Резервное копирование курсов Администратор. Базовый и Администратор «Битрикс24 в коробке».

  Перенос сайта

После этого можно непосредственно приступать к переносу сайта. Выполните действия в следующем порядке:

  1. Загрузите файл с архивом в корневую директорию сайта на удаленном сервере или на локальной машине в зависимости от того, откуда и куда вы переносите сайт. Если исходный сайт доступен из интернета, то лучше скачивать архив с дальнего сервера. При этом скачиваются все части архива автоматически. При переносе с локального на хостинг надо будет вручную положить все части рядом с restore.php.

    Важно! Если файл архива содержит в себе полную копию сайта (и ядро, и публичную часть), то на сервере систему «1C-Битрикс» устанавливать не нужно.

  2. Скачайте скрипт restore.php, который доступен по ссылке в справке [dw]внизу страницы[/dw][di][/di] Список резервных копий (Настройки > Инструменты > Резервное копирование > Список резервных копий), либо с помощью [dw]wget[/dw][di]wget -b https://www.1c-bitrix.ru/download/scripts/restore.php[/di]. Загрузите скрипт на сервер в корень сайта.
  3. Примечание: По этой ссылке расположен скрипт, соответствующий вашей версии дистрибутива. Свежую версию скрипта можно всегда скачать с сайта 1С-Битрикс.

  4. В адресной строке браузера наберите http://ваш_сайт/restore.php. Откроется [dw]первое окно[/dw][di][/di] мастера. Нажмите кнопку Далее.
  5. В открывшемся диалоговом окне выберите нужный вариант расположения файла с архивом и нажмите кнопку Далее.

    Примечание: Пункты Архив загружен в корневую папку сервера и Архив уже распакован появятся, когда архив будет скопирован или распакован в корень сайта соответственно.

    При размещении архива в облаке

  6. После скачивания архива будет предложено [dw]указать пароль[/dw][di][/di] (если архив был зашифрован на этапе резервного копирования) для распаковки файлов:
  7. После завершения распаковки файлов необходимо будет указать настройки соединения с базой данных, если при создании резервной копии был создан дамп базы данных.

    Укажите необходимые параметры, нажмите кнопку Восстановить и ждите завершения работы сценария.
  8. После успешной распаковки в открывшемся [dw]диалоговом окне[/dw][di][/di] нажмите кнопку Удалить локальную копию и служебные скрипты:

    Во избежание повреждения сайта или утечки информации будут удалены файлы:

    • /restore.php
    • /файл резервной копии (файл с расширением .tar.gz или .enc)
    • /bitrix/backup/дамп базы (файл с расширением .sql)
  9. Восстановление завершено.

Некоторые особенности:
  • Если в качестве WEB-сервера используется IIS, то учтите, что файл web.config также архивируется. Необходимо удалить извлеченный из архива файл web.config. Ваш сервер создаст новый под себя.
  • После переноса может не работать ЧПУ. В этом случае надо переименовать .htaccess.restore в .htaccess.
  • Если восстанавливается архив сделанный на демоверсии, то демопериод [dw]сохраняется[/dw][di]Срок демоверсии фиксируется в БД, поэтому при переносе вместе с данными БД переносится и срок демоверсии. Например, если при создании архива оставался 1 день демопериода, то при восстановлении в этот же день на следующий день демопериод закончится.[/di].


Примечание: О восстановлении сайта в административном интерфейсе можно прочитать в одноименном уроке здесь.



Перенос сайтов в многосайтовой конфигурации

Видеоурок

Лицензия допускает создание двух и более сайтов на одном экземпляре системы. Перенос системы на другой хостинг в двухсайтовой конфигурации имеет свои особенности.

  Порядок действий

Прежде всего, многосайтовость должна быть настроена на разных доменах.

Во-вторых, несколько меняется общий порядок действий:

  1. Создайте резервную копию главного сайта с ядром, файлами и базой:

  2. Перенесите главный сайт через restore.php.
  3. Создайте резервную копию второго и других сайтов без ядра и базы, только файлы. При создании копии исключите из архива папки /bitrix и /upload:

  4. Перенесите второй и другие сайты через restore.php.
  5. С помощью файла symlink.php сделайте связку с первым сайтом.
  6. Настройте пути и доменные имена для каждого сайта:

Возможные ошибки при переносе сайта

  Перенос сайта нештатными средствами

Перенос сайта на хостинг лучше всего выполнять встроенными в Bitrix Framework средствами резервного копирования/восстановления.

Несмотря на то, что фактически сайт на «1С-Битрикс: Управление сайтом» представляет из себя набор файлов и базу данных, копирование файлов напрямую на удаленный сервер в большинстве случаев будет не верным решением. Из-за большого количества мелких файлов такое копирование может растянуться на несколько часов. Кроме того, использование стандартных механизмов позволяет избежать последующих возможных проблем с правами доступа к файлам сайта.

Среди часто возникающих проблем:

  1. Веб-сервер не может записать в нужную ему папку или удалить временные файлы. Возможные последствия:

    • невозможность обновления продукта;
    • невозможность редактировать сайт через веб-интерфейс;
    • некорректная работа компонента кэширования;
    • и другие проблемы.

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

      Самым простым решением в этом случае будет установка прав на все файлы и папки 777 (для Unix платформы) либо любой другой способ дать PHP запись на эти файлы.

  2. Нет возможности отредактировать через ftp/ssh файлы, созданные через веб-интерфейс. В этом случае многим веб-разработчикам будет сложно дорабатывать сайт.

    Одним из простых, но не всегда работающих решений, является установка параметров в файле dbconn.php, позволяющих всем редактировать создаваемые через Bitrix Framework файлы.

    define("BX_FILE_PERMISSIONS", 0666);
    define("BX_DIR_PERMISSIONS", 0777);

    Однако для файлов, созданных через ftp/ssh, вам придется периодически изменять права вручную. Либо, если хостинг это поддерживает, устанавливать параметр umask.

  3. 500 ошибка, вызываемая после распаковки не через restore.php, а из серверного бекапа:
    PHP Fatal error:  Unknown: Failed opening required '/home/bitrix/www/bitrix/modules/security/tools/start.php' (include_path='.:/usr/share/pear:/usr/share/php') in Unknown on line 0

    Она вызывается если в корневом .htaccess прописан путь:

    auto_prepend_file  = /home/bitrix/www/bitrix/modules/security/tools/start.php

    а реально бекап разворачивается в /home/bitrix/ext_www/sitename.ru, например.

  Настройки PHP

При переносе сайта на хостинг могут возникнуть различные нюансы из-за настроек PHP:

  • Проблемы с несоответствием владельца файлов: на ряде хостингов PHP работает от имени одного пользователя, а доступ по ftp/ssh предоставлен другому. В этом случае файлы, созданные одним методом, могут быть недоступны для модификации, или вообще вызывать ошибку выполнения из-за нарушения параметров безопасности.
  • Проблемы с настройками безопасности: возможны различные варианты подключения PHP к веб-серверу, и в некоторых из этих вариантов устанавливаются жесткие ограничения на владельца файла и права на файл. В этом случае возможны ошибки с кодом 500, и разобраться в проблеме вам поможет только журнал ошибок веб-сервера.

    Пример: На многих хостингах, если PHP подключен как CGI, требуется соответствие владельца файла и прав на файл. Если владелец файла – не ваш аккаунт или права на файл допускают запись всем пользователям, PHP будет вызывать ошибку. В этом случае необходимо установить корректные права на файлы и папки, а также правильные параметры в dbconn.php.

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

    Пример: особо чувствительны к размеру памяти и времени выполнения различные скрипты импорта-экспорта данных. Если у вас возникают ошибки – проверяйте доступность ресурсов на хостинге, в случае их нехватки смените хостера.

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

  Возможные проблемы при работе с многосайтовостью в Bitrix Framework

Проверьте, что ваш хостинг позволит организовать многосайтовость выбранным вами методом. Не все провайдеры позволяют корректно (для Bitrix Framework) создавать дополнительные сайты. Информацию об способах организации многосайтовости можно получить в учебном курсе Многосайтовость.

Проблемы с почтой

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

Распакованный сайт недоступен

После распаковки резервной копии на всём сайте отображается только форма авторизации. Возможные причины и решения:

  • Некорректное значение поля Путь к корневой папке веб-сервера для этого сайта в настройках сайтов (Настройки > Настройки продукта > Сайты > Список сайтов).

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

  • Если перенос осуществлялся простым копированием файлов (FTP/SSH), мог не скопироваться файл .access.php. В данном файле хранятся права доступа групп пользователей к сайту, если данного файла нет, то для всех пользователей устанавливается право Запрещено.

    Решение 1: в корень сайта положить файл .access.php с содержимым:

    <?  $PERM["/"]["*"]="R"; ?>

    либо

    Решение 2: через файловый менеджер продукта в свойствах корневой папки сайта на вкладке Доступ установить для группы Все пользователи (в том числе неавторизованные) право Чтение.

Не полный архив

При просмотре архива, созданного штатной системой резервного копирования, через WinRar видно, что файлов в архиве гораздо меньше, чем на сайте.

Причина: дело в том, что у формата tar есть несколько диалектов. Система пакует архив в формате GNU tar, как это делает по умолчанию tar в Linux. WinRar понимает tar, но конкретно этот диалект поддерживает не полностью.

Резервный архив должен распаковываться системным restore.php, скачанным со страницы резервного копирования. Если и в этом случае часть файлов утеряна, проблему следует решать через техподдержку.

Ошибка ERROR 1062 (23000)

При распаковке резервной копии происходит ошибка: ERROR 1062 (23000) at line 1247: Duplicate entry '2-?' for key 2.

Причина: Ошибка происходит, если кодировка, в которой сделан архив, отличается от используемой на новом сервере баз данных.

  • Кодировка архива устанавливается в зависимости от содержимого файла /bitrix/php_interface/after_connect.php, например:
    <?
    $DB->Query("SET NAMES 'utf8'");
    ?>
    т.е архив будет создаваться в кодировке utf8.
  • Кодировку сервера баз данных можно увидеть в параметре character_set_server после выполнения SQL-запроса:
    show variables where Variable_name = 'character_set_server';

Обойти или устранить эту ошибку можно двумя способами:

  • В настройках нового сервера баз данных изменить кодировку в параметре character_set_server на ту, в которой сделан архив.

    Внимание! За выполнением этой операции возможно придется обратиться к администратору сервера.

  • Можно открыть архив в текстовом редакторе и в самое начало вставить строку:
    SET NAMES `utf8`;
    Кодировка выбирается в зависимости от кодировки архива.

    Внимание! Этот способ работает только в случае небольших дампов (которые успевают импортировать за один шаг).

Ошибки в .htaссess

Часть ошибок (например: ошибка 404 при переходе подробную информацию новостей), возникающих при переносе сайтов связана с тем, что при переносе файл .htaссess переименовывается с добавлением "_". Для решения проблемы достаточно проверить имя файла и, при обнаружении ошибки, восстановить его.



Дополнительные моменты

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

Удаление приложения

Удаление приложения на удаленном компьютере состоит в удалении базы данных и всех файлов и папок из корневой папки вашего веб-сервера.

Необходимый уровень прав на сервере

Настройка прав на сервере хостинг-провайдера может быть индивидуальна, но прежде всего должны быть установлены права на чтение/запись из скрипта для пользователя, под которым запущен веб-сервер Apache.

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

Проблема в том, что у каждого хостинг-провайдера своя политика безопасности и свои настройки.

На некоторых хостингах процесс сервера запускается по умолчанию под пользователем nobody:группа. Файлы, которые пользователь хостинга хранит на своей машине, должны быть доступны Apache. Это означает, что они либо имеют атрибут чтение для всех, либо же пользователь-владелец файлов обязан принадлежать к той же самой группе, что и сервер. В последнем случае файлы должны быть доступны для чтения членами группы (именно такие права для них устанавливают по умолчанию FTP-серверы). При таком подходе страдает безопасность: раз все пользователи принадлежат к одной и той же группе, то они могут читать файлы друг друга.

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

«1С-Битрикс: Управление сайтом» работает с любым уровнем прав, который вы указали ему при настройке (установке).

Чтобы продукт корректно работал с папками и файлами с заданным CHMOD (писал и создавал), вам нужно установить в /bitrix/php_interface/dbconn.php следующие константы:

define("BX_FILE_PERMISSIONS", 0644); 
define("BX_DIR_PERMISSIONS", 0755);

Это типовые настройки прав на большинстве хостингов. Если возникают какие-то проблемы с работой, то обращайтесь в техническую поддержку вашего хостинга.

Самостоятельно установить нужный уровень прав можно, используя команду CHMOD в консольном режиме.

Следующий вызов устанавливает уровень прав доступа и для файлов, и для папок:

chmod -R 644 *

Для установки прав только на папки можно использовать следующий код:

find . -type d -exec chmod 0755 {} ';'

Если надо установить разные права на папки и файлы, то выполните следующий скрипт:

<?php 
define("BX_FILE_PERMISSIONS", 0644); 
define("BX_DIR_PERMISSIONS", 0755); 

function chmod_R($path) { 

   $handle = opendir($path); 
   while ( false !== ($file = readdir($handle)) ) { 
     if ( ($file !== ".") && ($file !== "..") ) { 
       if ( is_file($path."/".$file) ) { 
         chmod($path . "/" . $file, BX_FILE_PERMISSIONS); 
       } 
       else { 
         chmod($path . "/" . $file, BX_DIR_PERMISSIONS); 
         chmod_R($path . "/" . $file); 
       } 
     } 
   } 
   closedir($handle); 
} 

$path=dirname(__FILE__); 
umask(0); 
chmod_R($path); 
echo $path; 
?>

Для установки рекурсивно прав раздельно на файлы и папки можно использовать некоторые программы FTP клиентов. Например, FlashFXP версии 3.хх.

FlashFXP позволяет также разделять права для файлов и папок, но выполняет смену прав медленнее.

Обратите внимание на установки соответствующих флагов:

Separately set File and Folder attributes (Раздельно устанавливать права на файлы и папки); 
Apply changes to all subfolders and files (Рекурсивная установка прав на подпапки и файлы) 

Для каждой из установок настраивается свой уровень:

 
Установка прав на папки   Установка прав на файлы

Обратите внимание! Модуль Управление структурой позволяет просмотреть права на доступ к файлам и папкам, установленные на уровне системы.

При просмотре файловой структуры в Менеджере файлов в столбце Права на доступ отображается уровень прав на доступ к файлам и папкам, информация о владельце и группе пользователей (для *NIX).

Использование файлов .htaccess

  Файл .htaccess

.htaccess (от англ. hypertext access) - файл дополнительной конфигурации веб-сервера Apache. Позволяет задавать большое количество дополнительных параметров и разрешений для работы веб-сервера в отдельном каталоге без изменения главного конфигурационного файла httpd.conf.

Файл .htaccess является подобием httpd.conf с той разницей, что действует только на каталог, в котором располагается, и на его дочерние каталоги. Файл .htaccess может быть размещен в любом каталоге. Директивы этого файла действуют на все файлы в текущем каталоге и во всех его подкаталогах, если только эти директивы не переопределены директивами нижележащих файлов .htaccess. Для того, чтобы файлы .htaccess можно было использовать, необходимы соответствующие настройки главного конфигурационного файла httpd.conf (значение директивы AllowOverride должно быть установлено как All). Пути к файлам и каталогам должны указываться от корня сервера.

При внесении изменений в файл .htaccess нет необходимости перезапускать сервер. Файл .htaccess проверяется при каждом обращении к серверу, так что изменения вступают в силу сразу после их внесения. Так как файл является служебным, он не доступен пользователям из веб-браузера.

Обратите внимание! При установке на шаге предварительной проверки производится проверка обработки файлов .htaccess.

В демонстрационном сайте файл .htaccess по умолчанию содержит следующие директивы:

Options -Indexes 
ErrorDocument 404 /404.php

<IfModule mod_php5.c>
  php_flag session.use_trans_sid off
  #php_flag default_charset UTF-8
  #php_value display_errors 1
</IfModule>

<IfModule mod_php7.c>
  php_flag session.use_trans_sid off
  #php_flag default_charset UTF-8
  #php_value display_errors 1
</IfModule>

<IfModule mod_rewrite.c>
  Options +FollowSymLinks
  RewriteEngine On
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-l
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteCond %{REQUEST_FILENAME} !/bitrix/urlrewrite.php$
  RewriteRule ^(.*)$ /bitrix/urlrewrite.php [L]
  RewriteRule .* - [E=REMOTE_USER:%{HTTP:Authorization}]
</IfModule>

<IfModule mod_dir.c>
  DirectoryIndex index.php index.html
</IfModule>

<IfModule mod_expires.c>
  ExpiresActive on
  ExpiresByType image/jpeg "access plus 3 day"
  ExpiresByType image/gif "access plus 3 day"
  ExpiresByType image/png "access plus 3 day"
  ExpiresByType text/css "access plus 3 day"
  ExpiresByType application/javascript "access plus 3 day"  
</IfModule> 

Внимание! Для активизации закомментированных PHP директив необходимо снять знак комментария (#) в начале строки. Если на вашем сервере Apache не установлено разрешение на использование PHP-флагов, выполнение данных директив приведет к возникновению внутренней ошибки (500). В случае возникновения ошибки необходимо снова закомментировать директивы, поместив в начало каждой знак #.

Для остальных PHP директив, не обозначенных знаком комментария (#), добавлена проверка на наличие необходимых модулей Apache в системе. Выполнение данных директив не приведет к возникновению ошибки в системе.

  1. PHP директива php_flag session.use_trans_sid off производит отключение подстановки идентификатора сессии в ссылке на сайте.
  2. Значение PHP флага php_value display_errors 1, указывает на то, что включено разрешение на вывод сообщений о возникновении ошибок. Директива php_value error_reporting определяет уровень ошибок, при возникновении которых будет выводиться сообщение. С помощью указанных директив можно настроить режим вывода интерпретатором PHP сообщений об ошибках.
  3. Блок директив IfModule mod_rewrite.c - это настройка правил для mod_rewrite.
  4. Директива ExpiresActive on включает кеширование изображений, позволяющее ускорить их загрузку при повторном обращении к страницам сайта.
  5. Директивы ExpiresByType image/jpeg "access plus 3 day", ExpiresByType image/gif "access plus 3 day", ExpiresByType image/png "access plus 3 day", ExpiresByType text/css "access plus 3 day", ExpiresByType application/javascript "access plus 3 day" в свою очередь, определяют формат изображений, стилей, скриптов и срок, на который будет произведено кеширование. По умолчанию, выполняется кеширование файлов формата .jpeg, .gif, .png, css и .js сроком на 3 дня.
Внимание! После внесения изменений, файл .htaccess должен быть сохранен в UNIX-формате (для оболочки FAR опция Сохранить как UNIX-текст).

  Авторизация в режиме CGI

В некоторых случаях может не работать авторизация при обмене данными с 1С. Часто проблема возникает в результате работы php в режиме CGI. В этом режиме есть проблемы с передачей данных авторизации HTTP в php. Можно это проверить, посмотрев phpinfo() в разделе Server API: CGI.

Можно обойти проблему, но необходимо чтобы на сервере была включена обработка .htaccess и поддержка mod_rewrite. Для этого выполните следующие действия:

  • В корне сайта в файл .htaccess добавьте строки:
        RewriteEngine on
        RewriteRule .* - [E=REMOTE_USER:%{HTTP:Authorization},L]
  • Закоментируйте следующие строки в файле bitrix/admin/.htaccess, которые отключают mod_rewrite:
        #<ifmodule mod_rewrite.c="">
        # RewriteEngine Off
        #</ifmodule>
  • В файл bitrix/php_interface/dbconn.php добавьте строки:
        $remote_user = $_SERVER["REMOTE_USER"] 
        ? $_SERVER["REMOTE_USER"] : $_SERVER["REDIRECT_REMOTE_USER"];
        $strTmp = base64_decode(substr($remote_user,6));
        if ($strTmp)
            list($_SERVER['PHP_AUTH_USER'], $_SERVER['PHP_AUTH_PW']) = explode(':', $strTmp);

Для проверки работоспособности HTTP-авторизации воспользуйтесь скриптом.

Внимание! Данный вариант обхода не всегда может решить проблему. Если при выполнении всех рекомендаций HTTP-авторизация не заработала, то следует детально разбираться с проблемой.


Ошибки подключения к БД

При возникновении ошибки подключения к базе данных на экран выдается сообщение вида:

Для решения проблемы следует:

  • проверить параметры подключения к базе данных (файл /bitrix/php_interface/dbconn.php до версии 20.900.0 и файл /bitrix/.settings.php с версии 20.900.0);
  • проверить доступность базы данных.

Внешний вид сообщения об ошибке определяется в файле /bitrix/modules/main/include/dbconn_error.php:

<br>
<table cellpadding="1" cellspacing="0" width="35%" bgcolor="#9C9A9C">
	<tr>
		<td><table cellpadding="5" cellspacing="0" width="100%">
			<tr>
				<td bgcolor="#FFFFFF" align="center"><FONT face="Verdana, Arial, Helvetica, sans-serif" size="-1">
				<font color="#FF0000"><b><?echo "Error connecting to database."?></b></font><br>Please try again.</font></td>
			</tr>
		</table></td>
	</tr>
</table>	
<br><br><br>

Для проверки доступности базы данных можно использовать, в частности, MySQLGUI - интерфейс управления для Windows, доступный для скачивания на странице http://www.mysql.ru/download/.

Ошибки запросов к БД

Иногда возникает ситуация, когда сайт перестает отвечать, и посетителям отображается пустая страница. В этом случае рекомендуется открыть файл bitrix/php_interface/dbconn.php и установить значение параметра $DBDebug = true;

<?
define("DBPersistent", true);
$DBType = "mysql";
$DBHost = "localhost:31006";
$DBLogin = "root";
$DBPassword = "";
$DBName = "bsm_demo";
$DBDebug = true;
$DBDebugToFile = false;

set_time_limit(60);

define("BX_FILE_PERMISSIONS", 0644);
define("BX_DIR_PERMISSIONS", 0755);
@ini_set("memory_limit", "64M");
?>

В результате будет получен код ошибки, содержащий, как правило, названия поврежденных таблиц базы данных.

Запуск утилиты perror.exe с кодом ошибки (файл perror.exe хранится в каталоге mysql/bin) позволяет получить описание ошибки по ее коду:

Примечание: Для ошибки с кодом 28 выводится следующее описание:

Данное сообщение означает, что на диске, где установлена база данных, недостаточно места для ее работы.

Если речь идет о повреждении базы данных, то рекомендуется воспользоваться встроенным инструментом системы для проверки и восстановления базы данных. Использование скрипта проверки и восстановления базы данных позволит оперативно восстановить работу сайта.

Обратите внимание на следующее:
  • Скрипт проверки и восстановления базы данных может быть использован только для MySQL с типом таблиц [dw]MyISAM[/dw][di]Для таблиц типа InnoDB неактуальна сама проблема поломки таблиц, поэтому для них нет инструмента.[/di].
  • Скрипт проверки запускается из административного раздела сайта Настройки -> Инструменты -> Проверка БД:

    В случае, если повреждены таблицы статистики и нет возможности перейти в административный раздел, сбор статистики может быть временно отключен с помощью параметра ?no_keep_statistic_LICENSE-KEY=Y. В параметре указывается лицензионный ключ сайта.

  • Существует возможность использования скрипта проверки и восстановления базы данных без перехода в административный раздел.

    Для этого при обращении к странице восстановления необходимо указать два параметра: имя (login) и пароль (password) на доступ к базе данных. Например: http://www.mysite.ru/bitrix/admin/repair_db.php?login=DB_Login&password=DB_Password. По умолчанию значения данных параметров хранятся в файле /bitrix/php_interface/dbconn.php.

Проблема:

На экран выводится ошибка:

MySQL Query Error: ….. [Out of memory restart server and try again (needed 65528 bytes)]

Решение:

Необходимо увеличить объем памяти в настройках MySQL.

Рекомендуется использовать следующие параметры MySQL, задавая их в конфигурационном файле MySQL my.cnf:

key_buffer = 128K
max_allowed_packet = 16M
table_cache = 4
sort_buffer_size = 128K
read_buffer_size = 128K
read_rnd_buffer_size = 128K
net_buffer_length = 128K
thread_stack = 128K

После изменения параметров необходимо будет перезагрузить MySQL.

500 - Internal Server Error

Ошибка сервера может быть вызвана различными причинами, поэтому ее диагностика достаточно сложна и трудоемка. Это не является ошибкой «1С-Битрикс: Управление сайтом». Она часто возникает на разделяемом хостинге из-за ограничения ресурсов системы.

При возникновении ошибки сервера в первую очередь необходимо просмотреть файл сервера error.log. В этом файле может содержаться строка с кодом ошибки.

  • Типичным примером причины возникновения ошибки сервера может быть превышение разрешенных прав на хостинге.

    Например, происходит попытка выполнить файл с атрибутами, не разрешёнными для запуска на сервере (например, файл имеет атрибуты 0755, а допускается 0711).
  • Также возможной причиной может быть наличие лимита по времени на исполнение php-скриптов;
  • Или у системы нет прав на запись или чтение файла и др.
  • Другой распространенной причиной возникновения внутренней ошибки сервера является нарушение конфигурации сервера или попытка использования неразрешенных инструкций, например, в файле .htaccess. В этом случае необходимо закомментировать либо удалить строку, содержащую неразрешенную директиву, в соответствующем файле (например, .htaccess).
  • Обратите внимание, если PHP работает как CGI, то 500 ошибка на сервере может быть вызвана фатальной ошибкой PHP. В этом случае рекомендуется выполнить проверку программного кода и диагностировать ошибку.
  • Внутренняя ошибка сервера может возникнуть при запуске из-под Apache CGI-скрипта, время исполнения которого превышает время, отведенное на выполнение скрипта в настройках сервера.

Таким образом, всё зависит от конфигурации сервера.

Важно понимать, указанные ограничения не настраиваются через настройки PHP в php.ini.

В нормальной ситуации такая ошибка и её причина фиксируется в логах сервера. В этом случае пользователю рекомендуется обратиться к хостеру с просьбой указать, что является причиной возникновения ошибки и попросить её устранить (например, увеличить ресурсы). Если хостер не смог найти решение - обратитесь в техподдержку компании «1С-Битрикс» с точным указанием того, как ошибка происходит и какие причины указал хостер. Без указания причины ошибки техподдержка помочь вам не сможет.

Виртуальная машина VMBitrix v7.x

Состав
«1C-Битрикс: Виртуальная машина»

«1C-Битрикс: Виртуальная машина» - бесплатный программный продукт, готовый к немедленному использованию виртуальный сервер, полностью настроенный, протестированный и адаптированный для оптимальной работы как с продуктами «1С-Битрикс», так и с любыми PHP-приложениями.

Виртуальная машина сэкономит время и силы на правильное развертывание и администрирование сайта или внутреннего информационного ресурса на базе продуктов «1С-Битрикс».

С помощью специальных ВМ-решений вы можете быстро получить оптимально сконфигурированный сервер, не уступающий по производительности VMBitrix, а по масштабируемости - превосходящий виртуальную машину «1С-Битрикс». Пакеты подготовлены специалистами «1С-Битрикс» и доступны для скачивания и использования.

В «1C-Битрикс: Виртуальная машина» входит:

  • mysql-server 5.*
  • web-server (Apache 2.4.*)
  • php 7.х, 8.x
  • nginx 1.20
  • memcached
  • stunnel
  • catdoc
  • xpdf
  • munin
  • nagios
  • sphinx


Решения для оптимизации
установки продуктов «1С-Битрикс»

  1. «1С-Битрикс: Веб-окружение» - Linux (BitrixEnv)

    «1С-Битрикс»: Веб-окружение» - Linux служит для быстрой и простой установки всего ПО, необходимого для работы продуктов и решений «1С-Битрикс» на Linux-платформе CentOS 7 (x86_64).

    Скачать bitrix-env.sh.

  2. «1C-Битрикс: Виртуальная машина 7.x»

    «1C-Битрикс: Виртуальная машина 7.x» специально сконфигурирована для быстрого исполнения программных продуктов «1С-Битрикс»: разворачивается за минуты и сразу же готова к работе! На виртуальную машину можно не только установить ознакомительные версии продуктов «1С-Битрикс», но и перенести свои, уже готовые проекты.

    Дистрибутивы VMBitrix доступны для:

    • VMWare;
    • OVA (Sphere и др);
    • VirtualBox;
    • HyperV.

    Скачать образы.

  3. Amazon Elastic Compute Cloud (Amazon EC2)

    Amazon EC2 - это веб-сервис, предоставляющий масштабируемые вычислительные мощности и созданный для быстрого и простого разворачивания веб-приложений на площадках (в облаках) Amazon. Специалистами «1С-Битрикс» подготовлены предконфигурированные образы VMBitrix (AMI-образы) для быстрого запуска приложений «1С-Битрикс» в Amazon EC2, которые включают:

    • CentOS 7.x;
    • NGINX + Apache2;
    • PHP 7.х, 8.x;
    • MySQL5 with InnoDB support;
    • Mail server agent;
    • UNIX-like Control Menu with common tasks;
    • IP address via DHCP, or configured by Amazon Elastic IP;
    • HTTPS support.

    Список ami-образов по регионам можно посмотреть на странице VMBitrix.



Работа с файлами
в BitrixEnv

Работа с файлами в BitrixEnv осуществляется по протоколам SSH / SFTP. Протоколы FTP и SCP по умолчанию не поддерживаются.


Внимание! «1C-Битрикс: Виртуальная машина» версии 7.x также позволяет управлять масштабированием серверов пула в простом визуальном режиме в административном интерфейсе с помощью модуля Управление масштабированием.

Глава предназначена для администраторов и пользователей продуктов «1С-Битрикс», устанавливающих для ознакомления либо переносящих готовые проекты на виртуальную машину VMBitrix. Аналогичным способом можно переносить проекты с удаленного сайта на виртуальную машину, между виртуальными машинами и т.д. В документе рассматриваются процедуры установки всех необходимых приложений для работы продукта на виртуальной машине VMBitrix.

Описание установки ПО виртуализации не входит в данное руководство. По всем вопросам установки этой программы обращайтесь к документации соответствующего ПО.

Если у вас возникнут вопросы по процессу установки продуктов компании «1С-Битрикс», вы можете обратиться в службу Технической поддержки. Обсуждение работы VMBitrix доступно на специализированном форуме или в группе Виртуальные машины Битрикс социальной сети компании «1С-Битрикс».



Важные замечания

Внимание! Информацию по устаревшим версиям «1C-Битрикс: Виртуальная машина» можно прочитать тут: версия 5.х и версия 4.3.

Внимание! Все названия хостов, адреса e-mail, серверов, ip-адреса и т.п информация в учебном курсе указываются в качестве примера. Поэтому при настройке виртуальной машины необходимо использовать свои данные.

Внимание! Если в VMBitrix или в BitrixEnv меняется ssl-сертификат с установленного по умолчанию на свой, и сертификат запаролен, то это вызовет проблему в работе мастеров и при перезапуске сервисов. Будет постоянно запрашиваться ввод пароля. Чтобы избежать подобных проблем, нужно удалить пароль из сертификата:
/path/to/openssl rsa -in /path/to/originalkeywithpass.key -out /path/to/newkeywithnopass.key


Что нового?

Изменения в актуальной версии BitrixVM.

VMBitrix v 7.5.х

Список изменений v 7.5.5 (декабрь 2023)

Список изменений v 7.5.4 (октябрь 2023)

Список изменений v 7.5.3 (октябрь 2023)

Список изменений v 7.5.2 (апрель 2022)

Список изменений v 7.5.1 (апрель 2022)

Обсуждение стабильной версии 7.5.x на форуме.

Архив изменений

История стабильных версий VMBitrix v 7.*.*

VMBitrix v7.4.х (Стабильная версия)


Список изменений v7.4.4 (ноябрь 2020)

Список изменений v7.4.3 (ноябрь 2019)

Список изменений v7.4.2 (октябрь 2019)

Список изменений v7.4.1 (август 2019)

Список изменений v7.4.0 (июль 2019)

Обсуждение стабильной версии 7.4.x на форуме.



VMBitrix v 7.3.х


Список изменений v7.3.4 (декабрь 2018)

Список изменений v7.3.3 (сентябрь 2018)

Список изменений v7.3.2 (август 2018)

Список изменений v7.3.1 (июль 2018)

Список изменений v7.3.0 (май 2018)

Обсуждение стабильной версии 7.3.x на форуме.

VMBitrix v 7.2.х


Список изменений v7.2.2 (декабрь 2017)

Список изменений v7.2.1 (декабрь 2017)

Список изменений v7.2.0 (декабрь 2017)


Обсуждение версии 7.2.x на форуме.



Установка «1С-Битрикс: Веб-окружение» - Linux (BitrixEnv)

Для кого?

«1С-Битрикс: Веб-окружение» - Linux (BitrixEnv) будет полезно:

  • Для пользователей и разработчиков, которые использовали продукт «1С-Битрикс: Виртуальная машина» в процессе подготовки сайта и столкнулись с проблемой переноса конфигурации на хостинг или на невиртуальное оборудование и потерей производительности.
  • Для специалистов хостинг-партнеров, планирующих создать шаблоны различных VPS для продуктов «1С-Битрикс».
  • Для системных администраторов, которым требуется быстро подготовить производительную платформу для установки или миграции сайтов на основе «1С-Битрикс».
  • Для программистов и системных администраторов, которым требуется быстро развернуть кластер для проектов на основе «1С-Битрикс».

«1С-Битрикс: Веб-окружение» - Linux позволяет быстро и с минимальными затратами развернуть оптимальное окружение для работы продуктов и решений «1С-Битрикс» на Linux-платформе CentOS 7 (x86_64):

  • mysql-server 5.7.x или 8.0.x
  • web-server (Apache 2.4.*)
  • php 8.x
  • nginx 1.18.0
  • memcached
  • stunnel
  • catdoc
  • xpdf
  • munin
  • nagios
  • sphinx

Установка
на CentOS 7

Рассмотрим установку «1С-Битрикс: Веб-окружение» - Linux на оборудовании с уже установленной CentOS 7 (Minimal) (x86_64).

  1. Авторизуемся на сервер под административным аккаунтом root и обновляем все пакеты системы:
    yum clean all && yum update
    
  2. Загружаем скрипт «1С-Битрикс: Веб-окружение» - Linux и запускаем его командами:

    wget https://repo.bitrix.info/yum/bitrix-env.sh && chmod +x bitrix-env.sh && ./bitrix-env.sh
    

    Примечание: Если на сервере нет утилиты для загрузки файлов wget, то ее можно установить командой yum install wget

  3. Далее необходимо согласиться на отключение SELinux (если SELinux включен в системе) и перезагрузить машину командой reboot:

  4. После перезагрузки сервера снова продолжите установку BitrixEnv:

    ./bitrix-env.sh
    
  5. При первом входе на сервер с логином root будет предложено сменить пароль у пользователя bitrix:

  6. Далее нужно создать пул (1. Create Management pool of server) и можно приступать к работе:

    Внимание! В VMBitrix версии 7.x+ нужно обязательно создать пул (1. Create Management pool of server). Мастер создания пула откроет все необходимые порты в CentOS для корректной работы сервисов продуктов «1С-Битрикс»:
    • 22 – ssh доступ;
    • 80 / 443 – http / https web-сервер;
    • 8890 / 8891 – http/https ntlm;
    • 8893 / 8894 – http/https сервер мгновенных сообщений;
    • 5222 / 5223 – http/https xmpp-сервер.

    Если пул не создан, то открыты только 22, 80 и 443 порты.
    Внутри машины могут использоваться дополнительные порты для служб и сервисов, но они не открываются наружу.

  7. Cервер готов для дальнейшего использования.
  8. После всех настроек сервера в целях безопасности не забудьте выйти из учетной записи root:
    • Выйти в консоль, выбрав в меню 0. Exit (или нажать Ctrl+C)
    • И затем в консоли выполнить команду exit

Тихая установка
BitrixEnv

Silent mode

С версии 7.1 появилась возможность создания пула в «тихом» режиме, когда после установки окружения VMBitrix запускается сразу создание пула с нужным именем хоста и паролем для root MySQL.

./bitrix-env.sh [-s] [-p [-H hostname]] [-F] [-m mysql_version] [-M mysql_root_password]
где:
  • -s – Тихий режим установки. Не задавать вопросы (Silent or quiet mode. Don't ask any questions).
  • -p – Создать пул после установки окружения (Create pool after installation of bitrix-env).
  • -H – Имя хоста (Hostname for for pool creation procedure).
  • -F – Будет использоваться в качестве файрвола firewalld.
  • -I – Будет использоваться в качестве файрвола iptables (по умолчанию).
  • -M – Пароль root для MySQL (Mysql password for root user).
  • -m 5.7 – установить MySQL 5.7 (по умолчанию).
  • -m 8.0 – установить MySQL 8.0.

Пример использования:

Запустить установку окружения в «тихом» режиме, использовать файрвол firewalld, создать пул с именем хоста server1, MySQL 8.0 и задать пароль root пользователя MySQL - 111111.

./bitrix-env.sh -s -p -H server1 -F -m 8.0 -M '111111'

Узнать список всех ключей запуска установки можно командами для VMBitrix и VMBitrix.CRM соответственно:

./bitrix-env.sh -h
./bitrix-env-crm.sh -h

Как управлять
BitrixEnv

Для перехода к выполнению любого действия в меню виртуальной машины введите число и нажмите Enter. Например, для настройки локального виртуального сервера в строке наберите 2 (Manage localhost) и нажмите Enter.

Чтобы вернуться из командной строки (если нажали 0. Exit или Ctrl+C) обратно в меню VMBitrix, введите в консоли команду:

/root/menu.sh

Работа с файлами
в BitrixEnv

Работа с файлами в VMBitrix осуществляется по протоколам SSH / SFTP. Протоколы FTP и SCP по умолчанию не поддерживаются.



Словарь

Каждая платформа имеет свои термины, используемые в работе. Чтобы без проблем ориентироваться в документации, учебных курсах, в помощь вам приведен словарь терминов системы.


ТерминОписание
АвторизацияПроцесс подтверждения прав доступа к функционалу корпоративного портала. Возможен только после регистрации.
Автосохранение Функция, позволяющая сохранить данные, введенные в поля формы, в случае нештатной ситуации.
Библиотека документовРаздел корпоративного портала, позволяющий организовать коллективный доступ и работу над документами и файлами.
Бизнес-процессПроцесс обработки документа, для которого задана одна точка входа и несколько точек выхода и последовательность действий (шагов, этапов, функций), совершаемых в заданном порядке и в определенных условиях.
Веб-мессенджерИнтерактивный инструмент, позволяющий обмениваться мгновенными сообщениями с другими сотрудниками корпоративного портала и получать информацию о событиях на портале.
Веб-форумФункционал для организации общения посетителей. Форум предлагает набор разделов для обсуждения. Работа форума заключается в создании сотрудниками тем в разделах и последующим обсуждением внутри этих тем.
Видеоконференции Сервис для общения между сотрудниками компании с видеоизображением.
Визуальный редакторИнструмент, который позволяет управлять содержанием страницы корпоративного портала в режиме реального времени через браузер.
Воронка продажСтраница, на которой представлено количественное соотношение всех сделок в CRM на разных стадиях.
ГаджетОсобый программный элемент, выполняющий функцию вывода определенных данных.
Главная страницаСтраница, куда выводится текущая информация по событиям в вашей компании.
Горячие клавиши (англ. hot key) Разновидность интерфейса взаимодействия с компьютером, представляющая собой нажатие клавиши (или сочетания клавиш) на клавиатуре, которому назначены (запрограммированы) определённые команды (операции).
График отсутствийСтраница, на которой автоматически выводится вся информация об отсутствиях работников на рабочем месте.
Группа пользователей Список сотрудников, имеющих определенный уровень прав на доступ к информации.
Документооборот Программный инструмент, предназначенный для функционального и поэтапного разделения работы с документами среди сотрудников.
Доска объявлений Сервис для просмотра размещенных на портале объявлений и создания своих.
Доска почета Специальный инструмент морального поощрения сотрудников.
Живая лентаСтраница, на которой выводятся последние события системы: новости, комментарии, новые файлы, системные события и так далее.
ЗадачиИнструмент для организации персональной и групповой работы. Задачи обладают свойствами: контроля по времени, контроля по эффективности работы, приоритету выполнения, ролями и другими.
Зарплата и отпуск Сервис для получения сотрудником доступа к Расчетным листкам, а также информации о текущем остатке неиспользованных дней отпуска.
Ключевые показатели эффективности - (англ. Key Performance Indicators, KPI) Система оценки, которая помогает организации определить достижение стратегических и тактических (операционных) целей.
КомпанияЗапись в CRM о компании, которая имеет какую-то форму сотрудничества (либо может иметь сотрудничество) с вашей компанией.
Корпоративный порталПрограммное обеспечение, предоставляющее сотрудникам компании, клиентам и простым пользователям доступ к различной служебной информации компании. Доступ может быть организован как из внутренних так и из внешних сетей с целью организации производственной деятельности. Объем корпоративной информации, доступной для конкретного пользователя программы, ограничивается в соответствии с имеющимся у него уровнем прав. Корпоративный портал, как правило, предоставляет возможности внутренних коммуникаций и интеграции сторонних приложений.
ЛидЗапись в CRM о какой либо форме контакта (телефон, e-mail, очная встреча и так далее), которая имеет потенциальную возможность перерасти в сделку.
Мгновенные сообщенияСпособ общения сотрудников на корпоративном портале, представляющий собой обмен персональными сообщениями.
Менеджер идейСервис, позволяющий рассматривать и обсуждать идеи, а также классифицировать их в соответствии с рейтингом.
ОбращениеЗаявка в техническую поддержку по какому-либо вопросу.
Ответственный (задачи) Сотрудник, которому была непосредственно поставлена задача.
Отчет по эффективностиСтраница, на которой выводятся сведения об эффективности сотрудников на основе задач, включенных в отчет по эффективности.
ПереговорнаяПомещение в офисе компании для проведения коллективных мероприятий.
Планировщик событийФункционал корпоративного портала, предназначенный для помощи в организации коллективных событий с учетом занятости его участников.
ПодпискаСервис, уведомляющий пользователя о различных событиях на портале.
Пользовательские поля Параметры сущностей, создаваемые сотрудниками.
Публичный раздел Основное место работы сотрудника, имеющего права на редактирование информации на портале. Он является частью "1С-Битрикс: Корпоративный Портал", видимой обычным пользователям.
Рабочая группаВиртуальное объединение людей для решения или обсуждения общих вопросов, целей и задач.
Рабочий столОсновная (главная) страница корпоративного портала.
Рабочий отчетЗапись, охватывающая определенный временной интервал и подтверждаемая руководителем, содержащая информацию о рабочем времени сотрудника, выполняемых и завершенных им задачах.
РассылкаПрисылаемые сотруднику сообщения о событиях на корпоративном портале в соответствии с его подпиской.
РегистрацияПроцедура, в результате которой человек становится пользователем корпоративного портала с определёнными правами доступа к определённому объёму функций.
Редакция Корпоративный портал, функционал которого настроен на определенные специализированные задачи, связанные со спецификой работы компании (Проект, Проект+ Команда, Компания, Корпоративный портал, Холдинг).
Режим правки Состояние страницы публичного раздела, в котором возможна настройка параметров компонентов, включенных в шаблон портала и в основную рабочую область данной конкретной страницы.
РейтингХарактеристика контента, прямо пропорциональная его популярности. Увеличивается путем нажатия сотрудниками кнопки Мне нравится.
РольСовокупность прав на действия с сущностями и настройками CRM.
СделкаЗапись о работе с клиентом, компанией по поводу продажи товара.
Сервер MS ExchangeПрограммный продукт с поддержкой мобильных устройств для обмена сообщениями и совместной работы.
Собрания и планеркиИнструмент, автоматизирующий подготовку к собранию, его ведение и контроль за исполнением поставленных на собрании целей, хранение истории, обеспечивающий "прозрачность" всего процесса для руководства.
СобытиеЛюбое изменение в записях: Контакт, Лид, Компания.
Социальная сетьПрограммный модуль, ориентированный на организацию совместной работы и общения сотрудников корпоративного портала и решения других задач, связанных с функционированием социальных сообществ.
Списки Универсальный инструмент для отображения любой структурированной информации в виде списков.
СправочникСписок значений параметров, относящихся к той или иной сущности CRM.
Структура компанииНаглядное графическое представление иерархии филиалов, подразделений и отделов компании в виде схемы.
Универсальный конструктор отчетов Отдельный модуль, который позволяет сотрудникам самим конструировать отчеты для разных объектов и в дальнейшем многократно их запускать. Отчеты изменяются в реальном времени, в зависимости от хода выполнения задач.
Уровни доступа Определенный комплекс операций в системе, доступный для выполнения пользователем. Они предназначены для создания системы управления пользователями. Уровни доступа определяются администратором и могут быть как изменены, так и созданы. Обладают свойством "наследования", то есть если для текущего раздела/страницы явно не задан уровень прав, тогда устанавливается то право, которое задано для вышележащего раздела.
Файловое хранилище Подключенные к порталу физические папки на сервере.
ФильтрПрограммный компонент, позволяющий из множества элементов выделить те, которые соответствуют определенным параметрам.
Форма отчетаВид страницы со списком каких-либо элементов.
Центр нотификацийЧасть веб-мессенджера, показывающая уведомления системы, касающиеся непосредственно текущего сотрудника:

Цепочка навигации или «Хлебные крошки»Элемент навигации, представляющий собой путь по корпоративному порталу от его «корня» до текущей страницы, на которой находится сотрудник.
ЭкстранетРасширение системы, которое позволяет компании осуществлять конфиденциальную связь с поставщиками, дистрибьюторами и другими внешними пользователями без доступа к внутрикорпоративной информации.
CalDAVИнтернет-стандарт, позволяющий клиентам получать коллективный доступ к информации и осуществлять планирование на удаленном сервере.
CRMCистема, предназначенная для повышения уровня продаж, оптимизации маркетинга и улучшения обслуживания клиентов. В CRM сохраняется информация о клиентах и история взаимоотношений с ними для последующего анализа результатов.
RSS-лентаСервис для сбора информационных RSS-потоков в одном удобном для чтения месте.
Send&SaveТехнология добавления e-mail в события какой-либо сущности CRM.
WikiРаздел проекта, структуру и содержимое которого пользователи могут сообща изменять с помощью инструментов, предоставляемых самой системой.
XMPP-клиент Приложение, позволяющее обмениваться сообщениями через протокол XMPP.


Запуск виртуальной машины BitrixVM

  Запуск виртуальной машины BitrixVM

Внимание! Если у вас при старте образа виртуальной машины появляется черный экран и сразу пропадает, а BitrixVM не стартует, проверьте поддержку аппаратной виртуализации VT-x/VT-d вашим процессором. Включить виртуализацию VT-x/VT-d можно в BIOS вашего компьютера. Также проверьте битность вашей операционной системы, на которой запускается виртуальная машина, – она должна быть 64-битной.

  1. Загрузите подходящий вам дистрибутив настроенной виртуальной машины BitrixVM.

  2. Загруженный архив распакуйте в любую папку, например, С:\BitrixVM\ и запустите виртуальную машину с помощью подходящего ПО:

    Примечание: Если при работе с VMWare Player виртуальная машина не запускается, откройте её настройки [dw](Edit virtual machine settings)[/dw][di] [/di] и во вкладке [dw]Options[/dw][di] [/di] укажите гостевую операционную систему:
    • Guest operating system: Linux
    • Version: CentOS 64-bit

  3. Начнется процесс загрузки операционной системы, установленной на виртуальной машине. В конце загрузки откроется окно:

  4. При первом запуске виртуальной машины BitrixVM будет предложено сменить пароли суперпользователя root и пользователя bitrix:

    Примечание: Для суперпользователя root по умолчанию задан пароль bitrix.

    Если у вас версия VMBitrix.CRM, то пароль пользователя root будет указан на экране.

    • В строке localhost login укажите логин: root, а в поле Password пароль: bitrix.
    • В строке (current) UNIX password укажите текущий пароль (bitrix) и нажмите Enter.
    • Введите новый пароль в строке Enter new UNIX password и нажмите Enter.
    • Повторите ввод нового пароля в строке Retype new UNIX password и нажмите Enter.

    Аналогично происходит смена пароля пользователя bitrix:

    Примечание: Сменить пароль пользователя bitrix можно позднее в панели управления виртуальным сервером с помощью пункта меню 1. Create Management pool of server - Change bitrix password.

  5. Далее нужно обязательно создать пул управления сервером с помощью меню 1. Create Management pool of server.

    Внимание! В BitrixVM версии 7.x+ нужно обязательно создавать пул (1. Create Management pool of server). Мастер создания пула откроет все необходимые порты в CentOS для корректной работы сервисов продуктов «1С-Битрикс».
    Если у вас в меню нет пунктов, кроме как 0. Exit и в таблице сетевых интерфейсов IP4: Undefined - это значит, что у вас проблема с сетевым адаптером виртуальной машины или в локальной сети нет DHCP сервера. Проверьте настройки сетевого адаптера виртмашины или попробуйте задать ip-адрес вручную.

  6. Обновите версии PHP и MySQL до рекомендуемых системных требований продуктов «1С-Битрикс».
  7. Виртуальный сервер готов для дальнейшего использования.

  8. После всех настроек виртуального сервера в целях безопасности не забудьте выйти из учетной записи root:
    • Выйти в консоль, выбрав в меню 0. Exit (или нажать Ctrl + C)
    • И затем в консоли выполнить команду exit

  9. Для запуска процесса установки продуктов компании 1С-Битрикс (или открытия уже установленного сайта), перейдите в браузере по пути, указанному в поле bitrix url.

Примечание: Пароли пользователей root и bitrix так же используются при подключении к сайту по SFTP.

  Посмотреть краткий процесс установки BitrixVM для запуска сайта на «1С-Битрикс: Управление сайтом» можно в видеороликах на нашем Youtube канале:

  Как управлять BitrixVM

Для перехода к выполнению любого действия меню виртуальной машины введите число и нажмите Enter. Например, для настройки локального виртуального сервера в строке наберите 2 (Manage localhost) и нажмите Enter.

Чтобы вернуться в вашу ОС, нажмите Ctrl+Alt (VMWare Player).

Чтобы вернуться из командной строки (если нажали 0. Exit) обратно в меню виртуальной машины, введите в консоли команду:

/root/menu.sh

Если вы запускаете несколько хостов в одной BitrixVM на локальном компьютере или в пределах вашей локальной сети, то можно указать для этих сайтов вместо IP свои выдуманные домены, предварительно прописав в файле hosts операционной системы или на сервере DHCP вашей сети. Тогда вы сможете обращаться к сайтам по доменным именам, но только в пределах вашего компьютера или вашей локальной сети.

Если при работе с BitrixVM возникли ошибки работы мастеров, то логи мастеров можно просмотреть в папке /opt/webdir/temp/.

Примечание: При возникновении проблем с сетевым адаптером VMWare Player или VirtualBox (например не открывается сайт по адресу виртуальной машины) необходимо перейти в настройки сетевого адаптера (Virtual Machine > Removable Devices > Network Adapter > Settings...), [dw]поменять режим работы адаптера[/dw][di]

[/di] с NAT на Bridged (или наоборот). И перезапустить виртуальный сервер, выбрав пункт меню 2. Manage localhost > 4. Reboot server.



VMBitrix.CRM

VMBitrix.CRM собирается на базе BitrixVM. Это готовое решение для CRM – внутри машины тоже самое, что и в основной машине BitrixVM.

Но у него есть отличия:

  1. Из меню убрано:

    • управление хостами
    • расширенное управление сайтами (убрано создание, удаление, ntlm, композит для nginx)
    • управление MySQL и репликацией
    • управление memcache, sphinx
    • управление web ролью и мониторингом
  2. При старте сразу:

    • создается пул
    • настроен memcache
    • установлен и работает push-сервер

Скачать его можно с сайта 1С-Битрикс под нужный вид виртуализации.

Далее нужно только установить Битрикс24.CRM (или восстановить копию), настроить почту и ssl-сертификат. И у вас готовый Битрикс24 с CRM!

Для отдельного сервера на базе CentOS 7 можно загрузить скрипт установки VMbitrix.CRM через консоль и запустить его командами:

wget http://repo.bitrix.info/yum/bitrix-env-crm.sh && chmod +x bitrix-env-crm.sh && ./bitrix-env-crm.sh


Также для VMBitrix.CRM есть вариант поставки exe-файла для тех, кто хочет в пару кликов познакомиться с Битрикс24.CRM и не обладает достаточными техническими знаниями. Совместим с Windows 7, 8, 10, Windows Server 2008 2012 2016.

Этот инсталлятор:

  • скачает и установит VirtualBox
  • скачает образ виртуальной машины и импортирует его в VirtualBox
  • установит сервис по вашему желанию
  • запустит машину и получит IP

После останется установить Битрикс24.CRM или восстановить копию проекта.

Примечание: Если устанавливается как сервис, то при перезагрузке компьютера виртуальная машина будет запущена в фоновом режиме. Для работы как сервиса у пользователя Windows должен быть установлен пароль.



Установка и перенос продуктов «1С-Битрикс» в BitrixVM/BitrixEnv

Установка и перенос продуктов «1С-Битрикс» может быть осуществлена несколькими способами.

Установка дистрибутива сайта в BitrixVM/BitrixEnv

Важно! Если вы используете BitrixVM7.5.1, то предварительно выполните обновление версии PHP до версии 8.0.0 или выше.

Для установки продукта «1С-Битрикс» нужно:

  1. Перейти по адресу [dw]bitrix url[/dw][di][/di], указанному в BitrixVM или BitrixEnv в браузере. Откроется страница с выбором варианта установки:

  2. Для продолжения необходимо выбрать один из вариантов:

    • Установить - в этом случае будет запущен мастер, который позволяет скачать и установить новый сайт средствами продуктов компании «1C-Битрикс». Шаги этого варианта аналогичны шагам, рассмотренным в главе Установка продукта с помощью BitrixSetup.

    • Восстановить копию - в этом случае будет запущен мастер, с помощью которого можно будет перенести существующий проект (восстановить проект из резервной копии).



Перенос продукта «1C-Битрикс» в виртуальную среду BitrixVM/BitrixEnv

Подготовка

Что должно быть готово перед переносом?

Для переноса сайта с хостинга (облака) или локального сервера на виртуальную среду BitrixVM или BitrixEnv необходимы: архив сайта и настроенная виртуальная среда BitrixVM или BitrixEnv.

После успешного создания архива сайта он будет доступен на странице [dw]Список резервных копий[/dw][di][/di] (Настройки > Инструменты > Список резервных копий) .

Воспользуйтесь командой [dw]Получить ссылку для переноса[/dw][di][/di] в меню действий (ссылка доступна только для локально размещенной копии) и в появившемся окне скопируйте её в буфер обмена:

Также можно скачать архив сайта на локальный компьютер с помощью пункта меню Скачать.

  Перенос сайта

Перенос сайта в виртуальную среду BitrixVM/BitrixEnv

  1. Запустить предварительно настроенную виртуальную среду BitrixVM или BitrixEnv.

  2. В адресной строке браузера ввести http://адрес_виртуальной_машины/ (можно указать домен или ip-адрес).

  3. Откроется мастер установки продукта «1С-Битрикс», где нужно выбрать [dw]Восстановить копию[/dw][di].[/di]:

  4. На этапе загрузки резервной копии указать место хранения архива сайта (в данном случае - ввести ссылку из буфера обмена, полученную на странице со списком резервных копий сайта):

    Примечание: Также есть возможность загрузить архив из облака «1С-Битрикс» (понадобится лицензионный ключ с действующей лицензией), с локального компьютера или из корневой папки сервера в зависимости от того, где хранится ваша резервная копия.

  5. После скачивания архива, если архив был зашифрован, то будет предложено [dw]ввести пароль[/dw][di][/di]:
  6. Далее необходимо настроить подключение к базе данных:

    Настройки подключения к MySQL по умолчанию в BitrixVM/BitrixEnv берутся из /home/bitrix/www/bitrix/php_interface/dbconn.php.

    Можно указать собственные параметры подключения к MySQL - в этом случае необходимо еще выбрать опцию Создать базу данных, если не существует.

  7. После успешного восстановления базы данных в целях безопасности необходимо Удалить локальную резервную копию и служебные скрипты, нажав на [dw]одноименную кнопку[/dw][di][/di].
  8. Перенос продукта «1C-Битрикс» на виртуальную среду BitrixVM/BitrixEnv [dw]закончен[/dw][di][/di].

Возможная ошибка

Ошибка "Call to undefined function mysqli_init()"

При переходе на новую версию платформы BitrixVM/BitrixEnv может возникнуть ошибка - "Call to undefined function mysqli_init()". Причина ошибки в том, что раньше в БД MySQL использовалось расширение mysql (объявлено устаревшим в PHP 5.5.0), а в новых версиях - mysqli.

Решение проблемы:

  1. В файле \bitrix\php_interface\dbconn.php добавить:
    define("BX_USE_MYSQLI", true); 
    
  2. В файле \bitrix\.settings.php:
    'className' => '\\Bitrix\\Main\\DB\\MysqlConnection',
    
    поменять на:
    'className' => '\\Bitrix\\Main\\DB\\MysqliConnection',
    
  3. Проверить наличие в файле /etc/php.d/30-mysqli.ini (или в подобном):
    extension=mysqli.so
    
  4. Cделать рестарт httpd:

    • CentOS 6:
      service httpd restart
      
    • CentOS 7:
      systemctl restart httpd.service
      


Типовые ошибки при установке

Возможные проблемы и их решение

При установке BitrixVM могут возникать ошибки, связанные с особенностями вашего ПК или с дистрибутивом.

Ниже список типовых проблем и способы их решения:

Не нашли свою проблему в списке? Переустановка часто помогает: удалите виртуальную машину, затем снова ее установите и скачайте дистрибутив продукта.


 Программа не поддерживает оборудование компьютера

Программа для виртуальных машин (например, VMWare или VirtualBox) не поддерживает оборудование компьютера и выдает ошибку о несовместимости с процессором «Unsupported CPU detected. The host CPU does not support the necessary hardware requirements».

Как решить:

  • Используйте альтернативное программное обеспечение для запуска виртуальных машин. Например, если ошибка возникает в VMWare, попробуйте VirtualBox
  • Установите более старую версию выбранной программы, которую можно найти на официальном сайте производителя VMWare или VirtualBox


 Выключена или отсутствует виртуализация

При запуске виртуальной машины появляется черный экран и сразу пропадает, а BitrixVM не стартует. Или появляется ошибка включающая слова [dw]VT-x, AMD-V, virtualization[/dw][di]Формулировка может быть вида «This host does not support "Intel EPT" hardware assisted MMU virtualization» или «This host supports Intel VT-x, but Intel VT-x is disabled».[/di].

Как решить:

  • Проверьте, поддерживает ли ваш процессор аппаратную виртуализацию (VT-x/VT-d/AMD-V)
  • Если поддерживает, активируйте эту функцию в BIOS компьютера. Как это сделать — индивидуально и зависит от вашего оборудования. Инструкцию по активации для вашего случая вы можете найти в интернете


 Не открывается сайт или показывается ошибка с сетевым адаптером

Вы запускаете виртуальную машину и появляются ошибки, связанные с адаптером (adapter). Или сайт не открывается по IP и отображает сообщение «Не удается получить доступ к сайту».

Как решить:

  • Для WMVare:
    • Выключите виртуальную машину
    • Перейдите в настройки сетевого адаптера
    • Измените [dw]режим работы[/dw][di][/di] адаптера с NAT на Bridged или наоборот
    • Запустите BitrixVM снова
  • Для VirtualBox:
    • Убедитесь, что режим работы сетевого адаптера установлен на Bridged
  • Если проблема сохраняется, возможно, потребуется обновление сетевого драйвера на вашем компьютере. Обновление драйвера зависит от операционной системы вашего ПК. Инструкции по обновлению драйверов для любой операционной системы вы найдете в интернете

 Нет IP-адреса после запуска BitrixVM

Поле [dw]bitrix url[/dw][di][/di] отсутствует и IP4 имеет статус undefined.

Как решить:

  • Перезапустите виртуальную машину. Иногда для корректного получения IP-адреса требуется несколько попыток запуска. Если проблема остается, переходите к следующему шагу
  • Проверьте настройки сетевого оборудования. Если перезапуск не помог, возможно, проблема связана с настройками сети. Попробуйте вручную настроить IP-адрес через меню BitrixVM или обратитесь за помощью к системному администратору


 502 ошибка или время ожидания истекло

При попытке открыть сайт по [dw]bitrix url[/dw][di][/di] после установки BitrixVM появляется ошибка «[dw]502 Bad Gateway/Bitrix Environment[/dw][di][/di]» или сообщение о том, что «Время ожидания ответа истекло».

Как решить:

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


 Дистрибутив не скачивается или загрузка стоит на месте

Во время скачивания дистрибутива с сервера:

  • процент загрузки не меняется (0%) в течение длительного времени
  • загрузка частично выполняется и затем отображается ошибка

Как решить:

  • Сбросьте [dw]кеш браузера[/dw][di]Откройте страницу в браузере по IP и нажмите Ctrl + F5 — на компьютере с Windows или Command + Option + R — на компьютере с MacOS. Либо очистите историю в настройках браузера.[/di] или попробуйте скачать дистрибутив, используя [dw]режим инкогнито[/dw][di]Как открыть окно в режиме инкогнито в Google Chrome:

    [/di]. Это может помочь, если проблема связана с временными файлами
  • Проверьте скачивание продукта через другой интернет-провайдер, например, используя мобильный интернет. Это позволит исключить проблемы, связанные с вашим основным подключением к интернету
  • Если способы выше не помогли, удалите виртуальную машину и вновь установите её. Возможно в процессе первоначальной установки что-то пошло не так и переустановка может решить проблему


 Странные символы и ошибки в мастере установки

Процесс скачивания дистрибутива не быстрый и иногда файл скачивается с ошибками. Это может проявиться по-разному: ошибками в мастере установки или символами �. Пример пользователя:

Цитата: «Я нажимаю принять соглашение, после этого на кнопку Далее и у меня появляются [dw]непонятные символы[/dw][di][/di]»

Как решить: удалите виртуальную машину, вновь установите её и скачайте дистрибутив продукта.


 Версия PHP или MySQL не соответствует требованиям (устарела)

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

Как решить: обновите PHP и MySQL через меню BitrixVM.

Сначала необходимо выполнить подготовительные работы:

  • В поле [dw]localhost login[/dw][di][/di] введите root и нажмите клавишу Enter (Ввод)
  • При первом запуске виртуальной машины BitrixVM в появившемся поле [dw]Password[/dw][di][/di] введите bitrix и нажмите Enter

    Обратите внимание, что все пароли вводятся скрытым образом, на экране символы не отображаются

  • Вам будет предложено сменить пароль для пользователя root:
    • В поле [dw](current) UNIX password[/dw][di][/di] введите старый пароль bitrix и нажмите Enter
    • Придумайте новый пароль для пользователя root и введите его в поле [dw]New password[/dw][di][/di], затем нажмите кнопку Enter
    • Повторите ввод нового пароля в строке [dw]Retype new password[/dw][di][/di] и нажмите Enter
  • Теперь придумайте новый пароль для пользователя [dw]bitrix[/dw][di][/di]: введите его в поле New password, нажмите Enter. Затем повторите его в поле Retype new password и вновь нажмите Enter
  • Примечание. При последующих запусках для пользователей root или bitrix в поле [dw]Password[/dw][di][/di] вводите пароли, придуманные вами на предыдущих шагах. Старые больше действовать не будут
  • Появится информация о необходимости создать [dw]пул управления сервером[/dw][di]Пул – это набор серверов управления или серверов шлюзов, которые распределяют между собой рабочие нагрузки и принимают на себя рабочие нагрузки в случае сбоя одного из членов.

    В самом простом случае в пуле будет единственный сервер, на котором настроено Bitrix-окружение. [/di]:
    • [dw]Введите[/dw][di][/di] цифру 1 в строке Enter your choice и нажмите Enter
    • Задайте произвольное [dw]название сервера[/dw][di][/di], например, myserver и нажмите Enter
    • Отобразится [dw]сообщение[/dw][di][/di] об успешном создании пула. Нажмите кнопку Enter
  • Виртуальный сервер готов для использования. Если забыли его IP-адрес, то он отображается в поле [dw]NetAddress[/dw][di][/di]

Подготовительные работы по настройке сервера выполнены и стало доступно [dw]меню виртуальной машины[/dw][di][/di]. Теперь можно обновить PHP и MySQL. Подробно об этом написано в уроке 8. Обновление PHP и MySQL (8. Update PHP and MySQL) отдельного курса по виртуальной машине.

Примечание. Обновлять версии PHP и MySQL может только пользователь root
После окончания всех настроек, в целях безопасности рекомендуется выйти из учетной записи root:
  • Введите цифру 0 в строке Enter your choice и нажмите Enter
  • Введите в консоли команду exit и нажмите Enter


1. Управление серверами пула (1. Manage servers in the pool)

Для начала работы с сервисами нужно создать и настроить пул сервера. Для этого нужно выбрать пункт главного меню 1. Create Management pool of server и ввести название сервера в данном пуле.

Мастер создания пула откроет все необходимые порты в CentOS для корректной работы сервисов продуктов «1С-Битрикс»:

  • 22 – ssh доступ;
  • 80 / 443 – http / https web-сервер;
  • 8890 / 8891 – http/https ntlm;
  • 8893 / 8894 – http/https сервер мгновенных сообщений;
  • 5222 / 5223 – http/https xmpp-сервер.

Если пул не создан, то открыты только 22, 80 и 443 порты.

Для большинства проектов достаточно всего лишь одного сервера в пуле, который создается на начальном этапе установки BitrixEnv (см выше). Добавление дополнительных может понадобится для масштабирования системы и распределения нагрузки между несколькими физическими серверами. Это делается назначением специальных ролей каждому серверу в пуле. Если у вас нет дополнительных физических машин, то необходимости добавления их в пул нет.

Внимание! Сервер в пуле - не значит сайт! Если вам нужно создать или добавить веб-сайт в BitrixEnv, то делать это нужно в меню Управление сайтами (Configure pool sites).

После создания пула в основном меню добавятся новые пункты в главном меню:



1. Добавление нового хоста в пул (1. Add new host to the pool)

Внимание! Добавление физических серверов в пул (кластер) нужно для масштабирования системы, для распределения нагрузки между несколькими серверами. Если у вас нет дополнительных физических серверов, то необходимости добавления их в пул нет.

На добавляемом сервере в пул (кластер) должно быть установлено BitrixVM или BitrixEnv.

Внимание! Сервер - не значит сайт! Если вам нужно создать или добавить веб-сайт в BitrixEnv, то делать это нужно в меню Управление сайтами (Configure pool sites).


Добавление нового сервера в пул (кластер) осуществляется с помощью меню 1. Manage servers in the pool > 1. Add new host to the pool.

Для этого необходимо задать ip-адрес или DNS-имя сервера, выбрать короткое имя (в примере - server2) и ввести пароль root для подключаемого сервера:

Примечание: Имя сервера можно выбрать любое, можно указать, что хотите: bx1, server10, mysite.com (можно и имя домена, если он один) и т.д.

Таким образом, можно добавлять любое количество серверов в пул:

Теперь можно управлять любым сервером пула с одной машины.

Примечание: Если зайти на присоединенный к пулу сервер, то система оповестит о нахождении данного сервера в пуле и невозможности отображения управляемого меню:


Внимание! Задачи могут выполняться довольно длительное время (до 2-3 часов и более) в зависимости от сложности задачи, объема данных, используемых в этих задачах, мощности и загруженности сервера. Проверить текущие выполняемые задачи можно с помощью меню 10. Background pool tasks > 1. View running tasks. Если по каким-либо причинам нужно посмотреть лог-файлы выполнения задач, то они находятся в директории /opt/webdir/temp.



2. Удаление хоста из пула (2. Remove host from the pool)

Удаление хоста, находящегося в пуле, осуществляется с помощью меню 1. Manage servers in the pool > 2. Remove host from the pool . Если на хосте есть хоть какие-то роли, то удаление хоста невозможно.

Для этого необходимо задать ip-адрес или DNS-имя хоста удаляемого из пула сервера:

После подтверждения сервер будет удален из пула:


Внимание! Задачи могут выполняться довольно длительное время (до 2-3 часов и более) в зависимости от сложности задачи, объема данных, используемых в этих задачах, мощности и загруженности сервера. Проверить текущие выполняемые задачи можно с помощью меню 10. Background pool tasks > 1. View running tasks. Если по каким-либо причинам нужно посмотреть лог-файлы выполнения задач, то они находятся в директории /opt/webdir/temp.



3. Перезапуск хоста (3. Reboot host)

Перезагрузка хоста, находящегося в пуле, осуществляется с помощью меню 1. Manage servers in the pool > 3. Reboot host.

Для этого необходимо задать имя хоста (в данном примере - server2) и согласиться на перезапуск сервера:



4. Обновление пакетов на хосте (4. Update packages on host)

С помощью менеджера пула можно удаленно обновлять Веб-окружение и компоненты системы на любом хосте, входящем в пул.

Например, в пул добавлена виртуальная машина версии 7.4.0, нам нужно обновить ее до 7.4.х.

  • Выбираем пункт меню 1. Manage servers in the pool > 4. Update packages on host, система спросит имя хоста для обновления и выбор, что обновлять – только окружение (bitrix) или полностью систему и окружение (all):

  • Менеджер пула запустит задачу обновления Веб-окружения на удаленном хосте:

    Важно! В процессе обновления BitrixVM версии PHP и MySQL автоматически не обновляются. Обновить их можно в ручном режиме с помощью пункта меню виртуальной машины 1. Manage hosts in the pool - 8. Update PHP and MySQL.

  • Через некоторое время система на удаленном хосте обновится до последней версии (в данном примере - 7.4.3)

Таким же образом можно обновлять включенные в пул виртуальные машины ранних версий.


Внимание! Задачи могут выполняться довольно длительное время (до 2-3 часов и более) в зависимости от сложности задачи, объема данных, используемых в этих задачах, мощности и загруженности сервера. Проверить текущие выполняемые задачи можно с помощью меню 10. Background pool tasks > 1. View running tasks. Если по каким-либо причинам нужно посмотреть лог-файлы выполнения задач, то они находятся в директории /opt/webdir/temp.



5. Смена пароля пользователя bitrix (5. Change 'bitrix' user password on host)

Смена пароля для пользователя bitrix осуществляется через пункт меню 1. Manage servers in the pool > 5. Change 'bitrix' user password on host.

Будет выдан запрос имени хоста, на котором нужно сменить старый пароль пользователя bitrix, указать новый и дать согласие на смену:

Внимание! Сменить пароль пользователя root через меню виртуальной машины нельзя. Для этого необходимо воспользоваться системными командами ОС. Например, для Centos 6/7 консольная команда смены пароля пользователя root: passwd.



6. Настройка таймзоны в пуле (6. Configure pool timezone)

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

Дата и время на сервере – это не одна конкретная дата и время, а фактически три различных времени:

  • сервера
  • PHP
  • MySQL

Каждое из них – со своим часовым поясом.

Примечание: По умолчанию в BitrixVM выставлена зона Europe/Moscow (MSK, UTC+03).

Смена таймзоны происходит через пункт меню веб-окружения 1. Manage servers in the pool > 6. Configure pool timezone, и меняет дату и время в трёх местах сразу. Это очень важный момент, чтобы все три места работали с одинаковыми параметрами.

  • После выбора континента, страны и города будет выведен запрос на согласие применения данной таймзоны:

  • После этого будет предложено также изменить таймзону для PHP:

  • И в заключение нужно подтвердить изменение таймзоны для всех серверов, входящих в пул:

Примечание: Корректность установки времени у PHP и MySQL можно проверить также через административный веб интерфейс продуктов «1C-битрикс»: Настройки > Инструменты > Проверка системы.



7. Удаление конфигурации пула (7. Remove pool configuration)

Внимание При удалении конфигурации пула происходит сброс информации о нодах и настроек подключения к ним. Поэтому не рекомендуется это делать, если:

Удаление конфигурации пула осуществляется с помощью меню 1. Manage servers in the pool > 7. Remove pool configuration. После подтверждения конфигурация пула будет удалена:

Меню же вернется к своему первоначальному состоянию:


Внимание! Задачи могут выполняться довольно длительное время (до 2-3 часов и более) в зависимости от сложности задачи, объема данных, используемых в этих задачах, мощности и загруженности сервера. Проверить текущие выполняемые задачи можно с помощью меню 10. Background pool tasks > 1. View running tasks. Если по каким-либо причинам нужно посмотреть лог-файлы выполнения задач, то они находятся в директории /opt/webdir/temp.



8. Обновление PHP и MySQL (8. Update PHP and MySQL)

Обновлять версии PHP и MySQL необходимо, исходя из рекомендуемых системных требований продуктов «1С-Битрикс».

В процессе обновления VMBitrix они автоматически не обновляются. Обновить их нужно в ручном режиме с помощью соответствующего пункта меню виртуальной машины 1. Manage servers in the pool - 8. Update PHP and MySQL.

Примечание: Указанный выше пункт меню присутствует в BitrixVM, начиная с версии 5.1.х и выше.

Укажите для обновления машину с конкретным именем хоста hostname:

Примечание. Можно указать all для обновления на всех машинах с ролью web, входящих в пул. Однако эта опция работает только при обновлении PHP. Для обновления MySQL выбирайте конкретные сервера по отдельности.

Далее можно выбрать варианты, что именно обновить:


1. Upgrade PHP

Для обновления версии выберите подходящий пункт Update PHP to version х.х:

Примечание: На данный момент возможные версии: 5.6, 7.0, 7.1, 7.2, 7.3, 7.4, 8.0, 8.1.
C 1 февраля 2023 года для всех продуктов компании «1С-Битрикс» минимальная версия PHP – 8.0, рекомендуемая – 8.1.

2. Downgrade PHP

Аналогичным способом можно и понизить версию PHP, выбрав нужную с помощью пункта меню Downgrade PHP to version х.х. Для VMbitrix.CRM минимальная версия – 7.0.


3. Upgrade MySQL version

Если вы обновили VMBitrix до версии 7.1 и выше, то у вас появится возможность обновить версию MySQL до 5.7 Percona DB. Сделать это можно, выбрав пункт Upgrade MySQL to 5.7 version:

После обновления MySQL до версии 5.7 появится возможность обновить MySQL до версии 8.0 – Upgrade MySQL to 8.0 version:

Внимание! После обновления MySQL до версии 8.0 обратно понизить версию до 5.7 через меню VMBitrix нельзя.

Внимание! Задачи могут выполняться довольно длительное время (до 2-3 часов и более) в зависимости от сложности задачи, объема данных, используемых в этих задачах, мощности и загруженности сервера. Проверить текущие выполняемые задачи можно с помощью меню 10. Background pool tasks > 1. View running tasks. Если по каким-либо причинам нужно посмотреть лог-файлы выполнения задач, то они находятся в директории /opt/webdir/temp.

Если обновления объёмные


9. Изменить имя хоста (9. Change hostname)

Смена имени хоста в пуле осуществляется через пункт меню 1. Manage servers in the pool > 9. Change hostname.

Будет выдан запрос имени хоста, на котором нужно сменить его старое имя, указать новое и дать согласие на смену:

После успешного выполнения задачи, будет сохранено новое название:



10. Использование бета-версии BitrixEnv (10. Enable or disable bitrix-env beta versions)

Бета-версии

Внимание! Для операций, описанных в данной главе, необходимы знания администрирования *nix-систем. Перед началом проведения данных операций рекомендуется сделать полный бекап «Виртуальной машины».

При разработке своих решений на основе виртуальной машины BitrixEnv/VMBitrix.CRM, может понадобиться отслеживание изменений в ее версиях файлов и новых возможностей. Для этого вы можете включить репозиторий бета-версии BitrixEnv/VMBitrix.CRM или подключить репозиторий исходников виртуальной машины и отслеживать все изменения.

Внимание!
  • Сама бета-версия и ее исходные коды доступны для BitrixEnv/VMBitrix.CRM, начиная с версии 7.3.10.
  • Обратного отката установленной бета-версии BitrixEnv/VMBitrix.CRM к стабильной нет. Чтобы перейти к ней, нужно дождаться релиза стабильной версии, новее беты, или установить текущую стабильную заново. Например, для бета-версии 7.3.10, нужно ждать стабильную версию 7.4.


Нумерация бета-версий

Мы решили оставить небольшой запас для возможности выпускать стабильные версии. Поэтому они будут иметь номер выше, чем текущая стабильная BitrixEnv/VMBitrix.CRM. Например, текущая – 7.3.2, бета – 7.3.10. До версии 7.3.10 могут быть выпущены стабильные версии, с версии 7.3.10 и выше – беты. Для нового релиза, например 7.4.xx, порядок тот же: до 7.4.10 – стабильные, 7.4.10 и выше – беты и т.д.

Функционал бета-версий

Все исправления, дополнения и новый функционал, выпускаемый в бете, выйдет в следующей стабильной версии.

Жизненный цикл бета-версии

Ориентировочно 2-4 месяца, после чего все изменения должны уйти в релиз стабильного варианта.

Включение/выключение

Как включить или выключить бета-версию BitrixEnv/VMBitrix.CRM

  1. Если у вас стабильный вариант, вам нужно обновить BitrixEnv/VMBitrix.CRM до 7.3.2 или выше.

  2. Далее есть 2 пути:
    • если пул не создан:
      • включить: 2. Configure localhost settings > 7. Enable or disable beta version of bitrix-env > 1. Enable bitrix-env beta versions.
      • выключить: 2. Configure localhost settings > 7. Enable or disable beta version of bitrix-env > 1. Disable bitrix-env beta versions.

    • если пул создан:
      • включить: 1. Manage Hosts in the pool > 10. Enable or disable bitrix-env beta versions > 1. Enable bitrix-env beta versions.
      • выключить: 1. Manage Hosts in the pool > 10. Enable or disable bitrix-env beta versions > 1. Disable bitrix-env beta versions.
      или:
      • включить: 2. Configure localhost settings > 7. Enable or disable beta version of bitrix-env > 1. Enable bitrix-env beta versions.
      • выключить: 2. Configure localhost settings > 7. Enable or disable beta version of bitrix-env > 1. Disable bitrix-env beta versions.

      Для VMBitrix.CRM (т.к пул создается сразу при установке машины):
      • включить: 2. Configure localhost settings > 7. Enable or disable beta version of bitrix-env > 1. Enable bitrix-env beta versions
      • выключить: 2. Configure localhost settings > 7. Enable or disable beta version of bitrix-env > 1. Disable bitrix-env beta versions

  3. Затем необходимо обязательно обновить пакеты через меню машины либо командой:

    yum clean all && yum update
    


Бета или стабильный?

Как определить, какой репозиторий используется: бета или стабильный?

Выполнить команду:

yum clean all
В строке со списком репозиториев для беты будет bitrix-beta, для стабильной bitrix. Например:
Cleaning repos: base bitrix-beta bitrix-source epel ...


Как вернуть стабильную

Обратного отката установленной беты к текущей стабильной нет, то есть если вы перешли, например, на бету 7.4.13, то вернуться к стабильной 7.4.4 нельзя.
В этом случае нужно дождаться релиза стабильной версии, новее беты, или установить её заново. Например для бета-версии 7.4.13, нужно ждать стабильную версию 7.5.
Не забудьте предварительно перейти к использованию репозитория стабильной версии, отключив репозиторий беты.

Как получить исходники

Скачать исходники можно так же, как и исходники стабильной.

Где посмотреть список изменений

Список изменений публикуется в главе Что нового?. Обсуждение бета версии происходит на форуме.

2. Управление локальным сервером (2. Configure localhost settings)



1. Изменение имени хоста (1. Configure hostname)

Чтобы задать имя хоста локального сервера, нужно перейти в главном меню 2. Manage localhost - 1. Configure hostname.

Далее согласиться на изменение и ввести название Input hostname, например, server1 (по умолчанию это localhost.localdomain):

После чего системе будет присвоено новое имя:

Примечание: Название для хоста можно выбрать любое, какое хотите: bx1, server10, mysite.com (можно и имя домена, если он один) и т.д.



2. Настройка IP-адреса сервера через DHCP (2. Configure network interface via DHCP)

При первом старте BitrixVM получение IP-адреса сервером происходит автоматически, если в сети есть настроенный DHCP-сервер.

Чтобы с помощью него сменить или обновить IP-адрес локального сервера, нужно:

  • Перейти в главном меню 2. Manage localhost - 2. Configure network interface via DHCP.
  • Выбрать сетевой интерфейс (в данном примере ens33) и автоматически будет получен IP-адрес от DHCP-сервера:



3. Настройка IP-адреса сервера вручную (3. Configure network inteface manually)

Для задания IP-адреса в ручном режиме необходимо:

  • Перейти в главном меню 2. Manage localhost - 3. Configure network interface manually.
  • Выбрать сетевой интерфейс (в данном примере - ens33).
  • Ввести данные:

    • Type IP address - новый IP-адрес сервера;
    • Type broadcast - широковещательный адрес сети;
    • Type network mask - маска подсети;
    • Type default gateway - шлюз по умолчанию;
    • Type DNS server - адрес DNS-сервера.
  • Проверить введенные данные и дать согласие на изменение параметров сети сервера:



4. Перезагрузка сервера (4. Reboot server)

Чтобы перезапустить сервер виртуальной машины BitrixVM, нужно перейти в главном меню 2. Manage localhost - 4. Reboot server.

Далее согласиться на перезапуск сервера:



5. Выключение сервера (5. Shutdown server)

Чтобы выключить сервер виртуальной машины BitrixVM, нужно перейти в главном меню 2. Manage localhost - 5. Shutdown server.

Далее согласиться на остановку сервера:



6. Обновление локального сервера (6. Update server)

Обновление

Внимание! Обновление продукта «1C-Битрикс: Виртуальная машина» - сложная операция, в процессе которой происходит обновление системных файлов операционной системы виртуальной машины, и для этого необходимы соответствующие знания администрирования *nix-систем. Перед запуском обновления рекомендуется сделать полный бекап «Виртуальной машины».


Для обновления локальной виртуальной машины необходимо выбрать в административном меню пункт 2. Manage localhost - 6. Update server и согласиться на обновление.

Скрипт автоматически проверит обновления компонентов и произведет их установку.

Внимание! Этот пункт меню запускает обновление компонентов BitrixVM/BitrixEnv и CentOS. Если у вас несколько серверов в пуле (кластер), или вы хотите обновить только пакеты BitrixVM/BitrixEnv, то целесообразно производить обновление виртуальных машин пула.



Ошибки и их решение

  1. Если в процессе обновления BitrixVM случится ошибка примерно такого вида:
    Failing package is: Percona-Server-Client-57-5.7.25-28.1.el7.x86_64
    GPG Keys are configured as: file:///etc/pki/rpm-gpg/RPM-GPG-KEY-Percona
    
    То нужно выполнить команду обновления пакета Percona:
    yum install https://repo.percona.com/yum/percona-release-latest.noarch.rpm
    

    И далее запустить обновление заново через меню.

  2. Если после обновления, что-то перестанет работать, то можно вернуть полностью или частично старые файлы настроек соответствующей службы, т.к. конфигурационные файлы при обновлении не перезаписываются, а сохраняются в файлах *.ori.(метка времени).

  3. Также в процессе обновления могут отключиться некоторые модули php. Для их включения необходимо выполнить следующие команды:
    mv -f /etc/php.d/(имя модуля).ini.disabled /etc/php.d/(имя модуля).ini
    service httpd restart
    
  4. Если в процессе обновления появится ошибка, что недостаточно места в загрузочном разделе /boot:

    At least 26MB more space needed on the /boot filesystem.
    
    То нужно в /etc/yum.conf установить installonly_limit=2.

    Затем очистить старые ядра командой:
    package-cleanup --oldkernels --count=2
    



Внимание! Задачи могут выполняться довольно длительное время (до 2-3 часов и более) в зависимости от сложности задачи, объема данных, используемых в этих задачах, мощности и загруженности сервера. Проверить текущие выполняемые задачи можно с помощью меню 5. Background tasks in the pool > 1. View running tasks. Если по каким-либо причинам нужно посмотреть лог-файлы выполнения задач, то они находятся в директории /opt/webdir/temp.



7. Использование бета-версии BitrixEnv (7. Enable or disable bitrix-env beta versions)

Бета-версии

Внимание! Для операций, описанных в данной главе, необходимы знания администрирования *nix-систем. Перед началом проведения данных операций рекомендуется сделать полный бекап «Виртуальной машины».

При разработке своих решений на основе виртуальной машины BitrixEnv/VMBitrix.CRM, может понадобиться отслеживание изменений в ее версиях файлов и новых возможностей. Для этого вы можете включить репозиторий бета-версии BitrixEnv/VMBitrix.CRM или подключить репозиторий исходников виртуальной машины и отслеживать все изменения.

Внимание!
  • Сама бета и ее исходные коды доступны для BitrixEnv/VMBitrix.CRM, начиная с 7.3.10.
  • Обратного отката установленной бета-версии BitrixEnv/VMBitrix.CRM к стабильной нет. Чтобы перейти на стабильную, нужно дождаться релиза стабильной версии, новее беты, или установить её заново. Например, для бета-версии 7.3.10, нужно ждать стабильную 7.4.


Нумерация бета-версий

Мы решили оставить небольшой запас для возможности выпускать стабильные версии. Поэтому беты будут иметь номер выше, чем текущая стабильная BitrixEnv/VMBitrix.CRM. Например, текущая – 7.3.2, бета – 7.3.10. До 7.3.10 могут быть выпущены стабильные версии, а с 7.3.10 и выше – беты. Для нового релиза, например 7.4.xx, порядок тот же: до 7.4.10 – стабильные, 7.4.10 и выше – беты и т.д.

Функционал бета-версий

Все исправления, дополнения и новый функционал, выпускаемый в бете, выйдет в следующей стабильной версии.

Жизненный цикл

Ориентировочно 2-4 месяца, после чего все изменения должны уйти в релиз стабильной версии.

Включение/выключение

Как включить или выключить бета-версию BitrixEnv/VMBitrix.CRM

  1. Если у вас стабильная версия машины, вам нужно обновить BitrixEnv/VMBitrix.CRM до 7.3.2 или выше.

  2. Далее есть 2 пути:
    • если пул не создан:
      • включить: 2. Configure localhost settings > 7. Enable or disable beta version of bitrix-env > 1. Enable bitrix-env beta versions.
      • выключить: 2. Configure localhost settings > 7. Enable or disable beta version of bitrix-env > 1. Disable bitrix-env beta versions.

    • если пул создан:
      • включить: 1. Manage Hosts in the pool > 10. Enable or disable bitrix-env beta versions > 1. Enable bitrix-env beta versions.
      • выключить: 1. Manage Hosts in the pool > 10. Enable or disable bitrix-env beta versions > 1. Disable bitrix-env beta versions.
      или:
      • включить: 2. Configure localhost settings > 7. Enable or disable beta version of bitrix-env > 1. Enable bitrix-env beta versions.
      • выключить: 2. Configure localhost settings > 7. Enable or disable beta version of bitrix-env > 1. Disable bitrix-env beta versions.

      Для VMBitrix.CRM (т.к пул создается сразу при установке машины):
      • включить: 2. Configure localhost settings > 7. Enable or disable beta version of bitrix-env > 1. Enable bitrix-env beta versions
      • выключить: 2. Configure localhost settings > 7. Enable or disable beta version of bitrix-env > 1. Disable bitrix-env beta versions

  3. Затем необходимо обязательно обновить пакеты через меню машины либо командой:

    yum clean all && yum update
    


Бета или стабильный?

Как определить, какой репозиторий используется: бета или стабильный?

Выполнить команду:

yum clean all
В строке со списком репозиториев для беты будет bitrix-beta, для стабильной bitrix. Например:
Cleaning repos: base bitrix-beta bitrix-source epel ...


Как вернуть стабильную версию

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

Как получить исходники

Скачать исходники можно так же, как и исходники стабильной версии.

Где посмотреть список изменений

Список изменений публикуется в главе Что нового?. Обсуждение бета версии происходит на форуме.

3. Настройка службы MySQL для пула (3. Configure MySQL service for the pool)

1. Обновить настройки для всех MySQL-серверов (1. Update settings for all MySQL servers)

Чтобы обновить настройки для всех MySQL-серверов, нужно перейти в главном меню 3. Configure MySQL service for the pool - 1. Update settings for all MySQL servers:

Опция обновляет конфигурацию одного или нескольких MySQL-серверов в пуле (если такое имеется) и приводит их к дефолтным настройкам для виртуальной машины.


Внимание! Задачи могут выполняться довольно длительное время (до 2-3 часов и более) в зависимости от сложности задачи, объема данных, используемых в этих задачах, мощности и загруженности сервера. Проверить текущие выполняемые задачи можно с помощью меню 10. Background tasks in the pool > 1. View running tasks. Если по каким-либо причинам нужно посмотреть лог-файлы выполнения задач, то они находятся в директории /opt/webdir/temp.



2. Изменить пароль пользователя root для MySQL (2. Change password for MySQL root user)

Внимание! В BitrixVM/BitrixEnv версии 7.x+ пароль root для MySQL-сервера не может быть пустым. При первом запуске BitrixVM он автоматически создается, а при установке BitrixEnv будет выдан запрос на его создание.

Если вам понадобилось сменить пароль root MySQL-сервера, нужно перейти в главном меню 3. Configure MySQL service for the pool - 2.Change password for MySQL root user.

Далее выбрать нужный сервер (имя хоста), согласиться на изменение и ввести новый пароль.



3. Остановить/Запустить службу MySQL на сервере (3. Stop/Start MySQL service on the server)

Остановить или запустить MySQL-сервер можно в главном меню 3. Configure MySQL service for the pool - 3. Stop/Start MySQL service on the server .

Далее выбрать нужный сервер (имя хоста), согласиться на остановку или старт:



4. Создать slave MySQL-сервер (4. Create MySQL slave)

Конфигурация master-slave

В «1C-Битрикс: Виртуальная машина» можно быстро развернуть кластерную конфигурацию master-slave «1С-Битрикс: Управление сайтом» и «Битрикс24 в коробке».

Ключевые особенности:

  • гибкая балансировка нагрузки SQL
  • простота администрирования
  • дешевое и быстрое неограниченное масштабирование
  • он-лайн бэкап
  • не требуется доработка логики веб-приложения

Схема «master - slave» реализуется средствами MySQL. Платформа «1С-Битрикс» позволяет гибко балансировать нагрузку между серверами, участвующими в репликации.

Внимание! Перед тем как начинать конфигурировать схему «master - slave» в BitrixVM/BitrixEnv нужно предварительно установить продукты «1С-Битрикс: Управление сайтом» или в «Битрикс24 в коробке» с модулем Веб-кластер. Данный модуль входит только в старшие редакции продуктов «1С-Битрикс».



Как создать slave сервер MySQL

Для создания slave сервера MySQL нужно:

  • Выбрать пункт меню 3. Configure MySQL service for the pool > 4. Create MySQL slave, ввести имя хоста в пуле, на котором будет создан slave сервер MySQL (в данном примере - server2):

  • Придумать и ввести пароли репликации и кластера:

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

  • Подождать, пока задача по добавлению slave cервера MySQL будет закончена.
  • Создадим аналогичным образом еще один slave сервер MySQL (server3). В итоге получим три сервера MySQL: master (server1) и два slave (server2 и server3):


Внимание! Задачи могут выполняться довольно длительное время (до 2-3 часов и более) в зависимости от сложности задачи, объема данных, используемых в этих задачах, мощности и загруженности сервера. Проверить текущие выполняемые задачи можно с помощью меню 10. Background tasks in the pool > 1. View running tasks. Если по каким-либо причинам нужно посмотреть лог-файлы выполнения задач, то они находятся в директории /opt/webdir/temp.



5. Смена master сервера MySQL (5. Change master MySQL server)

Для переноса master сервера MySQL на другую машину необходимо:

  • Выбрать пункт меню 3. Configure MySQL service for the pool > 5. Change master MySQL server.

    Примечание: Данный пункт меню появится только тогда, когда будет создан хотя бы 1 slave-сервер MySQL с помощью меню 3. Configure MySQL servers > 4. Create slave MySQL server.

  • Ввести имя хоста для будущего master сервера из списка доступных slave (например server2):

  • Подождать, пока задача по смене будет закончена.
  • В итоге серверы станут: master (server2) и два slave (server1 и server3):

Таким образом, мы перенесли master сервер MySQL с машины server1 на server2.


Внимание! Задачи могут выполняться довольно длительное время (до 2-3 часов и более) в зависимости от сложности задачи, объема данных, используемых в этих задачах, мощности и загруженности сервера. Проверить текущие выполняемые задачи можно с помощью меню 10. Background tasks in the pool > 1. View running tasks. Если по каким-либо причинам нужно посмотреть лог-файлы выполнения задач, то они находятся в директории /opt/webdir/temp.



6. Удаление slave сервера MySQL (6. Remove slave MySQL server)

Для удаления slave сервера MySQL необходимо:

  • Выбрать пункт меню 3. Configure MySQL service for the pool > 6. Remove slave MySQL server.

    Примечание: Данный пункт меню появится только тогда, когда будет создан хотя бы 1 slave-сервер MySQL с помощью меню 3. Configure MySQL servers > 4. Create slave MySQL server.

  • Ввести имя хоста удаляемого slave сервера (например server1):

  • Подождать, пока задача по удалению будет закончена.
  • В итоге серверы станут: master (server2) и один slave (server3):

Таким образом, мы освободили ресурсы машины server1 под другие роли.


Внимание! Задачи могут выполняться довольно длительное время (до 2-3 часов и более) в зависимости от сложности задачи, объема данных, используемых в этих задачах, мощности и загруженности сервера. Проверить текущие выполняемые задачи можно с помощью меню 10. Background tasks in the pool > 1. View running tasks. Если по каким-либо причинам нужно посмотреть лог-файлы выполнения задач, то они находятся в директории /opt/webdir/temp.



4. Настройка службы Memcached для пула(4.Configure Memcached service for the pool)

Продукты «1С-Битрикс» позволяют использовать пул серверов memcached для работы с кешем данных.

Это обеспечивает:

  • высокую эффективность - за счет централизованного использования кеша веб-приложением;
  • надежность - за счет устойчивости подсистемы кеширования к выходу из строя отдельных компонентов;
  • неограниченную масштабируемость - за счет добавления новых memcached-серверов.

Внимание! Перед тем как начинать использовать пул серверов memcached в BitrixVM/BitrixEnv нужно предварительно установить продукты «1С-Битрикс: Управление сайтом» или в «Битрикс24 в коробке» с модулем Веб-кластер. Данный модуль входит только в старшие редакции продуктов «1С-Битрикс».



1. Настройка службы memcached (1.Configure memcached service)

Для создания memcached сервера нужно:

  • Выбрать пункт меню Configure Memcached service for the pool > 1. Configure memcached service.
  • Ввести имя хоста в пуле, на котором будет запущен сервер (в данном примере - server1):

  • Подождать, пока задача по запуску будет закончена:

Внимание! Задачи могут выполняться довольно длительное время (до 2-3 часов и более) в зависимости от сложности задачи, объема данных, используемых в этих задачах, мощности и загруженности сервера. Проверить текущие выполняемые задачи можно с помощью меню 10. Background tasks in the pool > 1. View running tasks. Если по каким-либо причинам нужно посмотреть лог-файлы выполнения задач, то они находятся в директории /opt/webdir/temp.

2. Обновить настройки memcached сервера (2. Update settings on all memcached servers)

Чтобы обновить настройки для всех memcached -серверов, нужно перейти в главном меню 4. Configure memcached servers - 2. Update settings on all memcached servers:

Примечание: Данный пункт меню появится только тогда, когда будет создан хотя бы 1 memcached-сервер с помощью меню 4. Configure memcached servers > 1. Create memcached server.

Эта опция запускает проверку текущей конфигурации одного или нескольких memcached-серверов в пуле (если такие имеются).


Внимание! Задачи могут выполняться довольно длительное время (до 2-3 часов и более) в зависимости от сложности задачи, объема данных, используемых в этих задачах, мощности и загруженности сервера. Проверить текущие выполняемые задачи можно с помощью меню 5. Background tasks in the pool > 1. View running tasks. Если по каким-либо причинам нужно посмотреть лог-файлы выполнения задач, то они находятся в директории /opt/webdir/temp.



3. Удаление memcached сервера (3. Remove memcached server)

Для удаления memcached сервера необходимо:

  • Выбрать пункт меню 4. Configure memcached servers > 3. Remove memcached server.

    Примечание: Данный пункт меню появится только тогда, когда будет создан хотя бы 1 memcached-сервер с помощью меню 4. Configure memcached servers > 1. Create memcached server.

  • Ввести имя хоста удаляемого сервера (например server1):

  • Подождать, пока задача по удалению будет закончена.

Внимание! Задачи могут выполняться довольно длительное время (до 2-3 часов и более) в зависимости от сложности задачи, объема данных, используемых в этих задачах, мощности и загруженности сервера. Проверить текущие выполняемые задачи можно с помощью меню 5. Background tasks in the pool > 1. View running tasks. Если по каким-либо причинам нужно посмотреть лог-файлы выполнения задач, то они находятся в директории /opt/webdir/temp.



5. Мониторинг (5. Configure pool monitoring)

При разворачивании проектов на базе BitrixVM/BitrixEnv необходимо следить за состоянием сервера и отдельных его компонентов.

В составе BitrixVM/BitrixEnv уже имеются системы мониторинга - Munin и Nagios, которые имеют большое количество различных компонентов по отслеживанию функционирования всех систем сервера или нескольких серверов в составе кластера.



1. Настроить сервисы мониторинга (1. Configure monitoring services)

Начало работы

Внимание! Для корректной работы сервиса мониторинга необходима версия виртуальной машины не ниже 7.3.1.

Для начала работы систем мониторинга необходимо:

  1. В главном меню виртуальной машины выбрать пункт 5.Configure pool monitoring > 1. Configure monitoring services:

  2. Затем мастер предложит задать логин и пароль для сервисов мониторинга сервера Nagios и Munin:

    Логины / пароли по умолчанию (рекомендуется сменить на свои):
    Nagios: nagiosadmin / nagiosBitrixMon
    Munin: admin / muninBitrixMon

  3. Далее нужно будет указать e-mail для системных уведомлений Nagios и данные почтового сервера для отправки e-mail. Если отказаться, будет по умолчанию использоваться e-mail root-пользователя:

    • email address - адрес отправителя, от которого будет осуществляться пересылка писем. В данном случае этот email будет использоваться также как и получатель уведомлений от Nagios.
    • server address or DNS - ip- или dns-адрес почтового сервера. Если нажать Enter, то будет использован адрес по умолчанию (127.0.0.1)
    • server port - порт сервера. Порт зависит от типа соединения, 25 - для обычного и 465 - для зашифрованного (с использованием SSL). Если нажать Enter, то будет использован порт по умолчанию (25).
    • Если необходима SMTP-авторизация, то в строке SMTP authentication наберите y и введите логин и пароль для доступа к SMTP-серверу, в противном случае - n.
    • Если выбрана опция SMTP-авторизации, то понадобится ввести тип авторизации type of authentication method: auto, plain, scram-sha-1, cram-md5, gssapi, external, digest-md5, login, ntlm.
    • Если необходим TLS-протокол защищенной передачи данных, то в строке TLS enabled наберите y, в противном случае - n.
  4. Затем мастер сделает необходимые настройки и запустит сервисы мониторинга сервера.


Внимание! Задачи могут выполняться довольно длительное время (до 2-3 часов и более) в зависимости от сложности задачи, объема данных, используемых в этих задачах, мощности и загруженности сервера. Проверить текущие выполняемые задачи можно с помощью меню 10. Background pool tasks > 1. View running tasks. Если по каким-либо причинам нужно посмотреть лог-файлы выполнения задач, то они находятся в директории /opt/webdir/temp.



Мониторинг

Для мониторинга сервера из браузера нужно зайти по адресам и авторизоваться под учетными записями мониторинга:

  • Munin - http://адрес_сервера/munin/:

  • Nagios - http://адрес_сервера/nagios/:

Примечание: Сменить пароли для систем мониторинга можно с помощью повторного запуска пункта меню 5.Configure pool monitoring > 1. Configure monitoring services.



Как проверить e-mail уведомления от Nagios

Проверить работу нотификаций можно легко:

  • Например, остановим сервис МySQL:

    CentOS 6:

    service mysqld stop
    

    CentOS 7:

    systemctl stop mysqld.service
    
  • По умолчанию Nagios будет записывать в лог 3 сообщения со статусом CRITICAL;SOFT каждую минуту, а 4-му сообщению даст статус CRITICAL;HARD:

    В итоге сообщение примерно такого содержания должно прийти на почту, указанную в п.3 настройки уведомлений для админа (поле from address):

    Subject: ** PROBLEM Service Alert: server2/MySQL: connection to 3306 is CRITICAL **
    
    ***** Nagios *****
    
    Notification Type: PROBLEM
    
    Service: MySQL: connection to 3306
    Host: server2
    Address: 192.168.1.246
    State: CRITICAL
    
    Date/Time: Wed Jul 5 14:12:46 MSK 2017
    
    Additional Info:
    
    connect to address 192.168.1.246 and port 3306: Connection refused
    
  • После запуска службы MySQL командой # service mysqld start (CentOS 6) или # systemctl start mysqld.service (CentOS 7) в логе Nagios-а появится запись со статусом OK;HARD:

    И должно прийти сообщение на почту:

    Subject: ** RECOVERY Service Alert: server2/MySQL: connection to 3306 is OK **
    
    ***** Nagios *****
    
    Notification Type: RECOVERY
    
    Service: MySQL: connection to 3306
    Host: server2
    Address: 192.168.1.246
    State: OK
    
    Date/Time: Wed Jul 5 14:22:46 MSK 2017
    
    Additional Info:
    
    TCP OK - 0.001 second response time on 192.168.1.246 port 3306
    
  • Как видим, все работает - при возникновении неполадок на каком-либо сервере Nagios отправит уведомление админу на почту с указанием проблемы.

Примечание: Подробнее о email уведомлениях можно прочитать в документации Nagios.



2. Выключить сервисы мониторинга (2. Disable monitoring services)

Для выключения сервисов мониторинга Nagios и Munin необходимо:

  • Выбрать пункт меню 5. Configure pool monitoring > 2. Disable monitoring services:

  • Согласиться на действие:

  • Подождать, пока задача выключения сервисов мониторинга будет закончена.

Внимание! Задачи могут выполняться довольно длительное время (до 2-3 часов и более) в зависимости от сложности, объема данных, используемых в этих задачах, мощности и загруженности сервера. Проверить текущие выполняемые задачи можно с помощью меню 5. Configure pool monitoring > 1. View running tasks. Если по каким-либо причинам нужно посмотреть лог-файлы их выполнения, то они находятся в директории /opt/webdir/temp.



3. Добавить хосты для мониторинга (3. Add new host(s) on monitoring)

Если запущены системы мониторинга серверов и был добавлен новый хост в кластер, то система сама отследит новую машину и запустит задачу на добавление этой машины в мониторинг.

Пункт меню 5. Configure pool monitoring > 3. Add new host(s) on monitoring позволяет вручную запустить добавление нового хоста в систему мониторинга, если по каким-либо причинам он не добавился в мониторинг:

Примечание: При выборе 5. Configure pool monitoring > 3. Add new host(s) on monitoring) задача на автоматическое добавление нового хоста в мониторинг запустится сразу, без каких-либо запросов.


Внимание! Задачи могут выполняться довольно длительное время (до 2-3 часов и более) в зависимости от сложности задачи, объема данных, используемых в этих задачах, мощности и загруженности сервера. Проверить текущие выполняемые задачи можно с помощью меню 10. Background pool tasks > 1. View running tasks. Если по каким-либо причинам нужно посмотреть лог-файлы выполнения задач, то они находятся в директории /opt/webdir/temp.



6. Управление сайтами (6. Configure pool sites)

1. Создание сайта (1. Create site)

Внимание! После создания дополнительного сайта необходимо обязательно удалить созданный при установке дефолтный сайт, если он не используется.

Мастер создания дополнительных сайтов, позволяет развернуть на одной виртуальной машине несколько сайтов, как на независимых установках «1С-Битрикс», так и в рамках многосайтовости.

Внимание! В BitrixVM\BitrixEnv версии 7.х root пароль к MySQL не может быть пустым, он задается для BitrixEnv на этапе установки, а для BitrixVM автоматически при первом старте. Изменить root пароль к MySQL можно в меню 3. Configure MySQL service for the pool > 2. Change password for mysql user root . Если root пароль к MySQL будет пустым, то при добавлении нового сайта будет выдана ошибка.


Для добавления дополнительного сайта необходимо:

  • Предварительно настроить DNS-записи в управлении доменами или в случае локальной установки указать доменное имя в /etc/hosts на виртуальной машине, а также на всех компьютерах, с которых будет осуществляться доступ к данному сайту.
  • Далее из административного меню запустить мастер 6. Configure pool sites > 1 Create site:

    и указать:
    1. Enter site name - доменное имя дополнительного сайта без www;

      Внимание! Если у вас домен в национальной кодировке (например, кириллический домен), то в данное поле нужно вводить имя домена в Punycode-формате, воспользовавшись любым Unicode-Punycode конвертером (например этим).

    2. Enter site type - тип установки ядра «1С-Битрикс»:
      • kernel - в случае создания дополнительного сайта в рамках отдельной установки - отдельное ядро продукта «1С-Битрикс» в новой директории сайта.
      • ext_kernel - отдельное ядро продукта «1С-Битрикс» в новой директории сайта для создания линков на это ядро в рамках многосайтовости, ядро будет недоступно напрямую, а только через дополнительные сайты (работает в паре с сайтами типа link).
      • link - в случае создания дополнительного сайта в рамках многосайтовости - общее ядро и данные в общей базе с уже установленным продуктом «1С-Битрикс» (работает в паре с ядром ext_kernel).
    3. Enter full path to the Bitrix installation directory - указать путь до ядра продукта «1С-Битрикс», на которые будут сделаны симлинки (для ядра типа link).
    4. Enter site encoding - указать кодировку будущего сайта: UTF-8 или windows 1251 (для ядра типа kernel и ext_kernel).
    5. Do you want to enable cron task on site - включить ли выполнение заданий на cron для будущего сайта (для ядра типа kernel и ext_kernel).
    6. Do you want to specify them - по умолчанию название, логин и пароль базы данных и root-директория сайта создаются автоматически (в файлах dbconn.php и .settings.php (с версии 20.900.0 - только в .settings.php)), но с помощью данной опции можно указать свои, выбрав ответ y (для ядра типа kernel и ext_kernel).
  • В процессе работы мастера будет создана директория на сервере: /home/bitrix/ext_www/{название_хоста}, в которой будут:
    • символические ссылки на директорию ядра, которую выбрали ранее (если был выбран вариант link).
    • директории и скрипт BitrixSetup для установки или восстановления продукта (если был выбран вариант kernel).
    • директории и скрипт BitrixSetup для восстановления продукта (если был выбран вариант ext_kernel).
  • После завершения задачи по добавлению сайта он будет готов к использованию.

    Примечание: Количество дополнительных сайтов ограничивается лишь лицензией «1С-Битрикс» данной установки.

Внимание! Если был выбран вариант ядра ext_kernel и установлено ядро в /home/bitrix/ext_www/{название_хоста}, то в списке сайтов виртуальной машины данное ядро не появится до тех пор, пока не будет создан хотя бы один сайт (link) на это ядро.


Внимание! Задачи могут выполняться довольно длительное время (до 2-3 часов и более) в зависимости от сложности задачи, объема данных, используемых в этих задачах, мощности и загруженности сервера. Проверить текущие выполняемые задачи можно с помощью меню 10. Background pool tasks > 1. View running tasks. Если по каким-либо причинам нужно посмотреть лог-файлы выполнения задач, то они находятся в директории /opt/webdir/temp.



2. Удалить сайт (2. Delete site)

Для удаления записи о дополнительном сайте необходимо в административном меню выбрать пункт 6. Configure pool sites > 2. Delete site и выбрать директорию удаляемого сайта (Enter site directory):

Внимание! Мастер удаления дополнительного сайта удаляет папку и базу данных дополнительного сайта, поэтому необходимо предварительно сделать бекап важных данных.


Внимание! Задачи могут выполняться довольно длительное время (до 2-3 часов и более) в зависимости от сложности задачи, объема данных, используемых в этих задачах, мощности и загруженности сервера. Проверить текущие выполняемые задачи можно с помощью меню 10. Background pool tasks > 1. View running tasks. Если по каким-либо причинам нужно посмотреть лог-файлы выполнения задач, то они находятся в директории /opt/webdir/temp.



3. Настройка задач cron (3. Change cron tasks on site)

По умолчанию в виртуальной машине cron уже включен. Если по каким-либо причинам нужно отключить эту службу, то для этого необходимо:

  • Перейти в главном меню в 6. Configure pool sites > 3. Change cron tasks on site и ввести директорию сайта, для которого нужно отключить службу cron:

  • Согласиться на отключение и дождаться пока задача будет закончена:

Аналогичным способом осуществляется и включение службы:


Внимание! Информацию о том, как настроить в продуктах «1С-Битрикс» обработку всех агентов на cron, можно прочитать здесь.



4. Настройка SMTP (4. Change e-mail settings on site)

Настройка SMTP-клиента

Для настройки SMTP-клиента выполните следующее:

  1. Перейти в главном меню в 6. Configure pool sites > 4. Change e-mail settings on site и ввести имя хоста, для которого нужно настроить отправку почты:

  2. Далее ввести необходимые данные:

    • from address - адрес отправителя, от которого будет осуществляться пересылка писем.
    • server address or DNS - ip- или dns-адрес почтового сервера. Если нажать Enter, то будет использован адрес по умолчанию (127.0.0.1)
    • server port - порт сервера. Порт зависит от типа соединения, чаще всего: 25 - для обычного и 465 - для зашифрованного (с использованием SSL). Если нажать Enter, то будет использован порт по умолчанию (25).
    • Если необходима SMTP-авторизация, то в строке SMTP authentication наберите y и введите логин и пароль для доступа к SMTP-серверу, в противном случае - n.
    • Если выбрана опция SMTP-авторизации, то понадобится ввести тип авторизации type of authentication method: auto, plain, scram-sha-1, cram-md5, gssapi, external, digest-md5, login, ntlm (например для yandex.ru достаточно auto, а для mail.ru - plain).
    • Если необходим TLS-протокол защищенной передачи данных, то в строке TLS enabled наберите y, в противном случае - n.

    Примечание: При настройке укажите данные своего или публичного почтового сервиса. Настройки для часто используемых сервисов можно взять в отдельном уроке.

  3. Дождаться пока задача по настройке SMTP будет закончена.

  4. Убедиться в правильности введенных настроек можно снова в 6. Configure pool sites > 4. Change e-mail settings on site:



Внимание! При использовании нескольких физических веб-серверов в пуле (веб-кластер) автоматически не создается конфигурация msmtp на других серверах пула. Для работы конфигурации msmtp на spare-нодах кластера нужно скопировать вручную через ssh файл /home/bitrix/.msmtprc с master-ноды на spare-ноды и сменить владельца/группу у этих файлов на bitrix:bitrix. Далее на spare-нодах создать файл /etc/@msmtprc и сделать симлинк с него на файл /home/bitrix/.msmtprc.


Где хранятся логи msmtp

В логах msmtp можно всегда посмотреть ошибки отправки писем. Находятся логи в директории /home/bitrix/.

Для каждого сайта свой лог msmtp, в названии лога будет указано имя сайта – msmtp_{SiteName}.log. Например для сайта по умолчанию лог будет иметь имя msmtp_default.log.



Внимание! Задачи могут выполняться довольно длительное время (до 2-3 часов и более) в зависимости от сложности задачи, объема данных, используемых в этих задачах, мощности и загруженности сервера. Проверить текущие выполняемые задачи можно с помощью меню 10. Background pool tasks > 1. View running tasks. Если по каким-либо причинам нужно посмотреть лог-файлы выполнения задач, то они находятся в директории /opt/webdir/temp.





Настройки для почтовых сервисов

Здесь представлены настройки некоторых почтовых сервисов.

Gmail

  • From Email address – ваш адрес, от имени которого будут отправляться письма (пример: mail@gmail.com)
  • Server address or DNS – smtp.gmail.com
  • Server port – 587
  • SMTP authentication – yes
  • Login – ваш полный логин (пример: mail@gmail.com)
  • SMTP authentication method – auto
  • Enable TLS – yes

Доступно подключение как через обычный пароль, так и через пароль приложения (рекомендуемый).

Примечание: Сервис Gmail может блокировать подключение по smtp в целях безопасности. Как изменить настройки доступа к аккаунту для небезопасных приложений читайте в справке Google.


Яндекс.Почта

  • From Email address – ваш адрес, от имени которого будут отправляться письма (пример: mail@yandex.ru)
  • Server address or DNS – smtp.yandex.ru
  • Server port – 25 или 587
  • SMTP authentication – yes
  • Login – ваш полный логин (пример: mail@yandex.ru)
  • SMTP authentication method – auto
  • Enable TLS – yes

Доступно подключение как через обычный пароль (с подтверждением аккаунта), так и через пароль приложения (рекомендуемый).

Примечание: Сервис Яндекс.Почта может блокировать подключение по smtp в целях безопасности. В логе msmtp можно всегда посмотреть ошибки отправки писем. Если ваше письмо заблокировано, в логе будет указана причина и ссылка с указанием действий для разблокировки.
Внимание! Яндекс включил строгий контроль адреса отправителя. Это значит, что вы больше не сможете через SMTP-клиент отправить письмо, если отправитель в поле From («От кого») отличается от авторизованного пользователя по SMTP. Указать несколько отправителей в поле From также не получится.


Mail.ru

  • From Email address – ваш адрес, от имени которого будут отправляться письма (пример: mail@mail.ru)
  • Server address or DNS – smtp.mail.ru
  • Server port – 465
  • SMTP authentication – yes
  • Login – ваш полный логин (пример: mail@mail.ru)
  • SMTP authentication method – plain
  • Enable TLS – yes

Доступно подключение как через обычный пароль, так и через пароль приложения (рекомендуемый).

Внимание! Mail.ru включил строгий контроль адреса отправителя. Это значит, что вы больше не сможете через SMTP-клиент отправить письмо, если отправитель в поле From («От кого») отличается от авторизованного пользователя по SMTP. Указать несколько отправителей в поле From также не получится. Кроме того, сервер ограничил отправку в 500 писем в день.

Дополнительно

  • Документация по серверам IMAP, SMTP и POP3 для настройки Mail.ru


Другие сервисы

Настройки для других smtp сервисов можно взять по ссылкам:



Где хранятся логи msmtp

В логах msmtp можно всегда посмотреть ошибки отправки писем. Находятся логи в директории /home/bitrix/.

Для каждого сайта свой лог msmtp, в названии лога будет указано имя сайта – msmtp_{SiteName}.log. Например для сайта по умолчанию лог будет иметь имя msmtp_default.log.



Важно! Сами SMTP-сервисы могут иметь свои лимиты на оправку через них рассылок и могут ограничивать ваши рассылки, вплоть до полной блокировки почтового аккаунта, через который будут рассылаться письма.

Например, у Яндекса и Google по умолчанию лимит на отправку – 500 писем в сутки. Если в письме несколько получателей, то письмо каждому из них считается отдельным письмом. Этот ежесуточный лимит может изменяться на основании их собственных алгоритмов подсчета благонадежности пользователя.



5. Настройка https на сайте (5. Change https settings on site)

  Доступ по HTTPS

По умолчанию в виртуальной машине включена поддержка доступа к сайтам через протоколы HTTP и HTTPS.

Если необходимо оставить доступ к сайту только по защищенному протоколу HTTPS, то для этого нужно:

  • Перейти в главном меню в 6. Configure pool sites > 5. Change https settings on site и ввести имя хоста, для которого нужно настроить протокол доступа:

  • Согласиться на отключение HTTP доступа и дождаться пока задача будет закончена:

    Внимание! Для доступа к сайту только по протоколу HTTPS необходим SSL-сертификат от доверенного центра сертификации, иначе браузеры будут выдавать ошибку, что сертификат безопасности сайта не является доверенным.

  Доступ по HTTP

Аналогичным способом осуществляется возврат доступа к сайту по протоколу HTTP:


Внимание! Задачи могут выполняться довольно длительное время (до 2-3 часов и более) в зависимости от сложности задачи, объема данных, используемых в этих задачах, мощности и загруженности сервера. Проверить текущие выполняемые задачи можно с помощью меню 10. Background pool tasks > 1. View running tasks. Если по каким-либо причинам нужно посмотреть лог-файлы выполнения задач, то они находятся в директории /opt/webdir/temp.



6. Настройка резервного копирования сайта (6. Change backup settings on site)

Копирование
по расписанию

При разворачивании проектов на базе BitrixVM/BitrixEnv, часто встает задача создания резервной копии проекта по расписанию.

В BitrixVM/BitrixEnv есть функционал автоматического резервного копирования сайта и базы данных. Бекап будет создан по расписанию в виде архива .tar.gz и записан в директории /home/bitrix/backup/archive/.

У данного способа есть как преимущества, так и недостатки в сравнении с встроенным в продукты «1С-Битрикс» механизмом создания резервной копии:

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


Создание
расписания

Для создания расписания автоматического резервного копирования средствами BitrixVM/BitrixEnv необходимо:

  • В меню виртуальной машины выбрать пункт 6. Configure pool sites > 6. Change backup settings on site.
  • Выбрать из списка имя хоста и согласиться на изменение настроек расписания автоматического резервного копирования:

  • Выбрать периодичность и час запуска автоматического резервного копирования:

    Если необходимо выполнить более точную настройку бэкапов, можно воспользоваться утилитой командной строки:

    /opt/webdir/bin/bx-sites -a backup -d dbcp --enable --minute=10 --hour=18 --day=any --month=any --weekday=any
    

    Примечание: Как настроить правильное время в BitrixVM/BitrixEnv см. здесь.

  • На этом работа мастера настройки завершена, и в Cron (/etc/crontab) добавляется задача резервного копирования проекта.

    Бэкап делается для ядра (сайта типа kernel и ext_kernel) и всех его link, если такие существуют. Для этого создается задание в crontab-файле. Например:

    10 22 * * * bitrix /opt/webdir/bin/bx_backup.sh sitemanager /home/bitrix/backup/archive
    

    В качестве первой опции указывается имя БД, второй опцией указывается каталог, в котором будет создан архив.

    В итоге скрипт создаст архив следующего вида: www_backup__DD.MM.YYYY_<random_string>.tar.gz (например - www_backup_dbcp_21.10.2014_1RJKXbMv.tar.gz).

    Внутри архива должны присутствовать следующие файлы:

    1. дамп БД /home/bitrix/mysql_dump__DD.MM.YYYY_.sql
    2. данные сайта ядра
    3. данные сайтов типа ссылок с полным путем


Управление бэкапами
через bx-sites

  • -a|--action - действие по управлению сайтами, в данном случае это backup
  • -d|--database - название БД (в бэкапе будут содержаться данные для всех сайтов, которые используют эту БД)
  • --enable|--disable - включение или отключение бэкапа для сайтов
  • --minute - параметры записи в crontab файле (минуты)
  • --hour - параметры записи в crontab файле (часы)
  • --day - параметры записи в crontab файле (день)
  • --month - параметры записи в crontab файле (месяц)
  • --weekday - параметры записи в crontab файле (день недели)

В случае успешного выполнения утилита вернет новые опции для сайта:

/opt/webdir/bin/bx-sites -a backup -d sitemanager0 --enable --minute=10 --hour=23 --day=1 --month=any --weekday=any -o json | python -mjson.tool  
...
            "BackupCronFile": "/etc/crontab",
            "BackupDay": "1",
            "BackupFolder": "/home/bitrix/backup/archive",
            "BackupHour": "23",
            "BackupMinute": "10",
            "BackupMonth": "*",
            "BackupTask": "enable",
            "BackupVersion": "v5",
            "BackupWeekDay": "*", 
...


Списки
исключений

Ряд файлов/каталогов необходимо исключить из резервной копии. Список таких исключений можно найти в файле /opt/webdir/bin/ex.txt.

По умолчанию, в нем находятся следующие подкаталоги:

bitrix/cache
bitrix/managed_cache
bitrix/stack_cache
bitrix/local_cache
bitrix/backup
bitrix/tmp
upload/tmp
upload/resize_cache


Содержимое бэкапа/
восстановление

Как уже сказано выше, в бэкап включается:

  • сам каталог сайта ядра (kernel или ext_kernel);
  • файл dump БД (/home/bitrix/mysql_dump_<db>.sql);
  • каталоги сайтов (link), которые используют ядро.

Например команда:

/opt/webdir/bin/bx_backup.sh sitemanager /home/bitrix/backup/archive

создает в директории /home/bitrix/backup/archive/ архив www_backup_<DBName>_DD.MM.YYYY_<random_string>.tar.gz, например www_backup_sitemanager_09.03.2023_zJ34ogIj.tar.gz:

Для восстановления нужно распаковать бэкап в DocumentRoot ядра. В примере рассмотрим директорию для сайта по умолчанию /home/bitrix/www:

tar -xvzf /home/bitrix/backup/archive/www_backup_sitemanager_09.03.2023_zJ34ogIj.tar.gz -C /home/bitrix/www/

После чего нужно восстановить БД:

mysql sitemanager < /home/bitrix/www/home/bitrix/mysql_dump_sitemanager_09.03.2023_zJ34ogIj_after_connect.sql

Аналогичной командой нужно восстановить другой файл с бекапом базы данных сайта:

mysql sitemanager < /home/bitrix/www/home/bitrix/mysql_dump_sitemanager_09.03.2023_zJ34ogIj.sql

Затем восстановите данные дополнительных сайтов типа link, если они есть:

rsync -av /home/bitrix/www/home/bitrix/ext_www/<site_name> /home/bitrix/ext_www/

Далее удалите дамп базы данных и бэкапы дополнительных сайтов в целях безопасности.

rm -fr /home/bitrix/www/home/bitrix/*

Восстановление на другой сервер

Если копия восстанавливается на другом сервере, то сначала нужно создать восстанавливаемые сайты в меню VMBitrix. Также пароль от БД в архиве не подойдет к БД нового сервера, так как пароли генерируются случайным образом после установки новой виртуальной машины. То есть после восстановления нужно сменить пароль пользователя базы данных. Эти данные можно взять в секции connections файла /bitrix/.settings.php после распаковки архива бэкапа (для сайта по умолчанию пользователь базы данных – bitrix0).

Сменить пароль можно SQL запросом в консоли mysql:

SET PASSWORD FOR 'bitrix0'@'localhost' = PASSWORD('new_pass');

Затем восстановить дампы базы данных и бэкапы дополнительных сайтов.

Аналогичные действия нужно провести, если в качестве DocumentRoot для сайтов использовалась директория /home/bitrix/ext_www.

Примечание: Не забывайте следить за свободным местом на диске и периодически удалять старые резервные копии.





7. Настройка NTLM-авторизации на всех сайтах (7. Configure NTLM auth for all sites)

Настройка NTLM-авторизации...

Внимание! Для поддержки механизма NTLM-авторизации продуктами «1С-Битрикс: Управление сайтом» и «Битрикс24 в коробке» необходим модуль AD/LDAP интеграция версии 11.5.0 и выше.

После включения и настройки механизм начинает работать следующим образом:

  • неавторизованный посетитель приходит на проект, где обработчиком события он перенаправляется на открытый порт Apache (8890 для http или 8891 для https);
  • Apache выполняет NTLM-авторизацию пользователя и пользователь перенаправляется назад на 80 или 443 порт (для http и https соответственно);
  • следующие переходы по сайту пользователь выполняет в обычном режиме.

Более подробно ознакомиться с работой механизма можно в уроке NTLM-авторизация в стороннем окружении курса Администратор. Базовый.

Рассмотрим настройку NTLM-авторизации на примере:

пользователей в
«Битрикс24 в коробке»

  • Во время установки, в мастере выбираем Разрешить пользователям Active Directory авторизовываться на портале:

  • Далее вводим настройки подключения к домену AD, проверяем соединение:

  • Указываем соответствия групп в AD группам корпоративного портала:

  • После завершения установки в административном разделе портала открываем страницу Active Directory / LDAP серверы (Настройки > AD/LDAP):

  • редактируем параметры сервера Active Directory, указывая домен для NTLM авторизации:

  • После этого заходим в настройки модуля AD/LDAP и устанавливаем Использовать NTLM авторизацию:

Продукт «1С-Битрикс» готов к использованию NTLM-авторизации, осталось настроить виртуальную машину.


Внимание! Если необходимо для локальной сети компании настроить NTLM-авторизацию, а для сотрудников, работающих с порталом, использовать стандартную авторизацию, то дополнительно в настройках модуля AD/LDAP нужно указать диапазон IP-адресов, для которых необходима NTLM-авторизация - Ограничить NTLM переадресацию следующей подсетью (например, 192.168.0.1/24):



пользователей в
«1С-Битрикс: Виртуальная машина»

Для настройки виртуальной машины необходимо подключитьcя к ней под пользователем root, выбрать пункт меню 6. Configure pool sites > 7. Configure NTLM auth for all sites и ввести необходимые данные:

После подтверждения корректности введенных данных мастер настроит и запустит все необходимые службы, а также подключит виртуальную машину в домен.

Примечание: Проверить, что компьютер успешно введен в домен можно командой:
net ads testjoin

Настройка завершена, для успешной NTLM-авторизации осталось проверить настройки браузеров.



в браузерах

  • Internet Explorer

    Для успешной работы механизма нужно, чтобы веб-сервер находился в зоне Local Intranet (при необходимости нужно добавить):

  • Mozilla Firefox:

    Добавить веб-сервер к списку доверенных URI для автоматической NTLM-авторизации (через параметр network.automatic-ntlm-auth.trusted-uris на странице Firefox: about:config)

Примечание: Действия по включению NTLM-авторизации на уже установленном продукте «Битрикс24 в коробке», а также в «1С-Битрикс: Управление сайтом» аналогичны перечисленным выше, за исключением того, что сервер Active Directory добавляется вручную в административном разделе.



8. Настройка xmppd|smtpd сервисов для сайта (8. Configure optional services (xmppd|smtpd) for site)

Мастер позволяет управлять работой сервисов XMPP и SMTP с помощью Cron. Это может понадобится, если необходимо рассылать jabber- и почтовые сообщения в случае, если на сайте нет активности, т.е если все события на сайте работают на хитах.


Для управления необходимо:

  • Из административного меню запустить мастер 6. Configure pool sites > 8 Configure optional services (xmppd|smtpd) for site:

  • Далее указать:
    • Enter site-name - имя сайта;
    • Enter service name - имя сервиса xmppd или smtpd.
  • И согласиться на активацию работы сервисов через Cron:

  • После завершения данной задачи jabber-уведомления и почтовые сообщения будут отправляться по cron-расписанию, независимо от активности на сайте.

Аналогичным образом отключается данные опции:


Внимание! Задачи могут выполняться довольно длительное время (до 2-3 часов и более) в зависимости от сложности задачи, объема данных, используемых в этих задачах, мощности и загруженности сервера. Проверить текущие выполняемые задачи можно с помощью меню 10. Background pool tasks > 1. View running tasks. Если по каким-либо причинам нужно посмотреть лог-файлы выполнения задач, то они находятся в директории /opt/webdir/temp.



9. Настройка nginx для работы с композитом (9. Configure nginx for composite)

Внимание! Настройки в виртуальной машине BitrixVM должны производиться после осуществления настроек Композитного сайта в Административном разделе. Если такие настройки выполнены в колонке Composite должно стоять Y.

Конфигурации NGINX
для работы с композитом

Примечание: Если сайтов несколько, то для каждого сайта, для которого включается Композитный сайт, нужно осуществить настройки, описанные ниже.

Управление настройками композитного кеша для NGINX находятся в меню виртуальной машины: 6. Configure pool sites > 9. Configure nginx for composite:

Эта настройка выполняет следующие действия:

  1. По настройкам, заданным в форме Композитный сайт в Административном разделе, создает конфигурационный файл условий работы композита, персональных для сайта в каталоге /etc/nginx/bx/maps. Например, включен или выключен композит для https-запросов.
  2. Обновляет настройки сайта, добавляет:
    • проверку условий - глобальных (общих для всех сайтов) и персональных,
    • выбранного для композита хранилища (files, memcached), если все условия выполняются.


Включение и обновление
настроек NGINX для композита

Для включения или обновления настроек:

  1. Укажите имя сайта.
  2. Подтвердите выбор, запустится фоновое задание, которое выполнит все настройки описанные в предыдущих пунктах.

Примечание. Также можно воспользоваться утилитой командной строки bx-sites (не забудьте указать нужный сайт вместо default в примере).
/opt/webdir/bin/bx-sites -o json -a composite --enable --site=default



Выключение настроек NGINX
по работе с композитом

Для отключения настроек:

  1. Укажите имя сайта.
  2. Откажитесь от обновления существующих настроек.
  3. Подтвердите отключение настроек Композита, запустится фоновое задание, которое вернет настройки сайта к значениям по умолчанию.

Примечание Так же можно воспользоваться утилитой командной строки bx-sites. (Не забудьте указать нужный сайт вместо default в примере.)
/opt/webdir/bin/bx-sites -o json -a composite --disable --site=default



Внимание! Задачи могут выполняться довольно длительное время (до 2-3 часов и более) в зависимости от сложности задачи, объема данных, используемых в этих задачах, мощности и загруженности сервера. Проверить текущие выполняемые задачи можно с помощью меню 10. Background pool tasks > 1. View running tasks. Если по каким-либо причинам нужно посмотреть лог-файлы выполнения задач, то они находятся в директории /opt/webdir/temp.




PHP или NGINX?

После завершения настроек NGINX возникает вопрос: как проверить, через что отдаются страницы - через PHP или NGINX при использовании BitrixVM? Для такой проверки просмотрите заголовки ответа сервера.

Заголовки при использовании Композита в BitrixVM могут быть такие:

  • X-Bitrix-Composite:Nginx (file) - отдача страниц - NGINX, хранение - файлы;
  • X-Bitrix-Composite:Nginx (memcached) - отдача страниц - NGINX, хранение - memcached;
  • X-Bitrix-Composite:Cache (200) - отдача страниц - PHP, хранение - файлы.


Условия работы композитного кеша

Примечание: Указанные в этом уроке настройки производить не нужно. Здесь дано описание того, что происходит при включении настроек NGINX на технологию Композитный сайт в BitrixVM только для ознакомления.

Условия разделены на две группы:

Глобальные условия

Настройки определяются в файле: /etc/nginx/bx/maps/composite_settings.conf. NGINX не использует технологию Композитный сайт, если соблюдается хотя бы одно условие:

  1. есть заголовок BX_ACTION_TYPE,
  2. есть заголовок BX_AJAX,
  3. это не GET-запрос,
  4. в query_string есть параметр ncc,
  5. в query_string есть параметр bxajaxid,
  6. в query_string есть параметр sessid,
  7. запрос сделан из IE ранее 10 версии,
  8. запрос по адресу /bitrix/,
  9. запрос по адресу /index_controller.php,
  10. есть кука NCC,
  11. есть куки LOGIN, UIDH и при этом нет куки CC.

Определение условий сделано через http_ngx_map_module:

  • По каждому из условий создано свое отображение. Например, в случае если переменная $http_bx_action_type содержит данные, то композитный ключ $not_bx_action_type будет содержать 0.
    map $http_bx_action_type $not_bx_action_type {
      default "0";
      ''      "1";
    }
  • Все условия используются для финальной проверки:
    # test all global conditions
    map "${not_bx_action_type}${not_bx_ajax}${is_get}${non_arg_ncc}${non_arg_bxajaxid}${non_arg_sessid}${is_modern}${is_good_uri}${non_cookie_ncc}${is_storedAuth}" $is_global_composite {
      default     "1";
      ~0          "0";
    } 

    Если хоть одно из условий содержало 0, то итоговое значение переменной $is_global_composite будет равно 0.



Персональные условия для сайта

Персональные проверки NGINX для сайта, определяются в момент включения или обновления композита из консольного меню. Для таких настроек создается и обновляется файл в каталоге: /etc/nginx/bx/maps/. Имя файла имеет специальный формат: <ID>.cache_<SITE_NAME>.conf, где:

  • ID - уникальный идентификатор сайта для кеша (инкрементное значение от 1),
  • SITE_NAME - имя сайта в системе (example.org).

NGINX не будет использовать композитный кеш, если выполняется хотя бы одно из условий:

  1. в query_string есть параметр из конфига (ключ ~EXCLUDE_PARAMS в .config.php),
  2. запрос по протоколу HTTPS (по галочке в настройках),
  3. запрос на домен, не указанный в списке доменов (ключ DOMAINS в .config.php),
  4. запрос по адресу, не указанному в "маске включения" ( ключ ~INCLUDE_MASK в .config.php),
  5. запрос по адресу, указанному в списке "маска исключений" ( ключ ~EXCLUDE_MASK в .config.php).

Определение условий сделано через http_ngx_map_module:

  • По каждому из условий, найденных в .config.php, создается свое отображение. Например, если задано условие INCLUDE_MASK для запроса, будет создана следующая структура:
    # test include uri for site
    map $uri $is_include_uri_02 {
      default  "0";
      "~*^.*?\.php$"  "1";
      "~*^.*?/$"  "1";
    
    }

    Если переменная $uri содержит одно из следующих регулярных выражений, то $is_include_uri_02 будет содержать 1, в остальных случая переменная будет равна 0.

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

  • Все найденные условия, используются для финальной проверки:
    # variable $is_site_composite_02 used in site config
    map "${config_domain_02}${is_include_uri_02}${not_exclude_uri_02}${not_https_schema_02}" $is_site_composite_02 {
      default   "1";
      ~0        "0";
    }
    Если хоть одна из переменных получит значение 0, переменная $is_site_composite_02 будет содержать 0, в остальных случаях 1.


Ключ поиска в композите

Ключ - это файл, который NGINX будет искать в композитном кеше (ключ для memcached хранилища, файл в случае хранения на файлах). Он нужен для того, чтобы привести запрос на сайт (uri) к универсальному виду.

Данный ключ определяется в глобальных настройках в файле /etc/nginx/bx/maps/composite_settings.conf. Так же, как для условий, используется модуль nginx ngx_map_module:

map $uri $composite_key {
  default                         $uri;
  ~^(?P.+)/$           $non_slash;
  ~^(?P.+)/index.php$  $non_index;
  ~^(?P.+)/index.html$ $non_index;
}

Действуют следующие правила:

  • Если запрос заканчивается на слеш, то вырезается финальный слеш из запроса.
  • Если запрос содержит index.php или index.html, то они вырезаются из запроса.


Конфигурационный файл сайта

Проверки для включения технологии на стороне NGINX используются в конфигурационном файле сайта, который в виртуальном окружении находится в каталоге /etc/nginx/bx/site_enabled. В случае стандартной конфигурации, файл обычно содержит следующие настройки:

    # Include parameters common to all websites
    include bx/conf/bitrix.conf;

При включенной технологии Композитный сайт, настройки зависят от выбранного хранилища.

Указанные в этом подразделе настройки производить не нужно. Здесь для ознакомления дано описание того, что происходит при включении настроек NGINX на технологию Композитный сайт в BitrixVM.

Хранение в файлах

  1. В файле /bitrix/html_pages/.config.php опция STORAGE содержит значение files.
  2. В конфигурационном файле сайта, который в виртуальном окружении находится в каталоге /etc/nginx/bx/site_enabled, должно быть прописано:
      # определяем ключ композита и файл на диске
      set $composite_cache    "bitrix/html_pages/${host}${composite_key}/index@${args}.html";
      set $composite_file     "${docroot}/${composite_cache}";
    
      # файл, который определяет включен ли композит на сайте или нет
      set $composite_enabled  "${docroot}/bitrix/html_pages/.enabled";
       
      # переменная, которая используется для композитной проверки
      set $use_composite_cache "";
      # если переменная глобальных условий содержит 1, добавляем признак в  use_composite_cache
      if ($is_global_composite  = 1) {set $use_composite_cache "A";}
      # если переменная персональных условий сайта содержит 1, добавляем признак use_composite_cache
      if ($is_site_composite_02 = 1) {set $use_composite_cache "${use_composite_cache}B";}
    
      # Подключаем конфиг, который содержит наши стандартные настройки, без  location по умолчанию
      include bx/conf/bitrix_general.conf;
    
      # Основной location
      location / {
     
        # если файл включения композита существует, добавляем признак в use_composite_cache
        if (-f $composite_enabled)     { set $use_composite_cache "${use_composite_cache}C"; }
    
        # если файл кеша существует, добавляем признак в use_composite_cache
        if (-f $composite_file)  { set $use_composite_cache "${use_composite_cache}D"; }
     
        # если все четыре условия выполняются, отправляем запрос в location c кешем
        if ($use_composite_cache = "ABCD") { rewrite .* /$composite_cache last; } 
    	 
         # по дефолту отправляем в apache
        proxy_pass $proxyserver;
      }


Хранение в memcached

  1. В файле /bitrix/html_pages/.config.php опция STORAGE содержит значение memcached или memcached_cluster.

  2. В конфигурационном файле сайта, который в виртуальном окружении находится в каталоге /etc/nginx/bx/site_enabled, должно быть прописано:
    # устанавливаем параметры подключения для memcached 
      memcached_connect_timeout 1s;
      memcached_read_timeout 1s;
      memcached_send_timeout 1s;
      memcached_gzip_flag 65536; 
      # ключ поиска
      set $memcached_key "/${host}${composite_key}/index@${args}.html";
    
      # включен ли композитный кеш
      set $composite_enabled  "${docroot}/bitrix/html_pages/.enabled";
      # переменная, которая используется для проверки работы с композитом при запросе пользователя
      set $use_composite_cache "";
      # учитываем глобальные условия
      if ($is_global_composite  = 1) {set $use_composite_cache "A";}
      # учитываем персональные условия
      if ($is_site_composite_02 = 1) {set $use_composite_cache "${use_composite_cache}B";}
    
      # подключаем общие параметры для bitrix окружения, без использования  default location
      include bx/conf/bitrix_general.conf;
    
      # основной location
      location / { 
         # если данные не найдены в кеше проксируем запрос на apache
        error_page 404 405 412 502 504 = @apache;
     
        # учитываем наличие .enabled файла
        if (-f $composite_enabled)     { set $use_composite_cache "${use_composite_cache}C"; }
    
        default_type text/html;
        # если все совпало, отправляем запрос в memcached
        if ($use_composite_cache = "ABC") {
          add_header X-Bitrix-Composite "Nginx (memcached)";
          memcached_pass localhost:11211;
        }
        proxy_pass $proxyserver;
      }
    
      location @apache {
        proxy_pass $proxyserver;
      }


PHP или NGINX?

После завершения настроек NGINX возникает вопрос: как проверить, через что отдаются страницы - через PHP или NGINX при использовании BitrixVM? Для такой проверки просмотрите заголовки ответа сервера.

Заголовки при использовании Композита в BitrixVM могут быть такие:

  • X-Bitrix-Composite:Nginx (file) - отдача страниц - NGINX, хранение - файлы;
  • X-Bitrix-Composite:Nginx (memcached) - отдача страниц - NGINX, хранение - memcached;
  • X-Bitrix-Composite:Cache (200) - отдача страниц - PHP, хранение - файлы.


10. Настроить опции сайта (10. Configure site options)

1. Настроить параметр proxy_ignore_client_abort (1. Configure proxy_ignore_client_abort for site)

Внимание! Включение глобально параметра nginx proxy_ignore_client_abort нужно делать в крайних случаях, обычно это делать не требуется. Лучше это делать вручную и для конкретных location, а не глобально на весь сервер. В следующих версиях BitrixVM/BitrixEnv этот пункт меню будет переработан.

Включение параметра nginx proxy_ignore_client_abort может быть полезным при неполадках в работе Телефонии, Открытых линиях. Данный параметр определяет, закрывать ли соединение с проксированным сервером в случае, если клиент закрыл соединение, не дождавшись ответа.

Для управления необходимо:

  • Из меню запустить мастер 10. Configure site options > 1. Configure proxy_ignore_client_abort for site, ввести имя сайта и согласиться на включение параметра proxy_ignore_client_abort:

  • Дождаться завершения данной задачи.

Аналогичным образом отключается данный параметр:


Внимание! Задачи могут выполняться довольно длительное время (до 2-3 часов и более) в зависимости от сложности задачи, объема данных, используемых в этих задачах, мощности и загруженности сервера. Проверить текущие выполняемые задачи можно с помощью меню 10. Background pool tasks > 1. View running tasks. Если по каким-либо причинам нужно посмотреть лог-файлы выполнения задач, то они находятся в директории /opt/webdir/temp.



11. Сайты с ошибками (11. Show sites with errors)

Если по каким-либо причинам на сайтах появились серьезные ошибки: отсутствие модулей на сайте или нет подключения к БД (не получается подключиться с данными настроек сайта), то в меню виртуальной машины появляется пункт меню 6. Manage sites in the pool > 11. Show sites with errors:

Выбрав этот пункт меню, отобразится список сайтов с кратким описанием ошибки (в данном примере - нет соединения с базой данных mysql):


Примечание: Пункт меню 6. Configure pool sites > 11. Show sites with errors является скрытым и появляется только тогда, когда есть ошибки на сайтах под управлением виртуальной машиной BitrixVM или linux-окружением BitrixEnv. Как только ошибки будут исправлены, данный пункт снова скроется.



7. Управление Sphinx (7. Configure Sphinx service for the pool)

Использование Sphinx в качестве поискового механизма позволит значительно увеличить скорость поиска и снизит нагрузку на сервер.



1. Создать инстанс sphinx на сервере (1. Create sphinx instance on server)

Для установки Sphinx на сервер необходимо:

  • Установить и обновить проект до последней актуальной версии;
  • В меню виртуальной машины выбрать пункт 7. Configure Sphinx service for the pool > 1. Create sphinx instance on server:

  • Далее ввести имя хоста, где будет запущен сервер поиска (в данном примере server1):

  • Выбрать базу данных ядра системы сайта из списка:

  • Дать согласие на запуск полной переиндексации после установки сервера:

  • Подождать, пока задача по установке и переиндексации будет закончена:


Внимание! Задачи могут выполняться довольно длительное время (до 2-3 часов и более) в зависимости от сложности задачи, объема данных, используемых в этих задачах, мощности и загруженности сервера. Проверить текущие выполняемые задачи можно с помощью меню 10. Background pool tasks > 1. View running tasks. Если по каким-либо причинам нужно посмотреть лог-файлы выполнения задач, то они находятся в директории /opt/webdir/temp.


Примечание: Ручная настройка поискового механизма Sphinx описана в данном уроке.



2. Обновить настройки sphinx (создать индекс) (2. Update sphinx instance on server (add index))

Чтобы обновить настройки для всех Sphinx-инстансов, нужно перейти в главном меню 7. Configure Sphinx service for the pool > 2. Update sphinx instance on server (add index):

  • Примечание: Данный пункт меню появится только тогда, когда будет создан хотя бы один инстанс с помощью меню 7. Configure Sphinx service for the pool > 1. Create sphinx instance on server.

  • Далее ввести имя хоста, где будет запущен сервер поиска (в данном примере server1):

  • Выбрать базу данных ядра системы сайта из списка:

  • Дать согласие на запуск полной переиндексации после установки сервера:

  • Подождать, пока задача по установке и переиндексации будет закончена.

Эта опция запускает проверку текущей конфигурации одного или нескольких Sphinx-инстансов в пуле (если такие имеются) и запускает принудительную переиндексацию.



Внимание! Задачи могут выполняться довольно длительное время (до 2-3 часов и более) в зависимости от сложности задачи, объема данных, используемых в этих задачах, мощности и загруженности сервера. Проверить текущие выполняемые задачи можно с помощью меню 10. Background pool tasks > 1. View running tasks. Если по каким-либо причинам нужно посмотреть лог-файлы выполнения задач, то они находятся в директории /opt/webdir/temp.


Примечание: Ручная настройка поискового механизма Sphinx описана в данном уроке.



3. Удалить sphinx на сервере (3. Remove sphinx instance on server)

Для удаления Sphinx-инстанса с сервера необходимо:

  • Выбрать пункт меню 7. Manage sphinx in the pool > 3. Remove sphinx instance on server.

    Примечание: Данный пункт меню появится только тогда, когда будет создан хотя бы один инстанс с помощью меню 7. Configure Sphinx service for the pool > 1. Create sphinx instance on server.

  • Ввести имя хоста удаляемого Sphinx-инстанса (например server1):

  • Выбрать базу данных ядра системы сайта из списка:

  • Подождать, пока задача по удалению будет закончена.

Внимание! Задачи могут выполняться довольно длительное время (до 2-3 часов и более) в зависимости от сложности задачи, объема данных, используемых в этих задачах, мощности и загруженности сервера. Проверить текущие выполняемые задачи можно с помощью меню 10. Background pool tasks > 1. View running tasks. Если по каким-либо причинам нужно посмотреть лог-файлы выполнения задач, то они находятся в директории /opt/webdir/temp.



8. Управление веб-серверами (8. Manage pool web servers)

В «1C-Битрикс: Виртуальная машина» можно быстро развернуть кластеризацию веб-сервера в «1С-Битрикс: Управление сайтом» и «Битрикс24 в коробке».

При разделении проекта на несколько веб-серверов необходимо решить две задачи:

  • синхронизация данных (файлов) между серверами
  • балансировка нагрузки между серверами

Внимание! Перед тем как начинать использовать кластеризацию веб-сервера в BitrixVM/BitrixEnv нужно предварительно установить «1С-Битрикс: Управление сайтом» или в «Битрикс24 в коробке» с модулем Веб-кластер. Данный модуль входит только в старшие редакции продуктов «1С-Битрикс».



1. Создание веб-сервера (1. Create web role on server)

Для создания роли веб-сервера нужно:

  • Выбрать пункт меню 8. Manage pool web servers > 1. Create web role on server и ввести имя хоста в пуле, на котором будет создан веб-сервер (в данном примере - server3):

  • Выбрать вариант создания роли:
    1. one step - все действия по созданию web-роли будут произведены за 1 шаг. Данный вариант рекомендуется на простых проектах, где не так много данных.
    2. two steps - действия по созданию web-роли будут произведены за 2 шага для уменьшения ошибок в процессе создания роли. Данный вариант рекомендуется на крупных проектах, где очень много данных.

      Внимание! Если вы выбрали вариант two steps, после выполнения задачи 1-го шага нужно запустить 2-й шаг таким же образом на этом же сервере.

  • Подождать, пока задачи по созданию веб-сервера будут закончены. И мы увидим, что у нас 2 сервера с ролью web в пуле: server1 и server3:

  • Добавим еще одному серверу в пуле web-роль (server2) аналогичным способом. Мы видим, что у сервера с балансировщиком web-роль имеет тип main, а у дополнительных серверов пула - spare:


Внимание! Задачи могут выполняться довольно длительное время (до 2-3 часов и более) в зависимости от сложности задачи, объема данных, используемых в этих задачах, мощности и загруженности сервера. Проверить текущие выполняемые задачи можно с помощью меню 10. Background pool tasks > 1. View running tasks. Если по каким-либо причинам нужно посмотреть лог-файлы выполнения задач, то они находятся в директории /opt/webdir/temp.



2. Настроить модули PHP (2. Manage PHP extensions)

В разделе 8. Manage pool web servers > 2. Manage PHP extensions можно включить дополнительные модули PHP, которые могут понадобится в продуктах «1C-Битрикс».


На данный момент можно включить модуль SSH2 для PHP:

Выключается данный модуль аналогично:


Внимание! Задачи могут выполняться довольно длительное время (до 2-3 часов и более) в зависимости от сложности задачи, объема данных, используемых в этих задачах, мощности и загруженности сервера. Проверить текущие выполняемые задачи можно с помощью меню 10. Background pool tasks > 1. View running tasks. Если по каким-либо причинам нужно посмотреть лог-файлы выполнения задач, то они находятся в директории /opt/webdir/temp.



3. Настройка сертификатов (3. Configure certificates)

SSL-сертификат – это цифровая подпись сайта, она обеспечивает шифрованное соединение между посетителем сайта и сервером. Еще с его помощью подтверждается подлинность сайта – любой посетитель может проверить, действительно ли этот сайт принадлежит данной компании.

Начиная с версии BitrixVM 7.2.0, добавилась возможность подключения SSL-сертификатов как бесплатного Let's Encrypt, так и своего собственного, выпущенного любым авторизованным центром сертификации.

Центр сертификации Let’s Encrypt выдает SSL-сертификаты с проверкой домена (DV, Domain-validated certificate) бесплатно, срок их действия – 90 дней. Они начального уровня и подтверждают домен, а также шифруют и защищают данные при передаче с помощью протокола https. Установить его себе на сайт могут как физические лица, так и организации. Подойдут для небольших сайтов и маленьких проектов, когда нет необходимости в большом доверии со стороны клиентов и посетителей сайта. В BitrixVM SSL-сертификаты Let’s Encrypt выпускаются в течение нескольких минут, а продление производится автоматически, примерно за месяц до истечения срока действия.

SSL-сертификаты, предполагающие более высокое доверие к вашим продуктам, компании и сервисам, выпускают центры сертификации. При этом проводится более тщательная проверка:

  • SSL-сертификаты с проверкой компании (OV, Organization validation) – кроме защиты информации гарантируется принадлежность домена конкретной организации. Выдается только юридическим лицам с подтвержденным номером телефона. На сайте с таким сертификатом посетитель может найти информацию об организации-владельце сайта, обычно, просто щелкнув по иконке замочка.

  • SSL-сертификаты с расширенной проверкой (EV, Extended validation) – то же, что и OV, только проверяется уже налоговая и коммерческая деятельность компании, причем более тщательно. На сайте рядом с замочком появляется название компании. Чаще всего встречаются у банков и онлайн-систем с большим количеством посетителей.

Собственные SSL-сертификаты, выпущенные авторизованными центрами, нужно выпускать и продлевать самостоятельно. В BitrixVM их нужно подключать каждый раз, когда происходит их перевыпуск в центре сертификации.



1. Настройка сертификата Let's encrypt (1. Configure "Let's encrypt" certificate)


Важно! Прежде, чем выпускать сертификат Let’s Encrypt, убедитесь, что у вас создан сайт на тот хост (и он доступен из интернета), на который выпускается сертификат, а также указаны правильные DNS-настройки у регистратора или хостера DNS для этого домена. Иначе он не будет выпущен. Плюс к этому есть лимит – 5 ошибок в час выпуска сертификата на аккаунт для одного домена.

Для создания SSL-сертификата Let’s Encrypt нужно:

  • Перейти в меню 8. Manage pool web servers > 3. Configure certificates:

  • Выбрать пункт меню 1. Configure "Let's encrypt" certificate и ввести:
    • site name – имя сайта или несколько имен сайтов, для которых нужно выпустить сертификат(ы) Let's encrypt (в данном примере: test2.b24test.site)
    • dns name(s) – все домены данного сайта, для которых должен быть выпущен сертификат, включая домен с www и без, вводить несколько доменов через запятую
    • email for LE notifications – почтовый адрес для уведомлений сервиса Lets Encrypt

    и подтвердить ввод:

  • Мастер самостоятельно запросит и установит его в течение нескольких минут. Пути SSL-сертификатов будут указаны в этом же разделе:

  • Проверить выпущенный сертификат можно легко – перейти на ваш сайт по протоколу https, у валидного сертификата будет замочек:

Срок действия – 90 дней. Перевыпуск происходит автоматически за 20 дней до окончания срока действия.


Ручное обновление

С версии BitrixVM 7.4.0 проверка сертификатов автоматически производится еженедельно в субботу в 2 часа ночи по cron-у.

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

Также вы можете вручную командой:

/home/bitrix/dehydrated/dehydrated -c

Система проверит сроки действия и при необходимости запустит обновление.

Лог обновления можно посмотреть по пути: /home/bitrix/dehydrated_update.log.


Важно! У сервиса Lets Encrypt есть свои ограничения на выпуск сертификатов. Основные из них:
  • Выпуск 50 штук в неделю на домены (на зарегистрированные домены у регистратора, поддомены не входят в этот счет).
  • Если у вас много поддоменов, то можно все поддомены указать в одном сертификате, но здесь есть лимит в 100 поддоменов на одну штуку.
  • 5 ошибок в час выпуска сертификата на аккаунт для одного домена (не доступен хост, не прописаны записи в DNS домена и т.д).
  • Проверка HTTP-01 выполняется только с использованием порта 80. Если этот порт закрыт (провайдером, например), то сертификат не перевыпустится.

Подробнее о лимитах Let’s Encrypt читайте в статье Rate Limits.



2. Настройка собственного сертификата (2. Configure own certificate)

  Свой SSL-сертификат

Если у вас есть свой сертификат, выпущенный любым авторизованным центром, то можно также его подключить к сайту в BitrixVM.

Важно! Прежде, чем подключать его, убедитесь, что у вас создан сайт на тот хост (и он доступен из интернета), на который у вас выпущен сертификат, а также указаны правильные DNS-настройки у регистратора или хостера DNS для этого домена.

У вас должны быть следующие файлы: приватный ключ (private key), цепочка сертификатов (certificate chain) и сам сертификат (certificate).

Требования к импортируемым сертификатам:
  • Все перечисленные файлы должны быть в PEM-кодировке.
  • Приватный ключ не должен быть зашифрован.
  • Обязательны файлы сертификата и приватного ключа, файл с цепочкой можно не указывать.
  • Если вы используете свои пути для загрузки, то нужно указывать при импорте полные пути. Если хотите использовать относительные пути, то файлы сертификатов должны быть загружены в директорию /etc/nginx/certs.

  Подключение

Для подключения своего SSL-сертификата нужно:

  • Скопировать файлы сертификата в любую директорию на сервере с помощью любого клиента SFTP. В нашем примере мы создали директорию /home/bitrix/ssl/ и скопировали файлы в неё.

    Пути получились такие:

    1. приватный ключ/home/bitrix/ssl/test2.b24test.site_privkey.pem
    2. сам сертификат/home/bitrix/ssl/test2.b24test.site_cert.pem
    3. цепочка сертификатов/home/bitrix/ssl/test2.b24test.site_chain.pem

  • Далее перейти в меню 8. Manage pool web servers > 3. Configure certificates:

  • Выбрать пункт меню 2. Configure own certificate и ввести имя домена (Sitename) или несколько доменов, для которых нужно импортировать сертификат(ы) (в данном примере: test2.b24test.site), путь для приватного ключа (Private Key path), путь для сертификата (Certificate path), путь для цепочки сертификатов (Certificate Chain path) и подтвердить установку для этого домена:

  • Мастер самостоятельно установит сертификат. Пути будут указаны в этом же разделе:

  • Проверку результата можно выполнить легко – перейти на ваш сайт по протоколу https, у валидного сертификата будет зеленый замочек:

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

Примечание: Если вы использовали свою директорию сервера для копирования исходных файлов, то после импорта сертификата в целях безопасности эти файлы желательно удалить (в примере - /home/bitrix/ssl/). Если вы копировали файлы в /etc/nginx/certs, то удалять их не нужно.


3. Восстановление сертификата по умолчанию (3. Restore default certificate)

Если что-то пошло не так или вы хотите восстановить самоподписанный сертификат, который создается при первом запуске BitrixVM, то для этого нужно:

  • Перейти в меню 8. Manage pool web servers > 3. Configure certificates:

  • Выбрать пункт меню 3. Restore default certificate и ввести certificate file path – это путь к сертификату, который указан в таблице в поле Certificate (в данном примере: /home/bitrix/dehydrated/certs/test2.b24test.site/fullchain.pem) и подтвердить действие:

  • Мастер самостоятельно восстановит SSL-сертификат по умолчанию в /etc/nginx/ssl/cert.pem:



4. Удаление роли web c сервера (4. Remove web role from server)

Для удаления веб-сервера необходимо:

  • Выбрать пункт меню 8. Manage pool web servers > 4. Remove web role from server:

  • Ввести имя хоста сервера, у которого удаляется роль web (например server3):

    Внимание! Удалять web-роль можно только типа spare, тип main (сервер с балансировщиком) удалять нельзя.

  • Подождать, пока задача по удалению роли будет закончена.
  • В итоге из 3 веб-серверов только на двух останется web-роль (main - server1, spare - server2):


Внимание! Задачи могут выполняться довольно длительное время (до 2-3 часов и более) в зависимости от сложности задачи, объема данных, используемых в этих задачах, мощности и загруженности сервера. Проверить текущие выполняемые задачи можно с помощью меню 10. Background pool tasks > 1. View running tasks. Если по каким-либо причинам нужно посмотреть лог-файлы выполнения задач, то они находятся в директории /opt/webdir/temp.



9. Настроить сервис Push/RTC (9. Configure Push/RTC service for the pool)

Внимание! Данный пункт меню доступен в VMBitrix с версии 7.1.0.


Push-сервер (pulling-сервер, сервер мгновенных сообщений) предназначен для быстрого обмена сообщениями между пользователями, которые заходят на портал через браузер или подключаются с помощью настольного или мобильного приложений.


По умолчанию в VMBitrix для Push&Pull используется модуль Nginx-PushStreamModule. Главный его недостаток – если сервис падает по какой-либо причине, то недоставленные сообщения теряются, что порождает высокую нагрузку на PHP-бэкенд из-за особенностей работы модуля nginx. Новый модуль на NodeJS лишен этих недостатков.

По умолчанию в VMBitrix.CRM для Push&Pull сервера используется модуль на NodeJS.



1. Настроить NodeJS RTC сервис (1. Install/Update NodeJS RTC Service)

Модуль сервера очередей Nginx-PushStreamModule устарел и может работать нестабильно (зависание сообщений, падения). В результате чего сообщения могут не доставляться, это вызывает высокую нагрузку на службу PHP из-за особенностей работы модуля Nginx. Также он ограничен в функционале – в нем нет поддержки protobuf и персональных каналов, которые работают без сервера, нет возможности опроса публичного канала, чтобы узнать, кто в сети, и т.д.

Поэтому крайне рекомендуется использовать вместо устаревшего Nginx-PushStreamModule новый NodeJS-Pushserver.

Чтобы перейти на новый модуль NodeJS RTC вместо Nginx-PushStreamModule, нужно:

  1. В главном меню виртуальной машины выбрать пункт 9. Configure Push/RTC service for the pool > 1. Install/Update NodeJS RTC Service:

  2. Ввести имя хоста, где нужно запустить NodeJS RTC сервис (в примере мы выбрали server1 c запущенным сервисом NginxStreamModule), согласиться на смену модуля NginxStreamModule на NodeJS Push:

  3. Подождать, пока задачи по запуску NodeJS RTC Push&Pull сервера будут закончены:

Примечание В пуле может быть только один сервис Push&Pull. Если у вас запущен Push&Pull сервис на одном сервере, и вы выбираете в качестве сервера другую машину, то мастер остановит Push&Pull сервис на первой машине и запустит его на другой.


Внимание! Задачи могут выполняться довольно длительное время (до 2-3 часов и более) в зависимости от сложности задачи, объема данных, используемых в этих задачах, мощности и загруженности сервера. Проверить текущие выполняемые задачи можно с помощью меню 10. Background pool tasks > 1. View running tasks. Если по каким-либо причинам нужно посмотреть лог-файлы выполнения задач, то они находятся в директории /opt/webdir/temp.

Доп. материалы:



2. Удалить NodeJS RTC инстанс (2. Uninstall NodeJS RTC instance)

Чтобы перейти с NodeJS RTC обратно на модуль Nginx-PushStreamModule, нужно:

  1. В главном меню виртуальной машины выбрать пункт 9. Configure Push/RTC service for the pool > 2. Uninstall NodeJS RTC instance:

  2. Ввести имя хоста, где нужно перейти обратно на Nginx-PushStreamModule (в примере мы выбрали server1 c запущенным сервисом NodeJS RTC), согласиться на удаление NodeJS RTC:

  3. Подождать, пока задачи по запуску Nginx-PushStreamModule Push&Pull сервера будут закончены:


Внимание! Задачи могут выполняться довольно длительное время (до 2-3 часов и более) в зависимости от сложности задачи, объема данных, используемых в этих задачах, мощности и загруженности сервера. Проверить текущие выполняемые задачи можно с помощью меню 10. Background pool tasks > 1. View running tasks. Если по каким-либо причинам нужно посмотреть лог-файлы выполнения задач, то они находятся в директории /opt/webdir/temp.



10. Фоновые задачи (10. Background pool tasks)

  Посмотреть историю

Все изменения в виртуальной машине – настройки, запуск каких-либо служб, синхронизация и др. осуществляются с помощью скриптов – задач.

Просмотреть историю, а также выполняемые в данный момент задачи, можно с помощью пункта меню 10. Background pool tasks:

Просмотреть запущенную в данный момент задачу можно с помощью пункта меню 10. Background pool tasks > 1. View running tasks:

Для её остановки нужно перейти в пункт меню 10. Background pool tasks > 1. View running tasks > 1. Stop task и ввести идентификатор задачи:

Внимание! Задачи могут выполняться довольно длительное время (до 2-3 часов и более) в зависимости от сложности, объема данных, используемых в них, мощности и загруженности сервера.

  Очистить историю

Чтобы очистить историю нужно выбрать пункт меню 10. Background pool tasks > 2. Delete history:

Далее выбрать количество дней, за которое нужно оставить историю, и фильтр, по которому выбирать задачи (к примеру, выберем все задачи с TaskID common):

После этого будут выведены все задачи, удовлетворяющие заданному интервалу и фильтру, и далее запрос на очистку истории:

Внимание! Если по каким-либо причинам нужно посмотреть лог-файлы выполнения, то они находятся в директории /opt/webdir/temp.



11. Настроить сервис «Конвертер файлов» (11. Configure Transformer service)

Сервис Конвертер файлов выполняет преобразование документов и видео для просмотра в постах или комментариях ленты Новостей и Задач, в Диске, а также осуществляет генерацию документов по шаблонам в CRM.

Роль Конвертер файлов в VMBitrix доступна начиная с версии 7.5.0.


Для работы роли необходимо, чтобы в «1С-Битрикс24» были установлены модули:

  • «Конвертер файлов» (transformer) версии 20.100.0 и выше.
  • «Сервер конвертации файлов» (transformercontroller) версии 20.100.0 и выше.
Внимание! Модуль «Сервер конвертации файлов» (transformercontroller) доступен только в редакции «1С-Битрикс24: Энтерпрайз». Роли Конвертер файлов нет в меню VMBitrix.CRM в связи с недоступностью модуля «Сервер конвертации файлов» (transformercontroller) в редакции «1C-Битрикс24.CRM»


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

1. Настроить сервис «Конвертер файлов» (1. Configure Transformer service)


Ограничения роли:
  1. Требуется модуль «Сервер конвертации файлов» (transformercontroller), который доступен только в редакции «1С-Битрикс24: Энтерпрайз».
  2. Нельзя удалить сайт, если для него настроена роль – сначала нужно удалить её, потом уже можно удалить сайт.
  3. Вынос на отдельный сервер в пуле (кластере) не предусмотрен.
  4. Возможна установка только одной роли на машину.

Для настройки роли выполните следующие шаги:

  1. В главном меню виртуальной машины выберите пункт 11. Configure Transformer service – 1. Configure Transformer service:

  2. Введите имя сайта (в примере vm1.local):

  3. Перед запуском роли будет выдано оповещение об устанавливаемом ПО. После этого запустится задача configure_transformer_**********, которая:

    • установит пакеты erlang, rabbitmq, libreoffice6.4, ffmpeg и их связи;
    • настроит модули Конвертер файлов (transformer) и Сервер конвертации файлов (transformercontroller) для указанного сайта.

  4. После завершения задачи в указанных выше модулях будут прописаны все необходимые настройки:

  5. Далее убедитесь, что в Настройках Битрикс24 публичной части или в административном интерфейсе в настройках модуля Диск (Настройки – Настройки продукта – Настройки модулей – Диск) установлена опция Просматривать документы с помощью Битрикс24:

  6. Все готово.


Уроки по теме

Для дальнейшей эксплуатации могут понадобиться другие учебные материалы:


Внимание! Задачи могут выполняться довольно длительное время (до 2-3 часов и более) в зависимости от сложности задачи, объема данных, используемых в этих задачах, мощности и загруженности сервера. Проверить текущие выполняемые задачи можно с помощью меню 10. Background pool tasks > 1. View running tasks. Если по каким-либо причинам нужно посмотреть лог-файлы выполнения задач, то они находятся в директории /opt/webdir/temp.





2. Удалить сервис «Конвертер файлов» (2. Remove Transformer service)

Чтобы удалить роль Конвертер файлов, нужно:

  • В главном меню виртуальной машины выбрать пункт 11. Configure Transformer service – 2. Remove Transformer service:

  • Выбрать пункт 1. Remove Transformer service и согласиться на удаление роли:

  • Запустится задача, которая деактивирует запущенные раннее сервисы, удалит их данные и сбросит настройки модулей «Конвертер файлов» (transformer) и «Сервер конвертации файлов» (transformercontroller).

Внимание! Задачи могут выполняться довольно длительное время (до 2-3 часов и более) в зависимости от сложности задачи, объема данных, используемых в этих задачах, мощности и загруженности сервера. Проверить текущие выполняемые задачи можно с помощью меню 10. Background pool tasks > 1. View running tasks. Если по каким-либо причинам нужно посмотреть лог-файлы выполнения задач, то они находятся в директории /opt/webdir/temp.



Дополнительные настройки BitrixVM/BitrixEnv

Внимание!
  1. Для операций, описанных в главе, необходимы начальные знания администрирования. Перед началом проведения данных операций рекомендуется сделать полный бэкап «Виртуальной машины». Также некоторые настройки могут быть недокументированными разработчиком BitrixVM/BitrixEnv «лайфхаками», вы должны понимать, что делаете.
  2. Приведённые настройки сервера выходят за рамки меню Виртуальной машины. Это означает, что информация - ознакомительная и применять её следует с чётким пониманием того что вы делаете и с собственной ответственностью за совершаемые действия. В нашей техподдержке рассматриваются только вопросы по работе пунктов меню ВМ.



Изменение стандартных настроек BitrixVM без отключения автоподстройки

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

При запуске виртуальной машины BitrixVM или физического сервера с установленным пакетом BitrixEnv сервисом bvat автоматически настраиваются основные параметры Apache, PHP, MySQL и nginx в зависимости от количества доступной памяти. Это позволяет обеспечивать оптимальные настройки сервера.

Но в ряде случаев возникает необходимость изменения некоторых параметров без отключения сервиса bvat. Для внесения таких изменений в настройки сервера предусмотрены специальные конфигурационные файлы, позволяющие переопределять параметры, устанавливаемые сервисом bvat. Они имеют свое название и хранятся в директориях:

  • MySQL: /etc/mysql/conf.d/z_bx_custom.cnf

  • Apache: /etc/httpd/bx/custom/z_bx_custom.conf

  • nginx:
    • /etc/nginx/bx/site_ext_enabled/ - конфигурационные файлы своих дополнительных сайтов для всего сервера (например, bx_ext.conf, bx_ext_custom1.conf, ext_custom_site.com.conf и т.п)
    • /etc/nginx/bx/settings/ - конфигурационные файлы настроек для уровня http всего сервера (например, z_bx_custom.conf, z_bx_custom1.conf и т.п)
    • /etc/nginx/bx/site_settings/<SITE_NAME>/ - персональные настройки конкретного сайта, начиная с версии BitrixVM 7.5 или бета версии 7.4.10 (например, /etc/nginx/bx/site_settings/site.com/myconfig.conf).

    Конфигурационный файл nginx в этих директориях может быть как один общий, так несколько. Имя файла не имеет значения, главное, чтобы в них были неконфликтующие настройки.
  • PHP: /etc/php.d/z_bx_custom.ini

В случае, если в этих директориях нет конфигурационных файлов, то их можно создать самостоятельно.

Внимание! Все изменения стандартных конфигурационных файлов Apache, PHP, MySQL и nginx могут быть утрачены во время обновления виртуальной машины BitrixVM/BitrixEnv. Чтобы этого не произошло, все переопределяемые параметры должны быть только в файлах типа z_bx_custom.*, указанных выше для каждого сервиса.

Для вступления переопределяемых параметров в силу нужно перезапустить соответствующие службы: MySQL, Apache или nginx.

Пример изменения параметров в файле z_bx_custom.cnf



Увеличение дискового пространства BitrixVM

Внимание!
  1. Для операций, описанных в данной главе, необходимы знания администрирования *nix-систем. Перед началом проведения данных операций рекомендуется сделать полный бекап «Виртуальной машины».
  2. Приведённые настройки выходят за рамки меню Виртуальной машины. Это означает, что информация - ознакомительная и применять её следует с чётким пониманием того что вы делаете и с собственной ответственностью за совершаемые действия. В нашей техподдержке рассматриваются только вопросы по работе пунктов меню ВМ.

При использование виртуальной машины BitrixVM или ami-образа BitrixVM, со временем может возникнуть проблема нехватки свободного места.

Решить эту проблему можно двумя способами:

  1. добавить в виртуальную машину еще один жесткий диск, смонтировать его в системе и перенести на него часть контента (наиболее оптимальный способ);
  2. увеличить размер существующего виртуального жесткого диска.


Добавление дополнительного жесткого диска BitrixVM

Внимание!
  1. Для операций, описанных в данной главе, необходимы знания администрирования *nix-систем. Перед началом проведения данных операций рекомендуется сделать полный бекап «Виртуальной машины».
  2. Приведённые настройки выходят за рамки меню Виртуальной машины. Это означает, что информация - ознакомительная и применять её следует с чётким пониманием того что вы делаете и с собственной ответственностью за совершаемые действия. В нашей техподдержке рассматриваются только вопросы по работе пунктов меню ВМ.

Так как основной объем дискового пространства потребляется контентом сайтов и их резервными копиями, расположенными в /home/bitrix, а также БД, расположенной в /var/lib/mysql, то на отдельные диски следует выносить именно эти разделы.

Рассмотрим данную задачу на примере переноса на отдельный диск папки /home с контентом сайтов и их резервными копиями.

  • Для этого в настройках виртуальной машины в список оборудования, добавляем новый диск необходимого размера. Все указанные ниже действия необходимо осуществлять под учетной записью администратора root:

  • После добавления диска, для его инициализации, возможно, потребуется перезагрузить сервер. Увидеть новый диск и присвоенное ему буквенное обозначение можно, выполнив команду:
    fdisk -l

  • Запускаем утилиту fdisk для работы с диском /dev/sdb:
    fdisk /dev/sdb

    И командой n создаем новый раздел:

    • основной (primary partition) - команда p и Partition number (1-4): 1;
    • первый и последний сектора при этом выбираем по умолчанию - таким образом, будет создан раздел, используя все свободное пространство на диске:

  • Для сохранения изменений на диск и выхода из fdisk введите команду w.

  • После сохранения таблицы разделов, форматируем новый раздел и переносим на него информацию из /home:

    CentOS 6
    mkfs.ext4 /dev/sdb1 
    mount /dev/sdb1 /mnt 
    service httpd stop 
    service nginx stop
    mv -f /home/* /mnt 
    umount /mnt
    
    CentOS 7
    mkfs.ext4 /dev/sdb1 
    mount /dev/sdb1 /mnt 
    systemctl stop httpd.service
    systemctl stop nginx.service
    mv -f /home/* /mnt 
    umount /mnt
    
  • Следующим шагом определяем UUID нового диска:
    blkid
    /dev/sda1: UUID="99066558-ba04-465c-9962-e827aa2928ec" TYPE="ext4" 
    /dev/sda2: UUID="8ea38ef9-1ee5-423b-a013-15fd603a678e" TYPE="swap" 
    /dev/sda3: UUID="08ec5c65-8fd8-47ac-a998-d81195c8f964" TYPE="ext4" 
    /dev/sdb1: UUID="b2e58731-b621-4bd5-909a-afe3bb5dd8a1" TYPE="ext4"
    

    и добавляем запись (в данном примере: UUID=b2e58731-b621-4bd5-909a-afe3bb5dd8a1) о нем в /etc/fstab (вместо UUID можно также использовать имя устройства /dev/sdb):

  • Остается только примонтировать новый диск и запустить остановленные ранее службы:

    CentOS 6
    mount /home 
    service httpd start 
    service nginx start 
    
    CentOS 7
    mount /home 
    systemctl start httpd.service
    systemctl start nginx.service
    

Добавление дисков в других средах виртуализации или непосредственно на физическом сервере проходит аналогично.


Внимание! Если создаете на новом диске директорию /home/bitrix/www вручную, то убедитесь, чтобы она имела права bitrix:bitrix - 755 для директории и 644 - для файлов.


Увеличение размера существующего жесткого диска BitrixVM

Внимание!
  1. Для операций, описанных в данной главе, необходимы знания администрирования *nix-систем. Перед началом проведения данных операций рекомендуется сделать полный бекап «Виртуальной машины».
  2. Приведённые настройки выходят за рамки меню Виртуальной машины. Это означает, что информация - ознакомительная и применять её следует с чётким пониманием того что вы делаете и с собственной ответственностью за совершаемые действия. В нашей техподдержке рассматриваются только вопросы по работе пунктов меню ВМ.

Вторым способом увеличения дискового пространства в BitrixVM является увеличение размера уже существующего жесткого диска виртуальной машины.

  1. Сначала измените размер системного диска на требуемый, например до 100Гб:

    Изменить размер системного диска в VMWare

    Изменить размер системного диска в VirtualBox
  2. Далее необходимо запустить виртуальную машину BitrixVM, авторизоваться под root и перейти в режим командной строки (консоль), выбрав пункт меню 0. Exit в виртуальной машине.

  3. Смотрим диск и присвоенное ему буквенное обозначение консольной командой:
    fdisk -c -u -l

    где для диска /dev/sda:

    • sda1 - загрузочный сектор диска;
    • sda2 - файл подкачки (swap);
    • sda3 - раздел, в котором установлена операционная система и который как раз и нужно увеличить.


  4. Запускаем утилиту fdisk для работы с диском /dev/sda:
    fdisk -c -u /dev/sda
  5. Командой d удаляем раздел sda3, выбрав Partition number (1-4): 3:

    Внимание! Данные с диска при этом никуда не удаляются, в данном случае удаляется лишь запись о разделе из таблицы разделов диска.

  6. Далее командой n создаем новый раздел:
    • основной (primary partition) - команда p и Partition number (1-4): 3;
    • первый и последний сектора при этом выбираем по умолчанию - таким образом, будет создан раздел, используя все свободное пространство на диске.

  7. Для сохранения обновленной таблицы разделов и выхода из fdisk введите команду w:

  8. Чтобы система подгрузила новую таблицу разделов, необходима перезагрузка виртуальной машины:
    reboot
  9. После перезагрузки с помощью утилиты resize2fs увеличиваем размер файловой системы раздела /dev/sda3:
    resize2fs /dev/sda3

Проверить, что раздел увеличен можно с помощью команды df:

Изменение размера дисков в других средах виртуализации проходит аналогично.



Увеличение размера LVM-раздела BitrixEnv

Внимание!
  1. Для операций, описанных в данной главе, необходимы знания администрирования *nix-систем. Перед началом проведения данных операций рекомендуется сделать полный бекап «Виртуальной машины».
  2. Приведённые настройки выходят за рамки меню Виртуальной машины. Это означает, что информация – ознакомительная и применять её следует с чётким пониманием того что вы делаете и с собственной ответственностью за совершаемые действия. В нашей техподдержке рассматриваются только вопросы по работе пунктов меню ВМ.
  3. При автоматической разбивке диска на этапе установки системы CentOS 7, например в случае будущего развертывания VMBitrix c помощью скрипта bitrix_env.sh на готовый CentOS 7, устанавливается менеджер логических томов LVM2. В таком случае изменение размера LVM-раздела будет отличаться от предыдущих способов.


Пусть размер системного диска был увеличен с 20 ГБ до 100Гб, как было сделано ранее в VMWare или VirtualBox (пункт 1).

Тогда действия по изменению размера LVM-раздела будут такими:

  1. Смотрим, что в системе на данный момент есть из устройств/разделов командой:
    fdisk -l

  2. Убеждаемся, что место в системе автоматически не увеличилось при помощи команды:
    df -h

    Здесь мы также видим и запоминаем имя группы томов и имя тома – centos_vb1-root (у вас они будут другие):

    • centos_vb1 – имя группы томов;
    • root – имя тома.

  3. Создаем новый раздел sda3 – тип раздела: Linux LVM (код типа 8e) на неразмеченной области. Для этого начинаем работу с устройством sda c помощью команды:
    fdisk /dev/sda
  4. Далее командой n создаем новый раздел:
    • основной (primary partition) – команда p и Partition number (1-3, default 3): 3 (так как у нас было 2 логических раздела sda1 и sda2 – см. п.1);
    • первый и последний сектора при этом выбираем по умолчанию – нажмите Enter, таким образом, будет создан раздел, используя все свободное пространство на диске;
    • укажем тип раздела – команда t и Partition number (1-3, default 3): 3;
    • вводим код типа раздела, соответствующий Linux LVM – 8e;
    • смотрим таблицу разделов – команда p и убеждаемся, что все верно;
    • Раздел sda3 создан. Для сохранения обновленной таблицы разделов и выхода из fdisk – команда w.

  5. Чтобы система подгрузила новую таблицу разделов, необходима перезагрузка виртуальной машины:
    reboot
  6. После перезагрузки необходимо создать физический том sda3:
    pvcreate /dev/sda3
  7. Далее расширяем группу томов на новое пространство, используя имя группы томов centos_vb1 (которое мы запомнили ранее в п.2):
    vgextend /dev/centos_vb1 /dev/sda3
  8. Теперь расширим логический том, используя имя тома root (которое мы запомнили ранее в п.2):
    lvextend -l+100%FREE /dev/centos_vb1/root
  9. Сканируем диски на предмет наличия групп томов и активируем все найденные группы томов:
    vgscan
    vgchange -ay
    

  10. Узнаем тип файловой системы:
    file -s /dev/sda1

    Видим, что файловая система XFS.

  11. И наконец, расширяем файловую систему XFS (может потребоваться время):
    xfs_growfs /dev/centos_vb1/root

    Внимание! Если файловая система не XFS, а, например, ext4 или reiserfs, то команды будут такие (с учетом centos_vb1 – имя группы томов и root – имя тома из п.2):
    • resize2fs /dev/centos_vb1/root – для ext4;
    • resize_reiserfs /dev/centos_vb1/root – для reiserfs;

  12. Проверяем итоговый результат:
    df -h



Подключение Swap-раздела

Внимание!
  1. Для операций, описанных в данной главе, необходимы знания администрирования *nix-систем. Перед началом проведения данных операций рекомендуется сделать полный бекап «Виртуальной машины».
  2. Приведённые настройки выходят за рамки меню Виртуальной машины. Это означает, что информация - ознакомительная и применять её следует с чётким пониманием того что вы делаете и с собственной ответственностью за совершаемые действия. В нашей техподдержке рассматриваются только вопросы по работе пунктов меню ВМ.

Виртуальная машина BitrixVM поставляется с swap-разделом 256 МБ, а в образе ami он по умолчанию не подключен. Поэтому в процессе эксплуатации может возникнуть необходимость в расширении раздела подкачки.

Как и в случае с увеличением свободного места, наиболее простой способ - добавить дополнительный диск и разместить раздел подкачки на нем, либо создать файл подкачки.

Для этого:

  • подключаем к виртуальной машине диск или создаем файл подкачки:
    dd if=/dev/zero of=/swapfile bs=1M count=1024
    
  • создаем на диске:
    mkswap /dev/sdb1
    
    или в файле swap-раздел:
    mkswap /swapfile
    
  • подключаем раздел подкачки:
    swapon /dev/sdb1
    
    или файл подкачки:
    chmod 600 /swapfile
    swapon /swapfile
    
  • и наконец, добавляем запись о новом разделе подкачки в /etc/fstab, чтобы не включать после каждой перезагрузки вручную:
    /dev/sdb1 none swap sw 0 0
    
    или о файле подкачки:
    /swapfile none swap sw 0 0
    


Ручная настройка memcached

Внимание!
  1. Для операций, описанных в данной главе, необходимы знания администрирования *nix-систем. Перед началом проведения данных операций рекомендуется сделать полный бекап «Виртуальной машины».
  2. Приведённые настройки выходят за рамки меню Виртуальной машины. Это означает, что информация - ознакомительная и применять её следует с чётким пониманием того что вы делаете и с собственной ответственностью за совершаемые действия. В нашей техподдержке рассматриваются только вопросы по работе пунктов меню ВМ.

Внимание!

Если некорректно настроен Memcached (доступен снаружи), то этим могут воспользоваться злоумышленники для взлома сайта. Необходимо проверить опцию -l <ip> в его настройках. Обращение к Memcached должно быть разрешено только c вашего сайта.

  Настройка memcached

В случае, если в проекте планируется использовать memcached, необходимо произвести его настройку в соответствии с предполагаемой нагрузкой.

Для этого необходимо:

  1. В файле /etc/sysconfig/memcached задать следующие параметры:
    • MAXCONN = "1024" - количество одновременных подключений (по умолчанию 1024);
    • CACHESIZE="1024" - объем выделяемой памяти для кеша (по умолчанию 64MB);
    • OPTIONS="-t 8" - количество потоков memcached (по умолчанию 4).

    Примечание: Параметры MAXCONN, CACHESIZE и OPTIONS подбираются экспериментальным путем в зависимости от характера нагрузки и от имеющихся ресурсов.

    Оценить объем памяти, необходимой для кеширования (параметр CACHESIZE), можно по размеру вашего файлового кеша. Если у вас на проекте файловый кеш занимает 3 GB, то использование memcached c 256МБ памяти не будет эффективным за счет частого вытеснения.

  2. После настройки memcaсhed необходимо перезапустить командой:

    CentOS 6:

    service memcached restart
    

    CentOS 7:

    systemctl restart memcached.service
    
  3. Далее подключить его в /bitrix/php_interface/dbconn.php:

    define("BX_CACHE_TYPE", "memcache");
    define("BX_CACHE_SID", $_SERVER["DOCUMENT_ROOT"]."#01");
    define("BX_MEMCACHE_HOST", "127.0.0.1");
    define("BX_MEMCACHE_PORT", "11211");
    

    И в файле /bitrix/.settings_extra.php (если его нет, то создать):

    <?php
    return array(
      'cache' => array(
        'value' => array(
          'type' => 'memcache',
          'memcache' => array(
            'host' => '127.0.0.1',
            'port' => '11211',
          ),
          'sid' => $_SERVER["DOCUMENT_ROOT"]."#01"
        ),
      ),
    );
    ?>
    

  Работа с memcached через сокет

В случае, если используется один сервер, то для улучшения производительности можно настроить работу с memcached через сокет:

  1. В файле /etc/sysconfig/memcached задать параметры:

    • USER="bitrix" - пользователь, от которого будет запущен memcached;
    • OPTIONS="-t 8 -s /tmp/memcached.sock" - количество потоков и путь к сокету.

  2. Перезапустить memcached командой:

    CentOS 6:

    service memcached restart
    

    CentOS 7:

    systemctl restart memcached.service
    
  3. После этого необходимо изменить настройки в /bitrix/php_interface/dbconn.php:

    define("BX_CACHE_TYPE", "memcache");
    define("BX_CACHE_SID", $_SERVER["DOCUMENT_ROOT"]."#01");
    define("BX_MEMCACHE_HOST", "unix:///tmp/memcached.sock");
    define("BX_MEMCACHE_PORT", "0");
    

    И в файле /bitrix/.settings_extra.php (если его нет, то создать):

    <?php
    return array(
      'cache' => array(
        'value' => array(
          'type' => 'memcache',
          'memcache' => array(
            'host' => 'unix:///tmp/memcached.sock',
            'port' => '0',
          ),
          'sid' => $_SERVER["DOCUMENT_ROOT"]."#01"
        ),
      ),
    );
    ?>
    

Примечание: Если используется многосайтовость, то в примере указывается статичный [dw]sid[/dw][di]Идентификатор сайта, поле ID в параметрах настройки сайта[/di], без $_SERVER["DOCUMENT_ROOT"]. Иначе для двух сайтов кеш будет отличаться, так-как папки сайтов разные.



Исправление ошибок в старых сайтах с кодировкой windows-1251

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

При обновлении старых сайтов в кодировке Windows-1251, созданных в VMBitrix версии 7.4.3 или ниже, могут быть следующие ошибки:

  • Не работает Система обновлений продуктов «1С-Битрикс» – требует наличия параметра mb_internal_encoding('Windows-1251'); в dbconn.php.

  • При включенных предупреждениях Система обновлений не работает из-за предупреждения: «PHP Warning: htmlspecialchars(): charset `latin' not supported, assuming utf-8».

  • Проверка системы выдает ошибку «Строковые функции strtoupper и strtolower работают некорректно».


При обновлении VMBitrix до версии 7.5 и выше данные ошибки в установленных ранее сайтах в кодировке Windows-1251 автоматически не исправляются, поэтому вам нужно исправить их вручную для каждого такого сайта.

  1. Добавьте в файл /bitrix/php_interface/dbconn.php сайта строку:

    mb_internal_encoding('Windows-1251');
    
  2. В конфигурационном файле Apache для вашего сайта /etc/httpd/bx/conf/bx_ext_[ваш_сайт].conf замените строку:

    php_admin_value default_charset latin
    
    на такую:
    php_admin_value default_charset cp1251
    

    И перезапустите Apache:

    systemctl restart httpd.service
    
  3. Проверьте, есть ли локаль ru_RU.cp1251 в системе. Если ответ 0 – значит локали ru_RU.cp1251 нет, если 1 – есть:

    locale -a | grep ru_RU.cp1251 -ic
    

    Если локали ru_RU.cp1251 нет, выполните команду:

    localedef -c -i ru_RU -f CP1251 ru_RU.CP1251
    
  4. Далее добавьте в файл /bitrix/php_interface/dbconn.php вашего сайта в кодировке windows-1251 две строки:

    setlocale(LC_ALL, 'ru_RU.CP1251' );
    setlocale(LC_NUMERIC, 'C' );
    

    И перезапустите Apache:

    systemctl restart httpd.service
    
  5. Все готово. Проделайте эти действия для каждого сайта с кодировкой windows-1251, установленного ранее.


Примечание: В VMBitrix 7.5 и выше новые сайты, создаваемые в кодировке Windows-1251, проблем с однобайтовыми кодировками не имеет.


Корректное монтирование Windows-ресурсов

Внимание!
  1. Для операций, описанных в данной главе, необходимы знания администрирования *nix-систем. Перед началом проведения данных операций рекомендуется сделать полный бекап «Виртуальной машины».
  2. Приведённые настройки выходят за рамки меню Виртуальной машины. Это означает, что информация - ознакомительная и применять её следует с чётким пониманием того что вы делаете и с собственной ответственностью за совершаемые действия. В нашей техподдержке рассматриваются только вопросы по работе пунктов меню ВМ.


В случае необходимости подключения сетевого диска Windows в качестве хранилища для WebDAV можно воспользоваться следующей командой:

mount.cifs \\\\xxx.xxx.xxx.xxx\\folder /home/bitrix/www/docs/folder/smb -o user=XXXX,password=XXXX,uid=600,gid=600,file_mode=0777,noserverino  
где:
  • uid - идентификатор пользователя bitrix;
  • gid - идентификатор группы bitrix;
  • \\\\xxx.xxx.xxx.xxx\\folder - путь к сетевому ресурсу \\xxx.xxx.xxx.xxx\folder (\ используется для экранирования символов);
  • /home/bitrix/www/docs/folder/smb - папка, куда будет смонтирован диск.

Примечание: Использование опции noserverino является обязательным, так как в PHP есть уязвимость.


Выполнение всех агентов на Cron

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

Перенос агентов на cron

На больших и не очень проектах часто возникает вопрос с переносом исполнения некоторых особо тяжелых агентов на Cron. Агент считается "тяжёлым", если время его выполнения более 10 минут.

  • Для начала полностью отключим выполнение агентов на хите. Для этого необходимо выполнить команду в php-консоли административного меню продукта «1С-Битрикс» /bitrix/admin/php_command_line.php?lang=ru:
    COption::SetOptionString("main", "agents_use_crontab", "N"); 
    echo COption::GetOptionString("main", "agents_use_crontab", "N"); 
    
    COption::SetOptionString("main", "check_agents", "N"); 
    echo COption::GetOptionString("main", "check_agents", "Y");
    

    В результате выполнения должно быть NN.

  • Убираем из файла /bitrix/php_interface/dbconn.php определение следующих констант:
    define("BX_CRONTAB_SUPPORT", true);
    define("BX_CRONTAB", true);
    

    И заменяем:

    if(!(defined("CHK_EVENT") && CHK_EVENT===true))
       define("BX_CRONTAB_SUPPORT", true);
     
  • Далее добавляем запуск системного скрипта в Cron:
     */1 * * * * /usr/bin/php -f /home/bitrix/www/bitrix/modules/main/tools/cron_events.php
    
    Замените /home/bitrix/www/ на свой путь к корню сайта.

После этого все агенты и отправка системных событий будут обрабатывается из-под cron, раз в 1 минуту.

Примечание: Если после выполнения команды cron не заработал, то, значит, у вас ошибки в проекте. Эти ошибки, скорее всего, не связаны с агентами. Надо смотреть в логах PHP. Включить расширенный вывод ошибок можно в файле настроек .settings.php.

Очередь отправки почтовых сообщений

Чтобы не увеличивалась очередь отправки почтовых сообщений, нужно изменить параметр, отвечающий за количество почтовых обрабатываемых за раз событий. Для этого выполняем в php-консоли следующую команду:

COption::SetOptionString("main", "mail_event_bulk", "20"); 
echo COption::GetOptionString("main", "mail_event_bulk", "5");

Если очередной запуск cron_events.php произошёл до завершения работы ранее запущенного скрипта, то запуска агентов не произойдет и скрипт завершит свою работу (т.к. агенты блокируются на время выполнения). В данном случае обработка ничем не отличается от обработки на хите, новый хит может произойти в тот момент, когда еще не отработали агенты на предыдущем.

Как правило, скрипты, выполненные из под cron, не имеют ограничения на время исполнения. Но если в скриптах используются методы для работы с БД, то можно столкнуться с ошибкой выполнения вложенных скриптов. Для избежания этой ошибки можно подправить значение в /bitrix/php_interface/dbconn.php:

// если скрипт выполняется кроном, то лимит подключения к БД - 600 секунд, иначе - 60
@set_time_limit(php_sapi_name() == "cli" ? 600 : 60);


Опции монтирования

Внимание!
  1. Для операций, описанных в данной главе, необходимы знания администрирования *nix-систем. Перед началом проведения данных операций рекомендуется сделать полный бекап «Виртуальной машины».
  2. Приведённые настройки выходят за рамки меню Виртуальной машины. Это означает, что информация - ознакомительная и применять её следует с чётким пониманием того что вы делаете и с собственной ответственностью за совершаемые действия. В нашей техподдержке рассматриваются только вопросы по работе пунктов меню ВМ.

Для обеспечения более высокой производительности файловой системы рекомендуем отключать изменение метки времени при чтении файлов и директорий: noatime, nodiratime.

Для этого в /etc/fstab нужно отредактировать (добавить в текущую строку) параметры в строке со своим UUID:

UUID=abd9bdaa-e17d-40b3-aee5-37ef53a57b16 /    ext4    defaults,noatime,nodiratime    1 1
где UUID=abd9bdaa-e17d-40b3-aee5-37ef53a57b16 - уникальный идентификатор диска, который можно узнать в консоли по команде blkid.

Примечание: Вместо UUID можно также использовать имя устройства: /dev/sda1, /dev/sda2, /dev/sda3. Или метку тома если она задана, например: LABEL=root.

После перезагрузки новые настройки начнут действовать.

Чтобы применить новые настройки, не перезагружая сервер, можно выполнить перемонтирование разделов командой:

mount -o remount,noatime,nodiratime /

Примечание: К решению проблемы производительности файловой системы нужно подходить творчески. Если, например, на диске есть еще кеш некоторых приложений, то от предложенных мер производительность может снизиться, так как многие приложения очищают кеш по метке доступа, которые в примере предлагается отключить. В некоторых случаях увеличение времени коммита может дать лучший результат, особенно если много оперативной памяти. Время коммита задается параметром commit. Для установки его в 120 секунд, например, необходимо добавить commit=120. То есть набор опций монтирования будет defaults,noatime,commit=120.

По умолчанию сброс данных и метаданных на диск происходит каждые 5 сек. Откладывание времени сброса, так же может уменьшить фрагментацию файлов на диске, если есть файлы, в которые часто происходит дописывание данных. Например логи.


Подключение IDE

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

Для упрощения работы с Bitrix Framework в виртуальную машину включён Xdebug. Работает он по схеме:

Перед изменением настроек надо переименовать файл xdebug.ini.disabled в xdebug.ini и перезапустить httpd.

Для настройки машины воспользуйтесь следующим примером:

$ cat /etc/php.d/xdebug.ini
; Enable xdebug extension module
zend_extension=/usr/lib64/php/modules/xdebug.so
xdebug.remote_enable=on
xdebug.remote_host=192.168.205.1
xdebug.remote_port=9000

Примечание: Xdebug требует использовать proxy при работе через Network Address Translation (NAT), необходимо открыть порт 9000.


Исходные коды пакетов (начиная с версии 7.3.0!)

Внимание!
  1. Для операций, описанных в данной главе, необходимы знания администрирования *nix-систем. Перед началом проведения данных операций рекомендуется сделать полный бекап «Виртуальной машины».
  2. Приведённые настройки выходят за рамки меню Виртуальной машины. Это означает, что информация - ознакомительная и применять её следует с чётким пониманием того что вы делаете и с собственной ответственностью за совершаемые действия. В нашей техподдержке рассматриваются только вопросы по работе пунктов меню ВМ.

При разработке своих решений на основе виртуальной машины BitrixEnv/VMBitrix.CRM, может понадобиться отслеживание изменений в версиях файлов. Для этого вы можете подключить репозиторий исходников виртуальной машины.

Внимание! Исходные коды пакетов доступны для стабильных и бета-версий VMBitrix/VMBitrix.CRM, начиная с версии 7.3.0.


Стабильная VMBitrix/VMBitrix.CRM

  1. Добавляем файл для репозитория /etc/yum.repos.d/bitrix-source-stable.repo с содержимым:

    [bitrix-source-stable]
    name=$OS $releasever - source
    failovermethod=priority
    baseurl=https://repo.bitrix.info/yum/SRPMS
    enabled=1
    gpgcheck=1
    gpgkey=https://repo.bitrix.info/yum/RPM-GPG-KEY-BitrixEnv
    
  2. Проверяем, что есть пакет yum-utils:

    yum clean all && yum install yum-utils
    
  3. Скачиваем исходники виртуальной машины:

    • VMBitrix:

      yumdownloader --source bitrix-env
      
      Примерный ответ в консоли для обычной VMBitrix
    • VMBitrix.CRM

      yumdownloader --source bitrix-env-crm
      
      Примерный ответ в консоли для VMBitrix.CRM

Бета VMBitrix/VMBitrix.CRM

  1. Добавляем файл для репозитория /etc/yum.repos.d/bitrix-source-beta.repo с содержимым:

    [bitrix-source-beta]
    name=$OS $releasever - source
    failovermethod=priority
    baseurl=https://repo.bitrix.info/yum-beta/SRPMS
    enabled=1
    gpgcheck=1
    gpgkey=https://repo.bitrix.info/yum/RPM-GPG-KEY-BitrixEnv
    
  2. Проверяем, что есть пакет yum-utils:

    yum clean all && yum install yum-utils
    
  3. Скачиваем исходники виртуальной машины:

    • VMBitrix:

      yumdownloader --source bitrix-env
      
    • VMBitrix.CRM

      yumdownloader --source bitrix-env-crm
      


Ручное включение php-расширений

Внимание!
  1. Для операций, описанных в данной главе, необходимы знания администрирования *nix-систем. Перед началом проведения данных операций рекомендуется сделать полный бекап «Виртуальной машины».
  2. Приведённые настройки выходят за рамки меню Виртуальной машины. Это означает, что информация - ознакомительная и применять её следует с чётким пониманием того что вы делаете и с собственной ответственностью за совершаемые действия. В нашей техподдержке рассматриваются только вопросы по работе пунктов меню ВМ.

  Ручное включение

Помимо [ds]включения некоторых php-расширений из меню BitrixEnv[/ds][di]В разделе 8. Manage web nodes in the pool > 2. Manage PHP extensions можно включить дополнительные модули PHP, которые могут понадобится в продуктах «1C-Битрикс».

Подробнее ...[/di] можно включать нужные расширения вручную.

Конфигурационные ini-файлы доступных php-расширений находятся в директории /etc/php.d/:

Чтобы вручную включить нужное расширение, нужно файл {имя_расширения}.ini.disabled переименовать в {имя_расширения}.ini и перезапустить сервис Apache – httpd.

  Пример

Например, нам нужно включить расширение dom.

  1. Переходим в директорию сервера /etc/php.d/:

    cd /etc/php.d/
    
  2. Выводим список файлов в директории:

    ls
    
  3. Находим в списке файл 20-dom.ini.disabled, переименуем его в 20-dom.ini и сохраним с заменой текущего:

    mv 20-dom.ini.disabled 20-dom.ini
    

    Внимание! Если скопировать содержимое 20-dom.ini.disabled в 20-dom.ini и оставить эти два файла в директории /etc/php.d/, то при обновлении PHP или виртуальной машины dom-расширение будет деактивировано. Чтобы этого не произошло, нужно оставлять только один файл 20-dom.ini с активированным расширением.

  4. Далее перезапустим сервис Apache – httpd:

    • CentOS 6:

      service httpd restart
      
    • CentOS 7:

      systemctl restart httpd.service
      
  5. Все готово, расширение dom работает:

  Установка php-расширения, которого нет в BitrixVM

Также вы можете установить любое php-расширение самостоятельно.

Например установим расширение php-imap.

Сначала нужно найти его имя с помощью команды:

yum list php-imap*

Далее установить командой:

yum install php-imap

При установке будет создан файл /etc/php.d/20-imap.ini.

Затем нужно перезапустить сервис httpd.

Все готово, php-расширение imap работает:

Примечание: Некоторые php-расширения могут автоматически сами включаться после установки. Если ini-файл не был создан во время установки расширения, нужно создать его самостоятельно.



Настройка проксирования в BitrixVM

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

Очень частая ситуация, когда BitrixVM располагают внутри локальной сети офиса и проксируют запросы на нее из внешней сети Интернет.

Под проксированием будем понимать http-прокси, который имеет внешний адрес и позволяет организовать подключение пользователей к сайту, расположенному на виртуальной машине BitrixVM, а также сетевое оборудование, которое позволяет на уровне TCP/IP организовать подключение.



Настройка сервера

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

  Организация работы web-сокетов

Основная особенность в данном случае – это организация работы web-сокетов (ws/wss протоколов), так как бывают ситуации, когда требуются дополнительные настройки для того, чтобы сетевое оборудование не прерывало соединение по таймауту.

Настройку сетевого оборудования мы обсуждать не будем – предположим, что уже все настроено, поддержка web-сокетов включена.

Опишем ситуацию, когда понадобилось для работы перенести порт для ws/wss протоколов.

  1. Конфигурация виртуальной машины

Создаем конфигурационный файл /etc/nginx/bx/site_ext_enabled/rtc_ext.conf:

server {
	listen 1137;
	listen 1139 default_server ssl;

	#access_log off;

	server_name _;

	# ssl settings
	include bx/conf/ssl.conf;


	# Include im subscrider handlers
	include bx/conf/im_subscrider.conf;

	location / {
		deny all; 
	}
}
Внимательно отнеситесь к настройкам SSL (https). Нужно использовать те же настройки и тот же SSL-сертификат, что и на сайте, к которому предполагается подключить Push-server. Пример настроек можно взять из конфигурационного файла: /etc/nginx/bx/site_enabled/rtc-server.conf.

Не забываем перезапустить nginx после того, как внесли все коррективы.

CentOS 6:

service nginx restart

CentOS 7:

systemctl restart nginx.service

  2. Открытие портов

Открываем порты в виртуальной машине BitrixVM:

iptables:

iptables -I INPUT -p tcp -m state --state NEW -m tcp --dport 1137 -j ACCEPT
iptables -I INPUT -p tcp -m state --state NEW -m tcp --dport 1139 -j ACCEPT
iptables-save > /etc/sysconfig/iptables

firewalld:

firewall-cmd --permanent --add-port=1137/tcp
firewall-cmd --permanent --add-port=1139/tcp
firewall-cmd --reload

  3. Изменение настроек сайта

Добавляем выбранные порты в конфигурационный файл bitrix/.settings.php:

'pull_s1' => 'BEGIN GENERATED PUSH SETTINGS. DON\'T DELETE COMMENT!!!!',
'pull' => Array(
    'value' =>  array(
...
        'path_to_websocket' => 'ws://#DOMAIN#:1137/bitrix/subws/',
        'path_to_websocket_secure' => 'wss://#DOMAIN#:1139/bitrix/subws/',
...
    ),
),
'pull_e1' => 'END GENERATED PUSH SETTINGS. DON\'T DELETE COMMENT!!!!',

И затем проверяем работу через браузер.



Проксирование запросов

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

Предположим, что в качестве внешнего прокси выступает nginx сервер.
При желании можно данные настройки адаптировать и для других прокси-сервисов.

  Push-server

Вне зависимости от того, как организована у вас работа балансера – единственная точка входа или он обслуживает только запросы клиентов из внешних сетей, а BitrixVM запросы внутренней сети – на него нужно перенести настройки Push-server.

Переносим настройки проксирования запросов push на балансер – можно взять конфигурационный файл виртуальной машины bx/conf/im_subscrider.conf за основу (можно прям его скопировать на балансер):

location ~* ^/bitrix/subws/ {
    access_log off;
    proxy_pass http://nodejs_sub;
    # http://blog.martinfjordvald.com/2013/02/websockets-in-nginx/
    # 12h+0.5
    proxy_max_temp_file_size 0;
    proxy_read_timeout  43800;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $replace_upgrade;
    proxy_set_header Connection $connection_upgrade;
}

location ~* ^/bitrix/sub/ {
    access_log off;
    rewrite ^/bitrix/sub/(.*)$ /bitrix/subws/$1 break;
    proxy_pass http://nodejs_sub;
    proxy_max_temp_file_size 0;
    proxy_read_timeout  43800;
}

location ~* ^/bitrix/rest/ {
    access_log off;
    proxy_pass http://nodejs_pub;
    proxy_max_temp_file_size 0;
    proxy_read_timeout  43800;
}

Данный файл подключаем к серверу, на котором настроено проксирование запросов на виртуальную машину.


Верхний конфигурационный файл зависит от bx/settings/rtc-im_settings.conf, в котором определяются следующие параметры:

  • передача заголовков Upgrade и Connection через переменные:
    # if connection ti not set
    map $http_upgrade $connection_upgrade {
      default upgrade;
      '' 'close';
    }
    
    map $http_upgrade  $replace_upgrade {
      default $http_upgrade;
      ''      "websocket";
    }
    
  • upstream-server
    upstream nodejs_sub {
      ip_hash;
      keepalive 1024;
      server push:8010;
      server push:8011;
      server push:8012;
      server push:8013;
      server push:8014;
      server push:8015;
    }
    
    
    upstream nodejs_pub {
      ip_hash;
      keepalive 1024;
      server push:9010;
      server push:9011;
    }
    

Данный файл bx/settings/rtc-im_settings.conf тоже можно скопировать и подключить на уровне http-секции на балансере.

Важно! В файле bx/settings/rtc-im_settings.conf указано имя push-сервера, в рамках виртуальной машины BitrixVM все имена серверов пула прописаны в /etc/hosts. Внешний балансер об этом ничего не знает, поэтому нужно или прописать соответствие в hosts-файл балансера, или поменять настройку на IP-адрес push-сервера.

Далее на push-server необходимо открыть порты 8010-8015 и 9010-9011 для доступа с балансера.

iptables:

iptables -I INPUT -p tcp --match multiport --dport 8010:8015 -j ACCEPT
iptables -I INPUT -p tcp --match multiport --dport 9010:9011 -j ACCEPT
iptables-save > /etc/sysconfig/iptables

firewalld:

firewall-cmd --permanent --add-port=8010-8015/tcp
firewall-cmd --permanent --add-port=9010-9011/tcp
firewall-cmd --reload

  HTTPS доступ

Предположим, мы проксируем http и https сайта test.example.org на 80 порт виртуальной машины BitrixVM.

Включим модуль real_ip в BitrixVM – создаем конфигурационный файл bx/settings/real_ip.conf:

set_real_ip_from BALANCER_IP;
real_ip_header X-Forwarded-For;

В качестве real_ip_header нужно указать заголовок балансера, который он передает на бэкенд (виртуальную машину BitrixVM). В set_real_ip_from – IP-адрес балансера.

Перезапускаем nginx.

CentOS 6:

service nginx restart

CentOS 7:

systemctl restart nginx.service

Далее настраиваем передачу протокола, по которому клиент работает с сервером.

Нам нужно, чтобы балансер передавал на бэкенд-сервер информацию о протоколе:

proxy_set_header X-Forwarded-Proto $scheme;

На бэкенде (виртуальная машина BitrixVM) делаем конфигурацию для настройки переменных в файле bx/settings/schema.conf:

map $http_x_forwarded_proto $balancer_port {
   default 80;
   "https" 443;
}

map $http_x_forwarded_proto $balancer_https {
    default "NO";
    "https" "YES";
}

Тогда на бэкенде переменная $http_x_forwarded_proto будет содержать значение http или https в зависимости от протокола подключения.


Далее нам потребуется конфигурационный файл сайта:

сайт по умолчанию – /etc/nginx/bx/site_enabled/s1.conf
дополнительный сайт – /etc/nginx/bx/site_enabled/bx_ext_test.example.org.conf

В конфигурационном файле сайта нас интересует часть:

proxy_set_header Host $host:80;

Меняем указанную выше часть на:

proxy_set_header Host $host:$balancer_port;
proxy_set_header HTTPS $balancer_https;

Перезапускаем nginx:

CentOS 6:

service nginx restart

CentOS 7:

systemctl restart nginx.service

Все готово.

  Телефония

Для настройки проксирования телефонии можно использовать правило:

location ~* ^/(pub/imconnector/|pub/imbot.php|services/telephony/info_receiver.php|bitrix/tools/voximplant/) {
proxy_ignore_client_abort on;
proxy_pass $proxyserver;
}

О других настройках локальной сети при использовании телефонии рассказывается в соответствующем уроке курса Администратор сервиса Битрикс24.



BitrixVM API для провайдеров

В главе описывается API, помощью которого можно подключить процедуру заказа/создания машины в управлении пулом в продуктах «1С-Битрикс».



Провайдеры

Вся работа с провайдерами осуществляется с помощью плагинов, расположенных в определенном каталоге (на текущий момент всё управление сделано на файлах): /opt/webdir/providers.

Для каждого провайдера предусмотрены:

  • обязательные параметры командной строки для универсализации доступа к их возможностям;
  • стандартизированный вывод по завершению обработки результатов.

Скрипт плагина, который будет использован в web-интерфейсе продуктов «1С-Битрикс», должен быть раcположен по адресу:

/opt/webdir/providers/{provider_name}/bin/{provider_name}

Для подключения в пул плагин провайдера должен поддерживать следующие аргументы командной строки:

  • help - отображает поддерживаемые аргументы командной строки:
    {
      "options": [
        "help",
        "configs",
        "order",
        "order_status"
      ],
      "status": "enabled"
    }
    

    Массив options должен содержать список поддерживаемых опций (например, в данном случае отсутствует опция init, которая позволяет подключиться на этапе создания мастер сервера).

    Опция status может содержать следующие значения: disabled или enabled, что позволяет определить включен или выключен провайдер на конкретном сервере.

  • configs - отображает список поддерживаемых конфигураций:
    {
      "configurations": [
        {
          "id": "1",
          "descr": "Bitrix-env, 1 month, Centos-6 x86_64, CPU 2x1.0 Ghz, Memory 1Gb, HDD 20Gb"
        }
      ],
      "status": "enabled"
    }
    

    configurations - содержит список сервисов/конфигураций, которые может заказать пользователь, используя web интерфейс «1С-Битрикс».

    На текущий момент поддерживается два параметра по каждой конфигурации:

    • id - идентификатор конфигурации, который будет использован в заказе,
    • descr - описание для пользователя.
  • order - позволяет заказать сервер/VPS выбранной конфигурации, вторым параметром в данном случае будет передан номер конфигурации:
    {"task_id":"24"}
    

    task_id должен содержать номер задания, который используется для дальнейшего опроса и старта добавления машины по завершению.

  • order_status - позволяет получить информацию по заказу:
    {
      "server_password": "XXXXXXXXXXXXXX",
      "status": "finished",
      "server": "xxx.xxx.xxx.xxx",
      "task_id": "24"
    }
    
    где:
    • status - содержит информацию по заказу, может содержать следующие значения:
      • in_progress - находится на обработке со стороны провайдера/хостера;
      • finished - обработка завершена, можно добавлять машину в пул;
      • error - во время выполнения произошла ошибка.
    • server - содержит ip address или имя машины;
    • server_password - содержит пароль пользователя root для копирования ssh-ключей при подключение сервера в пул.

    Любое из действий может сообщить об ошибке с помощью значений в полях error и error_message. Например:

    {
      "error_message": "get_task error N102, No task found",
      "error": 1
    }
    

Внимание! Информацию о работе скрипта, который использует возможности провайдеров и позволяет подключить их в web- интерфейс, см Скрипт работы с провайдерами.



Скрипт работы с провайдерами

Данный скрипт нужен для встраивания плагинов провайдеров в web- интерфейс продуктов «1C-Битрикс».

На текущий момент реализованы следующие методы:

  • list - отображает список всех провайдеров, для которых существуют подкаталоги в директории /opt/webdir/providers на машине:
    {
      "params": {
        "providers": {
          "superprovider": {
            "status": "enabled"
          },
          "amazon": {
            "error": 1,
            "message": "bxProvider::optionsProvider: Provider amazon not exist on the host"
          }
        }
      }
    }
    

    В данном случае, это только включено или выключено, а так же ошибки, который возникли при запросе статуса.

    В случае если провайдеров нет на хосте, список будет пустым:

    {
      "params": {
        "providers": {
          
        }
      }
    }
    
  • status - покажет статус для провайдера:
    /opt/webdir/bin/bx-provider -a status --provider superprovider -o json
    {
      "params": {
        "provider_options": {
          "superprovider": {
            "options": {
              "order_status": 1,
              "order": 1,
              "help": 1,
              "configs": 1,
              "init": 0
            },
            "status": "enabled",
            "files": {
              "execute": "/opt/webdir/providers/superprovider/bin/superprovider",
              "holder": "/opt/webdir/providers/superprovider",
              "config": "/opt/webdir/providers/superprovider/etc/superprovider.conf"
            },
            "name": "superprovider",
            "config": "exists"
          }
        }
      }
    }
    

    В данном случае печатает внутреннюю информацию (используется как есть внутри обработчика), по сути, такой статус больше подходит для отладки работы провайдера, чем для использования в web-интерфейсе.

  • install и uninstall - создает/удаляет данные для провайдера (на текущий момент больше для отладки, возможно, в дальнейшем с помощью этих методов хостеры смогут установить свой плагин на сервер и удалить его):
    /opt/webdir/bin/bx-provider -a install --provider amazon --archive /tmp/amazon-v01.tar.gz
    
  • configs - отображает список всех конфигураций провайдера:
    /opt/webdir/bin/bx-provider -a configs --provider superprovider -o json
    {
      "params": {
        "provider_configs": {
          "superprovider": {
            "configurations": [
              {
                "id": "1",
                "descr": "Bitrix-env, 1 month, Centos-6 x86_64, CPU 2x1.0 Ghz, Memory 1Gb, HDD 20Gb"
              }
            ],
            "status": "enabled"
          }
        }
      }
    }
    
  • order - заказывает виртуальный сервер или VPS:
    /opt/webdir/bin/bx-provider -a order --provider superprovider --config_id 1 -o json
    {
      "params": {
        "provider_order": {
          "superprovider": {
            "task_id": "25"
          }
        }
      }
    }
    
  • order_status - отображает статус заказа:
    /opt/webdir/bin/bx-provider -a order_status --provider superprovider --task_id 25 -o json 
    {
      "params": {
        "provider_order": {
          "superprovider": {
            "server_password": "XXXXXXXXXXXXXXX",
            "status": "complete",
            "server": "xxx.xxx.xxx.xxx"
            "task_id": "25"
          }
        }
      }
    }
    
  • orders_list - список всех заказов, сделанных на хосте:
    /opt/webdir/bin/bx-provider -a orders_list --provider superprovider -o json
    {
      "params": {
        "provider_order_list": {
          "superprovider": {
            "25": {
              "status": "finished",
              "mtime": 1403445981,
              "error": 0,
              "message": ""
            },
            "22": {
              "status": "error",
              "mtime": 1403441000,
              "error": 1,
              "message": "cannot add ssh key to the server"
            },
            "21": {
              "status": "complete",
              "mtime": 1403440979,
              "error": 0,
              "message": ""
            },
            "23": {
              "status": "finished",
              "mtime": 1403441229,
              "error": 0,
              "message": ""
            }
          }
        }
      }
    }
    

    Тут добавлен еще один статус по задаче: complete - это значит, что сервер из данного задания был добавлен в пул.

  • order_to_host - запускает процедуру добавления сервера в пул с параметрами, переданными в статусе заказа:
    /opt/webdir/bin/bx-provider -a order_to_host --provider superprovider --task_id 25 -o json
    


Конфигурация и настройка web-кластера

Описание

Рассмотрим пул серверов из двух нод:

  • vm04 - основная нода ( на ней развернут пул )
  • vm03 - дополнительная нода ( на ней нет серверов )

Созданием веб-кластера, решаются следующие задачи:

  • Создание резервной копии.
  • Разделение веб-нагрузки на 2 ноды.

Через существующую реализацию кластера не решаются следующие задачи:

  • Горячая копия веб-сервера (вторая веб-нода) не будет полноценной заменой первой (без дополнительного вмешательства со стороны администратора сервера).
  • Возможность восстановления файлов, в случае их удаления. Синхронизация, в том числе и удаление, происходит достаточно быстро и удаление на любой ноде - приведет к удалению файла на всех.

В текущих настройках выделяются два типа веб-серверов:

  • Балансер: балансировщик, который проксирует запросы на все остальные ноды.
  • Веб: обработка php запросов.

Первый сервер в группе всегда - это роль балансера и веб. Все дополнительные сервера - это роль веб. В случае Виртуальной машины - роль балансера не может быть перенесена. Если ее нужно вынести на отдельный сервер, то читайте следующий урок.

Настройка web-ноды

Настройка web-ноды включает в себя следующие шаги:

  • Настройка синхрониазции файлов между нодами.
  • Конфигурация веб-служб для обработки запросов.

В BitrixVM представлено два сценария, которые настраивают веб-ноды:

  1. Настраивает web-ноду по шагам:
    • на первом шаге запускается сценарий по настройке синхронизации файлов,
    • на втором настраивает веб-сервисы.
    Шаги нужно разделить по времени если файлов много и перед запуском веб-сервисов хочется убедиться, что синхронизация выполнилась без ошибок.
  2. Настраивает все за "один" шаг. В один запуск сценария.

Синхронизация файлов/lsyncd

Синхронизация файлов делается через lsyncd.

Принцип работы:

  • intotify уведомляет приложение об изменениях в файловой системе;
  • lsyncd агрегирует изменения и запускает rsync/ssh для синхронизации;
  • синхронизация выполняется под пользователем bitrix.

Каталоги, которые синхронизируются (с сервера с ролью балансер на остальные сервера):

- /etc/nginx/bx/conf,
- /etc/nginx/bx/maps,
- /etc/nginx/bx/site_avaliable,
- /etc/nginx/bx/site_enabled,
- /etc/nginx/bx/site_cluster,
- /etc/nginx/bx/settings,
- /etc/httpd/bx/conf.

Между серверами с ролью веб - синхронизируются каталоги сайтов за исключением следующих подкаталогов:

- bitrix/cache
- bitrix/managed_cache
- bitrix/stack_cache
- upload/resize_cache.

Настройки lsyncd

Настройка включает в себя следующие шаги:

  1. Создание ssh ключей для пользователя bitrix. Это необходимо для работы rsync/ssh.
  2. Создание сервисов для синхронизации lsyncd-<HOSTNAME>, где HOSTNAME - это [dw]имя сервера[/dw][di]Уникальный идентификатор сервера в пуле.[/di] на который будут отправлены файлы в случае их изменения, создания или удаления.

    Например, если мы создаем web-ноду на сервере vm03, то на сервере vm04, будет создан сервис lsyncd-vm03; на сервере vm03 - lsyncd-vm04.

  3. Создание каталогов под временные файлы lsyncd. Это делается через сервис systemd-tmpfiles. Конфигурационный файл - /etc/tmpfiles.d/lsyncd.conf.
  4. Конфигурационные файлы lsyncd расположены по следующему пути /etc/lsyncd-<HOSTNAME>.conf.

    Основное различие между серверами: для сервера с ролью балансера (в примере vm04) файлы конфигурации будут содержать подкаталоги из /etc и каталоги сайтов. Для всех остальных дополнительных нод файлы конфигурации содержат только каталоги сайтов.

    Например, для конфигурации указанной выше. На сервере vm04 файл /etc/lsyncd-vm03.conf будет содержать следующие каталоги:

    sync {
      default.rsyncssh,
      host        = "vm03",
      source      = "/etc/nginx/bx/",
      targetdir   = "/etc/nginx/bx/",
      exclude   = {
        "site_enabled/http_balancer*.conf",
        "site_enabled/https_balancer*.conf",
        "site_enabled/upstream.conf",
        "site_enabled/pool_manager.conf",
        "site_ext_enabled/",
        "server_monitor.conf",
        "pool_passwords",
        }
    ....
    }
    
    -- httpd
    sync {
      default.rsyncssh,
      host        = "vm03",
      source      = "/etc/httpd/bx/conf/",
      targetdir   = "/etc/httpd/bx/conf/",
    }
    
    sync {
      default.rsyncssh,
      host        = "vm03",
      source      = "/home/bitrix/www/",
      targetdir   = "/home/bitrix/www/",
      exclude   = {
        "bitrix/cache/",
        "bitrix/managed_cache/",
        "bitrix/stack_cache/",
        "upload/resize_cache/",
        "*.log", // учтите, что исключая "*.log", исключаются компоненты и модули, например bizproc.log
      },

    А конфигурационный файл на сервере vm03 /etc/lsyncd-vm04.conf будет содержать каталоги:

    sync {
      default.rsyncssh,
      host        = "vm04",
      source      = "/home/bitrix/www",
      targetdir   = "/home/bitrix/www",
      exclude   = {
        "bitrix/cache/",
        "bitrix/managed_cache/",
        "bitrix/stack_cache/",
        "upload/resize_cache/",
        "*.log", // учтите, что исключая "*.log", исключаются компоненты и модули, например bizproc.log
        "bitrix/.settings.php",
        "php_interface/*.php",
    ...
    }

    Примечание: Если на сервере больше чем один сайт, то все они будут синхронизированы.

  5. Запуск сервиса и отслеживания статуса синхронизации. В сценарий включена проверка завершения синхронизации выбранных каталогов. Делается это через файл статуса для каждого запущенного сервиса: /var/log/lsyncd/daemon-<HOSTNAME>.status

Настройка и конфигурация web-служб

Выполните следующие шаги:

  1. Cоздайте логин для работы с базой. Работа с базой выполняется на удаленном сервере, поэтому требуется новый пользователь для работы с базой.
  2. Пропишите новые параметров в конфигурацию сайта. Меняются как настройки файлов, так и создаются записи в базу в модуль cluster.
  3. Создайте балансировщик на первой ноде пула (конфигурация NGINX сервиса). Балансирование нагрузки делается всегда на первой ноде в группе (в нашем примере vm04).

    Конфигурационные файлы: /etc/nginx/bx/site_enabled/http_balancer.conf и https_balancer_<SITENAME>.conf Настройки пула web-серверов содержаться в конфиге: /etc/nginx/bx/site_enabled/upstream.conf.

    Нагрузка распределяется по IP адресу клиента. В обычной ситуации клиент с одного и того же IPv4 адреса будет попадать на один и тот же web-сервер. Дополнительные конфиги для https_balancer* связаны с возможным существованием нескольких сайтов с разными сертификатами для одной конфигурации.
  4. Для Apache добавьте страницу статуса, которая позволяет из модуля cluster следить за статусом подключенного сервиса
  5. Выполните регистрацию нового веб-сервера в модуле Веб-кластер.

    Дополнительно на этом шаге в пуле за сервером закрепляется новая роль - web сервера.


Веб-кластер: конфигурация, бэкапы, восстановление

Описание

Рассмотрим несложную конфигурацию, где:

  • srv1 - главный web-сервер в пуле серверов. На нем настроен NGINX сервер в качестве балансера и есть Apache сервер который обрабатывает php-запросы.
  • srv2 - дополнительный сервер. На нем есть настроенный NGINX сервер с копией конфигов srv1. И есть Apache сервер, который обрабатывает php-запросы.

Примечание: На текущий момент конфигурации, которая позволяет вынести NGINX-балансер на отдельную ноду нет. Если таковая требуется можно взять за основу конфигурационные файлы NGINX сервера srv1. Но надо помнить, что официальной поддержки такой конфигурации в модуле Веб-кластер нет.

Между нодами настроена синхронизация файлов в обе стороны, используется lsyncd.

Для этого на каждой ноде поднят дополнительный сервис lsyncd-<имя_сервера>, где имя сервера - это идентификатор хоста в пуле Виртуальной машины с которым выполняется синхронизация. В нашем примере на сервере srv1, можно найти сервис lsyncd-srv2, который будет синхронизировать файлы с сервера srv1 на srv2. Синхронизация файлов выполняется по протоколу SSH+Rsync с авторизацией по ключу пользователем bitrix Виртуальной машины BitrixVM.

Логи сервиса можно найти в каталоге /var/log/lsyncd. Например, daemon-srv2.log - будет содержать лог синхронизации с серверов srv2, а daemon-srv2.status - текущий статус синхронизации. При этом основной сервер синхронизирует следующие каталоги:

/etc/httpd/bx/conf/
/etc/nginx/bx/
<каталог(и) сайта(ов)>

На дополнительных серверах, синхронизируются только каталоги для сайтов.

Из синхронизации на основном и дополнительных серверах исключены - подкаталоги содержащие кеш для сайтов, на дополнительных еще исключаются конфигурационные файлы:

"bitrix/cache/",
"bitrix/managed_cache/",
"bitrix/stack_cache/",
"upload/resize_cache/",
"*.log",
"bitrix/.settings.php",
"php_interface/*.php",

Какие есть возможности у такой конфигурации:

  • Масштабирование запросов, оба сервера могут обрабатывать запросы клиентов
  • "Бэкап" основного сервера. Тут важно понимать, что данная конфигурация не защищает от удаления данных, синхронизация через lsyncd выполняется достаточно быстро и удаление их на одной ноде, приведет к удалению на другой. Если нужен бэкап данных, настраиваем его стандартными способами. Архив лучше хранить не на тех же серверах, где происходит работа с файлами.

Теперь рассмотрим, что будет если одна из нод выйдет из строя.

Сломался дополнительный веб-сервер

Простой вариант - выходит из строя дополнительный web-сервер.

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

Если дополнительный сервер рабочий, но необходимо вывести его из эксплуатации, то используйте предусмотренный пункт в меню Виртуальной машины. Если такой возможности нет, то можно отключить вручную, убрав его из upstream серверов NGINX и выключив синхронизацию lsyncd конфигов.

Внимание! Если доступ к дополнительной ноде (srv2) есть у вас, но нет на мастер сервере, то выключите lsyncd сервис и на дополнительной ноде. Это нужно сделать до того как начнете чистить данные или работать с нодой вне пула.

По шагам на нашем примере:

  1. Отключить использование ноды на главном сервере /etc/nginx/bx/site_enabled/upstream.conf:
    upstream bx_cluster {
    ..
    server srv2:8080;
    }
  2. Удалить строку с неиспользуемым сервером.
    systemctl restart nginx
  3. Отключить синхронизацию файлов на дополнительной ноде:
    systemctl stop lsyncd-srv2
    systemctl disable lsyncd-srv2
  4. Отключить синхронизацию файлов:
    systemctl stop lsyncd-srv1
    systemctl disable lsyncd-srv1

Сломался основной сервер

Сложный вариант - выход из строя основного web-сервера. Его вы не пропустите скорее всего, но мониторинг тоже лучше настроить.

Ситуация тяжёлая, но не паникуйте: у вас есть все необходимые конфигурационные файлы на дополнительной ноде (не все включены в использование, но это легко поправить).

  1. Включите конфигурационные файлы балансера:
    ln -sf /etc/nginx/bx/site_avaliable/http* /etc/nginx/bx/site_enabled/
    ln -sf /etc/nginx/bx/site_avaliable/upstream.conf /etc/nginx/bx/site_enabled/
  2. Уберите основной сервер в upstream (/etc/nginx/bx/site_enabled/upstream.conf):
    upstream bx_cluster {
      ip_hash;
    
      server srv1:8080;
    ...
    
      keepalive 10;
    }
  3. Проверьте, что конфигурация рабочая и пеерезапустите NGINX:
    nginx -t
    systemctl restart nginx
  4. По умолчанию ваш сайт работает на ip-адресе сервера srv1. Самый простой вариант переключить DNS запись на адрес сервера srv2. Заранее нужно продумать это вариант, если время кеширования записи большое, то такое переключение может затянутся на часы или дни.

Как сделать образ BitrixVM для клонирования

В этой главе будет описано, как сделать образ виртуальной машины BitrixVM для клонирования.

Это пригодится специалистам, которые делают минимальную настройку виртуальной машины BitrixVM и потом клонируют ее, а полученный клон используют дальше для развертывания.

Рассмотрим установку часто используемых сервисов виртмашины:

  • push-server
  • memcached сервер

Существует 2 способа перенести виртуальную машину BitrixVM – ручное создание клона существующей машины с необходимыми сервисами и автоматическое развертывание готового образа (рекомендуемый).

Клонирование образа

План создания клона виртуальной машины BitrixVM выглядит примерно так:

  1. Для установки ПО нужно включить пул управления для машины
  2. Поставить необходимое ПО через меню или с помощью скриптов
  3. Удалить настройки пула
  4. Дополнительные очистки системы и ssh-ключей
  5. Сделать образ машины

1. Включение пула управления на машине

Данный шаг необходим, чтобы получить доступ к настройкам сервера, установки push-server и memcached.

Если на чистом сервере в меню выбрать пункт 1. Create Management pool of server, то он как раз проведет по необходимым настройкам.

Либо можно выполнить следующую команду:

/opt/webdir/bin/wrapper_ansible_conf -a create -H SERVER_NAME -I NET_INTERFACE
где:
-H SERVER_NAME – это имя сервера, которое будет использовано в настройках.
-I NET_INTERFACE – это сетевой интерфейс, чей IP-адрес будет использован в настройках пула.

Данная команда вернет ID задания, завершения которого нужно дождаться, чтобы продолжить дальше:

message
...
Run configuration pool job task_id=common_7874274840
All operations complete

Дождаться завершения можно, отслеживая состояние лог-файла:

tailf /opt/webdir/temp/common_7874274840/status
...
srv1                       : ok=75   changed=30   unreachable=0    failed=0

Если в полях unreachable и failed будут нулевые значения, значит все хорошо и можно продолжать.


2.1. Установка push-server

Установить push-server можно через меню или с помощью команды:

/opt/webdir/bin/bx-sites -a push_configure_nodejs -H  SERVER_NAME

Дожидаемся завершения задания.

info:bxDaemon:pushserver_2042054462:7097:1594650283::running:::

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

Предполагается, что образ будет использован для копирования виртуальной машины, поэтому адрес на новой установке, скорее всего, будет другой и указанные настойки не сработают. Чтобы это обойти, мы меняем адрес сервиса на localhost, который есть на любом Linux-хосте.

Для этого в файле /etc/sysconfig/push-server-multi меняем параметр на:

WS_HOST=127.0.0.1

И пересоздаем конфиги push-server:

systemctl stop push-server

/etc/init.d/push-server-multi reset

Nginx проксирует запросы на push-server на основание имени хоста. Чтобы он правильно определил, куда и как проксировать, меняем запись в /etc/hosts:

127.0.0.1 SERVER_NAME

2.2. Установка memcached сервера

Устанавливаем memcached сервер:

/opt/webdir/bin/bx-mc -a create -s SERVER_NAME

Тут про адрес при копировании можно не задумываться, т.к. сервис слушает все и доступ ограничивается настройками iptables/firewalld.


3. Удаление настроек пула

Если машина в пуле одна, то это стоит сделать хотя бы для того, чтобы на новой машине создать заново ssh-ключи и другие настройки безопасности.

Если в пуле несколько машин, то не рекомендуется оставлять настройки пула при копирование, т.к. в пуле существуют механизмы распознавания смены адреса и новая машина может взять на себя обязанности мастера.

Для этого нужно удалить файлы и каталоги конфигурации для ansible:

rm -rf /etc/ansible/{host_vars,group_vars,hosts,ansible-roles}

Или выполнить команду ansible:

/opt/webdir/bin/wrapper_ansible_conf -a delete_pool

4. Дополнительные очистки

Удаляем правила Udev для интерфейсов:

/bin/rm -f /etc/udev/rules.d/70*

Очищаем записи MAC-адресов и UUID устройств:

/bin/sed -i ‘/^(HWADDR|UUID)=/d’ /etc/sysconfig/network-scripts/ifcfg-eth0

Удаляем ssh-ключи. При старте новая машина создаст для себя новые ключи:

/bin/rm –f /etc/ssh/*key*

Очищаем логи сценариев:

/bin/rm -fr /opt/webdir/temp/*
/bin/rm -fr /opt/webdir/logs/*

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

Если копия (образ) делается для бэкапа и воссоздание из нее будет всегда той же самой машины, т.е. нет смены адреса, нет смены ключей, пул остается там, где был, то можно не выполнять вышеописанные действия.


Автоматическая настройка готового образа виртуальной машины (рекомендуется)

Можно настраивать чистый образ автоматически. Для этого просто добавьте приведенные выше команды в свой сценарий или bash-скрипт:

# создание пула
/opt/webdir/bin/wrapper_ansible_conf -a create -H SERVER_NAME -I NET_INTERFACE

# настройка пуш-сервера
/opt/webdir/bin/bx-sites -a push_configure_nodejs -H  SERVER_NAME

# настройка memcached сервиса
/opt/webdir/bin/bx-mc -a create -s SERVER_NAME

Вы получаете работоспособную установку без необходимости решать проблемы смены адреса при копировании шаблона.

Каждый запуск – это будет фоновое задание, статус которого можно отслеживать, как показано выше.



Установка БУС/КП на другие окружения

В главе описаны настройки, необходимые для установки продуктов 1С-Битрикс: Управление сайтом и 1С-Битрикс24 коробочная версия на другие окружения.

Внимание! Для операций, описанных в данной главе, необходимы начальные знания серверного администрирования. Так как инсталяция на другие окружения оттестирована вендором, но не является основной платформой для эксплуатации продуктов Bitrix Framework, то возможны незадокументированные сложности в установке. Вы должны понимать суть действий, осуществляемых вами в системе при установке продуктов.

Дополнительно

Настройка окружения для Debian 11

В главе описаны настройки окружения для операционной системы Debian 11 для установки на неё продуктов "1С-Битрикс24 (коробочная версия)" и "1С-Битрикс: Управление сайтом". Рассмотрена установка и настройка самой операционной системы, установка необходимых пакетов и конфигурация сервисов.

Внимание! Для операций, описанных в данной главе, необходимы начальные знания серверного администрирования. Так как инсталяция на другие окружения оттестирована вендором, но не является основной платформой для эксплуатации продуктов Bitrix Framework, то возможны незадокументированные сложности в установке. Вы должны понимать суть действий, осуществляемых вами в системе при установке продуктов.

Установка и настройка ОС

Установка

Установку необходимо выполнять с диска с минимальным набором ПО, остальное будет установлено по сети во время настройки.

В процессе установки выберите сервер с минимальной настройкой, в противном случае получите декстоп. Дальнейшая настройка будет показана на базе такой установки.

В качестве менеджера пакетов используется apt/apt-get. Обновите систему до последней стабильной версии. Отключите selinux:

su -
apt update && apt upgrade
echo 'SELINUX=disabled' > /etc/selinux/config
reboot

Настройка портов

Обязательно нужно открыть порты:

  • 22 – ssh доступ;
  • 80 / 443 – http / https web-сервер;

Остальные порты для:

  • ntlm
  • сервера мгновенных сообщений;
  • xmpp-сервера

нужно открывать, если только они используются. Можно выбрать произвольные порты, а можно те же, что используются в CentOS:

  • 8890 / 8891 – http/https ntlm;
  • 8893 / 8894 – http/https сервер мгновенных сообщений;
  • 5222 / 5223 – http/https.

Установка пакетов

Ниже приведен весь список пакетов, который нам понадобится для "1С-Битрикс24 коробочная версия". Для "1С-Битрикс: Управление сайтом" не нужен только push-server.

В дефолтном репозитории нет PHP 8.0, но есть сторонние, которые позволяют поставить необходимое ПО.

apt install -y lsb-release ca-certificates apt-transport-https software-properties-common gnupg2

Используйте репозиторий: packages.sury.org.

Настройте репозиторий, симпортируйте ключ репозитория, обновите список пакетов:

echo "deb https://packages.sury.org/php/ $(lsb_release -sc) main" | \
    sudo tee /etc/apt/sources.list.d/sury-php.list

wget -qO - https://packages.sury.org/php/apt.gpg | \
    sudo apt-key add -

apt update

Установите apache 2.4 и php 8.0:

# apt install apache2 -y

# apt install php8.0 php8.0-cli \
    php8.0-common php8.0-gd php8.0-ldap \
    php8.0-mbstring php8.0-mysql \
    php8.0-opcache \
    php-pear php8.0-apcu php-geoip \
    php8.0-mcrypt php8.0-memcache\
    php8.0-zip php8.0-pspell php8.0-xml -y

Установите nginx (1.18 версия):

apt install nginx -y

Установите MariaDB сервер (10.5 версия):

apt -y install mariadb-server mariadb-common

Установите node и npm (push-server) - 12.22:

apt install nodejs npm -y

Установите redis - 6.0:

apt install redis -y

Конфигурация Nginx

Рабочий каталог для сайта - /var/www/html/bx-site. Пользователь для web окружения - nginx, группа apache.

Конфигурация Nginx сервера:

/etc/nginx/nginx.conf                                       # основной конфигурационный файл
            |_conf.d/upstreams.conf                         # конфигурация для upstream серверов: apache && push-server
            |_conf.d/maps-composite_settings.conf           # параменные используемые для кеша
            |_conf.d/maps.conf                              # дополнительные переменные
            |_conf.d/http-add_header.conf                   # CORS заголовки
            |_sites-available/*.conf                        # подключаем сайты
                              |_default.conf                # сайт по умолчанию (настраиваем только 80 порт)
                                    |_conf.d/bx_temp.conf   # конфигурация BX_TEMPORARY_FILES_DIRECTORY
                                    |_conf.d/bitrix.conf    # дефолтная конфигурация сайта
                              |_rtc.conf                    # проксирование запросов на push-server (публикация)

Дефолтная конфигурация сайта:

conf.d/bitrix.conf                                          # основный блоки со включенным по умолчанию кешем в файлах
        |_conf.d/bitrix_general.conf                        # отдача статики, быстрая отдача для внешних хранилищ и прочее
                |_conf.d/errors.conf                        # обработка ошибок
                |_conf.d/im_subscrider.conf                 # проксирование запросов на push-server (получение)
                |_conf.d/bitrix_block.conf                  # блокировки по умолчанию

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

Все конфигурационные файлы можно скачать в архиве.

su -
rsync -av debian/nginx/ /etc/nginx/

В сервисе используются имена для проксирования на определенные службы:

  • httpd - проксирование запросов на apache,
  • push - проксирование запросов на push-server.

Чтобы заработала конфигурация, необходимо прописать службы в локальных адресах. Если сервисы расположены на другом хосте, то укажите здесь правильный адрес.

echo "127.0.0.1 push httpd" >> /etc/hosts

По умолчанию в Debian Apache2 сервер использует 80 порт и поставлен на автозапуск. Поэтому перед запуском nginx сервера, на время выключите Apache2 (на данный момент он еще не настроен). Остановите Apache2:

systemctl stop apache2

Запустите Nginx:

systemctl --now enable nginx

Конфигурация PHP

В данной версии установки централизованное хранилище конфигов:

/etc/php/8.0
|---- apache2
|       |-> conf.d/
|       |-> php.ini
|---- cli
|       |-> conf.d/
|       |-> php.ini
|---- mods-available
        |-> .ini

Файлы conf.d внутри каталогов /apache2 и /cli содержат ссылки на mods-available. То есть в дефолтной конфигурации и модуль apache2 и командная строка будут содержать одинаковый набор модулей с одинаковыми параметрами.

Добавьте настройки для следующих опций:

  • для модуля opcache:
    opcache.max_accelerated_files = 100000
    opcache.revalidate_freq = 0
  • настройки bitrexenv.ini:
    display_errors = Off
    error_reporting = E_ALL
    error_log = '/var/log/php/error.log'
    
    ; Set some more PHP parameters
    enable_dl = Off
    short_open_tag = On
    allow_url_fopen = On
    
    # Security headers
    mail.add_x_header = Off
    expose_php = Off
    ...

Конфигурационные файлы для PHP расположены в папке debian/php.d.

su -
rsync -av debian/php.d/ /etc/php/8.0/mods-available/

 ln -sf /etc/php/8.0/mods-available/zbx-bitrix.ini  /etc/php/8.0/apache2/conf.d/99-bitrix.ini
 ln -sf /etc/php/8.0/mods-available/zbx-bitrix.ini  /etc/php/8.0/cli/conf.d/99-bitrix.ini

Конфигурация Apache

По умолчанию конфигурация Apache устроена следующим образом:

#   /etc/apache2/
#   |-- apache2.conf
#   |   `--  ports.conf
#   |-- mods-enabled
#   |   |-- *.load
#   |   `-- *.conf
#   |-- conf-enabled
#   |   `-- *.conf
#   `-- sites-enabled
#       |-- 000-default.conf
#       `-- *.conf

Основное, что нужно изменить:

  • каталог для сайта /var/www/html/bx-site,
  • порт, который слушает сервис (так как в качестве внешнего сервиса используется nginx)
  • для сайта импортируйте настройки из виртуальной машины 000-default.conf.

Примечание: В дефолтной конфигурации /sites-enabled/000-default.conf - это ссылка на файл в каталоге /sites-available.

Конфигурационные файлы для apache можно найти в папке debian/apache2.

su -
rsync -av debian/apache2/ /etc/apache2/

Настройте следующие файлы:

  • ports.conf - смена Listen на 8090
  • sites-available/000-default.conf - настройки сайта

Отключите листинг каталогов в Apache:

a2dismod --force autoindex

Включите модуль rewrite:

a2enmod rewrite

Запустите сервис:

systemctl --now enable apache2

Конфигурация MariaDB

Что нужно добавить:

  • transaction-isolation поменять в READ-COMMITTED.
  • innodb_flush_method желательно должно быть равным O_DIRECT
  • innodb_flush_log_at_trx_commit желательно должно быть равным 2.

Конфигурационные файлы для БД расположены в папке debian/mysql .

su -
rsync -av debian/mysql/ /etc/mysql/

Измените следующие файлы:

  • my.cnf - добавляем загрузку настроек из каталога /etc/mysql/my-bx.d/,
  • my-bx.d/zbx-custom.cnf - сюда прописываем настройки, указанные выше.

Запустите сервис:

systemctl --now enable mariadb

systemctl restart mariadb

Настройте сервис через mysql_secure_installation:

mysql_secure_installation
...
Switch to unix_socket authentication [Y/n] n
 ... skipping.

Change the root password? [Y/n] y
New password:
Re-enter new password:
Password updated successfully!
Reloading privilege tables..
 ... Success!

Remove anonymous users? [Y/n] y
 ... Success!

Disallow root login remotely? [Y/n] y
 ... Success!

Конфигурация Redis

Данный сервис необходим для организации push-server.

Основное, что важно в конфигурационном файле:

  • включение файлового сокета для работы,
  • отключение сброса данных на диск (для работы push-server нам не нужна эта возможность),
  • группа пользователя.

Конфигурационные файлы для redis можно найти в папке debian/redis.

su -
rsync -av debian/redis/redis.conf /etc/redis/redis.conf
usermod -g www-data redis
chown root:www-data /etc/redis/ /var/log/redis/
[[ ! -d /etc/systemd/system/redis.service.d ]] && mkdir /etc/systemd/system/redis.service.d
echo -e '[Service]\nGroup=www-data' > /etc/systemd/system/redis.service.d/custom.conf
systemctl daemon-reload

Запустите сервис

systemctl enable redis-server.service
systemctl restart redis-server.service

Конфигурация push-server

Схема работы:

 -----------------------                                   ---------------------------------------------------
| nginx: 0.0.0.0:80     | -> /bitrix/sub|/bitrix/subws -> | node server.js --config push-server-sub-80XX.json |
 -----------------------                                   ---------------------------------------------------

 -----------------------                     ---------------------------------------------------
| nginx: 127.0.0.1:8895 | -> /bitrix/pub -> | node server.js --config push-server-pub-90XX.json |
 -----------------------                     ---------------------------------------------------

Nginx проксирует запрос на push-сервис выбранного типа. Запросы получения сообщений (например, sub) - публичные и проксируются со стандартных портов 80/443, запросы публикации (pub) доступны только с внутреннего адреса сервера.

Nodejs-процессы делятся на два типа:

  • процессы, отвечающие за подключение пользователя к выбранному каналу и получение им сообщений: слушают порты 8010-8015,
  • процессы, отвечающие за отправку сообщения в канал: слушают порты 9010-9011.

Для запуска push-server понадобится:

  • nodejs && npm,
  • архив сервиса и его модулей.

Скачайте архив:

su -
cd /opt
wget https://repo.bitrix.info/vm/push-server-0.3.0.tgz
npm install --production ./push-server-0.3.0.tgz

Установка должна закончиться строкой:

added 1 package, and audited 145 packages in 13s

16 packages are looking for funding
  run `npm fund` for details

Для удобства можно сделать так:

ln -sf /opt/node_modules/push-server/etc/push-server /etc/push-server

Скопируйте файлы сервиса и основной конфигурационный сайт:

su - 
cd /opt/node_modules/push-server
cp etc/init.d/push-server-multi /usr/local/bin/push-server-multi
mkdir /etc/sysconfig
cp etc/sysconfig/push-server-multi  /etc/sysconfig/push-server-multi
cp etc/push-server/push-server.service  /etc/systemd/system/
ln -sf /opt/node_modules/push-server /opt/push-server

Отредактируйте конфигурационный файл /etc/sysconfig/push-server-multi. Исправьте/добавьте параметры:

  • SECURITY_KEY - секретный ключ для подписи соединения между клиентом и push-сервером,
  • RUN_DIR - используется для хранения pid файлов процесса,
  • USER/GROUP - пользователь, под которым будет запущен сервис,
  • REDIS_SOCK - сокет, который использует Redis сервис.

Пример:

GROUP=www-data
SECURITY_KEY="PUTTHEPRIVATEKEYHERE"
RUN_DIR=/tmp/push-server
REDIS_SOCK=/var/run/redis/redis.sock

Создайте пользователя:

useradd -g www-data bitrix

Каждый nodejs процесс будет запущен как отдельный процесс. Сгенерируйте конфигурационные файлы:

/usr/local/bin/push-server-multi configs pub
/usr/local/bin/push-server-multi configs sub

Создайте каталог через tmpfiles.d.

echo 'd /tmp/push-server 0770 bitrix www-data -' > /etc/tmpfiles.d/push-server.conf
systemd-tmpfiles --remove --create

Создайте каталог логов:

[[ ! -d /var/log/push-server ]] && mkdir /var/log/push-server
chown bitrix:www-data /var/log/push-server

Изменяйте пользователя в конфигурационном файле сервиса /etc/systemd/system/push-server.service:

[Service]
User=bitrix
Group=www-data
ExecStart=/usr/local/bin/push-server-multi systemd_start
ExecStop=/usr/local/bin/push-server-multi stop
...

Переконфигурируйте файл:

systemctl daemon-reload

Запустите сервис

systemctl --now enable push-server

Перейдите в конфигурацию push-модуля (настройки сайта), включите использование локального push-сервера (последняя версия). Дополнительно нужно указать секретный ключ, который настраивали в файле /etc/sysconfig/push-server-multi.


Конфигурация сайта

  Сайт

Создайте рабочий каталог:

mkdir /var/www/html/bx-site
cd /var/www/html/bx-site
wget https://www.1c-bitrix.ru/download/scripts/bitrixsetup.php
chown www-data:www-data /var/www/html/bx-site -R

Аналогичным образом скачайте нужный дистрибутив и установите его в каталог: /var/www/html/bx-site.

Создайте базу данных и пользователя:

create database portal;
CREATE USER 'bitrix'@'localhost' IDENTIFIED BY 'PASSWORD';
GRANT ALL PRIVILEGES ON portal.* to 'bitrix'@'localhost';

Необходимо заменить PASSWORD на пароль, который будет использоваться для доступа к БД.

  Push-server

Для работы портала необходимо настроить push-server. Настройки могут быть выполнены через [dw]административный раздел портала[/dw][di]Настройки производятся на странице http://_имя_сайта_/bitrix/admin/settings.php?lang=ru&mid=pull

Нажмите на рисунок, чтобы увеличить

Подробнее...[/di], а можно добавить их в конфигурационный файл. Покажем как это делается вторым способом.

Исправьте конфигурационный файл /var/www/html/bx-site/bitrix/.settings.php, добавив следующую секцию:

return array (
'pull' => Array(
    'value' =>  array(
        'path_to_listener' => 'http://#DOMAIN#/bitrix/sub/',
        'path_to_listener_secure' => 'https://#DOMAIN#/bitrix/sub/',
        'path_to_modern_listener' => 'http://#DOMAIN#/bitrix/sub/',
        'path_to_modern_listener_secure' => 'https://#DOMAIN#/bitrix/sub/',
        'path_to_mobile_listener' => 'http://#DOMAIN#:8893/bitrix/sub/',
        'path_to_mobile_listener_secure' => 'https://#DOMAIN#:8894/bitrix/sub/',
        'path_to_websocket' => 'ws://#DOMAIN#/bitrix/subws/',
        'path_to_websocket_secure' => 'wss://#DOMAIN#/bitrix/subws/',
	'path_to_publish' => 'http://localhost:8895/bitrix/pub/',
        'path_to_publish_web' => 'http://#DOMAIN#/bitrix/rest/',
        'path_to_publish_web_secure' => 'https://#DOMAIN#/bitrix/rest/',
        'nginx_version' => '4',
        'nginx_command_per_hit' => '100',
        'nginx' => 'Y',
        'nginx_headers' => 'N',
        'push' => 'Y',
        'websocket' => 'Y',
        'signature_key' => 'PUTTHEPRIVATEKEYHERE',
        'signature_algo' => 'sha1',
        'guest' => 'N',
    ),
),
...
Внимание! signature_key должен содержать тот же ключ, который указан в /etc/sysconfig/push-server-multi в соответствующем ключе. Если все хорошо, то после перезапуска службы httpd:
systemctl restart apache2

Вы увидите запросы к push-server:

Request URL: ws://sitename/bitrix/subws/?CHANNEL_ID=....
Request Method: GET
Status Code: 101 Switching Protocols

Настройка окружения для Astra 1.7

В главе описаны настройки окружения для операционной системы Astra 1.7 для установки на неё продуктов "1С-Битрикс24 (коробочная версия)" и "1С-Битрикс: Управление сайтом". Рассмотрена установка и настройка самой операционной системы, установка необходимых пакетов и конфигурация сервисов.

Внимание! Для операций, описанных в данной главе, необходимы начальные знания серверного администрирования. Так как инсталяция на другие окружения оттестирована вендором, но не является основной платформой для эксплуатации продуктов Bitrix Framework, то возможны незадокументированные сложности в установке. Вы должны понимать суть действий, осуществляемых вами в системе при установке продуктов.

Установка и настройка ОС

Установка

Установку можно выполнять с диска с минимальным набором ПО, остальное будет установлено по сети во время настройки.

В процессе установки выбираем сервер с минимальной настройкой, в противном случае получим декстоп. Дальнейшая настройка будет показана на базе такой установки.

В качестве менеджера пакетов используется apt/apt-get. Обновляем систему до последней стабильной версии.

Настройка портов

Обязательно нужно открыть порты:

  • 22 – ssh доступ;
  • 80 / 443 – http / https web-сервер;

Остальные порты для:

  • ntlm
  • сервера мгновенных сообщений;
  • xmpp-сервера

нужно открывать, если только они используются. Можно выбрать произвольные порты, а можно те же, что используются в CentOS:

  • 8890 / 8891 – http/https ntlm;
  • 8893 / 8894 – http/https сервер мгновенных сообщений;
  • 5222 / 5223 – http/https.

Установка пакетов

Весь список пакетов, который нам понадобится для работы "Битрикс24" (для "1С-Битрикс: Управление сайтом" push сервер не нужен.):

  • mariadb
  • PHP
  • Apache
  • nginx
  • push-server
  • redis

mariadb

Подключите репозитории в файле /etc/apt/sources.list, добавив запись вида:

# Основной репозиторий
deb https://dl.astralinux.ru/astra/stable/1.7_x86-64/repository-main/
1.7_x86-64 main contrib non-free
# Оперативные обновления основного репозитория
deb https://dl.astralinux.ru/astra/stable/1.7_x86-64/repository-update/
1.7_x86-64 main contrib non-free
# Базовый репозиторий
deb https://dl.astralinux.ru/astra/stable/1.7_x86-64/repository-base/
1.7_x86-64 main contrib non-free
# Расширенный репозиторий
deb https://dl.astralinux.ru/astra/stable/1.7_x86-64/repository-extended/
1.7_x86-64 main contrib non-free
# Расширенный репозиторий (компонент astra-ce)
deb https://dl.astralinux.ru/astra/stable/1.7_x86-64/repository-extended/
1.7_x86-64 astra-ce

Обновитесь:

apt update && apt upgrade

Установите необходимые пакеты:

apt install mariadb-server mariadb-client

PHP и Apache

Для начала уставите apache2:

apt install apache2 apache2-dev

Рекомендуется использовать PHP 8.0. В дефолтном репозитории его нет и необходимо собрать его самостоятельно.

apt install -y lsb-release ca-certificates apt-transport-https software-properties-common gnupg2 \
    autoconf build-essential curl libtool libssl-dev libcurl4-openssl-dev libxml2-dev libreadline7 \
    libreadline-dev libzip-dev libzip4 \
    openssl pkg-config zlib1g-dev libsqlite3-dev sqlite3 libonig-dev \
    libpq-dev git autoconf bison re2c libpng-dev libldap2-dev \
    libfreetype6-dev libfreetype6 libjpeg-dev libxslt1-dev

Скачайте исходники:

cd /usr/local/src
wget https://www.php.net/distributions/php-8.0.23.tar.gz
cd php-8.0.23

./configure \
        --prefix=/usr \
        --with-config-file-path=/etc/php/8.0 \
        --sysconfdir=/etc/php/8.0 \
        --enable-mysqlnd \
        --with-pdo-mysql \
        --with-pdo-mysql=mysqlnd \
        --enable-bcmath \
        --enable-cli \
        --with-apxs2=/usr/bin/apxs2 \
        --with-fpm-user=www-data \
        --with-fpm-group=www-data \
        --enable-mbstring \
        --enable-phpdbg \
        --enable-shmop \
        --enable-sockets \
        --enable-sysvmsg \
        --enable-sysvsem \
        --enable-sysvshm \
        --with-zlib \
        --with-curl \
        --with-pear \
        --with-openssl \
        --enable-pcntl \
        --enable-gd \
        --with-jpeg \
        --with-mysqli \
        --with-readline \
        --with-freetype \
        --enable-session \
        --with-xsl \
        --with-openssl \
        --enable-opcache

make

make test

make install

cp php.ini-development /etc/php/8.0/php.ini

nginx

Установите nginx (1.18 версия)

apt install nginx -y

push-server

Установите node и npm (push-server) - 12.22

apt install nodejs npm -y

redis

Установите redis - 6.0

apt install redis -y

Конфигурация Nginx

Рабочий каталог для сайта - /var/www/html/bx-site. Пользователь для web окружения - nginx, группа apache.

Конфигурация nginx сервера:

/etc/nginx/nginx.conf                                       # основной конфигурационный файл
            |_conf.d/upstreams.conf                         # конфигурация для upstream серверов: apache && push-server
            |_conf.d/maps-composite_settings.conf           # параменные используемые для кеша
            |_conf.d/maps.conf                              # дополнительные переменные
            |_conf.d/http-add_header.conf                   # CORS заголовки
            |_sites-available/*.conf                        # подключаем сайты
                              |_default.conf                # сайт по умолчанию (настраиваем только 80 порт)
                                    |_conf.d/bx_temp.conf   # конфигурация BX_TEMPORARY_FILES_DIRECTORY
                                    |_conf.d/bitrix.conf    # дефолтная конфигурация сайта
                              |_rtc.conf                    # проксирование запросов на push-server (публикация)

Дефолтная конфигурация сайта:

conf.d/bitrix.conf                                          # основный блоки со включенным по умолчанию кешем в файлах
        |_conf.d/bitrix_general.conf                        # отдача статики, быстрая отдача для внешних хранилищ и прочее
                |_conf.d/errors.conf                        # обработка ошибок
                |_conf.d/im_subscrider.conf                 # проксирование запросов на push-server (получение)
                |_conf.d/bitrix_block.conf                  # блокировки по умолчанию

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

Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для Nginx размещены в папке astra/nginx

rsync -av astra/nginx/ /etc/nginx/

В сервисе используются имена для проксирования на определенные службы:

  • httpd - проксирование запросов на apache,
  • push - проксирование запросов на push-server. Чтобы заработала конфигурация, необходимо прописать их в локальных адресах. Если сервисы расположены на другом хосте, указываем здесь правильный адрес.
echo "127.0.0.1 push httpd" >> /etc/hosts

По умолчанию в Astra Apache2 сервер использует 80 порт и поставлен в автозапуск. Поэтому перед запуском nginx сервера, мы на время выключаем apache2 (мы его еще не настраивали). Останавливаем apache2:

systemctl stop apache2

Запустите Nginx

systemctl --now enable nginx

Конфигурация PHP

В данной версии установки централизованное хранилище конфигов:

/etc/php/8.0
|       |-> php.ini

Как минимум, нам нужно добавить настройки для следующих опций:

  • для модуля opcache
    opcache.max_accelerated_files = 100000
    opcache.revalidate_freq = 0
  • добавляем настройки bitrexenv.ini
    display_errors = Off
    error_reporting = E_ALL
    error_log = '/var/log/php/error.log'
    
    ; Set some more PHP parameters
    enable_dl = Off
    short_open_tag = On
    allow_url_fopen = On
    
    # Security headers
    mail.add_x_header = Off
    expose_php = Off
    ...
    

Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для PHP размещены в папке astra/php.d

su -
cd bx-os/astra

# добавляем конфиг для opcache
cat ./php.d/opcache.ini  >> /etc/php/8.0/php.ini

# остальные настройки
cat ./php.d/zbx-bitrix.ini  >> /etc/php/8.0/php.ini

# создаем каталог для логов
mkdir /var/log/php
chown www-data:www-data /var/log/php

Конфигурация Apache

По умолчанию конфигурация Apache устроена следующим образом:

#   /etc/apache2/
#   |-- apache2.conf
#   |   `--  ports.conf
#   |-- mods-enabled
#   |   |-- *.load
#   |   `-- *.conf
#   |-- conf-enabled
#   |   `-- *.conf
#   `-- sites-enabled
#       |-- 000-default.conf
#       `-- *.conf

Основное, что нужно изменить:

  • каталог для сайта /var/www/html/bx-site,
  • порт, который слушает сервис (так как в качестве внешнего сервиса используем nginx),
  • для сайта импортируем настройки из виртуальной машины 000-default.conf. Замечание: В дефолтной конфигурации sites-enabled/000-default.conf - это ссылка на файл в каталоге /sites-available.

Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для Apache размещены в папке astra/apache2

rsync -av astra/apache2/ /etc/apache2/

Настройте следующие файлы:

  • ports.conf - смена Listen на 8090
  • sites-available/000-default.conf - настройки сайта
  • mods-available/php.conf - конфгурация php модуля
  • apache2/apache2.conf - выключаем AstraMode

Отключите листинг каталогов в Apache:

a2dismod --force autoindex

Включите модуль rewrite:

a2enmod rewrite

Включите php модуль:

a2enmod php

Запустите сервис:

systemctl --now enable apache2

Конфигурация MariaDB

Необходимые настройки:

  • transaction-isolation измените в READ-COMMITTED.
  • innodb_flush_method желательно должно быть равным O_DIRECT
  • innodb_flush_log_at_trx_commit желательно должно быть равным 2.

Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для MariaDB размещены в папке astra/my.cnf.d

su -
rsync -av astra/mysql/ /etc/mysql/

Измените следующие файлы:

  • my.cnf - добавьте загрузку настроек из каталога /etc/mysql/my-bx.d/;
  • my-bx.d/zbx-custom.cnf - пропишите настройки, указанные выше.

Запустите сервис:

systemctl --now enable mariadb

systemctl restart mariadb

Настройте сервис через mysql_secure_installation.

mysql_secure_installation
...
Switch to unix_socket authentication [Y/n] n
 ... skipping.

Change the root password? [Y/n] y
New password:
Re-enter new password:
Password updated successfully!
Reloading privilege tables..
 ... Success!

Remove anonymous users? [Y/n] y
 ... Success!

Disallow root login remotely? [Y/n] y
 ... Success!

Конфигурация Redis

Данный сервис необходим для организации работы push-server.

Основное, что важно в конфиге:

  • включение файлового сокета для работы;
  • отключение сброса данных на диск (для работы push-server нам не нужна эта возможность);
  • группа пользователя.

Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для Redis размещены в папке astra/redis

su -
rsync -av astra/redis/redis.conf /etc/redis/redis.conf
usermod -g www-data redis
chown root:www-data /etc/redis/ /var/log/redis/
[[ ! -d /etc/systemd/system/redis-server.service.d ]] && mkdir /etc/systemd/system/redis-server.service.d
echo -e '[Service]\nGroup=www-data' > /etc/systemd/system/redis-server.service.d/custom.conf
systemctl daemon-reload

Запустите сервис:

systemctl enable redis-server.service
systemctl restart redis-server.service

Конфигурация push-server

Схема работы:

 -----------------------                                   ---------------------------------------------------
| nginx: 0.0.0.0:80     | -> /bitrix/sub|/bitrix/subws -> | node server.js --config push-server-sub-80XX.json |
 -----------------------                                   ---------------------------------------------------

 -----------------------                     ---------------------------------------------------
| nginx: 127.0.0.1:8895 | -> /bitrix/pub -> | node server.js --config push-server-pub-90XX.json |
 -----------------------                     ---------------------------------------------------

Nginx проксирует запрос на push-сервис выбранного типа. Запросы получения сообщений (например, sub) - публичные и проксируются со стандартных портов 80/443, запросы публикации (pub) доступны только с внутреннего адреса сервера.

Процессы Nodejs делятся на два типа:

  • Отвечающие за подключение пользователя к выбранному каналу и получение им сообщений. Они слушают порты 8010-8015
  • Отвечающие за отправку сообщения в канал. Они слушают порты 9010-9011.

Для запуска push-server понадобится:

  • nodejs и npm,
  • архив сервиса и его модулей.

Скачайте архив:

su -
cd /opt
wget https://repo.bitrix.info/vm/push-server-0.3.0.tgz
npm install --production ./push-server-0.3.0.tgz

Установка закончится строкой:

added 1 package, and audited 145 packages in 13s

16 packages are looking for funding
  run `npm fund` for details

Для удобства можно использовать:

ln -sf /opt/node_modules/push-server/etc/push-server /etc/push-server

Скопируйте файлы сервиса и основной конфиг:

su - 
cd /opt/node_modules/push-server
cp etc/init.d/push-server-multi /usr/local/bin/push-server-multi
mkdir /etc/sysconfig
cp etc/sysconfig/push-server-multi  /etc/sysconfig/push-server-multi
cp etc/push-server/push-server.service  /etc/systemd/system/
ln -sf /opt/node_modules/push-server /opt/push-server

Редактируйте конфигурационный файл /etc/sysconfig/push-server-multi. Нужно исправить/добавить параметры:

  • SECURITY_KEY - cекретный ключ для подписи соединения между клиентом и пуш-сервером,
  • RUN_DIR - используется для хранения pid файлов процесса,
  • USER/GROUP - пользователь, под которым будет запущен сервис,
  • REDIS_SOCK - сокет, который использует Redis сервис.

Пример

GROUP=www-data
SECURITY_KEY="PUTTHEPRIVATEKEYHERE"
RUN_DIR=/tmp/push-server
REDIS_SOCK=/var/run/redis/redis.sock

Создайте пользователя:

useradd -g www-data bitrix

Каждый nodejs процесс будет запущен как отдельный процесс. Сгенерируйте конфиги:

/usr/local/bin/push-server-multi configs pub
/usr/local/bin/push-server-multi configs sub

Создайте каталог через tmpfiles.d.

echo 'd /tmp/push-server 0770 bitrix www-data -' > /etc/tmpfiles.d/push-server.conf
systemd-tmpfiles --remove --create

Создайте каталог логов:

[[ ! -d /var/log/push-server ]] && mkdir /var/log/push-server
chown bitrix:www-data /var/log/push-server

Измените пользователя в конфигурационном файле сервиса /etc/systemd/system/push-server.service:

[Service]
User=bitrix
Group=www-data
ExecStart=/usr/local/bin/push-server-multi systemd_start
ExecStop=/usr/local/bin/push-server-multi stop
...

Переконфигурируйте

systemctl daemon-reload

и затем запустите сервис:

systemctl --now enable push-server

В [dw]настройках push модуля[/dw][di]Настройки производятся на странице http://_имя_сайта_/bitrix/admin/settings.php?lang=ru&mid=pull

Нажмите на рисунок, чтобы увеличить

Подробнее...[/di] в административном разделе сайта включите использование [dw]локального пуш сервера (последняя версия)[/dw][di]Нажмите на рисунок, чтобы увеличить.[/di]. Дополнительно нужно будет указать секретный ключ, который вы настраивали в файле /etc/sysconfig/push-server.


Конфигурация сайта

Сайт

  1. Создайте рабочий каталог:
    mkdir /var/www/html/bx-site
    cd /var/www/html/bx-site
    wget https://www.1c-bitrix.ru/download/scripts/bitrixsetup.php
    chown www-data:www-data /var/www/html/bx-site -R
    Аналогичным образом можно скачать нужный дистрибутив и установить его в каталог: /var/www/html/bx-site.
  2. Создайте базу данных и пользователя:
    create database portal;
    CREATE USER 'bitrix'@'localhost' IDENTIFIED BY 'PASSWORD';
    GRANT ALL PRIVILEGES ON portal.\* to 'bitrix'@'localhost';
    Необходимо заменить PASSWORD на пароль, который будете использовать для доступа к БД.
  3. Перейдите в http и откройте страницу: http://IP_ADDRESS/bitrixsetup.php. В качестве сервера БД используйте следующие настройки:
            'host' => '127.0.0.1',
            'database' => 'portal',
            'login' => 'bitrix',
            'password' => 'PASSWORD'

    Пароль измените на тот, который вводили на этапе создания аккаунта.

Push-server

Для работы портала необходимо настроить push-server. Настройки могут быть выполнены через [dw]административный раздел портала[/dw][di]Настройки производятся на странице http://_имя_сайта_/bitrix/admin/settings.php?lang=ru&mid=pull

Нажмите на рисунок, чтобы увеличить

Подробнее...[/di], а можно добавить их в конфигурационный файл. Покажем как это делается вторым способом.

Исправьте конфигурационный файл /var/www/html/bx-site/bitrix/.settings.php, добавив следующую секцию:

return array (
'pull' => Array(
    'value' =>  array(
        'path_to_listener' => 'http://#DOMAIN#/bitrix/sub/',
        'path_to_listener_secure' => 'https://#DOMAIN#/bitrix/sub/',
        'path_to_modern_listener' => 'http://#DOMAIN#/bitrix/sub/',
        'path_to_modern_listener_secure' => 'https://#DOMAIN#/bitrix/sub/',
        'path_to_mobile_listener' => 'http://#DOMAIN#:8893/bitrix/sub/',
        'path_to_mobile_listener_secure' => 'https://#DOMAIN#:8894/bitrix/sub/',
        'path_to_websocket' => 'ws://#DOMAIN#/bitrix/subws/',
        'path_to_websocket_secure' => 'wss://#DOMAIN#/bitrix/subws/',
        'path_to_publish' => 'http://localhost:8895/bitrix/pub/',
        'path_to_publish_web' => 'http://#DOMAIN#/bitrix/rest/',
        'path_to_publish_web_secure' => 'https://#DOMAIN#/bitrix/rest/',
        'nginx_version' => '4',
        'nginx_command_per_hit' => '100',
        'nginx' => 'Y',
        'nginx_headers' => 'N',
        'push' => 'Y',
        'websocket' => 'Y',
        'signature_key' => 'PUTTHEPRIVATEKEYHERE',
        'signature_algo' => 'sha1',
        'guest' => 'N',
    ),
),
...
Обратите внимание: signature_key должен содержать тот же ключ, который был указан в /etc/sysconfig/push-server-multi в соответствующем ключе. Если все хорошо, то после перезапуска httpd:
systemctl restart httpd2

Вы увидите запросы к push-server:

Request URL: ws://sitename/bitrix/subws/?CHANNEL_ID=....
Request Method: GET
Status Code: 101 Switching Protocols


Настройка окружения для SLES 15

В главе описаны настройки окружения для операционной системы SUSE Linux Enterprise Server 15 для установки на неё продуктов 1С-Битрикс24 коробочная версия и 1С-Битрикс: Управление сайтом. Рассмотрена установка и настройка самой операционной системы, установка необходимых пакетов и конфигурация сервисов.

Внимание! Для операций, описанных в данной главе, необходимы начальные знания серверного администрирования. Так как инсталяция на другие окружения оттестирована вендором, но не является основной платформой для эксплуатации продуктов Bitrix Framework, то возможны незадокументированные сложности в установке. Вы должны понимать суть действий, осуществляемых вами в системе при установке продуктов.

Установка и настройка ОС

Установка

Начнем с установки дистрибутива SUSE Linux Enterprise Server 15 (SLES 15). В процессе установки доступен выбор дополнительных модулей и расширений. Нам потребуется сервер с минимальной настройкой.

Внимание: Дальнейшая настройка будет показана именно на базе такой установки.

Также потребуется выполнить активацию подписки. Её можно произвести во время установки. Либо настроить уже после установки командой:

SUSEConnect -e EMAIL_ADDRESS -r REGISTER_CODE

Подписка привязывается к аккаунту. Поэтому при активации в качестве email_address и password указывайте те данные, с помощью которых Вы регистрировались на официальном сайте SUSE.

В качестве менеджера пакетов SUSE использует [dw]zypper[/dw][di]Zypper - консольный менеджер пакетов, основанный на библиотеке libzypp, используется в дистрибутиве GNU/Linux openSUSE.[/di].

  1. Обновите систему до последней стабильной версии.
  2. zypper refresh
    zypper update
    
  3. Подключите дополнительные расширения (официальные репозитории) для установки дополнительных пакетов:
  4. # модули python
    SUSEConnect --product sle-module-python2/15.2/x86_64
    # для php и nodejs (push-server)
    SUSEConnect  --product sle-module-web-scripting/15.2/x86_64
    

Все доступные репозитории можно посмотреть c помощью команды:

SUSEConnect --list-extensions

По умолчанию SELinux не устанавливается для минимальной установки, поэтому каких-либо дополнительных настроек для его отключения не требуется.

Настройка портов

Обязательно нужно открыть порты:

  • 22 – ssh доступ;
  • 80 / 443 – http / https web-сервер;

Остальные порты для:

  • ntlm
  • сервера мгновенных сообщений;
  • xmpp-сервера

нужно открывать, если только они используются. Можно выбрать произвольные порты, а можно те же, что используются в CentOS:

  • 8890 / 8891 – http/https ntlm;
  • 8893 / 8894 – http/https сервер мгновенных сообщений;
  • 5222 / 5223 – http/https.

Установка пакетов

Ниже приведен весь список пакетов, который нам понадобится для 1С-Битрикс24 коробочная версия. Для 1С-Битрикс: Управление сайтом из этого набора не нужен только push-server.

Установка по шагам

  1. Установите apache 2.4 и php 7.2:
  2. zypper -n install apache2
    
    zypper -n install php7 php7 php7 \
        php7 php7-opcache php7-zip php7-posix \
        php7-zlib php7-openssl php7-mbstring \
        php7-bz2 php7-curl php7-iconv \
        php7-json php7-pecl php7-devel php7-sockets  \
        php7-gd apache2-mod_php7 php7-mysql
    

    С 01.02.2023 ограничивается поддержка наших продуктов на PHP версии ниже 8.0. Рекомендуемая - 8.1 и выше. Поэтому после установки необходимо обновить PHP до версии не ниже 8.0.

  3. Установите Nginx 1.16:
  4. zypper -n install nginx
    
  5. Установите MariaDB сервер 10.4 :
  6. zypper -n install mariadb
    
  7. Установите Node (версия 14) и npm (push-server):
  8. zypper -n install nodejs10
    
  9. Установите Redis:
  10. zypper -n install redis
    


Конфигурация Nginx

Выполним конфигурацию Nginx.

  • Рабочий каталог для сайта - /var/www/html/bx-site.
  • Пользователь для web окружения - wwwrun.

Конфигурация nginx сервера:

/etc/nginx/nginx.conf                                       # основной конфигурационный файл
            |_conf.d/upstreams.conf                         # конфигурация для upstream серверов: apache && push-server
            |_conf.d/maps-composite_settings.conf           # переменные используемые для кеша
            |_conf.d/maps.conf                              # дополнительные переменные
            |_conf.d/http-add_header.conf                   # CORS заголовки
            |_sites-available/*.conf                        # подключаем сайты
                              |_default.conf                # сайт по умолчанию (настраиваем только 80 порт)
                                    |_conf.d/bx_temp.conf   # конфигурация BX_TEMPORARY_FILES_DIRECTORY
                                    |_conf.d/bitrix.conf    # дефолтная конфигурация сайта
                              |_rtc.conf                    # проксирование запросов на push-server (публикация)

Дефолтная конфигурация сайта:

conf.d/bitrix.conf                                          # основные блоки со включенным по умолчанию кешем в файлах
        |_conf.d/bitrix_general.conf                        # отдача статики, быстрая отдача для внешних хранилищ и прочее
                |_conf.d/errors.conf                        # обработка ошибок
                |_conf.d/im_subscrider.conf                 # проксирование запросов на push-server (получение)
                |_conf.d/bitrix_block.conf                  # блокировки по умолчанию

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

Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для Nginx расположены в папке: sles15/nginx.

Разместите их в директории /etc/nginx/.

В сервисе используются имена для проксирования на определенные службы:

  • httpd - проксирование запросов на apache;
  • push - проксирование запросов на push-server.

Чтобы заработала конфигурация, необходимо прописать их в локальных адресах. Если сервисы расположены на другом хосте, укажите здесь правильный адрес:

echo "127.0.0.1 push httpd" >> /etc/hosts

Запустите сервис:

systemctl --now enable nginx

Добавьте правила для firewalld:

firewall-cmd --zone=public --add-service=https --permanent
firewall-cmd --zone=public --add-service=http --permanent
firewall-cmd --reload


Конфигурация PHP

В данной версии установки хранилище конфигов централизованное: -- /etc/php7/conf.d

Минимально необходимо добавить такие настройки:

  • для модуля OPCache (opcache.ini):
  • opcache.max_accelerated_files = 100000
    opcache.revalidate_freq = 0
    
  • добавляем настройки в файл zx-bitrix.ini:
  • display_errors = Off
    error_reporting = E_ALL
    error_log = '/var/log/php/error.log'
    
    ; Set some more PHP parameters
    enable_dl = Off
    short_open_tag = On
    allow_url_fopen = On
    
    # Security headers
    mail.add_x_header = Off
    expose_php = Off
    ...
    

Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для PHP расположены в папке: sles15/php.d.

Разместите их в директории /etc/php7/conf.d/.

Установите в качестве владельца пользователя и группу root:

chown root:root /etc/php7/conf.d/ -R

Конфигурация Apache

По умолчанию Apache настроен на дефолтный сайт в каталоге /var/www/html.

Основное, что требуется сделать для настройки конфигурации Apache:

  • изменить каталог для сайта на var/www/html/bx-site;
  • изменить порт, который слушает сервис (так как в качестве внешнего сервиса используем nginx);
  • импортировать настройки для сайта из виртуальной машины.

Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для Apache расположены в папке: sles15/httpd.

Разместите их в директории /etc/apache2/.

Настроить требуется два файла:

  • vhosts.d/default.conf - заменить каталог в описании сайта на var/www/html/bx-site;
  • httpd/listen.conf - указать для Listen порт 8090.

После этого запустите сервис:

systemctl --now enable apache2

Конфигурация MariaDB

Для конфигурации MariaDB требуется выполнить такие настройки:

  • transaction-isolation изменить на READ-COMMITTED;
  • innodb_flush_method установить равным O_DIRECT (желательная, но не обязательная настройка);
  • innodb_flush_log_at_trx_commit установить равным 2 (желательная, но не обязательная настройка).

Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для MariaDB находятся в папке: sles15/my.cnf.d.

Разместите их в директории /etc/my.cnf.d/.

Запустите сервис:

systemctl --now enable mariadb

Настройки сервис выполняются через mysql_secure_installation.

Конфигурация Redis

Данный сервис нам нужен для организации Push-сервера.

Основное, что нам важно установить в конфигурации:

  • включить файловый сокет для работы;
  • отключить сброс данных на диск (для работы Push-сервера нам не нужна эта возможность);
  • группу пользователя.

Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для Redis расположены в папке: sles15/redis.

Разместите их в директории /etc/redis/.

su -
usermod -g www redis
chown -R redis:www /etc/redis/ /var/log/redis/ /var/lib/redis/
mkdir /etc/systemd/system/redis@.service.d
echo -e '[Service]\nGroup=www' > /etc/systemd/system/redis@.service.d/custom.conf
systemctl daemon-reload

Запустите сервис

systemctl --now enable redis@default

Конфигурация Push-server

Схема работы:

 -----------------------                                   ---------------------------------------------------
| nginx: 0.0.0.0:80     | -> /bitrix/sub|/bitrix/subws -> | node server.js --config push-server-sub-80XX.json |
 -----------------------                                   ---------------------------------------------------

 -----------------------                     ---------------------------------------------------
| nginx: 127.0.0.1:8895 | -> /bitrix/pub -> | node server.js --config push-server-pub-90XX.json |
 -----------------------                     ---------------------------------------------------

Nginx проксирует запрос на push-сервис выбранного типа. Запросы получения сообщений (например, sub) - публичные и проксируются со стандартных портов 80/443. Запросы публикации (pub) доступны только с внутреннего адреса сервера.

Nodejs-процессы делятся на два типа:

  1. Процессы, отвечающие за подключение пользователя к выбранному каналу и получение им сообщений. Слушают порты 8010-8015;
  2. Процессы, отвечающие за отправку сообщения в канал. Слушают порты 9010-9011.

Для запуска Push-сервера нам понадобятся:

  • nodejs & npm ;
  • архив сервиса и его модулей.

Для установки понадобится Python и утилита make:

zypper install python3 make wget -y

Выполните действия:

  1. Скачайте архив с репозитория repo.bitrix.info
    wget https://repo.bitrix.info/vm/push-server-0.2.2.tgz
    или с сайта архив push-server-0.2.2.tgz и разместите его в директории /opt. Выполните установку:
    su -
    cd /opt
    npm install --production ./push-server-0.2.2.tgz
    

    Установка закончится строкой:

    + push-server@0.2.2
    added 65 packages from 78 contributors and audited 65 packages in 45.77s
    
  2. Выполните (исключительно для удобства):
    su -
    ln -sf /opt/node_modules/push-server/logs /var/log/push-server
    ln -sf /opt/node_modules/push-server/etc/push-server /etc/push-server
    
  3. Копируем файлы сервиса и основную конфигурацию:

    su - 
    cd /opt/node_modules/push-server
    cp etc/init.d/push-server-multi /usr/local/bin/push-server-multi
    cp etc/sysconfig/push-server-multi  /etc/sysconfig/push-server-multi
    cp etc/push-server/push-server.service  /etc/systemd/system/
    ln -sf /opt/node_modules/push-server /opt/push-server
    
  4. Создайте временный каталог:
    echo 'd /tmp/push-server 0770 wwwrun www -' > /etc/tmpfiles.d/push-server.conf
    systemd-tmpfiles --remove --create
    

    Отредактируйте конфигурационный файл /etc/sysconfig/push-server-multi. В нём нужно исправить/добавить параметры:

    • USER/GROUP - пользователь, под которым будет запущен сервис;
    • SECURITY_KEY - cекретный ключ для подписи соединения между клиентами и пуш-сервером;

      Примечание: Длина ключа не имеет значения. В ключе можно использовать только буквы латинского алфавита и цифры, спецсимволы запрещены. Но имейте в виду, что простой короткий ключ небезопасен. Можно генерировать его, например, таким образом:
      cat /dev/urandom |tr -dc A-Za-z0-9 | head -c 128

    • RUN_DIR - директория для хранения PID файлов процесса.

    Пример настроек параметров:

    GROUP=www
    USER=wwwrun
    SECURITY_KEY="SECURITYKEY123456"
    RUN_DIR=/tmp/push-server
    REDIS_SOCK=/var/run/redis/default.sock
    
  5. Каждый nodejs процесс будет запущен как отдельный процесс. Сгенерируйте конфигурации:
    /usr/local/bin/push-server-multi configs pub
    /usr/local/bin/push-server-multi configs sub
    

    Сгенерированные конфигурации в формате [dw]json[/dw][di]push-server-sub-80XX.json
    push-server-pub-90XX.json[/di] будут размещены в каталоге: /etc/push-server/.

  6. Измените пользователя и путь к скрипту запуска в конфигурационном файле сервиса /etc/systemd/system/push-server.service:

    [Service]
    User=wwwrun
    Group=www
    ExecStart=/usr/local/bin/push-server-multi systemd_start
    ExecStop=/usr/local/bin/push-server-multi stop
    ...
    
  7. Измените права доступа на каталог с логами:

    chown wwwrun:www /opt/node_modules/push-server/logs /tmp/push-server -RH
    
  8. Переконфигурируйте:
    systemctl daemon-reload
    
  9. Запустите сервис:
    systemctl --now enable push-server
    
  10. Перейдите в конфигурацию push модуля (настройки сайта) и включите использование локального push-сервера (последняя версия). Дополнительно нужно будет указать секретный ключ SECURITY_KEY, который мы настраивали выше в файле /etc/sysconfig/push-server-multi.


Конфигурация сайта

  Сайт

Создайте рабочий каталог:

mkdir /var/www/html/bx-site
cd /var/www/html/bx-site
wget https://www.1c-bitrix.ru/download/scripts/bitrixsetup.php
chown www-data:www-data /var/www/html/bx-site -R

Аналогичным образом можно скачать нужный дистрибутив и установить его в каталог: /var/www/html/bx-site.

Создайте базу данных и пользователя:

create database portal;
CREATE USER 'bitrix'@'localhost' IDENTIFIED BY 'PASSWORD';
GRANT ALL PRIVILEGES ON portal.* to 'bitrix'@'localhost';

Необходимо заменить PASSWORD на пароль, который будет использоваться для доступа к БД.

  Push-server

Для работы портала необходимо настроить push-server. Настройки могут быть выполнены через [dw]административный раздел портала[/dw][di]Настройки производятся на странице http://_имя_сайта_/bitrix/admin/settings.php?lang=ru&mid=pull

Нажмите на рисунок, чтобы увеличить

Подробнее...[/di], а можно добавить их в конфигурационный файл. Покажем как это делается вторым способом.

Исправьте конфигурационный файл /var/www/html/bx-site/bitrix/.settings.php, добавив следующую секцию:

return array (
'pull' => Array(
    'value' =>  array(
        'path_to_listener' => 'http://#DOMAIN#/bitrix/sub/',
        'path_to_listener_secure' => 'https://#DOMAIN#/bitrix/sub/',
        'path_to_modern_listener' => 'http://#DOMAIN#/bitrix/sub/',
        'path_to_modern_listener_secure' => 'https://#DOMAIN#/bitrix/sub/',
        'path_to_mobile_listener' => 'http://#DOMAIN#:8893/bitrix/sub/',
        'path_to_mobile_listener_secure' => 'https://#DOMAIN#:8894/bitrix/sub/',
        'path_to_websocket' => 'ws://#DOMAIN#/bitrix/subws/',
        'path_to_websocket_secure' => 'wss://#DOMAIN#/bitrix/subws/',
	'path_to_publish' => 'http://localhost:8895/bitrix/pub/',
        'path_to_publish_web' => 'http://#DOMAIN#/bitrix/rest/',
        'path_to_publish_web_secure' => 'https://#DOMAIN#/bitrix/rest/',
        'nginx_version' => '4',
        'nginx_command_per_hit' => '100',
        'nginx' => 'Y',
        'nginx_headers' => 'N',
        'push' => 'Y',
        'websocket' => 'Y',
        'signature_key' => 'PUTTHEPRIVATEKEYHERE',
        'signature_algo' => 'sha1',
        'guest' => 'N',
    ),
),
...

Обратите внимание, что signature_key должен содержать тот же ключ, который указан в /etc/sysconfig/push-server-multi в соответствующем ключе. Если все хорошо, то после перезапуска apache2:

systemctl restart apache2

Вы увидите запросы к push-server:

Request URL: ws://sitename/bitrix/subws/?CHANNEL_ID=....
Request Method: GET
Status Code: 101 Switching Protocols

Настройка окружения для RedHat8

В главе описаны настройки окружения для операционной системы RedHat8 для установки на неё продуктов 1С-Битрикс24 (коробочная версия) и 1С-Битрикс: Управление сайтом. Рассмотрена установка и настройка самой операционной системы, установка необходимых пакетов и конфигурация сервисов.

Внимание! Для операций, описанных в данной главе, необходимы начальные знания серверного администрирования. Так как инсталяция на другие окружения оттестирована вендором, но не является основной платформой для эксплуатации продуктов Bitrix Framework, то возможны незадокументированные сложности в установке. Вы должны понимать суть действий, осуществляемых вами в системе при установке продуктов.

Установка и настройка ОС

Установка

Для начала необходимо установить дистрибутив Red Hat Enterprise Linux 8 (RedHat8). В процессе установки выберите сервер с минимальными настройками.

Важно! Дальнейшая настройка будет показана на базе именно такой установки.

По завершении установки нужно активизировать подписку, иначе не будут работать установки и обновления системы:

subscription-manager register --username email_address --password password --auto-attach

Подписка привязана к аккаунту. В качестве email_address и password укажите тот, с помощью которого регистрировались на сайте RedHat.

Для авторизации можно вместо e-mail использовать логин, указанный при регистрации.

Для установки можно использовать только официальные репозитории от RedHat.

В качестве менеджера пакетов используется dnf. Обновите систему до последней стабильной версии. Отключите selinux

su -
dnf update -y
echo 'SELINUX=disabled' > /etc/sysconfig/selinux
reboot

Настройка портов

Обязательно нужно открыть порты:

  • 22 – ssh доступ;
  • 80 / 443 – http / https web-сервер;

Остальные порты для:

  • ntlm
  • сервера мгновенных сообщений;
  • xmpp-сервера

нужно открывать, если только они используются. Можно выбрать произвольные порты, а можно те же, что используются в CentOS:

  • 8890 / 8891 – http/https ntlm;
  • 8893 / 8894 – http/https сервер мгновенных сообщений;
  • 5222 / 5223 – http/https.


Установка пакетов

Ниже приведен весь список пакетов, который нам понадобится для 1С-Битрикс24 коробочная версия. Для 1С-Битрикс: Управление сайтом не нужен только push-server.

  1. Установите apache 2.4 и php 7.2:
    dnf -y install httpd
    
    dnf -y install php php php-cli php-common \
        php-devel php-gd php-json php-mbstring \
        php-mysqlnd php-opcache php-pdo php-pear \
        php-pecl-apcu php-pecl-zip php-process php-xml php-ldap
    

    С 01.02.2023 ограничивается поддержка наших продуктов на PHP версии ниже 8.0. Рекомендуемая версия PHP – 8.1 и выше. Поэтому после установки необходимо обновить PHP до версии не ниже 8.0.

  2. Установите nginx (1.14 версия):
    dnf install nginx -y
    
  3. Установите MariaDB сервер (10.1 версия):
    dnf install mariadb -y
    
  4. Установите node и npm (push-server):
    dnf install nodejs -y
    
  5. Установите redis:
    dnf install redis -y
    


Конфигурация Nginx

Выполните конфигурацию Nginx.

  • Рабочий каталог для сайта - /var/www/html/bx-site.
  • Пользователь для web окружения - nginx, группа apache.

Конфигурация nginx сервера:

/etc/nginx/nginx.conf                                       # основной конфигурационный файл
            |_conf.d/upstreams.conf                         # конфигурация для upstream серверов: apache && push-server
            |_conf.d/maps-composite_settings.conf           # переменные, используемые для кеша
            |_conf.d/maps.conf                              # дополнительные переменные
            |_conf.d/http-add_header.conf                   # CORS заголовки
            |_sites-available/*.conf                        # подключаем сайты
                              |_default.conf                # сайт по умолчанию (настраиваем только 80 порт)
                                    |_conf.d/bx_temp.conf   # конфигурация BX_TEMPORARY_FILES_DIRECTORY
                                    |_conf.d/bitrix.conf    # дефолтная конфигурация сайта
                              |_rtc.conf                    # проксирование запросов на push-server (публикация)

Дефолтная конфигурация сайта:

conf.d/bitrix.conf                                          # основный блок с включенным по умолчанию кешем в файлах
        |_conf.d/bitrix_general.conf                        # отдача статики, быстрая отдача для внешних хранилищ и прочее
                |_conf.d/errors.conf                        # обработка ошибок
                |_conf.d/im_subscrider.conf                 # проксирование запросов на push-server (получение)
                |_conf.d/bitrix_block.conf                  # блокировки по умолчанию

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

Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для Nginx расположены в папке: redhat8/nginx.

Разместите их в директории /etc/nginx/.

В сервисе используются имена для проксирования на определенные службы:

  • httpd – проксирование запросов на apache;
  • push – проксирование запросов на push-server.

Чтобы заработала конфигурация, необходимо прописать их в локальных адресах. Если сервисы расположены на другом хосте, укажите здесь правильный адрес:

echo "127.0.0.1 push httpd" >> /etc/hosts

Запустите сервис:

systemctl --now enable nginx

Добавьте правила для firewalld:

firewall-cmd --zone=public --add-service=https --permanent
firewall-cmd --zone=public --add-service=http --permanent
firewall-cmd --reload


Конфигурация PHP

В данной версии установки централизованное хранилище конфигов: /etc/php.d.

Минимальные настройки, которые необходимо добавить:

  • для модуля opcache:

    opcache.max_accelerated_files = 100000
    opcache.revalidate_freq = 0
    

  • добавьте настройки bitrexenv.ini:

    display_errors = Off
    error_reporting = E_ALL
    error_log = '/var/log/php/error.log'
    
    ; Set some more PHP parameters
    enable_dl = Off
    short_open_tag = On
    allow_url_fopen = On
    
    # Security headers
    mail.add_x_header = Off
    expose_php = Off
    ...
    

Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для Nginx расположены в папке: redhat8/php.d.

Разместите их в директории /etc/php.d/.



Конфигурация Apache

По умолчанию Apache настроен на дефолтный сайт в каталоге /var/www/html.

Основные действия для настройки конфигурации Apache:

  • изменить каталог для сайта на var/www/html/bx-site;
  • изменить порт, который слушает сервис (так как в качестве внешнего сервиса будет использоваться nginx);
  • импортировать настройки для сайта из виртуальной машины.

Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для Nginx расположены в папке: redhat8/httpd.

Разместите их в директории /etc/httpd/.

Необходимо настроить файлы:

  • conf.d/default.conf – в описании сайта замените каталог на conf/httpd.conf;
  • conf/httpd.conf – в Listen замените порт на 8090;
  • conf.modules.d – меняем на 00-mpm.conf.

Модуль php для apache работает только с менеджером процессов prefork. Включите его.

Запустите сервис:

systemctl --now enable httpd



Конфигурация MariaDB

Для конфигурации MariaDB выполните следующие настройки:

  • transaction-isolation измените на READ-COMMITTED;
  • innodb_flush_method установите равным O_DIRECT (рекомендованная, но не обязательная настройка);
  • innodb_flush_log_at_trx_commit установите равным 2 (рекомендованная, но не обязательная настройка).

Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для Nginx расположены в папке: redhat8/my.cnf.d.

Разместите их в директории /etc/my.cnf.d/.

Запустите сервис:

systemctl --now enable mariadb

Настройка сервиса выполняется через mysql_secure_installation.



Конфигурация Redis

Данный сервис необходим для организации Push-сервера.

Основные настройки, которые необходимо выполнить в конфигураторе:

  • включить файловый сокет для работы;
  • отключить сброс данных на диск (для работы Push-сервера эта возможность не нужна);
  • установить группу пользователя.

Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для Nginx расположены в папке: redhat8/redis.

Разместите их в директории /etc/redis/ и выполните команды:

su -
usermod -g apache redis
chown root:apache /etc/redis/ /var/log/redis/
mkdir /etc/systemd/system/redis.service.d
echo -e '[Service]\nGroup=apache' > /etc/systemd/system/redis.service.d/custom.conf
systemctl daemon-reload

Запустите сервис:

systemctl --now enable redis



Конфигурация Push-server

Схема работы:

 -----------------------                                   ---------------------------------------------------
| nginx: 0.0.0.0:80     | -> /bitrix/sub|/bitrix/subws -> | node server.js --config push-server-sub-80XX.json |
 -----------------------                                   ---------------------------------------------------

 -----------------------                     ---------------------------------------------------
| nginx: 127.0.0.1:8895 | -> /bitrix/pub -> | node server.js --config push-server-pub-90XX.json |
 -----------------------                     ---------------------------------------------------

Nginx проксирует запрос на push-сервис выбранного типа. Запросы получения сообщений (например, sub) – публичные, проксируются со стандартных портов 80/443. Запросы публикации (pub) – доступны только с внутреннего адреса сервера.

Nodejs-процессы делятся на два типа:

  1. Процессы, отвечающие за подключение пользователя к выбранному каналу и получение им сообщений. Слушают порты 8010-8015;
  2. Процессы, отвечающие за отправку сообщения в канал. Слушают порты 9010-9011.

Для запуска Push-сервера необходимы:

  • nodejs & npm;
  • архив сервиса и его модулей.

Для установки понадобится Python и утилита make:

dnf install python3 make -y

Выполните следующие действия:

  1. Скачайте и установите архив push-server-0.3.0.tgz:

    su -
    cd /opt
    wget https://repo.bitrix.info/vm/push-server-0.3.0.tgz
    npm install --production ./push-server-0.3.0.tgz
    

    Примечание: Если репозиторий repo.bitrix.info недоступен, скачайте архив push-server-0.3.0.tgz и разместите его в директории /opt. Далее выполните установку:

    su -
    cd /opt
    npm install --production ./push-server-0.3.0.tgz
    

    Установка закончится строкой:

    + push-server@0.3.0
    added 65 packages in 46.522s
    

  2. Для удобства дальнейшей работы выполните команды:

    su -
    ln -sf /opt/node_modules/push-server/logs /var/log/push-server
    ln -sf /opt/node_modules/push-server/etc/push-server /etc/push-server
    

  3. Скопируйте файлы сервиса и основную конфигурацию:

    su - 
    cd /opt/node_modules/push-server
    cp etc/init.d/push-server-multi /usr/local/bin/push-server-multi
    cp etc/sysconfig/push-server-multi  /etc/sysconfig/push-server-multi
    cp etc/push-server/push-server.service  /etc/systemd/system/
    ln -sf /opt/node_modules/push-server /opt/push-server
    

  4. Создайте временный каталог:
    echo 'd /tmp/push-server 0770 apache apache -' > /etc/tmpfiles.d/push-server.conf
    systemd-tmpfiles --remove --create
    

    Отредактируйте конфигурационный файл /etc/sysconfig/push-server-multi. В нём нужно исправить/добавить параметры:

    • SECURITY_KEY - cекретный ключ для подписи соединения между клиентами и пуш-сервером;

      Примечание: Длина ключа не имеет значения. В ключе можно использовать только буквы латинского алфавита и цифры, спецсимволы запрещены. Но имейте в виду, что простой короткий ключ небезопасен. Можно генерировать его, например, таким образом:
      cat /dev/urandom |tr -dc A-Za-z0-9 | head -c 128

    • RUN_DIR - директория для хранения PID файлов процесса;
    • USER/GROUP - пользователь, под которым будет запущен сервис.

    Пример настроек параметров:

    GROUP=apache
    SECURITY_KEY="SECURITYKEY123456"
    RUN_DIR=/tmp/push-server
    

  5. Каждый nodejs-процесс будет запущен как отдельный процесс. Сгенерируйте конфигурации:

    /usr/local/bin/push-server-multi configs pub
    /usr/local/bin/push-server-multi configs sub
    

    Сгенерированные конфигурации в формате [dw]json[/dw][di]push-server-sub-80XX.json
    push-server-pub-90XX.json[/di] будут размещены в каталоге: /etc/push-server/.

  6. В конфигурационном файле сервиса /etc/systemd/system/push-server.service измените пользователя:

    [Service]
    User=apache
    Group=apache
    ExecStart=/usr/local/bin/push-server-multi systemd_start
    ...
    

  7. Измените права доступа на каталог с логами:

    chown wwwrun:www /opt/node_modules/push-server/logs /tmp/push-server -RH
    
  8. Переконфигурируйте:

    systemctl daemon-reload
    

  9. Запустите сервис:

    systemctl --now enable push-server
    

  10. Перейдите в конфигурацию Push-модуля (настройки сайта) и включите использование локального Push-сервера (последняя версия). Укажите секретный ключ, который настраивали ранее в файле /etc/sysconfig/push-server-multi.


Конфигурация сайта

  Сайт

Создайте рабочий каталог:

mkdir /var/www/html/bx-site
cd /var/www/html/bx-site
wget https://www.1c-bitrix.ru/download/scripts/bitrixsetup.php
chown www-data:www-data /var/www/html/bx-site -R

Аналогичным образом можно скачать нужный дистрибутив и установить его в каталог: /var/www/html/bx-site.

Создайте базу данных и пользователя:

create database portal;
CREATE USER 'bitrix'@'localhost' IDENTIFIED BY 'PASSWORD';
GRANT ALL PRIVILEGES ON portal.* to 'bitrix'@'localhost';

Необходимо заменить PASSWORD на пароль, который будет использоваться для доступа к БД.

  Push-server

Для работы портала необходимо настроить push-server. Настройки могут быть выполнены через [dw]административный раздел портала[/dw][di]Настройки производятся на странице http://_имя_сайта_/bitrix/admin/settings.php?lang=ru&mid=pull

Нажмите на рисунок, чтобы увеличить

Подробнее...[/di], а можно добавить их в конфигурационный файл. Покажем как это делается вторым способом.

Исправьте конфигурационный файл /var/www/html/bx-site/bitrix/.settings.php, добавив следующую секцию:

return array (
'pull' => Array(
    'value' =>  array(
        'path_to_listener' => 'http://#DOMAIN#/bitrix/sub/',
        'path_to_listener_secure' => 'https://#DOMAIN#/bitrix/sub/',
        'path_to_modern_listener' => 'http://#DOMAIN#/bitrix/sub/',
        'path_to_modern_listener_secure' => 'https://#DOMAIN#/bitrix/sub/',
        'path_to_mobile_listener' => 'http://#DOMAIN#:8893/bitrix/sub/',
        'path_to_mobile_listener_secure' => 'https://#DOMAIN#:8894/bitrix/sub/',
        'path_to_websocket' => 'ws://#DOMAIN#/bitrix/subws/',
        'path_to_websocket_secure' => 'wss://#DOMAIN#/bitrix/subws/',
	'path_to_publish' => 'http://localhost:8895/bitrix/pub/',
        'path_to_publish_web' => 'http://#DOMAIN#/bitrix/rest/',
        'path_to_publish_web_secure' => 'https://#DOMAIN#/bitrix/rest/',
        'nginx_version' => '4',
        'nginx_command_per_hit' => '100',
        'nginx' => 'Y',
        'nginx_headers' => 'N',
        'push' => 'Y',
        'websocket' => 'Y',
        'signature_key' => 'PUTTHEPRIVATEKEYHERE',
        'signature_algo' => 'sha1',
        'guest' => 'N',
    ),
),
...

Обратите внимание, что signature_key должен содержать тот же ключ, который указан в /etc/sysconfig/push-server-multi в соответствующем ключе. Если все хорошо, то после перезапуска httpd:

systemctl restart httpd

Вы увидите запросы к push-server:

Request URL: ws://sitename/bitrix/subws/?CHANNEL_ID=....
Request Method: GET
Status Code: 101 Switching Protocols

Настройка окружения для РЕД ОС 7.2

В главе описаны настройки окружения для операционной системы РЕД ОС 7.2 для установки на неё продуктов 1С-Битрикс24 (коробочная версия) и 1С-Битрикс: Управление сайтом. Рассмотрена установка и настройка самой операционной системы, установка необходимых пакетов и конфигурация сервисов.

Внимание! Для операций, описанных в данной главе, необходимы начальные знания серверного администрирования. Так как инсталяция на другие окружения оттестирована вендором, но не является основной платформой для эксплуатации продуктов Bitrix Framework, то возможны незадокументированные сложности в установке. Вы должны понимать суть действий, осуществляемых вами в системе при установке продуктов.

Установка и настройка ОС

Установка

Для начала необходимо установить дистрибутив РЕД ОС 7.2. В процессе установки выберите сервер с минимальными настройками (в противном случае в результате получите десктоп).

Важно! Дальнейшая настройка будет показана на базе именно такой установки.

Для установки можно использовать только официальные репозитории РЕД ОС. Вам понадобится версия 7.2 (в поставке версия php 7.1, а в репозитории доступна 7.2).

В качестве менеджера пакетов используется yum. Обновите систему до последней стабильной версии и отключите selinux:

su -
yum update -y
echo 'SELINUX=disabled' > /etc/sysconfig/selinux
reboot

Настройка портов

Обязательно нужно открыть порты:

  • 22 – ssh доступ;
  • 80 / 443 – http / https web-сервер;

Остальные порты для:

  • ntlm
  • сервера мгновенных сообщений;
  • xmpp-сервера

нужно открывать, если только они используются. Можно выбрать произвольные порты, а можно те же, что используются в CentOS:

  • 8890 / 8891 – http/https ntlm;
  • 8893 / 8894 – http/https сервер мгновенных сообщений;
  • 5222 / 5223 – http/https.


Установка пакетов

Ниже приведен список всех пакетов, которые понадобятся для 1С-Битрикс24 (коробочная версия). Для 1С-Битрикс: Управление сайтом список аналогичен (не нужно устанавливать только push-server).

  • Apache 2.4 и php 7.4:

    # yum install httpd -y
    
    # yum -y install php php-cli php-common \
     php-devel php-gd \
     php-imap php-json php-ldap php-mbstring \
     php-mysqlnd php-opcache php-pdo \
     php-pear php-pear-DB php-pecl-apcu \
     php-pecl-apcu-bc php-pecl-geoip \
     php-pecl-mcrypt php-pecl-memcache  \
     php-pecl-ssh2 php-process php-pspell php-xml php-zipstream
    

    С 01.02.2023 ограничивается поддержка наших продуктов на PHP версии ниже 8.0. Рекомендуемая версия PHP - 8.1 и выше. Поэтому после установки необходимо обновить PHP до версии не ниже 8.0.

  • Nginx (версия 1.18):

    yum install nginx -y
    

  • MariaDB сервер (версия 10.5):

    yum -y install mariadb-server mariadb
    

  • Node и npm (push-server), версия 16.13:

    yum install nodejs -y
    

  • Redis (версия 6.2):

    yum install redis -y
    



Конфигурация Nginx

Настройте конфигурацию Nginx.

  • Рабочий каталог для сайта - /var/www/html/bx-site.
  • Пользователь для web окружения - nginx, группа apache.

Конфигурация nginx сервера:

/etc/nginx/nginx.conf                                       # основной конфигурационный файл
            |_conf.d/upstreams.conf                         # конфигурация для upstream серверов: apache && push-server
            |_conf.d/maps-composite_settings.conf           # параменные используемые для кеша
            |_conf.d/maps.conf                              # дополнительные переменные
            |_conf.d/http-add_header.conf                   # CORS заголовки
            |_sites-available/*.conf                        # подключаем сайты
                              |_default.conf                # сайт по умолчанию (настраиваем только 80 порт)
                                    |_conf.d/bx_temp.conf   # конфигурация BX_TEMPORARY_FILES_DIRECTORY
                                    |_conf.d/bitrix.conf    # дефолтная конфигурация сайта
                              |_rtc.conf                    # проксирование запросов на push-server (публикация)

Дефолтная конфигурация сайта:

conf.d/bitrix.conf                                          # основные блоки со включенным по умолчанию кешем в файлах
        |_conf.d/bitrix_general.conf                        # отдача статики, быстрая отдача для внешних хранилищ и прочее
                |_conf.d/errors.conf                        # обработка ошибок
                |_conf.d/im_subscrider.conf                 # проксирование запросов на push-server (получение)
                |_conf.d/bitrix_block.conf                  # блокировки по умолчанию

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

Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для Nginx расположены в папке: redos/nginx.

Разместите их в директории /etc/nginx/.

В сервисе используются имена для проксирования на определенные службы:

  • httpd – проксирование запросов на apache;
  • push – проксирование запросов на push-server.

Чтобы заработала конфигурация, необходимо прописать их в локальных адресах. Если сервисы расположены на другом хосте, укажите здесь правильный адрес:

echo "127.0.0.1 push httpd" >> /etc/hosts

Запустите сервис:

systemctl --now enable nginx



Конфигурация php

В данной версии установки централизованное хранилище конфигов: /etc/php.d.

Минимальные настройки, которые необходимо добавить:

  • для модуля opcache:

    opcache.max_accelerated_files = 100000
    opcache.revalidate_freq = 0
    

  • настройки файла bitrexenv.ini:

    display_errors = Off
    error_reporting = E_ALL
    error_log = '/var/log/php/error.log'
    
    ; Set some more PHP parameters
    enable_dl = Off
    short_open_tag = On
    allow_url_fopen = On
    
    # Security headers
    mail.add_x_header = Off
    expose_php = Off
    ...
    

Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для PHP расположены в папке: redos/php.d.

Разместите их в директории /etc/php.d/.



Конфигурация Apache

По умолчанию Apache настроен на дефолтный сайт в каталоге /var/www/html.

Основные действия для настройки конфигурации Apache:

  • изменить каталог для сайта на var/www/html/bx-site;
  • изменить порт, который слушает сервис (так как в качестве внешнего сервиса будет использоваться nginx);
  • импортировать настройки для сайта из виртуальной машины.

Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для Apache расположены в папке: redos/httpd.

Разместите их в директории /etc/httpd/.

Необходимо настроить два файла:

  • conf.d/default.conf – в описании сайта замените каталог на var/www/html/bx-site;
  • conf/httpd.conf – в Listen замените порт на 8090.
  • conf.modules.d/00-mpm.conf - смена mpm event на prefork.

Запустите сервис:

systemctl --now enable httpd

Конфигурация MariaDB

Для конфигурации MariaDB выполните следующие настройки:

  • transaction-isolation измените на READ-COMMITTED;
  • innodb_flush_method установите равным O_DIRECT (рекомендованная, но не обязательная настройка);
  • innodb_flush_log_at_trx_commit установить равным 2 (рекомендованная, но не обязательная настройка).

Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для MariaDB расположены в папке: redos/my.cnf.d.

Разместите их в директории /etc/my.cnf.d/.

Запустите сервис:

systemctl --now enable mariadb

Настройка сервиса выполняется через mysql_secure_installation.



Конфигурация Redis

Данный сервис необходим для организации Push-сервера.

Основные настройки, которые необходимо выполнить в конфигураторе:

  • включить файловый сокет для работы;
  • отключить сброс данных на диск (для работы Push-сервера эта возможность не нужна);
  • установить группу пользователя.

Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для Nginx расположены в папке: redos/redis.

Разместите их в директории /etc/redis/ и выполните команды:

su -
usermod -g apache redis
chown root:apache /etc/redis/ /var/log/redis/
[[ ! -d /etc/systemd/system/redis.service.d ]] && mkdir /etc/systemd/system/redis.service.d
echo -e '[Service]\nGroup=apache' > /etc/systemd/system/redis.service.d/custom.conf
systemctl daemon-reload

Запустите сервис:

systemctl --now enable redis



Конфигурация Push-server

Схема работы:

 -----------------------                                   ---------------------------------------------------
| nginx: 0.0.0.0:80     | -> /bitrix/sub|/bitrix/subws -> | node server.js --config push-server-sub-80XX.json |
 -----------------------                                   ---------------------------------------------------

 -----------------------                     ---------------------------------------------------
| nginx: 127.0.0.1:8895 | -> /bitrix/pub -> | node server.js --config push-server-pub-90XX.json |
 -----------------------                     ---------------------------------------------------

Nginx проксирует запрос на push-сервис выбранного типа. Запросы получения сообщений (например, sub) – публичные, проксируются со стандартных портов 80/443. Запросы публикации (pub) – доступны только с внутреннего адреса сервера.

Nodejs-процессы делятся на два типа:

  1. Процессы, отвечающие за подключение пользователя к выбранному каналу и получение им сообщений. Слушают порты 8010-8015;
  2. Процессы, отвечающие за отправку сообщения в канал. Слушают порты 9010-9011.

Для запуска Push-сервера необходимы:

  • nodejs & npm;
  • архив сервиса и его модулей.

Выполните следующие действия:

  1. Скачайте и установите архив push-server-0.3.0.tgz:

    su -
    cd /opt
    wget https://repo.bitrix.info/vm/push-server-0.3.0.tgz
    npm install --production ./push-server-0.3.0.tgz
    

    Примечание: Если репозиторий repo.bitrix.info недоступен, скачайте архив push-server-0.2.2.tgz и разместите его в директории /opt. Далее выполните установку:

    su -
    cd /opt
    npm install --production ./push-server-0.3.0.tgz
    

    Установка закончится строкой:

    added 73 packages, and audited 74 packages in 8s
    

  2. Для удобства дальнейшей работы выполните команды:

    su -
    ln -sf /opt/node_modules/push-server/logs /var/log/push-server
    

  3. Скопируйте файлы сервиса и основную конфигурацию:

    su - 
    cd /opt/node_modules/push-server
    cp etc/init.d/push-server-multi /usr/local/bin/push-server-multi
    cp etc/sysconfig/push-server-multi  /etc/sysconfig/push-server-multi
    cp etc/push-server/push-server.service  /etc/systemd/system/
    ln -sf /opt/node_modules/push-server /opt/push-server
    

  4. В конфигурационном файле /etc/sysconfig/push-server-multi исправьте (или добавьте, если их нет) следующие параметры:
    • SECURITY_KEY – секретный ключ для подписи соединения между клиентом и пуш-сервером;

      Примечание: Длина ключа не имеет значения. В ключе можно использовать только буквы латинского алфавита и цифры (спецсимволы запрещены). Но имейте в виду, что простой короткий ключ небезопасен. Можно генерировать его, например, таким образом:
      cat /dev/urandom |tr -dc A-Za-z0-9 | head -c 128

    • RUN_DIR – директория для хранения PID файлов процесса;
    • USER/GROUP – пользователь, под которым будет запущен сервис.

    Пример настроек параметров:

    GROUP=apache
    SECURITY_KEY="SECURITYKEY123456"
    RUN_DIR=/tmp/push-server
    

  5. Каждый nodejs-процесс будет запущен как отдельный процесс. Сгенерируйте конфигурации:

    /usr/local/bin/push-server-multi configs pub
    /usr/local/bin/push-server-multi configs sub
    

    Сгенерированные конфигурации в формате [dw]json[/dw][di]push-server-sub-80XX.json
    push-server-pub-90XX.json[/di] будут размещены в каталоге: /etc/push-server/.

  6. Создайте каталог через tmpfiles.d:

    echo 'd /tmp/push-server 0770 apache apache -' > /etc/tmpfiles.d/push-server.conf
    systemd-tmpfiles --remove --create
    

  7. В конфигурационном файле сервиса /etc/systemd/system/push-server.service измените пользователя:

    [Service]
    User=apache
    Group=apache
    ExecStart=/usr/local/bin/push-server-multi systemd_start
    ExecStop=/usr/local/bin/push-server-multi stop
    ...
    

  8. Переконфигурируйте:

    systemctl daemon-reload
    

  9. Запустите сервис:

    systemctl --now enable push-server
    

  10. Перейдите в конфигурацию Push-модуля (настройки сайта) и включите использование локального Push-сервера (последняя версия). Укажите секретный ключ, который настраивали ранее в файле /etc/sysconfig/push-server-multi.


Конфигурация сайта

Сайт

Создайте рабочий каталог:

mkdir /var/www/html/bx-site
cd /var/www/html/bx-site
wget https://www.1c-bitrix.ru/download/scripts/bitrixsetup.php
chown apache:apache /var/www/html/bx-site -R

Аналогичным образом скачайте нужный дистрибутив и установите его в каталог: /var/www/html/bx-site.

Создайте базу данных и пользователя:

create database portal;
CREATE USER 'bitrix'@'localhost' IDENTIFIED BY 'PASSWORD';
GRANT ALL PRIVILEGES ON portal.* to 'bitrix'@'localhost';

Необходимо заменить 'PASSWORD', на пароль который будете использовать для доступа к БД.

Push-server

Для работы портала необходимо настроить push-server. Настройки могут быть выполнены через [dw]административный раздел портала[/dw][di]Настройки производятся на странице http://_имя_сайта_/bitrix/admin/settings.php?lang=ru&mid=pull

Нажмите на рисунок, чтобы увеличить

Подробнее...[/di], а можно добавить их в конфигурационный файл. Покажем как это делается вторым способом.

Исправьте конфигурационный файл /var/www/html/bx-site/bitrix/.settings.php, добавив следующую секцию:

return array (
'pull' => Array(
    'value' =>  array(
        'path_to_listener' => 'http://#DOMAIN#/bitrix/sub/',
        'path_to_listener_secure' => 'https://#DOMAIN#/bitrix/sub/',
        'path_to_modern_listener' => 'http://#DOMAIN#/bitrix/sub/',
        'path_to_modern_listener_secure' => 'https://#DOMAIN#/bitrix/sub/',
        'path_to_mobile_listener' => 'http://#DOMAIN#:8893/bitrix/sub/',
        'path_to_mobile_listener_secure' => 'https://#DOMAIN#:8894/bitrix/sub/',
        'path_to_websocket' => 'ws://#DOMAIN#/bitrix/subws/',
        'path_to_websocket_secure' => 'wss://#DOMAIN#/bitrix/subws/',
	'path_to_publish' => 'http://localhost:8895/bitrix/pub/',
        'path_to_publish_web' => 'http://#DOMAIN#/bitrix/rest/',
        'path_to_publish_web_secure' => 'https://#DOMAIN#/bitrix/rest/',
        'nginx_version' => '4',
        'nginx_command_per_hit' => '100',
        'nginx' => 'Y',
        'nginx_headers' => 'N',
        'push' => 'Y',
        'websocket' => 'Y',
'signature_key' => 'SECURITYKEY123456',
        'signature_algo' => 'sha1',
        'guest' => 'N',
    ),
),
...
Внимание! .Обратите внимание, signature_key должен содержать тот же ключ, который вы указали в /etc/sysconfig/push-server-multi в соответствующем ключе. Если все хорошо, то после перезапуска httpd:
systemctl restart httpd

Вы увидите запросы к push-server:

Request URL: ws://sitename/bitrix/subws/?CHANNEL_ID=....
Request Method: GET
Status Code: 101 Switching Protocols


Настройка окружения для РЕД ОС 7.3

В главе описаны настройки окружения для операционной системы РЕД ОС 7.3 для установки на неё продуктов 1С-Битрикс24 (коробочная версия) и 1С-Битрикс: Управление сайтом. Рассмотрена установка и настройка самой операционной системы, установка необходимых пакетов и конфигурация сервисов.

Внимание! Для операций, описанных в данной главе, необходимы начальные знания серверного администрирования. Так как инсталяция на другие окружения оттестирована вендором, но не является основной платформой для эксплуатации продуктов Bitrix Framework, то возможны незадокументированные сложности в установке. Вы должны понимать суть действий, осуществляемых вами в системе при установке продуктов.

Установка и настройка ОС

Для начала необходимо установить дистрибутив РЕД ОС 7.3. В процессе установки выбирите сервер с минимальной настройкой (в противном случае получите декстоп).

Внимание! Дальнейшая настройка будет показана на базе такой установки.

Для установки можно использовать только официальные репозитории от Ред ОС. Вам понадобятся обновления (в поставке версия php 7.4 , в репозитории доступна 8.1).

В качестве менеджера пакетов используется yum. Обновляем систему до последней стабильной версии. Отключаем selinux:

su -
yum update -y
echo 'SELINUX=disabled' > /etc/sysconfig/selinux
reboot


Установка пакетов

Ниже приведен список всех пакетов, которые понадобятся для "1С-Битрикс24 (коробочная версия)". Для "1С-Битрикс: Управление сайтом" список аналогичен (не нужно устанавливать только push-server).

  1. Apache 2.4 и PHP 8.1:
    # yum install httpd -y
    
    # yum install -y php81-release
    
    # yum install -y \
        php php-cli php-common php-devel \
        php-gd php-imap php-json php-ldap \
        php-mbstring php-mysqlnd php-opcache \
        php-pdo php-pear php-pear-DB php-pecl-apcu \
        php-pecl-mcrypt php-pecl-memcache \
        php-process php-pspell php-xml php-zipstream
  2. NGINX (1.22.1 версия)
    yum install nginx -y
  3. MariaDB сервер (10.10.2-MariaDB версия)
    yum -y install mariadb-server mariadb
  4. Node и NPM (push-server) - 16.13
    yum install nodejs npm -y
  5. Redis - 7.0.5
    yum install redis -y

Конфигурация NGINX

Настройте конфигурацию Nginx:

  • Рабочий каталог для сайта - /var/www/html/bx-site.
  • Пользователь для web окружения - nginx, группа apache.

Конфигурация NGINX сервера:

/etc/nginx/nginx.conf                                       # основной конфигурационный файл
            |_conf.d/upstreams.conf                         # конфигурация для upstream серверов: apache && push-server
            |_conf.d/maps-composite_settings.conf           # параменные используемые для кеша
            |_conf.d/maps.conf                              # дополнительные переменные
            |_conf.d/http-add_header.conf                   # CORS заголовки
            |_sites-available/*.conf                        # подключаем сайты
                              |_default.conf                # сайт по умолчанию (настраиваем только 80 порт)
                                    |_conf.d/bx_temp.conf   # конфигурация BX_TEMPORARY_FILES_DIRECTORY
                                    |_conf.d/bitrix.conf    # дефолтная конфигурация сайта
                              |_rtc.conf                    # проксирование запросов на push-server (публикация)

Дефолтная конфигурация сайта:

conf.d/bitrix.conf                                          # основный блоки со включенным по умолчанию кешем в файлах
        |_conf.d/bitrix_general.conf                        # отдача статики, быстрая отдача для внешних хранилищ и прочее
                |_conf.d/errors.conf                        # обработка ошибок
                |_conf.d/im_subscrider.conf                 # проксирование запросов на push-server (получение)
                |_conf.d/bitrix_block.conf                  # блокировки по умолчанию

Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для Nginx расположены в папке: redos/nginx.

rsync -av redos/nginx/ /etc/nginx/

В сервисе используются имена для проксирования на определенные службы:

  • httpd - проксирование запросов на apache
  • push - проксирование запросов на push-server

Чтобы заработала конфигурация, необходимо прописать их в локальных адресах. Если сервисы расположены на другом хосте, указываем здесь правильный адрес.

echo "127.0.0.1 push httpd" >> /etc/hosts

Запускаем сервис

systemctl --now enable nginx


Конфигурация PHP

В данной версии установки централизованное хранилище конфигов: /etc/php.d.

Минимальные настройки, которые необходимо добавить:

  • для модуля opcache
    opcache.max_accelerated_files = 100000
    opcache.revalidate_freq = 0
  • Настройки файла zx-bitrix.ini:
    display_errors = Off
    error_reporting = E_ALL
    error_log = '/var/log/php/error.log'
    
    ; Set some more PHP parameters
    enable_dl = Off
    short_open_tag = On
    allow_url_fopen = On
    
    # Security headers
    mail.add_x_header = Off
    expose_php = Off
    ...

Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для PHP расположены в папке: redos/php.d.

su -
cd /tmp
hg clone http://hg.bx/repos/bx-os
cd bx-os
rsync -av redos/php.d/ /etc/php.d/


Конфигурация Apache

По умолчанию apache настроен на дефолтный сайт в каталоге /var/www/html.

Основные действия для настройки конфигурации Apache:

  • изменить каталог для сайта на /var/www/html/bx-site,
  • изменить порт, который слушает сервис (так как в качестве внешнего сервиса будет использоваться nginx),
  • импортировать настройки для сайта из виртуальной машины.

Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для Apache расположены в папке: redos/httpd.

su -
cd /tmp
hg clone http://hg.bx/repos/bx-os
cd bx-os
rsync -av redos/httpd/ /etc/httpd/

Мы настраиваем три файла:

  • conf.d/default.conf – в описании сайта замените каталог на var/www/html/bx-site;
  • conf/httpd.conf смена значения Listen на порт 8090
  • conf.modules.d/00-mpm.conf - смена mpm event на prefork.

Запустите сервис:

systemctl --now enable httpd


Конфигурация Mariadb

Для конфигурации MariaDB выполните следующие настройки:

  • transaction-isolation измените на READ-COMMITTED;
  • innodb_flush_method установите равным O_DIRECT (рекомендованная, но не обязательная настройка);
  • innodb_flush_log_at_trx_commit установить равным 2 (рекомендованная, но не обязательная настройка).

Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для MariaDB расположены в папке: redos/my.cnf.d.

Разместите их в директории /etc/my.cnf.d/.

Запустите сервис:

systemctl --now enable mariadb

Настройка сервиса выполняется через mysql_secure_installation.



Конфигурация Redis

Данный сервис необходим для организации работы Push-сервера.

Основные настройки, которые необходимо выполнить в конфигураторе:

  • включить файловый сокет для работы;
  • отключить сброс данных на диск (для работы Push-сервера эта возможность не нужна);
  • установить группу пользователя.

Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для Nginx расположены в папке: redos/redis.

Разместите их в директории /etc/redis/ и выполните команды:

su -
usermod -g apache redis
chown root:apache /etc/redis/ /var/log/redis/
[[ ! -d /etc/systemd/system/redis.service.d ]] && mkdir /etc/systemd/system/redis.service.d
echo -e '[Service]\nGroup=apache' > /etc/systemd/system/redis.service.d/custom.conf
systemctl daemon-reload

Запустите сервис:

systemctl --now enable redis


Конфигурация Push-server

Схема работы

 -----------------------                                   ---------------------------------------------------
| nginx: 0.0.0.0:80     | -> /bitrix/sub|/bitrix/subws -> | node server.js --config push-server-sub-80XX.json |
 -----------------------                                   ---------------------------------------------------

 -----------------------                     ---------------------------------------------------
| nginx: 127.0.0.1:8895 | -> /bitrix/pub -> | node server.js --config push-server-pub-90XX.json |
 -----------------------                     ---------------------------------------------------

Nginx проксирует запрос на push-сервис выбранного типа. Запросы получения сообщений (например, sub) – публичные, проксируются со стандартных портов 80/443. Запросы публикации (pub) – доступны только с внутреннего адреса сервера.

Nodejs-процессы делятся на два типа:

  1. Процессы, отвечающие за подключение пользователя к выбранному каналу и получение им сообщений. Слушают порты 8010-8015;
  2. Процессы, отвечающие за отправку сообщения в канал. Слушают порты 9010-9011.

Для запуска Push-сервера необходимы:

  • nodejs & npm;
  • архив сервиса и его модулей.

Выполните следующие действия:

  1. Скачайте и установите архив push-server-0.3.0.tgz:

    su -
    cd /opt
    wget https://repo.bitrix.info/vm/push-server-0.3.0.tgz
    npm install --production ./push-server-0.3.0.tgz
    

    Примечание: Если репозиторий repo.bitrix.info недоступен, скачайте архив push-server-0.2.2.tgz и разместите его в директории /opt. Далее выполните установку:

    su -
    cd /opt
    npm install --production ./push-server-0.3.0.tgz
    

    Установка закончится строкой:

    added 73 packages, and audited 74 packages in 8s
    

  2. Для удобства дальнейшей работы выполните команды:
    su -
    ln -sf /opt/node_modules/push-server/etc/push-server /etc/push-server
  3. Скопируйте файлы сервиса и основную конфигурацию:
    su - 
    cd /opt/node_modules/push-server
    cp etc/init.d/push-server-multi /usr/local/bin/push-server-multi
    cp etc/sysconfig/push-server-multi  /etc/sysconfig/push-server-multi
    cp etc/push-server/push-server.service  /etc/systemd/system/
    ln -sf /opt/node_modules/push-server /opt/push-server
  4. В конфигурационном файле /etc/sysconfig/push-server-multi исправьте (или добавьте, если их нет) следующие параметры:
    • SECURITY_KEY – секретный ключ для подписи соединения между клиентом и пуш-сервером;

      Примечание: Длина ключа не имеет значения. В ключе можно использовать только буквы латинского алфавита и цифры (спецсимволы запрещены). Но имейте в виду, что простой короткий ключ небезопасен. Можно генерировать его, например, таким образом:
      cat /dev/urandom |tr -dc A-Za-z0-9 | head -c 128

    • RUN_DIR – директория для хранения PID файлов процесса;
    • USER/GROUP – пользователь, под которым будет запущен сервис.

    Пример настроек параметров:

    GROUP=apache
    SECURITY_KEY="PUTTHEPRIVATEKEYHERE"
    RUN_DIR=/tmp/push-server
  5. Каждый nodejs-процесс будет запущен как отдельный процесс. Сгенерируйте конфигурации:

    /usr/local/bin/push-server-multi configs pub
    /usr/local/bin/push-server-multi configs sub
    

    Сгенерированные конфигурации в формате [dw]json[/dw][di]push-server-sub-80XX.json
    push-server-pub-90XX.json[/di] будут размещены в каталоге: /etc/push-server/.

  6. Создайте каталог через tmpfiles.d:
    echo 'd /tmp/push-server 0770 apache apache -' > /etc/tmpfiles.d/push-server.conf
    systemd-tmpfiles --remove --create
  7. Создайте каталог логов:

    mkdir /var/log/push-server
    chown apache:apache /var/log/push-server
  8. В конфигурационном файле сервиса /etc/systemd/system/push-server.service измените пользователя:

    [Service]
    User=apache
    Group=apache
    ExecStart=/usr/local/bin/push-server-multi systemd_start
    ExecStop=/usr/local/bin/push-server-multi stop
    ...
    

  9. Переконфигурируйте:

    systemctl daemon-reload
    

  10. Запустите сервис:

    systemctl --now enable push-server
    

  11. Перейдите в конфигурацию Push-модуля (настройки сайта) и включите использование локального Push-сервера (последняя версия). Укажите секретный ключ, который настраивали ранее в файле /etc/sysconfig/push-server-multi.


Конфигурация сайта

Сайт

Создайте рабочий каталог:

mkdir /var/www/html/bx-site
cd /var/www/html/bx-site
wget https://www.1c-bitrix.ru/download/scripts/bitrixsetup.php
chown apache:apache /var/www/html/bx-site -R

Аналогичным образом скачайте нужный дистрибутив и установите его в каталог: /var/www/html/bx-site.

Создайте базу данных и пользователя:

create database portal;
CREATE USER 'bitrix'@'localhost' IDENTIFIED BY 'PASSWORD';
GRANT ALL PRIVILEGES ON portal.* to 'bitrix'@'localhost';

Необходимо заменить 'PASSWORD', на пароль который будете использовать для доступа к БД.

Push-server

Для работы портала необходимо настроить push-server. Сервис запущен, необходимо сделать настройки.

Настройки могут быть выполнены через [dw]административный раздел портала[/dw][di]Настройки производятся на странице http://_имя_сайта_/bitrix/admin/settings.php?lang=ru&mid=pull

Нажмите на рисунок, чтобы увеличить

Подробнее...[/di], а можно добавить их в конфигурационный файл. Покажем как это делается вторым способом.

Исправьте конфигурационный файл /var/www/html/bx-site/bitrix/.settings.php, добавив следующую секцию:

return array (
'pull' => Array(
    'value' =>  array(
        'path_to_listener' => 'http://#DOMAIN#/bitrix/sub/',
        'path_to_listener_secure' => 'https://#DOMAIN#/bitrix/sub/',
        'path_to_modern_listener' => 'http://#DOMAIN#/bitrix/sub/',
        'path_to_modern_listener_secure' => 'https://#DOMAIN#/bitrix/sub/',
        'path_to_mobile_listener' => 'http://#DOMAIN#:8893/bitrix/sub/',
        'path_to_mobile_listener_secure' => 'https://#DOMAIN#:8894/bitrix/sub/',
        'path_to_websocket' => 'ws://#DOMAIN#/bitrix/subws/',
        'path_to_websocket_secure' => 'wss://#DOMAIN#/bitrix/subws/',
	'path_to_publish' => 'http://localhost:8895/bitrix/pub/',
        'path_to_publish_web' => 'http://#DOMAIN#/bitrix/rest/',
        'path_to_publish_web_secure' => 'https://#DOMAIN#/bitrix/rest/',
        'nginx_version' => '4',
        'nginx_command_per_hit' => '100',
        'nginx' => 'Y',
        'nginx_headers' => 'N',
        'push' => 'Y',
        'websocket' => 'Y',
        'signature_key' => 'PUTTHEPRIVATEKEYHERE',
        'signature_algo' => 'sha1',
        'guest' => 'N',
    ),
),
...
Внимание, signature_key должен содержать тот же ключ, который Вы указали в /etc/sysconfig/push-server-multi в соответствующем ключе. Если все хорошо, то после перезапуска httpd:
systemctl restart httpd

Вы увидите запросы к push-server:

Request URL: ws://sitename/bitrix/subws/?CHANNEL_ID=....
Request Method: GET
Status Code: 101 Switching Protocols


Настройка окружения для ALT 8 SP Server

В главе описаны настройки окружения для операционной системы ALT 8 SP Server для установки на неё продуктов 1С-Битрикс24 коробочная версия и 1С-Битрикс: Управление сайтом. Рассмотрена установка и настройка самой операционной системы, установка необходимых пакетов и конфигурация сервисов.

Внимание! Для операций, описанных в данной главе, необходимы начальные знания серверного администрирования. Так как инсталяция на другие окружения оттестирована вендором, но не является основной платформой для эксплуатации продуктов Bitrix Framework, то возможны незадокументированные сложности в установке. Вы должны понимать суть действий, осуществляемых вами в системе при установке продуктов.

Установка и настройка ОС

Установка

Начнем с установки продукта Alt 8 SP Server. В процессе установки доступен выбор набора пакетов. Выберите набор пакетов для организации web-сервера. Остальные (например, такие как сервер печати, samba сервер и т.п.) отключите.

Внимание: Дальнейшая настройка будет показана именно на базе такой установки.

Дополнительно подключите репозитории, т.к. на установочном диске есть не все нужные нам пакеты.

Примечание: Для установки можно использовать только официальные репозитории от ALT8.

В качестве менеджера пакетов используем apt-get.

  1. Обновите систему до последней стабильной версии:
  2. su -
    apt-repo rm all
    vim /etc/apt/sources.list.d/altsp-C.list  # <-- в этом файле раскомментируйте нужное зеркало, которое зависит от типа установки
    apt-get update
    apt-get dist-upgrade
    update-kernel -t un-def
    reboot
    
  3. После перезагрузки удалите неиспользуемые ядра:
  4. su -
    remove-old-kernels -t un-def
    

По умолчанию SELinux не устанавливается для данного типа установки, поэтому каких-либо дополнительных настроек для его отключения не требуется.

Настройка портов

Обязательно нужно открыть порты:

  • 22 – ssh доступ;
  • 80 / 443 – http / https web-сервер;

Остальные порты для:

  • ntlm
  • сервера мгновенных сообщений;
  • xmpp-сервера

нужно открывать, если только они используются. Можно выбрать произвольные порты, а можно те же, что используются в CentOS:

  • 8890 / 8891 – http/https ntlm;
  • 8893 / 8894 – http/https сервер мгновенных сообщений;
  • 5222 / 5223 – http/https.

Установка пакетов

Ниже приведен весь список пакетов, который нам понадобится для 1С-Битрикс24 коробочная версия. Для 1С-Битрикс: Управление сайтом из этого набора не нужен только push-server.

Установка по шагам:

  1. Apache 2.4 и php 7.2 уже будут установлены на сервере, если Вы выбрали web-сервер на этапе установки дистрибутива.

    Если Вы выбрали минимальную установку (а не web-сервер), то просто поставьте все пакеты из списка ниже:

    su -
    apt-get install apache2-mods apache2-htcacheclean \
        apache2-cgi-bin-test-cgi apache2-htpasswd \
        apache2-httpd-prefork apache2-mod_php7 \
        apache2-mod_cache_disk apache2 \
        apache2-datadirs apache2-cgi-bin-printenv \
        apache2-htcacheclean-control apache2-html \
        apache2-ab apache2-base apache2-httpd-worker apache2-cgi-bin apache2-icons
    
    apt-get install php7-mcrypt php7-imap \
        php7 php7-xsl php7-gd php7-memcache \
        php7-exif php7-zip php7-mbstring \
        php7-fileinfo apache2-mod_php7 \
        php7-libs php7-dom php7-xmlrpc php7-dba php7-curl \
        php7-mysqli php7-openssl php7-opcache
    

    С 01.02.2023 ограничивается поддержка наших продуктов на PHP версии ниже 8.0. Рекомендуемая версия PHP – 8.1 и выше. Поэтому после установки необходимо обновить PHP до версии не ниже 8.0.

  2. Установите Nginx (версия 1.20.1):
    su -
    apt-get install nginx
    
  3. Установите MariaDB сервер (версия 10.4.20):
    su -
    apt-get install mariadb-server mariadb-client
    
  4. Установите Node и npm (push-server) (версия 14.3.0):
    su -
    apt-get install node npm
    
  5. Установите Redis (версия 5.0.4):
    su -
    apt-get install redis
    


Конфигурация Nginx

Выполним конфигурацию Nginx.

  • Рабочий каталог для сайта - /var/www/html/bx-site.
  • Пользователь для web окружения - _nginx/_webserver.

Конфигурация nginx сервера:

/etc/nginx/nginx.conf                                       # основной конфигурационный файл
            |_conf.d/upstreams.conf                         # конфигурация для upstream серверов: apache && push-server
            |_conf.d/maps-composite_settings.conf           # переменные используемые для кеша
            |_conf.d/maps.conf                              # дополнительные переменные
            |_conf.d/http-add_header.conf                   # CORS заголовки
            |_sites-available/*.conf                        # подключаем сайты
                              |_default.conf                # сайт по умолчанию (настраиваем только 80 порт)
                                    |_conf.d/bx_temp.conf   # конфигурация BX_TEMPORARY_FILES_DIRECTORY
                                    |_conf.d/bitrix.conf    # дефолтная конфигурация сайта
                              |_rtc.conf                    # проксирование запросов на push-server (публикация)

Дефолтная конфигурация сайта:

conf.d/bitrix.conf                                          # основный блоки со включенным по умолчанию кешем в файлах
        |_conf.d/bitrix_general.conf                        # отдача статики, быстрая отдача для внешних хранилищ и прочее
                |_conf.d/errors.conf                        # обработка ошибок
                |_conf.d/im_subscrider.conf                 # проксирование запросов на push-server (получение)
                |_conf.d/bitrix_block.conf                  # блокировки по умолчанию

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

Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для Nginx расположены в папке: alt8/nginx.

Разместите их в директории /etc/nginx/.

Для удобства, в конфигурационных файлах используются имена серверов httpd - apache2, сервис push push-server. По умолчанию они будут ставиться на локальную машину, поэтому прописываем следующие записи в /etc/hosts:

127.0.0.1 httpd push

Если Вы планируете развернуть данные сервисы на отдельных хостах, то нужно прописать правильный IP в /etc/hosts или сконфигурировать DNS сервер.

Запустите сервис:

systemctl --now enable nginx

Конфигурация PHP

В данной версии установки два местоположения для конфигов:

  • /etc/php/7.2/cli/php.d/ настройка CLI;
  • /etc/php/7.2/apache2-mod_php/php.d/ настройки модуля Apache.

Минимально необходимо добавить настройки для модуля Apache:

  • для модуля OPCache (файл opcache.ini) укажите:
    opcache.max_accelerated_files = 100000
    opcache.revalidate_freq = 0
  • и добавьте файл настроек zx-bitrix.ini

Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для PHP находятся в папке: alt8/php.d.

Разместите их в директории /etc/php/7.2/apache2-mod_php/php.d/.

Можно проверить, что php нашел все модули без проблем и нет ошибок в конфигурации:

php -m

Создайте каталоги для сессий и загрузки файлов:

mkdir /tmp/php_upload /tmp/php_sessions
chown apache2:_webserver /tmp/php_upload /tmp/php_sessions -R 

Каталоги в /tmp находятся под управлением tmpfiles, делаем настройку для них:

vim /etc/tmpfiles.d/bitrix.conf
----
d /tmp/php_sessions 0770 apache2 _webserver -
d /tmp/php_upload 0770 apache2 _webserver -
----

Конфигурация Apache

По умолчанию Apache настроен на дефолтный сайт в каталоге /var/www/html.

Основное, что требуется сделать для настройки конфигурации Apache:

  • изменить каталог для сайта на var/www/html/bx-site;
  • изменить порт, который слушает сервис (так как в качестве внешнего сервиса используем nginx);
  • импортировать настройки для сайта из виртуальной машины.

Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для Apache находятся в папке: alt8/httpd2.

Разместите их в директории /etc/httpd2/.

Настроить требуется три файла:

  • conf/ports-available/http.conf - указать новый порт: 8090;
  • conf/sites-available/default.conf - заменить каталог в описании сайта на var/www/html/bx-site;
  • conf/httpd2.conf - изменить группу пользователя на _webserver.

Отключите приватный Tmp каталог для сервиса httpd:

mkdir /etc/systemd/system/httpd2.service.d
echo -e "[Service]\nPrivateTmp=false\n" /etc/systemd/system/httpd2.service.d/custom.conf
systemctl daemon-reload

После этого запустите сервис:

systemctl --now enable httpd2


Конфигурация MariaDB

Для конфигурации MariaDB требуется выполнить такие настройки:

  • transaction-isolation изменить на READ-COMMITTED;
  • innodb_flush_method установить равным O_DIRECT (желательная, но не обязательная настройка);
  • innodb_flush_log_at_trx_commit установить равным 2 (желательная, но не обязательная настройка).

Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для MariaDB находятся в папке: alt8/my.cnf.d.

Разместите их в директории /etc/my.cnf.d/.

Запустите сервис:

systemctl --now enable mariadb

Настройте пароль для доступа к серверу и прочие опции безопасности через скрипт:

mysql_secure_installation
.....

Set root password? [Y/n] y
New password:
Re-enter new password:
Password updated successfully!
Reloading privilege tables..
 ... Success!


By default, a MariaDB installation has an anonymous user, allowing anyone
to log into MariaDB without having to have a user account created for
them.  This is intended only for testing, and to make the installation
go a bit smoother.  You should remove them before moving into a
production environment.

Remove anonymous users? [Y/n] y
 ... Success!

Normally, root should only be allowed to connect from 'localhost'.  This
ensures that someone cannot guess at the root password from the network.

Disallow root login remotely? [Y/n] y
 ...


Конфигурация Redis

Данный сервис нам нужен для организации Push-сервера.

Основное, что нам важно установить в конфигурации:

  • включить файловый сокет для работы;
  • отключить сброс данных на диск (для работы Push-сервера нам не нужна эта возможность);
  • установить группу пользователя.

Все конфигурационные файлы можно скачать в архиве. Конфигурационные файлы для Redis находятся в папке: alt8/redis.

Разместите их в директории /etc/redis/ и выполните:

su -
usermod -g apache2 \_redis
chown root:apache2 /etc/redis/ /var/log/redis/
mkdir /etc/systemd/system/redis.service.d
echo -e '[Service]\nGroup=apache2' > /etc/systemd/system/redis.service.d/custom.conf
systemctl daemon-reload

Запустите сервис:

systemctl --now enable redis

Конфигурация Push-server

Схема работы:

 -----------------------                                   ---------------------------------------------------
| nginx: 0.0.0.0:80     | -> /bitrix/sub|/bitrix/subws -> | node server.js --config push-server-sub-80XX.json |
 -----------------------                                   ---------------------------------------------------

 -----------------------                     ---------------------------------------------------
| nginx: 127.0.0.1:8895 | -> /bitrix/pub -> | node server.js --config push-server-pub-90XX.json |
 -----------------------                     ---------------------------------------------------

Nginx проксирует запрос на push-сервис выбранного типа. Публикация сообщений ограничена для локальной ноды.

Nodejs-процессы делятся на два типа:

  1. Процессы, отвечающие за подключение пользователя к выбранному каналу и получение им сообщений. Слушают порты 8010-8015;
  2. Процессы, отвечающие за отправку сообщения в канал. Слушают порты 9010-9011.

Для запуска Push-сервера нам понадобятся:

  • nodejs & npm ;
  • архив сервиса и его модулей.

Выполните действия:

  1. Скачайте архив с репозитория repo.bitrix.info
    wget https://repo.bitrix.info/vm/push-server-0.3.0.tgz
    и разместите его в директории /opt. Выполните установку:
    su -
    cd /opt
    npm install --production ./push-server-0.3.0.tgz
    

    Установка закончится строкой:

    + push-server@0.3.0
    added 144 packages from 151 contributors and audited 144 packages in 10.388s
    
  2. Выполните (исключительно для удобства):
    su -
    ln -sf /opt/node_modules/push-server/etc/push-server /etc/push-server
    
  3. Скопируйте файлы сервиса и основную конфигурацию:
    su - 
    cd /opt/node_modules/push-server
    cp etc/init.d/push-server-multi /usr/local/bin/push-server-multi
    cp etc/sysconfig/push-server-multi  /etc/sysconfig/push-server-multi
    cp etc/push-server/push-server.service  /etc/systemd/system/
    ln -sf /opt/node_modules/push-server /opt/push-server
    
  4. Отредактируйте конфигурационный файл /etc/sysconfig/push-server-multi. В нём нужно исправить/добавить параметры:
    • USER/GROUP - пользователь, под которым будет запущен сервис;
    • SECURITY_KEY - cекретный ключ для подписи соединения между клиентами и пуш-сервером;
    • RUN_DIR - директория для хранения PID файлов процесса.

    Пример настроек параметров:

    USER=apache2
    GROUP=_webserver
    SECURITY_KEY="SECURITYKEY123456"
    RUN_DIR=/tmp/push-server
    
  5. Каждый nodejs процесс будет запущен как отдельный процесс. Сгенерируйте конфигурации:
    /usr/local/bin/push-server-multi configs pub
    /usr/local/bin/push-server-multi configs sub
    

    Сгенерированные конфигурации в формате [dw]json[/dw][di]push-server-sub-80XX.json
    push-server-pub-90XX.json[/di] будут размещены в каталоге: /etc/push-server/.

  6. Создайте каталог через tmpfiles.d:
    echo 'd /tmp/push-server 0770 apache2 _webserver -' > /etc/tmpfiles.d/push-server.conf
    systemd-tmpfiles --remove --create
    
  7. Создайте каталог логов:
    mkdir /var/log/push-server
    chown apache2:_webserver /var/log/push-server
  8. Измените пользователя в конфигурационном файле сервиса: /etc/systemd/system/push-server.service

    [Service]
    User=apache2
    Group=_webserver
    ExecStart=/usr/local/bin/push-server-multi systemd_start
    ExecStop=/usr/local/bin/push-server-multi stop
    ....
    
  9. Переконфигурируйте:
    systemctl daemon-reload
    
  10. Запустите сервис:
    systemctl --now enable push-server
    
  11. Перейдите в конфигурацию push модуля (настройки сайта) и включите использование локального push-сервера (последняя версия). Дополнительно нужно будет указать секретный ключ SECURITY_KEY, который мы настраивали выше в файле /etc/sysconfig/push-server-multi.


Конфигурация сайта

Сайт

  1. Создайте рабочий каталог:
    mkdir /var/www/html/bx-site
    cd /var/www/html/bx-site
    wget https://www.1c-bitrix.ru/download/scripts/bitrixsetup.php
    chown apache2:_webserver /var/www/html/bx-site -R
    Аналогичным образом можно скачать нужный дистрибутив и установить его в каталог: /var/www/html/bx-site.
  2. Создайте базу данных и пользователя:
    reate database portal;
    CREATE USER 'bitrix'@'localhost' IDENTIFIED BY 'PASSWORD';
    GRANT ALL PRIVILEGES ON portal.* to 'bitrix'@'localhost';
    Необходимо заменить PASSWORD на пароль, который будете использовать для доступа к БД.

Push-server

Для работы портала необходимо настроить push-server. Настройки могут быть выполнены через [dw]административный раздел портала[/dw][di]Настройки производятся на странице http://_имя_сайта_/bitrix/admin/settings.php?lang=ru&mid=pull

Нажмите на рисунок, чтобы увеличить

Подробнее...[/di], а можно добавить их в конфигурационный файл. Покажем как это делается вторым способом.

Исправьте конфигурационный файл /var/www/html/bx-site/bitrix/.settings.php, добавив следующую секцию:

return array (
'pull' => Array(
    'value' =>  array(
        'path_to_listener' => 'http://#DOMAIN#/bitrix/sub/',
        'path_to_listener_secure' => 'https://#DOMAIN#/bitrix/sub/',
        'path_to_modern_listener' => 'http://#DOMAIN#/bitrix/sub/',
        'path_to_modern_listener_secure' => 'https://#DOMAIN#/bitrix/sub/',
        'path_to_mobile_listener' => 'http://#DOMAIN#:8893/bitrix/sub/',
        'path_to_mobile_listener_secure' => 'https://#DOMAIN#:8894/bitrix/sub/',
        'path_to_websocket' => 'ws://#DOMAIN#/bitrix/subws/',
        'path_to_websocket_secure' => 'wss://#DOMAIN#/bitrix/subws/',
	'path_to_publish' => 'http://localhost:8895/bitrix/pub/',
        'path_to_publish_web' => 'http://#DOMAIN#/bitrix/rest/',
        'path_to_publish_web_secure' => 'https://#DOMAIN#/bitrix/rest/',
        'nginx_version' => '4',
        'nginx_command_per_hit' => '100',
        'nginx' => 'Y',
        'nginx_headers' => 'N',
        'push' => 'Y',
        'websocket' => 'Y',
'signature_key' => 'SECURITYKEY123456',
        'signature_algo' => 'sha1',
        'guest' => 'N',
    ),
),
...
Обратите внимание: signature_key должен содержать тот же ключ, который был указан в /etc/sysconfig/push-server-multi в соответствующем ключе. Если все хорошо, то после перезапуска httpd:
systemctl restart httpd2

Вы увидите запросы к push-server:

Request URL: ws://sitename/bitrix/subws/?CHANNEL_ID=....
Request Method: GET
Status Code: 101 Switching Protocols


Монитор производительности

Монитор производительности показывает скорость работы сайта на хостинге, выявляет узкие места (скрипты на сайте, которые потребляют наибольшее число системных ресурсов) и основные ошибки настройки сервера.

Подробнее про оптимальную настройку сервера можно посмотреть в главе [ds]Конфигурирование веб-систем для оптимальной работы[/ds][di]Типовые настройки серверного программного обеспечения рассчитаны на минимальное оборудование и статические HTML-приложения. Внесение некоторых конфигурационных изменений в серверное ПО позволяет в несколько раз увеличить производительность системы в целом, сократить время генерации страниц, увеличить устойчивость системы к пиковым нагрузкам.

Подробнее ...[/di].

Настройки модуля

  Настройки модуля

Глобальные параметры модуля определяются на странице настроек Монитор производительности (Настройки > Настройки продукта > Настройки модулей > Монитор производительности).

Нажмите на рисунок, чтобы увеличить

Для настройки модуля доступны следующие опции:

  • Максимальная длина URL при отображении – опция позволяет указать максимальное количество символов, которое будет использоваться для отображения URL'ов на административных страницах, относящихся к модулю.
  • Вести журнал предупреждений PHP – регистрация ошибок PHP, отображение ошибок на странице [ds]Ошибки PHP[/ds][di]На странице Монитор производительности: журнал ошибок PHP ((Настройки > Производительность > Ошибки PHP (N)) можно просмотреть журнал регистрации ошибок PHP, где N – общее количество ошибок.

    Подробнее ...[/di].
  • Вести журнал кеширования – регистрация информации о файлах кеша, просмотр информации – на странице [ds]Кеширование[/ds][di]На странице Кеширование (Настройки > Производительность > Кеширование) можно просмотреть информацию о кеше и его файлах.

    Подробнее ...[/di].
  • Записывать только операции с большими файлами кеша – сохранение операций только с файлами кеша, размер которых больше, чем указано в поле Размер файла кеша больше которого считать его большим.
  • Вести журнал SQL запросов – регистрация SQL запросы, просмотр записей на странице [ds]SQL Запросы[/ds][di]На странице Монитор производительности: запросы (Настройки > Производительность > SQL Запросы) можно просмотреть отчет по запросам SQL:

    Подробнее ...[/di].
  • Сохранять стек вызова для SQL запросов – сохранение стека запросов, просмотр на странице SQL Запросы.
  • Записывать только медленные SQL запросы: – запись запросов с продолжительностью более чем указанные в поле Время исполнения после которого считать запрос медленным.
  • Включить монитор – запуск монитора производительности в выбранное время. Действие аналогично опции Тестировать производительность на странице Панель производительности (Настройки > Производительность > Панель производительности).

    Если монитор включен, то в поле Активность монитора будет отображен статус Работает, при этом ниже будет выведена информация: До окончания активности осталось: (часов:минут:секунд).

Вкладка Генератор таблетов предназначена для разработчиков. На ней включается автоматическая генерация таблетов для ORM и настраиваются параметры генератора.

Настройка прав доступа производится типовым для Bitrix Framework способом. Подробнее про [ds]настройку доступа[/ds][di]Настройка прав доступа к модулям системы позволяет определить диапазон допустимых действий пользователя над модулем и его контентом. Управление правами доступа к модулям выполняется:

Подробнее ...[/di] к модулям.



Публичная часть модуля

  Просмотр статистики "с лица"

Для оценки производительности в публичной части сайта используется кнопка [dw]Отладка[/dw][di][/di], которая позволяет отображать статистику прямо на странице:

Нажмите на рисунок, чтобы увеличить

Примечание:
  • Для административной части сайта также доступна Статистика SQL-запросов, Время исполнения страницы. [dw]Отображение статистики[/dw][di][/di] включается с помощью меню кнопки Отладка в публичной части сайта.
  • До версии 20.0.1300 также отображалась Статистика компрессии. С указанной версии модуль Компрессия удалён из продукта.

  Что отображается в статистике

Статистика в целом по странице отображается внизу страницы:

  • [dw]Информация для опций[/dw][di][/di] Время исполнения страницы и Статистика компрессии
  • Информация для опции [dw]Статистика SQL-запросов[/dw][di][/di].

    Ссылка Всего SQL запросов позволяет отобразить более подробную информацию обо всех запросах на странице в специальной форме (см. ниже).

  • При одновременно отмеченных опциях Время исполнения страницы и Статистика SQL-запросов внизу страницы будет доступна ссылка [dw]Время создания страницы[/dw][di][/di], которая позволит отобразить статистику страницы в специальной форме:

    Примечание: При отмеченной опции Суммарная статистика по ссылке Время создания страницы будет доступна более [dw]подробная информация[/dw][di]Ссылки в верхней части формы позволяют отобразить в нижней части формы список задействованных
    включаемых областей. Ссылки в нижней части формы позволяют отобразить информацию о запросах.

    [/di].

  Информация о запросах

Для просмотра информации о запросах компонента, необходимо выбрать пункт меню Статистика включаемых областей и затем использовать ссылку вида Запросов: n, отображаемую в информационной области, которая расположена рядом с компонентом:

Откроется форма, в которой будет отображена [dw]информация о запросах[/dw][di]В нижней части формы отображается детальная информация о каждом запросе. Для отображения информации о другом запросе компонента необходимо использовать ссылку в верхней части формы.[/di]:

  Кеш

Данные о кеше выводятся во всплывающем окне:



Административные страницы модуля

В административной части сайта к модулю Монитор производительности относятся следующие страницы, расположенные в разделе Производительность (Настройки > Производительность).

Скорость сайта

  Следите за скоростью работы сайта

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

Скорость сайта - комплексный показатель комфортности работы с сайтом для посетителей. [dw]Инструмент[/dw][di]Доступен после установки обновления main 14.9.0 и только для русских версий продуктов "1C-Битрикс: Управление сайтом".[/di] учитывает качество разработки сайта, качество хостинга и доступность сайта по сети. Рассчитывается для 1000 последних посетителей сайта. Скорость сайта фактически показывает, как быстро отобразился сайт для большинства из этих 1000 посетителей.

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

На Рабочем столе в административной части есть гаджет, показывающий текущую скорость загрузки страниц вашего сайта:

Как считается Скорость сайта

  Страница Скорость сайта

Для просмотра подробной информации о скорости загрузки сайта перейдите на страницу Скорость сайта (Настройки > Производительность > Скорость сайта).

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

Чтобы оперативно контролировать скорость работы сайта прямо с этой же страницы можно перейти к настройкам в [ds]Панели производительности[/ds][di]Для оценки производительности необходимо перейти в раздел Монитор производительности (Настройки > Производительность > Панель производительности).

Подробнее ...[/di], [ds]Композитного сайта[/ds][di]Для включения технологии необходимо понять какой режим вы хотите использовать (автоматический или ручной) и нажать кнопку включения на нужной закладке. Активизация одного из режимов делает неактивной кнопку включения другого режима.

Подробнее ...[/di] и [ds]CDN[/ds][di]После включения поддержки CDN ссылки на статические файлы сайта (картинки, файлы стилей css, скрипты js) будут заменены. Вместо локальных URL'ов будут использоваться служебные имена серверов сети CDN. При этом не потребуется вносить никакие изменения в DNS и не нужно заботиться о сбросе кеша CDN при обновлении файлов.

Подробнее ...[/di].

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

На диаграмме показано время, с которым страницу увидел посетитель, и количество страниц, загруженных с таким временем. Если подвести курсор к конкретному столбцу диаграммы, то будут отображены 10 страниц с худшими показателями времени загрузки.

Еще ниже представлен график, отображающий статистику последних посещений сайта на разных этапах загрузки страницы:

  1. DNS (DNS Lookup). Хоть в большинстве своем, запрос к DNS по скорости близок к нулю, так как данные кешируются и браузерами, и самими серверами DNS (локальными, серверами провайдера и т.п.) инструмент "скорость сайта" учитывает этот параметр и выводит его на график.
  2. Дальше происходит Подключение к серверу (Connect to Server) и разрешение на дальнейшие действия. Это некое "рукопожатие", время которого также выводится на график.
  3. Следующий шаг - это Ответ сервера (Request Document). Чем дальше от клиентов находится сервер, тем больше будет этот показатель. По нему можно ориентироваться, сколько теряется времени на ответ сайта посетителю.
    Данный ответ может быть не разовой операцией, ведь чем больше запросов делает страница к серверу, чтобы произвести загрузку ресурсов и т.п., тем дольше все будет отрабатываться.
  4. Дальше происходит Загрузка HTML (Receive Document). Здесь учитывается время загрузки HTML-страницы для ее последующей обработки.
  5. После того, как страница загрузилась, начинается процесс ее обработки - Обработка HTML ([dw]часть блока[/dw][di]Обработка HTML[/di] Process the Document and Load the DOM) и загрузки ресурсов.
    Вот здесь при наличии ошибок в разработке, процесс загрузки страницы может очень "просесть", что будет заметно на графике.
  6. Далее следует Отрисовка страницы ([dw]сумма процессов[/dw][di]Отрисовка страницы[/di]), когда браузер обрабатывает содержимое страницы (синтаксический анализ HTML, CSS, обработка элементов JavaScript и отображение страницы) после загрузки её с сервера и до начала отрисовки.

Примечание: Все графики можно совместить, или отслеживать их в разрезе каждой страницы, поднося курсор к нужным узлам.

  Документация по теме


Страницы и компоненты

Чтобы собиралась статистика по нагрузке страниц, должен быть включен Монитор производительности (в настройках модуля, опция Включить монитор).

  Страницы

На странице Монитор производительности: страницы (Настройки > Производительность > Страницы) можно просмотреть отчет по нагружаемости страниц:

Монитор производительности: страницы

Переход по ссылке с названием страницы позволяет просмотреть все её хиты на странице Хиты.

  Компоненты

На странице Монитор производительности: компоненты (Настройки > Производительность > Компоненты) можно просмотреть отчет по используемым на страницах сайта компонентам или включаемым областям:

Монитор производительности: компоненты

Переход по ссылке в графе Запросы позволяет просмотреть все SQL Запросы компонента на странице SQL Запросы.

Здесь же можно включить группировку по компонентам, если необходимо увидеть общую картину по использованию того или иного компонента.



Хиты

Учёт хитов

На странице Монитор производительности: хиты (Настройки > Производительность > Хиты) выводится отчет по [dw]хитам[/dw][di]Хит - это запрос к веб-серверу для получения файла (веб-страницы, изображения, JavaScript'а, таблицы стилей и т. д.).

Подробнее...[/di]:

Монитор производительности: хиты

Переход по ссылке >> позволяет перейти на желаемую страницу в публичную часть сайта и просмотреть [dw]детальную статистику[/dw][di][/di].

Примечание: Нажав кнопку [dw]Отладка[/dw][di][/di] или выбрав пункт меню Суммарная статистика (Отладка > Суммарная статистика) на Панели управления в публичной части сайта и перейдя по ссылке >> со страницы Монитор производительности: хиты (Настройки > Производительность > Хиты), можно просмотреть [dw]более детальную статистику[/dw][di][/di].

Переход по ссылке с названием страницы (или по ссылке в графе Запросы) позволяет просмотреть все SQL запросы хита на странице SQL Запросы.

Переход по ссылке в графе Компоненты позволяет просмотреть отчет по используемым компонентам для хита на странице Компоненты.


SQL запросы

Отчёт по SQL запросам

На странице Монитор производительности: запросы (Настройки > Производительность > SQL запросы) отображается отчет, если в настройках модуля включены опции [dw]Вести журнал запросов и Сохранять стек вызова для SQL запросов.[/dw][di][/di]:

Двойной клик по строке таблицы с запросом или пункт меню действий План исполнения позволит просмотреть план исполнения запроса [dw]в новом окне[/dw][di][/di].


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


Кеширование

Файлы кеша

Информация о файлах кеша доступна при включённой в настройках модуля Монитор производительности опции [dw]Вести журнал кеширования[/dw][di][/di]. В этом случае эта информация отобразится на странице Кеширование (Настройки > Производительность > Кеширование).

Кнопка Группировка позволяет выбрать режим отображения данных в таблице:

  • Без группировки - отображается вся информация о кеше, без каких-либо группировок;
  • Группировка по компонентам - информация о кеше сгруппирована по названию компонентов;
  • Группировка по типу - информация о кеше сгруппирована по типу кеша (управляемый / неуправляемый);
  • Группировка по каталогу - информация о кеше сгруппирована по каталогам, в которых хранятся файлы кеша;
  • Группировка по файлу - информация о кеше сгруппирована по файлам, в которых хранятся кеш.

Ссылки в таблице позволяют применять фильтр, согласно выбранному полю. Для полей таблицы в колонке Файл ссылка с названием позволяет перейти к просмотру содержимого этого файла.

Документация по теме:


Таблицы в базе данных

  Таблицы БД

Просмотреть их можно наа странице Таблицы в базе данных (Настройки > Производительность > Таблицы ):

Показ столбца Размер индексов добавлен с версии модуля 23.0.0.

Работая со списком таблиц вы можете использовать:

  • [dw]Групповые действия[/dw][di]Групповые действия[/di] для применения оптимизации или преобразований сразу к нескольким таблицам;
  • [dw]Фильтры[/dw][di][/di]. После введения текста в поле в списке останутся только те таблицы, что содержат указанный текст.

Переход по ссылке с именем таблицы позволяет просмотреть её содержимое.

  Работа с записями таблицы

При открытии таблицы из списка, вы увидите список всех её записей. На такой странице доступны следующие возможности:

Примечание: с версии модуля 23.0.0 обновлен интерфейс работы с таблицами. Далее в уроке показаны скриншоты из нового интерфейса.
  • Инструмент [ds]Фильтр+поиск[/ds][di]Найти среди большого количества однотипных элементов нужный товар, новость, баннер – да все, что угодно! – поможет удобный настраиваемый инструмент Фильтр+поиск.

    Подробнее в курсе Контент-менеджер.[/di] – пригодится для поиска нужных вам записей или фильтрации списка.
  • Для таблиц модуля Инфоблоки, Поиск и Мгновенные сообщения реализована выборка строк с фильтром по текущему значению в связанных таблицах.

    Поясним на примере. Выберем таблицу b_search_content и в контекстном меню конкретной записи (в примере: ID=41) укажем выборку строки [dw]из связанной таблицы[/dw][di]Нажмите на рисунок, чтобы увеличить[/di] (b_search_content_text). Выполнится выборка тех строк таблицы b_search_content_text, где SEARCH_CONTENT_ID=41.

    Нажмите на рисунок, чтобы увеличить

  • Вывод [dw]информации[/dw][di][/di], полученной из связанной таблицы (при наведении курсора на значение внешнего ключа).
  • По команде [dw]Изменить[/dw][di][/di] – [dw]редактирование записи и сброс управляемого кеша[/dw][di][/di] после сохранения записи.
  • [dw]Редактирование сериализованных значений[/dw][di]В системе должно быть установлено расширение Tokenizer.[/di] в альтернативном представлении.
  • [dw]Создание новых записей[/dw][di][/di] в таблицах с автоинкрементным первичным ключом.
Система запоминает просмотренные вами таблицы. В режиме просмотра записей, на контекстной панели в правом верхнем углу будет доступно меню Последние таблицы (n), которое позволяет быстро и удобно переключаться между ними. На странице со списком всех таблиц также отображаются [dw]Последние просмотренные таблицы[/dw][di][/di].


Индексы

  Индексы

Заочно нельзя сказать какие [ds]индексы[/ds][di]Поиско́вый и́ндекс - структура данных, которая содержит информацию о документах и используется при поиске на сайте.

Подробнее ...[/di] необходимо создавать, надо всегда рассматривать конкретную ситуацию. Они нужны для конкретных выборок на конкретных проектах. В зависимости от архитектуры и логики проекта медленные запросы получаются у каждого свои, и для них нужны свои индексы, часто составные.

Страницы Анализ индексов и Список индексов - инструмент анализа и рекомендаций по созданию индексов.

  Создание индекса (видеоурок)

  Анализ индексов

Анализ индексов лучше производить после получения списка медленных запросов. Для этого в настройках модуля включите [dw]соответствующую опцию[/dw][di][/di] и установите время, после которого запрос будет считаться медленным. Рекомендуемое время работы монитора - [dw]сутки[/dw][di] Данное время работы можно установить, если отмечена опция Записывать только медленные SQL запросы. В противном случае время работы монитора составляет до 1 часа. [/di], но, опять же, надо учитывать реалии конкретного проекта.

После получения списка медленных запросов на странице Анализ индексов (Настройки > Производительность > Индексы > Анализ индексов) необходимо воспользоваться кнопкой Выполнить анализ собранных SQL запросов и отобразится список всех запросов, которые были совершены за это время, отсортированных по имени таблицы:

В общем списке в первую очередь нужно обращать внимание на запросы с большей продолжительностью и на большое их количество. Но и в случае больших величин у этих параметров не на каждый запрос стоит создавать индекс (возможно нужно просто исправить код компонента). Косвенным критерием успешности создания индекса служит время выполнения запроса до и после создания индекса.

При необходимости можно посмотреть план выполнения любого запроса. Команда Детальный анализ позволяет перейти к анализу конкретного запроса и созданию его индекса.

На этой странице жирным шрифтом выделяются таблица и колонки, к которым обращается запрос.

[dw]Структура таблицы[/dw][di][/di] - информационная закладка. Главное в ней - размер таблицы. И если размер большой (к примеру, больше 100 мегабайт), то построение и удаление индексов лучше проводить в часы наименьшей нагрузки на сайт.

[dw]Анализ запросов[/dw][di][/di] - закладка с собственно анализом запроса. При принятии решения о создании индекса учитывайте, селективен ли этот запрос и процент [dw]селективности[/dw][di]Селективность индекса – это отношение количества различных проиндексированных значений к общему количеству строк в таблице. Индекс с высокой селективностью хорош тем, что позволяет Базе данных при поиске соответствий отфильтровывать больше строк. Подробнее...[/di]. Информация об этом выводится в таблице.

Создание индекса - закладка, на которой непосредственно принимается решение о создании (или нет) индекса. Те запросы, по которым не нужно создавать индекс, можно внести в список Не предлагать создавать.

Запросы, по которым принято решение, пропадают из списка запросов и появляются на странице Список индексов.

  Список индексов

Страница Список индексов (Настройки > Производительность > Индексы > Список индексов) отображает результаты ваших решений по анализу тех или иных запросов. "Зелёный" статус - индекс создан, "красный" статус - индекс не будет создаваться.



Настройки и ошибки PHP

  Настройки

На странице Монитор производительности: настройки PHP (Настройки > Производительность > PHP) отображается сводная таблица Параметры окружения с анализом параметров PHP.

Монитор производительности: настройки PHP

С помощью ссылки Настройки PHP можно перейти на страницу с подробной информацией (phpinfo).

  Ошибки

На странице Монитор производительности: журнал ошибок PHP (Настройки > Производительность > Ошибки PHP (N)) можно просмотреть журнал регистрации ошибок PHP, где N - общее количество ошибок.

Монитор производительности: сервер БД

Примечание: Данная страница отображается, только если в настройках модуля Монитор производительности указана опция Вести журнал предупреждений PHP.

Журнал ошибок PHP ошибок хранится в базе. Удалить журнал ошибок PHP можно с помощью опции [dw]Удалить собранные ранее данные[/dw][di]Доступна только при отключенном мониторе

[/di] в настройках модуля Монитор производительности.



Сервер БД

Наблюдаем за сервером

На странице Монитор производительности: сервер БД (Настройки > Производительность > Сервер БД) отображается сводная статистика производительности сервера базы данных и рекомендации:

Монитор производительности: сервер БД

Значения, отличающиеся от рекомендуемых, выделяются цветом:



История замеров производительности

История работы над производительностью

На странице История замеров производительности (Настройки > Производительность > История) выводятся результаты прошлых замеров производительности.

В таблице отображается производительность системы с указанием даты замера.


Панель производительности

Вы узнаете, как протестировать производительность, определить проблему и поправить "узкие" места сайта.

Панель производительности: поиск "узких" мест сайта

  Поиск "узких" мест сайта

Для оценки производительности перейдите в раздел Монитор производительности (Настройки > Производительность > Панель производительности).

Нажмите на рисунок, чтобы увеличить

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

Проблема далеко не всегда кроется в хостинге, она может быть и в самом сайте. Модуль позволяет определить проблему и исправить её. Для этого требуется запустить тест производительности в течение некоторого времени – для [dw]малопосещаемых проектов[/dw][di]Если сайт малопосещаемый, рекомендуется самому открывать различные страницы сайта для сбора статистики модуля.[/di] – час, для посещаемых можно выбрать меньшее время. Система будет фиксировать посещения и собирать статистику о времени выполнения каждой страницы, числе SQL запросов и другие параметры.

Показатель производительности - величина, обратная времени исполнения ядра продукта (среднему на 10 измерений).

Если [dw]Производительность = 18,66[/dw][di][/di], то публичная страница сайта с пустым шаблоном (например, версия для печати), с пустой рабочей областью будет создаваться за 1/18,66 или 0,0536 сек. Если говорить проще, то сервер сгенерирует 18 (пустых, но с подключением ядра) страниц в секунду. То есть чем выше число, тем производительнее работает сайт.

Умножив 18 (страниц в секунду) на 60 получим, что сервер может генерировать около 1080 пустых, но с подключением ядра, страниц в минуту. Так, если посещаемость ресурса составляет всего 1000 человек в день, то производительность сервера будет [dw]на пределе[/dw][di]Предполагается, что эта 1000 посетителей вдруг зашла на сайт одномоментно.[/di]. Естественно, в реальных условиях производительность будет ниже, в зависимости от "нагруженности" различных страниц сайта, нагрузки на сам сервер и других условий.

Показатель производительности не вычисляется на основе производительности файловой системы, работы базы, сессий и почты. Эти цифры нужны для того, чтобы помочь системному администратору найти узкое место (если такое есть). Величина производительности всегда обратна величине среднего времени отклика.

  Что важно знать

Важно: Абсолютные цифры монитора производительности сами по себе ничего не значат. Они нужны только для того, чтобы помочь найти и решить [dw]проблему производительности[/dw][di]Например, известно, что страница или раздел сайта открываются долго (несколько секунд и дольше). Тогда оценка монитора производительности покажет, что в данном случае является препятствием.[/di].


Если какая-то из подсистем сайта работает медленно, возможно, проблема не в самом сайте, а в конфигурации ОС или неустановленных необходимых драйверах. Это комплексная задача, которая должна решаться квалифицированным системным администратором. Можно взять мощное железо и получить низкие цифры.

При оценке производительности учтите что:

  • Оценка зависит от редакции продукта.
    Раз мы замеряем время работы ядра, очевидно, оно будет зависеть от размера ядра. Для редакции «Бизнес» со всеми включенными модулями оценка всегда будет ниже, чем на «Старте» на том же оборудовании. Эталонная оценка в Мониторе производительности продукта делалась на редакции «Бизнес».
  • Результат зависит от пользовательских функций в /bitrix/php_interface/init.php.
    Указанный [dw]файл[/dw][di]Примечание: файл init.php подключается при открытии каждой страницы сайта и служит для запуска обработчиков событий или подключения каких-либо дополнительных функций. Файл не является обязательным (т.е. его может не быть в папке /bitrix/php_interface).[/di] подключается на каждый хит, в том числе и при работе административной части. Файл /bitrix/php_interface/init.php не должен содержать запросы к БД и любые другие ресурсоемкие операции.
  • Оценка будет меняться в зависимости от нагрузки.
    Чем больше нагружен сервер, тем ниже будет оценка. Но даже при пиковой нагрузке она не должна опускаться ниже приемлемого уровня, чтобы можно было говорить, что сервер справляется (например, не ниже 10 единиц, т.е. 0,1 сек. на страницу).
  • Показатель производительности не показывает возможности масштабирования системы.
    Процесс веб-сервера работает на одном ядре, а значит, когда измеряется производительность без нагрузки, число ядер процессора не влияет на результат. Другое дело под нагрузкой: многоядерная система в состоянии сохранить высокие показатели.
  • Для базы данных на отдельном сервере оценка производительности будет ниже.
    Когда речь идет о [dw]кластере[/dw][di]Кла́стер (англ. cluster - скопление, кисть, рой) - объединение нескольких однородных элементов, которое может рассматриваться как самостоятельная единица, обладающая определёнными свойствами. В рамках нашего рассказа имеется в виду кластер серверов.[/di], мы имеем масштабируемую систему: при увеличении нагрузки она должна сохранять хорошие показатели. Но при моментальном замере времени открытия страниц без нагрузки мы неизбежно увидим небольшое замедление за счет межсерверных коммуникаций.

Вкладка Конфигурация

  Вкладка Конфигурация

Во вкладке отображаются текущие показатели производительности подсистем сервера и сравнение их с показателями эталонной системы.

Нажмите на рисунок, чтобы увеличить

Если какая-то подсистема не удовлетворяет оптимальным условиям, то будет выведена ссылка с рекомендациями по исправлению в колонке Примечание.

  Основные ошибки конфигурации

  • Не установлен акселератор php.
    Наличие акселератора php просто жизненно необходимо, даже без дополнительных настроек страницы открываются в три раза быстрее, во столько же раз снижается нагрузка на процессор. Поддерживается акселератор OPcache.
  • Включено ограничение open_basedir.
    На shared хостинге сложно отделить клиентов друг от друга. Самый простой вариант: включить open_basedir, тогда на все операции с файлами происходит дополнительная проверка пути. Это существенно снижает производительность. Решением будет использовать собственный экземпляр Apache для каждого пользователя или установка дополнительных модулей на сервер для ограничения доступа. В этом случае ограничение open_basedir ставить не нужно! Доступ ограничивается системой для пользователя веб-сервера.
  • Не установлен или не настроен NGINX.
    Хоть это напрямую не влияет на оценку производительности, но чрезвычайно важно для нагруженных проектов: лучше когда статика (картинки, стили, ява скрипты) отдаётся NGINX'ом и не обрабатываться Apache. Посмотрите логи доступа Apache: там не должно быть ни одного запроса к статике!
  • Не настроена база данных.
    По возможности всегда используйте формат данных InnoDB, рекомендуемые настройки смотрите на странице монитора производительности Сервер БД.
  • Стоят не оригинальные драйвера оборудования.
    Особенно актуально для RAID контроллеров: при установке на Linux системах обычно предлагает к установке open source драйвера, которые не всегда достаточно эффективно работают с оборудованием. Всегда ставьте оригинальные драйвера с сайта разработчика.
  • PHP как CGI.
    PHP, запускаемый как CGI (не FastCGI) – плохая схема.
    На каждое обращение к php-скрипту запускается новый процесс интерпретатора PHP. Все это работает очень медленно, производительность сайта будет крайне низкой.

  Как читать оценку подсистем

Монитор производительности не имеет прямого доступа к системным ресурсам, поэтому оценки, полученные средствами PHP, в большей степени отражают работу PHP, чем сервера.

  • Конфигурация - собственно, оценка производительности.
  • Среднее время отклика - число, обратное оценке производительности.
  • Процессор (CPU). Делается большое число простых математических вычислений. Задача не распараллеливается, поэтому идет оценка работы одного ядра процессора. Когда сайт работает на VPS, здесь часто можно увидеть, что "зажат" процессор.
  • Файловая система. Этот тест показывает не столько работу диска, сколько работу PHP с файлами: создается, исполняется, удаляется большое число простых файлов. Данный показатель зависит от производительности файловой системы и эффективности работы PHP акселератора. В целом хорошо показывает, как работает PHP на данной конфигурации (без учета работы базы).
  • Почтовая система. Отправляется тестовое письмо на hosting_test@bitrix.ru. Содержимое письма: "This is test message. Delete it." Никакая служебная информация не передается! Если настроена отправка почты на cron, этот показатель можно игнорировать.
  • Время старта сессии. Сессия стартует на каждый хит, поэтому это время будет прибавляться к работе каждой страницы. Проблемы обычно возникают, когда меняются настройки хранения сессий PHP так, что скапливаются сотни тысяч файлов сессий.
  • База данных (чтение/запись/удаление). Отправляется большое число простых запросов в базу. Это очень утрированный тест: он не показывает, как база будет работать со сложными запросами на больших объемах данных. Очевидно, что для базы данных на локальной машине цифры будут выше, чем для базы на отдельном сервере. Это нормально.


Вкладка Битрикс

Во вкладке отображаются текущие настройки продукта, непосредственно влияющие на производительность, с соответствующими рекомендациями для оптимальной работы продукта.

Нажмите на рисунок, чтобы увеличить

Клик по рекомендации – переход на страницу системы, где выполняются эти настройки.



Вкладка Разработка

  Разработка

В этой вкладке отображается список страниц сайта, среднего времени выполнения и предполагаемых ошибок разработчика.

Нажмите на рисунок, чтобы увеличить

Например, ошибка, которую предлагается исправить, - некэшированные компоненты.

Примечание: Для просмотра информации об ошибках используйте ссылку в колонке Ошибки разработки.

Чтобы увидеть причину ошибки, нажмите на адрес страницы в колонке 20 самых нагружающих страниц.

  Пример анализа

Список адресов и статистики выполнения для страницы /catalog/index.php:

Нажмите на рисунок, чтобы увеличить

Обратите внимание – на странице /catalog/index.php размещён комплексный компонент Каталог с включенным ЧПУ, поэтому реальные URL для этой страницы – разные. Приведенная таблица отсортирована по уменьшению времени выполнения страницы, и хорошо видно, что если в первый раз страница открывалась 1,5 секунды, то в последующие разы с постоянным уменьшением времени. При этом сработало кэширование компонентов, и, как следствие - уменьшение времени на выполнение SQL-запросов.

Проверим, какие компоненты выполняются на этой странице. Для этого нажмите на число в колонке Компоненты нужной страницы. Список компонентов и их характеристики для хита 14 по адресу /catalog/t-shirts/t-shirt-men-s-fire/.

[dw]Вы увидите[/dw][di][/di] список компонентов, подключаемых на странице, число SQL-запросов из них и тип кэширования. В этом списке ищутся те некэшированное компоненты, о которых сообщал монитор производительности.

Аналогичным образом просматривается список SQL-запросов на этой странице (для данного хита). Для определения, какой из компонентов не кэшируется вернитесь на страницу Монитор производительности: хиты и нажмите на ссылку >> перед адресом страницы, откроется сводная статистика по странице. Здесь вы увидите, на каком именно этапе построения страницы сайта [dw]затрачивается максимальное время[/dw][di][/di].

Если на Панели управления нажата кнопка Отладка (Отладка > Суммарная статистика), то в этом окне будет отображён и [dw]список компонентов страницы[/dw][di][/di]. Любой из компонентов можно настроить, выбрав его из этого списка. Как правило, компоненты расположены в том же порядке, что и на странице диагностики.

Примечание: Подробнее про работу с монитором производительности в публичной части сайта смотрите в уроке Публичная часть модуля.



Вкладка Масштабируемость

Получаем количественные данные

В модуле [ds]Монитор производительности[/ds][di]Монитор производительности показывает скорость работы сайта на хостинге, выявляет узкие места (скрипты на сайте, которые потребляют наибольшее число системных ресурсов) и основные ошибки настройки сервера.

Подробнее ...[/di] доступен встроенный инструмент тестирования нагрузки многопоточных и [ds]веб-кластерных[/ds][di] Модуль Веб-кластер — это комбинация технологических решений, которые позволяют распределить один сайт на несколько серверов, решая тем самым несколько задач:
1) обеспечение высокой доступности сайта;
2) его масштабирование в условиях возрастающей нагрузки;
3) балансирование нагрузки, трафика, данных между несколькими серверами.

Подробнее...[/di] систем (Настройки > Производительность > Панель производительности, вкладка Масштабируемость).

Монитор производительности

Для проведения теста настройте форму. Поясним некоторые поля.

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

    Также на тестируемом сайте необходимо на время проведения теста отключить опцию блокировки пользователя при большом количестве соединений ([dw]Блокировать?[/dw][di][/di]) в настройках модуля Веб-аналитика, вкладка Настройки, секция Ограничение активности.

  • Страница (оставьте пустым для системного теста). В поле указывается адрес страницы, к которой будут происходить обращения во время теста, например, к индексной странице. При пустом поле обращение будет происходить к [dw]системной странице[/dw][di]/bitrix/admin/perfmon_panel.php?test=Y&show_page_exec_time=Y&show_sql_stat=N[/di];
  • Максимальная продолжительность теста (минут). Задаётся время в течение которого продолжается тест по достижению числа соединений, указанных в поле Конечное количество одновременных соединений, причем в каждом последующем шаге теста количество одновременных соединений будет одно и то же.

Нажмите Начать тестирование, и в реальном времени будут строиться: таблица с результатами, графики генерации Страниц в секунду и Время генерации/получения страницы.

Таблица Результаты

Помимо колонок теста и Соединений, пояснения к которым не требуются, в таблице также присутствуют следующие колонки:

  • Хитов - общее количество [dw]хитов[/dw][di]Хит – это запрос к веб-серверу для получения файла. Подробнее...[/di] произведенных за тест;
  • Ошибок - в данном случае под ошибками понимается ответ сервера, отличающийся от 200 ОК;
  • Страниц в секунду - количество страниц отданных тестируемым сервером за секунду;
  • Время генерации страницы - время генерации страницы на тестируемом сервере;
  • Время получения страницы - время получения страницы от тестируемого сервера.

График Страниц в секунду

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

В тесте с одинаковом количеством соединений график не должен иметь провалов.


График Время генерации/получения страницы

С увеличением количества одновременных соединений время отдачи страниц клиентам будет также увеличиваться (синий график), а время генерации не должно меняться в широких пределах (красный график).


Документация по теме:


Пример нахождения мелких ошибок в производительности

  Мелкие ошибки
  в производительности сайта

Перед сдачей проекта протестируйте сайт и найдите ошибки в верстке, неправильно настроенного кэширования и другие мелкие недочеты. Для этого скачайте два-три раза все страницы на жесткий диск. Для этой цели хорошо подходит бесплатная программа wget, работающая под управлением Linux/Unix систем и встроенная в виртуальную машину VMBitrix.

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

Для тестирования включите режим тестирования производительности, затем перейдите в виртуальную машину и выполните такие команды:

cd /tmp
mkdir test1
cd test1
rm -rf localhost
wget -m http://localhost
rm -rf localhost
wget -m http://localhost
rm -rf localhost
wget -m http://localhost

Для повтора теста повторите 2 последние команды. Если тестирование затянулось, прервать его можно, нажав CTRL+C.

Внимание! При большом числе обращений с одного адреса проактивная защита не позволит выполнить тестирование. Отключите контроль активности на странице Проактивный фильтр (Настройки > Проактивная защита > Проактивный фильтр).

  Низкая скорость работы сайта
  и низкая оценка производительности

В первую очередь необходимо проверить наличие [ds]акселератора php[/ds][di]Наличие акселератора php просто жизненно необходимо, даже без дополнительных настроек страницы открываются в три раза быстрее, во столько же раз снижается нагрузка на процессор.

Подробнее ...[/di]. Это специальный модуль, который выполняет прекомпиляцию php скриптов, что позволяет уменьшить время работы скриптов в среднем в три раза.

Затем проверить, не включено ли расширение [ds]open_basedir[/ds][di]На shared хостинге сложно отделить клиентов друг от друга. Самый простой вариант: включить open_basedir, тогда на все операции с файлами происходит дополнительная проверка пути.

Подробнее ...[/di].

  Медленное открытие
  страниц

Наиболее просты в определении и легки для детектирования две проблемы:

  • все или значительная часть страниц сайта открывается не очень быстро;
  • некоторые разделы сайта почти не открываются или открываются очень медленно.

Причины могут быть разные, но, пожалуй, одни из самых частых:

Для первой проблемы. В коде страниц сайта имеются битые ссылки, которые переадресуются на индексную или на 404 страницу. Такие несуществующие адреса легко отлавливаются после получасового теста Монитора производительности.

Для второй проблемы: после сбоя некоторые таблицы базы данных оказались повреждены. В результате нагрузка на MySQL возросла в сотни раз. 5-ти минутный тест Монитора производительности показал, что причина – в нескольких поврежденных таблицах в разделе Каталог.


Конфигурирование веб-систем для оптимальной работы

Типовые настройки серверного программного обеспечения рассчитаны на минимальное оборудование и статические HTML-приложения. Внесение некоторых конфигурационных изменений в серверное ПО позволяет в несколько раз увеличить производительность системы в целом, сократить время генерации страниц, увеличить устойчивость системы к пиковым нагрузкам.

В этой главе приведены рекомендации по настройке серверного ПО, которые выполняются сотрудниками компании «Битрикс» при конфигурировании проектов с посещаемостью более 3-10 тысяч уникальных пользователей в день, либо при недостаточности системных ресурсов для обработки меньшей нагрузки.

Все рекомендации относятся в основном к UNIX-системам или Windows-системам, использующим веб-сервер Apache.

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

Внимание! Все рекомендации подразумевают, что выполнены все обязательные требования и, по возможности, рекомендуемые установки на странице Проверка сайта (Инструменты > Проверка сайта) в Административном разделе продукта.

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

Особенности веб-приложений

Веб-приложения отличаются от программ, работающих под управлением операционной системы, например, Windows.

Основное отличие – в задачах. Windows-приложение ожидает действий пользователя и работает постоянно, пока оно запущено. В случае веб-приложения посетитель сайта видит уже результат выполнения программы, которая, к этому времени, уже завершила свою работу и освободила ресурсы сервера для обслуживания других посетителей. При открытии другой (или этой же) страницы выполняется новый экземпляр программы, который, после выдачи данных пользователю, также завершается.

Таким образом, в операционной системе вам принадлежат все ресурсы компьютера, и почти неограниченное время, а в Веб вам принадлежит лишь совсем чуть-чуть памяти (обычно 32-256 мб) и немного времени (обычно не более 30-90 секунд). Кроме того, спецификой любого более-менее посещаемого проекта является необходимость обслуживать различное число посетителей в разное время суток, и простым увеличением ресурсов сервера добиться необходимого качества очень сложно.

В связи с этим конфигурирование веб-систем для работы с проектами на платформе Bitrix Framework имеет свои особенности.

PHP-приложения

Раньше HTML-проекты представляли собой обычный статический документ, который содержал специальные теги разметки. С точки зрения администратора веб-сайта, данные документы считываются веб-сервером и передаются по TCP/IP протоколу. Не выполняется никаких дополнительных приложений, не потребляется дополнительная память, не используется база данных. Это очень просто и удобно, но этого уже недостаточно для современных проектов.

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

Программный продукт "1C-Битрикс: Управление сайтом" разработан на языке программирования PHP. На данный момент поддерживается PHP версии 8.0.0 и выше.

PHP: (англ. PHP: Hypertext Preprocessor — «PHP: препроцессор гипертекста») — скриптовый язык программирования общего назначения с открытым исходным кодом, применяемый для разработки веб-приложений. В настоящее время поддерживается подавляющим большинством хостинг-провайдеров и является одним из лидеров среди языков программирования, применяющихся для создания динамических веб-сайтов.

Обратите внимание на отличие PHP от скриптов, написанных на других языках, например, на Perl или C: вместо того, чтобы создавать программу, которая занимается формированием HTML-кода и содержит бесчисленное множество предназначенных для этого команд, создается HTML-код с несколькими внедренными командами PHP. Код PHP отделяется специальными начальным и конечным тегами, которые позволяют процессору PHP определять начало и конец участка HTML-кода, содержащего PHP-скрипт.

Значительным отличием PHP от какого-либо кода, выполняющегося на стороне клиента, например, JavaScript, является то, что PHP-скрипты выполняются на сервере. Если бы у вас на сервере был размещен PHP-скрипт, клиент получил бы только результат выполнения скрипта, причем он не смог бы выяснить, какой именно код выполняется. Вы даже можете сконфигурировать свой сервер таким образом, чтобы HTML-файлы обрабатывались процессором PHP, так что клиенты даже не смогут узнать, получают ли они обычный HTML-файл или результат выполнения скрипта.

С точки зрения администратора, принципиально важен тот факт, что PHP является интерпретируемым языком и PHP-скрипт исполняется только на сервере. Интерпретируемый язык - это значит, что сколько бы раз вы не запрашивали страницу на языке программирования PHP, она будет каждый раз обрабатываться на сервере специальным интерпретатором PHP, будет проверяться синтаксис языка, правильность конструкций и вызовы функций, и только после этого, код PHP будет исполняться.

Таким образом, в отличие от обычных HTML-страниц, сайты на PHP потребляют больше оперативной памяти на один процесс веб-сервера. Веб-сервер может приступить к передаче страницы клиенту в большинстве случаев только после того, как страница готова и PHP выполнил свои инструкции. Это приводит к некоторому замедлению по сравнению с HTML-страницами в выдаче содержимого клиенту.

Внимание! Задача администратора сервера – настроить программное обеспечение для минимизации нагрузки на сервер, организации стабильной работы сервера и ускорения работы сайтов.

Базы данных

Дополнительным фактором, влияющим на производительность системы, является правильное использование баз данных. Все современные проекты для отображения динамической информации (новостей, каталога товаров и др.) используют СУБД (системы управления базами данных), а СУБД, в свою очередь, требует правильной настройки своих параметров.

Соединение с базой данных

База данных представляет собой независимое клиент-серверное приложение, которое запускается и работает в операционной системе. Внешние приложения соединяются с базой данных через TCP/IP или внутренние потоки, направляют SQL-запросы и получают в ответ от базы данных необходимые данные.

Возможно два типа соединения с базой данных для веб-приложения:

  • обычное соединение;
  • постоянное соединение (Persistent).

Обычное соединение устанавливается каждый раз во время выполнения страницы при первом обращении к базе данных. Установленное соединение освобождается (в большинстве случаев и закрывается) после завершения страницы.

Постоянное соединение (функции PHP обычно называются *_pconnect) устанавливается один раз при первом обращении к базе данных и при повторных обращениях, даже из других страниц, используются уже открытые соединения к базе данных.

Учитывая, что открытие соединения к базе данных - процесс относительно дорогой по ресурсам и времени (происходит установление TCP/IP соединения, выделяются буферы памяти, проводится проверка и авторизация, настраиваются перекодировщики и выполняется целый ряд других функций), использование постоянных соединений является предпочтительным, если это не приводит к превышению числа одновременных соединений с базой данных. Целесообразность применения постоянных соединений прямо пропорциональна частоте обращений к базе данных, то есть посещаемости сайта.

Например, если на сайте за 15 минут в среднем бывает по 100 посетителей, применение define("DBPersistent", true); целесообразно, если по 5, то, конечно же, нет.

Примечание: Устанавливая соединение с базой данных, при указании параметру server значения localhost или localhost:port, PHP в большинстве своем будет пытаться соединиться с локальным сокетом без использования TCP/IP. Если вы все же хотите использовать TCP/IP, используйте адрес 127.0.0.1 вместо localhost.

Соединение без использования TCP/IP дает наивысшие результаты по производительности, особенно при передаче больших объемов информации из базы данных. Но если база данных расположена на другой машине и избежать соединения по TCP/IP не удается, использование постоянного соединения становится еще более выгодным.

В большинстве случаев база данных работает на той же машине, что и PHP-приложение и веб-сервер. Но вполне возможна ситуация, когда база данных установлена на соседней машине или даже у другого провайдера. "1С-Битрикс: Управление сайтом" устанавливает соединение с сервером базы данных через стандартные библиотеки, которые идут в поставке языка программирования PHP.

В "1С-Битрикс: Управление сайтом" с версии 20.900.0 тип соединения с базой данных устанавливается в файле [dw]/bitrix/.settings.php[/dw][di]В файле: /bitrix/php_interface/dbconn.php до этой же версии[/di] в ядре D7.

Пример содержимого файла:

'connections' => array (
        'value' => array (
            'default' => array (
                'className' => '\\Bitrix\\Main\\DB\\MysqlConnection',
                'host' => 'localhost:31006',
                'database' => 'admin_bus',
                'login' => 'admin_bus',
                'password' => 'admin_bus',
                'options' => 2,
                'handlersocket' => array (
                    'read' => 'handlersocket',
                ),
            ),

Используйте константу DBPersistent, чтобы установить тип соединения с базой данных.

Для отключения постоянного соединения используйте:
define("DBPersistent", false);

Использование постоянных соединений может потребовать некоторой настройки Apache и MySQL. Убедитесь, что вы не превысите максимальное число дозволенных соединений. Читайте дополнительную информацию в документации PHP относительно используемой вами базы данных.

Работа с базами данных в Bitrix Framework

Какие проекты можно назвать большими?

Комплексное сочетание целого ряда факторов может привести к тому, что проект получает название «большой» и требует определенного конфигурирования и отношения:

  • большая посещаемость проекта в среднесуточном выражении;
  • высокие пиковые нагрузки;
  • невозможность кэшировать страницы в силу сложной бизнес-логики;
  • большие интерактивные проекты: форумы, блоги, журналы;
  • индивидуальные страницы для отдельных пользователей;
  • большие объемы данных;
  • недостаточность аппаратных ресурсов по отношению к предыдущим факторам.

Примечание: даже если у вас сравнительно небольшой проект, лучше настроить веб-сервер правильно, чтобы в случае неожиданного роста посещаемости, например, при рекламной кампании, сайт стабильно работал.

Почему умирают сайты?

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

  Как работает веб-сервер

Рассмотрим типичную схему работы веб-сервера:

При запросе страницы сайта происходит обращение к веб-серверу, который запускает интерпретатор PHP для выполнения скрипта. Далее программа выполняется, взаимодействует с СУБД и отдает результат выполнения клиенту. Кроме того, веб-сервер отдает клиенту сопутствующие файлы – картинки, документы, css файлы и другую статическую информацию.

В современных сайтах при открытии каждой страницы клиенту отдается несколько десятков файлов – от действительно результата выполнения PHP программы до статических картинок.

Важно отметить, что для отдачи каждого файла используется, как правило, отдельный процесс Apache, который занимает память веб-сервера. В 2012 году средний размер процесса Apache в памяти – от 64 до 500 мб, и очень легко занять всю оперативную память процессами веб-сервера.

  Узкие места

Выделим несколько узких мест в приведенной схеме:

  1. Передача данных клиенту. Решение проблем медленных каналов
  2. Производительность PHP. Уменьшение времени выполнения скрипта.
  3. Обмен с базой данных.
  4. Настройка СУБД на максимальную производительность
  5. Отдача статики. Решение проблемы медленных каналов.

Передача данных клиенту

Работа веб-сервера Apache организована таким образом, что процесс веб-сервера занимает память системы, пока полностью не завершит отдачу файла. Таким образом, в случае если у клиента медленный канал связи, то даже при быстром выполнении PHP скрипта сервер будет не справляться даже с маленькой нагрузкой.

Дополнительно, при отдаче статических файлов с помощью Apache ценная память веб-сервера используется расточительно – под выдачу статики, для обработки которой не требуется выполнять программы на PHP.

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

Очень часто администраторы не отдают себе отчет в том, насколько данный фактор влияет на стабильность системы и эффективное использование оперативной памяти.

Давайте сделаем простой расчет. Рассмотрим две системы: А и Б.

В системе А время генерации страниц составит 0.1 секунды, а время передачи страницы клиенту в среднем будет составлять всего 5 секунд (в реальной жизни среднее значение окажется еще больше). В системе Б мы будем считать время генерации страниц равным 0.1, а время передачи страницы пользователю равным нулю. Предположим, что на каждый сайт поступает по 100 запросов в секунду.

Система А

Обработка 100 запросов в секунду потребует одновременной работы 500 самостоятельных процессов веб-сервера. "Почему?" - спросите вы. А как же иначе, если даже обработав запрос за 0.1 с., наши процессы, получается, еще не способны обрабатывать другие запросы, а будут висеть в памяти и просто дожидаться, пока пользователи в течение 5 секунд будут получать страницу. На четвертой секунде веб-сервер получит еще 100 запросов и должен будет запустить еще 100 процессов. Соответственно, на пятой секунде в памяти должно находиться 500 процессов и только с этого момента процессы первой секунды начнут высвобождаться и обрабатывать новые запросы.

Таким образом, система А для нормальной работы будет запускать порядка 500 процессов, что потребует от нас в лучшем случае 32 Гб оперативной памяти. Обратите внимание, что даже если бы время генерации страниц было равно 0.001 секунды, это бы не увеличило производительность системы, так как процессы ожидают передачи данных пользователям на медленных каналах, а не времени генерации страниц. Т.е. производительность системы А никак не связана с производительностью PHP и продукта.

Система Б

За первую секунду на сервер поступит 100 запросов. Для обработки 100 запросов нам потребуется всего 10 процессов. Один процесс обрабатывает один запрос за 0.1 секунды. Как мы договорились для системы Б, время передачи страницы пользователю будет равно нулю. Т.е. за 1 секунду, один процесс веб-сервера способен обработать 10 запросов пользователей! К завершению первой секунды, все запросы будут обработаны всего 10 процессами и ко второй секунде все эти процессы будут свободны и готовы обрабатывать следующие запросы. Так же случится и на третьей секунде, и через час.

Таким образом, система Б для нормальной работы будет запускать всего 10 процессов, что потребует от нас порядка 640М оперативной памяти. И очень важно отметить, что уменьшение времени генерации страниц до 0.01 секунды позволит реально увеличить производительность системы в 10 раз, и нам будет достаточно уже только 1 процесса для обработки всех 100 запросов в секунду. Производительность системы Б зависит только от производительности PHP и продукта и не зависит от медленных каналов.

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

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

Производительность PHP, базы данных и статика

Рассмотрим остальные "узкие места".

Производительность PHP. Уменьшение времени выполнения скрипта.

До 60% рабочего времени веб-сервера тратят на повторную компиляцию PHP-кода перед исполнением. Ключевой способ снизить нагрузку на процессор – использовать прекомпиляторы PHP-кода, которые снижают нагрузку на систему за счет перевода PHP из интерпретируемого в частично компилируемый язык.

Обмен с базой данных

Если ваш проект работает на выделенном сервере, вы можете настроить взаимодействие с СУБД для уменьшения затрат времени на установку соединений. Для этого используется постоянные соединения с базой данных, что позволяет уменьшить общее время выполнения скрипта.

Настройка СУБД на максимальную производительность

Установки по умолчанию для большинства СУБД рассчитаны на некие средние величины. Для повышения производительности необходимо оптимизировать эти настройки.

Отдача статики. Решение проблемы медленных каналов.

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

Причины "умирания" сайтов

Таким образом, при больших нагрузках проект может прекратить нормальное функционирование по следующим причинам:

  • Нехватка оперативной памяти для нормальной одновременной работы процессов веб-сервера и базы данных. В большинстве систем на каждый запрос к сайту открывается отдельный процесс веб-сервера. Обычный размер процесса Apache с подключенным PHP-модулем и работающим приложением может составить порядка 64-500 мегабайт. В результате пиковых нагрузок происходит одновременный запуск очень большого числа процессов (иногда больше нескольких сотен процессов). И как следствие, начинается свопирование процессов, а это неизбежно сказывается на производительности базы данных, и производительность всей системы в целом резко снижается.

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

  • Недостаточная производительность базы данных при одновременных конкурентных запросах, невозможность полностью использовать ресурсы сервера. Данная ситуация очень часто возникает при работе с MySQL. Надо отметить, что обычно MySQL использует формат таблиц MyISAM. Это очень простой и эффективный вариант работы, но, к сожалению, при большом числе одновременных запросов такая база данных становится критически узким местом в производительности системы в целом. Во время вставки данных, обновления и некоторых других запросах, происходит эксклюзивное блокирование таблиц и, как следствие, все запросы выполняются только последовательно, а не одновременно. В результате, при росте нагрузки, время генерации страниц возрастает необоснованно резко и в итоге становится неприемлемо большим. Менее всего подвержены подобным проблемам проекты, использующие MySQL с форматом таблиц InnoDB.

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

Двухуровневая конфигурация веб-сервера Front-End и Back-End

Наилучшим способом для устранения перечисленных проблем является создание двухуровневой системы Front-End + Back-End для обработки запросов.

Front-End – публичная часть проекта, обеспечивающая прием запросов от пользователей, трансляцию запросов к Back-End и выдачу непосредственного содержимого пользователю.

Back-End – исполнительная часть системы, которая обеспечивает выполнение PHP-скриптов, формирование контентных страниц и работу бизнес-логики приложений.

Рассмотрим пример конфигурации более детально. После применения оптимизации у нас должна получиться система примерно следующего вида:


Front-end

  Что использовать?

Начнем с построения Front-end системы и определения целей и задач, которые будет решать данная часть двухуровневой архитектуры.

В качестве Front-End сервера можно использовать NGINX, SQUID, OOPS или любой аналогичный продукт.

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

SQUID и OOPS - это классические прокси-сервера, которые выполняют проксирование запросов и чаще всего кэшируют статические запросы, сохраняя в кеше или у себя на диске копии статических запрашиваемых объектов в течение определенного интервала времени.

Наилучшие практические результаты получены при использовании NGINX. Но использование кэширующих прокси-серверов также возможно с получением отличных результатов.

Двухуровневая архитектура выставляет перед пользователем Front-end легкий веб или прокси-сервер, который принимает все запросы от пользователей, исполняет все запросы, которые возможно обработать самостоятельно без обращения к Back-End. Если используется NGINX или аналогичный продукт, все статические объекты напрямую считываются с диска и передаются клиенту. Если используется кэширующий прокси-сервер, статические объекты, графические файлы и таблицы стилей запрашиваются с Back-end только при первом обращении к ним. После этого файлы хранятся в кэш Front-end в соответствии с политикой кэширования и отдаются пользователям без обращения к Back-end.

  Цели и задачи

Основные цели, которых мы добиваемся созданием первого Front-end уровня:

  • минимизация числа запросов, поступающих к Back-end веб-серверу. Надо добиться ситуации, когда Front-end будет обращаться к Back-end процессам только для получения содержимого PHP-страницы. Все запросы к статическим объектам должны обрабатываться легкими процессами Front-end самостоятельно или при использовании кэширующего прокси-сервера на всех запросах, кроме первого.

    Совет: проверьте лог Back-end веб-сервера, чтобы убедиться, что вы настроили все правильно и действительно исключили лишние запросы. В логе должны быть представлены только страницы PHP, другие запросы не должны проходить к Back-end системе и не будут отражаться в лог файле.

  • минимальное потребление оперативной памяти при обработке статических запросов. Число статических запросов существенно превосходит число запросов к PHP-страницам. Процессы Front-end потребляют в среднем 2-5М оперативной памяти и очень незначительно увеличиваются при обработке статических документов. Это позволяет в разы уменьшить потребление оперативной памяти всей системой в целом.
  • защита системы от фактора медленных каналов. Как для статических запросов, так и для HTML-страниц, полученных от PHP-процессов Back-end веб-сервера, процессы Front-end могут передавать страницу пользователю достаточно долго, потребляя при этом очень мало оперативной памяти. Таким образом, Front-end, транслируя запрос к Back-end, получает ответ, высвобождает процессы Back-end для обработки других запросов, а сам передает страницу пользователю, снимая фактор медленных каналов. Система приближается к идеальной системе Б в примере, приведенном в уроке Передача данных клиенту.

    Внимание! Убедитесь, что буферы Front-end достаточны, чтобы без ожидания на передаче принять от Back-end всю страницу. То есть фактически буфер в идеале должен быть равен размеру самой большой страницы у вас на сайте.

  • механизм защиты Back-end от большого числа запросов за счет ожидания свободных процессов Back-end для продолжения работы. Проверьте и убедитесь, что Front-end будет ожидать 5-10-15 минут, пока не высвободятся процессы Back-end. Наличие такого механизма позволит нам настроить Back-end так, чтобы полностью стабилизировать систему и подготовиться к стрессовым нагрузкам.

Как вы видите, появление Front-end позволяет нам снять целую категорию рисков и подготовить систему к дальнейшей работе

Внимание! Если вы используете кэширующий прокси-сервер в качестве Front-End, обязательно настраивайте время кэширование документов. Графические файлы и таблицы стилей, XML-файлы и другие статические объекты с веб-сервера должны запрашиваются только в соответствии с политикой кэширования. После этого файлы хранятся в прокси-сервере и отдаются пользователям без обращения к Back-End и Apache. Рекомендуется настраивать время кэширования для графических файлов на 3-5 дней. Пример настройки кэширования через файл .htaccess в корне веб-сервера:
ExpiresActive on 
ExpiresByType image/jpeg "access plus 3 day" 
ExpiresByType image/gif "access plus 3 day"

Для работы этого примера необходимо, чтобы веб-сервер позволял переопределение переменных через файл .htaccess и модуль mod_expires был установлен. В некоторых случаях на Front-end политика кеширования настраивается независимо от настроек Back-end.

Таким образом, Front-end будет кешировать все графические изображения. Запросы к контентным страницам не будут кешироваться и будут перенаправляться к Back-end.


Back-end и порядок взаимодействия

  Back-end

Back-end представляет собой обычный веб-сервер Apache, который исполняет PHP-приложения.

Back-end готов исполнять запросы на графические и статические документы, если вы используете кэширующий прокси-сервер для Front-end. Но очень важно, чтобы число запросов к статическим элементам через Back-end было минимальным и 99% запросов приходилось на выполнение именно PHP-страниц. Не забывайте, что использование Back-end для обработки статических запросов обходится очень дорого.

Конфигурируя Back-end, можно добиться значительного выигрыша в производительности и стабилизировать систему по расходу памяти. В большинстве случаев Back-end представляет собой обычный веб-сервер Apache, работающий на нестандартном порту, к примеру, на порту 88 и отвечающий только на запросы с localhost или IP адреса Front-end.

Совет администратору: Лучше использовать несколько внутренних IP адресов типа 127.0.0.2, 127.0.0.3 и т.д. с 80-м портом, иначе возможны нежелательные редиректы на неработающий порт у Front-end.

  Процесс взаимодействия

Рассмотрим процесс взаимодействия Front-End и Back-End при обработке запроса пользователя к обычной странице сайта.

  • Запрос от пользователей принимается Front-end, например, по адресу http://www.1c-bitrix.ru/ на 80 порту. На нашем сайте мы используем NGINX в качестве Front-end.
  • Запрос принимается и транслируется к Back-end (веб-сервер Apache с PHP), который обрабатывает запросы по адресу http://127.0.0.2:80/.
  • Запрос исполняется Back-end веб-сервером, отрабатывает программный продукт на PHP и генерируется HTML-текст страницы для пользователя.
  • Подготовленная HTML-страница от Back-end передается Front-end как ответ на запрос пользователя, соединение между Front-end и Back-end закрывается (желательно не использовать KeepAlive на Back-end), и процесс Back-end высвобождает оперативную память или начинает обработку другого запроса.
  • Front-end передает готовую сформированную страницу посетителю столько времени, сколько требуется пользователю, даже если он работает на медленном канале. Потребление памяти Front-end для передачи страницы пользователю минимально.
  • Получив страницу, браузер посетителя посылает последовательно серию запросов на графические элементы и таблицу стилей. Все запросы принимаются Front-end и обрабатываются без обращений к Back-end, т.е. все статически документы самостоятельно вычитываются с диска без использования медленных и дорогих процессов Back-end.

  Пример уменьшения объема памяти

Пример уменьшения объема занимаемой оперативной памяти и числа процессов при подключении Front-end сервера (без настройки на отдачу статических файлов).

В этом примере был подключен NGINX, который все запросы, в том числе и запросы к статике, передавал back-end (Apache). Никаких дополнительных настроек на Back-end не выполнялось. Время подключения nginx – 12:50.

Используемая веб-сервером память:

Число одновременно выполняемых процессов Apache:

Как показала практика, двухуровневая конфигурация Front-end + Back-end существенно разгружает машину, уменьшает объемы потребляемой памяти, значительно ускоряет время обработки запросов и позволяет больше памяти выделить для работы базы данных. Такая конфигурация также позволяет значительно разгрузить сервер при обработке большого числа статических файлов, например, музыки, дистрибутивов программных продуктов, презентаций и других схожих объектов. Например, простым подключением NGINX удалось снизить нагрузку на веб-сервер в 5 раз.


Стабилизируем Back-end по расходу оперативной памяти

  Стрессовые нагрузки

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

Для стабилизации системы по расходу памяти и минимизации числа запущенных процессов Back-end мы рекомендуем в настройках сервера Apache установить параметр MaxClients в значении от 5 до 50, в зависимости от объема оперативной памяти. Значение этого параметра не должно превышать 80% от объема доступной памяти сервера за вычетом памяти, выделенной под СУБД. Устанавливая MaxClients, вы ограничиваете возможное число одновременно запущенных процессов Back-end. Тем самым, удается поставить жесткий лимит по потреблению памяти и исключить выход машины из строя при стрессовых нагрузках.

Пример поведения сервера при неправильно установленном MaxClients

Зависание сервера при слишком большом значении MaxClients:

На приведенном скриншоте произошло следующее:

Запущена команда top в Linux, показывающая объем занятой и свободной памяти, число выполняющихся процессов и объем памяти, занимаемый ими. В данном примере достаточно посещаемый веб-сайт работал на мощном сервере с двумя 4-х ядерными процессорами и 5 Гб оперативной памяти. Размер swap-файла – 4 Гб.

MaxClients был установлен в 100. Каждый процесс Apache занимал около 250 Мб, что привело к полному исчерпанию и оперативной памяти, и файла подкачки на 40 процессах Apache. В связи с отсутствием доступной памяти процессоры сервера не смогли справиться с нагрузкой и сервер зависал.

Таким образом, число MaxClients необходимо подбирать, исходя из системных ресурсов и нагрузки.

  Методика подбора параметра

Методика подбора может быть следующей. Посчитайте, сколько памяти у вас занимает один Back-end процесс. Например, 50 Мб. Если мы установим MaxClients равным 4, значит максимальное потребление памяти может составить 200 Мб. Для машины с 512 Мб оперативной памяти MaxClients желательно выбрать между 5-10. Для правильной конфигурации Front-end, когда вся статика обрабатывается без участия Back-end, это позволит вполне комфортно обрабатывать порядка 50 тысяч хитов в сутки или примерно 10-20 тысяч уникальных пользователей.

Для крупных проектов с конфигурациями из двух машин или при наличии больших объемов памяти рекомендуется производить выбор значения MaxClients в процессе нагрузочного тестирования.

Важно! Подбирайте MaxClients так, чтобы система при стрессовых нагрузках потребляла не более 90% процессорных ресурсов и никогда не доходила до 100%. Это позволит вам стабилизировать использование процессорных ресурсов и быть уверенным, что не начнется общая регрессия по производительности во время пиковых нагрузок.

Обратите внимание, что очень важно настраивать время ожидания для Front-end таким образом, чтобы при отсутствии свободных процессов в Back-end, Front-end ожидал освобождения ресурсов. Тем самым организуется очередь запросов, и Back-end защищается от перегрузки.

Так же рекомендуется подбирать параметры управления процессами Back-end в соответствии с установленным лимитом MaxClients. Например, если MaxClients = 5, тогда рекомендуется установить:

MinSpareServers 5 
StartServers 5 
MaxClients 5

Т.е. это означает, что при старте сервера сразу будет запущено столько процессов Back-end, сколько максимально возможно соединений. Процессы никогда не будут выгружаться из памяти и будут готовы в любой момент принять и обработать запрос от Front-end. При запуске системы мы с вами сразу увидим объем используемой Back-end оперативной памяти, что позволит остальную память распределить для базы данных.

Совет! Рекомендуется для начала выбирать минимальное значение MaxClients, например, 5. В процессе работы проекта проверять время исполнения страницы. Если на быстром канале наблюдается ситуация, когда время выполнения страницы (параметр ?show_page_exec_time=Y) в пиковые моменты показывает стабильно минимальное значение, а визуально мы наблюдаем существенную задержку перед открытием страницы, то это может свидетельствовать о нехватке процессов Back-end. Иными словами о том, что запросы принимаются Front-end и долго удерживаются в ожидании высвобождения Back-end процессов.

В этом случае можно рекомендовать увеличить MaxClients, но обязательно с учетом общего баланса системы по расходу памяти.

  MaxClients и базы данных

Еще одно преимущество использования MaxClients связано с базами данных.

Наличие лимита позволяет включить постоянное соединение к базе данных (только если у вас свой сервер с 1-2-я проектами) и уменьшить время соединения с базой данных и число работающих процессов базы данных. Если величина параметра MaxClients меньше или равна максимальному числу соединений с базой данных, то это гарантирует, что никогда не будет запущено больше этого числа процессов Back-end. Следовательно к базе данных не будет открыто больше соединений. Фактически, всегда в памяти будут находиться MaxClients загруженных процессов Back-end с открытыми соединениями к базе данных, готовые к обработке запросов.

Внимание! Практика показывает, что администраторы поверхностно относятся к данной рекомендации и не устанавливают лимиты или устанавливают их необоснованно большими. Это приводит к полному дисбалансу двухуровневой системы и потере стабильности при больших нагрузках (см. рисунок выше).

Еще раз подчеркнем, что соблюдение этих рекомендаций позволяет:

  • Стабилизировать конфигурацию по расходу памяти при любых нагрузках;
  • Защитить сервер от процессорных перегрузок и общей регрессии производительности;
  • Безопасно использовать постоянное соединение к базе данных.

Производительность PHP

  PHP прекомпиляторы

Важно! До 60% рабочего времени веб-сервера тратят на повторную компиляцию PHP-кода перед исполнением.

Ключевой способ снизить нагрузку на процессор – использовать прекомпиляторы PHP-кода. В настоящее время поддерживается акселератор OPcache (рекомендуется, доступен сразу «из коробки» в PHP v.5.5+).

Не забывайте выделять достаточный объем оперативной памяти для хранения разделяемого кэша скомпилированных PHP-файлов. Обычно бывает достаточно 32-64 Мб, но для уверенности можно увеличить объем выделяемой памяти до 128 Мб, в расчете на файлы административного раздела. Прекомпиляторы используют разделяемый кэш для хранения скомпилированного PHP кода в оперативной памяти, который доступен всем рабочим процессам веб-сервера, при этом скомпилированный PHP код хранится в кэше в единственном экземпляре (без дублирования).

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

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

Для ускорения работы с PHP-сессиями рекомендуется сохранять файлы сессий в каталоге, который представляет собой виртуальный диск в памяти или использовать установку session.save_handler=mm в php.ini. Если есть возможность, рекомендуется использовать системный RAM диск. При этом необходимо отключать опцию Передавать пароль в зашифрованном виде на закладке Авторизация страницы настроек Главного модуля.

  Панель производительности

Важным инструментом по настройке производительности PHP является модуль Монитор производительности, входящий в комплект всех продуктов "1С-Битрикс". Протестировать настройки системы можно в административной части на странице Панель производительности (Настройки > Производительность > Панель производительности). Неоптимальная конфигурация PHP:

Как правило, выполнение рекомендаций позволяет увеличить производительность системы до достаточных величин. Численное значение параметра Конфигурация показывает основную характеристику сайта – скорость отдачи страниц клиенту. Чем больше число, тем лучше.

  Некоторые типовые ошибки

Ошибка Segmentation fault может произойти:

  • В результате "падения" РНР при использовании отложенной загрузки классов;
  • При использовании Zend server могут "упасть" скрипты в cron или консоли.

В первом случае необходимо определить в dbconn.php:

define("NO_BITRIX_AUTOLOAD",true)

Во втором случае надо:

  • либо использовать другую версию PHP без подключения Zend optimizer+ ;
  • либо скопировать хостерский php.ini куда-то выше document root, удалить подключение Zend extension manager или zend optimizer и прописать в кроне опцию -c, которая позволяет указать папку, в которой необходимо искать файл php.ini.
  • либо в "падающем" скрипте определить:
    define('BX_NO_ACCELERATOR_RESET', true)

Сжатие страниц

Компрессия при передаче данных между сервером и клиентом обеспечивает сжатие страниц для ускорения вывода содержания сайта пользователям.

Сжатие в несколько раз уменьшает объем передаваемых HTML-данных между сайтом и браузером клиента, что существенно увеличивает скорость работы как для посетителей, так и для администраторов сайта.

Предпочтительнее сжимать страницы на Front-End. При отсутствии такой возможности можно сжимать данные на Back-End.

Возможные способы:

  • mod_deflate;
  • модуль [dw]Компрессии[/dw][di]Начиная с версии main 20.0.1300 модуль Компрессия удалён из продукта. Рекомендуется настроить сжатие контента в веб-сервере.[/di], входящий в продукты "1С-Битрикс";
  • стандартные модули PHP;
  • стандартные модули Apache.

Для исключения излишнего расходования процессорных ресурсов рекомендуется применять сжатие только на одном уровне. Например, при использовании сжатия Front-end сервером рекомендуется не использовать сжатие на уровне Apache и отключить модуль компрессии "1С-Битрикс: Управление сайтом".

Дополнительные рекомендации для двухуровневой конфигурации

По умолчанию, при работе в двухуровневой конфигурации, в качестве адреса клиента будет указываться адрес, на котором работает NGINX или другой акселератор. Для правильной работы модуля статистики необходимо обеспечить передачу реального IP адреса с Front-end в Back-end.

Например, для NGINX используется следующая технология: сервер NGINX устанавливает специальный заголовок в запросе, а специальный модуль Apache (rpaf или real_ip) учитывает этот заголовок вместо стандартного.

Если же такой модуль не установлен, то вы можете сами изменить адрес клиента. Например, если адрес клиента передается в переменной HTTP_X_FORWARDED_FOR (так делает прокси-сервер SQUID) или HTTP_X_REAL_IP, то для замены переменной в продукте необходимо в файле /bitrix/php_interface/dbconn.php вставить подобный пример кода:

if(isset($_SERVER['HTTP_X_FORWARDED_FOR']) || isset($_SERVER['HTTP_X_REAL_IP'])) {
    foreach(array('HTTP_X_FORWARDED_FOR', 'HTTP_X_REAL_IP') as $key => $value) {
        if(
            isset($_SERVER[$value])
            &&  strlen($_SERVER[$value]) > 0
            &&  strpos($_SERVER[$value], "127.") !== 0
        ) {
            if($p = strrpos($_SERVER[$value], ",")) 
            { 
                $_SERVER["REMOTE_ADDR"] = $REMOTE_ADDR = trim(substr($_SERVER[$value], $p+1)); 
                $_SERVER["HTTP_X_FORWARDED_FOR"] = substr($_SERVER[$value], 0, $p); 
            } 
            else 
                $_SERVER["REMOTE_ADDR"]= $REMOTE_ADDR = $_SERVER[$value]; 
            
            break;
        }
    }
}

Кроме того, в конфигурации Apache на Back-end желательно отключить KeepAlive. Поскольку Front-end находится или на этой машине, или "рядом", более быстрое высвобождение ресурсов предпочтительнее.


Достигнутые результаты

В результате построения двухуровневой архитектуры и выполнения ряда рекомендаций мы должны получить следующие результаты:

  • система стабилизирована по расходу памяти; Front-End и Back-End занимают заранее отведенный объем памяти, который не будет расти даже при увеличении нагрузки;
  • в стрессовой ситуации система будет стабильно и равномерно обрабатывать запросы, Back-end не будет увеличивать число одновременно выполняемых процессов выше установленного лимита MaxClients, Front-end будет принимать все запросы от пользователей и ожидать освобождения процессов Back-end;
  • использование процессорных ресурсов ограничено числом одновременно работающих процессов Back-end в соответствии с MaxClients, не начнется регрессия производительности;
  • возможно безопасное использование постоянного соединения с базой данных без опасения превысить число возможных соединений; в памяти все время находится установленное число Back-end процессов, готовых к обработке запросов и с установленным соединением с базой данных;
  • процессорные ресурсы существенно высвобождены за счет прекомпиляции PHP-кода;
  • пользователи комфортно работают со сжатыми страницами.

Пример настройки двухуровневой архитектуры

В качестве примера рассмотрим конфигурацию виртуальной машины VMBitrix. В состав конфигурации входят:

  • Веб-сервер Apache в качестве Back-end
  • NGINX в качестве Front-end
  • Zend Server CE в качестве настроенного модуля PHP (с прекомпилятором)
  • Дополнительные настройки СУБД MySQL и других параметров сервера.

Для рассмотрения и управления настройками перейдите в консоль виртуальной машины или подключитесь к ней через ssh или sftp.


Настройка веб-сервера Apache

  Конфигурационные файлы

Основным конфигурационным файлом веб-сервера является /etc/apache2/apache2.conf (в других системах файл может называться /etc/httpd/httpd.conf). Далее, подключается файл с настройкой портов прослушивания для веб-сервера и другие файлы. Иногда это все размещается в одном файле, иногда (как в виртуальной машине – в разных).

Рассмотрим основные параметры этих файлов.

/etc/apache2/apache2.conf

Timeout 300 #если 300 секунд не происходит никаких операций, завершить процесс
KeepAlive Off #все запросы у нас короткоживущие
User ${APACHE_RUN_USER} #пользователь, под которым работает веб-сервер
Group ${APACHE_RUN_GROUP} #группа, под которой работает веб-сервер

/etc/apache2/ports.conf

Listen *:8888 #веб-сервер работает на порту 8888

/etc/apache2/envvars Осуществляется установка переменных окружения – пользователя и группы.

export APACHE_RUN_USER=bitrix
export APACHE_RUN_GROUP=bitrix

/etc/apache2/conf.d/prefork Осуществляется настройка числа процессов сервера.

 #работает с этим расширением
StartServers 4 #4 одновременных сервера
MinSpareServers 4 
MaxSpareServers 4
MaxClients 4 #4 одновременных клиента
MaxRequestsPerChild 200 #после 200 запросов перезапускать процесс

Таким образом, настройки веб-сервера достаточно простые. Фактически, в стандартной конфигурации достаточно изменить только порт, на котором работает веб-сервер и параметр MaxClients и связанные с ним.

  Некоторые ключевые моменты настройки

Для конфигурации используются нестандартные порты. Например, 192.168.1.1:8888. В этом случае можно обращаться к Apache снаружи мимо фронтенда и проверить его работу. Это достоинство способа. И могут возникнуть лишние редиректы. Это ограничение способа, которое, впрочем, обходится.

Либо использовать внутренние адреса на стандартных портах. Например, 127.0.0.2:80. Нельзя будет обращаться снаружи мимо фронтенда, но зато нет проблем с редиректами.

Ограничение процессов (StartServers) зависит от параметров системы. Разумное число - 20-30 процессов, точнее надо вычислять. Посмотрите сколько памяти у вас может занять один процесс, поделите общее количество памяти на размер одного процесса, это даст примерное число процессов.

По логам проверяйте, что бы вся статика отдавалась Frontend'ом. В логах не должно быть обращений к статическим файлам: gif, jpg, css и подобным.


Пример: число процессов веб-сервера

Как определить максимальное число процессов веб-сервера? Естественно, только опытным путем. При этом начальное значение можно подобрать достаточно просто - нужно посмотреть, сколько занимает процесс apache во время типового обращения к сайту:

  • Зайдите в Linux и запустите команду free. Она покажет вам общий размер оперативной памяти и свободный размер:
    # free
                 total       used       free     shared    buffers     cached
    Mem:        255676     224340      31336          0      33468      67964
    -/+ buffers/cache:     122908     132768
    Swap:       530136      51800     478336
    

    В примере показано, что в системе ~256 Мб памяти, ~500 Мб swap (виртуальная память на диске). Системной памяти занято ~120 мб, вся неиспользуемая память отдана под файловый кэш

  • Наберите команду top
  • Откройте любую страницу сайта, параллельно смотря значение в программе top. Вверху появится процесс с названием apache2:
      PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
    14687 bitrix    20   0  153m  45m  28m R  6.7 18.2   0:05.34 apache2
    

    В этом примере столбец RES как раз и показывает примерное количество памяти, выделяемое на один процесс. Таким образом, для типового сайта на "1С-Битрикс: Управление сайтом" - это около 50 Мб. Соответственно, параметр MaxClients выбран 4 исходя из соображения, что должна остаться память под операционную систему и работу СУБД.

Из этого примера видно, что для достаточно посещаемого сайта (не интернет-магазина) минимальные требования по памяти для веб-сервера (или VPS) – от 512 Мб. Для интернет-магазина с обменом с минимальный объем памяти на сервере или VPS должен быть не менее 1 Гб.


Настройка Front-end NGINX

  Конфигурационный файл

Каталог с конфигурацией NGINX - /etc/nginx. Рассмотрим его конфигурационный файл /etc/nginx/nginx.conf:

        user    bitrix;  #пользователь, под которым работает nginx. Желательно совпадение с пользователем apache
        worker_processes  8; #8 одновременных процессов
        error_log  /var/log/nginx/error.log warn;
        pid        /var/run/nginx.pid;
        worker_rlimit_nofile 10240;  #максимальное число открытых файлов

        events {
                use epoll;
                worker_connections  10240; #максимальное число соединений с одним процессом. Система может одновременно работать с max_clients = worker_processes * worker_connections, т.е. с 81920 соединений, в том числе статических файлов
        }

        http {  
                include       /etc/nginx/mime.types;
                default_type  application/octet-stream;
#формат логов
                log_format  main  '$remote_addr - $remote_user [$time_local] $status' 
                                '"$request" $body_bytes_sent "$http_referer" '
                                '"$http_user_agent" "$http_x_forwarded_for"';
                log_format      common  '$remote_addr - - [$time_local] "$request" $status $bytes_sent "$http_referer" "$http_user_agent" $msec';

                access_log  /var/log/nginx/access.log  common;
                sendfile        on;
                tcp_nopush     on;
                tcp_nodelay    on;
                client_max_body_size       10m; # максимально допустимый размер тела запроса клиента, указываемый в строке "Content-Length" в заголовке запроса 
                client_body_buffer_size    128k;
                proxy_connect_timeout      300; #время на ожидание соединения
                proxy_send_timeout         300;
                proxy_read_timeout         300;
                proxy_buffer_size          64k;
                proxy_buffers              8 64k;
                proxy_busy_buffers_size    64k;
                proxy_temp_file_write_size 10m;
                gzip on; #сжимать передаваемые данные
                gzip_proxied any;
                gzip_types application/x-javascript text/css;

        server { #виртуальный хост
                listen 80; #порт 80
                server_name bitrix; #адрес узла. Если узел всего один – можно написать любой
                server_name_in_redirect off; #лучше поставить в ON – передавать запрошенное имя сайту
                access_log /var/log/nginx/access.log common;
                index index.php;
                error_page 500 502 503 504 /500.html;
                error_page 404 = /404.php;
#установить дополнительные заголовки для определения адреса клиента в статистике сайта
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header Host $host:80;
                client_max_body_size 1024M; #максимальный размер передаваемого файла
                client_body_buffer_size 4M;
                root /var/www; #корневая папка сайта

#включить https режим при нахождении в корне сайта файла .htsecure
                if (-f /home/bitrix/www/.htsecure) {
                        rewrite ^(.*)$ https://$host$1 permanent;
                }

#выбрать, какие данные пересылать backend серверу, а какие – показывать напрямую
#в данной конфигурации все пересылается backend серверу
#обилие вариантов потребовалось компании Битрикс для того, чтобы при добавлении в конфигурацию отдачу статических файлов напрямую через NGINX динамические запросы на псевдостатические файлы все-таки перенаправлялись на backend
                location / { expires 3d;
                                if ($request_method = OPTIONS ) {
                                        proxy_pass http://127.0.0.1:8888;
                                        }
                                if ($request_method = PROPFIND ) {
                                        proxy_pass http://127.0.0.1:8888;
                                        }
                                if ($request_method = PROPPATCH ) {
                                        proxy_pass http://127.0.0.1:8888;
                                        }
                                if ($request_method = MKCOL ) {
                                        proxy_pass http://127.0.0.1:8888;
                                        }
                                if ($request_method = COPY ) {
                                        proxy_pass http://127.0.0.1:8888;
                                        }
                                if ($request_method = MOVE ) {
                                        proxy_pass http://127.0.0.1:8888;
                                        }
                                if ($request_method = LOCK ) {
                                        proxy_pass http://127.0.0.1:8888;
                                        }
                                if ($request_method = UNLOCK ) {
                                        proxy_pass http://127.0.0.1:8888;
                                        }
                        }

                location ~ ^(/extranet/docs|/docs|/workgroups|/company/profile|/bitrix/tools|/company/personal/user).*/$ {
                        proxy_pass         http://127.0.0.1:8888;
                        }

                location ~ ^(/extranet/docs|/docs|/workgroups|/company/profile|/bitrix/tools|/company/personal/user) {
                        if (-d $request_filename) {
                            rewrite  ^(.*)(/*)$  $1/  last;
                        }
                        proxy_pass         http://127.0.0.1:8888;
                        }

                location ~ ^(/bitrix/html_pages)
                        {
                        root /var/www;
                        index index@.html;
                        if (!-f $request_filename)
                                {
                                rewrite ^/bitrix/html_pages(.*)@(.*)\.html$ $1.php?$2 break;
                                rewrite ^/bitrix/html_pages(.*)\.html$ $1\.php break;
                                proxy_pass http://127.0.0.1:8888;
                                }
                        }

                location ~ \.php$ {
                                root        /var/www;
                                if ($request_method = POST ) {
                                        break;
                                        proxy_pass http://127.0.0.1:8888;
                                        }
                                if ($http_cookie !~ "PHPSESSID=" ) {
                                        rewrite ^(.*)\.php$ /bitrix/html_pages$1@$args.html? last;
                                        }
                                proxy_pass http://127.0.0.1:8888;
                                }

                location ~ /$ {
                                root        /var/www;
                                if ($request_method = POST ) {
                                        break;
                                        proxy_pass http://127.0.0.1:8888;
                                        }
                                if ($http_cookie !~ "PHPSESSID=" ) {
                                        rewrite ^(.*)/$ /bitrix/html_pages$1/index@$args.html? last;
                                        }
                                proxy_pass http://127.0.0.1:8888;
                                }

                location ~ (/|\.php|\.asmx|/rest.*)$ {
                        proxy_pass         http://127.0.0.1:8888;
                        }
                location ~ /\.ht {
                        deny  all;
                        }
                location ~ /favicon.ico {
                        proxy_pass         http://127.0.0.1:8888;
                        }

                location ~ ^(/bitrixsetup\.php)$ {
                    proxy_pass         http://127.0.0.1:8888;
                    proxy_buffering off;
                }

        }
#аналогичная конфигурация для https (удалена)
}

В данной конфигурации настройка NGINX проведена так, что все обращения к серверу будут перенаправляться на Back-end сервер. Однако, можно избранные файлы отдавать через NGINX. В этом случае будет достигнуто дополнительное увеличение производительности.

  Некоторые нюансы настройки

# cat /proc/cpuinfo | grep "processor" | wc -l
worker_processes 8;

Регулируем размер очереди, который мы можем обрабатывать worker_processes. Сами разработчики NGINX рекомендуют выбирать число в соответствии с числом процессоров в системе.

# max_clients = worker_processes * worker_connections
events {
        use epoll;
        worker_connections  10240;
}

worker_connections - сколько запросов одновременно может обрабатывать один процесс. NGINX легкий и надёжный. Он способен выдержать такое число. В результате общее число коннектов, которые будут обрабатываться - это значение worker_processes умноженное на значение worker_connections.

# больше - больше памяти, меньше - чаще пишем на диск
client_body_buffer_size 4m;

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

# максимально быстро получаем ответ от бэкенда
proxy_buffering on;

Включение proxy_buffering позволяет облегчить работу с клиентами с медленными каналами. Такие клиенты будут медленно соединяться с NGINX, медленно от него получать данные. Но сам frontend данные с backend'а получает быстро и не загружает веб-сервер.

gzip            on;
gzip_proxied    any;
gzip_static     on;
gzip_types      application/x-javascript text/css;
gzip_min_length 1100;

Обязательно включайте сжатие статики, что также ускорит отдачу данных.

Дополнительную информацию по настройке NGINX вы можете получить на сайте www.nginx.ru и wiki.nginx.org.



Отдача графики напрямую NGINX

Для того, чтобы графические файлы отдавались напрямую NGINX, вам необходимо добавить в конфигурацию сервера строки, подобные этим:

location ~* \.(jpg|jpeg|gif)$ {
            root         /var/www;
            access_log   off;
            expires      3d;
        }

В приведенном примере все файлы с расширением jpg, jpeg или gif будут считываться напрямую NGINX, причем корневой папкой для хранения файлов будет /var/www.

Оптимизация базы данных

Оптимизация работы с базой данных MySQL является одной из важнейших стратегий в оптимизации системы в целом.

У каждого производителя базы данных есть целый раздел в документации, который посвящен вопросам производительности и оптимизации её работы.

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

Основные принципы

Если кратко попробовать сформулировать стратегию оптимизации, то прозвучит это примерно так:

  • как можно меньше дисковых операций чтения данных; старайтесь увеличивать размер буфера кэширования, чтобы база данных как можно меньше читала данные с диска;
  • как можно меньше сортировок данных на диске; старайтесь увеличить буфер сортировки таким образом, чтобы избежать двойных сортировок и сортировок на диске.
  • увеличивайте параллельность исполнения запросов за счет запуска большого числа процессов базы данных, выбора форматов хранения данных, обеспечивающих параллельность работы;
  • отложенная фиксация транзакций на диске; очень желательно настроить базу данных так, чтобы при изменении данных или их вставке не производилась немедленная запись на диск, а изменения собирались и фиксировались с некоторым интервалом; это позволяет значительно быстрее возвращать управление продукту после выполнения SQL запросов.

    Примечание: Надо отметить, что при этом несколько снижается надежность. В случае сбоя системы те данные, которые еще не "сброшены" на диск, будут потеряны.

Давать конкретные рекомендации по настройке базы данных достаточно сложно, так как сервер базы данных - это сложное приложение и вам обязательно нужно проконсультироваться с документацией поставщика по вопросам настройки.

Но стоит отметить особое преимущество, которое мы получили в результате создания двухуровневой конфигурации. Созданная нами система сбалансирована по расходу оперативной памяти, и мы точно знаем свободный объем памяти и можем безопасно для системы использовать эту память для конфигурирования базы данных. В большинстве систем порядка 60-80% оперативной памяти удается выделить для базы данных и это позволяет значительно ускорить работу всей системы в целом.

Постоянное соединение с базой данных

Важным параметром, влияющим на потребление памяти базой данных MySQL, является максимальное число одновременных соединений, определяемое параметром max_connections (для старых установок с БД Oracle – это параметр processes).

При использовании двухуровневой архитектуры Front-end/Back-end можно в несколько раз уменьшить число одновременных соединений и высвободить больше памяти для сортировки данных в памяти и буферизации.

Если установлено число MaxClients в настройках веб-сервера Back-end, можно считать, что максимальное число соединений к базе данных будет соответствовать максимальному числу одновременных соединений.

Рекомендуется подбирать параметр max_connections таким образом, чтобы иметь резерв в 10-20% свободных соединений от максимального значения.

Настройка базы данных MySQL

  InnoDB или MyISAM?

Оптимизация работы с базой данных для MySQL-версии продукта является одной из важнейших стратегий в оптимизации системы в целом, так как продукт активно работает с базой данных.

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

Основным недостатком MyISAM с точки зрения производительности является блокировка на уровне таблицы при выполнении тех или иных операций. В результате, при большой нагрузке MySQL именно MyISAM таблицы становятся основным узким местом в системе, мешая увеличивать утилизацию машины и число обрабатываемых запросов. Это также приводит к увеличению времени работы страницы за счет ожидания используемых таблиц на уровне MySQL.

Рекомендуется переводить все таблицы проекта в формат данных InnoDB. Формат InnoDB, начиная с версии MySQL 4.0, входит в стандартную поставку продукта и обеспечивает надежное хранение данных, транзакционность и блокирование данных на уровне строки.

Два важных момента, которые дают основание предпочесть таблицы InnoDB перед MyISAM:

  1. Надежность. В MyISAM высока вероятность сбоя таблиц, особенно больших, особенно при высокой посещаемости, особенно часто изменяемых. Есть риск потерять несколько (десятков, сотен) записей и целостность данных. В InnoDB чинить отдельные таблицы не придется. Если упадет, так все сразу. Но на практике это - исключительное явление, практически не встречаемое. Благодаря транзакционности, риск нарушения целостности минимальный.

    Недостатки InnoDB: нужно внимательно следить за свободным местом на диске; накапливающаяся фрагментация данных (лечится периодическим переводом таблиц из InnoDB в MyISAM и обратно).

  2. Скорость. На невысокой посещаемости MyISAM ведет себя быстрее, как на модификацию, так и на чтение. Однако, при росте посещаемости достаточно быстро сказывается отсутствие транзакций и блокировка на уровне таблиц. При некоторой величине посещаемости проект просто реально умирает. В InnoDB запись будет медленнее (транзакции же), зато при высокой посещаемости блокировки наступят намного, намного позже, чем для MyISAM.

  Как поменять тип таблиц на InnoDB

Поменять тип таблиц на InnoDB можно следующим образом:

  1. В административном меню Настройки системы > Инструменты > SQL запрос выполнить команду:
     SHOW TABLES 
  2. В результате вы получите список всех текущих таблиц продукта. Для каждой таблицы необходимо выполнить команду:
     ALTER TABLE <ИМЯ ТАБЛИЦЫ>, type=InnoDB 

    В FAQ приведен пример для создания скрипта для перевода таблиц в InnoDB.

  3. После перевода таблиц вашей базы в InnoDB надо добавить в файл /bitrix/php_interface/dbconn.php нижеследующий код:
     define("MYSQL_TABLE_TYPE", "InnoDB"); 

Переход на тип таблиц InnoDB позволяет избежать возникновения узкого участка в производительности при работе с базой данных и в полном объеме использовать системные ресурсы.

Внимание! Обязательно конфигурируйте InnoDB. Для лучшей производительности базы данных при работе с InnoDB рекомендуется настроить my.cnf для MySQL в разделе параметров для InnoDB innodb_*.

Наибольшее внимание следует обратить на следующие параметры и примеры:

 set-variable = innodb_buffer_pool_size=250M 
 set-variable = innodb_additional_mem_pool_size=50M 
 set-variable = innodb_file_io_threads=8 
 set-variable = innodb_lock_wait_timeout=50 
 set-variable = innodb_log_buffer_size=8M 
 set-variable = innodb_flush_log_at_trx_commit=0 
Рекомендуется: Для сокращения времени ответа сервера можно использовать отложенные транзакции и, в частности, устанавливать переменную set-variable = innodb_flush_log_at_trx_commit=0.

Если MyISAM уже не используется активно, можно высвободить память в пользу InnoDB параметров.

Желательно, чтобы кэш данных вмещал в себя основной объем данных, используемых продуктом в работе. Обычно для работы базы данных выделяется порядка 60-80% свободной памяти в системе.

Рекомендуется: Производить многопотоковую (multithreading) сборку MySQL для улучшения производительности системы и возможностей по параллельной обработке запросов.

  Пример настроек

Пример рекомендуемых настроек для сервера с 2 Гб оперативной памяти, работающего с операционной системой FreeBSD/Linux:

 set-variable = table_open_cache=4096

В составе продукта около 250 таблиц, поэтому рекомендуется увеличивать кэш для заголовков таблиц.

 set-variable = key_buffer_size=16M 
 set-variable = sort_buffer_size=8M 
 set-variable = read_buffer_size=16M 

Эти параметры используются только для MyISAM. Если в базе нет таблиц MyISAM, то лучше установить минимальные значения.

set-variable = query_cache_size=64M 
 set-variable = query_cache_type=1

Кэширование результатов запросов. Обычно бывает достаточно 32 Мб (смотреть на статус Qcache_lowmem_prunes). Максимальный размер результата по умолчанию - 1 Мб, его можно регулировать.

 set-variable = innodb_buffer_pool_size=780M 

Основной буфер - чем больше, тем лучше.

set-variable = innodb_additional_mem_pool_size=20M

Вспомогательный буфер на внутренние структуры, большой делать не имеет смысла.

 set-variable = innodb_log_file_size=100M 
 set-variable = innodb_log_buffer_size=16M

Чем больше размер лог-файла, тем реже надо будет записывать в основной файл данных. Суммарный размер лог-файла может быть сопоставим с величиной innodb_buffer_pool_size (по умолчанию ведется два лога).

 set-variable = innodb_flush_log_at_trx_commit=0 

Отложенная фиксация транзакций, раз в секунду

 set-variable = tmp_table_size=32m

Размер временных таблиц рекомендуется увеличивать до 32 Мб.

Рекомендуется так же увеличивать join_buffer_size до 2 Мб, это существенно влияет на скорость выполнения ряда запросов.

set-variable = join_buffer_size = 2M

Совет администратору Переход на InnoDB может привести к значительному замедлению некоторых масштабных операций записи и обновления данных. Это связано с тем, что все операции по изменению данных начинают выполняться с использованием транзакций. Кроме того, в отличие от MyISAM для кэширования таблиц InnoDB не используется кэш операционной системы, а все кэшированные данные хранятся в кэше БД, определяемом параметром innodb_buffer_pool_size. Вы должны сами определить оптимальность перехода вашего проекта на формат данных InnoDB.

Внимание! Если по каким-то причинам вы решили продолжить работу с типом данных MyISAM, обязательно проведите конфигурирование MySQL для увеличения объемов кэшируемой информации, областей сортировки и минимизации числа дисковых операций. Использование для базы данных 60-80% оперативной памяти может ускорить работу стандартного проекта в несколько раз.

  Временная папка

При наличии достаточного количества ОЗУ рекомендуется выносить временную папку MySQL на ramdisk в памяти.

Для этого:

  • Убедитесь, что в ядре реализована поддержка tmpfs.
  • Создайте новую точку монтирования и дайте все права на использование:
        # mkdir /mnt/tmpfs/
        # chmod 777 /mnt/tmpfs/
  • Дайте команду (от рута или через sudo):
        # mount -t tmpfs -o size=1024M tmpfs /mnt/tmpfs/
        или
        $ sudo mount -t tmpfs -o size=1024M tmpfs /mnt/tmpfs/
    где 1024M есть размер RAMdisk в Мегабайтах.

    Внимание! К размеру папки нужно подходить осторожно: если вы попросите создать ramdisk больше, чем имеете оперативной памяти, система начнёт сгружать всё в swap-файл и реальный результат подключения временной папки может быть отрицательным.

  Ссылки по теме



Настройка базы данных Oracle

Внимание! С 1 января 2017 года прекращена поддержка продуктов «1С-Битрикс» на базах данных Oracle Database и MS SQL Server. Для установок, использующих эти БД, недоступны обновления и возможности новых релизов.

Урок в курсе оставлен для тех, кто использует установку с Oracle. Он не обязателен к изучению и его можно пропустить.

Общие рекомендации по настройке Oracle совпадают с рекомендациями Oracle по конфигурированию системы для уменьшения дисковых операций чтений, сортировки и перестроения.

Стоит обратить внимание на системные переменные управления памятью. Рекомендуется использовать до 60-80% оперативной памяти для кеширования данных за счет управления переменными:

db_cache_size 
shared_pool_size 
pga_aggregate_target
 

Начиная с версии Oracle 10, рекомендуется использовать Automatic Shared Memory Management:

  • при установке БД, выбрать % ОЗУ, которая будет доступна БД в пределах 60-80% от ОЗУ сервера с помощью параметра SGA_MAX_SIZE
  • во время эксплуатации БД количество памяти, доступное Oracle можно откорректировать (в большую или меньшую стороны) с помощью параметра SGA_TARGET без перезапуска БД. Индикатором правильности установки параметров управления памятью будет отсутствие дисковых операций swap, также имеет смысл контролировать общесистемный размер используемого swap пространства – не более 100 MB.

Для экономии места SGA (shared_pool) и уменьшения расходов процессорных ресурсов на разбор SQL-запросов, отличающихся только значениями констант, рекомендуется установить параметр

cursor_sharing = FORCE
либо
cursor_sharing = SIMILAR
отключив расчёт гистограмм для столбцов таблиц в параметрах сбора статистики:
begin dbms_stats.set_param( 'METHOD_OPT', 'FOR ALL COLUMNS SIZE 1'  ); end;

Если Oracle установлен на той же машине, что и веб-сервер, рекомендуется использовать протокол IPC (PROTOCOL = IPC) и (KEY = EXTPROC) для соединения с базой для исключения работы через IP-стек.

Если реализована двухуровневая схема обработки запросов с Front-end и Back-end и установлен параметр MaxClients, то можно без опасений использовать постоянные соединения между PHP и Oracle (Persistent connection), выполнив следующую установку в файле /bitrix/php_interface/dbconn.php:

 define("DBPersistent",true); 
Примечание: Начиная с релиза Oracle 10g R2, возможно использование отложенных транзакций (Enhanced COMMIT) в случаях если бизнес-требования к проекту допускают возможную потерю данных нескольких последних транзакций. Использование отложенных транзакций существенно ускоряет проект, позволяет снять прямую зависимость от производительности дисковой подсистемы и существенно уменьшить время генерации страниц. Для использования этого механизма, необходимо установить параметр: COMMIT_WRITE='BATCH,NOWAIT'.

Пример-упражнение

Пример-упражнение. Настройки MySQL для виртуальной машины

В качестве примера рассмотрим как настроена база данных MySQL в виртуальной машине VMBitrix.

Перейдите в папку /etc/mysql и посмотрите настройки MySQL для виртуальной машины. Выключите виртуальную машину и установите ей большее значение ОЗУ (например, 512 мб). Посмотрите, как изменились настройки в файле /etc/mysql/conf.d/bvat.cnf:

Для 256 мб:
[mysqld]
query_cache_size=32M
innodb_buffer_pool_size=32M
для 512 мб:
[mysqld]
query_cache_size=48M
innodb_buffer_pool_size=96M

Кроме того, при 512 мб система чувствует себя гораздо свободнее:

Доступная память при 256 мб:
# free
             total       used       free     shared    buffers     cached
Mem:        255676     224340      31336          0      33468      67964
-/+ buffers/cache:     122908     132768
Swap:       530136      51800     478336
Доступная память при 512 мб:
# free
             total       used       free     shared    buffers     cached
Mem:        515572     299208     216364          0       6944     186336
-/+ buffers/cache:     105928     409644
Swap:       530136          0     530136

Связано это с тем, что виртуальная машина VMBitrix содержит скрипты, активизирующиеся при загрузке и устанавливающие необходимые параметры системы. Ключевым параметром является объем оперативной памяти, установленный в системе.

Примечание: Кастомизацию настроек можно производить без отключения виртуальной машины. Для этого достаточно вносить изменения в файл /etc/mysql/conf.d/z_bx_custom.cnf.

Оптимизация запросов к БД

  Пример оптимизации запроса

Всегда минимизируйте запросы. Например, если в цикле идет запрос к элементу ИБ, то уже необходимо задуматься над минимизацией. Да, это займет больше времени, но вам скажут спасибо клиенты.

Нельзя:

foreach($arResult["ORDERS"] as $key => $val)
{
	foreach($val["BASKET_ITEMS"] as $vvval)
	{
		$rsEls = CIBlockElement::GetByID();
	}
}

Следует:

$arIDs = array();
foreach($arResult["ORDERS"] as $key => $val)
	{
		foreach($val["BASKET_ITEMS"] as $vvval)
		{
			$arIDs[] = $vvval["PRODUCT_ID"];
		}
	}
if(!empty($arIDs))
{
	$rsEls = CIBlockElement::GetList(array(), array("ID" => $arIDs));
	...
}

foreach($arResult["ORDERS"] as $key => $val)
{
	foreach($val["BASKET_ITEMS"] as $vvval)
	{
		//наполняем данные, налаживая соответствие ID-ков
	}
}

Фактически, вы сводите порой десятки, если не сотни, запросов к одному.

  Специальные методы

Если для какого-либо изменения в БД предусмотрен специальный метод, то следует использовать именно его, а не более общий метод изменения БД.

Хороший пример - модуль интернет-магазина и работа с заказом: можно изменить флаг оплаты заказа путем CSaleOrder::Update, а можно путем CSaleOrder::PayOrder. Так вот, следует применять именно PayOrder, потому что в нем произойдет вызов соответствующих обработчиков.

Даже если вам надо изменить множество полей (того же заказа) и флаг оплаты, то произведите изменение через PayOrder, а затем уже апдейт остальных полей.