ローカル
ランナーホストにインストールされたツールと依存関係を使い、ホスト上で直接実行します。
プロジェクトランナーで、別のネットワークへのアクセス、実行能力の追加、ジョブに必要なツールの提供を行います。タスク履歴と結果は Semaphore に保持します。
ジョブによって必要なネットワークアクセス、ツール、実行能力は異なります。すべてをアプリケーションサーバーで実行すると、同じ制約を共有することになります。
各ジョブの実行場所を選び、ツールを準備し、Semaphore サーバーとは独立して実行能力を追加します。
プロジェクトランナーを作成し、名前を付けて有効にします。タグはここで追加することも、後から更新することもできます。
実行マシンに Semaphore をインストールし、生成された設定でランナーモードを起動します。ランナーが Online と表示されることを確認してください。
場所、環境、ワークロードに応じてランナーにタグを付けます。1 つのランナーは複数のタグを持てます。
タスクテンプレートのランナータグに、一致する値を設定します。新しいタスクは、そのタグを持つオンラインのランナーを待ちます。
ランナーはジョブを実行する場所を決めます。エグゼキューターは、ホスト環境を使うか、コンテナー内で開始するかを決めます。
ランナーホストにインストールされたツールと依存関係を使い、ホスト上で直接実行します。
Pro では、ジョブをコンテナーで実行し、タスクテンプレートごとにエグゼキューターのイメージを選べます。
Enterprise では、必要なイメージと依存関係を備えた Kubernetes Pod でジョブを実行できます。
対象が存在するリージョンやネットワークで自動化を実行します。ランナーは、プライベートサブネットへのアクセス、管理対象システムまでの距離の短縮、チーム専用の実行能力を提供できます。ネットワーク上の配置、ランナータグ、エグゼキューターは、それぞれ設定の異なる部分を担います。
ランナーは Semaphore サーバーに接続し、ポーリングします。サーバーからランナーへの受信接続を開始する必要はありません。ランナーが Semaphore と、タスクに必要な対象やソースへ接続できるなら、NAT の背後やプライベートサブネットの拠点で役立ちます。
グローバルランナーは複数のプロジェクトで利用でき、プロジェクトランナーは 1 つのプロジェクトに属します。対応するタグによって、テンプレートの要件とランナーの能力や場所を関連付けます。タグ要件のないタスクには既定ランナーの設定が適用されます。適切なランナーが利用できない場合、タスクは黙って別の場所で実行されるのではなく、待機したままになることがあります。
ローカル実行は、ランナーホストのプロセスコンテキストで動作し、その権限を使います。対応する Docker と Kubernetes のエグゼキューターは、コンテナーまたは Pod の境界を設けますが、それぞれ設定とエディションの要件があります。実際の境界はマウント、ネットワーク、特権、イメージで決まります。ランナーという名称だけで分離が保証されるわけではありません。
追加のランナーにより、すべてのタスクを Web アプリケーションホストで実行せずに、実行能力や到達範囲を増やせます。同時タスク設定とポーリングは動作特性に影響します。高度な単発実行では、登録、割り当てフック、ジョブ終了後に停止するランナーを組み合わせることもできますが、そのライフサイクルを支えるデプロイ自動化が必要です。
閉じたネットワーク内で稼働する必要がある場合は、Enterprise のオフラインライセンスを使います。Semaphore とランナーをその環境内に置き、公開ネットワークへのアクセスなしで必要な Git リポジトリ、エグゼキューターのイメージ、ツールの依存関係を提供してください。
ローカル実行はランナーホストのプロセス権限を使います。ジョブ専用のコンテナーや Pod が必要な場合は、タスクに合うイメージ、マウント、ネットワーク設定を備えた Docker または Kubernetes のエグゼキューターを使ってください。
タスクには、テンプレートが参照する認証情報と設定が必要です。Key Store の環境変数とファイルソースは、値が実行に使われる前に Semaphore サーバー上で解決されます。
グローバルランナーはインスタンス全体で使うために登録され、プロジェクトランナーは特定のプロジェクトに属します。グローバルな分散実行はすべてのプランで利用でき、プロジェクト単位の範囲と関連する振り分け機能は、料金表に示すとおり Pro と Enterprise に含まれます。運用の責任範囲と環境へのアクセスに応じて範囲を選んでください。プロジェクト専用のランナーを使えば実行場所を意識して指定できますが、実行プロセスが何にアクセスできるかは、そのランタイム設定で決まります。
ランナーは Semaphore に接続し、処理をポーリングして通信を開始します。これにより、サーバーからランナーへの受信接続なしに、NAT の背後やプライベートネットワーク内に配置できます。それでもランナーは、Semaphore エンドポイント、タスクが使うリポジトリ、パッケージソース、外部サービス、対象へ接続する必要があります。それぞれの経路を確認してください。外向きポーリングによって、ほかのネットワーク要件がなくなるわけではありません。
対応するランナータグ、テンプレートの要件、既定ランナーの設定を使い、適切な実行環境に作業を割り当てます。タグには意味のある能力や場所の名前を付け、可用性と能力を把握できるようにします。適切なランナーの準備ができていなければ、タスクは待機することがあります。同じ経路を本番変更に使う前に、影響のない操作で選択した経路をテストし、タスク詳細で実行ランナーを確認してください。
それだけでは分離されません。ローカルエグゼキューターは、ランナーホストのプロセスコンテキストで、その環境が提供するアクセスを使って動作します。Docker や Kubernetes での実行では別の境界が生まれますが、マウント、特権、ネットワーク、イメージの内容は引き続き重要です。実行場所と実行方式は別々に判断してください。ランナーやコンテナーという名称を完全な安全性の保証と考えず、必要な依存関係を準備し、ホストへのアクセスを確認します。
選択した実行経路で、各ジョブが必要とするランタイムを準備します。対応するエグゼキューターイメージの設定を使えば、共有ホスト上のすべてのジョブを変更せずに、特定の Ansible、Terraform、Python などの依存関係を明示できます。該当するエグゼキューターの選択肢について、インストール済みのバージョンとエディションを確認してください。そのうえで、管理者の対話セッションだけでなく、実際の実行環境内でリポジトリアクセス、パッケージ、対象への接続をテストします。
ランナーの追加は、タスクの実行能力を増やしたり実行場所を変えたりするもので、アプリケーションの制御プレーンを高可用にするものではありません。アプリケーションの HA では、文書化された共有データベース、Redis、負荷分散アーキテクチャのもとで複数の Semaphore ノードを連携させます。両者は補完できますが、解決する問題は異なります。どこを拡張するか決める前に、ボトルネックが実行能力、ネットワークへの到達性、UI と API へのアクセスのどれかを判断してください。
利用可能なランナーがテンプレートの振り分け要件に一致するまで、タスクは待機状態にとどまります。ランナーのタグ、有効フラグ、最近の接続状態を確認し、その後で実行能力を確認してください。タグは選択ルールであるため、タグのないランナーや異なるタグのランナーがそのジョブを自動的に引き受けることはありません。
はい。ランナーが Pro の Docker エグゼキューターまたは Enterprise の Kubernetes エグゼキューターを使う場合、テンプレートで既定のジョブイメージを上書きできます。ジョブごとに、自動化に必要なツールチェーンを使えます。必要なアプリケーションと依存関係をイメージに準備してください。この項目はローカルエグゼキューターの動作を変えません。テンプレートの実行設定を見る。