インストールとセットアップ
自動化サービスと、そのコマンドを実行するマシンは同じシステムである必要はありません。導入方法の選択は、初期設定とプライベート環境へのアクセスの両方に影響します。
Rundeckは、Javaランタイムと、ネイティブパッケージ、実行可能なWAR、Dockerを使い、Kubernetesなしの一般的なサーバーで動作します。初期設定用にH2が同梱されています。H2は本番環境ではサポートされないため、本番では対応する外部データベースを設定します。商用のRunbook Automationはマネージドサービスとしても利用できます。
Semaphore UIは、スタンドアロンバイナリ、ネイティブパッケージ、Docker、Kubernetesによる導入に対応します。運用チームはJVMを追加せず、既存ホストにサービスを配置して自動化リポジトリを接続できます。少数の定期手順を共有する画面が欲しい場合にも、大きなチームで自動化をセルフホストしたい場合にも有効です。どちらもサーバーをWindowsで実行でき、RundeckではJavaが必要です。Ansibleの実行にはLinux、WSL、Linuxランナーやコンテナなど、対応する制御環境が必要です。WindowsネイティブのWebサーバーがあることは、WindowsがAnsibleのネイティブな制御ノードになることを意味しません。
自動化ツール
チームは構成管理、プロビジョニング、小規模な保守プログラムを組み合わせることがよくあります。どちらもこれらのツールを実行できますが、必要なジョブ設定の量が異なります。
Rundeckの内蔵Ansible連携は、プレイブックとモジュールを実行し、Ansibleインベントリをインポートできます。そのため、既存のプレイブックを個別のコマンドステップに書き直す必要はありません。必要なインタープリターがあれば、コマンドやスクリプトのステップでBash、PowerShell、Pythonも実行できます。
Semaphore UIは、対応する各ツールに専用のテンプレート設定を用意しています。Ansibleの操作ではプレイブックとインベントリを選択します。Terraform/OpenTofuとTerragruntのテンプレートはインフラ設定とワークスペースを扱い、Bash、PowerShell、Pythonのテンプレートは対応するファイルを直接実行します。Ansible中心のチームは、プロビジョニングと補助ツールをホスト操作と同じ画面にまとめられます。
テスト環境の作成依頼を考えると、利点がわかります。Terraform/OpenTofuでインフラを作成し、Ansibleでホストを構成し、Pythonでアプリケーションのエンドポイントを確認できます。Semaphore UIの各テンプレートはツール別の設定を保持し、共有するリポジトリ、インベントリ、変数グループのオブジェクトを参照します。Rundeckは同じ手順をワークフローステップ、プラグイン、ジョブ参照で表現します。違いは自動化に使う言語ではなく、その設定をどう準備し、再利用するかにあります。
Terraform/OpenTofuの共有ステートも必要なチーム向けに、Semaphore UI Proはワークスペース、バージョン履歴、画面での管理を備えたHTTPバックエンドを提供します。既存の外部バックエンドも引き続き使えます。Rundeckは、インフラコードに設定されたバックエンドを使ってTerraformを実行できます。RundeckのTerraformプロバイダーはRundeck自体の設定を管理するものであり、インフラジョブのステートを保存する機能とは目的が異なります。
保存した正確なTerraformプランを承認して適用する必要がある場合は、プランの保存と再利用を明示的に設定します。Semaphore UIの標準実行はplanとapplyを別々に行い、上書きしない限り標準コマンドに-lock=falseを使用します。ステートバックエンドを提供しても、これらのタスクコマンド設定は変わりません。
設定とスケジュール
再利用可能な操作には、保存した定義、共通設定、起動フォームが必要です。定期実行でも、担当者にコマンドを再構成させず、準備済みの内容を再利用できることが重要です。
Rundeckは、保存した手順をジョブと呼びます。ワークフローのステップと、起動時の入力を集めるオプションを組み合わせます。オプションには必須値、検証、外部URLから取得する選択肢を設定できます。ランブック自体が、ノードへの操作やプラグインのステップを順序立てて定義する場合に適しています。
Semaphore UIのTask Template（タスクテンプレート）は、1つの自動化操作を再利用するための設定です。Ansibleでサービスを再起動する場合、エンジニアはリポジトリ、プレイブック、インベントリ、認証情報を選び、共通設定の変数グループを関連付けます。入力フォームで、同僚にサービス名や変更の参照番号を尋ねることもできます。次回の起動でもこの準備を再利用するため、同僚はコマンドラインを組み立て直す代わりに、操作そのものを扱えます。
リポジトリオブジェクトは、Git URL、既定のブランチ、アクセス認証情報を複数のテンプレート向けに1か所で保持します。プレイブックのリポジトリを一度接続すれば、バックアップ、デプロイ、証明書の更新に再利用できます。RundeckのGit SCM連携は、ジョブ定義のバージョン管理とインポートを行います。ジョブが使う自動化コードの取得は、別のステップまたは連携機能です。
名前付きの変数グループによって、Semaphore UIのテンプレートで環境設定のまとまりを再利用できます。地域ごとのエンドポイントやドメイン設定をまとめて管理し、それらを使う操作に関連付けられます。Rundeckでもプロジェクトのグローバル変数で値を共有し、ジョブのオプションで実行固有の値を収集できます。Semaphore UIは、グループ化と割り当てをテンプレート設定画面で明示します。
同じ仕組みは定期作業にも使えます。データベースのバックアップ用プレイブックを設定済みの入力でcronスケジュールから実行し、保守時間の前には担当者が手動実行することもできます。証明書の確認、更新、パッチ適用は、同じインベントリに対して個別のテンプレートを使えます。どちらも定期スケジュールに対応するため、違いは保存したジョブと周辺設定がチームの既存の自動化にどう合うかです。
実行
ジョブは、プライベートホスト、近くに配置したランナー、管理された実行環境で動かす必要がある場合があります。Webサービスの場所だけで、これらの実行方法が決まるわけではありません。
実行環境はプライベートインフラの近くに配置できます。例えば、顧客のネットワーク内にあるSemaphore UIランナーから、そこに接続できるホストに対してAnsibleの保守プレイブックを実行できます。Communityにはグローバルランナーが含まれ、Proはプロジェクトに割り当てるランナーとタグによる振り分けを追加します。Dockerによるタスク実行はProから利用でき、Kubernetesによるタスク実行にはEnterpriseが必要です。両製品の振り分け機能は、対応する商用エディションでタグによる実行用マシンの選択に対応します。
Rundeck Communityでも、通常はSSHや他のノードエグゼキューターを使い、リモートノードでコマンドを実行できます。商用のEnterprise Runnerは、リモート環境に独立した実行拠点を提供します。リモート実行をすべて有償機能とみなさず、各手順をどこで実行し、どの接続が必要かを比較してください。どちらのアプリケーションも、Dockerで導入することと、各ジョブを専用コンテナで実行することは別です。
どちらも並行する処理を制御できます。Semaphore UIはテンプレートごとに並列実行を設定し、プロジェクトごとに実行中のタスク数を制限します。Rundeckは同じジョブの複数実行を許可し、ノードへの処理配布に使うスレッド数を設定できます。これらの設定で、基礎となるプレイブックやランブックを変更せずに実行能力を共有できます。
ワークフロー
サービスの更新では、バックアップ、設定変更、検証、失敗後の復旧が必要になることがあります。手順の組み立て方と再利用可能なサブ手順が、ランブックの保守方法を決めます。
複数の操作をまとめる場合、Semaphore UIのワークフローは成功時と失敗時の経路、承認、待機を使ってテンプレートを接続します。例えば、Ansibleによる更新と検証の前にバックアップを行えます。Rundeckは、再利用可能なジョブ参照、ステップ単位のエラーハンドラー、1回だけ実行するステップと選択した各ノードに配布するステップを区別する実行方式を提供します。Semaphore UIでは個別のテンプレートを複数のワークフローで再利用できますが、ワークフロー全体を別のワークフローに組み込むことはできません。
どちらも取得した値を後続のステップに渡せます。Semaphore UI 2.20は、Ansibleのset_stats、Terraform/OpenTofu/Terragruntのoutputs、Bash、PowerShell、PythonのJSONを収集し、宛先の入力に対応付けます。収集はサーバーまたはランナーのローカルエグゼキューターで動作しますが、DockerとKubernetesのエグゼキューターでは動作しません。Rundeckはログフィルターでデータを取得し、内蔵のGlobal Variableステップで後続ステップや親ジョブに値を公開します。どちらの方式でもホストアドレスなどの値は直接渡せますが、ファイルやアーカイブには次のステップからアクセスできるストレージか、明示的な転送が必要です。受け取り側のテンプレートで入力を定義し、プレイブックやインベントリ設定からその値を使って新しいホストを対象にします。
本番環境の更新では、Semaphore UIのワークフローが重要な操作の前に承認ノードで一時停止できます。2.20の承認権限はプロジェクトのタスクを実行する権限に従い、独立した承認者ロールは2.21向けに発表されています。Rundeckのジョブ参照とAPIを使えば、承認する手順を個別に起動するジョブに分け、外部の承認プロセスと接続できます。ただし、通常のジョブ起動を強制された承認とみなすのではなく、承認ゲートと処理の再開をチームで実装する必要があります。
多くのランブックが同じ複数ステップの復旧手順を共有する場合、Rundeckの入れ子のジョブ参照は特に有効です。Semaphore UIでは、再利用する単位が1つのプレイブックやツール呼び出しである場合、共通の操作をテンプレートにしておく方式が適しています。ワークフロー内に別のワークフローが必要な手順では、APIによるオーケストレーションや分割方法の変更が必要になり、設定と結果の扱いが増えます。
アクセス制御と認証
同僚にサービス再起動ボタンを提供するときには、許可する手順、ホスト、サインイン方法も決める必要があります。これらの制御は、担当者が作業を選ぶ方法に合うものであるべきです。
RundeckのACLポリシーは、ジョブ、ノード、その他のリソースを区別します。特定の手順とホスト群の一部にアクセスを付与でき、担当者が多くのランブックをまたいで対象を選ぶ場合に有効です。
Semaphore UIはプロジェクトと準備済みテンプレートを中心に作業を委任します。Communityのプロジェクトロールでも、すべての運用担当者に自動化リソースの編集責任を与えずに、同僚がタスクを実行できます。サービス再起動、バックアップ、チェックを1つのプロジェクトにまとめ、エンジニアが定義を管理し、同僚が必要な操作を起動できます。
プロジェクト全体の起動権限では広すぎる場合、Enterpriseがカスタムロールとテンプレート単位の実行権限を追加します。例えば、サポート担当者にはサービス再起動テンプレートを許可し、デプロイは別のロールに制限できます。インベントリ、認証情報、有効な起動時の上書き設定は、そのテンプレートの設定に属します。この方式は、任意のジョブに横断的に適用される独立したノード権限とは異なります。
Semaphore UI ProはLDAP/Active DirectoryとOIDCのサインインに加え、ローカルTOTPを提供します。Rundeckはローカルアカウントと、LDAPやActive Directoryを含むJAAS経由のディレクトリ認証に対応します。認証が利用者を特定し、プロジェクトロールやACLポリシーが、その人に起動できる内容を別途定めます。準備済み操作で許可するホストやパラメーターの上書きは、委任する範囲に合うものだけにする必要があります。
ログと監査
実行記録は操作の失敗を説明します。監査証跡は、誰がサービスを利用、変更したかを示し、セキュリティチームが別途収集できます。
操作を実行した同僚は、作成者に再現を頼まずに何が起きたかを確認できる必要があります。どちらも実行結果とログを保持します。Rundeckはジョブのステップとノードごとの結果を表示します。Semaphore UIは各タスクの状態、出力、リポジトリのリビジョン、起動の詳細を保持し、インシデント調査で同じ実行を振り返れるようにします。
Ansibleでのパッチ適用や証明書のジョブ向けに、Semaphore UI Proは成功したホストとサーバーごとに失敗したタスクを示すホスト概要を追加します。担当者は影響を受けたホストから対応する出力を確認できます。この概要がなくても、Communityのタスク履歴とログは有用です。これらの実行記録は自動化処理を説明し、管理操作の監査イベントは別の目的を担います。
Rundeckは監査リスナーで監査イベントを記録し、ACLの判断には独立した認可ログを用意しています。商用のRunbook Automationは外部サービス向けのAudit Streamプラグインを追加し、ログエージェントでローカルファイルを収集することもできます。Semaphore UIは記録を有効にすると管理者向けの監査ログ画面を提供し、ProはTLS SyslogやSplunk HECでイベントを転送します。セキュリティチームはアクセスや設定の確認にこれらの記録を使い、エンジニアはタスクログとホスト概要で操作自体を調査できます。
読了時間：約17分
