クラウドシークレットマネージャー統合 詳細

バージョン 2.18

クラウドプラットフォームを使用する組織は、実行時にクラウドプロバイダーのシークレット管理サービスから直接シークレットを取得する方法を必要としています。これにより、認証情報の重複を避け、既存のローテーションポリシーを活用できます。この機能は、AWS Secrets Manager および Azure Key Vault とのネイティブ統合を Enterprise 専用機能として追加します。

Enterprise

  • AWS Secrets Manager 統合 — IAM ロール、アクセスキー、または引き受けロールを使用して、実行時に AWS Secrets Manager からシークレットを取得します。フィールド抽出と自動ローテーション付きの JSON 構造シークレットをサポートします。(#2248)
  • Azure Key Vault 統合 — マネージド ID またはサービスプリンシパル認証を使用して、実行時に Azure Key Vault からシークレットを取得します。自動ローテーション付きのシークレット、キー、証明書をサポートします。(#2248, #3170)
  • シークレットキャッシング — 解決されたシークレットをメモリにキャッシュすることで、クラウドプロバイダーへの API 呼び出しを削減します。

永続リポジトリキャッシュ

バージョン 2.18

現在、Semaphore はタスクテンプレートごとにリポジトリを個別のディレクトリにクローン(またはプル)しています。これは大規模なリポジトリでは遅く、ディスク I/O を浪費します。この機能は、リポジトリごとのフラグを追加し、バックグラウンドで定期的に更新される共有の永続クローンに切り替えます。AWX がプロジェクト更新を処理する方法と同様です。有効にすると、そのリポジトリを参照するすべてのテンプレートが単一の作業コピーを共有し(Semaphore のローカルリポジトリで既に使用されているモデルと同じ)、個々のタスク実行ではクローンやプルがトリガーされなくなります。

Community

  • リポジトリ設定の「リポジトリをキャッシュ」フラグ — 各リポジトリにトグルを追加し、有効にするとタスク実行ごとにクローンする代わりに単一の永続クローンを保持します。クローンはそのリポジトリを使用するすべてのテンプレート間で共有され、ローカルリポジトリが既に持っている動作と一致します。(#1212)
  • バックグラウンド定期同期 — キャッシュフラグが有効な場合、タスク開始時ではなくバックグラウンドワーカーで設定可能な間隔(例:5分ごと)で更新をプルし、タスクが常に最新のチェックアウトに対して即座に起動できるようにします。
  • 手動同期アクション — リポジトリ UI に「今すぐ同期」ボタンと、定期スケジュール外で即座にプルをトリガーするための対応する API エンドポイントを提供します。
  • 強制プッシュ/履歴書き換えへの耐性 — 通常のプルで失敗する代わりに、上流の強制プッシュを適切に処理します(例:git fetch --all && git reset --hard origin/<branch>)。(#800)
  • ダーティな作業ツリーの回復 — プル前にダーティな作業ツリー(例:残存する .retry ファイル)を自動検出してクリーンし、「ローカル変更」エラーを防止します。(#308)
  • 古いクローンのクリーンアップ — 削除されたリポジトリや URL が変更されたリポジトリのキャッシュされたクローンをガベージコレクションし、ディスク容量を回収します。(#1497, #2679)
  • 同期ステータスの可視化 — リポジトリ詳細ページに最終同期のタイムスタンプとステータス(成功/失敗)を表示し、作業コピーがどの程度新しいかをユーザーが確認できるようにします。
  • リポジトリごとの同期スケジュール — 個々のリポジトリでグローバル同期間隔をオーバーライドできるようにします(例:変更頻度の高いリポジトリは毎分、安定したリポジトリは毎時)。

LDAP と OpenID のグループマッピング

バージョン 2.18

Semaphore は認証に LDAP と OpenID Connect (OIDC) をサポートしていますが、統合はログインで止まっています。ID プロバイダーのグループメンバーシップに基づいた自動ロールまたはプロジェクト割り当てはありません。すべての OIDC/LDAP ユーザーは初回ログイン後に手動でプロジェクトとロールに割り当てる必要があります。さらに、OIDC リダイレクト処理、クレーム解析、LDAP 設定に複数のバグがあり、認証体験が不安定になっています。

Community

  • クレームによる OIDC ログイン制限 — 特定のクレーム値(例:必須グループメンバーシップやメールドメイン)を持つユーザーのみがログインできるようにします。(#2626, #2938)
  • SSO 自動ログイン — ログイン画面をバイパスして OIDC/SSO プロバイダーに直接リダイレクトし、SSO がダウンした場合の復旧用フェイルセーフ URL を提供します。(#2548, #2899)
  • OIDC PKCE サポート — RFC 9700 で推奨されている Proof Key for Code Exchange を OIDC 認可コードフローに追加します。(#3072)
  • OIDC 環境変数設定 — 設定ファイルだけでなく環境変数経由でも OIDC プロバイダーを設定できるようにし、コンテナでのシークレット管理を簡素化します。(#2528, #3120)
  • web_host/web_root での OIDC リダイレクトの修正web_host が空の場合や web_root がサブパスに設定されている場合の OIDC ログイン後の 404 エラーを解決します。(#2681, #1524, #2532, #3121)
  • OIDC クレーム処理の修正username_claim が無視される、email クレームが認識されない、client_secret_file が不正なリクエストを生成する問題を解決します。(#1731, #2818, #3122)
  • LDAP クレーム式の修正 — LDAP マッピングでの壊れたテンプレート式(例:mail | {{ .username }}@domain.com<no value> に解決される)を修正します。(#3127)
  • LDAP ユーザー名割り当ての修正 — LDAP ユーザーがランダムに生成された文字列ではなく、実際の LDAP ユーザー名を取得するようにします。(#3688)
  • LDAP ローカル認証フォールバック — LDAP が有効な場合でもローカル管理者アカウントがログインできるようにし、LDAP サーバーがダウンした場合のロックアウトを防止します。(#1363)
  • LDAP デバッグログ — LDAP 認証失敗のトラブルシューティングを可能にする有用なログ出力を追加します。(#2932)
  • OIDC/LDAP ユーザーとローカルアカウントのリンク — 重複を作成せずに、既存のローカルアカウントを外部 ID プロバイダーに変換またはリンクできるようにします。(#3339)
  • OIDC プロバイダーログアウト — Semaphore からログアウトする際に IdP セッション(例:Keycloak)を終了し、適切なアカウント切り替えを可能にします。(#1496)

Pro

  • LDAP 認証情報のアクセスキーへの同期 — ログイン時に LDAP パスワードが変更された場合、オプションでアクセスキーのパスワードを自動更新し、Ansible 認証情報を同期状態に保ちます。(#3696)

Enterprise

  • OIDC グループからロールへのマッピング — OIDC クレーム(例:groups クレーム)に基づいて Semaphore ロールとプロジェクトメンバーシップを自動割り当てし、初回ログイン後の手動ユーザーセットアップを不要にします。(#1499, #2483)
  • LDAP グループからロールへのマッピング — Active Directory / LDAP グループを Semaphore ロールにマッピングし、グループメンバーシップによる管理者ロール割り当てを含みます。(#3226, #1316)
  • LDAP/OIDC 統合による完全な RBAC — 詳細なロールベースアクセス制御(グローバル管理者、プロジェクト管理者、プロジェクトユーザー、読み取り専用)を実装し、外部 ID プロバイダーグループからの自動ロール割り当てを行います。(#891)
  • プラガブル認証アーキテクチャ — 認証をプロバイダーインターフェースに抽象化し、複数の認証バックエンドをサポートし、新しいプロバイダーの追加を簡素化します。(#465, #1820)
  • ユーザー削除時の孤立データの修正 — ユーザーの削除時に project__user マッピングをクリーンアップし、チームビューのクラッシュを防止します。(#3514)

柔軟な通知システム

バージョン 2.19

Semaphore UI の現在の通知システムは config.json を通じてのみ設定され、限られたチャネルセット(メール、Telegram、Slack、MS Teams)をサポートし、プロジェクトごとのカスタマイズが最小限のグローバルレベルで動作しています。この機能は通知をゼロから再設計し、UI 管理型、拡張可能、プロジェクトおよびテンプレート単位での設定を可能にします。

Community

  • 拡張可能なチャネルアーキテクチャ — チャネルごとの実装を持つ通知チャネルの共通インターフェースを定義し、コアロジックを変更せずに新しいチャネルを容易に追加できるようにします。多くのプロバイダーを一度にカバーするために、ユニバーサル通知ライブラリ(例:nikoksr/notify)やゲートウェイ(例:Apprise)の採用を検討してください。(#2325, #1290)
  • UI 管理型の通知設定 — 通知設定を設定ファイルから Web UI に移行し、プロジェクトおよびテンプレート単位の粒度で設定でき、同じチャネルタイプの複数インスタンスをサポートします。(#3387, #1821, #3588)
  • テンプレートベースのメッセージカスタマイズ — データベースではなくディスク上のファイルとして保存されるユーザー定義のメッセージテンプレートをサポートします。
  • プロジェクトごとのチャネル選択 — プロジェクト設定を通じて、どの通知チャネルをアクティブにするかをプロジェクトごとに設定できるようにします。(#3588)
  • 送信 Webhook イベント — イベントタイプ(START、SUCCESS、FAILURE)を定義し、設定可能な URL、ヘッダー、HMAC 認証を使用してプロジェクトごとに Webhook テンプレートを作成できるようにします。(#1825, #2594, #3066)
  • 新しい通知チャネル — Discord (#2924)、Ntfy (#3383)、Google Chat (#1148)、Rocket.Chat (#1091)、Pushover (#2594) のサポートを追加します。
  • 「修復済み」通知 — GitLab CI の復旧アラートと同様に、失敗後の最初の成功実行時に通知を送信します。(#3380)
  • テンプレートごとの全通知無効化 — 既存の「成功通知を無効にする」チェックボックスに加えて、「すべての通知を無効にする」オプションを追加します。(#3724)
  • 成功時のメール送信 — 成功通知パスにメールを含めます(現在、成功時に通知されるのは Telegram/Slack/MS Teams のみです)。(#3503)
  • 通知内のタスク URL の修正 — すべてのチャネル(メール、Slack、MS Teams)が相対パスではなくスキームとホストを含む完全修飾タスク URL を受け取るようにします。(#2097, #2311, #3292)
  • メール配信の問題を修正 — SMTP ポート 465(暗黙的 TLS)サポート、TLS 前の認証順序、日付ヘッダーのフォーマットを解決します。(#2201, #2971, #3542, #3209)
  • Telegram スレッド/トピックサポートmessage_thread_id を使用して特定の Telegram グループスレッドに通知を送信できるようにします。プロジェクトおよびテンプレートごとに設定可能です。(#3493, #1456)
  • Slack テンプレートの改善 — Slack Workflow Builder との互換性のためにトップレベルフィールド(titletextcolor)を公開します。(#2607)
  • アラートプロキシサポート — システム全体のプロキシを必要とせずに、送信通知リクエスト用の HTTP プロキシを設定できるようにします。(#1484)

Pro

  • Pro 専用通知チャネル — Pro プランでのみ特定の通知チャネルをサポートします。
  • 長時間実行タスクのアラート — タスクが設定可能な時間しきい値を超えた場合に通知をトリガーします。(#1393)

Enterprise

  • 通知の監査ログ — 配信ステータス、タイムスタンプ、受信者詳細を含む、送信されたすべての通知の検索可能なログを維持します。エラーログを改善し、失敗時の受信者コンテキストを含めます。(#3410)
  • インシデント管理プラットフォームとの統合 — PagerDuty、Opsgenie、ServiceNow との、自動インシデント作成とライフサイクル追跡のためのネイティブ統合。
  • ロールベースの通知アクセス制御 — 組織のロールと権限に基づいて、通知ルールとチャネルを設定できるユーザーを制限します。

テンプレートごとの複数インベントリ

バージョン 2.19

Ansible CLI はインベントリを構成するための複数の -i 引数の受け渡しをネイティブにサポートしています(例:ansible-playbook -i common_vars.yml -i staging_hosts.yml)。Semaphore は現在、各タスクテンプレートを単一のインベントリに制限しているため、ユーザーはインベントリスクリプト、マージされたファイル、追加の環境変数などの回避策を強いられています。この機能はその制限を解除し、インベントリ管理に関するより広範な問題に対処します。

Community

  • マルチインベントリサポート — 単一のタスクテンプレートに複数のインベントリをアタッチし、Ansible に連続する -i 引数として渡せるようにします(例:ansible-playbook -i common_vars.yml -i staging_hosts.yml)。テンプレートごとに 1 つのインベントリという制限を解消します。(#2093)
  • オプションのインベントリフィールドansible.cfg で既にインベントリソースが指定されている場合、テンプレートのインベントリフィールドをオプションにします。(#1574)
  • URL/HTTP インベントリソース — リモート URL や API エンドポイントからのインベントリ取得をサポートします。ファイルシステムにアクセスできないホスト型/SaaS 環境に不可欠です。(#1924)
  • 実行時インベントリ選択 — 現在の自由テキストによる回避策に代わり、タスク起動時にドロップダウンでインベントリを選択できるようにします。(#1354)
  • スケジュールタスクのインベントリ永続化の修正 — スケジュールダイアログで選択したインベントリがテンプレートのデフォルトにフォールバックするのではなく、保存され実行時に使用されるようにします。(#3566, #3293)
  • プロジェクトのエクスポート/復元時にインベントリリポジトリリンクが失われる問題の修正 — インベントリとリポジトリの関連付けがプロジェクトエクスポート時に削除され、インポート時に復元されません。(#3369, #3177)
  • 動的インベントリへの環境変数の受け渡し — コンテナ/ホスト環境変数が動的インベントリスクリプトおよびプラグイン(例:Python スクリプト、microsoft.ad.ldap)で利用可能であることを確認します。(#2724, #2783)
  • git ベースのインベントリ認証の修正 — インベントリのリモートブランチ取得時にリポジトリの認証情報を使用し、未認証のアクセス試行を修正します。(#3539)
  • ホストごとの認証情報オーバーライド — インベントリで定義されたホストごとの ansible_user や接続変数をグローバルな --extra-vars でオーバーライドしないようにします。マルチユーザーインベントリパターンを可能にします。(#1464, #1621)
  • UI でのインベントリ内容の表示 — ファイルベースおよび動的インベントリの内容を UI に表示し、検査やデバッグに使用できるようにします。外部リポジトリのソースファイルへのリンクも含みます。(#3169, #1555, #3543)
  • タスクコンテキストでのインベントリ名の公開 — Playbook がどのインベントリがアクティブかを参照できるように、semaphore_vars または環境変数としてインベントリ名を利用可能にします。(#1580)

Pro

  • インベントリとランナーのアフィニティ — インベントリホストをランナータグに関連付け、ターゲットホストへのネットワークアクセスを持つランナーにのみタスクがディスパッチされるようにし、マルチネットワーク環境での失敗を回避します。(#3322)
  • インベントリごとの複数 SSH キー — 各ホストが固有の SSH キーを使用するフリートのために、単一のインベントリに複数のキーストアエントリを割り当てられるようにします。(#3336)
  • ハイパーバイザーインベントリ統合 — ハイパーバイザー API(VMware、Proxmox)とのネイティブ統合により、動的インベントリを自動生成および更新します。(#2709)
  • ホストグループ管理 API — インベントリペイロード全体を書き換えることなく、インベントリグループからホストを追加/削除するための API を提供します。(#1560)

Enterprise

  • テンプレートごとの許可インベントリの制限 — テンプレートで「インベントリを確認する」が有効な場合、選択可能なインベントリを管理者が定義した許可リストに制限し、誤った環境へのターゲット指定を防止します。(#3587)
  • 中央ホストレジストリ — 共有ホスト管理レイヤーを提供し、ホストの変更(例:ホスト名や IP の更新)がそのホストを参照するすべてのインベントリに手動編集なしで伝播されるようにします。(#564)
  • ホストファクトの保存と可視化 — ホストごとに Ansible ファクトを保存し、タスク実行前後の状態を差分と履歴機能付きで表示します。(#930)

テンプレートごとの複数変数グループ

バージョン 2.20

Semaphore は現在、各タスクテンプレートに単一の変数グループ(環境)のアタッチのみを許可しています。これにより、複数のテンプレートが共通の設定を共有する場合にグループ間で変数を複製するか、すべてを含むモノリシックな変数グループを作成することを余儀なくされています。この機能はテンプレートごとに複数の変数グループを構成可能にし、変数処理における多数のバグ(シリアライゼーション、優先順位、伝播、サーベイ変数のライフサイクル)を修正します。

Community

  • マルチ環境構成 — 単一のタスクテンプレートに複数の変数グループをアタッチし、共有変数セット(例:共通デフォルト、リージョンごとのオーバーライド)をテンプレート間で構成・再利用できるようにします。(#2612)
  • 変数グループのクローン — 少数の値のみが異なる環境を、すべてのフィールドを一から再作成せずにセットアップできるクローンアクションを追加します。(#3295)
  • 再利用可能なサーベイ変数セット — サーベイ変数をタスクテンプレートから独立したスタンドアロンの割り当て可能なオブジェクトに分離し、テンプレートごとの重複を回避します。(#2212)
  • extra-vars JSON シリアライゼーションの修正 — 複雑な extra-vars を Go マップ文字列ではなく適切な JSON としてシリアライズし、Terraform/OpenTofu での jsondecode 失敗を修正します。(#3748, #1644, #2619)
  • サーベイ変数の優先順位の修正 — 環境の extra-vars とサーベイの両方に同じ変数名が存在する場合のサイレントオーバーライドを解決します。明確な優先順位を定義するか、エラーを発生させます。(#3108)
  • 空/オプションのサーベイ変数処理の修正 — オプションのサーベイ変数が一貫して省略されるか空文字列として渡されるようにし、ランダムに混在しないようにします。(#2182)
  • スケジュールタスクのサーベイデフォルト値 — タスクをスケジュールする際にサーベイ変数のデフォルト値を指定できるようにし、自動実行が必須プロンプトで失敗しないようにします。(#2244)
  • bash タスクのサーベイ変数を環境変数として渡す — シェルタイプのタスクでは、サーベイ変数を CLI 引数ではなく OS 環境変数として公開します。(#2433)
  • Tofu/Terraform init 時にサーベイ変数を渡すplan/apply だけでなく init フェーズにもサーベイ変数を転送し、変数駆動のバックエンド設定をサポートします。(#2554)
  • 追加 CLI 引数での Jinja2 参照 — テンプレート構文(例:-l {{ hosts }})を使用して、追加 CLI 引数フィールドでサーベイ変数と環境変数を参照できるようにします。(#1053)
  • 実行準備時の環境変数 — タスク実行時だけでなく、準備フェーズ(例:galaxy install、Git ロール認証)でも環境変数を利用可能にします。(#3178)
  • リポジトリファイルからの extra-vars 読み込み — UI でのインライン入力ではなく、リポジトリ内の JSON/YAML ファイルから extra-vars を読み込むことをサポートし、GitOps ワークフローを可能にします。(#2343)
  • API 経由での実行時環境オーバーライド — API でタスクを起動する際に異なる変数グループを渡せるようにします。(#1367, #3291)

Pro

  • 複雑なサーベイ変数タイプ — 構造化 JSON 配列として渡される動的なオブジェクトリスト型サーベイ変数(例:VLAN 設定)をサポートします。(#3557)
  • スケジュールごとの変数オーバーライド — スケジュールされたジョブにカスタム変数値をアタッチし、同じテンプレートを異なるスケジュールで異なるパラメータで実行できるようにします。(#2378)
  • ユーザーコンテキストからの動的変数値 — ログインユーザーの ID で変数を自動入力します(例:{{ current_user }})。(#2524, #909)

Enterprise

  • 変数のプライベートマーク — 変数に「プライベート」フラグを追加し、値が実行ログ、タスク履歴、API レスポンスに表示されないようにします。(#2887)
  • 環境変数の可視性制限 — 変数グループの内容を管理者ロールのみに制限し、共有プロジェクトテンプレートでの認証情報の露出を防止します。(#1126)
  • ビルドレベルの変数スナップショット — タスク実行時に変数値をスナップショットし、再実行時に現在の値ではなく元の値を使用するようにします。(#1097)

ユーザー所有シークレット

バージョン 2.20

Semaphore のキーストアは現在、すべてのプロジェクトメンバー間で共有されています。プロジェクトにアクセスできるユーザーは、保存されたすべての認証情報を使用(場合によっては閲覧)できます。これはチームメンバーが自分の認証情報にのみアクセスすべきマルチユーザー環境でセキュリティ上の懸念を生じさせます。さらに、キーストアには暗号化、シークレットの更新、参照整合性に関する複数のバグがあり、外部シークレット管理システムとの統合も欠如しています。

Community

  • パーソナルキーストア — ユーザーごとのキーストアを提供し、個人の認証情報(SSH キー、sudo パスワード)を他のプロジェクトメンバーから分離し、プロジェクトレベルのキーストアを通じて共有されないようにします。(#1483, #1373)
  • シークレット更新動作の修正 — シークレット環境変数の編集が成功したように見えるが、実際には値が永続化されない問題を解決します。(#2546)
  • プロセスリストからのシークレット非表示 — OS プロセスリストに表示されるコマンドライン引数経由でシークレット extra-vars を渡すのを止め、セキュアなメカニズム(例:一時ファイル、stdin)を使用します。(#3219)
  • キーストアでの SSH 証明書サポート — 証明書ベースの認証ワークフロー用に、SSH キーと一緒に SSH 証明書を保存できるようにします。(#3171)
  • SSH 公開鍵の表示 — 利便性のために、キーストア UI に保存された SSH キーの公開鍵部分を表示します。(#1643)
  • Docker シークレットサポート_FILE 環境変数パターン(例:POSTGRES_PASSWORD_FILE)をサポートし、環境変数経由で渡す代わりに Docker/Kubernetes シークレットをマウントして読み取れるようにします。(#1268)
  • Docker での暗号化キー処理の修正SEMAPHORE_ACCESS_KEY_ENCRYPTION 環境変数が尊重され、コンテナ再起動時にランダムなキーで上書きされないようにします。(#2228, #3068, #3204)
  • キーストアのリネームで参照が壊れる問題の修正 — キーストアエントリのリネームにより、リンクされたすべてのインベントリとテンプレートが壊れる問題を解決します。(#3188)
  • Vault パスワード API の修正 — REST API 経由での Ansible Vault パスワードの設定と更新を、重複キー制約エラーなしで行えるようにします。(#3413, #2773)

Pro

  • 外部シークレットストア統合 — Semaphore のデータベースに保存する代わりに、実行時に HashiCorp Vault、Azure Key Vault、AWS KMS、または Bitwarden からシークレットを取得します。(#2248, #658)

Enterprise

  • グローバルアクセスキー — キーストアエントリを重複なしでプロジェクト間で共有し、一元管理とプロジェクト横断リンクを実現します。(#110)
  • シークレットアクセス監査証跡 — コンプライアンスとフォレンジックのために、キーストアエントリとシークレット変数のすべてのアクセスと使用をログに記録します。

ワークフロー

バージョン 2.21

Semaphore は現在、各タスクテンプレートを独立したユニットとして扱っています — 複数のテンプレートをマルチステップの実行パイプラインに連鎖させる組み込みの方法がありません。この機能はワークフローを導入します — 条件分岐、ステップ間の変数受け渡し、オプションの人間による承認ゲートを備えた有向非巡回グラフ(DAG)のタスクテンプレートです。設計は AWX Workflow Job Templates、Rundeck ジョブワークフロー、Jenkins/GitLab CI パイプラインの概念を参考にしています。

Community

  • ワークフローテンプレート — 条件(on_successon_failurealways)付きの有向辺で接続されたタスクテンプレートノードの DAG を定義する新しいトップレベルエンティティを導入し、プロジェクト内でマルチステップの自動化パイプラインを可能にします。(#3182, #2334, #1383, #836)
  • ワークフロー実行エンジン — トポロジカル順序でワークフローノードを実行し、辺の条件を尊重して独立したブランチを並列実行し、複数の親を持つノードには ALL 収束を適用します。(#2281, #3088)
  • ワークフロー実行ダッシュボード — ノードごとのステータス(保留中、実行中、成功、失敗、スキップ)を示す DAG グラフ、クリック可能なノードログ、全体的なタイミングを表示するワークフロー実行の統合ビューを提供します。
  • ノード間の変数受け渡し — タスクテンプレートが出力変数を生成(既知のファイルまたは Ansible set_stats 経由)し、下流のノードに自動的にエクストラ変数として注入できるようにします。(#3182)
  • ワークフローのスケジューリングと API トリガー — ワークフローの cron スケジューリング、API トリガー実行、webhook トリガーをサポートし、ワークフローレベルでのオプションのサーベイ変数を備えます。(#3088)

Pro

  • ビジュアルワークフローエディター — リアルタイム DAG 検証、ノード配置、辺上の条件セレクターを備えた、UI でワークフローを設計するためのドラッグ&ドロップグラフィカルエディター。
  • ノードごとのオーバーライド — ワークフローノードレベルでテンプレートのインベントリ、認証情報、変数グループ、または CLI 引数をオーバーライドし、単一のワークフロー内で異なる環境間で同じテンプレートの再利用を可能にします。
  • 承認ゲート — 設定可能なタイムアウト、承認者への通知、UI または API からの承認/拒否アクションを備え、指定されたポイントでワークフロー実行を一時停止して人間の承認を待ちます。

Enterprise

  • ワークフロー RBAC — ワークフローの作成、編集、実行、承認のための細かいアクセス権限、ロールベースの承認ゲート割り当て、監査ログを備えます。
  • クロスプロジェクトワークフロー — ワークフロー内で他のプロジェクトのタスクテンプレートを参照し、インフラ、アプリケーション、モニタリングプロジェクトにまたがる組織全体の自動化パイプラインを可能にします。
  • ワークフローのバージョニングとロールバック — ワークフロー定義のバージョン履歴を diff 付きで維持し、以前のバージョンを復元し、各実行で使用されたバージョンを記録します。