Ты хотел запустить ноду, но вот это всё линуксовое непонятно и бесит? Конечно же я не соглашусь что линукс это плохо, просто помогу изменить ваше отношение к платформе, и дать необходимый набор знаний для запуска ноды…
Вот тебе, дорогой мой читатель — «Букварь нодо-дела» !
ВНИМАНИЕ: Обязательно прочтите в конце статьи раздел “Восстанавливаем упавшую ноду”
В этой статье я постарался предельно просто, насколько это возможно для данной тематики, и доступно донести информацию о том, как правильно и «по-взрослому», развернуть, настроить и запустить ноду на арендованных ресурсах. На примере тестовой ноды Symbol.
Не так давно, на NEM HUB Social Mining, мы попробовали и таки сделали запуск тестовой ноды Symbol на Windows 10. Кстати кто пропустил это мероприятие или не знает о NEM HUB Social Mining — не упустите возможность зарегистрироваться и присоединиться к сообществу NEM HUB Social Mining ! Там не только интересно, но и можно получить дополнительный доход !
Если говорить о продуктивной эксплуатации нод, т.е. «по-взрослому», приведенный ранее вариант не самый лучший, и это очень мягко сказано! Почему? Потому что домашний ПК/ноутбук, вы будете постоянно выключать/ перезагружать, а это не является нормальным режимом работы ноды. Ну и сама связка систем и окружения — действительно “неестественная” для таких задач. Например — все легко решили вопрос с пробросом портов на домашнем роутере? Уверен, что не все! Поэтому более правильным будет развертывание ноды на выделенном сервере за пределами квартиры/дома/виллы или юрты😊
Что такое арендуемые сервера и какие они бывают?
Если не сильно глубоко вдаваться в решения, это могут быть:
1. физический выделенный сервер.
2. виртуальный сервер
3. облако, где вам будут выделены ресурсы, из которых вы будете сами строить свой сервер.
Вариант 1 не самый выгодный, т.к. стоит дорого
Вариант 3, тоже не самый дешёвый и требует определенных знаний.
Самый простой и доступный вариант — это виртуальный частный сервер или VPS, аббревиатура, которую вы часто встречали. Это то, что нам надо — просто, недорого, и огромный выбор! Площадок которые предлагают VPS реально так много, что я даже не смогу их перечислить! Я лишь приведу небольшой список тех, которые я сам использовал в своей практики, для того чтобы оставить вам право выбора !
В этой статье я вам расскажу и объясню общую схему, которая вам гарантированно поможет запустить тестовую ноду Symbol сейчас, а также любую другую продуктивную ноду.
Для начала я вам покажу очень простую схему, которая описывает работу фактически любой ноды. Тут нет ничего сложного!
Давайте определимся и договоримся о аббревиатуре которую мы будем использовать, чтобы говорить “на одном языке” — итак “нода”, это виртуальный/физический сервер, на котором установлено специальное программное обеспечение (операционная система + ПО для работы ноды), этот сервер должен быть подключен к сети интернет, у него должен быть статический (неизменный) IP адрес, и у него должны быть открыты определенные порты. Всё!
Выглядит просто и понятно. Давайте теперь разберемся с нюансами ? Например у когото может возникнуть вопрос — что такое порт? Я не буду вдаваться в глубины сетевых технологий, а поясню это по-другому:
- IP адрес, это как адрес вашего многоквартирного дома. На пример ул. Нодостроителя Умелого, дом 1, адрес сервера пишется чуть по-другому и будет выглядеть, например так: 35.202.153.18. Эти цифры и есть то, что называется IP адрес.
Далее — информация в сети интернет передается наборами или пакетами данных. Это что-то типа писем, которые мы отправляем на почте облизав конверт и марку чтобы прилепить второе к первому, предварительно в него что-то вложив. Когда вы отправляете письмо, вы (упрощаем схему) указываете Адрес и Номер Квартиры получателя. Адрес — это IP адрес.
А что же тогда номер квартиры? Вот это и есть порт! У каждого сервера, согласно принятых стандартов, есть порты с номерами от 1 до 65 535. Т.е. сервер — это дом с 65 535 квартир. Т.е. когда вам кто-то отправляет письмо, вы говорите — отправь мне на адрес 35.202.153.18 на порт 3000.
Нода Symbol, использует порт 3000 для того, чтобы к этой ноде могли обращаться другие сервера/пользователи и отправлять свои письма с запросами. Итого:
— Сервер = «ваш дом»
— адрес «вашего дома» ул. Нодостроителя Умелого, дом 1 = адрес сервера, например 35.202.153.18
— номер «вашей квартиры» 3000, куда вы принимаете письма = порт № 3000
Соответственно, чтобы обратиться по адресу ул. Нодостроителя Умелого, дом 1, квартира 3000, в «серверном» стандарте, надо указать адрес 35.202.153.18:3000
При этом, чтобы письмо было вам доставлено почтальоном, после того как он позвонит вам в дверь, вы должны открыть её. На вашем сервере этот порт должен быть открыт постоянно т.к. нода должна получать все «письма», из интернета, которые отправляются другими пользователями на адрес 35.202.153.18:3000. Это называется “слушать порт”.
Если говорить о ноде Symbol, то она использует еще один порт — 7900, он необходим серверам Catapult для связи между узлами.
Общая схема выглядит так:
Это полная картинка ноды, причем фактически любой. И так, что у нас есть ?
1. Подключение к сети интернет
2. Виртуальный сервер
3. Открытые порты 3000 и 7900 (это необходимо для ноды Symbol)
4. ПО для реализации функций ноды
5. Панель или консоль для доступа и управления к удаленному серверу
6. Владелец ноды, а по сути, это вы, читатели статьи
Что мы должны сделать? Или каков наш план работ?
1. Выбор площадки для аренды виртуального сервера VPS
2. Регистрация и оплата ресурсов
3. Подключение к консоли управления вашим будущим сервером
4. Установка операционной системы (остановимся на Ubuntu 18.04 LTS) и необходимых пакетов
5. Установка Docker
6. Установка утилиты управления контейнерами Docker-Compose
7. Установка контейнера Symbol node
8. Настройка firewall для открытия нужного порта. И пару слов о безопасности
9. Запуск нод
9.1. Запуск обыкновенной ноды, режим peer-assembly.
9.2. Запуск ноды в расширенном режиме api-harvest-assembly.
9.3. Обновление ноды peer-assembly или api-harvest-assembly на новую версию
9.4. Проверяем работу портов
9.5. Дополнительные настройки
9.6. Доверяй — но проверяй !
10. Набор полезных команд
11. Полезные ссылки
12. И еще раз о безопасности Docker
13. Восстанавливаем упавшую ноду
И так — приступаем!!!
1.Выбор площадки для аренды виртуального сервера
Что нам надо знать, при подборе площадки для аренды ресурсов под ноду? Само собой количество ресурсов, которое нам понадобится на построение самой ноды. Что такое ресурсы и какие нас интересуют?
1. Процессор, измеряется в ядрах CPU, и частоте ядра — выбираем согласно требованиям к ноде (2 ядра или больше)
2. Объем оперативной памяти, измеряется в Gb — выбираем согласно требованиям к ноде (8 Гб или больше)
3. Объем дискового хранилища, измеряется в Gb — выбираем согласно требованиям к ноде (30 Гб или больше)
4. Статический IP адрес — Да/Нет, надо «Да»
5. Объем трафика, измеряется в Gb — как правило трафик безлимитный, но на самых бюджетных тарифных планах может быть ограничение трафика, обратите внимание т.к. могут возникнуть «неожиданные» затраты.
Внимание ! Нижеприведенные ссылки — реферальные! При этом полезные и с объективной информацией, которая вам позволит сделать максимально правильный выбор (данные были выверены на 01.07.2020). Если вам не сложно — зарегистрируйтесь по ним, этим вы окажете поддержку текущих и дальнейших экспериментов и тестов, которые требуют финансовых вложений, ибо коммунизм почему то еще не наступил…
Из тех, что сам использую/использовал, могу рекомендовать:
- сервис AllNode — платформа «заточена» сугубо под развертывание нод, процесс максимально автоматизирован, настройка ноды предельно упрощена и не требует фактически никаких знаний. Цена ноды, на данный момент 10$ в месяц (+ единоразово 1$ за первичное развертывание ПО), что соизмеримо с минимальной суммой аренды VPS.
- Список недорогих VPS хостинг-площадок в РФ, с примерной ценой аренды в месяц, за подходящую конфигурацию (2 ядра, 4 Гб ОЗУ, 20Гб диск, статический IP):
Fastzone — от 1300 руб/мес
Firstbyte — от 720 руб/мес
Eurobyte — от 810 руб/мес
Ruvds — от 470-1040 руб/мес (зависит от схемы использования постоянный ресурс или по запросу, необходимо вникнуть в принцип этого подхода)
Vps.house — от 1340 руб/мес - Список недорогих VPS хостинг-площадок в Украине, с примерной ценой аренды в месяц, за подходящую конфигурацию (2 ядра, 4 Гб ОЗУ, 20Гб диск, статический IP):
HOSTiQ — от 378 грн/мес
vds64 — от 675 грн/мес
vps.ua — от 384 грн/мес
server.ua — от 590 грн/мес
Cityhost.ua— от 332 грн/мес
Ukrnames.com— от 359–500 грн/мес (первый месяц -50%)
Fornex.com — от 600 грн/мес (ЕС)
GMhost — от 380 грн/мес - условно бесплатный вариант от Google Cloud. Большой белый брат, чье имя пишут буквами разных цветов,щедрый, но хитрый как и все бледнолицые 😊 Запомните — первый раз вам выделяется бесплатный кредит в 300 баксов на аренду по сути любого ресурса в их облаке. Но стоимость используемых ресурсов постоянно считается и списывается с этих 300 баксов. По этому не забывайте что, как только сумма потребленных ресурсов превысит 300 баксов — с вашей карты начнут снимать оплату. Поэтому заказывая ресурс, смотрите на ориентировочную стоимость в месяц и прикидывайте на сколько вам хватит 300$. Пробовать обмануть систему создавая новые аккаунты не стоит — бледнолицые хитрые и быстро “вычислят по ипшнику” т.н. соседние аккаунты, заблокируют их, а оно вам надо ? Да, и настройка ноды на этом ресурсе требует знаний и бубна…
2. Регистрация и оплата ресурсов
Здесь все зависит только от вас. Выбирая ту или иную площадку, вы выбираете ту, которая вам будет максимально «комфортной» со стороны финансовых условий (цена) так и сервисов (механизмы оплаты, предоплата, постоплата и т.п.). Выбирайте то, что в итоге вам больше нравится и то, что вам более удобно! Как правило весь процесс сводится к 2 шагам:
- Регистрация на платформе. Логин, пароль, имя, платежная карта и т.п. информация
- Заказ ресурсов/пакета и их оплата
3. Подключение к консоли управления вашим будущим сервером
Подключение к вашему серверу/ноде, как правило происходит через браузер (консоль появится в отдельном окне браузера) или используя специальные приложения, работающие по SSH (22 порт) протоколу через внешний IP адрес вашего сервера.
Здесь пригодится утилита PuTTY — простая, надежная и удобная. На официальном сайте есть документация которая поможет вам разобраться как с ней работать.
4. Установка операционной системы (остановимся на Ubuntu 18.04 LTS) и необходимых пакетов
После того как на арендованном хостинге у вас развернулся образ системы, приступаем к ее настройке. Работаем понятное дело только с консолью! Работа с консолью предполагает ввод набора команд и их выполнение. Команды вводим руками, чтобы выполнить то что ввели — жмем Enter
Обновляем систему и пакеты:
sudo apt update && sudo apt upgrade
Установим пакеты, необходимые для работы apt по протоколу https:
sudo apt install apt-transport-https ca-certificates curl software-properties-common
И устанавливаем GIT
sudo apt install git
5. Установка Docker
Добавляем на сервер ключ официального репозитория разработчиков Docker:
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
Устанавливаем сам докер
sudo apt install docker
6. Установка утилиты управления контейнерами Docker-Compose
sudo apt install docker-compose
7. Установка контейнера Symbol node
sudo git clone https://github.com/nemfoundation/symbol-testnet-bootstrap.git
Структура папок ноды будет выглядеть так:
root:
— / symbol-testnet-bootstrap
— — /api-harvest-assembly — здесь контейнер с “расширенной” нодой
— — /peer-assembly — здесь контейнер с “стандартной” нодой
— — / api-assembly
— — /identity — здесь файл настройки ноды
— — /utilities
— — /… и другие файлы и папки нам не интересные
8. Настройка firewall для открытия нужного порта. И пару слов о безопасности.
Во время проведения одного эксперимента с тестовыми нодами, в одной телеграмм группе (рекомендую присоединиться — https://t.me/nem_hub_ru ) был поднят вопрос — «а что с безопасностью серверов для нод, мы же порты открываем !?». Все верно, порты открываем, без открытых портов 3000 и 7900 нода не будет работать полноценно!
Порт 7900, используется сервером Catapult для связи между нодами.
Порт 3000, используется шлюзом REST для предоставления пользователям/сервисам доступа к API узла.
Если говорить о безопасности вашей ноды, надо понимать, что безопасность зависит только о т нас самих, знаний и понимания того как работают эти технологии.
Есть базовый набор правил, которые необходимо соблюдать:
1. Root пользователь, да и любой другой, должен иметь безопасный пароль. Это значит что категорически нельзя использовать пароли типа 1111, qwerty, password и т.п. простые, «примитивные» пароли. Такие пароли «вскрываются» достаточно просто. А вот пароль {FRYB-vtyz-pf-10-CTREYL! Вряд ли можно «подобрать», как минимум затраты на его взлом несоизмеримо выше, чем выгода от такого взлома. Поэтому придумывайте СЛОЖНЫЙ пароль — большие/маленькие буквы, спецсимволы, цифры.
Да, указанный выше пароль ({FRYB-vtyz-pf-10-CTREYL!) не используйте, поскольку он опубликован — а значит он уже скомпрометирован!!!
2. Порты. Порты — это по сути «двери» в ваш сервер. В правилах «хорошего тона» — все неиспользуемые порты, должны быть закрыты для доступа снаружи (т.е. из сети internet), т.е. не принимать никаких запросов, и просто «отфутболивать» любое обращение к ним, а лучше вообще «молчать». Теоретически для вашей ноды должны быть открыты 3 порта:
— 22 TCP — для удаленного доступна к серверу ноды по SSH через, например, утилиту PuTTY. Часто организуется “автоматически” провайдером VPS. На этом пункте остановлюсь чуть подробнее. Используя данное подключение, мы получаем безопасный доступ к вашему серверу, а также его терминалу, для управления работой сервера. Это может показаться не так удобно, как с графическим интерфейсом и мышкой, но это безопаснее, надежнее, требует меньше ресурсов и… удобно ! Теоретически, по умолчанию, 22 порт должен быть открыт.
— 3000 TCP — доступ к API интерфейсу ноды
— 7900 TCP — поддержка взаимодействия нод
Итак, как открыть нужные порты?
1. Для начала посмотрим какие правила есть вообще в системе:
sudo iptables -nvL
2. Открываем 22, 3000 и 7900 порты:
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 3000 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 7900 -j ACCEPT
ВНИМАНИЕ ! Можно закрыть все остальные порты (игнорировать все что не задано разрешающими правилами), но тут надо быть очень аккуратным и точно понимать что вы делаете и как это работает. В случае неправильных действия вы можете заблокировать самим себе удаленный доступ к своей виртуальной машине…
Если осознаете риски, и уверены в том что вы делаете — тогда этот пункт для вас.3. Ну и «вишенка на торт» — меняем политику по умолчанию на DROP (игнорировать все что не задано разрешающими правилами)
sudo iptables -P INPUT DROP
cохраняем изменения в настройках ipsec
sudo iptables-save
4. И немного информации, сугубо для общего расширения знаний:
2 полезных сценария, которые могут быть вам полезны в ваших проектах: запретить все что не разрешено и разрешить все что не запрещено
Сценарий 1.
Запретить все что не разрешено
Разрешить подключение с любых IP для определенных портов
sudo iptables -А INPUT --dport ПОРТ1,ПОРТ2,ПОРТ3 -j ACCEPT
Разрешить подключение на любые порты с определенного IP
sudo iptables -A INPUT -s IP_АДРЕС -j ACCEPT
Разрешить подключение на определенные порты с определенного IP
sudo iptables -A INPUT --dport ПОРТ1,ПОРТ2,ПОРТ3 -s IP_АДРЕС -j ACCEPT
Запретить все остальное
sudo iptables -P INPUT DROP
Сценарий 2.
Разрешить все что не запрещено
Запретить подключение с любых IP для определенных портов
sudo iptables -А INPUT --dport ПОРТ1,ПОРТ2,ПОРТ3 -j DROP
Запретить подключение на любые порты с определенного IP
sudo iptables -A INPUT -s IP_АДРЕС -j DROP
Запретить подключение на определенные порты с определенного IP
sudo iptables -A INPUT --dport ПОРТ1,ПОРТ2,ПОРТ3 -s IP_АДРЕС -j DROP
Разрешить все остальное
sudo iptables -P INPUT ACCEPT
При этом я настоятельно рекомендую более глубоко изучить тему безопасности Linux систем, и работу iptables/ipsec.
На этом подготовительные работы завершены, и теперь приступаем к непосредственному запуску нод !
9. Запуск нод
В данном разделе мы научимся запускать, останавливать, обновлять ноды, причем в 2х вариантах
- упрощенный режим — peer-assembly. Это режим простой ноды, которая только обрабатывает транзакции.
- расширенный режим — api-harvest-assembly. Это нода которая не только обрабатывает транзакции но и обеспечивает доступ к API Symbol.
9.1. Запуск обыкновенной ноды, режим peer-assembly.
Выполняем команды:
cd /
cd symbol-testnet-bootstrap/peer-assembly
sudo docker-compose up --build -d
И проверяем работоспособность ноды:
sudo docker-compose ps peer-node
В итоге мы должны получить ответ похожий на этот:
9.2. Запуск ноды в расширенном режиме api-harvest-assembly.
Выполняем команды:
cd /
cd symbol-testnet-bootstrap/api-harvest-assembly
sudo docker-compose up --build -d
Дожидаемся отработки команд. Даем ноде синхронизироваться (минут 10–15), и проверяем работоспособность !
На любом устройстве, в браузере вводим ссылку:
http://ваш_внешний_ip_адрес:3000/node/info
и в ответ вам должна прийти информация о вашей ноде.
На примере моей ноды это выгладит так
http://35.202.153.18:3000/node/info
{“version”:0,”publicKey”:”8660DF31B6E84C7D7FB0E40C59446113650DD623CF57E680628775BED8F4D19C”,”networkGenerationHashSeed”:”4009619EB7A9F824C5D0EE0E164E0F99CCD7906A475D7768FD60B452204BD0A2",”roles”:3,”port”:7900,”networkIdentifier”:152,”host”:””,”friendlyName”:”nemhub-socialmining-2020-quest”}
Если ответ похож на этот — поздравляю ! Вы запустили ноду в расширенном режиме api-harvest-assembly !
9.3. Обновление ноды peer-assembly или api-harvest-assembly на новую версию
Ни что не вечно под луной, как кто-то сказал, это касается и нас с вами, а в данном случае наших нод ! Разработчики не просто так едят свой хлеб/суши/батат и прочее — они постоянно добавляют новые фичи, исправляют старые баги или на оборот, но на месте не стоят. Поэтому логично что ПО ноды надо периодически обновлять.
Обновление простой ноды peer-assembly:
cd /
cd symbol-testnet-bootstrap/peer-assembly
sudo docker-compose down
cd /
sudo rm -R symbol-testnet-bootstrap
sudo docker system prune -a (возможно запросит подтверждение, нажмите “y”)
Теперь опять загружаем последнюю версию ноды из репозитория:
git clone https://github.com/nemfoundation/symbol-testnet-bootstrap.git
Запускаем обновленную ноду:
cd /
cd symbol-testnet-bootstrap/peer-assembly
sudo docker-compose up --build -d
Обновление расширенной ноды api-harvest-assembly:
Для расширенной ноды обновление делается очень схоже с предыдущим пунктом, все отличие только в папках:
cd /
cd symbol-testnet-bootstrap/api-harvest-assembly
sudo docker-compose down
cd /
sudo rm -R symbol-testnet-bootstrap
sudo docker system prune -a (возможно запросит подтверждение, нажмите “y”)
Теперь опять загружаем последнюю версию ноды из репозитория:
sudo git clone https://github.com/nemfoundation/symbol-testnet-bootstrap.git
Запускаем обновленную ноду:
cd /
cd symbol-testnet-bootstrap/api-harvest-assembly
sudo docker-compose up --build -d
9.4. Проверяем работу портов
Ранее мы настроили порты в firewall, для того чтобы нода могла “общаться с миром”.
Проверяем что они доступны — для этого используем сканер портов, на ваш выбор:
https://hidemy.name/ru/port-scanner/
https://free.proxy-sale.com/skaner-portov/
https://portscaner.ru/
Результат сканирования должен быть похож на этот:
9.5. Дополнительные настройки
Важно! После первого запуска ноды, автоматически создается файл настроек ноды config-input.yaml.
Он расположен по пути symbol-testnet-bootstrap/identity. Почему я об этом говорю? В настройках этого файла есть возможность задать «дружественное» имя для ноды. По умолчанию оно выглядит похожим на такое «8660df31», что скажем честно — мало информативно, хотя чего ожидать от бездушной машины !? Так вот я вам расскажу как это исправить ! Надо запустить команды:
Останавливаем контейнер:
sudo docker-compose down
Переходим в корень файловой системы:
cd /
Переходим в папку с файлом настроек:
cd symbol-testnet-bootstrap/identity
Запускаем редактор:
sudo nano config-input.yaml
а затем найти запись поле (оно по умолчанию в самом конце)
friendly_name: ‘тут_чтото_будет_написано’
и заменить ‘тут_чтото_будет_написано’ на более читаемое название, для примера напишем
friendly_name: ‘mytestsymbolnode000001’
После этого сохраняем изменения (Ctrl + O) и выходим из редактора (Ctrl+X).
Теперь надо опять повторить переход в папку с контейнером и его запуск:
cd /
cd symbol-testnet-bootstrap/peer-assembly
или
cd symbol-testnet-bootstrap/api-harvest-assembly
sudo docker-compose up --build -d
9.6. Доверяй — но проверяй !
А как еще проверить итоги работы в п.п. 9.1/9.2/9.3/9.4/9.5 ? Достаточно просто! Если ваша нода правильно стартанула, и все правильно настроено, то она должна будет отобразиться (через некоторое время, примерно 10–15 минут) в списке общедоступных нод по адресу:
https://symbolnodes.org/nodes/
Не нашли ? Не беда — идем на страницу поиска:
https://symbolnodes.org/search/
и в правом верхнем углу вводим внешний IP вашей ноды. Если все хорошо, то вы увидите что-то схожее (в данном примере наша тестовая нода в режиме peer-node)
Ваша нода там видна? Если видна — наслаждаемся итогами и полученными знаниями!
ВНИМАНИЕ !
На момент написания этой статьи, актуальной версией Symbol ноды была сборка 0.9.6.3. Не будет лишним периодически заходить на github проекта, и смотреть версии последних релизов:
https://github.com/nemfoundation/symbol-testnet-bootstrap/releases/
10. Набор полезных команд:
Запуск докера:
sudo docker-compose up --build -d
Остановка докера:
sudo docker-compose down
Проверка версии docker-compose :
docker-compose –version
Проверка запуска контейнеров
sudo docker ps
В итоге будет нечто похожее (обратите внимание — должно быть 4 контейнера !):
Перезапуск докера (обычная версия)
cd /
cd symbol-testnet-bootstrap/peer-assembly
sudo docker-compose down
sudo docker-compose up -d
Перезапуск докера (расширенная версия)
cd /
cd symbol-testnet-bootstrap/api-harvest-assembly
sudo docker-compose down
sudo docker-compose up -d
Сброс настроек ноды (помогает при сбоях расширенной ноды, таких как остановка синхронизации)
1. Остановить ноду
cd /
cd symbol-testnet-bootstrap/peer-assembly
sudo docker-compose down
2. Выполнить
sudo ./reset-to-nemesis.sh
3. Запустить ноду
sudo docker-compose up -d
Проверка работоспособности докера «Hello world»:
sudo docker run hello-world
Обновление системы и пакетов программ:
sudo apt update && sudo apt upgrade
Восстановить настройки ipsec:
sudo iptables-restore
Список правил в системе
sudo iptables --list-rules
11. Полезные ссылки
Экспроллер узлов сети:
https://symbolnodes.org/server/
GIT Symbol Node:
https://github.com/nemfoundation/symbol-testnet-bootstrap/releases
GIT Symbol wallet:
https://github.com/nemfoundation/symbol-desktop-wallet/releases
Информация о вашей ноде:
http://your_external_ip_address:3000/node/info
http://your_external_ip_address:3000/node/health
http://your_external_ip_address:3000/node/peers
http://your_external_ip_address:3000/chain/height
12. И еще раз о безопасности Docker.
Сразу начну с главного — теоретически есть 2 пути для «взлома» вашей ноды, при использовании контейнера:
1. Компрометация на уровне ПО внутри контейнера. Данный сценарий может быть «разыгран» при условии, что разработчиком в контейнер был заложен зловредный код (умышленно или нет), который в определенный момент может сработать и стать «вратами» для взлома системы. Также, из «внутренних» проблем возможен вариант с ошибками в правах доступа внутри контейнера.
Я предположу, что разработчики Symbol не сильно заинтересованы в создании «закладок» в своих нодах, как и в допущении ошибок в системе безопасности самого контейнера, что гарантированно приведет к свертыванию проекта и сведению к 0 всей многолетней работы. С точки зрения рисков — указанные выше, будем считать стремящимся к 0.
2. Незащищенное внешнее соединение позволяющее получить несанкционированный доступ к управлению службой Docker. Здесь все просто — оставьте открытыми только те порты которые надо, выполните рекомендации по безопасности хост-системы, и будем вам «сухо и комфортно». Если очень просто поясню — если у вас открыты нужные для работы ноды порты, а остальные закрыты, при этом вышеуказанные «внутренние» риски стремятся к 0, то и открытые 3000 и 7900 порт не создадут вам проблему! Почему? Потому что эти порты «слушает» только безопасное ПО ноды, и оно не позволяет выполнять любые некорректные инструкции.
Если у вас есть «подозрения» что все плохо — чуть ниже, тулзы вам в руки, и проверяйте ноду, ищите потенциальные уязвимости, это будет очень полезно и познавательно !
Средства проверки безопасности хоста с Docker:
https://github.com/coreos/clair — бесплатный инструмент
https://snyk.io/ — коммерческая версия, но есть и бесплатная
https://anchore.com/opensource/ — коммерческая версия, но есть и бесплатная
Полезные ссылки по теме Symbol Node:
https://symbolnodes.org/
https://symbolnodes.org/nodes/
Официальная информация по Docker / Docker Compose
https://docs.docker.com/engine/install/ubuntu/ https://docs.docker.com/compose/install/
Полезные статьи по безопасности Docker (для общего ознакомления)
https://habr.com/ru/company/acribia/blog/448704/ https://habr.com/ru/company/flant/blog/474012/
https://codeby.net/threads/docker-10-rekomendacij-pobezopasnosti.67203/
https://itfb.com.ua/reshenie-problem-s-bezopasnostyu-docker/
https://www.securitylab.ru/analytics/505009.php
https://system-admins.ru/problemy-bezopasnosti-docker-kontejnerov/
13. Восстанавливаем упавшую ноду
Так уж сложилось, что мы участвуем в эксперименте, когда еще основная сеть не запущена. Поэтому мы “ловим” баги, и это нормально !
В данном разделе будут добавляться выявленные баги и решения, в начале будут идти самые свежие. Итак поехали, внимательно читаем, сравниваем со своей проблемой, если подходит — применяем “рецепт”
Описание проблемы: Через некоторое время нода “падает”, или не синхронизируется, или зависает, или вариации из предыдущих.
Причина проблемы: в тестовой сети, при реальной нагрузке, нода потребляет значительный объем памяти для синхронизации. Нет, она не будет есть есть и есть память сколько не дай, просто существует минимально необходимый обьем который необходим для стабильной работы.
На своем опыте пришол к таким характеристикам сервера для ноды:
процессора — 2–4 ЦПУ
память — 8 Гб , но гарантированно будет работать если будет 12–14 Гб ОЗУ
Инструкция по “оживлению” падающей ноды:
1.Останавливаем контейнеры
cd /
cd symbol-testnet-bootstrap/api-harvest-assembly
sudo docker-compose down
Останавливаем сам сервер, а точнее ВМ. Добавляем память чтобы итого было минимум 8 Гб ОЗУ, но лучше 12 или больше
Запускаем сервер/ВМ
2. После запуска сервера проверяем — есть ли файл recovery.lock в папке symbol-testnet-bootstrap/api-harvest-assembly/data/api-node :
cd /
cd symbol-testnet-bootstrap/api-harvest-assembly/data/api-node
ls | grep recovery.lock
Если есть — УДАЛИТЬ:
sudo rm recovery.lock
3. Переходим в папку с настройками:
cd /
cd symbol-testnet-bootstrap/api-harvest-assembly/api-node/userconfig/resources
открываем файл config-node.properties.template для редактирования
sudo nano config-node.properties.template
в файле config-node.preperties.template параметр maxBlocksPerSyncAttempt = 1435
изменить на
maxBlocksPerSyncAttempt = 400
4. Выполнить скрипт сброса настроек ноды в дефолтное состояние, “обнуление” но в хорошем смысле :)
cd /
cd symbol-testnet-bootstrap/api-harvest-assembly
sudo ./reset-to-nemesis.sh
5. Запустить ноду
sudo docker-compose up -d
6. посмотреть какие контейнеры запустились:
sudo docker ps
должно показать 4 контейнера
CNAMES
apiharvestassembly_api-node_1
apiharvestassembly_rest-gateway_1
apiharvestassembly_db_1
apiharvestassembly_api-broker_1
БАГ В ВЕРСИИ 0.9.6.3 !
В ходе эксперимента, была выявлена проблема, с работой нод версии 0.9.6.3, связанная с неконтролируемым ростом логов Dockers.
ВНИМАНИЕ !
1. Данное решение является “обходным” и только для версии 0.9.6.3, для других версий его использовать нельзя !
2. Если вы использовали данное решение, и перешли на новую версию — удалите внесенные изменения, т.к. это решение по сути отключает логирование, что тоже плохо.
Описание:
Нода запускается хорошо, все работает.
Через 1–2–3 дня нода перестает возвращать нормальный статус (проверка через http://ваш_внешний_IP_адрес_ноды:3000/node/info).
В это же время, с высокой вероятностью, становится невозможно подключиться к консоли.Причины.
С высокой вероятностью проблема в том что 25 Гб дискового пространства — недостаточно для работы ноды, и в итоге система не может запустить необходимые сервисы, включая сеанс SSH. Предполагается что наиболее активно использует дисковое пространство сервис docker.
Решение :
1. Если у вас есть доступ к ноде:
1.1. Зайти на сервер
1.2. Остановить ноду
1.3. Остановить сервер
1.4. Расширить диск до минимум 30 Гб, желательно до 40 Гб (будьте внимательны с тарификацией и затратами)
1.5. Запустить сервер, зайти в консоль
1.6. Создать файл /etc/docker/daemon.json с содержимым
{
“log-driver”: “none”
}
1.7. Если вы не перезапускали сервер (п.п. 1.1–1.3) — перезапустите докер командой:
service docker restart
1.8. Запускаете ноду.2. Если у вас нет доступа к ноде через консоль:
2.1. Остановить принудительно сервер
2.2. Расширить диск до минимум 30 Гб, желательно до 40 Гб
(будьте внимательны с тарификацией и затратами)
2.3. Запустить сервер
2.4. Попробовать подключиться к консоли.
2.5. Если получилось — выполнить решение п.п. 1
2.6. Если подключиться по SSH так и не получается — остается только удалить эту ноду и создать новую….
Автор : DrCryptos
Кто желает помочь и поддержать эксперименты и изыскания автора:
BTC 37A5xjBtfXafeba9vaYPvnph49UuoJYXK5
ETH 0x6D21Df4CF5A94ED7a2007a133F12169Ebf3343A3
NEM NCPESMFGRZK7JPGN3WZTWCDCQIODDF4ITPDULFXZ
