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

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

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

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

• releases — директория с релизами (версиями) приложений. В данной директории хранятся все устанавливаемые на сервер версии заданного приложения для возможности отката к предыдущей версии в случае неудачного обновления.

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

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

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

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

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

   rails@server:~/arm_isp$ touch current/tmp/restart.txt

4. Запуск, остановка, перезапуск
   
   Управление работой веб-приложений в общем случае осуществляется с помощью инит-скрипта веб-сервера nginx /etc/init.d/nginx. Например, команда на перезапуск nginx-а имеет следующий вид:

   root@server:~# /etc/init.d/nginx restart

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

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

• connection_manager или hcmd
  

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

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

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

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

3. Запуск, остановка, перезапуск
    
   Управление работой менеджера соединений осуществляется с помощью инит-скрипта /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 

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

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

2. Запуск, остановка, перезапуск
    
   Управление работой приложений-агентов осуществляется с помощью индивидуального инит-скрипта (например, для hpd — ). Команда на перезапуск имеет следующий вид:

   root@server:~# /etc/init.d/hpd restart