まだプログラマーですが何か?

プログラマーネタとアスリートネタ中心。たまに作成したウェブサービス関連の話も http://twitter.com/dotnsf

2019年01月

IBM Domino 10 の新機能の1つで、個人的にすごく楽しみにしていた domino-db パッケージを遅ればせながら使ってみました。

このパッケージについて簡単に説明します。IBM Domino サーバーのアプリケーションデータベースにアクセスする方法は何通りかありますが、一般的にはこれまで以下の3通りありました:

(1) 専用クライアント(IBM Notes)を使う
(2) サーバー側で HTTP タスクを有効にした上で、ブラウザなどの HTTP クライアントからアクセスする
(3) IBM Notes が導入されたシステムから C/C++ や Java、ActiveX でプログラミングを行ってアクセスする

(1) はごくごく一般的な、いわゆる「ノーツ」を使ってアクセスする方法で、(2) はブラウザを使ってアクセスします。この2つはプログラミングというよりは、普通に提供されている機能です。(3) はプログラミングによってアプリケーションやマクロを作成してアクセスする方法なのですが、そのための SDK やインターフェースは同システム内にノーツが導入されている前提で提供されているものでした。つまりプログラミングで IBM Domino サーバーにアクセスする場合、IBM Notes クライアントがインストールされていることが前提条件であり、IBM Notes がインストールされていない(またはインストールできない)環境からはプログラミングしてもネイティブコードが存在しないので実行できない、という制約があったのでした。


このたび IBM Domino 10.0 から提供された App Dev Pack という拡張機能によって、この制約がなくなりました。つまり、

(4) App Dev Pack で提供される domino-db パッケージを使ってプログラミングし、Node.js からアクセスする

という4つ目の選択肢が新たに与えられたことになります。なお App Dev Pack は IBM Domino 10.0.1 と同時に提供が開始されました。またこの段階では Linux 版の App Dev Pack のみが提供されています。詳しくは以下でも紹介しますが、2019/01/14 時点では Linux (CentOS7/RHEL7)版の IBM Domino 10.0.1 サーバーと、Linux 上の Node.js 環境で動作します(2019/01/18 修正 domino-db パッケージは Linux 以外でも動くようです。少なくとも Windows からは動きました)

この App Dev Pack を実際に使って試してみました。今回は以下のような2台の Linux システム間で実際に動かしています:
2019011302


【IBM Domino サーバー】
OS: CentOS 7
Domino: 10.0.1

【クライアント】
OS: Ubuntu 16.04
Notes: インストールせず
Node.js: 8.11

今回は同一ネットワーク上に上記2台の Linux マシンを構築していますが、実際にはクライアントから IBM Domino サーバーに(名前とポート番号指定だけで)アクセスすることが可能であれば、インターネット越しでも可能だと思っています。


【環境準備】
CentOS 7 上に IBM Domino 10.0.1 環境を構築します。こちらの手順はすぐ下に記載した部分以外は省略します(私がこちらを参照したわけではないのですが、詳しくはこちらに記載された方法で導入できるようです)。なお Linux 版の Domino 10.x は CentOS/RHEL 7 以上でないとインストールできません。

ただ上記リンク先に書かれていなくて、ちと注意が必要な点があるのでそこだけ追記しておきます。

後述の環境では(Proton の動作ポートが動的な設定のままでも動くように)インフラ部分のセキュリティレベルをかなり緩めに作りました。具体的には SELinux を無効にし、更にファイアウォール(firewalld)も止めている、という点をコメントしておきます。具体的なコマンドとしては IBM Domino インストール後に root でログインして以下を実行しました:
(firewalld を停止)
# systemctl stop firewalld

(firewalld の無効化)
# systemctl disable firewalld

(SELinux の設定ファイルを編集)
# vi /etc/selinux/config

(SELINUX=enforcing とあった行を以下のように更新して、保存)
SELINUX=disabled

(システム再起動)
# shutdown -r now

これでファイアウォールや実行ポート番号を意識せずに以下の記述内容が実行できる環境にしています。



そして上記の環境を使い、CentOS 7側には Proton というサーバータスクを、Ubuntu 側には domino-db パッケージをそれぞれ追加導入しています。つまりシステム的にはこんな感じで Proton と domino-db パッケージを経由して通信しています:
2019011303


以下、それぞれの追加モジュールについて紹介します。

まずクライアント側に domino-db という npm パッケージを用意します。このパッケージが IBM Domino とのアクセスを提供しており、Node.js を使ったプログラム内で IBM Domino のデータベースを読み書きすることができるようになります。なお 2019/01/14 時点で提供されている domino-db パッケージのバージョンは 1.1.0 であり、Linux 版のみが提供されているようでした。

またサーバー側にも Proton というアプリケーション(正確にはサーバータスク・アプリケーション)が必要です。この Proton が前述の domino-db を使ったアプリケーションからのリクエストやレスポンスに対応します。なお 2019/01/14 時点で提供されている Proton のバージョンは 0.2.2 であり、こちらも Linux 版のみが提供されているようでした。

これら2つのモジュールが互いに通信しあって Node.js プログラムからの IBM Domino へのリクエスト制御やデータベースの読み書きに対応します。


実際にこれらをインストールする手順を紹介します。まず Domino 10 のインストールモジュールをダウンロードした IBM サイトなどから IBM Domino AppDev Pack をダウンロードします。2019/01/15 時点でのバージョンは 1.0 で Linux English 版のみ、 DOMINO_APPDEV_PACK_1.0_LNX_EN.tgz というファイル名でした:
2019011502


このアーカイブファイルを展開すると、以下のようなファイル群が表れます。なお、今回以下で紹介するものの中で使っているのは青のファイルのみで、これらのファイルが /tmp 以下に展開されているものとします:
- LICENSE
- NOTICE
- domino-appdev-docs-site.tgz : ドキュメント
- domino-domino-db-1.1.0.tgz : domino-db パッケージ
- domino-iam-service-1.0.15.tgz : IAM 認証用モジュール
- domino-node-iam-client-1.0.22.tgz : IAM 認証用の Node.js クライアントモジュール
- node-demo.nsf : デモ用アプリケーション
- oauth-dsapi-0.2.2.tgz : OAuth 用モジュール
- proton-addin-0.2.2.tgz : Proton 一式

なお、以下で紹介する内容は domino-appdev-docs-site.tgz を展開したドキュメント内にかかれている内容をベースに独自にカスタマイズしたものです。以下ではこのファイルを参照することはありませんが、domino-db パッケージを使ってアプリケーション開発をする場合の API リファレンスなども含まれているので、こちらは必ず手元で参照できるようにしておきましょう:
2019011501


まずはサンプルで使うドミノデータベース node-demo.nsf をデータフォルダに移動させます。いったん IBM Domino サーバーをシャットダウンし、notes ユーザー(Linux 内で IBM Domino を実行するユーザー)でログインします。そして node-demo.nsf をデータフォルダ直下にコピーしておきます:
$ cd /local/notesdata

$ cp /tmp/node-demo.nsf .

$ chown notes.notes node-demo.nsf

なお、このデータベースに特別な設計が含まれているわけではありません。ただし、今回の設定では Anonymous ユーザーでこのデータベースにアクセスして文書を作成することになるので、Anonymous ユーザーで文書を読み書きができるような権限設定が必要です。他のデータベースを使う場合も同様です。

次に IBM Domino 10 サーバーに Proton を導入します。notes ユーザーで以下のコマンドを実行してファイルコピー&セットアップを行います:
Domino バイナリのあるフォルダに移動
$ cd /opt/ibm/domino/notes/latest/linux

libnotes.so が存在していることを確認
$ ls -la libnotes.so

Proton ファイルをこのフォルダ内に展開
$ sudo tar -xzvf /tmp/proton-addin-0.2.2.tgz

setup_proton.sh を使ってセットアップ
$ sudo sh -v ./setup_proton.sh

この時点で Proton を起動することは可能ですが、デフォルト状態のままだと同一システムからのリクエストのみ受け付けます。今回は外部の別マシンから Node.js アプリケーションを実行したいので、外部リクエストを受け付けるための設定を追加する必要があります。

そのため、データフォルダ(/local/notesdata/)以下の notes.ini ファイルをテキストエディタで開き、以下の1行を追加します:
PROTON_LISTEN_ADDRESS=0.0.0.0

PROTON_LISTEN_ADDRESS は Proton へのリクエストを受け付けるホストの IP アドレスです。デフォルトは 127.0.0.1 なので同一システムからのリクエストのみ受け付けます。上記の 0.0.0.0 は全ての外部ホストからのリクエストを受け付ける、という設定です。

ここで1つ注意を。実は Proton の実行ポート番号は動的に決まるのですが notes.ini に以下の一行を追加することで実行ポート番号を指定できることになっています(この例の場合は 6000 番ポート):
PROTON_LISTEN_PORT=6000

が、私が試した限りでは、この1行を追加すると Proton 自身が起動に失敗するようになってしまいました。原因はよくわからないのですが、先に進めるため、今回は上記の設定はしていません。つまり Proton は起動時に空きポートを探して動的なポートで起動されるようにしています。

ここまでの設定ができたら IBM Domino サーバーを起動し、更に起動後のサーバーコンソールに以下を実行して Proton サーバータスクを実行します:
> load proton

するとコマンドに続いて以下のような実行ログが表示されます:
> load proton

PROTON> Build 0.2.2
PROTON> Listening on 0.0.0.0:1217, INSECURE
PROTON> Note: Requested port was 0, Actual listen port is 1217
PROTON> Server initialized
PROTON> Server allows Anonymous access only.
  :

この場合の例では Proton は 1217 番ポートが空いていることを確認し、1217 番ポートでリクエストを待ち受けている状態になりました。この番号は後で使うので覚えておきましょう。

これで IBM Domino サーバー側の設定は終わりです。実際には通信に SSL を使ったり、IAM による認証や権限管理を行ったりする設定もできるようですが今回は試していません。興味ある方はドキュメントを参照して挑戦してみてください。


次にクライアント側である Ubuntu システムのセットアップに移ります。まず Ubuntu に Node.js を導入します。ドキュメントによると Node.js V8.x で動作確認を行っている模様なので、今回も Node.js V8 を導入することにします(V10.x でも動くらしい、とは書かれていました、念の為)。多くの環境で Node.js を導入するとデフォルトで V8.x になると思っていますが、6以下だったり10以上だったりする場合は nvm などを使って Node.js V8.x (と npm)が動く環境を用意してください。

そして AppDev Pack 内に含まれている domino-db パッケージを転送するなどして、Ubuntu 側にコピーしておきます(以下の紹介ではカレントフォルダ内に domino-domino-db-1.1.0.tgz が存在しているものとします)。これでアプリケーション開発の準備は完了です。

チュートリアルをベースに、以下のような Node.js プログラムコード(test01.js)を記述します:
//. test01.js

//. domino-db のロード
const { useServer } = require( '@domino/domino-db' );

//. Domino サーバー(192.168.1.100)と Proton の実行ポート(1217)を指定
const serverConfig = {
  hostName: '192.168.1.100',
  connection: {
    port:1217
  }
};

//. 対象とするデータベース
const databaseConfig = {
  filePath: 'node-demo.nsf'
};

//. データベースに新規に作成する文書の内容
const createOptions = {
  documents: [
    {
      Form: 'Contact',
      Firstname: 'Kei',
      LastName: 'Kimura',
      City: 'Funabashi',
      State: 'Chiba'
    }
  ]
};

//. domino-db を使って Proton に接続
useServer( serverConfig ).then( async server => {
  //. 接続に成功したら処理対象データベースを指定
  const database = await server.useDatabase( databaseConfig );

  //. 設定した内容で文書を作成
  const response = await database.bulkCreateDocuments( createOptions );

  //. 作成した文書の unid を取得
  const unids = response.documents.map( doc => doc['@unid'] );

  //. 作成した文書の unid をコンソールに表示して終了
  console.log( `Documents created: ${unids}` );
});

Node.js に慣れている人であればなんとな~く処理内容は理解できると思います。1点だけコメントすると、上記の青字部分で指定した内容でデータベース内に新規文書を作成します。上記例では documents は配列になっていますが、その要素は1つだけです(つまり1文書だけ作成します)。配列要素の中身は作成する文書の各フィールドとその値を指定します。つまり今回の例では以下のようなフィールドとその値を指定してノーツの文書を新規に作成することになります:
フィールド名フィールド値
FormContact
FirstNameKei
LastNameKimura
CityFunabashi
StateChiba


また documents は配列なので、ここに2つ以上のオブジェクトを指定することも可能です。その場合は2つの文書がバルクインサートで作成され、結果の unid も2つ得ることができます。 ただ今回は1文書のみ作成する前提で上記コードが記述されている点にご注意ください。

このコードを実行してみます。まず上記で作成した test01.js ファイルがあるフォルダで domino-db パッケージを npm install します。domino-db はまだ npmjs に登録されているわけではなく、あくまでインストールモジュールから導入する必要があります。したがって以下のようなコマンドでローカルファイルシステムの同一フォルダにある domino-domino-db-1.1.0.tgz を指定してインストールします:
$ npm install ./domino-domino-db-1.1.0.tgz --save

domino-db のインストールができれば test01.js を実行することができます。また実行結果には作成された文書の UNID が表示されます:
$ node test01

Documents created: 5F29E1B7FD62450649258383005083FE

実際に Domino 10 サーバー上の node-demo.nsf ファイルを開いてみると、All Names ビューから Name が Kei Kimura となった文書が追加されていることが確認できます:
2019011301


この文書を開いてみると、入力した通りの内容で文書が作成されていることが確認できます。本当に Notes/Domino の導入されていないシステムから domino-db パッケージを使ってデータベース内に文書を作成することができました:
2019011503


本当に domino-db パッケージ(と Node.js)だけでリモートの IBM Domino データベースに文書を作成することができちゃいました。今はサーバー側もクライアントも Linux 環境でないとできない(2019/01/18 修正 サーバー側が Linux 環境でないとできない)、という制約がありますが、いずれ他のシステムでもこの機能が提供される(勝手にそう思ってますが・・)と超便利だと思いました。

1点だけ、Proton の実行ポート番号を notes.ini で指定すると動かなくなる、という現象は自分だけなのでしょうか?この辺りはまだ情報があまりなく、うまい回避方法があるといちいち実行ポートをコンソールで確認する必要がなくなって便利なんだけどな・・・ 情報求む。


ラズベリーパイ(Raspbian OS)に NoSQL 型のデータベースである Apache CouchDB を導入する手順を紹介します:
2019011402


Apache CouchDB (以下、"CouchDB")はオープンソースで提供されている NoSQL データベースです。IBM Cloud の IBM Cloudant はこの CouchDB をベースに提供されているマネージド DBaaS です:
2019011401


なお、IBM Cloudant は分散データベース環境がはじめから提供されていますが、以下で紹介する例では CouchDB を1インスタンスで運用する前提での導入方法とさせていただきます。また導入する CouchDB のバージョンは 2019/01/14 時点での最新版である 2.3.0 を対象としています。

まずは準備作業としてリポジトリをアップデートしておきます:
$ sudo apt-get update -y

$ sudo apt-get dist-upgrade -y

続いて Erlang Solutions のリポジトリを追加し、再度アップデートします:
$ wget http://packages.erlang-solutions.com/debian/erlang_solutions.asc

$ sudo apt-key add erlang_solutions.asc

$ sudo apt-get update

追加したリポジトリを使って、ビルドに必要なライブラリ等を導入します:
$ sudo apt-get --no-install-recommends -y install build-essential pkg-config erlang libicu-dev libmozjs185-dev libcurl4-openssl-dev

またビルドしたバイナリを実行するユーザー(couchdb)と、そのホームディレクトリ(/home/couchdb/)をこの段階で作成しておきます:
$ sudo useradd -d /home/couchdb couchdb

$ sudo mkdir /home/couchdb

$ sudo chown couchdb:couchdb /home/couchdb

ではいよいよ CouchDB のビルドを行います。2.3.0 のソースコードをダウンロード&展開して、ビルドします:
$ cd

$ wget http://mirror.ibcp.fr/pub/apache/couchdb/source/2.3.0/apache-couchdb-2.3.0.tar.gz

$ tar -zxvf apache-couchdb-2.3.0.tar.gz

$ cd apache-couchdb-2.3.0/

$ ./configure

$ make release

ビルドが成功すると、完成したバイナリが ./rel/couchdb/ 以下に作成されています。このフォルダ以下を /home/couchdb/ 以下にコピーし、couchdb ユーザー向けに実行権限を変更します:
$ cd ./rel/couchdb/

$ sudo cp -Rp * /home/couchdb

$ sudo chown -R couchdb:couchdb /home/couchdb

これでビルドは完了です。不要であればソースコードやリポジトリのファイルは削除しても構いません(残しておいても構いません):
$ cd

$ rm -R apache-couchdb-2.3.0/

$ rm apache-couchdb-2.3.0.tar.gz

$ rm erlang_solutoins.asc

この段階で CouchDB を起動することは可能ですが、デフォルト設定のままだと CouchDB はローカルホストからのリクエストのみ受け付ける設定になっています。CouchDB を外部ホストから利用する場合や、管理者向けコンソールに外部ホストからアクセスする場合は外部アクセスを許可するよう、起動前に設定を変更しておく必要があります。

外部ホストからのアクセスを許可するには、/home/couchdb/etc/local.ini ファイルをテキストエディタで開き、
#bind_address = 127.0.0.1

となっている箇所を、以下のように書き換えて保存します:
bind_address = 0.0.0.0

そして couchdb ユーザーの権限で CouchDB を起動します:
$ sudo -i -u couchdb /home/couchdb/bin/couchdb

起動後、別のターミナルから以下の curl コマンドを実行して動作を確認します:
$ curl http://localhost:5984/

{"couchdb":"Welcome","version":"2.3.0","git_sha":"07ea0c7","uuid":"48b039b37b2b29236f33806d9a96c248","features":["pluggable-storage-engines","scheduler"],"vendor":{"name":"The Apache Software Foundation"}}


私自身はラズパイ3とラズパイゼロで動作を確認しましたが、ラズパイゼロでも CouchDB 程度であれば大した負荷にはならずに実行できました。




(参考)
https://www.hackster.io/mehealth-ch/installing-couchdb-on-raspbian-stretch-ccb2a7



ラズベリーパイをデスクトップ用途で使う場合のテキストエディタとしては現時点でこれが最適かなあ、と思うのが Visual Studio Code です。ラズベリーパイ環境にもインストールできるようになっていました。


導入にあたり、まずは GPG Key をインストールしておく必要があります:
$ wget -qO - https://packagecloud.io/headmelted/codebuilds/gpgkey | sudo apt-key add -

その後、root で Visual Studio Code の Community Build をインストールします:
$ sudo su
# . <( wget -O - https://code.headmelted.com/installers/apt.sh )
# exit

導入後はメニューから code-oss を選択するか、コマンドラインから以下を実行して起動します:
$ code-oss

2019-01-13-093932_1184x624_scrot
 

普段が vi 使いなので比較の対象としてアレですが、複数ファイルを開いて切り替える使いやすさとか、補完機能とか、いわゆる「モダンな」機能が満載で、それでいてそんなに重いわけでもなく、いい感じ。


ラズベリーパイネタシリーズです。

今回はオープンソースのブロックチェーン基盤である Hyperledger Fabric を一通り Raspbian OS に導入して実行する手順を紹介します。まあラズパイの 1GB 物理メモリでどこまで実用的に動くか、というのはあまり期待できないし、また現時点では Hyperledger Fabric はともかく、Hyperledger Composer を使った動作は 32bit OS である Raspbian OS ではどうやら難しいのかもしれない・・・と感じていることを最初に申し上げておきます。 なお以下で紹介する手順はこの環境で確認しています:

モデル: Raspberry Pi 3B+
OS: Raspbian 2018-11-13 (Stretch Full) ※最新版はこちら
SD カード: 128GB

※ページ最下の【参考】でも参照しているリンク先では Docker Swarm 環境で3台のラズパイを使った Hyperledger Fabric 環境構築を紹介しています。実用面ではこちらのほうが現実的かもしれません。



【導入手順】
基本方針として、このブログエントリ最下段の【参考】で記した2つのページの情報をあわせた方法で導入しています。

おおまかには以下の順序で Hyperledger Fabric 環境を構築します:
0. 事前準備
1. Docker 導入
2. Docker Compose 導入
3. Docker Image ダウンロード
4. 起動


今回は1台のラズパイの中に Docker 環境を構築し、その Docker の中で各種 Hyperledger Fabric のイメージを1インスタンスずつ動かして環境構築します。そのため上記のような順序でインストールする必要があります。


【0. 事前準備】
今回 Hyperledger Fabric を Docker 上で動かします。そのためラズパイに Docker 等を導入することになるのですが、そのための前提ライブラリ等を用意しておきます。ラズパイのターミナル等を開いて、以下のコマンドを順次実行します:
リポジトリ更新
$ sudo apt-get update && sudo apt-get upgrade -y

依存ライブラリを導入
$ sudo apt-get install git curl gcc libc6-dev libltdl3-dev python-setuptools -y

python pip インストーラーを更新
$ sudo -H pip install pip --upgrade

ここまでの操作が完了すると、ラズパイ用の Docker がインストールできるようになります。


【1. Docker 導入】

上記に続いて以下のコマンドを実行します:
Docker 導入
$ curl -sSL get.docker.com | sh

Docker の実行権限設定
$ sudo usermod -aG docker pi

ここまで完了したら一度ログアウトし、再度ログインします(最後の実行権限設定が有効になります)。ここまで正しく実行できていると、sudo なしで docker コマンドを実行することができるようになっているはずです:
Docker バージョン確認
$ docker -v
↑ Docker のバージョンが表示されれば、ここまでの手順は完了です。


【2. Docker Compose 導入】

引き続き Docker Compose を導入します。こちらは pip を使って導入し、導入後はすぐにコマンドを実行することが可能です:
Docker Compose 導入
$ sudo pip install docker-compose

Docker Compose バージョン確認
$ docker-compose -v
↑ Docker Compose のバージョンが表示されれば、ここまでの手順は完了です。


【3. Docker イメージダウンロード】

こちらのサイトで提供されている、ラズパイ用にビルド済みの Hyperledger Fabric (v1.0.7) の Docker イメージ群を docker pull コマンドでダウンロードします:
$ docker pull jmotacek/fabric-baseos:armv7l-0.3.2

$ docker pull jmotacek/fabric-basejvm:armv7l-0.3.2

$ docker pull jmotacek/fabric-baseimage:armv7l-0.3.2

$ docker pull jmotacek/fabric-ccenv:armv7l-1.0.7

$ docker pull jmotacek/fabric-javaenv:armv7l-1.0.7

$ docker pull jmotacek/fabric-peer:armv7l-1.0.7

$ docker pull jmotacek/fabric-orderer:armv7l-1.0.7

$ docker pull jmotacek/fabric-buildenv:armv7l-1.0.7

$ docker pull jmotacek/fabric-testenv:armv7l-1.0.7

$ docker pull jmotacek/fabric-zookeeper:armv7l-1.0.7

$ docker pull jmotacek/fabric-kafka:armv7l-1.0.7

$ docker pull jmotacek/fabric-couchdb:armv7l-1.0.7

$ docker pull jmotacek/fabric-tools:armv7l-1.0.7

自分でビルドする方法もあるようなのですが、あまりに面倒そうなので出来合いのものを使わせていただきました。 jmotacek 様、ありがとうございます。


これで Hyperledger Fabric 環境を動かすために必要な準備が完了しました。


【4. 起動】
Hyperledger Fabric の準備が整ったので起動します。ラズパイ1台で(物理メモリ 1GB で)この環境を起動するのは、できるか/できないかで言えばできそうですが、実用には厳しいかもしれません。環境に応じてスワップメモリを増やしておきましょう。方法はこちらを参照ください(私自身はスワップを 2GB に設定して以下を実行しました)。

Hyperledger Fabric の起動スクリプトの元となるキット(通称「サポートツール」)をダウンロード&展開します。以下の例ではホームディレクトリ以下に fabric/ というフォルダを作り、その中に展開しています:
$ mkdir ~/fabric

$ cd ~/fabric

$ curl -O https://raw.githubusercontent.com/hyperledger/composer-tools/master/packages/fabric-dev-servers/fabric-dev-servers.zip

$ unzip fabric-dev-servers.zip

この中の docker-compose.yml ファイルを上記で用意したラズパイ向け Docker イメージ用に書き換えます。具体的には ~/fabric/fabric-scripts/hlfv12/composer/docker-compose.yml を以下のように編集しました(変更部分をにしています):
version: '2'

services:
#  ca.org1.example.com:
#    image: jmotacek/fabric-ca:armv7l-1.0.7
#    environment:
#      - FABRIC_CA_HOME=/etc/hyperledger/fabric-ca-server
#      - FABRIC_CA_SERVER_CA_NAME=ca.org1.example.com
#
#    ports:
#      - "7054:7054"
#    command: sh -c 'fabric-ca-server start --ca.certfile /etc/hyperledger/fabric-ca-server-config/ca.org1.example.com-cert.pem --ca.keyfile /etc/hyperledger/fabric-ca-server-config/19ab65abbb04807dad12e4c0a9aaa6649e70868e3abd0217a322d89e47e1a6ae_sk -b admin:adminpw -d'
#    volumes:
#      - ./crypto-config/peerOrganizations/org1.example.com/ca/:/etc/hyperledger/fabric-ca-server-config
#    container_name: ca.org1.example.com
#
  orderer.example.com:
    container_name: orderer.example.com
    image: jmotacek/fabric-orderer:armv7l-1.0.7
    environment:
      - ORDERER_GENERAL_LOGLEVEL=debug
      - ORDERER_GENERAL_LISTENADDRESS=0.0.0.0
      - ORDERER_GENERAL_GENESISMETHOD=file
      - ORDERER_GENERAL_GENESISFILE=/etc/hyperledger/configtx/composer-genesis.block
      - ORDERER_GENERAL_LOCALMSPID=OrdererMSP
      - ORDERER_GENERAL_LOCALMSPDIR=/etc/hyperledger/msp/orderer/msp
    working_dir: /opt/gopath/src/github.com/hyperledger/fabric
    command: orderer
    ports:
      - 7050:7050
    volumes:
        - ./:/etc/hyperledger/configtx
        - ./crypto-config/ordererOrganizations/example.com/orderers/orderer.example.com/msp:/etc/hyperledger/msp/orderer/msp

  peer0.org1.example.com:
    container_name: peer0.org1.example.com
    image: jmotacek/fabric-peer:armv7l-1.0.7
    environment:
      - CORE_LOGGING_LEVEL=debug
      - CORE_CHAINCODE_LOGGING_LEVEL=DEBUG
      - CORE_VM_ENDPOINT=unix:///host/var/run/docker.sock
      - CORE_PEER_ID=peer0.org1.example.com
      - CORE_PEER_ADDRESS=peer0.org1.example.com:7051
      - CORE_VM_DOCKER_HOSTCONFIG_NETWORKMODE=composer_default
      - CORE_PEER_LOCALMSPID=Org1MSP
      - CORE_PEER_MSPCONFIGPATH=/etc/hyperledger/peer/msp
      - CORE_LEDGER_STATE_STATEDATABASE=CouchDB
      - CORE_LEDGER_STATE_COUCHDBCONFIG_COUCHDBADDRESS=couchdb:5984
    working_dir: /opt/gopath/src/github.com/hyperledger/fabric
    command: peer node start
    ports:
      - 7051:7051
      - 7053:7053
    volumes:
        - /var/run/:/host/var/run/
        - ./:/etc/hyperledger/configtx
        - ./crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp:/etc/hyperledger/peer/msp
        - ./crypto-config/peerOrganizations/org1.example.com/users:/etc/hyperledger/msp/users
    depends_on:
      - orderer.example.com
      - couchdb

  couchdb:
    container_name: couchdb
    image: jmotacek/fabric-couchdb:armv7l-1.0.7
    ports:
      - 5984:5984
    environment:
      DB_URL: http://localhost:5984/member_db

そして起動コマンドを実行します:
$ cd ~/fabric

$ ./startFabric.sh

↓こんな感じで Docker 内でイメージがコンテナ化され、実行されていきます:
2019011003


少し時間がかかりますが(1分くらい?)コマンドが完了すると、こんな画面になってプロンプトが戻ります:
2019011004


以下のコマンドで起動中のコンテナの状態を確認し、Hyperledger Fabric の各種コンテナが実行されていることを確認します:
$ docker ps

↓docker-compose.yml で指定されたイメージが起動していることが確認できます。Hyperledger Fabric の起動に成功しました!:
2019011002


ちなみに、この「Hyperledger Fabric が起動しただけ」の段階で使用メモリを確認してみました。起動しただけであれば意外と余裕あるようにも見えますね・・・
2019011006



【(途中まで)使ってみる】
Hyperledger Fabric の導入と起動までであれば上記までで完了していますが、せっかくなのでこの環境を使ってみることにします(といっても、以下で紹介しているのはカードファイルのインポートまでですが・・)。

具体的には「サポートツールで提供されているスクリプトを使って管理者用のカードファイルを作成する」ところまでを紹介します。といってもここから先はラズパイ特有の部分はなく、通常の方法と一緒というか、通常と同じ方法でできる所までを紹介する、というスタンスです。

そのために composer コマンドと呼ばれる、Hyperledger Composer のコマンドラインツールを導入するのですが、その前提として Node.js v8.x 環境(node と npm)が必要になります。ここがちとややこしいのですが、今回の導入に使った Raspbian OS 2018-11-13 (Stretch Full) でははじめから V8 の node コマンドは使えるようになっていますが、npm が導入されていません。というわけで今後のことも考えて node のバージョン管理ツール(n package)と合わせて Node.js v8.x を導入しておくことにします:
一旦 npm を導入
$ sudo apt-get install npm

キャッシュを更新
$ sudo npm cache clean

n package をインストール
$ sudo npm install n -g

n package で導入できる Node.js のバージョン(8.xx.xx の最新バージョン)を確認
$ sudo n list

(8.xx.xx の中では 8.15.0 が最新であったと仮定)
Node.js V8.15.0 を指定してインストール $ sudo n 8.15.0

一度ログアウト&ログインし直して、改めて node コマンドと npm コマンドのバージョンを確認します:
$ node -v
v8.15.0

$ npm -v
6.4.1
↑ Node.js V8.x と対応する npm が導入できたことを確認


Node.js 環境が整ったので、改めて composer コマンドをインストールします。今回用意した Hyperledger Fabric のバージョンが v1.0.7 のイメージなので、このバージョンに合う composer-cli v0.16 を指定してインストールします(※):
$ sudo npm install --unsafe-perm -g composer-cli@0.16

※ラズパイ環境だからかもしれませんが、上記の --unsafe-perm オプションを付けないと実行結果がエラーになってしまうようでした。こちらを参照。


そしてサポートツール内の createPeerAdminCard.sh を実行して、PeerAdmin@hlfv1 のカードを作成します:
$ cd ~/fabric/fabric-scripts/hlfv1

$ ./createPeerAdminCard.sh

composer のコマンドで、PeerAdmin@hlfv1 カードが作成されていることを確認します:
$ composer card list
2019011101


とりあえず動作確認できたのはここまでです。2019/01/11 時点でこの先に進もうとして BNA ファイルを用意して composer runtime install し(ここまでは成功)、composer network start させようとすると、以下のようなエラーになりました:
Error: Error trying to instantiate composer runtime. Error: No valid responses from any peers.
Response from attempted peer comms was an error: Error: Error starting container: API error (400): {"message":"Minimum memory limit allowed is 4MB"}
2019011102


このエラーの原因がまだわかっていないのですが、調べた範囲ではもしかすると 32bit OS である Raspbian OS に原因があるような気もしていて、そうだとすると現時点で Hyperledger Composer のこの先を動かすのは厳しいのかなあ・・・ とも思っています。

この辺りは引き続き調査もしますが、情報求む(苦笑)。


【Hyperledger Fabric を終了する】
起動した Hyperledger Fabric を終了するには startFabric.sh と同じフォルダにある stopFabric.sh を実行します:
$ ./stopFabric.sh

↓終了できました:
2019011005



実メモリ 1GB の制約はどうにもならないので実用的な使い方は難しいかもしれませんが、とりあえず1台のラズパイで Hyperledger Fabric が起動できることは確認できました。CouchDB などを使わずに、既存のビジネスネットワークに Peer だけ動かして接続するような使い方であればもう少し余裕を持って使えるかもしれません。


秋葉原の最安値で済ませることができれば、
 本体 5000 円 + ケース 1000 円 + Micro SDカード 2000 円
8000 円程度で Hyperledger Fabric のブロックチェーン環境が一台確保できる、ということになりますね。安っ!


【参考】
https://stackoverflow.com/questions/45800167/hyperledger-fabric-on-raspberry-pi-3
https://www.joemotacek.com/hyperledger-fabric-v1-0-on-a-raspberry-pi-docker-swarm-part-2/

久しぶりのラズベリーパイネタです。

これまであまり意識することなかったんですが、ラズパイ(Raspbian) をデフォルトのまま使っている時のスワップサイズって 100MB しかないんですね。。
2019011001


ラズパイのメインメモリは 1GB 固定です。サーバー用途メインで、あまり重い作業をしなければこれで足りるのかもしれませんが、デスクトップ用途で使ってブラウザでタブをたくさん開いて・・・という使い方をしていると、結構な確率でメモリ不足になると思います。 というわけで、スワップファイル容量を変更する手順を調べたので以下に紹介します。

Raspbian の場合、スワップファイル容量は /etc/dphys-swapfile というテキストファイルで管理されています。スワップファイル容量を変更するにはこのファイルをテキストエディタで開いて、CONF_SWAPSIZE という変数の値を(メガバイト単位で)指定します。例えば以下の例では 2GB に指定しています:
CONF_SWAPFILE=2048

ただし、2GB 以上の値を指定する場合は同ファイル内にある CONF_MAXSWAP の値も変更する必要があります(32 bit カーネルを考慮しているせいか、この値を変更せずに CONF_SWAPFILE の値だけを 2048 より大きな値に変更してもスワップファイルサイズは 2048 に設定されてしまうようです)。例えば 4GB に設定する場合は以下のようにします:
CONF_SWAPFILE=4096
CONF_MAXSWAP=4096

設定変更後に以下のコマンドで dphys-swapfile を再起動すると、スワップファイルのサイズが変更されます:
$ sudo systemctl stop dphys-swapfile
$ sudo systemctl start dphys-swapfile

2019011002


当たり前ですがスワップファイルはマイクロ SD カード内に作られるため、マイクロ SD カードの容量とも相談して設定する必要があります。またあまり頻繁にスワップが発生するような使い方だと、ただでさえストレージとしては比較的寿命の短いマイクロ SD カードの劣化を意識する必要が出てくるかもしれません。

その場合はラズパイに USB メモリを挿してマウントし、上記の /etc/dphys-swapfile ファイル内の CONF_SWAPFILE でスワップファイルを USB メモリ内に作成するようにしてマイクロ SD カードから退避させる、という方法もあるようです(未確認)。


このページのトップヘ