新リリース。ノードを停止してください。バイナリを置き換えます。次に、ダウンロードしたものが本当に正しかったのかを確認します。これは、ダスクの運用担当者が注意深く管理する必要があるメンテナンス手順だと私が想定していたものです。しかし、最新のノード・インストーラのフローでは、聞こえる以上に重要な1点が変更されました。バージョン0.5.22では、置き換え用のアーティファクトを、ライブファイルが置き換わる前にステージングし、検証するように強化されています。ダスクのアップグレード手順も同じ順序です。インストーラがサポートされたRuskおよびウォレットのバイナリをダウンロードして確認し、その後で初めて、動作中のRuskサービスを停止します。また、アップグレードを新規のノードインストールのように扱うのではなく、オペレーターのチェーン状態、コンセンサスキー、意図したサービス上書きを保持します。サービスはその後も停止したままなので、オペレーターは再生成された設定を確認し、Ruskを意図して起動し、ピアおよびブロック高の進行状況を確実にしてから、ジョブが完了したと呼び出せます。
これは小さな、しかし役に立つ運用上の節目です。
アップグレードのウィンドウは、置き換えが準備できた後に開始されます。オペレーターがそれを使えるかどうか調べている最中ではありません。
常に利用可能であることが求められるインフラにとって、その順序は、別の便利なコマンドよりも価値があります。
@Dusk $DUSK #dusk