概要

RundeckのHA構成を組むべく、Rundeckのデータストレージをローカルから外部のRDBに設定するメモとなります。
公式ドキュメントが今ひとつわかりづらいので基本的な部分からまとめてみました。

環境情報

Rundeck: v2.8.2
OS: Amazon Linux 2017.03

デフォルトRDB

Rundeckはデフォルトでは組み込みのH2 Databaseを使用しています。（v1.5以前はHSQLDB）
設定は/etc/rundeck/rundeck-config.propertiesで確認することができます。

/etc/rundeck/rundeck-config.properties

dataSource.url = jdbc:h2:file:/var/lib/rundeck/data/rundeckdb;MVCC=true

RDBの接続先を変更するためには、設定を追加します。（下記はPostgresに設定する例）
http://rundeck.org/docs/administration/setting-up-an-rdb-datasource.html

/etc/rundeck/rundeck-config.properties

dataSource.driverClassName = org.postgresql.Driver
dataSource.url = jdbc:postgresql://${dbserver}/${dbname}
dataSource.username=${dbuser}
dataSource.password=${dbpassword}

この設定でH2 Databaseの情報はPostgreSQLで管理されるようになりました。
しかしながらRundeckにはそもそもRDBで管理されない（ローカルのファイルシステムに保存さる）情報が存在するため、これだけでは不十分です。

RDB管理されない情報

http://rundeck.org/docs/administration/storage-facility.html
Rundeckにはキー情報とプロジェクト情報を格納する2つのストレージ機構があり、
デフォルトでこれらのストレージにはローカルのファイルシステムが利用されます。
※H2 Databaseではありません。

キーストレージ

http://rundeck.org/docs/administration/key-storage.html
キーストレージは、Rundeckがリモートノードに接続するための、公開鍵、秘密鍵、パスワード情報などをセキュアに格納するためのストレージとなります。
格納先の物理パスは${framework.var.dir}/storage（デフォルトでは/var/lib/rundeck/var/storage）配下となり、メタ情報はmeta/key配下、コンテンツ情報はcontent/key配下に格納されます。

$ ls -ltr /var/lib/rundeck/var/storage/
合計 8
drwxrwxr-x 3 rundeck rundeck 4096  6月  4 14:30 meta
drwxrwxr-x 3 rundeck rundeck 4096  6月  4 14:30 content

プロジェクトストレージ

プロジェクトストレージは、Rundeckのプロジェクト情報を格納するためのストレージとなります。
格納先の物理パスは${framework.projects.dir}（デフォルトでは/var/rundeck/projects）配下となり、プロジェクト単位にディレクトリが作成されます。

$ ls -ltr /var/rundeck/projects/
合計 8
drwxrwxr-x 4 rundeck rundeck 4096  6月  4 13:45 ProjectSample01
drwxrwxr-x 4 rundeck rundeck 4096  6月  4 13:45 ProjectSample02

各プロジェクトフォルダの中のetcディレクトリ内を見ると、プロジェクトの基本情報やリソースモデルファイルが格納されていることがわかります。

$ ls -ltr /var/rundeck/projects/ProjectSample01/etc/
合計 8
-rw-rw-r-- 1 rundeck rundeck 269  6月  4 13:49 resources.xml
-rw-rw-r-- 1 rundeck rundeck 771  6月  4 13:50 project.properties

RDB管理されない情報をRDB管理する

RundeckのChange Logを遡るに、キー情報はv2.1.0から、プロジェクト情報はv2.5.0からRDB管理ができるようになっています。
※厳密に言うとキー情報に関してはストレージ機能自体がv2.1.0から新規追加されています。

これらの情報をRDBに格納するためには、storage-pluginsの設定が必要となります。
http://rundeck.org/docs/plugins-user-guide/configuring.html#storage-plugins
上記を参考にrundeck-config.propertiesを編集します。

キーストレージ

rundeck.storage.providerプレフィクスを利用します。
デフォルトではfileproviderが利用されています。

/etc/rundeck/rundeck-config.properties

# Enable DB for Key Storage
rundeck.storage.provider.1.type=db
rundeck.storage.provider.1.path=keys

プロジェクトストレージ

rundeck.config.storage.providerプレフィクスを利用します。
デフォルトではdbproviderが利用されているため、明示的に指定する必要はありません。¹

/etc/rundeck/rundeck-config.properties

# Enable DB for Project Storage
rundeck.config.storage.provider.1.type=db
rundeck.config.storage.provider.1.path=projects

さらにファイルストレージの場合、下記のプロパティでストレージタイプをdbに指定する必要があります。（デフォルトではfilesystem）
http://rundeck.org/docs/administration/project-setup.html#project-definitions

/etc/rundeck/rundeck-config.properties

# Enable DB for Project Storage
rundeck.projectsStorageType=db

暗号化

キー情報とストア情報は、Storage Converter Pluginの1つであるJasypt Encryption Pluginを利用してストレージ保存時にデータの暗号化を行うことができます。今回は割愛します。

設定値まとめ

以上の設定値をまとめると下記となります。

# RDB Settings
dataSource.driverClassName = org.postgresql.Driver
dataSource.url = jdbc:postgresql://${dbserver}/${dbname}
dataSource.username=${dbuser}
dataSource.password=${dbpassword}

# Enable DB for Project Storage
rundeck.projectsStorageType=db
rundeck.config.storage.provider.1.type=db       // 省略可能
rundeck.config.storage.provider.1.path=projects // 省略可能

# Enable DB for Key Storage
rundeck.storage.provider.1.type=db
rundeck.storage.provider.1.path=keys

設定が完了したらRundeckを再起動しましょう。
Rundeckにより既存のH2 Databaseの情報を元に新規DBのマイグレーションが行われます。
プロジェクトストレージが既にローカルのファイルシステムを利用している場合は、プロジェクト情報もDBに自動的に反映されます。
※キーストレージの情報は反映されません。

RDBの構造

外部RDBへの移管が完了した状態でデーブルを覗いてみると新規に20テーブルが作成されていることがわかります。
キーストレージとプロジェクトストレージの情報はstorageテーブルに格納されます。

所感

うーむ。率直に言って直感的ではないなぁと言う印象ですね。

キー情報とプロジェクト情報についてはそれぞれ設定が必要
さらにキー情報とプロジェクト情報でキープレフィクスが統一されていない
さらにさらにプロジェクト情報は追加でrundeck.projectsStorageTypeの指定が必要

という具合に初めてドキュメントを見た時は非常に困惑しました。
Change Logを見ると「あ、後からこの機能が追加されたから、仕方なくこうなったんだな」という具合に理解できることがあると思います。理解はできても納得かは別ですが・・・。
まぁイケてないと思う部分があればプルリク送れって話ですよね。
どこかでちゃんとソースを読んでみようと思います。

明示的に指定する場合と指定しない場合で、微妙に保存時のロジックが異なるように見受けられる（storageテーブルのnamespaceカラムの値が異なる）が後ほどソースを追ってみたいと思う。公式ドキュメントに従って、明示的に指定しないほうが無難かと思われる。 ↩