Перейти к содержанию

Режим технического обслуживания системы

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

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

Эти функции выполняет специальный компонент - web-сервис webbi (доступен для Windows и Linux), входящий в поставку системы и расположенный рядом с основным web-сервисом TESSA (web), находящимся в одноимённой директории.

Webbi работает постоянно, параллельно и не зависимо от web-сервиса TESSA, принимает и обрабатывает все запросы, адресованные web-сервису TESSA, когда он физически недоступен.

Если ранее при недоступности web-сервиса TESSA возвращалась ошибка с крайне общим и неконкретизированным описанием “Сервер не отвечает/недоступен”, то теперь, благодаря работе webbi, будет выведена настроенная дизайнером, брендированная для каждого решения, содержащая фирменный логотип, цвета и корпоративный шаблон html страница с информацией о причинах и продолжительности технического обслуживания. Что существенно повышает удобство использования приложений пользователями, их информированность и, как следствие, позволяет уменьшить количество обращений в службу технической поддержки с вопросами о сбое в работе системы (как это воспринималось ранее). Теперь webbi позволяет оповещать пользователей о проводимых технических работах в штатном режиме.

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

Important

По умолчанию возможность приёма команд из внешнего контура отключена. Включить её и настроить маршрут для приёма команд можно в поле Settings -> Management конфигурационного файла app.json для webbi.

Important

Работа с webbi должна производиться только по протоколу HTTPS, за что должен отвечать соответствующим образом настроенный reverse proxy (IIS или nginx).

Требования

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

Important

Важно помнить, что поддержка режима технического обслуживания возможна только при использовании reverse proxy серверов IIS и nginx.

Настройка сервера

Настройка сервиса webbi

Webbi является http-сервером с возможностью управления переадресацией запросов, поступающих на основной сервер TESSA.

Для корректной работы webbi необходимо задать ряд обязательных данных.

Рассмотрим аргументы командной строки и их назначение.

Аргумент Описание
-c <config> Указывает путь к файлу конфигурации в формате JSON, содержащему настройки webbi (как правило app.json). Рекомендуется указывать данный аргумент, в противном случае webbi не сможет управлять переключением правил переадресации запросов. Если аргумент не задан, должны быть заданы все остальные аргументы
-server <name> Указывает имя сервера TESSA, обслуживание которого осуществляет webbi
-p <port> Указывает порт, который будет использован webbi для работы. По умолчанию используется порт 9000
-r <redisConnectionString> Строка с данными подключения к серверу Redis
-ri <refreshInterval> Указывает интервал обновления данных из Redis в формате <numOfSeconds>s, или <numOfMilliseconds>ms. Допустимо использовать дробные значения. Значение по умолчанию 3 секунды
-unrestricted Допускает обработку запросов от любых адресов, приходящих на прослушиваемый webbi порт. По умолчанию webbi обрабатывает запросы, поступающие только с того компьютера, на котором он запущен.

Использование данного флага может ухудшить безопасность системы. Не рекомендуется его использовать без уверенности в необходимости именно такого режима работы webbi. Флаг допустимо использовать только в изолированных системах, например, внутри docker контейнера
-v Флаг использования многословного режима. В этом режиме на консоль будут выводится подробные диагностические сообщения
-dbg Флаг использования отладочного режима. Рекомендуется использовать только в диагностических целях для проверки работы сервера. В этом режиме будет доступна страница /info с подробной информацией о текущем состоянии webbi
-cid Полный путь к файлу с уникальным идентификатором компонента.
Если файл не указан, то при старте компонента будет создан файл .cid рядом с исполняемым файлом.
Если файл пуст, то в указанный файл будет записан уникальный идентификатор компонента

Tip

Рекомендуется указывать номер порта целым числом больше 10000 не кратным 10, что в большей степени поможет исключить попытку запустить webbi на уже занятом кем-то порту, например, 19857. Как правило, номера портов меньше 8000 (реже 10000) резервируются системными службами и приложениями.

Note

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

Рассмотрим доступную диагностическую информацию, отображаемую на странице /info при запуске webbi в отладочном режиме.

Поле Описание
Program Имя, версия и дата сборки приложения
Component identifier (CID) Уникальный идентификатор компонента
OS Сведения об операционной системе, под управлением которой работает приложение
Host name Имя компьютера, на котором работает приложение
CPUs count Доступное количество ядер
Server Code Код сервера TESSA, поддержку которого осуществляет приложение
Port Номер порта, используемого приложением
Data refresh interval Интервал обновления данных из Redis
Maintenance Сведения о текущем режиме технического обслуживания: on - включен, off - выключен
Redis state Сведения о текущем состоянии доступности Redis для приложения: Healthy - доступен, Unhealthy - недоступен
Redis initialized Сведения о том, что данные системы в Redis полностью инициализированы: Yes - TESSA установила флаг, что все данные записаны в Redis, No - флаг отсутствует или отличается от ожидаемого
Can publish component info Признак достаточности данных в Redis для публикации webbi информации о себе как о компоненте системы
Work mode Сведения о режиме работы приложения: Standalone - независимая работа, Managed by IIS - работа приложения под управлением IIS
Switching mode Установленный режим работы для переключения правил reverse proxy сервера при переводе системы в состояние технического обслуживания:
- none - режим не задан, webbi не будет переводить переключать настройки reverse proxy;
- iis - задан режим работы IIS, webbi будет переключать правила IIS;
- nginx - задан режим работы nginx, webbi будет переключать правила nginx
Switching rules file is known Признак того, что путь к файлу правил для reverse proxy задан в настройках webbi
Can switch Информация о том, возможно ли переключение системы в режим технического обслуживания
Management enabled Информация о том, что приём внешних команд управления компонентами включен
Management endpoint Информация о пути, по которому будет осуществляться приём внешних команд управления компонентами.
В случае, если приём команд включен, в данном блоке будет выведена ссылка, иначе - текст

Important

Используйте отладочный режим только при первичной настройке webbi или при возникновении каких-либо проблем, чтобы не раскрывать чувствительную информацию о системе, делающую её менее безопасной.

Рассмотрим настройки webbi в едином файле конфигурации app.json для web-сервиса TESSA. Вы можете использовать любое подходящее имя файла, главное, чтобы он имел формат JSON и использовал указанную далее структуру данных.

Поле Settings главного объекта файла, JSON объект.

Поле Описание
ServerCode Код (символьное имя) сервера TESSA
Redis Строка подключения к Redis
ResponseHeaders JSON объект с дополнительными заголовками, которые необходимо отправлять при ответе на каждый клиентский запрос. Каждое поле объекта - это имя соответствующего заголовка, а значение - его содержание
Discovery.KeysStrictSecurity Флаг включения строгой политики безопасности работы с ключами для обработки команд доверенного контура
Management JSON объект с настройками маршрута для отправки команд из внешнего контура в доверенный
Webbi JSON объект с основными настройками webbi

Поле Settings -> Management, JSON объект.

Поле Описание
Enable Флаг включения маршрута приёма команд из внешнего контура в доверенный. По умолчанию маршрут выключен
Endpoint Строка с именем маршрута.
Имя должно иметь длину 10 и более символов, должно начинаться с буквы, за которой должны следовать буквы, цифры, или символы _ , -. Допускаются только буквы английского алфавита в верхнем или нижнем регистре.
Рекомендуется использовать в качестве префикса строку management.
По умолчанию используется имя management

Поле Settings -> Webbi, JSON объект.

Поле Описание
Port Указывает порт, который будет использован webbi для работы
RefreshInterval Указывает интервал обновления данных из Redis в формате dd.hh:mm:ss, где dd - дни, hh - часы в 24 часовом формате, mm - минуты, ss - секунды (поддерживаются целые или вещественные числа)
LogsPath Строка с именем директории для хранения файлов журналов событий webbi. По умолчанию используется директория logs в рабочей директории webbi
MaintenanceConfig JSON объект с настройками управления правилами переадресации запросов. Если отсутствует, webbi не должен переключать правила переадресации запросов

Поле Settings -> Webbi -> MaintenanceConfig, JSON объект.

Поле Описание
Mode Режим работы. Доступные варианты: IIS, nginx. Обязательное поле
Path Путь к файлу с правилами переадресации запросов. Если путь не указан, webbi не будет переключать правила переадресации запросов
RulePrefix Префикс правил переадресации запросов для IIS. Если не указан, будут использованы все имеющиеся правила переадресации
SwitchOn Инструкция для включения режима техобслуживания. Только для nginx. Если не задана, то webbi не будет переключать правила переадресации запросов
SwitchOff Инструкция для выключения режима техобслуживания. Только для nginx. Если не задана, то webbi не будет переключать правила переадресации запросов
ReloadCommand Инструкция для перезапуска nginx. Только для nginx. Если не задана, webbi не будет перезапускать nginx

Пример файла конфигурации.

{
    ".if": [
        "linux",
        {
            "Settings": {
                "Webbi": {
                    "MaintenanceConfig" : {
                        "Mode": "nginx",
                        "Path": "/etc/nginx/conf.d/maintenance.switch",
                        "SwitchOn": "set $maintenance on;",
                        "SwitchOff": "set $maintenance off;",
                        "ReloadCommand": "sudo -n nginx -s reload"
                    }
                }
            }
        },
        "windows",
        {
            "Settings": {
                "Webbi": {
                    "MaintenanceConfig" : {
                        "Mode": "iis",
                        // Path to your TESSA web application installation
                        //"Path": "C:/inetpub/wwwroot/platform/web/web.config",
                        "Path": "C:/tessa/web/web.config",
                        "RulePrefix": "Maintenance"
                    }
                }
            }
        }
    ],



    ".include": [
        "app-*.json",
        "../web/app.json",
        "../app.json"
    ],



    "Settings": {
        // Basic options
        "ServerCode": "tessa",
        "Redis": "localhost",
        "ResponseHeaders": {
            "X-Frame-Options": "sameorigin",
            "X-XSS-Protection": "1; mode=block",
            // Extra headers
            "MySuperHeader": "Webbi"
        },
        // Strict keys security
        "Discovery.KeysStrictSecurity": false,
        // Command management endpoint settings
        "Management": {
            "Enable": false,
            "Endpoint": "management"
        },
        // Webbi options
        "Webbi": {
            "Port": 19857,
            "RefreshInterval": "00.00:00:03",
            "LogsPath": "@logs",
            "MaintenanceConfig" : {
                "Mode": null,
                "Path": null,
                "RulePrefix": null,
                "SwitchOn": null,
                "SwitchOff": null,
                "ReloadCommand": null
            }
        }
    }
}

Настройка внешнего вида страниц, отображаемых webbi

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

Important

Все сделанные изменения вступят в силу после перезапуска webbi.

Страницы отображаются при помощи механизма шаблонов html страниц языка Go. Сами шаблоны расположены в директории views основной директории webbi. Рассмотрим их смысл и назначение.

Файл шаблона Описание Используемые сообщения
layout.tmpl Основной шаблон макета страницы. Все остальные страницы наследуют схему его разметки Title
maintenance.tmpl Шаблон страницы технического обслуживания. Содержит информацию о причинах технического обслуживания, сроках его проведения и любые иные дополнительные сведения MaintenanceMessage
normal.tmpl Шаблон страницы нормальной работы системы. Отображается с момента переключения системы в нормальный режим, до полного введения TESSA в работу NormalMessage
about.tmpl Шаблон страницы о текущем состоянии webbi. Отображается, если webbi запущен в отладочном режиме -

Для лучшего понимания устройства страниц и возможностей их переопределения рассмотрим шаблоны layout.tmpl и maintenance.tmpl.

Шаблон layout.tmpl определяет основную структуру html страницы и задаёт две области HeadTemplate и BodyTemplate для вставки содержимого каждой конкретной страницей наследником. При этом все наследники автоматически используют базовую структуру страницы (приведена далее схематично).

<!DOCTYPE html>
<html>
  <head>



    ...



    <link rel="stylesheet" href="{{ .BasePath }}assets/main.css" />



    <!--Here goes additional header content for page-->
    {{template "HeadTemplate" .}}
  </head>
  <body>
    <section id="header">
      <div class="page-header">
        <img src="{{ .BasePath }}assets/images/logo.png" />
        <p>{{ .Localize "Title" }}</p>
      </div>
    </section>
    <!--Here goes main body content for page-->
    {{template "BodyTemplate" .}}
  </body>
</html>

Important

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

Как можно видеть, HeadTemplate позволяет внедрить содержимое в область заголовка страницы, например, детализировать название страницы (тег title) и задать дополнительные таблицы стилей (CSS файлы).

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

Именно два этих шаблона, фактически, места для вставки содержимого и определяются в шаблонах каждой конкретной страницы. Рассмотрим определение страницы maintenance.tmpl.

{{define "HeadTemplate"}}
<title>
  {{ .Get "ServerCode" }}
</title>
{{ end }}



{{define "BodyTemplate"}}
<section id="message">
  <!-- Design for IE 11 (desktop client) -->
  <table>
    <tr>
      <td class="td-icons">
        <svg
          class="mes-img"
          xmlns="http://www.w3.org/2000/svg"
          fill="currentColor"
          viewBox="0 0 16 16">
          ...
        </svg>
      </td>
      <td>
        {{ range .Localize "MaintenanceMessage" | paragrapher }}
        <p>{{ . }}</p>
        {{ end }}
      </td>
    </tr>
  </table>
</section>
{{ end }}

Как можно видеть, всё содержимое страницы сводится к определению двух шаблонов в формате {{define "Имя шаблона"}} Содержимое шаблона {{ end }}. На странице можно отображать как статическую html разметку, так и локализуемые сообщения и строки.

Important

Для вывода локализованных сообщений на странице используется конструкция {{ range .Localize "Название сообщения или строки локализации" | paragrapher }}<p>{{ . }}</p>{{ end }}. Эта конструкция выводит локализованное сообщение или строку локализации с указанным именем, с учётом переноса строк. Можно использовать сокращённую форму {{ .Localize "Название сообщения или строки локализации" }}, если вы уверены, что в локализуемой строке нет переносов строк, поскольку всё содержимое будет выведено в одну строку без учёта форматирования (переносов строк). Таким образом, можно добавлять на страницу любую локализуемую информацию.

Important

Все имена, которые используются в конструкциях вида {{ .Localize "Имя" ... }} должны быть включены либо в список сообщений, либо в список строк локализации, доступных webbi см. Перевод системы в режим технического обслуживания.

Статические ресурсы страниц

Webbi позволяет страницам использовать статические ресурсы, которые располагаются в директории public основной директории webbi. При написании адреса ресурса на странице, public является корневой директорией (/), адреса всех ресурсов должны быть описаны относительно неё без включения имени самой директории public.

Tip

Рекомендуется все используемые ресурсы располагать в директории assets (ресурсы), группируя их по соответствующим поддиректориям.

Important

Все файлы, расположенные в директории public, будут доступны для скачивания. Размещайте файлы в этой директории и её поддиректориях только если вы уверены в необходимости этого.

На данный момент директория public содержит только директорию assets (ресурсы), данные в которой сгруппированы согласно их виду и назначению.

Директория Содержимое
icons Иконки и миниатюры изображений
images Полноразмерные изображения

Непосредственно в самой директории assets расположены каскадные таблицы стилей и файл манифеста web-приложения.

Настройка IIS

Для обеспечения поддержки режима технического обслуживания TESSA под управлением IIS необходимо выполнить следующие шаги:

  • Установить и настроить необходимые модули:
  • Настроить webbi.
  • Настроить web-приложение TESSA (web).

Установка и настройка модулей

Модуль URL Rewrite добавляет поддержку возможности переопределения запросов для сайта и/или приложения, а Application Request Routing добавляет возможность задействовать обратный прокси сервер при выполнении запроса.

Данная функциональность необходима для переадресации запросов с основного сервера TESSA на webbi при переходе в режим технического обслуживания.

Important

Порядок установки модулей крайне важен. Сначала необходимо установить URL Rewrite и лишь затем Application Request Routing, т.к. последний зависит от первого. Установка в другом порядке может привести к неработоспособности связки этих модулей.

Important

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

Вначале необходимо установить URL Rewrite версии 2.1.

Принимаем условия соглашения и устанавливаем модуль.

Ждём завершения установки.

Далее аналогичным образом устанавливаем модуль Application Request Routing версии 3.0. Доступна только английская версия модуля.

Убедимся, что модули установлены и доступны в диспетчере служб IIS.

Теперь необходимо включить модуль Application Request Routing для переадресации запросов. В противном случае переадресация не будет работать. В диспетчере служб IIS откройте настройки модуля Application Request Routing Cache двойным щелчком левой кнопки мыши.

В открывшемся диалоге в разделе действий в подразделе Proxy нажмите на ссылку Server Proxy Settings....

В открывшемся диалоге установите флаг Enable proxy. Остальные настройки можно оставить без изменений.

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

На этом установка и настройка необходимых для IIS модулей завершена.

Настройка webbi

Для удобства управления рекомендуется устанавливать webbi как приложение, работающее под управлением IIS. Именно этот процесс мы и рассмотрим далее.

Important

Приложение webbi должно работать на том же сервере, где работает web-приложение TESSA.

Note

При желании, вы можете установить webbi как службу Windows (подробнее об этом можно прочитать по ссылке, шаг 5). Однако данный вариант установки менее удобен при обслуживании, чем установка webbi как приложения IIS, поэтому здесь он не рассматривается.

Настройка пула приложений

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

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

Important

Для переключения запросов к web-приложению TESSA на webbi необходимо, чтобы у учётной записи, от имени которой работает пул, был доступ на запись к файлу web.config в директории с web-приложением TESSA.

Настроим созданному пулу (webbi) доступ на запись файла web.config приложения TESSA.

Настроим учётную запись, от имени которой работает пул. Рекомендуется использовать ту же учётную запись, которая была задана при установке web-приложения TESSA (как правило tessa). Для этого выделим пул и откроем его Дополнительные параметры.

Установим рекомендуемую учётную запись tessa. Для этого нажмём на кнопку ....

В открывшемся диалоге выберем пункт Особая учетная запись, далее нажав на кнопку Установить... в открывшемся окне, укажем нужную учетную запись (в формате имя домена\имя учетной записи и пароль). В результате требуемая запись будет установлена:

Tip

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

Теперь определим в какой директории расположено web-приложение TESSA. Для этого выберем приложение и в контекстном меню выберем пункт Управление приложением -> Дополнительные параметры.

Запоминаем значение поля Физический путь. В рассматриваемом случае это C:\inetpub\wwwroot\tessa\web.

Перейдём в эту директорию в проводнике (Explorer) и выберем файл web.config. Далее откроем его свойства.

Переходим на вкладку Безопасность и нажимаем кнопку Изменить.

В открывшемся окне нажимаем кнопку Добавить.

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

После проверки имён, имя должно выглядеть как показано на рисунке (имя должно быть подчёркнуто Имя домена или локальной машины\tessa). Далее нажимаем на кнопку OK в диалоге.

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

В первом диалоге видим установленные разрешения. В нём также нажмём кнопку OK и применим изменения.

Теперь у приложения webbi, работающего под управлением соответствующего пула IIS, есть необходимые разрешения, требуемые для переадресации запросов на себя в то время, как основное приложение TESSA переведено в режим технического обслуживания и недоступно для пользователей.

Настройка приложения

Создайте директорию webbi рядом с директорией web (в случае стандартной установки это C:\inetpub\wwwroot\tessa). Скопируйте в неё всё содержимое соответствующей директории webbi из архива установки TESSA (расположена рядом с директорией web).

Tip

Если директория webbi появилась в менеджере IIS, пропустите шаг по добавлению виртуального каталога и переходите к шагу преобразования каталога в приложение.

Добавление виртуального каталога

Если директория webbi не появилась в менеджере IIS, добавим ссылку на неё. Выберем директорию tessa в составе сайта (в нашем случае Default Web Site) и в контекстном меню выберем пункт Добавить виртуальный каталог.

Укажем имя виртуального каталога webbi и путь, соответствующий директории, которую мы создали на предыдущем шаге. Применим настройки, нажав на кнопку OK.

Преобразование каталога в приложение

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

В открывшемся диалоге настроим пул приложений на созданный нами ранее (webbi). Для этого нажмём на кнопку Выбрать.

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

В исходном окне также нажимаем кнопку OK.

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

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

За перевод команды отвечает специальный маршрут switch.

Ограничение осуществляется путём задания списка IP адресов (v4), которым разрешён доступ к команде. По умолчанию, разрешён доступ только с локального компьютера, на котором установлен IIS.

Рассмотрим, как настроить данное правило под ваши нужды.

Выберите приложение webbi и далее в группе IIS выберите модуль Переопределение URL-адресов. Двойным щелчком левой кнопки мыши войдите в настройки правил модуля.

Правило для управления доступом называется disable switch. Двойным кликом откройте это правило.

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

Настроим условие так, чтобы доступ к команде имели все клиенты с адресами в диапазоне 195.167.0.100-195.167.0.255. В качестве условия выступает регулярное выражение со стандартным синтаксисом. Поэтому дополнительное условие будет выглядеть как 195.167.0.1\d+. Для его добавления в список уже существующих условий используется |. Чтобы проверить правильность регулярного выражения можно использовать встроенный инструмент проверки, для этого нужно нажать на кнопку Проверить. Для завершения настройки и применения нового условия нужно нажать OK.

Видим, что наше условие изменено. Применим изменения в правиле, нажав на кнопку Применить.

Эту же настройку можно выполнить прямым редактированием файла web.config для webbi.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
    </handlers>
    <!-- В атрибуте arguments указываются аргументы командной строки. -->
    <aspNetCore processPath=".\webbi.exe" arguments="-c app.json" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" forwardWindowsAuthToken="true" requestTimeout="00:10:00" startupTimeLimit="3600" hostingModel="OutOfProcess">
      <environmentVariables>
        <!-- В атрибуте value можно указать номер порта для управляемого IIS приложения. -->
        <environmentVariable name="ASPNETCORE_PORT" value="19857" />
      </environmentVariables>
    </aspNetCore>
    <rewrite>
      <rules>
        <rule name="disable switch" enabled="true" stopProcessing="true">
          <match url="^switch([/\?].*)?$" />
          <action type="CustomResponse" statusCode="403" statusReason="Forbidden: Access is denied." statusDescription="You do not have permission to view this directory or page using the credentials that you supplied." />
          <conditions>
            <!-- В атрибуте pattern указывается список IP адресов с которых разрешён доступ к маршруту /switch для перевода системы в режим технического обслуживания. Список заполняется в виде регулярного выражения. -->
            <add input="{REMOTE_ADDR}" pattern="(::1|127.0.0.1|195.167.0.1\d+)" negate="true" />
          </conditions>
        </rule>
      </rules>
    </rewrite>
  </system.webServer>
</configuration>

Условие со списком разрешённых адресов находится в узле configuration -> system.webServer -> rewrite -> rules -> rule (name="disable switch") -> conditions -> add, атрибут pattern. Поскольку мы открыли файл после применения правила в графическом пользовательском интерфейсе, то соответствующее значение уже содержится в данных атрибута: (::1|127.0.0.1|195.167.0.1\d+).

Следует также обратить внимание на два других важных момента.

Аргументы запуска webbi настраиваются в узле configuration -> system.webServer -> aspNetCore, атрибут arguments.

Порт для работы webbi под управлением IIS указывается в узле configuration -> system.webServer -> aspNetCore -> environmentVariables -> environmentVariable (name="ASPNETCORE_PORT"), атрибут value.

На этом настройку приложения webbi для IIS можно считать завершённой.

Настройка web-приложения TESSA

Теперь рассмотрим настройку правил переадресации запросов от приложения TESSA web к webbi при переходе системы в режим технического обслуживания. Каждое правило можно задать в диспетчере IIS в настройках модуля URL Rewrite, также как мы настраивали правила для webbi. В этом разделе мы рассмотрим второй вариант настройки правил прямым редактированием файла web.config.

Откройте файл web.config web-сервиса TESSA. Напомним, что часть, относящаяся к настройке правил переадресации запросов, находится в узле configuration -> system.webServer -> rewrite. Перенесите его в свой файл. Он должен выглядеть следующим образом.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <!-- Секция с правилами переадресации запросов. Скопируйте её в свой файл web.config -->
    <rewrite>
      <!-- Правила переадресации -->
      <rules>
        <!-- Переадресация запроса проверки работоспособности. -->
        <rule name="MaintenanceHealthCheckRule" enabled="false" stopProcessing="true">
          <match url="^hcheck$" />
          <action type="Rewrite" url="https://localhost/tessa/webbi/hcheck" />
        </rule>



        <!-- Переадресация запросов на доступ к статическим данным страницы со сведениями о режиме технического обслуживания. -->
        <rule name="MaintenanceAssetsRule" enabled="false" stopProcessing="true">
          <match url="^(.*/)?assets/(.*)" />
          <action type="Rewrite" url="https://localhost/tessa/webbi/assets/{R:2}" />
        </rule>



        <!-- Переадресация всех запросов на страницу со сведениями о режиме технического обслуживания. -->
        <rule name="MaintenanceRule" enabled="false" stopProcessing="true">
          <match url="(.*)" />
          <action type="Rewrite" url="https://localhost/tessa/webbi/" />
        </rule>
      </rules>
    </rewrite>
    <!-- Конец секции с правилами переадресации. -->



    <!-- Эта часть должна быть взята из вашего оригинального файла и не требует изменений. Изменения здесь могут повлечь к утрате работоспособности приложения. -->
    <handlers>
      <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
    </handlers>
    <aspNetCore processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" forwardWindowsAuthToken="true" requestTimeout="00:10:00" startupTimeLimit="3600" hostingModel="InProcess">
      <environmentVariables />
    </aspNetCore>
    <httpProtocol>
      <customHeaders>
        <remove name="X-Powered-By" />
      </customHeaders>
    </httpProtocol>
    <security>
      <requestFiltering allowDoubleEscaping="true">
        <requestLimits maxAllowedContentLength="4294967295" maxUrl="10999" maxQueryString="2097151" />
      </requestFiltering>
    </security>
  </system.webServer>
</configuration>

Important

Порядок следования правил в узле rewrite важен! Изменение порядка приведёт к некорректной работе переадресации.

В данном случае у нас задано три правила переадресации.

Правило Описание
MaintenanceHealthCheckRule Переадресация запроса проверки работоспособности. Данное правило является обязательным и не должно меняться. Позволяет определить доступность и нормальное функционирование webbi
MaintenanceAssetsRule Переадресация запросов на доступ к статическим данным страницы со сведениями о режиме технического обслуживания. Как правило, страница с описанием времени осуществления технического обслуживания содержит различные иконки, изображения и CSS стили. Это правило требуется для их корректной загрузки. В противном случае пользователю будет отображён только HTML текст без надлежащего форматирования и других статических ресурсов
MaintenanceRule Переадресация всех запросов на страницу со сведениями о режиме технического обслуживания. Обязательное правило. Должно быть последним в списке правил, т.к. перехватывает все запросы и прекращает дальнейшую обработку правил переадресации

Important

Обратите внимание, что имена всех правил доступа начинаются с префикса Maintenance, именно он указывается в app.json webbi: Settings -> Webbi -> MaintenanceConfig -> RulePrefix. Если вы выберете иную схему именования, не забудьте поменять указанную настройку в файле app.json webbi, иначе webbi не сможет переключить правила переадресации запросов.

Important

Обратите внимание, что во всех правилах переадресации использован базовый адрес https://localhost/. Здесь должно быть указано имя вашего сайта (домена). Например, адрес правила MaintenanceRule https://localhost/tessa/webbi/ для домена tessa.ru должен выглядеть https://tessa.ru/tessa/webbi/. Не забудьте настроить корректные адреса для всех правил.

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

Описанные выше правила переадресации выделены рамкой.

На этом настройка поддержки режима техобслуживания для IIS завершена.

Настройка nginx

Для обеспечения поддержки работы TESSA в режиме технического обслуживания под управлением nginx необходимо выполнить следующие шаги:

  • Настроить конфигурационные файлы nginx.
  • Настроить работу webbi в качестве сервиса (службы, демона) операционной системы.
  • Настроить доступ к файлу maintenance.switch в директории nginx/conf.d.
  • Настроить доступ к выполнению определённых команд (опционально при выполнении следующего пункта, иначе обязательно).
  • Опционально настроить сервис webbi-reloader, автоматизирующий перезапуск nginx при изменении файла с флагом режима технического обслуживания.

Здесь предполагается, что TESSA и nginx уже установлены и настроены в вашей операционной системе.

Настройка конфигурационных файлов nginx

Настройка конфигурационных файлов nginx необходима, чтобы запросы к web-сервису TESSA перенаправлялись сервису webbi, когда система переведена в режим технического обслуживания. Откройте файл конфигурации nginx, который при стандартной установке расположен по пути /etc/nginx/conf.d/default. Внесите в него правки, чтобы он выглядел примерно следующим образом.

Important

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

Tip

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

# для протокола https
server {
    # maintenance mode switch flag
    include conf.d/maintenance.switch;



    # здесь всё, что было раньше, до блока "location /"
    ...



    location / {
        # Важно, чтобы эта часть была первой, до существующего содержимого!
        # maintenance mode switch
        if ($maintenance = on) {
          rewrite ^(.*)$ / break;
          #send all to webbi
          proxy_pass https://localhost:1020;
          break;
        }



        # здесь всё, что было раньше внутри блока "location /"
        ...



    }



    # новое содержимое
    # route for static resources
    location ~* (.*/assets)/(.+) {
        # maintenance mode switch
        if ($maintenance = on) {
            rewrite /assets/(.+)$ /assets/$1 break;
            proxy_pass https://localhost:1020;
            break;
        }
    }
}



# новое содержимое
# maintenance mode: proxy for webbi
server {
    # если порт уже занят, нужно указать другой
    listen 1020 ssl;
    listen [::]:1020 ssl;



    # ВАЖНО! Используйте те же настройки SSL, что и для базового сервиса
    # Начало блока настроек SSL
    ssl_certificate /etc/pki/tls/certs/localhost.crt;
    ssl_certificate_key /etc/pki/tls/private/localhost.key;



    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers HIGH:!aNULL:!MD5;
    # Конец блока настроек SSL



    location / {
        proxy_pass http://localhost:19857;
    }



    location ~* /assets/(.+) {
        proxy_pass http://localhost:19857;
        break;
    }



    location ~* /switch {
        limit_except POST {
            deny all;
        }
        # here you configure allowed IP addresses.
        allow 127.0.0.1;
        deny all;
        proxy_pass http://localhost:19857;
    }
}

Important

Если у вас используются другие настройки для базового сервиса TESSA, не забудьте применить их. Если при настройке webbi вы решили использовать другой порт, не забудьте внести изменения в настройке прокси сервера для webbi (maintenance mode: proxy for webbi).

Important

webbi должен иметь доступ к файловой системе с настройками для nginx.

Tip

Части, относящиеся к режиму технического обслуживания, помечены в файле комментариями # maintenance.

Tip

Подробнее про создание сертификата и ключа для SSL описано в инструкции по установке TESSA на Linux.

Обратите внимание на настройки доступа к маршруту /switch. Не забудьте настроить список IP адресов, которым разрешён доступ к этой команде.

Создайте в директории /etc/nginx/conf.d/ файл maintenance.switch со следующим содержимым:

set $maintenance off;

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

Important

Не забудьте изменить настройки доступа к файлу maintenance.switch. Для этого выполните команду sudo chmod 644 maintenance.switch.

Important

Не забудьте изменить владельца файла maintenance.switch, если webbi и/или webbi-reloader работают от имени другого пользователя. Например, для смены владельца на учётную запись tessa выполните команду sudo chown tessa maintenance.switch.

Настройка работы webbi в качестве сервиса операционной системы

Скопируйте каталог webbi из директории linux, расположенной в директории основного дистрибутива, в директорию, в которой у вас расположен web-сервис TESSA. Если вы следовали стандартной инструкции, то базовый путь /home/tessa/tessa/.

Перейдите в директорию webbi в директории назначения и выполните команду:

sudo chmod 755 webbi

Данная команда устанавливает флаг “Исполняемый” для файла webbi.

Important

Если TESSA расположена на одной физической машине, а nginx на другой, то webbi необходимо скопировать на ту машину, на которой установлен nginx. Также в этом случае необходимо скопировать файл app.json из директории web в директорию webbi. Без этого система не будет работать в нужном режиме.

Important

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

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

sudo stat /sbin/init

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

Настройка службы webbi для systemv

Рассмотрим, как настроить службу webbi для системы управления службами systemv.

Перейдите в директорию /etc/init.d/ и создайте в ней файл webbi следующего содержимого:

#!/bin/sh
### BEGIN INIT INFO
# Provides:          webbi - platform paired web server for maintenance mode
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Stop/start webbi
### END INIT INFO



PATH=/sbin:/usr/sbin:/bin:/usr/bin



if [ -L $0 ]; then
    SCRIPTNAME=`/bin/readlink -f $0`
else
    SCRIPTNAME=$0
fi



NAME="webbi"
DAEMONUSER="tessa"
DAEMONDIR="/home/$DAEMONUSER/tessa/webbi"
DAEMON="$DAEMONDIR/webbi"
DAEMON_ARGS="-c app.json"
LOGDIR="/home/$DAEMONUSER/tessa/logs/"
LOGFILE="$LOGDIR/webbi.log"
PIDFILE="/var/run/webbi.pid"



# Exit if the package is not installed
[ -x "$DAEMON" ] || exit 0



. /lib/init/vars.sh



. /lib/lsb/init-functions



do_start()
{
    log_daemon_msg "Starging system $NAME daemon"
    su - $DAEMONUSER -c "mkdir -p '$LOGDIR'"
    su - $DAEMONUSER -c "rm -f '$LOGFILE'"
    start-stop-daemon --start --name "$NAME" --user $DAEMONUSER \
        --background --make-pidfile --pidfile "$PIDFILE" \
        --stdout "$LOGFILE" --stderr "$LOGFILE" \
        --chdir "$DAEMONDIR" \
        --exec "$DAEMON" -- $DAEMON_ARGS
    RETVAL="$?"
    log_end_msg $?
    return "$RETVAL"
}



do_stop()
{
    # Return
    #   0 if daemon has been stopped
    #   1 if daemon was already stopped
    #   2 if daemon could not be stopped
    #   other if a failure occurred
    log_daemon_msg "Stopping system $NAME daemon"
    start-stop-daemon --stop --quiet --oknodo --retry=5 --pidfile "$PIDFILE"
    RETVAL="$?"
    log_daemon_msg $?
    rm -f $PIDFILE
    return "$RETVAL"
}



case "$1" in
    start)
        [ "$VERBOSE" != no ] && log_daemon_msg "Starting " "$NAME"
        do_start
        case "$?" in
            0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
            2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
        esac
        ;;
    stop)
        [ "$VERBOSE" != no ] && log_daemon_msg "Stopping " "$NAME"
        do_stop
        case "$?" in
            0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
            2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
        esac
        ;;
  restart)
        log_daemon_msg "Restarting $DESC" "$NAME"
        do_stop
        case "$?" in
            0|1)
                do_start
                case "$?" in
                    0) log_end_msg 0 ;;
                    1) log_end_msg 1 ;; # Old process is still running
                    *) log_end_msg 1 ;; # Failed to start
                esac
                ;;
            *)
                # Failed to stop
                log_end_msg 1
                ;;
        esac
        ;;
    status)
        status_of_proc -p "$PIDFILE" "$DAEMON" "$NAME" && exit 0 || exit $?
        ;;
    *)
        echo "Usage: $SCRIPTNAME {start|stop|restart|status}" >&2
        exit 3
        ;;
esac



exit $RETVAL

Tip

Вы можете найти этот файл в архиве в директории init.d.

Tip

Для создания и редактирования файла вы можете использовать команду sudo nano /etc/init.d/webbi, или команду вызова другого текстового редактора от имени пользователя с повышенными привилегиями.

Important

Переменные скрипта DAEMONUSER, DAEMONDIR, LOGDIR зависят от установки webbi. В случае необходимости запуска от другого пользователя укажите его имя в DAEMONUSER. В случае установки webbi в директорию, отличную от /home/$DAEMONUSER/tessa/, измените переменные DAEMONDIR, LOGDIR таким образом, чтобы они соответствовали директории установки webbi.

Important

Ознакомьтесь с документацией start-stop-daemon для вашей операционной системы. В некоторых версиях вместо двух аргументов --stdout и --stderr используется один --output. В этом случае скорректируйте соответствующую часть функции do_start (--stdout "$LOGFILE" --stderr "$LOGFILE" замените на --output "$LOGFILE").

Задайте права на исполнение данного сервиса.

sudo chmod 755 /etc/init.d/webbi

Добавьте сервис в автозапуск.

  • Наиболее надёжный способ:
    sudo ln -s /etc/init.d/webbi /etc/rc0.d/S01webbi
  • Если доступна команда chkconfig:
    sudo chkconfig --add /etc/init.d/webbi
  • Если доступна команда update-rc.d: 
    sudo update-rc.d webbi defaults
  • Если доступна команда rc-update:
    sudo rc-update add webbi default

Управление сервисом.

  • Запуск:
    sudo service webbi start
  • Останов:
    sudo service webbi stop
  • Перезапуск:
    sudo service webbi restart
  • Получение сведений о текущем состоянии:
    sudo service webbi status
Настройка службы webbi для systemd

Рассмотрим, как настроить службу webbi для системы управления службами systemd.

Создайте в директории /etc/systemd/system/ файл webbi.service со следующим содержимым:

[Unit]
Description=Webbi - platform paired web server for maintenance mode



[Service]
WorkingDirectory=/home/tessa/tessa/webbi
ExecStart=/home/tessa/tessa/webbi/webbi -c app.json
Restart=always
RestartSec=10
SyslogIdentifier=webbi
User=tessa



[Install]
WantedBy=multi-user.target

Tip

Вы можете найти этот файл в архиве в директории systemd.

Important

Переменные файла конфигурации User, WorkingDirectory, ExecStart зависят от установки webbi. В случае необходимости запуска от другого пользователя укажите его имя в User. В случае установки webbi в директорию, отличную от /home/$DAEMONUSER/tessa/, измените переменные WorkingDirectory, ExecStart таким образом, чтобы они соответствовали директории установки webbi.

Настройте автозапуск сервиса webbi и запустите его, выполнив команду:

sudo systemctl enable webbi

Tip

Здесь webbi соответствует имени сервиса webbi.service без расширения .service.

Управление сервисом.

  • Запуск:
    sudo systemctl start webbi
  • Останов:
    sudo systemctl stop webbi
  • Перезапуск:
    sudo systemctl restart webbi
  • Получение сведений о текущем состоянии:
    sudo systemctl status webbi

Настроить права доступа к выполнению команд управления nginx

В стандартном режиме работы webbi предполагается, что она сама будет перезапускать nginx командой nginx -s reload после переключения в режим технического обслуживания. В большинстве случаев её выполнение нужно осуществлять от имени пользователя с повышенными правами (команда sudo).

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

sudo visudo

Перейдите в конец файла и добавьте строку следующего вида, где tessa это имя пользователя, от имени которого будет работать webbi (указанное в настройках сервиса).

tessa ALL = (ALL) NOPASSWD: /usr/sbin/nginx

Tip

Если вы запускаете webbi от имени суперпользователя, данных настроек производить не следует. Также отредактируйте строку ReloadCommand в app.json webbi следующим образом: "ReloadCommand": "nginx -s reload".

Note

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

%sudo ALL=(ALL) NOPASSWD: /usr/sbin/nginx
Если данная настройка также не помогла, обратитесь к руководству своей операционной системы по настройке запуска команд от имени суперпользователя без ввода пароля.

Настройка сервиса webbi-reloader, автоматизирующего перезапуск nginx

Рассмотрим как настроить автоматический перезапуск nginx при изменении файла maintenance.switch без участия webbi.

Для автоматического отслеживания изменений в файлах необходимо установить пакет inotify-tools. Выполните это командой:

sudo apt install inotify-tools

Удалите текст команды перезапуска из файла app.json для webbi: "ReloadCommand":"".

"Settings": {
    "Webbi": {
        "MaintenanceConfig": {
            "Mode": "nginx",
            "Path": "/etc/nginx/conf.d/maintenance.switch",
            "SwitchOn": "set $maintenance on;",
            "SwitchOff": "set $maintenance off;",
            // Здесь пустая строка.
            "ReloadCommand": ""
        }
    }
}

Создайте в директории /etc файл nginx-reloader.sh следующего содержания:

#!/bin/bash



watchPath=$1



while true
do
  inotifywait --exclude .swp -e create -e modify -e delete -e move $watchPath
  sudo -n nginx -t
  if [ $? -eq 0 ]
  then
    echo "Detected Nginx config change"
    echo "Executing: nginx -s reload"
    sudo -n nginx -s reload
  fi
done

Tip

Вы можете найти этот файл в архиве.

Important

Если данный файл будет выполняться от имени суперпользователя, необходимо удалить префиксы sudo -n во всех командах вызова nginx.

Выполните следующую команду, чтобы сделать файл исполняемым:

sudo chmod 755 /etc/nginx-reloader.sh

Important

webbi-reloader необходимо настроить для той же системы управления сервисами, для которой настроена TESSA.

Настройка службы webbi-reloader для systemv

Рассмотрим, как настроить службу webbi-reloader для системы управления службами systemv.

Перейдите в директорию /etc/init.d/ и создайте в ней файл webbi-reloader следующего содержимого:

#!/bin/sh
### BEGIN INIT INFO
# Provides:          webbi nginx maintenance switch file watching and nginx reloading
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Stop/start webbi maintenance watchers
### END INIT INFO



PATH=/sbin:/usr/sbin:/bin:/usr/bin



if [ -L $0 ]; then
    SCRIPTNAME=`/bin/readlink -f $0`
else
    SCRIPTNAME=$0
fi



NAME="webbi-reloader"
DAEMONUSER=tessa
DAEMON="/etc/nginx-reloader.sh"
DAEMON_ARGS="/etc/nginx/conf.d/maintenance.switch"
PIDFILE="/var/run/webbi-reloader.pid"



# Exit if the package is not installed
[ -x "$DAEMON" ] || exit 0



. /lib/init/vars.sh



. /lib/lsb/init-functions



do_start()
{
    log_daemon_msg "Starging system $NAME daemon"
    start-stop-daemon --start --name "$NAME" --user $DAEMONUSER --background --make-pidfile --pidfile "$PIDFILE" --exec "$DAEMON" -- $DAEMON_ARGS
    RETVAL="$?"
    log_end_msg $?
    return "$RETVAL"
}



do_stop()
{
    # Return
    #   0 if daemon has been stopped
    #   1 if daemon was already stopped
    #   2 if daemon could not be stopped
    #   other if a failure occurred
    log_daemon_msg "Stopping system $NAME daemon"
    start-stop-daemon --stop --quiet --oknodo --retry=5 --pidfile "$PIDFILE"
    RETVAL="$?"
    log_daemon_msg $?
    rm -f $PIDFILE
    return "$RETVAL"
}



case "$1" in
    start)
        [ "$VERBOSE" != no ] && log_daemon_msg "Starting " "$NAME"
        do_start
        case "$?" in
            0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
            2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
        esac
        ;;
    stop)
        [ "$VERBOSE" != no ] && log_daemon_msg "Stopping " "$NAME"
        do_stop
        case "$?" in
            0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
            2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
        esac
        ;;
  restart)
        log_daemon_msg "Restarting $DESC" "$NAME"
        do_stop
        case "$?" in
            0|1)
                do_start
                case "$?" in
                    0) log_end_msg 0 ;;
                    1) log_end_msg 1 ;; # Old process is still running
                    *) log_end_msg 1 ;; # Failed to start
                esac
                ;;
            *)
                # Failed to stop
                log_end_msg 1
                ;;
        esac
        ;;
    status)
        status_of_proc -p "$PIDFILE" "$DAEMON" "$NAME" && exit 0 || exit $?
        ;;
    *)
        echo "Usage: $SCRIPTNAME {start|stop|restart|status}" >&2
        exit 3
        ;;
esac



exit $RETVAL

Tip

Вы можете найти этот файл в архиве в директории init.d.

Important

В случае необходимости запуска от другого пользователя укажите его имя в DAEMONUSER. Учтите, что этот пользователь должен иметь права на чтение директории /etc/nginx/conf.d/ и на перезапуск nginx.

Задайте права на исполнение данного сервиса.

sudo chmod 755 /etc/init.d/webbi-reloader

Добавьте сервис в автозапуск.

  • Наиболее надёжный способ:
    sudo ln -s /etc/init.d/webbi-reloader /etc/rc0.d/S01webbi-reloader
  • Если доступна команда chkconfig:
    sudo chkconfig --add /etc/init.d/webbi-reloader
  • Если доступна команда update-rc.d: 
    sudo update-rc.d webbi-reloader defaults
  • Если доступна команда rc-update: 
    sudo rc-update add webbi-reloader default

Управление сервисом.

  • Запуск:
    sudo service webbi-reloader start
  • Останов:
    sudo service webbi-reloader stop
  • Перезапуск:
    sudo service webbi-reloader restart
  • Получение сведений о текущем состоянии:
    sudo service webbi-reloader status
Настройка службы webbi-reloader для systemd

Рассмотрим, как настроить службу webbi-reloader для системы управления службами systemd.

Создайте в директории /etc/systemd/system/ файл webbi-reloader.service со следующим содержимым:

[Unit]
Description=Webbi nginx maintenance switch watcher



[Service]
ExecStart=/etc/nginx-reloader.sh "/etc/nginx/conf.d/maintenance.switch"
Restart=always
RestartSec=10
SyslogIdentifier=webbi-reloader
User=tessa



[Install]
WantedBy=multi-user.target

Tip

Вы можете найти этот файл в архиве в директории systemd.

Important

В случае необходимости запуска от другого пользователя укажите его имя в User. Учтите, что этот пользователь должен иметь права на чтение директории /etc/nginx/conf.d/ и на перезапуск nginx.

Настройте автозапуск сервиса webbi-reloader и запустите его, выполнив команду:

sudo systemctl enable webbi-reloader

Tip

Здесь webbi-reloader соответствует имени сервиса webbi-reloader.service без расширения .service.

Управление сервисом.

  • Запуск:
    sudo systemctl start webbi-reloader
  • Останов:
    sudo systemctl stop webbi-reloader
  • Перезапуск:
    sudo systemctl restart webbi-reloader
  • Получение сведений о текущем состоянии:
    sudo systemctl status webbi-reloader

Перевод системы в режим технического обслуживания

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

Important

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

Команда проверки работоспособности webbi:

tadmin Maintenance hcheck -wa:https://localhost/tessa/webbi -wt:42 -nologo

При нормальном режиме работы будет выведено healthy.

Команда проверки правильности настроек правил переключения в режим технического обслуживания для reverse proxy:

tadmin Maintenance Check -wa:https://localhost/tessa/webbi -wt:42 -nologo

При нормальном режиме работы будет выведено Ok.

Рассмотрим использование каждой из перечисленных команд.

Important

Для работы команд SendCommand и SendCommandClient требуется наличие соответствующих ключей с правами перевода системы в режим технического обслуживания. При этом приватный ключ должен быть доступен tadmin, а публичный известен webbi.

Important

Для работы команды SendCommandClient также требуется, чтобы в webbi был включен режим приёма внешних команд (Settings -> Management -> Enable в файле app.json).

Перевод системы в режим технического обслуживания при помощи команды SendCommand

Рассмотрим перевод системы в режим технического обслуживания командой tadmin SendCommand.

tadmin SendCommand Maintenance -k:admin.key -kp:admin -pp:c=switch-on "-pp:m:NormalMessage=$NormalMessage" "-pp:m:MaintenanceMessage={$MaintenanceMessage}\n{$CustomMessage} 15:00 27/02/2023" "-pp:m:MyMessage=Watever\nI'd like to write\nin multiple\nlines" "-pp:m:A=" -nologo

Кратко рассмотрим используемые аргументы (подробнее здесь):

  • -k - путь к приватному ключу с правами перевода системы в режим технического обслуживания;
  • -kp - пароль от приватного ключа;
  • -pp:c - задаёт выполняемую команду;
  • -pp:m: - позволяет определить сообщения для различных режимов работы, которые могут использоваться на страницах. Аргумент позволяет задать одно и более сообщений в формате <messageName>=<messageText>. Если ничего не указать после =, то тело соответствующего сообщения будет заменено на пустую строку, что (практически) эквивалентно его подавлению при выводе;
  • -nologo - предотвращает отображение сообщения по авторским правам и номеру версии.

Important

В Linux необходимо экранировать символ $ при помощи символа \ (т.е. использовать запись \$) или использовать вместо двойных кавычек (") одинарные ('). Т.к. это влияет на интерпретацию аргументов -m, содержащих конструкции вида $SomeMessageOrLocalizationString.
Это же справедливо и для Windows, если в качестве командной строки используется PowerShell.

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

wet-island-DjxdNv OK: Maintenance mode on

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

После этого система будет выводить сообщение примерно следующего содержания (при условии, что константа локализации CustomMessage содержит сообщение Ориентировочное время завершения работ:).

Перевод системы в режим технического обслуживания при помощи команды SendCommandClient

Рассмотрим перевод системы в режим технического обслуживания командой tadmin SendCommandClient.

tadmin SendCommandClient Maintenance -k:admin.key -kp:admin -wa:https://localhost/tessa/webbi -wm:management -wt:42 -pp:c=switch-on "-pp:m:NormalMessage=$NormalMessage" "-pp:m:MaintenanceMessage={$MaintenanceMessage}\n{$CustomMessage} 15:00 27/02/2023" "-pp:m:MyMessage=Watever\nI'd like to write\nin multiple\nlines" "-pp:m:A=" -u:admin -p:admin -nologo

Кратко рассмотрим используемые аргументы (подробнее здесь):

  • -k - путь к приватному ключу с правами перевода системы в режим технического обслуживания;
  • -kp - пароль от приватного ключа;
  • -wa - задаёт адрес сервера webbi;
  • -wm - маршрут, по которому webbi принимает внешние команды;
  • -wt - задаёт таймаут ожидания ответа при выполнении команды;
  • -pp:c - задаёт выполняемую команду;
  • -pp:m: - позволяет определить сообщения для различных режимов работы, которые могут использоваться на страницах. Аргумент позволяет задать одно и более сообщений в формате <messageName>=<messageText>. Если ничего не указать после =, то тело соответствующего сообщения будет заменено на пустую строку, что (практически) эквивалентно его подавлению при выводе;
  • -u, -p - стандартные аргументы для задания пользователя и пароля для доступа к web-сервису TESSA;
  • -nologo - предотвращает отображение сообщения по авторским правам и номеру версии.

Important

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

Important

В Linux необходимо экранировать символ $ при помощи символа \ (т.е. использовать запись \$) или использовать вместо двойных кавычек (") одинарные ('). Т.к. это влияет на интерпретацию аргументов -m, содержащих конструкции вида $SomeMessageOrLocalizationString.
Это же справедливо и для Windows, если в качестве командной строки используется PowerShell.

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

wet-island-DjxdNv OK: Maintenance mode on

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

После этого система будет выводить сообщение примерно следующего содержания (при условии, что константа локализации CustomMessage содержит сообщение Ориентировочное время завершения работ:).

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

tadmin SendCommandClient Maintenance -k:admin.key -kp:admin -wa:https://localhost/tessa/webbi -wm:management -wt:42 -pp:c=switch-on "-pp:m:NormalMessage=$NormalMessage" "-pp:m:MaintenanceMessage={$MaintenanceMessage}\n{$CustomMessage} 15:00 27/02/2023" "-pp:m:MyMessage=Watever\nI'd like to write\nin multiple\nlines" "-pp:m:A=" -pp:i -nologo

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

Important

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

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

tadmin SendCommandClient Maintenance -k:admin.key -kp:admin -wa:https://localhost/tessa/webbi -wm:management -wt:42 -pp:c=switch-on -pp:i -nologo

Imortant

Все ограничения изолированного режима сохраняются. Шаблоны сообщений считываются из файла app.json утилиты tadmin.

Перевод системы в режим технического обслуживания при помощи команды Maintenance

Рассмотрим перевод системы в режим технического обслуживания командой tadmin Maintenance Switch-On.

tadmin Maintenance Switch-On -wa:https://localhost/tessa/webbi -wt:42 "-m:NormalMessage=$NormalMessage" "-m:MaintenanceMessage={$MaintenanceMessage}\n{$CustomMessage} 15:00 27/02/2023" "-m:MyMessage=Watever\nI'd like to write\nin multiple\nlines" "-m:A=" -u:admin -p:admin -nologo

Кратко рассмотрим используемые аргументы (подробнее здесь):

  • -wa - задаёт адрес сервера webbi;
  • -wt - задаёт таймаут ожидания ответа при выполнении команды;
  • -m: - позволяет определить сообщения для различных режимов работы, которые могут использоваться на страницах. Аргумент позволяет задать одно и более сообщений в формате <messageName>=<messageText>. Если ничего не указать после =, то тело соответствующего сообщения будет заменено на пустую строку, что (практически) эквивалентно его подавлению при выводе;
  • -u, -p - стандартные аргументы для задания пользователя и пароля для доступа к web-сервису TESSA;
  • -nologo - предотвращает отображение сообщения по авторским правам и номеру версии.

Important

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

Important

В Linux необходимо экранировать символ $ при помощи символа \ (т.е. использовать запись \$) или использовать вместо двойных кавычек (") одинарные ('). Т.к. это влияет на интерпретацию аргументов -m, содержащих конструкции вида $SomeMessageOrLocalizationString.
Это же справедливо и для Windows, если в качестве командной строки используется PowerShell.

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

Opening session...
Session is opened
Try to switch rewrite rules.
Rewrite rules successfully switched.

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

После этого система будет выводить сообщение примерно следующего содержания (при условии, что константа локализации CustomMessage содержит сообщение Ориентировочное время завершения работ:).

Перевод системы в режим технического обслуживания можно выполнить и без необходимости взаимодействия с web-сервисом TESSA, в так называемом изолированном или автономном режиме. Для этого используется флаг -isolated.

tadmin Maintenance Switch-On -wa:https://localhost/tessa/webbi -wt:42 "-m:NormalMessage=$NormalMessage" "-m:MaintenanceMessage={$MaintenanceMessage}\n{$CustomMessage} 15:00 27/02/2023" "-m:MyMessage=Watever\nI'd like to write\nin multiple\nlines" "-m:A=" -isolated -nologo

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

Important

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

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

tadmin Maintenance Switch-On -wa:https://localhost/tessa/webbi -wt:42 -isolated -nologo

Imortant

Все ограничения изолированного режима сохраняются. Шаблоны сообщений считываются из файла app.json утилиты tadmin.

Источники локализации

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

Источник Порядок Описание Класс поставщик данных
Файл app.json утилиты tadmin 10 Строки локализации, расположенные в секции Settings -> Maintenance -> Localization. Не переопределяют уже имеющиеся в итоговой библиотеке строки ConfigurationMaintenanceLocalizationStrategy
Сервис локализации TESSA 100 Строки локализации, получаемые из стандартных библиотек локализации TESSA. Не используется в изолированном режиме. Не переопределяет уже имеющиеся в итоговой библиотеке строки LocalizationServiceMaintenanceLocalizationStrategy

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

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

Important

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

Выход из режима технического обслуживания

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

Вывод системы из режима технического обслуживания при помощи команды SendCommand

Рассмотрим вывод системы из режима технического обслуживания командой tadmin SendCommand.

tadmin SendCommand Maintenance -k:admin.key -kp:admin -pp:c=switch-off -nologo

Кратко рассмотрим используемые аргументы (подробнее здесь):

  • -k - путь к приватному ключу с правами перевода системы в режим технического обслуживания;
  • -kp - пароль от приватного ключа;
  • -pp:c - задаёт выполняемую команду;
  • -nologo - предотвращает отображение сообщения по авторским правам и номеру версии.

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

wet-island-DjxdNv OK: Maintenance mode off

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

Вывод системы из режима технического обслуживания при помощи команды SendCommandClient

Рассмотрим вывод системы из режима технического обслуживания командой tadmin SendCommandClient.

tadmin SendCommandClient Maintenance -k:admin.key -kp:admin -wa:https://localhost/tessa/webbi -wm:management -wt:42 -pp:c=switch-off -nologo

Кратко рассмотрим используемые аргументы (подробнее здесь):

  • -k - путь к приватному ключу с правами перевода системы в режим технического обслуживания;
  • -kp - пароль от приватного ключа;
  • -wa - задаёт адрес сервера webbi;
  • -wm - маршрут, по которому webbi принимает внешние команды;
  • -wt - задаёт таймаут ожидания ответа при выполнении команды;
  • -pp:c - задаёт выполняемую команду;
  • -nologo - предотвращает отображение сообщения по авторским правам и номеру версии.

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

wet-island-DjxdNv OK: Maintenance mode off

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

Вывод системы из режима технического обслуживания при помощи команды Maintenance

Рассмотрим вывод системы из режима технического обслужиания командой tadmin Maintenance Switch-Off.

tadmin Maintenance Switch-Off -wa:https://localhost/tessa/webbi -wt:42 -nologo

Кратко рассмотрим используемые аргументы (подробнее здесь):

  • -wa - задаёт адрес сервера webbi;
  • -wt - задаёт таймаут ожидания ответа при выполнении команды;
  • -nologo - предотвращает отображение сообщения по авторским правам и номеру версии.

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

Try to switch rewrite rules.
Rewrite rules successfully switched.

Что говорит о нормальном выполнении команды.

Back to top