В данном руководстве рассматриваются вопросы эксплуатации приложений, входящих в состав АСР «Гидра». С полной схемой их взаимодействия можно ознакомиться на странице с описанием взаимодействия приложений.

Веб-приложения

Офис оператора связи (hoper или arm_isp)
Личный кабинет абонента (hupo или arm_private_office)
«Миграция» (arm_migration)
Платежный портал (arm_payments)
Портал авторизации (huas)

Веб-приложения, работающие с

, основаны на фреймворке Ruby on Rails (язык Ruby). Они функционируют под пользователем ОС rails с помощью веб-сервера nginx в связке с модулем passenger. Версии веб-приложений устанавливаются на сервере сотрудниками компании «Латера» с помощью собственных средств.

Каждое приложение устанавливаются на сервере в отдельную директорию (например, в /opt/hydra/rails/arm_isp), которая имеет следующее содержимое:

releases — директория с релизами (версиями) приложений. В данной директории хранятся все устанавливаемые на сервер версии заданного приложения для возможности отката к предыдущей версии в случае неудачного обновления.
current — символическая ссылка на директорию с текущей используемой версией приложения. На данную ссылку устанавливается путь до приложения в настройках виртуального хоста в настройках веб-сервера.
shared — директория с общими данными приложения, которые используются независимо от релизов. В данной директории, в частности, хранятся временные файлы и логи, которые генерирует приложение во время своей работы.

Эксплуатация

Ротация и архивация лога

В процессе своей работы веб-проложения сохраняет лог выполнения запросов в файл shared/log/production.log, размеры которого со временем эксплуатации системы могут достигать нескольких гигабайт. Чтобы избежать угрозы нехватки свободного дискового пространства, рекомендуется регулярно производить ротацию и архивацию данного лога, например, с помощью logrotate.
Удаление старых релизов

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

Для ускорения обработки запросов веб-приложения в ходе своей работы генерируют внутренний кэш в оперативной памяти. В некоторых случаях, например при изменении ссылки на текущий релиз приложения, кэш необходимо сбрасывать, чтобы избежать непредсказуемой работы приложения. Сброс кэша можно осуществить с помощью выполнения следующей команды из директории с приложением:
rails@server:~/arm_isp$ touch current/tmp/restart.txt
Запуск, остановка, перезапуск

Управление работой веб-приложений в общем случае осуществляется с помощью инит-скрипта веб-сервера nginx /etc/init.d/nginx. Например, команда на перезапуск nginx-а имеет следующий вид:
root@server:~# /etc/init.d/nginx restart
Перезапуск отдельного приложения может потребоваться, например, когда приложение перестает быть доступным для всех пользователей.

Менеджер соединений с БД

connection_manager или hcmd

Менеджер соединений написан с использованием фреймворка Ruby on Rails на языке Ruby, запускается под пользователем ОС rails и имеет аналогичную веб-приложениям структуру директорий. Он запускается в режиме демона и предоставляет интерфейс взаимодействия с БД со стороны веб-приложений.

Эксплуатация

Ротация и архивация лога

В процессе своей работы менеджер соединений сохраняет лог выполнения запросов в файле shared/log/connection_manager.log, размеры которого со временем эксплуатации системы могут достигать нескольких гигабайт. Чтобы избежать угрозы нехватки свободного дискового пространства, рекомендуется регулярно производить ротацию и архивацию данного лога, например, с помощью logrotate.
Удаление старых релизов

Со времением эксплуатации в директории releases может накопиться большое количество устаревших версий приложения, которые уже не совместимы с текущей установленной версией системы. Чтобы избежать засорения дискового пространства, рекомендуется производить регулярное удаление старых релизов, например, спустя месяц с момента их последнего использования.
Запуск, остановка, перезапуск

Управление работой менеджера соединений осуществляется с помощью инит-скрипта /etc/init.d/hydra_connection_manager. Например, команда на перезапуск имеет следующий вид:
root@server:~# /etc/init.d/hydra_connection_manager restart

Приложения-агенты

Коллектор трафика (hcd)
Автономный RADIUS-демон (hard)
Менеджер активного оборудования (hamd)
Платежный шлюз (hpd)
Демон интерфейса (hid)

Все агенты написаны на языке Python и имеют одинаковые возможности по настройке и управлению выполнением. При промышленной эксплуатации они запускаются в режиме демона и управляются с помощью индивидуального инит-скрипта (например, для hcd — /etc/init.d/hcd). Для работы каждого приложения существует персональный конфигурационный файл, в котором задаются параметры запуска. Например, для hard (файл /etc/hard/hard.conf):

# Уровень лог-сообщений
log level = debug
# Путь до лог-файла
log path = /var/log/hard/hard.log
# Максимальный размер лог-файла до создания нового, Кб
log rotate size = 10240
# Количество резервируемых лог-файлов
log rotate count = 25
# Путь до PID-файла приложения
pid path = /var/run/hydra/hard.pid

Эксплуатация

Ротация и архивация лога

В процессе своей работы приложения ведут лог в индивидуальном файле, путь к которому задается в конфиге (например, для hard — /var/log/hard/hard.log). Все агенты имеют встроенный функционал по ротации лог-файла. При настройке параметров, отвечающих за ротацию (log rotate size и log rotate count) важно уделить внимание интенсивности заполнения лог-файла во время эксплуатации системы, на основе которой выставить подходящие значения в конфиге. Лог-файл должен содержать данные минимум за последнюю неделю работы приложения.
Запуск, остановка, перезапуск

Управление работой приложений-агентов осуществляется с помощью индивидуального инит-скрипта (например, для hpd — ). Команда на перезапуск имеет следующий вид:
root@server:~# /etc/init.d/hpd restart