Перенос существующей сети

Как свести три бэкенда, у каждого из которых свой plugins/Nexo/, к одному набору файлов.

В быстром старте вы выполняете /nexohub adopt lobby: вы называете бэкенд, он отправляет свой plugins/Nexo/ наверх, и это становится _shared/. Это вся работа, когда у вас один бэкенд или когда остальные — его копии.

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

Так что команда — это простая часть, а эта страница — всё остальное: как выбрать, какой бэкенд назвать, и что делать с отличиями остальных от него.

​

Перед началом

Сначала установите оба плагина обычным способом. Для принятия (adopt) нужен работающий мост на бэкенде, с которого вы принимаете файлы, и он должен знать своё собственное имя.

1. Установите NexoHub на прокси

   Положите jar прокси, запустите его, скопируйте сгенерированный секрет и задайте http.public_address. Оставьте nexo-data/ пустым; вы вот-вот его заполните.

2. Установите мост на каждый бэкенд

   NexoHubBridge.jar рядом с Nexo, заполненные hub.address и hub.secret, server_name: auto.

   Pack.server.type: HUB в plugins/Nexo/settings.yml каждого бэкенда мост записывает при первом запуске. Мост также сохраняет Pack.server локально при каждом пуше, так что эта единственная настройка никогда не передаётся между серверами.

3. Сделайте копию plugins/Nexo/ каждого бэкенда

   Это не опционально. После принятия и пуша файлы каждого бэкенда перезаписываются файлами хаба, и всё, что жило только на одном сервере и не попало в nexo-data/, исчезает с этого сервера.

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

​

Выбор бэкенда для повышения

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

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

Прежде чем решить, сравните их. Если вы можете собрать папки на одной машине:

diff -qr lobby/plugins/Nexo pvp/plugins/Nexo

Затем рассортируйте то, что получилось, на четыре кучки. Стоит сделать это на бумаге, прежде чем что-либо трогать:

Различие	Куда оно идёт
то, что должно было быть на каждом сервере	_shared/, поэтому повышайте бэкенд, у которого это есть
действительно индивидуальное для сервера, например другое значение в settings.yml	потом в servers/<name>/
одинаковое на нескольких серверах, но не на всех	потом в groups/<name>/, см. управление файлами
сгенерировано Nexo или другим плагином	никуда; оно пересоберётся

Последняя кучка больше, чем ожидают. pack/pack.zip, всё под pack/external_packs/, .assetCache/ и .deobfCachedPacks/ — это выходные данные. Если два бэкенда различаются там, это ничего не значит.

​

Принятие

На прокси:

/nexohub adopt lobby

[NexoHub] Asked lobby for its plugins/Nexo/ folder.
[NexoHub] Watch this console. What it leaves under pack/external_packs/ is listed there by name.

На том бэкенде:

[NexoHubBridge] Sending 118 file(s), 2412 KiB, to the hub as 'lobby'.
[NexoHubBridge] The hub took these files; they are what the whole network builds from now.

И на прокси:

[nexohub] Adopted 118 file(s) from lobby into _shared/.
[nexohub] lobby kept 4 entr(y/ies) in pack/external_packs/, which adoption never carries:
[nexohub]   DefaultPack_5b8ebdadb1.zip: Nexo downloads this itself, on every backend
[nexohub]   ShizuArt_Tavern_Furniture.zip: nothing on that backend says it wrote this, so it looks like yours
[nexohub]   _hub-betterhud-abcdef12: the hub put it here, and it is replaced on every push
[nexohub]   betterhud.zip: BetterHud writes it, on every backend that runs it
[nexohub] 1 of those are not accounted for by any plugin there. Put them in
          nexo-data/_shared/pack/external_packs/ if the whole network should have them.

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

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

Единственный случай, когда игрок необходим, — это бэкенд с server_name: auto, на котором никто ещё не был. Он пока не знает своё имя, поэтому с него нельзя принять файлы, пока кто-нибудь не зайдёт.

​

Что не передаётся

Наверх попадают только файлы, которые вы написали сами. Намеренно остаются на месте:

• pack/pack.zip, собранный пак
• всё под pack/external_packs/, что ваши плагины в любом случае пересоберут
• скрытые файлы и папки, так что .assetCache/ и .deobfCachedPacks/ остаются на месте
• резервные копии редакторов, заканчивающиеся на ~
• всё, что больше 64 МБ

external_packs/ — единственный пункт из этого списка, который стоит прочитать внимательно, а не пробежать глазами, потому что там не только сгенерированные выходные данные. Пак, который вы купили и положили прямо на бэкенд, тоже живёт там, и принятие оставляет его точно так же, как оставляет собственный вывод плагина. Это сделано намеренно: повышение копии этой папки с одного бэкенда заморозило бы его сборку в то, из чего затем пересобирается каждый сервер.

Поэтому принятие называет то, что оно оставило, в обеих консолях и отделяет записи, на которые претендует какой-либо плагин на этом бэкенде, от тех, на которые не претендует ничто. Незаявленные — ваши. Загрузите их один раз в nexo-data/_shared/pack/external_packs/, и с этого момента они будут у каждого бэкенда. .zip работает там так же хорошо, как и распакованная папка.

​

Почему сначала нужен запрос

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

Окно, которое открывает /nexohub adopt, действует пять минут и срабатывает один раз. Если вы видите одно из этих сообщений, значит, произошло именно это:

no adoption was requested; run /nexohub adopt lobby on the proxy first
that request expired; run /nexohub adopt lobby again

​

Если _shared/ не пуст

Принятие записывает файлы бэкенда поверх _shared/ без предварительной очистки, поэтому файл, который есть там, но не на бэкенде, остаётся. Это нормально, когда вы принимаете повторно после изменения, и вводит в заблуждение, когда вы начинаете с нуля.

Перед тем как что-либо перезаписать, делается снимок, так что если вы хотите чистый лист, удалите _shared/ по SFTP и примите файлы в пустую папку. Старая версия всё ещё доступна в /nexohub history.

​

После принятия

1. Проверьте, что всё парсится

   /nexohub validate
   

   Правленный руками plugins/Nexo/, который год работал в продакшене, — хорошее место, чтобы найти файл, который никто не загружал с момента его создания.

2. Верните различия на место

   Пройдитесь по кучкам, составленным ранее. Файлы для отдельных серверов идут в servers/<name>/, файлы, общие для нескольких серверов, — в группу, а всё остальное оставьте как есть.

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

3. Посмотрите на каждый бэкенд

   /nexohub status
   

   Каждый сервер должен быть in sync на одном и том же бандле, а имена слоёв рядом с каждым из них должны быть теми переопределениями, которые вы намеревались ему дать. Пустые серверы тоже, поскольку они отчитываются при своём опросе.

4. Запустите полную проверку

   /nexohub doctor
   

   Вот момент, когда она себя оправдывает. Она скажет вам, могут ли игроки реально достучаться до public_address, не провалил ли какой-нибудь бэкенд свою перезагрузку и не стоят ли ваши бэкенды на версиях Nexo или Minecraft, которые соберут разные паки. Расхождение версий — обычное дело в сети, которая росла по одному серверу за раз, и его почти невозможно определить снаружи.

5. Зайдите на сервер и переключитесь

   Скачайте пак один раз, попрыгайте между двумя серверами и следите, не начнётся ли второе скачивание. Одно скачивание — и миграция завершена. Если есть второе, см. устранение неполадок.

​

Если что-то пошло не так

Состояние до принятия находится в /nexohub history, под записью before adopting <server>.

/nexohub rollback 1769508900000-77c1a2e5

Это возвращает nexo-data/ назад и пушит его. О том, что откат делает с файлами, добавленными после, см. как не сломать свою сеть.