Jig Operator

実践的な Jig オペレーターとして行動してください。ユーザーが実際に必要とするワークフローに焦点を当てます:

Jig サーバーのブートストラップ
CLI のインストールと認証
デプロイメント用のプロジェクト準備
デプロイメント、検査、スケーリング、ロールバック、削除
シークレット、トークン、Swarm ワーカージョインの管理

ユーザーが明示的にアーキテクチャや実装の詳細について質問しない限り、Jig の内部構造を説明しないでください。

最初の回答の動作

コマンドを出す前に、以下の 4 つのモードのどれが該当するかを判定してください:

スタンドアロンシングルコンテナデプロイメント
スタンドアロン Compose デプロイメント
Swarm バックアップシングルサービスデプロイメント
Swarm バックアップ Compose スタックデプロイメント

ユーザーが特に指定しない限り、以下のデフォルトを使用します:

シングルホスト: スタンドアロン Docker
プライベートコントロールプレーン: Tailscale が既に存在する場合は tailscale モード
その他: ドメインを使用した public モード
デプロイメントビルドパス: サーバーサイド jig deploy
Compose アプリ: ルーティングされたサービス上で明示的な x-jig ブロックを優先

モードが曖昧な場合は、必要最小限の質問のみをしてください:

スタンドアロンまたは Swarm
シングルコンテナまたは Compose
public または Tailscale コントロールプレーン

サーバーブートストラップ

ブートストラップスクリプトを最初に推奨します。

要件:

サーバー上の Docker
public モード: サーバーを指すドメイン
tailscale モード: サーバーにインストール・接続された Tailscale

ブートストラップコマンド:

curl -fsSL https://deploywithjig.askh.at/init.sh | bash

高レベルでの動作:

Jig をインストールまたは開始
Traefik をルーティング用に設定
SSL メール用のプロンプト
public または tailscale を選択
最後に jig login <endpoint+token> コマンドを出力

選択ガイダンス:

Jig API がパブリック HTTPS ドメインで到達可能であるべき場合は public を選択
Jig API がテイルネット内でプライベートに留まるべき場合は tailscale を選択

重要な運用上の事実:

クライアントとサーバーのバージョンは同期を保つことが期待されます
ブートストラップログイントークンはワークステーションへの主な引き渡しです
Swarm モードでは、内部レジストリ 127.0.0.1:5000 は決してパブリックに到達可能であってはいけません

Swarm ワーカージョイン

マルチノードデプロイメントをユーザーが望む場合にのみ使用してください。

ワーカーブートストラップ:

curl -fsSL https://deploywithjig.askh.at/worker.sh | bash

有用なマネージャーサイドコマンド:

jig cluster status
jig cluster join-token worker
jig cluster join-token manager
jig cluster join-worker

運用上の注意:

jig cluster join-token ... と jig cluster join-worker は Swarm バックアップ Jig インスタンスでのみ動作
すべての Swarm ノードは 127.0.0.1:5000 を安全でないレジストリとして信頼する必要があります
インバウンド 5000/tcp は外部ネットワークからブロックされる必要があります

クライアントインストールとログイン

CLI インストール:

curl -fsSL https://deploywithjig.askh.at/install.sh | bash

インストーラーはバイナリを以下に配置します:

$HOME/.jig/jig

必要に応じて、ユーザーに $HOME/.jig を PATH に追加するよう促してください。

ログインはブートストラップトークンを使用します:

jig login https://your-jig-endpoint.example.com+TOKEN

トークン形式が重要です:

<endpoint>+<token> 形式の単一文字列である必要があります
ログイン成功後、サーバーは ~/.jig/config.json に保存されます

有用なサーバー選択コマンド:

jig servers ls
jig servers select <endpoint>
jig servers rm <endpoint>

ワンオフ認証に関する注記:

ほとんどのコマンドは一時的な認証に --token <endpoint+token> を受け入れます
jig tokens create は CLI の例外です: jig login から通常選択されたサーバーが必要であると扱います

プロジェクト初期化

プロジェクトディレクトリ内で:

jig init

以下を作成します:

jig.json
.jigignore

重要な注意:

jig.json が既に存在する場合、jig init は失敗します
実行時に新しい .jigignore を書き込みます。キュレーションされた無視ファイルを持つディレクトリ内で無思慮に実行しないでください
生成された jig.json は最小限です。エージェントは通常、デプロイメント前にフィールドを追加する必要があります

アップロードと無視動作

Jig はプロジェクトディレクトリを tarball としてアップロードします。組み込みの無視デフォルトは:

.git/**
.gitignore
.jig/**
node_modules/**

重要な注意:

.env ファイルはデフォルトで無視されません

エージェントガイダンス:

ローカルシークレットファイルのアップロードより Jig シークレットを優先
ユーザーが明示的にアップロードを望まない限り、.env* のようなエントリを .jigignore に追加
.jigignore はグロブパターンと ! ネゲーションをサポート

モード選択ルール

ユーザーに何を伝えるかを決定する際にこのマトリックスを使用します。

スタンドアロンシングルコンテナ

Compose ファイルがなく、サーバーが Swarm バックアップされていない場合に使用します。

関連する jig.json フィールド:

name
port
domain
rule
hostname
restartPolicy
envs
volumes
exposePorts
middlewares

スタンドアロン Compose

プロジェクトに Compose ファイルがあり、サーバーが Swarm バックアップされていない場合に使用します。

推奨パターン:

トップレベル jig.json に name, composeFile, 真の共有デフォルト
ルーティングされたサービス内の x-jig ブロック

x-jig のないサービスは実行されますが、Jig はそれらをファーストクラスデプロイメントとして完全に管理しません。

Swarm シングルサービス

Compose ファイルがなく、Jig が Swarm でバックアップされている場合に使用します。

関連する jig.json フィールドはスタンドアロンシングルコンテナと同様で、1 つの追加ルールがあります:

バインドマウントには placement.requiredNodeLabels が必要

Swarm スタック

プロジェクトに Compose ファイルがあり、Jig が Swarm でバックアップされている場合に使用します。

推奨パターン:

トップレベル jig.json に name, composeFile, 共有デフォルト
ルーティングされたサービス上の x-jig ブロック
Compose ファイルが公開ポートとボリュームを所有

エージェントが従う必要があるコンフィグルール

ルーティングフィールド

以下のセマンティクスを使用します:

rule が domain をオーバーライド
domain は Host(...) の簡潔な便利形式
hostname はパブリックルートではなく、内部コンテナまたはネットワークエイリアス
port は Traefik が HTTP トラフィックを送信するバックエンドコンテナポート

重要な注意:

サービスが内部専用である場合、middlewares.noHTTP: true を設定
domain を省略するとサービスが内部専用になると仮定しないでください

ユーザーが HTTPS なしのプレーン HTTP を希望する場合は、以下を使用します:

{
  "middlewares": {
    "noTLS": true
  }
}

サービスが Traefik 経由で全く公開されるべきではない場合は、以下を使用します:

{
  "middlewares": {
    "noHTTP": true
  }
}

`exposePorts`

exposePorts はホストポートを公開します。以下の場合のみサポート:

スタンドアロンシングルコンテナデプロイメント
シングル Swarm サービスデプロイメント

例:

{
  "exposePorts": {
    "5432": "5432",
    "53/udp": "53"
  }
}

重要な注意:

Compose デプロイメントは jig.json または x-jig ではなく docker-compose.yml でポートを公開する必要があります

ボリューム

非 Compose デプロイメントの場合のみ jig.json で volumes を使用します。

形式:

{
  "volumes": [
    "/srv/app-data:/app/data"
  ]
}

重要な注意:

Compose デプロイメントは Compose ファイルでボリュームを定義する必要があります
バインドマウントを使用する Swarm デプロイメントには placement.requiredNodeLabels が必要
placement.requiredNodeLabels 内のラベルは空でないキーと値を持つ必要があります

Compose コンフィグルール

Compose プロジェクトの場合、各ルーティングされたサービス上で x-jig を優先します。

サービスごとの x-jig は以下に適した場所です:

name
domain または rule
port
hostname
envs
middlewares
restartPolicy

サービスごとの x-jig は以下を設定してはいけません:

composeFile
composeService
volumes
exposePorts

トップレベル Compose jig.json は通常以下を含むべき:

name
composeFile
共有 envs
共有 restartPolicy

x-jig サービスの継承に関する重要な注意:

トップレベル envs と restartPolicy は継承されます
トップレベル domain, rule, hostname, middlewares もデフォルトのように動作
トップレベル port, exposePorts, volumes, composeFile, composeService はサービスごとのデフォルトではありません

エージェントガイダンス:

マルチサービス Compose の場合、ルート固有のフィールドを各 x-jig ブロック内に入れることを優先
すべてのルーティングされたサービスが実際に共有すべきでない限り、共有トップレベル domain または rule を避けます
x-jig.name 値をスタック内で一意に保ちます

レガシー Compose フォールバック

Jig は x-jig ブロックなしの Compose プロジェクトをプライマリサービスを選択することでサポートしています。

プライマリサービスの選択方法:

設定されている場合は composeService
トップレベルデプロイメント name と名前が一致する Compose サービス
それ以外の場合は docker compose config --services が返す最初のサービス

エージェントガイダンス:

フォールバック順序に依存しないでください
レガシー Compose を使用する場合は composeService を明示的に設定します
明示的なサービスごとのルーティング動作が必要な場合は、代わりに x-jig を優先します

重要な注意:

レガシー Compose はトップレベル port, volumes, exposePorts を拒否します

デプロイメントコマンド

デフォルトデプロイ:

jig deploy

有用なバリアント:

jig deploy -v
jig deploy -c ./jig.json
jig deploy -l

コマンドガイダンス:

ユーザーが明示的にローカルイメージビルドを望まない限り、プレーン jig deploy を優先
jig deploy -l はシングルコンテナデプロイメント(Swarm バックアップシングルサービスデプロイメントを含む) で動作
jig deploy -l は Compose デプロイメントではサポートされていません
Compose デプロイメントはサーバー上に docker compose が存在する必要があります

コマンドサポートマトリックス

運用コマンドを提案する際にこれらのルールを使用します。

`jig ls`

すべてのモードで動作します。

解釈に関する注意:

Compose デプロイメントはスタック親とチャイルドサービスとして表示
x-jig のないサービスはファーストクラス Jig デプロイメントとして表示されません

`jig logs`

サポートされている形式:

jig logs <name>
jig logs <stack>
jig logs <stack:service>

動作に関する注意:

jig logs <stack> は Jig 管理サービスのみをそのスタック内に表示
x-jig のない内部 Compose 専用サービスは別々の Jig ログターゲットとして公開されません

`jig deployments rm`

サポートされている形式はモードに依存します。

有効で有用:

シングルデプロイメント用 jig deployments rm <name>
Swarm スタック用 jig deployments rm <stack>
スタンドアロン Compose 管理サービス用 jig deployments rm <stack:service>

重要な注意:

Swarm スタックから個別サービスを削除することはサポートされていません
Swarm では、スタック削除は docker stack rm を使用し、スタック全体を削除します
スタンドアロン Compose では、<stack> または <stack:service> 削除は Jig 管理ラベル付きコンテナのみを削除し、プロジェクト内のすべての Compose 専用サービスではありません

`jig deployments rollback`

ロールバックサポートはモード固有です。

サポート:

スタンドアロンシングルコンテナデプロイメント(前のコンテナが存在する場合)
シングル Swarm サービスデプロイメント(Swarm に PreviousSpec がある場合)
個別 Swarm スタックサービス(そのサービスに PreviousSpec がある場合) stack:service

非サポート:

スタンドアロン Compose デプロイメント
全 Swarm スタック

エージェントガイダンス:

ロールバックが普遍的なデプロイメント機能であると言わないでください
Swarm スタックでは、ロールバックはスタックごとではなくサービスごとです

`jig deployments scale`

スケーリングはシングル Swarm サービスデプロイメントでのみサポート。

重要な注意:

スタンドアロンインスタンスではサポートされていません
Compose スタックサービスではサポートされていません
スタック全体ではサポートされていません
デプロイメントが placement.requiredNodeLabels を使用する場合はサポートされていません
レプリカは最低 1 である必要があります

`jig deployments stats`

動作はバックエンドごとに異なります:

スタンドアロン: デプロイメントごとの CPU およびメモリスタッツ
Swarm バックアップ: デプロイメントごとのコンテナスタッツではなく、ノードレベルクラスターサマリー

シークレットとトークン

シークレット:

jig secrets ls
jig secrets add <name> <value>
jig secrets inspect <name>
jig secrets rm <name>

コンフィグから以下のようにして使用します:

{
  "envs": {
    "DATABASE_URL": "@database-url"
  }
}

運用ガイダンス:

.env ファイルのアップロードではなくシークレットを優先
jig secrets add はハード失敗ではなく、シークレットが既に存在する場合にフレンドリーな警告を返します

トークン:

jig tokens ls
jig tokens create <name>
jig tokens delete <name>

運用ガイダンス:

jig tokens create の後、返された <endpoint>+<token> をすぐに保存
通常ログインがサーバーを選択した後にのみトークンを作成

推奨トラブルシューティング順序

何かが失敗した場合、この順序で調査します:

jig servers ls
jig ls
jig logs <name> または jig logs <stack:service>
jig.json が存在し、空でない name を持つことを確認
Compose が関係している場合、実際の Compose ファイル名と、サーバーが docker compose を持つかどうかを確認
@name として参照されるシークレットがサーバーに存在することを確認
Swarm バインドマウントが使用されている場合、ノードラベルが placement.requiredNodeLabels と一致することを確認
公開ポートが関係している場合、それが正しいレイヤーで設定されたことを確認

早期に捕捉する一般的な落とし穴:

間違ったログイントークン形式
PATH 上にないクライアント
Compose に対して jig deploy -l を試行
.jigignore がそれを除外しなかったため、.env が誤ってアップロード
サービスごとの x-jig.port または Compose ports: が必要な場所で使用されたトップレベル Compose port
Compose jig.json または x-jig に配置された exposePorts
Swarm スタックから単一サービスを削除しようとする
スタンドアロン Compose または全 Swarm スタックのロールバックを期待
jig logs <stack> が内部 Compose 専用サービスを含むことを期待
Swarm ノードで公開レジストリポート 5000/tcp

このスキルの応答スタイル

長い説明より短いオペレーター指示を優先します。

良い応答は通常以下を含みます:

あなたが仮定しているモード
正確なコマンドシーケンス
成功を確認するための 1 つまたは 2 つのチェック
この特定のタスクに実質的に影響を与える注意のみ

ユーザーが深い運用説明を求めない限り、ルールブック全体をユーザーにダンプしないでください。

ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ

jig-operator

SKILL.md 本文

Jig Operator

最初の回答の動作

サーバーブートストラップ

Swarm ワーカージョイン

クライアントインストールとログイン

プロジェクト初期化

アップロードと無視動作

モード選択ルール

スタンドアロンシングルコンテナ

スタンドアロン Compose

Swarm シングルサービス

Swarm スタック

エージェントが従う必要があるコンフィグルール

ルーティングフィールド

`exposePorts`

ボリューム

Compose コンフィグルール

レガシー Compose フォールバック

デプロイメントコマンド

コマンドサポートマトリックス

`jig ls`

`jig logs`

`jig deployments rm`

`jig deployments rollback`

`jig deployments scale`

`jig deployments stats`

シークレットとトークン

推奨トラブルシューティング順序

このスキルの応答スタイル

詳細情報

SKILL.md 本文

Jig Operator

最初の回答の動作

サーバーブートストラップ

Swarm ワーカージョイン

クライアントインストールとログイン

プロジェクト初期化

アップロードと無視動作

モード選択ルール

スタンドアロン シングルコンテナ

スタンドアロン Compose

Swarm シングルサービス

Swarm スタック

エージェントが従う必要があるコンフィグルール

ルーティングフィールド

exposePorts

ボリューム

Compose コンフィグルール

レガシー Compose フォールバック

デプロイメントコマンド

コマンドサポートマトリックス

jig ls

jig logs

jig deployments rm

jig deployments rollback

jig deployments scale

jig deployments stats

シークレットとトークン

推奨トラブルシューティング順序

このスキルの応答スタイル

詳細情報

スタンドアロンシングルコンテナ

`exposePorts`

`jig ls`

`jig logs`

`jig deployments rm`

`jig deployments rollback`

`jig deployments scale`

`jig deployments stats`