本記事の情報は古いバージョンの情報に基づいているため、申し訳ありませんが、Symbolのノード関連の情報をお探しの方は、本記事の内容は参照せず、別記事をお探しになることを強く推奨します。
先日以下の記事をQiitaに投稿させて頂きました。
GCP(Google Cloud Platform)でNEMの次期バージョンSymbolのテストネットのノードを構築する手順
私自身も、テストネットのノードをたてて維持しているのですが、さすが、現在まさに開発中のSymbolブロックチェーンのテストネットだけあって、新しいノード構築ツールがどんどんリリースされ、そのたびに何回かノードをたてなおす必要が生じました。
その中で新しいノード構築ツールでのノードのたてなおしの流れや、発生したトラブル等の記録をここに残しておこうと思います。
ノードの構築に困ったときにご参考になれば幸いです。間違い等もあるかもしれませんので、何かあればぜひご指摘頂けますと幸いです。
古いノード構築ツールで動いているノードを新しいノード構築ツールで立て直す手順
大まかな流れ
- 稼働中のノード(=古いノード構築ツールで動いているノード)を止める
- (dockerのキャッシュをクリアする)
- 古いノード構築ツールをフォルダごと消す
- 以降は通常のノード構築手順と同じ
各作業の詳細
1. 稼働中のノード(=古いノード構築ツールで動いているノード)を止める
まずは稼働中のノードを停止する必要があります。
- 現在自分がどのフォルダにいるか確認する(≒lsコマンドを実行し、docker-compose.yamlが表示されるか確認する)
- docker-compose.yamlがあるディレクトリでないと、2.のコマンドが実行できないと思うので、そのフォルダにいない場合は、cdコマンド等で対象のディレクトリへ移動しましょう。
- (docker-compose.yamlがあるディレクトリ上で、)以下コマンドを実行する
これで稼働中のノードを停止させることができたと思います。
sudo docker-compose down
2. (dockerのキャッシュをクリアする)
次にdockerのキャッシュが残っていると意図しない動作となる可能性があるため、キャッシュをクリアしておくと望ましい旨、記載されていましたが、フォルダ毎消す手順の方が望ましいようで、最新のGitHubの手順の説明ページからはこの内容は削除されていました。やらなくてもよいかもしれない？手順ですが、これをやることでトラブルになることはないと思うので、きれいにリセットしたい方はやってみても別に問題は無いと思います。
- 以下コマンドを実行する
sudo docker system prune -a - 確認を求められるので
yと入力しEnter
3. 古いノード構築ツールをフォルダごと消す
その場合は、消したいフォルダの一つ上のフォルダへ移動し、以下コマンドを実行してください。
ただし、このコマンドは、有無を言わさず該当フォルダを削除してしまうため、間違ったフォルダで実行してしまったり、間違ったフォルダ名を指定して実行してしまうと
バルス
のように全てを無に帰す破壊力を潜在的に持っています。実行する際は、正しいフォルダ上で、本当に消したいフォルダ名を指定していることを慎重に確認して実行するようご注意ください。
sudo rm -rf 消したいフォルダ名4. 以降は通常のノード構築手順と同じ
以降は通常のノード構築と同様の手順でOKです。
作業の中で発生したトラブル
friendly_nameとhostの反映のために設定ファイルに追記しノードを再起動した際にブロック高さの更新が止まってしまうことが何回か発生
この症状がよく発生しました。古いノードを新しいノードに入れ替える要領でノードを再起動すると直るときがあったり、直らないときがあったり色々でした。
色々試行錯誤する中で、そもそも私自身がノード同士の通信で使うポート7900を明示的に開ける処理をしていないことに気づきました。この設定を初回ノード起動前に実施することで、この症状については改善した印象があります。手順を記載した記事の方も7900ポートを明示的に先に開けておくような手順に修正しておきました。もし、ノード再起動でブロック高さの更新が止まってしまった人は、7900ポートが明示的に開けてあるかを確認し、開いていない場合は明示的に開けた後、全部最初からやり直してみると良いかもしれません。
2020/02/11追記
7900番を明示的に開けていても、ノード再起動時にブロック高さの更新が止まる現象が起こるという情報を伺いました。
再起動時、停止していた間に他のノードからの通信が失敗したり、host等の情報が変わって他ノードにて保有されている情報と不一致が発生する等の状況によって、ノードの信頼度のスコアが低下し、ブロックチェーンのネットワークに参加できない状態に一時的になってしまうのでしょうか。その場合、時間をおいてリトライする等の対策が必要かもしれませんが、このあたりはあまり検証できていません。
個人的にはhost, friendly_name等を初回ノード起動前に設定できると、楽でよさそうだな...と感じました。
フォークしていた？させてしまっていた？
もしかすると、7900番を明示的に開けずにノードをたてていたので、自分のネットワークの中(Googleが暗黙的に7900番での通信を許可している範囲のネットワークの中)だけ、他の全世界のネットワークと異なる全然違う世界だったのでは...という気もしています。(ごめんなさい、きちんと検証はできていません。)ノード運用のハードルは技術的にはかなり低いとはいえ、正確な理解に基づく正確なオペレーションが重要であると感じました。
まとめ
ノードの再構築については、dockerのキャッシュのクリアという手順が新たに追加されていましたが、その後この手順は公式ページからは削除され、フォルダ毎削除してやり直すという手順が推奨されているように見えました。
なお、トラブルの原因は、現時点では、私の設定もれ(ノード間通信で使う7900ポートの開け忘れ)という印象です。(2020/02/11追記:7900番を開けていても同様の問題が発生した事例はあるようで、他の理由もありそうです。)他にもいろいろあるのかもしれませんので、他にも何か気づいたことあれば、色々追記していこうと思います。
テストネットで色々な問題が明確となり、メインネットが円滑にローンチされ、Symbolブロックチェーンの活用を通じてより良いサービスが実現されることを祈っています。