コンテンツにスキップ
Blink Labs

スタートアップサービスの作成

Dingo

Section titled “Dingo”

Dingoは、Go言語で書かれたCardanoブロックチェーンデータノードであり、Ouroboros Network Node-to-Nodeミニプロトコルファミリーを使用して、Cardanoブロックチェーン上のネットワーク通信に積極的に参加します。

⚠️ これは開発中のプロジェクトであり、現在活発に開発が進められています


このガイドでは、systemdサービスの設定方法について説明します。systemdサービスを使用してDingoノードを実行すると、コンピューターが再起動したときにDingoノードを自動的に再起動することで、稼働時間を最大化できます。以下の手順に従って始めましょう。


✅ このガイドは一般的なLinux環境を前提としています。必要に応じてコマンドとパスを調整してください。

✅ このガイドは、クイックスタートガイドをすでに完了していることを前提としています。


ステップ1 - Dingoバイナリと設定の移動

Section titled “ステップ1 - Dingoバイナリと設定の移動”

Dingoバイナリを/usr/local/bin/に、設定を/etc/dingo/に移動して、システム全体からアクセスできるようにします。


バイナリをコピーします：

ターミナルウィンドウ
sudo cp ~/dingo/dingo /usr/local/bin/

✅ which dingoを実行して、バイナリがコピーされたことを確認できます


設定ディレクトリを作成し、設定をコピーします：

ターミナルウィンドウ
sudo mkdir -p /etc/dingo
sudo cp ~/dingo/dingo.yaml /etc/dingo/

ステップ2 - dingo.yamlのパスの更新

Section titled “ステップ2 - dingo.yamlのパスの更新”

サービスはあなたのユーザーとして実行されますが、設定は/etc/dingo/にあるため、データベースとソケットのパスが絶対パスを使用していることを確認する必要があります。以下を実行して、$HOMEを展開した状態で設定を再生成します：

ターミナルウィンドウ
sudo bash -c "cat <<EOF > /etc/dingo/dingo.yaml
# Database
databasePath: \"$HOME/dingo/.dingo\"


# Plugins
plugins:
  storage:
    blob:
      provider: \"badger\"
      config:
        blockCacheSize: 0
        compression: false
        dataDir: \"$HOME/dingo/.dingo/badger\"
        gc: true
        indexCacheSize: 0
    metadata:
      provider: \"sqlite\"
      config:
        dataDir: \"$HOME/dingo/.dingo/metadata.db\"
  mempool:
    provider: \"default\"
    config:
      # `capacity` はモードの既定値を上書きする任意の設定です。既定値は Praos モードと通常の serve モードで 1 MiB、Musashi モードで 25 MiB です。
      # 既定値を使うには、このキーをコメントアウトするか省略します。
      # capacity: 1048576
      # `revalidationDeltaCap` は FIFO 再検証中に追随する変更量の上限です。既定値は 64 で、正の値でなければなりません。
      # revalidationDeltaCap: 64
  api:
    blockfrost:
      provider: \"builtin\"
      config:
        port: 0
    mesh:
      provider: \"builtin\"
      config:
        port: 0
    utxorpc:
      provider: \"builtin\"
      config:
        port: 0


# Mithril
mithril:
  aggregatorUrl: \"\"
  cleanupAfterLoad: true
  enabled: true
  verifyCertificates: true
  # `true` はローカル開発・テスト専用で、HTTP とローカルまたはプライベートな宛先を許可します。
  allowInsecureHttp: false
  # `allowInsecureHttp` は `--mithril-allow-insecure-http` / `DINGO_MITHRIL_ALLOW_INSECURE_HTTP` で上書きできます。
  # `pinnedDigest` は任意です。v1 ではスナップショットのダイジェスト、v2 では Cardano データベースアーティファクトのハッシュを指定します。
  # この指定は新しいデータベースの初回ブートストラップにのみ使用します。
  # pinnedDigest: \"\"


> 📝 既定では、Mithril は HTTPS と公開宛先を要求し、ローカル、プライベート、その他の非公開宛先を拒否します。`allowInsecureHttp: true` はローカル開発またはテストでのみ使用する明示的な例外であり、本番環境では有効にしないでください。


# Network
# ヘルスチェックリスナー。`--health-port` / `DINGO_HEALTH_PORT` で変更できます。`0` を指定すると無効になります。
healthPort: 12799
# readiness の許容 tip gap（スロット数）。`--health-ready-gap-slots` / `DINGO_HEALTH_READY_GAP_SLOTS` で変更できます。
healthReadyGapSlots: 1000
bindAddr: \"0.0.0.0\"
metricsPort: 12798
debugPort: 0
network: \"preview\"
# NtC 接続の上限は合計 100、送信元 IP ごとに 5 です。`--max-ntc-conns` / `DINGO_MAX_NTC_CONNS` と `--max-ntc-connections-per-ip` / `DINGO_MAX_NTC_CONNECTIONS_PER_IP` でも設定できます。
# 値が 0 以下の場合は無視され、既定値が使用されます。
maxNtCConns: 100
maxNtCConnectionsPerIP: 5
privateBindAddr: \"127.0.0.1\"
privatePort: 3002
relayPort: 3001
socketPath: \"$HOME/dingo/dingo.socket\"


# Storage
barkBaseUrl: \"\"
barkPort: 0
# `barkPort` と `databaseLifecycle.snapshotDir` を併用する場合は、`barkClientCaFilePath` と `tlsCertFilePath` / `tlsKeyFilePath` の両方が必要です。
databaseLifecycle:
  # `snapshotEnabled` を有効にすると、エポック境界で自動スナップショットを作成します。
  # プライマリの blob provider が `badger`、`s3`、または `gcs` の場合は自動スナップショットを有効にできないため、`snapshotEnabled` を無効にしてください。
  snapshotEnabled: false
  # 自動スナップショットの保存先です。各スナップショットは個別のサブディレクトリに書き出されます。
  snapshotDir: \"$HOME/dingo/snapshots\"
  # ローカル保存に加えて、スナップショットをクラウドにもミラーします。`s3://bucket/prefix` または `gcs://bucket/prefix` を指定します。
  # `dingo_extra_plugins` ビルドタグが必要です。
  snapshotCloudDestination: \"\"
  # 複数ノードで同じクラウド保存先を共有する場合の追加パスです。
  snapshotCloudDestinationPrefix: \"\"
  # 古い自動スナップショットの保持数です。`0` はすべて保持します。
  snapshotRetention: 0
  # N epoch ごとに自動スナップショットを作成します。`1` は毎回です。
  snapshotEveryNEpochs: 1
storageMode: \"core\"
EOF"

📝 APIポートはAPIストレージモードでのみ有効です。0 を設定すると、そのAPIは無効になります。

📝 debugPort はプロファイリングが必要な場合を除き 0 のままにします。debugPort は独立した任意の pprof リスナーを制御し、通常は無効のままにします。

storageMode: "api"
plugins:
  api:
    blockfrost:
      provider: "builtin"
      config:
        port: 3000
    mesh:
      provider: "builtin"
      config:
        port: 8080
    utxorpc:
      provider: "builtin"
      config:
        port: 9090
midnight:
  # Midnight のインデックス作成と gRPC 提供は別々に制御します。gRPC 提供には API ストレージモード、`serverEnabled: true`、0 以外の `port` が必要です。
  # `serverEnabled` が `false` の場合はリスナーを起動しません。
  serverEnabled: false
  # `reflectionEnabled` は gRPC のサービス検出を個別に有効化する設定です。`serverEnabled: true` が必要です。
  reflectionEnabled: false
  # ループバック以外で TLS なしの接続を許可します。リモートの平文接続には `allowInsecureRemote: true` または TLS が必要です。
  allowInsecureRemote: false
  # gRPC の待ち受けポートです。`serverEnabled` が `true` の場合は 0 以外にします。
  port: 50051
  # gRPC の待ち受けアドレスです。省略または空欄の場合の既定値はループバック（`127.0.0.1`）です。
  host: "127.0.0.1"
  authTokenPolicyId: ""

これらのポートは、更新後のローカル Blockfrost エクスプローラーの例に合わせた値です。これらのサービスが必要な場合にのみ有効にできます。

📝 midnight.authTokenPolicyId は、API ストレージモードで Midnight インデックスを使用する場合にのみ適用されます。空のままにすると、認証トークン照合のより広い既定の動作が維持されます。

📝 プライマリの blob provider が badger、s3、または gcs の場合は自動スナップショットを有効にできませんが、手動の dingo database snapshot コマンドと Bark の CreateSnapshot は引き続き利用できます。停止中のデータディレクトリには dingo database snapshot|restore|truncate を使えます。barkPort と databaseLifecycle.snapshotDir を併用した実行中ノードでは、Bark の DatabaseService が Restore と Truncate をライブで実行します。これらの機能を使う場合は barkClientCaFilePath と tlsCertFilePath / tlsKeyFilePath の両方を設定してください。 📝 core ストレージモードでは、consumed_utxo_prune_floor より前の消費済み UTxO 行を保持処理がすでに削除しているため、その下限より古い truncate 対象を指定すると、Dingo は変更を加える前に要求を拒否します。下限と同じ対象は指定できます。API ストレージモードではこの判定を行わず、動作は変わりません。巻き戻しが古すぎる場合は、より浅い対象を選ぶか、完全に同期したピアのスナップショットから復旧してください。


ステップ3 - Mithrilからのブートストラップ（初回実行のみ）

Section titled “ステップ3 - Mithrilからのブートストラップ（初回実行のみ）”

サービスを初めて起動する前に、Mithrilスナップショットからデータベースをブートストラップします：

ターミナルウィンドウ
dingo mithril sync --config /etc/dingo/dingo.yaml

📝 mithril.downloadMaxTransientRetries は、TLS タイムアウト、HTTP 429 応答、HTTP 5xx 応答などの一時的なブートストラップダウンロード障害に対する再試行回数を制御します。例では既定値の 10 を使用しています。

これによりスナップショットがダウンロードおよびロードされ、数時間の同期時間を節約できます。詳細はクイックスタートガイドのステップ4を参照してください。

📝 これは一度だけ行う必要があります。初回ブートストラップ後は、systemdサービスがノードの同期を維持します。


ステップ4 - dingo.serviceユニットファイルの作成

Section titled “ステップ4 - dingo.serviceユニットファイルの作成”

systemdサービスファイルを作成します。YOUR_USERをあなたのユーザー名（echo $USER）に置き換えてください：

ターミナルウィンドウ
cat <<ENDFILE | sudo tee /etc/systemd/system/dingo.service > /dev/null
[Unit]
Description=Dingo Node
After=network-online.target


[Service]
Type=simple
Restart=on-failure
RestartSec=10
User=YOUR_USER
ExecStart=/usr/local/bin/dingo serve --config /etc/dingo/dingo.yaml
SyslogIdentifier=dingo
TimeoutStopSec=5


[Install]
WantedBy=multi-user.target
ENDFILE

ステップ5 - サービスの有効化と開始

Section titled “ステップ5 - サービスの有効化と開始”

起動時にサービスが実行されるように有効化し、すぐに開始します：

ターミナルウィンドウ
sudo systemctl daemon-reload
sudo systemctl enable dingo.service
sudo systemctl start dingo.service

ステップ6 - ステータスの確認

Section titled “ステップ6 - ステータスの確認”

ポート 12799 のヘルスエンドポイントを確認します：

ターミナルウィンドウ
curl -i http://127.0.0.1:12799/health
curl -i http://127.0.0.1:12799/healthz
curl -i http://127.0.0.1:12799/readyz

/health と /healthz は、イベントループの応答性を含む liveness（生存確認）を確認します。/readyz は、tip gap が不明でなく、healthReadyGapSlots を超えず、データベースも準備完了している場合に、readiness（準備完了確認）と判定します。ブロックプロデューサーでは、forger が実行中で、認証情報が使用可能であること（該当する場合はリモート KES の準備完了を含む）も必要です。Mithril のブートストラップ中もこれらのプローブを利用できます。

サービスが実行中であることを確認します：

ターミナルウィンドウ
sudo systemctl status dingo.service

ログをリアルタイムで追跡するには：

ターミナルウィンドウ
sudo journalctl -u dingo -f

エラーが発生した場合に最近のログを確認するには：

ターミナルウィンドウ
sudo journalctl -u dingo -n 50 --no-pager

おめでとうございます。Dingoのスタートアップサービスを設定しました！

Section titled “おめでとうございます。Dingoのスタートアップサービスを設定しました！”

Doc Holiday logo

Docs authored by Doc Holiday

ページを編集

最終更新日: