Runbook Automation（RBA）は、PagerDuty の定型業務を自動化するツールとして登場し、今ではインシデント管理の運用高度化に欠かせない存在となりました。2024年は特に多くの反響があり、さまざまなサポートを行う機会がありました。
特に初期セットアップやジョブの実行に関する質問が多かったため、今後、それらの手順を設定ガイドとしてまとめていこうと思います。スムーズな導入の参考になれば幸いです。
まず、本記事では、Runbook Automation の導入を検討している方向けに、トライアルの申し込みからユーザーやグループの作成と権限付与までを解説します。
Runbook Automation とは
PagerDuty Runbook Automation （RBA）は、IT 運用タスクを自動化する強力なツールです。自動診断や復旧、サーバーのプロビジョニング、定期メンテナンスなど、様々な運用タスクを自動化することで、運用コストの削減、人的ミスの軽減、サービス品質の向上を実現します。
従来の手作業による運用では、時間と労力がかかり、ミスが発生しやすいという課題がありましたが、RBAを導入することで、これらの課題を解決し、安定したシステム運用が可能になります。
Runbook Automation の基本情報については、PagerDuty のブログ ルーティン業務を劇的に改善する「Runbook(ランブック)」とは？ にて触れておりますので、併せてご参照ください。
トライアル環境の利用開始
※すでにトライアル環境をお持ちの方はこちらのステップはスキップしてください。
Runbook Automation のトライアルを申し込むには 公式ウェブサイト からアクセスし、申し込みフォームには、氏名、メールアドレス、会社名などの情報を入力します。必須項目は赤色のアスタリスクでマークされていますので、必ず入力してください。
件名が "PagerDuty Runbook Automation trial activation" のメールが届くので、メール内のリンクからパスワードを設定し、ログインしてください。（ユーザーIDはAppAdmin）
メールには以下の内容が記載されています。
- パスワードは 数字・特殊文字を含む10文字以上 にする必要がある
- 最大 10人のフルユーザー が利用可能
- トライアルアカウントは30日間 利用可能
- Automated Diagnostics Project に含まれる 事前構築済みのジョブテンプレート の使用を推奨
- RBAのドキュメント（英語のみ）について
- サポートについて（英語のみ）
特に No.4 についてログイン後、サンプルの Project と ジョブテンプレート があらかじめ用意されていることが分かります。そのため、一からジョブを作成せずにすぐに試すことができます。
ユーザーの管理
それでは、管理コンソールに AppAdmin でログインして、初期設定を行っていきます。
まずRBAにおいて、ユーザーや権限周りはどのように管理するのか、その考え方について簡単にまとめます。
ユーザー管理の概要
- ユーザーのログインと権限付与の仕組みがある
- ログインの仕組みは、ビルトインの認証（Local User / Group）、LDAP、SSO など
- 権限付与は Access Control Policy (ACL) Policy にて設定
- ACL は YAML形式のポリシーファイルで定義
- その他、User Class や User Role という仕組みもある
参考情報
ユーザーの種類
- ローカルユーザー（Built-in Users）
- Manage Local User で管理
- Local Group を利用してグループ分けできる
- 外部認証
- LDAP/Active Directory連携やSSO（Okta, Azure Active Directoryなど）が利用可能
- ログイン後は User Class 内に登録される
- デフォルトでAppAdminがアサインされる（SaaSの場合）
- 外部認証経由で登録されたユーザーはローカルグループに追加できない
User Class
- 特定のライセンスをユーザーに割り振る目的で使用
- ACLの上位セットとして機能するが、詳細な権限設定はACLにて管理する
- オンプレ版では、
Full UserとJob Runnerクラスがある - SaaS 版では、
AppAdminとJob Runnerクラスがある
参考情報
User Role
- ACL 内で使用される属性であり、システム内で実行できるアクションやアクセスできるリソースを定義
- オンプレ版では、
opsadminとfulladminなどオンプレ特有のインフラ設定の変更（データベース設定、クラスタ管理など）に対しての権限をもつ - SaaS版は、
appadminが最も高い権限を持つロール - SaaS版でも、ACLの設定で
opsadminとfulladminが表示されるが、設定してもappadminの権限と同等となる（正直ちょっとわかりづらい）
参考情報
ACL (Access Control List) Policy
- RBA内の権限管理で利用する仕組み
- System Context Rule : プロジェクトに属さないすべてのアクセス（サーバー管理、グループメンバーシップ、複数のプロジェクトで使用する資格情報、プロジェクト自体へのアクセスなど）を管理
- Project Context Rule : プロジェクト内のアクセス（ノードやジョブへのアクセスなど）を管理
- User もしくは Group 単位で設定
参考情報
ユーザーの追加
AppAdmin 以外のユーザーを追加します。右上の歯車マークを開き、User Manager からアクセスできます。
Manage Local Users より [Add User] ボタンをクリックして、ユーザーを追加します。
username や Password などを入力します。必要に応じて Groups にチェックを入れて [Save] します。
ACL Policy の設定
次に、作成したユーザーにACL Policyを設定します。デフォルトで作成されている Local Group admin や user にユーザーを所属させることで、ログイン後ある一定の権限が付与された状態になりますが、もう少し細かいアクセス制御をした ACL Policy を作成したいと思います。
参考にしたのは以下の情報です。
ACLレシピについて
では、Group/Project Full Access を作成したいと思います。
ACL Policy を設定する前に、以下の2点を先に完了させておく必要があります。
Local Group の作成
サンプルコードを見ると、アクセスコントロールを grp-sandbox-full というグループに付与している箇所がいくつかあります。（例：group: grp-sandbox-full）そのため、コードをこのまま利用するのであれば、先に作っておく方がスムーズです。
Local Group は、歯車マーク→ User Manager → Manager Local Group にて新規作成できます。
後ほどアクセステストを行うユーザー takanogu を Selected に追加しておき、[Save] で保存します。
Project の作成
こちらもコード内に project: prj-sandbox と記載されている箇所がいくつかあるので事前に作成しておきます。左上の Projects から [+Create Project] で新規の Project を作成します。
Project Name を "prj-sandbox" とサンプルコードに合わせます。
Key Storage パスの確認
API Token や SSH 接続時の認証情報を安全に保管しておくために Key Storage を利用します。
ACL サンプルのコード内では、path: keys/project/prj-sandbox と表記されていますが、これは prj-sandbox Project 作成時に、専用の Key Storage が自動的に作成されるためです。
こちらは prj-sandbox に移動し、Project Settings から Key Storage をクリックします。
このように Key Storage のパスが確認できます。
事前準備はこれでOKです。
ACL Policy の作成
右上歯車マークから Access Control をクリックして、[＋Create ACL Policy] で新しく ACL Policy を作成します。
ACL Policy の Name を設定して、Rule を追加します。
ここで、ACL Policy GUI 記載の通り、[+ New Rule] で1つずつルールを追加することが可能ですが、KB に掲載されている サンプルコード をそのまま Editor にコピペします。
[Save] をクリックして、一覧画面にて追加されたことを確認します。
アクセス確認
実際に takanogu でログインしてみます。
Project を開いてみると、作成した Project のみが表示されます。
Project Settings も含め設定が可能なようです。
今回のケースでは、Group 単位で ACL Policy を設定しましたが、User 単位でも設定できますので、いくつかのパターンをお手元でも試していただければと思います。
また、admin Group における ACL Policy のサンプルコードも記載がありますので、こちらもご参照ください。
System Configurationの設定
最後に、System Configuration について簡単にご紹介します。ここでは、システム全体の動作に関する設定を行います。例えば、プラグインや SSO の設定、通知メールの設定、オンプレ (Self-hosted) 利用の場合は Runner 関連の設定などを管理できます。
Runbook Automation のKBを読むと、rundeck-config.properties などのファイルを編集して設定を有効にするような記載がありますが、SaaS版ではその構成ファイルを直接編集するのではなく、この System Configuration を編集をする必要があるので注意をしてください。
おわりに
Runbook Automation は、システム運用を自動化するための強力なツールです。トライアルを利用することで、その機能と効果を実際に体験できます。本記事が、Pagerduty Runbook Automation の導入を検討している方の参考になれば幸いです。