2.4. Миграция Boro Solution¶

2.4.1. Введение¶

Описание¶

Данный раздел описывает, как перенести установку ПО Boro Solution на другой сервер или обновить операционную систему с установленным Boro Solution, сохранив при этом все настройки и данные, кроме статистики задач. В процессе переноса можно обновить ПО Boro Solution на более новую версию (требуется согласование с технической поддержкой) и выбрать ОС из поддерживаемого списка.

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

Создание архива настроек текущего приложения и частичного дампа базы данных.
Установка на новый или старый сервер новой операционной системы.
Установка ПО Boro Solution на новой ОС:
- «перенос приложения» — для установки используется пак, который был получен ранее;
- «перенос и обновление приложения» — для установки требуется пак со свежей версией приложения.
Перенос старых настроек и дампа БД на новую установку ПО Boro Solution.
Лицензирование новой установки (получение ключей у технической поддержки).
Восстановление работы зондов с новым сервером Boro.

Примечания¶

Если используется внешняя БД под управлением PostgreSQL, нужно пропустить выполнение части пунктов, обозначенных как опциональные. Соответственно, не будет создан дамп базы данных, и его не нужно переносить на новую систему.
Для создания SQL-дампа (в конфигурации, которая указана в рамках данной статьи) вам понадобится дисковое пространство, размер которого можно ценить как «не более 5% от размера вашей текущей БД».
При выполнении большинства пунктов из инструкции переноса сервис мониторинга будет отсутствовать, это время вынужденного бездействия (Downtime).
При миграции сохраняются настройки из панели администратора (email, telegram), пользователи, проекты с настройками, записи о зондах и задачах, архивы со сформированными отчётами. Не сохраняется:
- статистика по задачам, если не используется внешний PostgreSQL;
- версии бинарных файлов зондов (после миграции сервер будет выдавать версию зонда из установочного пака);
- лицензионные ключи и сертификаты (требуется выпуск новых сертификатов);
- HTTPS-сертификат и соответствующий ключ к веб-интерфейсу (сертификат для браузера);
- собственные файлы (файлы логотипов в случае использования сервера под white label).
Совет: если планируется использовать старый сервер, рекомендуется сохранить настройки из каталога /etc. Архив может понадобиться для восстановления конфигурации после установки новой ОС, например при настройке сетевых интерфейсов.
```
time tar -czf etc.bckp_$(date -Id).tgz /etc

# additionally include certbot home directory:
#time tar -czf etc.bckp_$(date -Id).tgz /etc /home/certbot
```
Если миграция была прервана по каким-либо причинам после создания дампа базы данных, и старый сервер был восстановлен/запущен заново, то перед возобновлением миграции/переезда, лучше повторить процесс создания дампа заново.
В данной статье выбран самый медленный процесс переноса БД (путем создания SQL-дампа с помощью pg_dump) с длительным периодом простоя сервиса, однако данный способ имеет наименьшее количество «подводных камней».

Бэкап можно создать и без остановки Boro сервисов (без простоя). Он позволит восстановить базу данных, но часть данных может быть утеряна (например, информация о новых задачах, запущенных после начала создания дампа). Такой бэкап может быть полезен при оценке размера дамп-файла.

Существует также бинарный формат создания дампа. Перенос через бинарный дамп быстрее, но есть вероятность, что при обновлении ПО Boro Solution может измениться мажорная версия PostgreSQL. В таком случае нет гарантий полной совместимости дампов.

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

2.4.2. Миграция¶

Примечание

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

На старом сервере¶

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

Сохраните конфигурацию на сервере для всех запущенных зондов:

RAILS_PATH=${RAILS_PATH:-/opt/elecard/boro-rails-server}

_ruby_script='
  _p_a = App.where(id: RedisCache::Alive.get_live_app_ids).map do |a|
    a.auto_save_config(auto_save_descr: "before migrating Solution")
    [a.project_id, [a.id, a.desc]]
  end.group_by(&:first).map{|_p, _p_as| [_p, _p_as.map(&:last)]}.to_h
  puts "Live Probes:"
  Project.where(id: _p_a.keys).order(:id).each do |_p|
    puts "• project id:%4d, \"%s\", probes:" % [_p.id, _p.title]
    _p_a[_p.id].sort.each do |_app_id, _app_descr|
      puts "  • %4d, \"%s\"" % [_app_id, _app_descr]
    end
  end
'
su - boro -c "
  cd \"$RAILS_PATH\";
  source setup_env.sh;
  bin/rails runner '$_ruby_script'
"

RAILS_PATH может отличаться от указанного в скрипте. Укажите путь до установленного приложения Boro.

Остановите Boro Solution (с этого момента сервис становится недоступен):
```
systemctl stop \
  boro_puma.{default,web_api} \
  boro_sidekiq.{default,timeline} \
  boro_golang.{server,worker}
```
Примечание

Не обращайте внимания на сообщение об ошибке Failed to stop boro_sidekiq.timeline.service..., если оно появится.
Опциональный шаг. Пропустите, если используется внешняя база данных под управлением PostgreSQL. Создайте дамп базы данных. Обратите внимание, что в скрипте указаны таблицы, которые НЕ будут включены в дамп:
```
SQL_DUMP=${SQL_DUMP:-"dump.$(date -Id).common.sql.gz"}
tables_statistics_to_exclude=(
  statistics
  alarm_journals
  alarm_journal_actives
  timeline_data
  events
  thumb
  kpi_availabilities
  records
#   kpi_reports
#   alarm_records
#   alive_timelines
)

time (
  sudo --non-interactive --login --user=postgres \
    pg_dump boro_db \
      --no-password \
      --clean --if-exists \
      $(printf -- "--exclude-table-data=%s* " "${tables_statistics_to_exclude[@]}") \
) | gzip >"$SQL_DUMP"
chmod go-rwx "$SQL_DUMP"
```
dump.YYY-MM-DD.common.sql.gz — дамп-файл, который понадобится для переноса базы данных.

Примечание

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

Опциональный шаг. Выполните простую валидацию дамп-файла:

SQL_DUMP=${SQL_DUMP:-"dump.$(date -Id).common.sql.gz"}
_tbls=(users projects apps tasks)
_excerpt=$(gzip -dc "$SQL_DUMP" |
  sed -nE '/^COPY public\.('$(tr ' ' '|' <<<"${_tbls[@]}")') /,/^\\\.$/ { /^COPY public\./{p;=}; /^\\\.$/=}'
)
for _tbl in "${_tbls[@]}"; do
  _m=$(grep -EA2 "^COPY public\\.$_tbl " <<<"$_excerpt")
  printf "%9s: " "$_tbl"
  if [ -z "$_m" ]; then
    echo "ERROR, not found! "
    continue
  fi
  _line_first=$(tail -2 <<<"$_m" | head -1)
  _line_last=$(tail -1 <<<"$_m")
  printf "%8d\n" "$(($_line_last - $_line_first - 1))"
done

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

   users:           51
projects:          141
    apps:         1488
   tasks:       458145

Сделайте резервную копию настроек Rails-приложения, секретных ключей и других важных данных:

RAILS_PATH=${RAILS_PATH:-/opt/elecard/boro-rails-server}
RAILS_DUMP=${RAILS_DUMP:-"dump.$(date -Id).rails_artifacts.tgz"}

tar -C "$RAILS_PATH" -czf "$RAILS_DUMP" \
  .secret_key.file .secretkey.systemd.env \
  config/{.env,settings}.yml \
  tmp/alarms/

dump.YYY-MM-DD.rails_artifacts.tgz — tarball-архив с артефактами Rails;

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

На новом сервере¶

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

Установите Boro Solution, как описано в разделе Установка Boro Solution. Если установка производится на другой сервер, инсталляцию приложения можно начинать параллельно с созданием дампа БД, чтобы сократить время простоя.
Загрузите дамп-файл и архив с артефактами Rails на сервер.

Остановите Boro Solution:

systemctl stop \
  boro_puma.{default,web_api} \
  boro_sidekiq.default \
  boro_golang.{server,worker}

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

RAILS_PATH=${RAILS_PATH:-/opt/elecard/boro-rails-server}
DB_NAME=$(grep 'database: ' "$RAILS_PATH/config/database.yml" | cut -d: -f2 | tr -d ' ')
DB_USER=$(grep 'username: ' "$RAILS_PATH/config/database.yml" | cut -d: -f2 | tr -d ' ')

su - postgres -c "
  dropdb $DB_NAME
  createdb --encoding=UTF8 --locale=en_US.UTF-8 $DB_NAME
  psql --command='
    GRANT all PRIVILEGES on DATABASE \"$DB_NAME\" to \"$DB_USER\";
    GRANT all PRIVILEGES on SCHEMA     public     to \"$DB_USER\";
  ' $DB_NAME
"

RAILS_PATH может отличаться от указанного в скрипте. Укажите путь до установленного приложения Boro.

Опциональный шаг. Пропустите, если используется внешняя БД под управлением PostgreSQL. Восстановите данные из дамп-файла БД:

SQL_DUMP=${SQL_DUMP:-"dump.$(date -Id).common.sql.gz"}

time gzip -dc "$SQL_DUMP" | (sudo -iu postgres psql -tq $DB_NAME)

# Если имя пользователя в старой БД было другим, здесь его можно изменить:
#time gzip -dc "$SQL_DUMP" | sed "s/\"SenSay\"/\"$DB_USER\"/" | (sudo -iu postgres psql -tq $DB_NAME)

Опциональный шаг. Пропустите, если используется внешняя БД под управлением PostgreSQL. Запустите миграцию:
```
RAILS_PATH=${RAILS_PATH:-/opt/elecard/boro-rails-server}

su - boro -c "
  cd \"$RAILS_PATH\";
  source setup_env.sh;
  bin/rake db:migrate
"
```

Восстановите настройки, секретные ключи и другие данные:

RAILS_PATH=${RAILS_PATH:-/opt/elecard/boro-rails-server}
RAILS_DUMP=${RAILS_DUMP:-"dump.$(date -Id).rails_artifacts.tgz"}

gzip -dc "$RAILS_DUMP" | (sudo -u boro tar -C "$RAILS_PATH" -x)

Запустите службы Boro Solution:

systemctl restart \
  boro_puma.{default,web_api} \
  boro_sidekiq.default \
  boro_golang.{server,worker}

Проверьте работоспособность Boro Solution:
- запустите /opt/elecard/bin/status.sh;
- проверьте сконфигурированный базовый URL для зондов (см. раздел Изменение имени сервера): grep client_api_base_url ${RAILS_PATH:-/opt/elecard/boro-rails-server}/config/.env.yml;
- проверьте веб-интерфейс вручную, там должны отображаться данные проектов, профили всех настроек и прочая информация (кроме информации о запущенных задачах и зондах).
Пройдите путь Установки сертификатов.
На этом миграция завершена.

2.4.3. Перенос зондов¶

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

если в HTTPS-сертификате для старого сервера был прописан один или несколько IP-адресов, то интерфейсы с такими IP-адресами должны присутствовать на новом сервере;
если в HTTPS-сертификате для старого сервера было прописано одно или несколько имён хоста (hostname), то необходимо обновить эти DNS-записи так, чтобы они указывали на новый сервер;
в HTTPS-сертификате для нового сервера необходимо сохранить набор имён хоста и/или IP-адресов (то, что фигурирует в атрибуте CN/common name и опционально в SAN-е).

Если обновлялись DNS-записи, имеет смысл перезапустить зонды вручную (через консоль серверов, на которых они запущены), так как задержка обновления DNS-записей зондом может составлять до 20 минут. Кроме этого, необходимо учитывать задержку в распространении обновлений записей на самих DNS-серверах.

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

Если же при миграции часть условий выше не выполняется (например, изменяется имя хоста или IP-адреса), то для восстановления работы зондов нужно либо установить их заново, либо у каждого зонда скорректировать адрес сервера в monitor.cfg.

Если некоторые задачи не запускаются после перемещения зонда на новый сервер, вы можете восстановить их, применив сохранение конфигурации, которая была создана до остановки старого сервера. Такие конфигурации называются «auto save».

Обновите все активные зонды из веб-интерфейса, если для них доступна новая версия.