grzegorznowak.cardano_node

概要バージョン洞察

Cardanoノード役割

CardanoノードをUbuntuおよびDebianにsystemdサービスとしてインストールします。その後、Ansibleトルティーヤで包み、特定の操作を制御可能で、冪等性を持ち、全般的にシンプルにします。

指示があればCNCLIを追加して統合することができます。

対応ディストリビューション

他のディストリビューションの採用とサポートは、ユーザーからのフィードバックに大きく依存します。

使用ケースをイシュートラッカーに追加してください。私たちは進めながらそれらを整理します。

Ubuntu

20.04
18.04

Debian

bullseye

インストール

以下のいずれかを使用します：

ansible-galaxy install grzegorznowak.cardano_node
リポジトリを直接クローンします

例のプレイブック

インストールには2つの主要なモードがあります：

ソースからのコンパイル
IOHKの事前構築されたバイナリを使用

cardano_install_methodフラグで制御可能です。詳細は「設定」セクションを参照してください。

バイナリディストリビューションインストールは一般的にはほとんどのケースに適しているはずですが、究極のオタクビルドを解除したい場合はソースを使用してください。

この役割では、両方のアプローチを試みます。

GitHubからクローンした場合

- name: Cardanoノードを統合
  hosts: all
  vars:
    cncli_add: true  # CNCLIを含める
    cardano_wallets:  # 2つのウォレットを作成
      - savings
      - operations
  roles:
    - cardano-node-role

ansible-galaxyでインストールした場合

- name: Cardanoノードを統合
  hosts: all
  vars:
    cncli_add: true  # CNCLIを含める
    cardano_wallets:  # 2つのウォレットを作成
      - savings
      - operations
  roles:
    - grzegorznowak.cardano_node

設定と使用方法

デフォルトでは、cardanoユーザーおよびグループのためにCardanoがインストールされます。これは推奨される慣行です。他の設定はdefaults/main.ymlに見つけることができます。

詳細な使用例やコピーペースト可能なコマンドは、次回以降のスプリントで到着します。

NFTトークン

この役割を使用して、ネイティブのNFTトークンを冪等的にミントします。トークンがすでに存在し、望ましい数量である場合は、再度ミントを試みません。

この時点で、ミントされたトークンはミントに使用したアドレスに送信されます。

メインネットに必要な最小構成：

cardano_install_method: dist
active_network: main
cardano_wallets:
  - &wallet_default default
cardano_nfts:
  - slug: BurningGiraffe
    description: Burning Giraffe
    image: ""  # NFTのIPFSハッシュ
    name: Burning Giraffe
    id: 1
    # このNFTのポリシーメタデータを編集可能にするために予約するスロット数：
    open_period: 1000000  
    quantity: 10
    wallet: *wallet_default

ネイティブトークン

この役割を使用して、ネイティブトークン（NFTではない）を冪等的にミントします。トークンがすでに存在し、望ましい数量である場合は、再度ミントを試みません。

この時点で、ミントされたトークンはミントに使用したアドレスに送信されます。

メインネットに必要な最小構成：

cardano_install_method: dist
active_network: main
cardano_wallets:
  - &wallet_default default
cardano_assets:
  - name: MyAsset
    quantity: 1000000
    wallet: *wallet_default

支払いアドレス

ADAアドレスを管理することができます。

注：この役割は（まだ）ウォレットソフトウェアを統合していません。この役割は、CLIコマンドを使用して送受信するために必要なファイルを作成します。「ウォレット」とは、関連するファイルを保持するための名前付きパスを指します。

現在のアプローチは、存在しないウォレットのみを作成し、壊れている（プライベートキーが欠けている）ものを報告します。セキュリティ上の理由から、既存のウォレットを削除しようとはしません。これは、システムの指定された状態を定義して収束させるというansibleの哲学に反します。

# 役割で追跡したいウォレット名のリストを記入
cardano_wallets:
  - savings
  - operations

上記のサンプルに基づいて - すべてのデフォルト値を使用している場合、生成されたウォレットアドレスは以下にあります：

/home/cardano/wallets/savings/payment.addr
/home/cardano/wallets/operations/payment.addr

ウォレットのプライベートキーと共に

ノード同期状態の確認

Cardanoノードが完全に同期されるまでプレイブックの実行をブロックします。

- name: 完全に同期されるまで待機
  assert_cardano_synced:
    cardano_node_socket: "{{ cardano_node_socket }}"
    cardano_bin_path: "{{ cardano_bin_path }}"
    active_network: "{{ active_network }}"
    testnet_magic: "{{ network_magic }}"  # テストネットでのみ使用
  retries: 60
  delay: 240    # 完全同期のために最大4時間待機
  become: true
  become_user: "{{ cardano_user }}"
  register: sync_check_result
  until: sync_check_result.progress | int == 100

資金の確認

特定のアドレスが少なくとも指定された量のADAを持っていることを確認します。常にいくつかのADAを持っている必要があるサービスを監視したり、特定の操作が必要な量を持っているかどうかをブロックしたりするのに役立ちます。

- set_fact
      wallet_to_check: default
      lovelace_needed: 1000000000

- name: ウォレットの収集
  cardano_wallet:
    cardano_bin_path: "{{ cardano_bin_path }}"
    name: "{{ wallet_to_check }}"
    active_network: "{{ active_network }}"
    testnet_magic: "{{ network_magic }}"  # テストネットでのみ使用
  become: true
  become_user: "{{ cardano_user }}"
  register: wallet_results

- name: Lovelaceを持っていることを確認
  assert_address_funded:
    cardano_node_socket: "{{ cardano_node_socket }}"
    cardano_bin_path: "{{ cardano_bin_path }}"
    active_network: "{{ active_network }}"
    testnet_magic: "{{ network_magic }}"  # テストネットでのみ使用
    expected_lovelace: "{{ lovelace_needed }}"
    address: "{{ wallet_results['wallets_addresses'][wallet_to_check] }}"    
  retries: 60
  delay: 240    # 完全同期のために最大4時間待機
  become: true
  become_user: "{{ cardano_user }}"
  register: lovelace_result
  until: lovelace_result.lovelace | int > lovelace_needed

一般設定

# Cardanoユーザー
cardano_user: cardano
cardano_group: cardano
cardano_home_directory: "/home/{{ cardano_user }}"

# 選択可能なオプション：
# src - ソースからコンパイル
# dist - 公式バイナリを使用
cardano_install_method: dist

# バージョン変数
ghc_version: 8.10.4
cabal_version: 3.4.0.0

# ソースから構築する場合にのみ適用
cardano_node_version: 1.33.0

# distからインストールする場合にのみ適用
cardano_hydra_build: 9941151
# 常にshaを確認してください。さもなければ有害かもしれません
cardano_dist_sha_256: eb7fbc652f79bcb8f56699ed7fee174a4ed321307c7086838d44972136795543
cardano_dist_url: "https://hydra.iohk.io/build/{{ cardano_hydra_build }}/download/1"

# サービス設定
cardano_listen_addr: 127.0.0.1
cardano_listen_port: 22322  # 非特権ユーザーとして実行する場合は上位の範囲内である必要があります

# CNCLI設定
cncli_add: false  # cncli-syncサービスとともにcncliを有効にするには'true'に設定

もっと詳細があるので、すぐにdefaults/main.ymlファイルを直接確認して、すべての小さな詳細を見てください。

Cardano CLI

このリポジトリの一つの最終目標は、ansibleタスクを使用してCardanoの操作を抽象化することですが、サービスやバイナリに直接相互作用することを妨げるものではありません。

su cardano
cd ~/bin
./cardano-cli --help

使用の詳細については、cardano-cliのドキュメントを直接参照してください。

CNCLI

使用の詳細については、元のリポジトリをご覧ください。

サービスの管理

他のサービスと同様に使用します。

# cardano-nodeプロセスの管理：
systemctl status cardano-node
systemctl restart cardano-node

# 一般的なログの確認
journalctl -u cardano-node

CNCLI同期サービスと相互作用する場合、これを有効にします。

# cncli-syncプロセスの管理
systemctl status cncli-sync
systemctl restart cncli-sync

# 一般的なログの確認
journalctl -u cncli-sync

統合テスト

LXDでローカルに

LXDはすでにインストールおよび設定されている必要があります。

./test-local.shでフルスイートをトリガーします。

必要なバイナリのコンパイルはCPU集約型タスクであるため、長時間のプロセスを覚悟してください。

クラウド上のCIパイプライン

CIはDOインフラストラクチャの上に構築され、mainブランチでのすべての重要な変更セットに対してトリガーされます。

コストを抑えるために、ソースからはFocal Fossaに対してのみCIが行われています。

事前構築されたバイナリCIはfocalとbionicに対して行われます。

他のサポートされているプラットフォームはローカルで評価されています。

モチベーション

この役割はCardanoのバックエンドとサービスの設定を継続的に探索するもので、機能は時間とともに成長します。

高いTDDとコーディング基準に基づいて製作されており、変更が既存のコンポーネントを壊さないことを確認します。

Ansibleピザを注文するときは、常にテストを要求することを忘れないでください。

公式のDockerイメージの代わりにこの役割をいつ使用すべきですか？

まず第一に、Dockerはプロジェクトで具体的なタスクに対して一貫したイメージを提供するために多く活用する素晴らしいツールです。 Dockerの特異性には代償が伴い、ネットワーキングやsystemdに関しては楽しくありません。 単独では、完全には実行できず、そのためKubernetes、Docker Swarmなどが必要です。これは、メッシュVPNやライブサービスモニタリングなどの特注の設定を行う必要がある場合には問題を解決するために層を追加し続けることになり、最終的にはインフラストラクチャーをコードとしてデプロイするのが容易でない多くの依存関係を招くことになります。

開発において何かを学んだことがあるとすれば、すべてに共通するソリューションは実際には存在しないということです。生産グレードのプラットフォームが検討されている時点で、Dockerを正しく定義された制御環境に押し込もうとすることは、特定の価値を提供する役割のよく理解された最小限のセットをコンパイルするよりも、はるかに多くの作業になります。

もしあなたがDockerファーストアプローチでシステムを開発していないのであれば、私は個人的にそれが非常に回り道な方法だと考えますが、あなたはこの役割を楽しむかもしれません。加えて完全に透明ですから、 Dockerイメージにどんなものがプリパッケージされているかを心配することはありません。

初期のテストはLXDコンテナを使って行われました。これは軽量で高速で、Ubuntuにネイティブであり、Dockerが本当にできないレベルで実際のサーバーをシミュレートできます。