はじめに
前回の続きとしてウッキウキでGithubをつかったRundeckのバックアップ(リストア)を作ろうとしたら挫折したその話を書く。
もともと書きたかったのはあとがきだけなのにやることがどんどん増えていく。
挫折した話
まず綺麗な手順を作ろうとおもってまっさらなRundeckを立ててGit Importをしようとした。
以下の記事を応用してまっさらなRundeckを立てた。
SCM設定
前回設定したRundeckからプロジェクト・秘密鍵・対象プロジェクトを移設し「Setup SCM」から「Git Import」を設定する。
設定が必要な項目は「Git Export」より少なく2か所だけ
-
Git URLは作成したリポジトリを指定する。
-
SSH Key Storage Pathに先ほどkeystorageに設定したものを指定する。
「SCM Plugin Setup Complete」がでれば設定完了。
例のごとくJob画面になにか増えているので「Import Remote Changes」を選択する。
実際にimportしようとしたらこうなった。pluginが足りていなかった。私は挫折した。
というかここまでくるまでに別な場所でもいくつかハマっていて実用的じゃなかった。
じゃあどうするか
まず「Git Export」「Git Import」設定済みのRundeckを用意してJobを全部消してきれいにする。(しなくてもいい)
おもむろにAWS Consoleへ行き、対象Rundeckのイメージ作成を行う。
イメージ名は適当で構わない
イメージができたら該当のAMIから新しいインスタンスを起動する。
あたらしく立ったRundeckで改めて「Import Remote Changes」を実行する。
Githubが勝手に差分吸収して最新の状態にJobをimportしてくれる。とてもらく。
この形であれば秘密鍵やプラグインなど移行せずとも全て同じものを使ってくれるため最小限の工数でRundeckのバックアップ(リストア)ができる。
またこのケースだとAMIをから立ち上げるのに期間が空いてもGithubが差分吸収してくれるのでAMI側のバージョン管理が不要。
これならAMI運用でもつらくないのでは。(多少プラグイン追加でバージョン差分がでても)
デメリットとしてはActivityを保持してくれないところ。(でもActivityを監査に使うところなら外だししてるだろうし問題ないだろう)
あとがき
もともと前回の記事を書いているときにこのRundeckをAMIで無限増殖させられたら面白いのではと考えていた。
たとえばリポジトリは共通で本番用のRundeckから流すと本番用のJobとして動き、開発用なら開発用のJobとして動く構成とか、
Job作成用のDev-RundeckでJobを作り、Job実行権限のみのops-Rundeckで非エンジニアがセルフサービスで実行するとか,
(ops-rundeckはACLが厄介だが)
とても夢が広がった。
なお、今回気付いたがrundeck.orgの仕様が変わっており公式では最新版しかインストールできない？感じに変わっていた。
過去バージョンはpackeagecloudを使うようなので記事を更新しておく。