Rundeck - cronから移行しやすいジョブスケジューラを使ってみよう

こんにちは。斎藤です。

最近、Dockerなどのコンテナ型仮想化技術、Chef, Ansible, Itamae などによるITインフラ構築・運用自動化技術の利用が進んでいます。一方で、何年も動いて「歴史」を積み重ねているシステムも数多くあります。そして、私を含めてそれらの運用に関わる事もあるでしょう。そんな「歴史」のあるシステムも、何とか運用を効率化したいと思う事があるかもしれません。

今日は、バッチジョブや複数サーバに対する運用を効率化するRundeckを取り上げます。「何ができるの?」「はじめかた」そして「利用時の留意点」の3点についてお話しします。

※OSはCentOS 6系、Rundeck はバージョン 2.4.0、Java VM は Oracle JDK 1.7.0_72 を利用しています。

何ができるの?

ジョブスケジューラ

cron。Linux系OSに標準搭載されているジョブスケジューラです。標準で使えるため、多くの方が実務で利用されているのではないでしょうか。そんな cron は手軽に利用できる一方、システム全体の規模が拡大すると、登録するジョブ数が増えたり、ジョブ同士の依存関係が出たり、そして複数のサーバにジョブを設定するようになり、管理が非常に面倒になります。

これらの問題を、Rundeck は解決してくれます。

rundeck_jobs.png

私が考える特徴として、以下の3つがあります。

  • ジョブの管理を一元化できる
    • 複数サーバに対する一括適用、対象のサーバを絞り込んでの適用、どちらも可能。
    • WebUI, CLI どちらからも操作可能。手順書を作る時はCLIの方が便利ですからその点もGood。
  • ジョブの構造化が可能
    • サーバAでジョブを実行後、サーバBのジョブ実行に移る、なんてのも容易に設定できる。
    • 大きな単位のジョブに、小さな単位のジョブを包含する事で管理性を向上できる。
  • 複雑過ぎない設定
    • 日付はcronベースの書式で記述できるので、ほぼそのまま移行可能。
    • 開始・完了・失敗通知はメールはもちろん、WebHook も設定できて自動化の幅が広がる。

Rundeck は、 cron での管理が苦しいシステムへの福音となるのではないでしょうか。

複数サーバに対するコマンドの一括実行

先ほど、ジョブを複数サーバに対して一括実行できる機能があることをご紹介しました。これを応用して、逐次複数サーバにコマンドを実行できる機能があります。

rundeck_commands.png

これ、地味に便利です。いちいちサーバにsshでログインせずとも、指定した複数のサーバに対し、ミドルウェアのバージョンを拾ったり、コマンドを適用する作業を行うことができます。また、結果もサーバ毎にまとめられるため、成功・失敗・標準出力の確認も容易に行えます。

はじめかた

Rundeck はドキュメントが充実しています。まずは Getting Started をご覧頂き、インストールしてみて下さい。RHEL, CentOS には yum リポジトリ、Debian, Ubuntu には Debinan Package(dpkg) が用意されていますから、こちらを利用されるとインストールが楽です。手元のMacで検証されたい方は、jarファイルをダウンロードして利用してみて下さい。

ジョブの作り方は Tutorials をご覧ください。

Rundeck で管理対象に入れるサーバには、Rundeck サーバから SSH 接続ができるようにしてください。なお、Rundeck はエージェントレスで動くため、エージェントのインストール作業は不要です。

利用時の留意点

サーバのドメイン設定

以下の設定を忘れると、ログイン後に意図しないページに転送されてしまいます。

yumまたはdpkg経由でインストールした時は /etc/rundeck/rundeck-config.properties/etc/rundeck/framework.properties が対象となります。

Java VM のメモリ・GC関連の設定

直接jarを利用して実行する場合、Javaコマンドで起動時にメモリの使用量を以下の通りにする必要があります。そうしませんと OutOfMemoryError が発生します。yumまたはdpkg経由でインストールした時は、既に設定が施されています。

  • -Xmx: 512MB以上
  • -XX:MaxPermSize: 256MB以上

また、一部環境でRundeck起動中にGCが多発してCPUリソースに高い負担をかける場合があります。その場合は、GCのモードを切り替えてみると緩和されることがあります。

  • -XX:+UseConcMarkSweepGC

なお、yumまたはdpkg経由でインストールした時は、/etc/rundeck/profile内にJava起動時のオプションを設定する箇所がありますので、あわせて確認してみて下さい。

ジョブ一覧からジョブの詳細を確認する

これは留意点というよりTipsなのですが、ジョブ一覧のジョブ名をマウスオーバーすると、ジョブ設定の詳細がポップアップで表示されます。都度設定ページに移らなくても確認できますので便利です。

sudo

ジョブ上で sudo 実行時にパスワードが必要な設定な場合、私の環境では cron 実行時はパスワードが渡されない結果となりました。このため、cron に登録したジョブはバッチ実行ユーザに対して、コマンドを規制した上で sudo 権限を渡すか、root権限が不要な状態で実行できるように施した方が良いかと思います。

なお、逐次実行のジョブについては、ドキュメントの SSH Plugins 節の説明の通りに設定を施すと、パスワード付きの sudo を実行することができます。

※もし cron 実行時もパスワードあり sudo が実行できる方法があったら知りたいです...

監視設定

万一、 Rundeck が停止すると、全てのスケジュールジョブが実行できなくなります。そのため、 Rundeck のプロセス、及び httpd の監視は最低限施しましょう。

バックアップ

ドキュメントの Backup and Recovery 節に、バックアップが必要なファイルが記載されています。欠かさずにバックアップを行いましょう。

また、Rundeckサーバを冗長化したい場合、待機系の Rundeck サーバにファイルを同期しておくと良いです。障害時に、待機系の Rundeck サーバのプロセスを起動するだけでよくなります。障害時に実行中のプロセスの強制停止は救えないかもしれませんが、全く実行できなくなる状況は阻止することができます。切替後、再実行可能な設計にしていれば、再実行も容易のはずです。

まとめ

ここまで、Rundeckについて「何ができるの?」「はじめかた」そして「利用時の留意点」についてお話しししました。 cron で今まで管理していたスケジュールジョブをそのまま移行しやすく、かつ cron で管理するには大変だった部分に対し、痒い所に手が届くツールなのを知っていただけたのではないでしょうか。

実は、これまでいくつかジョブスケジューラを試していました。選定から外れてしまったものは、いわゆるエンタープライズ用で機能こそ充実しているもののライセンスフィーがそれなりにしてしまったり、OSS であるものの習熟に時間がかかりそうなものでした。そんな中、現場で軌道に乗っていたのは Jenkins だったのですが、これはもともとCI用のミドルウェアのため、ジョブスケジューラとしては機能過剰でした。そこで、ある社外の方より、Rundeck を現場で採用しているという話を伺い、様々なジョブスケジューラの中から選定しました。現在、新規導入した案件の本番機で稼働していますが、順調に動いています。

手元の環境でさくっと立ち上げてみて、自分たちに馴染むものかどうか検証していただけたら幸いです。

それでは皆様、ごきげんよう。

おしらせ

当社 CTOの馬場の単著「Webエンジニアが知っておきたいインフラの基本」絶賛発売中です!当社の現場で実際に利用されているITインフラ構築・運用技術を体系的にまとめている書籍です。構築、運用で迷ったり、知りたいことがある方は、ぜひご覧頂けたら幸いです。レビュワーの斎藤からもイチオシであります!!!