Описание курса
Обновление Битрикс24 и работа...

Обновление Битрикс24 и работа с пакетами СПО

Урок 6 из 8

25 мин

Предыдущий урок Следующий урок

Общие принципы обновления Битрикс24 в закрытом контуре

Приложение Битрикс24 состоит из нескольких компонентов:

  1. Серверное окружение приложения
  2. Файлы приложения
  3. Серверное окружение СУБД
  4. Пользовательские файлы

Обновления продукта можно разделить на 2 типа:

  1. Обновление приложения затрагивает только работу самого приложения и модель данных.
  2. Обновление приложения требует предварительного обновления серверного окружения и/или окружения СУБД.

Важно помнить!

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

Как понять, какой тип обновления?

Обычно в разделе «Обновления» вендор предупреждает о том, что текущее окружение не соответствует необходимому минимуму, и его нужно обновить (установлена устаревшая версия PHP, СУБД и т. д.).

Если такое предупреждение есть, используется обновление с предварительным обновлением окружения (тип обновления - 2). Если такого предупреждения нет, обновляем только ядро продукта (тип обновления 1).

Обновляйте тестовое окружение

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

1) Обновление приложения затрагивает только работу самого приложения и модель данных

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

  1. Убедитесь, что тестовый стенд не является точной копией продуктива.

    Это важная деталь. Если вы делаете тестовую версию портала путем копирования продуктового сервера, вам необходимо после этого:

    1. Скорректировать домен во всех настройках как сервера, так и приложения. Домен должен быть привязан к вашей лицензии.
    2. Деактивировать коннекторы в облачные хранилища. (В тот момент, когда вы на копии Битрикс24 для тестирования удалите какой-то файл, он будет удален и на боевой версии).
  2. Выполните резервную копию приложения на тестовом сервере. Можно штатными средствами.
  3. Выполните резервную копию БД. Также можно сделать это штатными средствами, но если данных много, мы рекомендуем использовать специализированные средства, например, Percona XtraBackup (данный инструмент позволяет делать копию “на горячую”, не блокируя данные во время создания).
  4. Запустите процедуру обновления.
  5. После того как она будет выполнена:
    1. Проверьте все базовые тест-кейсы. По возможности автоматизируйте проверку через специализированные инструменты.
    2. Проведите нагрузочное тестирование. Если тестовый сервер имеет более слабую конфигурацию, чем боевой, учтите это в нагрузочном.
    3. Обратите внимание на отчеты в вашей APM-системе.
    4. По возможности снимите и посмотрите трейсы через любую систему профилировки.

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

Важно помнить!

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

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

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

Важно помнить!

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

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

2) Обновление требует обновления конфигураций сервера

Важно помнить!

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

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

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

Общий порядок обновления пакетов СПО:

  1. Заблокировать публичную часть портала для пользовательского доступа.
  2. Сохранить резервные копии конфигурационных файлов текущих версий.
  3. Выполнить процедуру резервного копирования файлов ядра портала, дампа БД и пользовательских файлов.
  4. Выполнить процедуру резервного копирования серверов приложений.
  5. Выполнить остановку СПО на серверах приложений.
  6. Выполнить конфигурацию пакетного менеджера для включения или модификации источника репозитория, предназначенного для установки обновленной версии СПО.
  7. Выполнить обновление необходимых пакетов.
  8. Скорректировать настройки СПО по умолчанию из сохраненных настроек предыдущей версии СПО.
  9. Выполнить запуск СПО на серверах приложений.
  10. Выполнить обновление ядра и компонентов портала через административную панель портала.
  11. Проверить через веб-браузер работу компонентов портала.
  12. Открыть публичный доступ для пользователей портала.

Важно помнить!

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

Особенности установки пакетов в закрытом контуре

Подготовка состава пакетов для обновления СПО

Для установки и обновления пакетов в закрытом контуре необходимо заранее уточнить название ОС, её версию ядра и перечень установленных обновляемых пакетов СПО.

Списки репозиториев для открытия внешнего доступа находятся в настройках пакетного менеджера. Например, для BitrixVM используется пакетный менеджер yum с конфигурацией репозиториев по пути /etc/yum.repos.d/. Для других типов ОС пути до конфигурации репозиториев будут различаться.

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

  1. Версии текущих установленных пакетов с зависимостями.
  2. Версии устанавливаемых/обновляемых пакетов с зависимостями.

Работы по обновлению СПО выполняются под учетной записью с правами администратора.

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

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

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

nginx -V

Для версии BitrixVM 7.5.1 вывод будет следующим:

nginx version: nginx/1.20.2
built by gcc 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC)
built with OpenSSL 1.1.1m  14 Dec 2021
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-openssl=/builddir/build/BUILD/bx-nginx-1.20.2/openssl-1.1.1m --with-openssl-opt=enable-tls1_3 --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-http_auth_request_module --with-http_v2_module --with-mail --with-mail_ssl_module --with-file-aio --add-module=/builddir/build/BUILD/bx-nginx-1.20.2/nginx-push-stream-module-0.4.1 --add-module=/builddir/build/BUILD/bx-nginx-1.20.2/mod_zip-1.2.0 --add-module=/builddir/build/BUILD/bx-nginx-1.20.2/headers-more-nginx-module --add-module=/builddir/build/BUILD/bx-nginx-1.20.2/ngx_pagespeed-1.13.35.2 --add-module=/builddir/build/BUILD/bx-nginx-1.20.2/ngx_brotli --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic'

Обновление пакетов СПО для BitrixVM

Пререквизиты

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

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

  • /etc/nginx - директория конфигурационных файлов для Nginx.
  • /etc/httpd - директория конфигурационных файлов для Apache HTTP Server.
  • /etc/php-zts.d/* - директория конфигурационных файлов для PHP (Thread Safe).
  • /php.d/* - общая директория для дополнительных конфигурационных файлов PHP.
  • /etc/php.ini - основной конфигурационный файл PHP.
  • /etc/mysql/conf.d - директория для дополнительных конфигурационных файлов MySQL.
  • /etc/my.conf - основной конфигурационный файл MySQL.

PHP

Обновление PHP для BitrixVM осуществляется через меню виртуальной машины - menu.sh:

  1. В стартовом меню необходимо выбрать раздел «1. Manage servers in the pool».
  2. В меню выбрать «8. Update PHP and MySQL».
  3. В меню для установки на один сервер необходимо ввести hostname одного сервера, для обновления пакетов на всех серверах – all.
  4. Необходимо выбрать тип операции «1. Upgrade PHP» или «2. Downgrade PHP»:
  5. Если выбрано обновление, то необходимо выбрать версию.
  6. После выбора версии необходимо подтвердить обновление.

После подтверждения процедуры обновления будет запущена ansible роль обновления пакетов ОС и пакетов php. Логи выполнения роли будут расположены по пути /opt/webdir/temp/bx_php_upgrade_php80_*.

Настройки, ранее заданные для php, необходимо сверить и скорректировать в обновленных файлах.

После выполнения обновления необходимо продолжить выполнение шагов, описанных в разделе «Общий порядок обновления пакетов СПО серверов приложений».

Nginx

Nginx из состава BitrixVM устанавливается и обновляется из репозитория bitrix.repo.

Процедура обновления nginx:

  1. Остановка nginx: sudo systemctl stop nginx.
  2. Сохранение текущих конфигурационных файлов nginx из папки /etc/nginx.
  3. Обновление через пакетный менеджер yum: sudo yum update bx-nginx.
  4. Приведение в соответствие с ранее сохраненными, обновленных конфигурационных файлов /etc/nginx.
  5. Старт nginx: sudo systemctl start nginx.

Apache

Apache из состава BitrixVM устанавливается и обновляется из репозитория epel CentOs.

Процедура обновления Apache:

  1. Остановка Apache: sudo systemctl stop httpd.
  2. Сохранение текущих конфигурационных файлов Apache из папки /etc/httpd.
  3. Обновление через пакетный менеджер yum: sudo yum update httpd<./li>
  4. Приведение в соответствие с ранее сохраненными, обновленных конфигурационных файлов /etc/httpd.
  5. Старт Apache: sudo systemctl start httpd.

MySql

Обновление MySql в BitrixVM осуществляется через меню виртуальной машины -menu.sh:

  1. В стартовом меню необходимо выбрать раздел «1. Manage servers in the pool».
  2. В меню выбрать «8. Update PHP and MySQL».
  3. В меню для установки на один сервер необходимо ввести hostname одного сервера, для обновления пакетов на всех серверах – all.
  4. Необходимо выбрать тип операции «3. Upgrade MySQL version».
  5. Для обновления необходимо выбрать версию «1. Upgrade MySQL to version 8.0»и подтвердить операцию обновления.

После подтверждения процедуры обновления будет запущена ansible роль обновления пакетов percona. Логи выполнения роли будут расположены по пути /opt/webdir/temp/bx_php_upgrade_mysql80_*

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

После выполнения обновления необходимо продолжить выполнение шагов, описанных в разделе «Общий порядок обновление пакетов СПО серверов приложений».

Обновление пакетов СПО для CentOs/RHEL

Пререквизиты

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

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

  • /etc/nginx
  • /etc/httpd
  • /etc/php-zts.d/*
  • /php.d/*
  • /etc/php.ini
  • /etc/mysql/conf.d
  • /etc/my.conf

PHP

Обновление из репозиториев remi

Для обновления пакетов из репозитория remi необходимо открыть доступ с обновляемых серверов приложений до серверов, перечисленных в конфигурации пакетного менеджера yum. Если репозиторий remi был ранее подключен, то его конфигурации перечислены по пути /etc/yum.repos.d в файлах remi-*.repo .

Для установки репозитория remi необходимо выполнить команду:

yum install http://rpms.remirepo.net/enterprise/remi-release-7.rpm

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

Для обновления пакетов php необходимо выполнить команды:

sudo yum update php*

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

Обновление php из локальных пакетов

Для обновления пакетов php без доступа до внешних репозиториев необходимо предварительно подготовить пакеты с зависимостями.

  1. Получить перечень установленных пакетов php на обновляемых серверах приложений: 
    sudo rpm -qa | grep php
    Пример вывода результата команды:
    картинка
  2. Установить yum-utils: 
    sudo yum install yum-utils
  3. Скачать пакеты с зависимостями с помощью команды: 
    yumdownloader –resolve php-<версия php>*
    Пример команды загрузки списка пакетов для версии php-8.1: 
    yumdownloader --resolve php-8.1*
  4. После скачивания пакетов с зависимостями необходимо сверить список скачанных модулей с ранее установленными из шага 1. В шаг 3 нужно добавить недостающие модули и повторить загрузку модулей.
  5. Для установки пакетов используется команда: 
    sudo yum localinstall *php*.rpm

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

Nginx

По умолчанию используем Пакет bx-nginx из состава BitrixVM

Для обновления nginx с модулями, необходимыми для работы портала необходимо на сервере с доступом в интернет и установленным BitrixVm выполнить установку пакета загрузку пакета:

sudo yum install yum-utils
yumdownloader --resolve bx-nginx

Для установки пакета используется команда:

sudo yum localinstall bx-nginx*.rpm

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

Apache

Обновление из репозиториев epel

Для обновления пакетов Apache из репозитория epel необходимо открыть доступ с обновляемых серверов приложений до серверов, перечисленных в конфигурации пакетного менеджера yum. Если репозиторий epel был ранее подключен, то его конфигурации перечислены по пути /etc/yum.repos.d в файлах epel.repo.

Для установки репозитория epel необходимо выполнить команду:

sudo yum install epel-release

Для обновления пакетов Apache необходимо выполнить команду:

sudo yum update httpd

Обновление Apache из локальных пакетов

Для обновления пакетов Apache без доступа до внешних репозиториев необходимо предварительно подготовить пакеты с зависимостями.

На отдельном сервере с доступом к интернет и с ОС и той же версией ядра, что и обновляемые сервера необходимо:

  1. Установить yum-utils 
    sudo yum install yum-utils
  2. Скачать пакеты с зависимостями с помощью команды 
    yumdownloader –resolve httpd

Для установки пакета используется команда:

sudo yum localinstall httpd*.rpm

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

PerconaDb

Обновление из репозиториев PerconaDB

Для обновления PerconaDB необходимо на сервере с доступом в интернет и установленным BitrixVm выполнить загрузку и установку пакетов.

До процедуры обновления нужно:

  1. Выполнить полное резервное копирование данных БД.
  2. Выполнить резервное копирование конфигурационных файлов БД.

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

  1. Отключить в пакетном менеджере старый репозиторий PerconaDB.
  2. Выполнить удаление устаревших пакетов:
    sudo rpm -qa | grep Percona-Server | xargs rpm -e --nodeps
  3. Подключить в пакетном менеджере необходимый репозиторий PerconaDB.
    sudo percona-release enable ps-80 release
  4. Выполнить установку необходимых пакетов:
    sudo yum install percona-server-server percona-server-client
percona-server-shared percona-server-shared-compat
  5. После установки пакетов необходимо перенести настройки из ранее сохраненных резервных копий.
  6. Восстановить пользователей и базу из резервной копии.
  7. Добавить perconaDB в автозагрузку

Обновление PerconaDB из локальных пакетов

Для обновления пакетов PerconaDB без доступа до внешних репозиториев необходимо предварительно подготовить пакеты с зависимостями.

До процедуры обновления нужно:

  1. Выполнить полное резервное копирование данных БД.
  2. Выполнить резервное копирование конфигурационных файлов БД.

На отдельном сервере с доступом к интернет и с ОС и той же версией ядра, что и обновляемые сервера необходимо:

  1. Установить yum-utils 
    sudo yum install yum-utils
  2. Отключить в пакетном менеджере старый репозиторий PerconaDB.
  3. Подключить в пакетном менеджере необходимый репозиторий PerconaDB. 
    sudo percona-release enable ps-80 release
  4. Скачать пакеты с зависимостями с помощью команды 
    yumdownloader --resolve percona-server-server percona-server-client percona-server-shared percona-server-shared-compat

Для установки пакета используется команда:

sudo yum localinstall percona-server*.rpm

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

Предыдущий урок

Урок 6 из 8

Следующий урок