Terraform UI：Semaphore UIとGaiaの比較

Denis GukovSemaphore UI 創業者兼 CTO
読了時間：約15分

GaiaとSemaphore UIは、どちらもインフラ自動化のWebインターフェースを提供します。GaiaはTerraformのモジュールとスタックをセルフサービスのカタログとして提供します。Semaphore UIはTerraform/OpenTofuに加え、Ansible、Terragrunt、Bash、PowerShell、Pythonを実行し、プロビジョニングとその後の運用をカバーします。本記事ではGaia 2.4.0とSemaphore UI 2.20.0を比較します。

この記事について AI に相談

概要

Terraformモジュールで環境を作成できますが、そのプロセスの共有にはapplyの実行以上のことが必要です。利用者は適切な入力と認証情報を指定し、生成されたステートと出力を確認する必要があります。その後、サーバーとサービスには構成、バックアップ、更新、他の人が繰り返し行える運用手順が必要になります。

Gaiaはプロビジョニングの部分をTerraformサービスカタログにまとめます。作成者がモジュールを公開し、利用者が個別に設定されたスタックを作成し、ジョブがリソースのplan、apply、destroyを行います。各スタックは、1つのインフラインスタンスについて独自の変数、認証情報、ステート、実行履歴を保持します。

Semaphore UIはプロビジョニングを、より広い自動化サービスに組み込みます。Terraform/OpenTofuのテンプレートはワークスペース、再利用可能な変数、起動フォームを使えます。Ansibleテンプレートがインベントリとホスト構成を追加し、Bash、PowerShell、Python、Terragruntの操作も同じプロジェクトと実行方式を使います。ワークフローがステップを接続し、スケジュールによってその後の保守も同じ画面で扱えます。

1つのプロジェクトにある複数の自動化ツール向けSemaphore UIタスクテンプレート。
Semaphore UI. 準備済みのAnsible、Infrastructure as Code、コマンドラインの操作を、プロジェクトのタスク一覧で共有します。
入力変数、Terraformジョブ、出力を表示するGaiaのスタック画面。
Gaia. モジュールのインスタンスは、独自の入力、ジョブ、stateを持つスタックとして管理されます。公式ドキュメントの例。 出典

主要項目の比較

どちらも、各自のノートPCに設定を再現せずにインフラコードを実行できます。主な違いは、共有サービスが管理する対象です。Terraformモジュールのカタログを管理するのか、プロビジョニング、Ansibleの構成、定期的な運用まで管理するのかが異なります。

GaiaとSemaphore UIの主な特徴
比較項目 Semaphore UI Gaia
自動化ツール Ansible, Terraform/OpenTofu, Terragrunt, Bash, PowerShell, Python Terraform
再利用する単位 タスクテンプレートとワークフロー Terraformモジュールと個別に設定するスタック
インストール バイナリ、パッケージ、Docker、Kubernetes Javaアプリケーション、Docker Compose、Kubernetes
実行時の依存関係 データベース、Git、選択したツール Javaアプリケーション、MongoDB、Docker/Kubernetesランナー
実行 サーバーまたはランナー上 DockerまたはKubernetesを使う独立したランナー
スケジュール cron 式と単発実行 plan/applyジョブAPIを使う外部スケジューラー
ワークフロー Ansible、IaC、スクリプトのテンプレートを接続 Terraformのplan/applyステージ、外部オーケストレーション
ステートストレージ 既存のバックエンド、またはPro内蔵のHTTPバックエンド 内蔵のスタックステートバックエンド
入力 入力フォーム、再利用可能な変数グループ、シークレット モジュール変数、既定値、検証
インベントリ 再利用可能なAnsible定義と検出プラグイン スタックごとのTerraformリソースと出力
アクセス制御 プロジェクトロール、Enterprise のカスタムロール 管理者とユーザーのロール、組織単位のモジュールアクセス
認証情報 キーストアと外部シークレットストア クラウドの認証情報、任意のVault連携
ライセンス MITライセンスのCommunity、商用のProとEnterprise MPL 2.0ライセンスのオープンソース

Gaiaは承認済みモジュールとその個別のスタックインスタンスをまとめ、オープンソースプロジェクトに内蔵のTerraformステートストレージを含めます。Semaphore UIはチームの既存ツールや設定を中心に操作を準備します。そのため、プロビジョニングジョブと、環境のライフサイクル全体で使うAnsibleプレイブックや保守ジョブを、同じ画面で扱えます。

対象範囲が広いからといって、すべてのジョブをワークフローにする必要はありません。同僚が準備済みのバックアップやサービス再起動を単独で実行し、両方が必要な手順ではエンジニアがプロビジョニングと構成を接続できます。

機能比較

再利用可能な入力、インベントリ、認証情報により、同僚は設定を組み立て直さずに操作を実行できます。実行設定が処理の場所を決め、スケジュール、ワークフロー、記録された結果がプロビジョニング後の作業を支えます。

インストールとセットアップ

共有の自動化サービスは、既存サーバーやコンテナプラットフォームの一部として実行できます。アプリケーションとジョブの実行環境は、別々に導入方法を選べます。

対応一部対応非対応
インストールとセットアップ: GaiaとSemaphore UI
比較項目 Semaphore UI Gaia
スタンドアロンのネイティブバイナリ 対応 非対応Javaランタイムが必要
ネイティブ Linux パッケージ 対応 非対応Javaアプリケーションとしての配布
Docker デプロイ 対応 対応Docker Composeのサービス
Kubernetes デプロイ 対応 対応

GaiaはJavaのWebアプリケーション、MongoDBデータベース、実行ランナーを分離します。ランナーはDockerコンテナやKubernetes PodでTerraformを起動し、並列ジョブ数の上限を設定できます。Docker Composeはこれらのサービスをまとめ、実験的なHelmチャートがKubernetesへの導入方法を提供します。

Semaphore UIはバイナリやネイティブパッケージに加え、DockerやKubernetesでも動作します。エンジニアのノートPCから日常の自動化を移すチームは、既存のサーバーで始め、TerraformのプロビジョニングとAnsibleの保守に同じサービスを使えます。ジョブ用のコンテナが必要かどうかは、選んだ実行方式によって決まります。

自動化ツール

プロビジョニング、ホスト構成、サービス保守では異なるツールを使います。専用テンプレートならそれらを独立して実行できる一方、Terraformのプロビジョナーはコマンドをリソースのライフサイクルに結び付けます。

対応一部対応非対応
自動化ツール: GaiaとSemaphore UI
比較項目 Semaphore UI Gaia
Terraform / OpenTofu 対応 一部対応Terraformモジュール、OpenTofuテンプレートなし
Ansible Playbook 対応 一部対応Ansible実行環境を備えたプロビジョナー
Terragruntジョブの直接実行 対応 非対応Terraformコマンドのライフサイクル
Bash 対応 一部対応必要なインタープリターを備えたプロビジョナー
PowerShell 対応 一部対応必要なインタープリターを備えたプロビジョナー
Python 対応 一部対応必要なインタープリターを備えたプロビジョナー
Ansibleとスクリプトの独立した操作 対応 非対応スタックのRUNジョブとDESTROYジョブ

Gaiaは生成したTerraformコマンドの手順でモジュールを実行します。ランナーのイメージやリモート対象に必要なツールがあれば、TerraformのプロビジョナーからAnsibleやコマンドラインプログラムを呼び出せます。新しく作成したリソースの構成には使えますが、コマンドはTerraformの実行に付随し、独立したGaiaの操作にはなりません。標準のコマンド生成には、独立したOpenTofuやTerragruntのテンプレートはありません。

Semaphore UIは、Ansible、Terraform/OpenTofu、Terragrunt、Bash、PowerShell、Pythonを直接実行するテンプレートを提供します。OpenTofuでインフラを作成し、Ansibleでパッケージを構成し、Pythonで稼働準備を確認できます。その後、Ansibleによる構成やPowerShellによる保守を、Terraformのライフサイクルを再度開始せずに単独で実行できます。Proの内蔵ステートバックエンドは、Terraform/OpenTofuのステートと履歴もそれらのジョブとともに保持します。

操作の設定と入力

作成者が一度設定を準備すれば、同僚は繰り返し実行できる操作を要求できます。Gaiaはモジュールとそのスタックインスタンスを保存し、Semaphore UIはプロビジョニングや保守で再利用できるテンプレートを保存します。

対応一部対応非対応
操作の設定と入力: GaiaとSemaphore UI
比較項目 Semaphore UI Gaia
操作設定の保存 対応タスクテンプレート 対応モジュールとスタック
入力フォーム 対応 対応
変数の設定と再利用 対応テンプレート間で共有する名前付きグループ 対応モジュールの既定値とスタックごとの値
入力の検証 対応必須項目、整数チェック、選択肢 対応必須値と正規表現

Gaiaのモジュール作成者は、ソースリポジトリ、Terraformのバージョン、変数スキーマを定義します。利用者はそのモジュールからスタックを作成し、自分の環境に合う値とクラウド認証情報を指定します。スタックは固有のステートとジョブを持つ永続的なインスタンスとなり、個別に依頼されるインフラのカタログに適しています。Gaiaは必須値と設定可能な正規表現を検証します。Semaphore UIの入力フォームは必須項目、整数、選択肢を検証しますが、同等の正規表現ルールは設定できません。

Semaphore UIは保存した操作をTask Template（タスクテンプレート）と呼びます。リポジトリ、ツール設定、変数、操作に必要なインベントリや認証情報をまとめます。名前付きの変数グループで環境設定をテンプレート間で再利用し、入力フォームの項目で起動時の値を収集します。例えば、サービス再起動のテンプレートでサービスと環境の選択肢を用意すれば、同僚にコマンドの組み立てを求めずに済みます。プロビジョニングのテンプレートでも、同じ方式で環境パラメーターを指定できます。

Terraformのライフサイクル

実用的なTerraformの画面には、コマンドの起動以上の機能が必要です。コード、入力、ステート、利用者に要求が許可された操作の関係を、繰り返し使える形で保持する必要があります。

対応一部対応非対応
Terraformのライフサイクル: GaiaとSemaphore UI
比較項目 Semaphore UI Gaia
Terraformのplanとapply 対応 対応
独立した環境インスタンス 対応準備済みテンプレートとワークスペース設定 対応モジュールから作成するスタック
環境ごとのステートと認証情報 対応設定済みのバックエンド、ワークスペース、認証情報 対応独立したスタックステートとクラウド認証情報
環境の削除 対応Terraform/OpenTofuのdestroy操作 対応Destroyジョブ
標準動作で保存済みプランを適用 非対応 非対応
内蔵のステートストレージ 対応Pro 対応

Gaiaは、スタックに設定されたモジュール、入力、クラウド認証情報に対してplan、apply、destroyを実行します。内蔵バックエンドがスタックのステートを保持し、スタックのページに出力とジョブ履歴をまとめます。同じモジュールから作成した場合でも、別々のテスト環境で独立したステートと実行記録を保持できます。

Semaphore UIはタスクテンプレートでTerraform/OpenTofuのリポジトリ、ワークスペース、設定を選択します。変数グループで関連ジョブ間の設定を再利用し、入力フォームで起動時の値を収集します。エンジニアは環境のプロビジョニング操作を一度準備し、同僚が保存済みの設定から要求できるようにします。各環境には独自の変数、認証情報、バックエンドのステートも必要です。Gaiaはこれらを個別のスタックインスタンスで表します。Semaphore UIでは、対応するテンプレート、ワークスペース、バックエンド設定をチームが準備します。ワークスペースの分離はバックエンドに依存するため、ワークスペースを選ぶだけで、すべてのバックエンドのステートが分離されるわけではありません。Terraformに加え、TerragruntとOpenTofuも専用テンプレートとして選べます。

リポジトリ、ワークスペース、変数グループを指定するSemaphore UIのTerraformテンプレート設定。
Semaphore UI. Terraformテンプレートは、ソースコード、ワークスペース、再利用可能な変数を1つの準備済み操作にまとめます。
リポジトリ設定、許可されたチーム、編集可能な入力変数を表示するGaiaのモジュールエディター。
Gaia. モジュールはリポジトリ、許可されたチーム、入力検証を定義します。プロジェクト公式の例。 出典

ステートは、その設定の独立した要素です。Gaiaは商用ライセンスなしで、スタックごとのステートバックエンドを提供します。Semaphore UIはTerraform/OpenTofuコードに設定されたバックエンドを使い、Proでは履歴と画面管理を備えた内蔵HTTPステートバックエンドも提供します。バックエンドをSemaphore UI内に置けば、別のステートサービスを追加せず、ステートを変更するジョブと同じ場所で共有ステートを管理できます。

どちらも標準動作では、事前に保存したプランファイルを適用しません。Gaia 2.4.0はplanの結果を表示しますが、applyコマンドは保存済みのプランファイルを使用しません。Semaphore UIの標準実行もplanとapplyを別々に行います。提案された正確な変更に承認を適用する必要がある場合は、そのプランの保存と再利用を明示的に組み込む必要があります。

インベントリ

パッチ適用や証明書チェックには、ホストを繰り返し選択できる仕組みが必要です。Ansibleインベントリがその役割を担い、Terraformステートはスタックが管理するリソースを記述します。

対応一部対応非対応
インベントリ: GaiaとSemaphore UI
比較項目 Semaphore UI Gaia
再利用可能なAnsibleインベントリ 対応画面上の定義またはGit内のファイル 非対応インベントリリソースなし
ホストの動的検出 対応Ansibleインベントリプラグイン 一部対応インベントリの生成、またはTerraformからAnsibleを呼び出す

Gaiaは各スタックにTerraformのリソースと出力を保持します。Terraformの出力は、プロビジョナーや他のシステムに必要なホストアドレスを提供できますが、Gaiaの画面内にAnsibleインベントリリソースを作るものではありません。プロビジョナー経由でAnsibleを呼び出す場合、自動化処理の一部としてインベントリを受け取るか生成する必要があります。

Semaphore UIはAnsibleインベントリを再利用可能なプロジェクトリソースとして保存します。静的な定義を編集したり、Git内のファイルを使ったり、ジョブ実行時にAnsibleインベントリプラグインでホストを検出したりできます。同じインベントリをデプロイ、パッチ適用、証明書チェックに使えます。プロビジョニングが作業の始まりにすぎず、その後も既存のホスト群を扱い続ける場合に特に有効です。

実行

実行設定は、どのマシンが対象にアクセスし、どの依存関係を提供するかを決めます。どちらもプライベートインフラ内で実行できますが、コンテナを使わないジョブの選択肢は異なります。

対応一部対応非対応
実行: GaiaとSemaphore UI
比較項目 Semaphore UI Gaia
コンテナなしのジョブ実行 対応 非対応TerraformのジョブランナーにDockerまたはKubernetesが必要
リモート実行 対応ランナー 対応独立したGaia Runner
Dockerによるジョブ実行 対応Pro 対応
Kubernetes ジョブ Pod 対応Enterprise 対応

Gaiaはアプリケーションとランナーを分離します。ランナーは待機中のTerraformステップを要求し、設定可能な並行数でDockerコンテナやKubernetes Pod内に実行します。Gaia APIとモジュールが利用するサービスに到達できれば、プライベートインフラの近くで動かせます。選択したイメージがTerraformと、プロビジョナーに必要な追加プログラムを提供します。

Semaphore UIはアプリケーションサーバー上、または対象の近くに配置したランナー上でジョブを実行できます。小規模な導入はコンテナプラットフォームなしで始められ、大規模な導入ではランナーから別のネットワークに到達できます。ProはプロジェクトランナーとDockerでのジョブ実行を追加し、EnterpriseはKubernetesのジョブPodを追加します。WebアプリケーションをDockerに導入することと、各ジョブを専用コンテナで実行することは別々の選択です。

スケジュール

指定した時刻や手動操作なしでインフラジョブを繰り返すには、スケジュールが重要です。Semaphore UIは準備済みテンプレートを直接スケジュールします。GaiaはTerraformスタックのジョブを調整する外部スケジューラーを必要とします。Semaphore UIのタスクが扱う範囲はより広いため、同じスケジュール画面で独立したバックアップ、パッチ適用、証明書チェックも扱えます。

対応一部対応非対応
スケジュール: GaiaとSemaphore UI
比較項目 Semaphore UI Gaia
cronスケジュール 対応 一部対応ジョブAPIを呼び出す外部スケジューラー
一度だけの予約実行 対応 一部対応ジョブAPIを呼び出す外部スケジューラー

Semaphore UIは、準備済みテンプレートにcronと一度だけのスケジュールを保存します。夜間のバックアップ、定期的な証明書チェック、パッチ適用で、作成者が選んだインベントリ、認証情報、起動設定を再利用できます。手動実行と定期実行は同じ実行履歴に表示されます。

Gaia 2.4.0にはスケジュール画面がありません。外部スケジューラーはPOST /api/stacks/{id}/{jobType}でRUNまたはDESTROYジョブを作成し、POST /api/jobs/{jobId}/planでplanを開始できます。変更の適用は、planの完了後に/api/jobs/{jobId}/applyへ別のPOSTを送って行います。スケジューラーは、ジョブIDの作成を実行完了とみなさず、このライフサイクルを処理し、ジョブの最終結果を確認する必要があります。

ワークフロー

環境の手順全体では、インフラのプロビジョニング、ホスト構成、サービス検証を行います。Gaiaはスタックジョブのplan/applyステージを管理し、Semaphore UIは独立した操作とその結果を接続します。

対応一部対応非対応
ワークフロー: GaiaとSemaphore UI
比較項目 Semaphore UI Gaia
ツールを横断するビジュアルワークフロー 対応 非対応複数ツールのワークフローエディターなし
承認ステップ 対応 一部対応Terraformのplanとapplyの間の確認
操作間の値の受け渡し 対応 一部対応コードまたはAPI連携によるスタック出力の受け渡し

Gaiaはスタックのplanからapplyまでを扱います。画面ではplan後に別途確認を行え、スタックの削除も同様です。Terraformのプロビジョナーはそのライフサイクル内で追加の操作を実行でき、外部システムはAPIで複数のジョブを調整できます。Gaiaには、独立して再利用可能なAnsible、Terraform、スクリプトの操作をつなぐビジュアルグラフはありません。

Semaphore UIは承認、成功時と失敗時の経路を含むビジュアルワークフローで、保存済みテンプレートを接続します。ロールアウトでインフラをプロビジョニングし、承認を待ち、ホストを構成して検証できます。各テンプレートはその後の保守にも使えます。サーバーやランナーのローカルエグゼキューターを使えば、収集した値をステップ間で渡せます。生成ファイルや保存済みTerraformプランには、引き続きアクセス可能なストレージや明示的な転送が必要です。どちらの製品も、標準動作では保存済みTerraformプランを適用しません。

アクセス制御

プロビジョニング用モジュールの共有と、準備済みのサービス再起動の委任では、必要な権限の境界が異なります。アクセス設定によって、作成者が操作を準備し、同僚に利用に必要な権限を与えられることが重要です。

対応一部対応非対応
アクセス制御: GaiaとSemaphore UI
比較項目 Semaphore UI Gaia
ロールベースのアクセス 対応プロジェクトロール 対応ロールとモジュールの組織
カスタムロール 対応Enterprise 非対応固定のアプリケーションロール
外部サービスによるサインイン 対応ProLDAP と OIDC 対応GitHubとGitLabのOAuth2、LDAP

Gaiaは組織を使ってモジュールを共有し、管理者とユーザーのロールを提供します。モジュールの作成者が承認済みのTerraform定義をチームに公開し、利用者が自分のスタック用の設定を指定します。GitHubとGitLabの連携は、OAuth2サインインとリポジトリのインポートを組み合わせます。LDAPにも対応します。

Semaphore UI Communityはプロジェクト内で自動化を共有します。プロジェクトロールが、プロジェクト内の自動化を誰が閲覧、実行、編集できるかを制御します。実行権限を持つ同僚は、デプロイ、バックアップ、保守ジョブを起動し、結果を確認できます。エンジニアが操作を準備し、同僚は保存済みの設定と起動時の入力を使います。

アクセスを特定の操作に限定する必要がある場合、Enterpriseではカスタムロールとテンプレート単位の実行権限を追加できます。たとえば、プロジェクト全般の編集権限を与えずに、サービス再起動テンプレートの実行を委任できます。この境界は入力フォームだけでなく、ロール権限と操作の設定によって定まります。Proは中央のIDプロバイダーを利用するチーム向けにLDAPとOIDCによるサインインを追加します。Semaphore UI Proではローカルアカウント向けのTOTPによる二要素認証も利用できます。

シークレット

クラウドのプロビジョニング用認証情報と、ホスト構成に使うSSH認証情報は別のリソースです。共有サービスは、実行のたびに担当者にシークレットの貼り付けを求めずに、それらを再利用できる必要があります。

対応一部対応非対応
シークレット: GaiaとSemaphore UI
比較項目 Semaphore UI Gaia
認証情報の保存 対応SSH鍵とパスワード 対応クラウド認証情報のオブジェクト
HashiCorp Vault 対応Proシークレットの取得 対応Transit暗号化と動的AWS認証情報
内蔵のOpenBao取得機能 対応Pro 非対応
内蔵のAWS Secrets Manager取得機能 対応Enterprise 非対応
内蔵のAzure Key Vault取得機能 対応Enterprise 非対応
内蔵のDevolutions Server取得機能 対応Enterprise 非対応
内蔵のCyberArk取得機能 対応EnterprisePVWA REST API 非対応

GaiaはAWS、Google Cloud、Azureのクラウド認証情報を提供します。任意のVault連携では、Transitエンジンによる暗号化を利用し、Vaultのシークレットエンジンに動的なAWS認証情報を要求できます。これらの認証情報はTerraformスタックのライフサイクルを支えます。

Semaphore UIのKey Storeは、Ansibleホスト用のSSHキーやパスワードなど、チームの手順で使用する認証情報に対応しています。準備済みの操作は保存された項目を参照するため、実行のたびに認証情報を貼り付ける必要がありません。ProではHashiCorp VaultとOpenBaoからのシークレット取得を、EnterpriseではAWS Secrets Manager、Azure Key Vault、Devolutions Serverとの連携、およびPVWA APIを介したCyberArkとの連携を追加できます。

たとえば、同じ環境でプロビジョニングにはクラウド認証情報を、その後のAnsible設定にはSSHキーを使用できます。これらは、それぞれの操作に関連付けられた別々の認証情報です。両プラットフォームともVaultを利用できますが、Gaiaの暗号化と動的認証情報の機能は、ジョブ用に保存済みシークレットを取得する機能とは異なります。Gaiaの組み込み認証情報タイプには、上記のほかのシークレットストア用コネクターは含まれません。Terraformコードから独自のデータソースや外部コマンドで取得することは可能ですが、その設定と保守はGaiaの認証情報画面ではなく、自動化側で行います。

ログと監査

ジョブの実行後、担当者には結果と、失敗を調査するための十分な情報が必要です。Terraformスタックの履歴とAnsibleのホスト結果は、同じ環境について異なる問いに答えます。

対応一部対応非対応
ログと監査: GaiaとSemaphore UI
比較項目 Semaphore UI Gaia
実行履歴とログ 対応 対応
実行者とタイムスタンプ 対応 対応
内蔵のAnsibleホスト／タスクレポート 対応Pro 非対応Terraformのplan/apply出力
管理操作の監査画面 対応サインインと記録された操作 非対応ジョブ履歴のみ、管理操作の監査画面なし

Gaiaはスタックジョブの実行ユーザー、状態、時刻、plan/applyの各段階を記録します。この履歴は、環境のプロビジョニングに伴う変更を確認し、Terraformの出力を調査する際に役立ちます。これはスタック操作の記録であり、Ansibleホストのレポート画面や管理操作の監査画面ではありません。

Semaphore UIは、対応するツール全体のタスク履歴を保持します。ProのAnsibleサマリーではホストとタスクの結果が追加され、パッチ適用や証明書チェックに失敗したサーバーを特定できます。監査ログは、サインインと対応する管理操作をタスク出力とは別に記録します。そのため、プロビジョニングとホスト保守の両方を行うチームは、Terraform stateをサーバー上のすべての操作の記録と見なすことなく、同じサービス内で調査できます。Proでは監査記録のフィルタリングとエクスポートに加え、チームのSIEMパイプラインに向けたSyslogとSplunk HECによる転送も利用できます。

連携とAIによる支援

既存のパイプラインやサービスから、APIで準備済みの自動化を要求できます。リポジトリ連携はコードをサービスに取り込み、イベント起点の接続には結果を確実に追跡する方法も必要です。

対応一部対応非対応
連携とAIによる支援: GaiaとSemaphore UI
比較項目 Semaphore UI Gaia
REST API 対応 対応
Gitリポジトリ 対応 対応GitHubとGitLabからのモジュールインポート
自動化の受信Webhook 対応リクエストの照合と入力値の抽出 一部対応ジョブAPIを呼び出す外部の受信処理

GaiaはGitHubまたはGitLabからモジュールを取り込み、スタック、ジョブ、およびその結果のAPIを提供します。CIパイプラインや外部の申請サービスからスタックジョブを作成し、計画を開始して、適用するタイミングを決められます。Webhookを起点とする構成には、これらの呼び出しと結果追跡を行うアダプターが必要です。Semaphore UIはREST APIに加え、リクエストを照合し、その値を準備済みタスクの入力にマッピングする受信連携Webhookを提供します。

GaiaのTerraformカタログを維持するチームは、API連携を使い、プロビジョニング完了後にSemaphore UIのAnsible設定や保守テンプレートを起動できます。その操作のインベントリ、認証情報、実行記録はSemaphore UIが管理します。これはチームが実装する接続であり、GaiaからSemaphoreへの組み込み連携ではありません。両プロジェクトともドキュメントとソースコードを公開しているため、コーディングアシスタントは接続コードの作成や設定、ジョブ出力の調査に活用できます。

ライセンスとサポート

GaiaとSemaphore UIには、いずれも無料のセルフホスト型オープンソース版があります。有料機能を比較する前から、Terraformモジュールカタログと複数の自動化ツールを扱うサービスという対象範囲の違いがあります。商用機能とサポートは、別途検討すべき要素です。

オープンソースと商用の選択肢

GaiaはMPL-2.0ライセンスで、Terraformスタックのstateバックエンドを含みます。Semaphore UI CommunityはMITライセンスで、対応ツールのテンプレート、ワークフロー、スケジュール、プロジェクトロール、実行履歴を提供します。Proは組み込みstateバックエンド、プロジェクトランナー、Dockerでのタスク実行、外部Vault連携を追加します。Enterpriseでは、より詳細なアクセス、実行、可用性の制御を追加できます。

Terraformによるプロビジョニングと定期的なAnsible操作の両方が必要なチームでは、これらのCommunity機能だけでも共有の自動化サービスを構築できます。ProやEnterpriseが必要かどうかは、単に複数のツールを使うかではなく、state、アクセス、実行の要件によって決まります。

保守とサポート

Gaiaの最新公開リリースは2022年8月12日付の2.4.0です。2026年10月21日時点の確認では、アプリケーションリポジトリのmainブランチも同じコミットを指しています。採用するチームは現在の依存関係を評価し、必要な変更を自ら保守する必要があります。

Semaphore UIは継続的にリリースを公開し、同じ製品ファミリー内でベンダーサポートを提供しています。Communityの支援はベストエフォートで、Proには営業時間内のベンダーサポートが含まれ、Enterpriseでは要件に応じたサポートを選べます。Communityでジョブの共有を始め、運用要件の拡大に合わせて商用機能やサポートを導入できます。

選び方

まず、チームがインフラをどのように申請し、管理したいかを考えます。Gaiaはモジュールカタログと個別のスタックインスタンスを中心にプロビジョニングを構成します。Semaphore UIは再利用可能なTerraform/OpenTofuテンプレート、変数、実行設定を中心に構成し、スケジュールとワークフローで手順全体を支えます。どちらもプロビジョニングに利用できます。選択の基準は運用モデルと、同じ画面でほかの自動化も扱う必要があるかどうかです。

Gaiaを選ぶ場合

承認済みのTerraformモジュールを公開し、利用者が独自のスタックインスタンスを作成できるようにすることが要件であれば、Gaiaはその用途に特化した選択肢です。

  • 個別のスタックインスタンスがサービスの中心です。 申請された環境ごとに独自の入力、認証情報、state、plan/apply/destroyの履歴が必要で、構成管理と保守は別の仕組みで行います。
  • 標準で含まれるstateストレージが重要です。 モジュールカタログとTerraform stateバックエンドを1つのオープンソース製品で利用したく、アプリケーションとランナーの保守をチームで担えます。

Semaphore UI を選ぶ場合

柔軟な実行方法と商用サポートを備えた再利用可能なTerraform/OpenTofu操作が必要な場合や、プロビジョニングをAnsible、Bash、PowerShell、Pythonとつなぐ必要がある場合は、Semaphore UIが適しています。

  • 導入方法とサポートを選びたい場合。 既存サーバーにバイナリやネイティブパッケージで導入し、必要に応じてリモート実行を追加できます。同じ製品ファミリー内でProやEnterpriseの機能とベンダーサポートを利用できます。
  • プロビジョニング後もAnsibleでの作業が続きます。 既存のインベントリ、認証情報、プレイブックを使い、同じサービスでホスト設定、パッチ適用、証明書チェック、バックアップを行う必要があります。
  • 運用環境がすでにIaCコードで定義されています。 必要な変数、認証情報、state設定を含むTerraform/OpenTofuまたはTerragruntのテンプレートを準備し、チームメンバーが実行や予約できるようにします。モジュールカタログや個別に申請するスタックインスタンスをサービスの中心に据えず、既存設定の実行を共有したいチームに適しています。
  • 手順で複数のツールを組み合わせます。 再利用可能なテンプレートとワークフローを通じて、Terraform/OpenTofuやTerragruntのプロビジョニングをAnsible設定、BashやPowerShellの操作、Pythonのチェックにつなげられます。

よくある質問

1つの設定から別々の環境を作成できますか？

GaiaではTerraformモジュールを一度公開すると、利用者は独自の入力、認証情報、stateを持つ別々のスタックを作成できます。Semaphore UIではテンプレート、入力フォーム、変数グループ、Terraform/OpenTofuのworkspaceを使用します。Semaphore UIで環境の申請を準備する際は、環境ごとに適切なworkspaceとバックエンドのstate設定を用意してください。

Semaphore UIではどのstateバックエンドを使えますか？

Terraform/OpenTofuコードで設定済みのバックエンドをそのまま使えます。Proには履歴と画面上での管理に対応した組み込みHTTPバックエンドもあります。Gaiaはオープンソース版にスタックのstateバックエンドを含みます。実行用の画面を移行する際は、各環境と設定、stateとの対応関係を維持する必要があります。

実行をプライベート環境内に留められますか？

はい。Gaia RunnerはWebアプリケーションから分離され、DockerコンテナーまたはKubernetes PodでTerraformを実行します。Semaphore UIは自社サーバーや独立したランナーでタスクを実行します。Proではタスク単位のDocker実行、EnterpriseではKubernetes実行を選べます。実行マシンは対象インフラと必要なサービスにアクセスできる必要があります。

プロビジョニングからAnsible設定や保守につなげられますか？

Semaphore UIでは可能です。ワークフローでTerraform/OpenTofuのプロビジョニング、Ansible設定、検証タスクを接続できます。個別のテンプレートは後日のバックアップ、更新、サービス操作にも利用でき、スケジュールで保守を繰り返せます。Gaiaの組み込みライフサイクルはTerraformのplan、apply、destroyを中心とし、後続の操作はほかのシステムで扱います。

GaiaのモジュールカタログをSemaphore UIへ直接移行できますか？

元のTerraformコードは再利用できますが、Gaiaのモジュールとスタックのカタログは、Semaphore UIのテンプレートとworkspaceとは異なるモデルです。各環境の入力、認証情報の参照、バックエンドのstate、実行依存関係を準備済みの操作に対応付ける必要があります。

この記事は役に立ちましたか？

出典

  1. Gaia contributors, “Gaia v2.4.0 release”. URL: https://github.com/gaia-app/gaia/releases/tag/v2.4.0 (参照日: ).
  2. Gaia, “Gaia concepts”. URL: https://docs.gaia-app.io/getting-started/concepts/ (参照日: ).
  3. Gaia, “QuickStart”. URL: https://docs.gaia-app.io/getting-started/quick-start/ (参照日: ).
  4. Gaia, “Gaia Runner configuration”. URL: https://docs.gaia-app.io/configuration/runner-configuration/ (参照日: ).
  5. Gaia contributors, “Mozilla Public License 2.0”. URL: https://github.com/gaia-app/gaia/blob/v2.4.0/LICENSE (参照日: ).
  6. Gaia contributors, “Gaia v2.4.0 source code”. URL: https://github.com/gaia-app/gaia/tree/v2.4.0 (参照日: ).
  7. Gaia, “GitHub integration”. URL: https://docs.gaia-app.io/configuration/github-integration/ (参照日: ).
  8. Gaia, “GitLab integration”. URL: https://docs.gaia-app.io/configuration/gitlab-integration/ (参照日: ).
  9. Semaphore UI, “Installation”. URL: https://semaphoreui.com/docs/admin-guide/installation (参照日: ).
  10. Semaphore UI, “Applications”. URL: https://semaphoreui.com/docs/user-guide/apps (参照日: ).
  11. Semaphore UI, “Terraform/OpenTofu”. URL: https://semaphoreui.com/docs/user-guide/apps/terraform (参照日: ).
  12. Semaphore UI, “Task Templates”. URL: https://semaphoreui.com/docs/user-guide/task-templates (参照日: ).
  13. Semaphore UI, “Workflows”. URL: https://semaphoreui.com/docs/user-guide/workflows (参照日: ).
  14. Semaphore UI, “Runners”. URL: https://semaphoreui.com/docs/admin-guide/runners (参照日: ).
  15. Semaphore UI, “Semaphore UI editions”. URL: https://semaphoreui.com/pricing (参照日: ).
  16. Semaphore UI, “Variable Groups”. URL: https://semaphoreui.com/docs/user-guide/environment (参照日: ).
  17. Gaia, “Gaia interface example”. URL: https://github.com/gaia-app/gaia/blob/v2.4.0/README.md (参照日: ).
  18. Gaia contributors, “Terraform plan and apply command construction”. URL: https://github.com/gaia-app/gaia/blob/v2.4.0/src/main/java/io/gaia_app/runner/RunnerCommandBuilder.java (参照日: ).
  19. Semaphore UI, “Terraform execution implementation”. URL: https://github.com/semaphoreui/semaphore/blob/58a596ed20b724af67c468588edcda12d1779549/db_lib/TerraformApp.go (参照日: ).
  20. Semaphore UI, “Inventory”. URL: https://semaphoreui.com/docs/user-guide/inventory (参照日: ).
  21. Semaphore UI, “Schedules”. URL: https://semaphoreui.com/docs/user-guide/schedules (参照日: ).
  22. Semaphore UI, “Semaphore cron and one-time schedule execution”. URL: https://github.com/semaphoreui/semaphore/blob/58a596ed20b724af67c468588edcda12d1779549/services/schedules/SchedulePool.go (参照日: ).
  23. Semaphore UI, “Task history and output”. URL: https://semaphoreui.com/docs/user-guide/tasks (参照日: ).
  24. Semaphore UI, “Team roles and extended RBAC”. URL: https://semaphoreui.com/docs/user-guide/team#extended-rbac (参照日: ).
  25. Semaphore UI, “Key Store”. URL: https://semaphoreui.com/docs/user-guide/key-store (参照日: ).
  26. Semaphore UI, “Semaphore local execution, workflow outputs, inventory paths, host limits and branch overrides”. URL: https://github.com/semaphoreui/semaphore/blob/58a596ed20b724af67c468588edcda12d1779549/services/tasks/local_executor.go (参照日: ).
  27. Gaia contributors, “Stack job launch API for RUN and DESTROY”. URL: https://github.com/gaia-app/gaia/blob/v2.4.0/src/main/java/io/gaia_app/stacks/controller/StackRestController.java#L104-L123 (参照日: ).
  28. Gaia contributors, “Independent stacks, variables and credential references”. URL: https://github.com/gaia-app/gaia/blob/v2.4.0/src/main/java/io/gaia_app/stacks/bo/Stack.java (参照日: ).
  29. Semaphore UI, “External secret storage types in the Semaphore UI 2.20 candidate”. URL: https://github.com/semaphoreui/semaphore/blob/58a596ed20b724af67c468588edcda12d1779549/db/SecretStorage.go (参照日: ).
  30. Gaia contributors, “Gaia 2.4.0 built-in credential types”. URL: https://github.com/gaia-app/gaia/blob/v2.4.0/src/main/java/io/gaia_app/credentials/Credentials.kt (参照日: ).
  31. Semaphore UI, “CyberArk secret storage for Enterprise”. URL: https://semaphoreui.com/docs/user-guide/key-store/cyberark (参照日: ).
  32. Gaia contributors, “Gaia 2.4.0 application routes”. URL: https://github.com/gaia-app/gaia/blob/v2.4.0/src/main/client/app/router.js (参照日: ).
  33. Gaia contributors, “Gaia RUN and DESTROY job types”. URL: https://github.com/gaia-app/gaia/blob/v2.4.0/src/main/java/io/gaia_app/stacks/bo/JobType.java (参照日: ).
  34. Gaia contributors, “Configurable Terraform runner image”. URL: https://github.com/gaia-app/gaia/blob/v2.4.0/src/main/java/io/gaia_app/modules/bo/TerraformImage.kt (参照日: ).
  35. Gaia contributors, “Runner scripts, stack inputs and execution environment”. URL: https://github.com/gaia-app/gaia/blob/v2.4.0/src/main/java/io/gaia_app/runner/RunnerController.java (参照日: ).
  36. Gaia contributors, “Separate plan, apply and retry API actions”. URL: https://github.com/gaia-app/gaia/blob/v2.4.0/src/main/java/io/gaia_app/stacks/controller/JobRestController.kt (参照日: ).
  37. Gaia contributors, “Stack job identity, user, timing and execution steps”. URL: https://github.com/gaia-app/gaia/blob/v2.4.0/src/main/java/io/gaia_app/stacks/bo/Job.java (参照日: ).
  38. HashiCorp, “Terraform provisioners and command execution”. URL: https://developer.hashicorp.com/terraform/language/provisioners (参照日: ).
  39. Semaphore UI, “Audit log and external log forwarding”. URL: https://semaphoreui.com/docs/admin-guide/audit-log (参照日: ).
  40. Semaphore UI, “Incoming integrations and webhooks”. URL: https://semaphoreui.com/docs/user-guide/integrations (参照日: ).
  41. Semaphore UI, “Reusable Git repositories”. URL: https://semaphoreui.com/docs/user-guide/repositories (参照日: ).
  42. Gaia contributors, “Stack state API used to retrieve Terraform outputs”. URL: https://github.com/gaia-app/gaia/blob/v2.4.0/src/main/java/io/gaia_app/stacks/controller/TerraformStateController.java (参照日: ).

上記のドキュメント、リポジトリ、製品情報に基づきSemaphore UI Teamが作成した比較です。各出典に参照日を記載しています。

関連リンク

チームがすでに行っている運用と、必要な制御を評価してください。

Semaphore UI のインストール

インストール方法を選び、既存の操作の一つで評価してください。

Semaphore UI のエディションを比較

チームに必要なアクセス、シークレット保管、実行の制御を確認します。