19分で読了

Docker インスタンス管理ガイド

Docker インスタンスは、GIIP エージェントをリモートPC/サーバーにコンテナとして展開し、GIIP Web上で生成・参照・廃棄できる管理者機能です。インスタンストークンを対象PCに伝えてコンテナを起動すると、そのPCがGIIPエージェント（1分ごとのポーリング）と slack-bot（オプション）で動作し始めます。

🏢 Docker インスタンス管理ページへ →

📋 概要

Docker インスタンス管理ページでは、giip-fde-agent Docker コンテナをリモートPC/サーバーに展開するためのインスタンスを作成し、管理します。インスタンス作成時、GIIPサーバーがAES-256-GCMで認証情報を暗号化して保存し、トークンを1回だけ表示します。

⚠️ この度は管理者専用です。 アクセスするには管理者レベル uLevel >= 70 が必要です。それ未満のユーザーはホームにリダイレクトされます。

🔍 画面構成

1. ヘッダー

ページタイトル: "Docker インスタンス管理"
+ Create Docker instance ボタン: 新規インスタンス作成モーダルを開きます。

2. インスタンス一覧テーブル

カラム	説明
Label	インスタンス名（未設定の場合は `#<diSn>`）
LSSN	事前登録されたlsvrのシリアル番号。作成直後のトークン表示エリアとこの一覧に表示されます。クリックでlsvrdetailに移動
Created	作成日時
Last fetched	コンテナがトークンで最後にenvを受け取った時刻。リアルタイム生存確認ではなく「最後の起動時刻」に近い
Status	Active（緑）または Revoked（赤）バッジ。所有権の不一致で CQE ブートストラップが実行されない可能性がある行にはバッジの横に警告アイコン（⚠️）が付きます — ホバーで説明を表示、クリックでその lssn の実行リスト（cqelsvrRunList）へ移動します（giip 3062）
Actions	Revoke ボタン — トークンを無効化（実行中のコンテナは停止しない）

⚠️ Last fetched が - の場合: コンテナがまだ一度も起動していない状態です。手順 ①（手動）または ②（Provision now）をまだ実行していません。

🛠️ インスタンスの作成方法

+ Create Docker instance ボタンをクリックします。
必須フィールド3つを入力します。
- GIIP_LOGIN_ID: GIIP ログインアカウント（例: user@example.com）
- GIIP_SK: GIIP シークレットキー（パスワードとは別）
- GIIP_CSN: CSN 番号（例: 47）
任意フィールドを入力します。
- Label: インスタンス名（例: lowy-dp01-docker）
- GIIP_PROJECT_NAME: デフォルト docker
- GIIP_WORKDIR: 作業ディレクトリ（任意）
- GIIP_REST_BRANCH: Git ブランチ（任意）
- SLACK_BOT_TOKEN / SLACK_APP_TOKEN / SLACK_CHANNEL_ID: Slack ボット（任意 — 両方必要）
- Enable hourly-issue-scheduler: チェックボックス（デフォルト on） — 毎時 :07 にイシュースケジューラを実行
Create をクリックします。

トークンは必ずコピーしてください

作成直後、トークンは1回だけ表示されます。

GIIP_INSTANCE_TOKEN=<トークン>

モーダルを閉じると二度と表示されません。 コンテナ起動に必要なため、必ずコピーしてから進んでください。

🛠️ 作成後のコンテナ起動 — 手順 ①（手動、全環境）

トークンをコピーした後、対象PC/サーバーで以下を実行します。

# 1. giip-fde-agent リポジトリをクローン
git clone https://github.com/LowyShin/giip-fde-agent.git
cd giip-fde-agent/docker

# 2. .env ファイルにトークンのみ記述
echo 'GIIP_INSTANCE_TOKEN=<コピーしたトークン>' > .env

# 3. Docker Compose で起動
docker compose up -d --build

.env に トークン1行だけで十分です。 他の環境変数は fetch-instance-env.sh が dockerInstanceFetch API（トークン自体が認証情報）でサーバーから自動取得します。
.env に直接キーを記述すると その値が優先します（部分的上書き可能）。

🛠️ 作成後のコンテナ起動 — 手順 ②（リモート Provision now）

対象PCにすでに GIIP エージェントが動作していて lssn がある場合にのみ使用可能です。（giip 3043）ドロップダウンにはDocker Desktop がインストール済みで、一度でも使用状況を報告したことがある lssn だけが候補として表示されます — 作成直後の（エージェントがまだ一度も接続したことのない）インスタンス自身の lssn は最初から候補に出ません。

トークン表示エリアのドロップダウンから、リソースに余裕がある対象（CPU/Mem/Disk 使用率と実行中コンテナ数が併記されます）を選択します。候補が1件もない場合はドロップダウンの代わりに案内文が表示されます — その場合は手順①（手動）をご利用ください。
[Provision now] ボタンをクリックします。
CQE キューにブートストラップスクリプト（mssn=6122）が登録され、即時強制実行（CQERunForce）されます。

⚠️ このボタンは GIIP エージェントがインストールされた PC でのみ動作します。 エージェントがない場合は手順 ① を使用してください。

ℹ️ 権限: [Provision now] はサーバー（DockerInstanceProvision）が検査します。インスタンスが属する csn と対象サーバーが属する csn のメンバーであれば誰でも実行でき、スクリプトの所有者である必要はありません。失敗した場合は理由が画面に表示され（下のトラブルシューティング表）、インスタンス作成は完了済みでトークンも有効なので、手順 ①（手動）で進められます。

⚠️ 最大1分かかる: 対象PCのGIIPエージェントは約60秒ごとにポーリングするため、最大1分待ちます。

🔍 作成後の「接続」確認 — 3つの方法

GIIP Web内にコンテナに接続するターミナルはありません。 確認は以下の3つの方法です。

1. コンテナシェルへの接続（対象PC上）

docker exec -it giip-fde-agent bash

コンテナ名は giip-fde-agent（固定）です。

2. ログ確認（対象PC上）

docker compose logs -f          # docker/ ディレクトリから
docker logs -f giip-fde-agent   # どこからでも可

正常に起動すると次のメッセージが表示されます：

[entrypoint] cloned ...
[fetch-instance-env] env applied from GIIP_INSTANCE_TOKEN
[entrypoint] registered giipAgentLinux cron (every 1 min)
[entrypoint] ready. tailing logs.

3. GIIP Web での確認 — lsvrlist（サーバー一覧）

これが「GIIP Web での接続確認」の正統な方法です。

インスタンス作成時にlsvrが事前登録されます — インスタンス作成時にlssnが即座に発行されてUIに表示されるため、コンテナ起動前にlsvrがlsvrlistに表示されます（giip 2856）。

コンテナ起動時：

giipAgentLinux をクローンします。
giipAgent.cnf（sk=登録した GIIP_SK、lssn=GIIP_LSSN 環境変数）をincipiteします。
1分ごとに giipAgent3.sh を実行します（ただし、lssnが0でないため、CQEQueueGetの自己登録パスではなく既存のlsvrを維持します）。
その後、このコンテナが 他のサーバーと同じ lsvrlist 一覧に表示されます。

確認パス: /ja/lsvrlist → 該当 lssn をクリック → lsvrdetail で tLSvr.lsChkdt ハートビートで生存確認

⚠️ GIIP_SK がない場合または GIIP_ENABLE_AGENT=false の場合、この登録は行われず、GIIP Web でコンテナの状態をまったく確認できません。起動ログ末尾の [entrypoint] summary: ブロックの giip agent: on|off (理由) でこの状態を一目で判定できます（giip #2855）。

4. Slack での確認（Slack ボット設定時）

SLACK_BOT_TOKEN と SLACK_APP_TOKEN の両方を入力した場合にのみ、slack-bot が pm2 で起動されます。指定チャンネルでボットが応答すれば正常です。

⚠️ どちらかのトークンが欠けるとスキップされます — 片方だけでは何も起動しません。

🧩 対象サーバーを新しく増やす方法（Docker インストール → 候補表示）

Provision now のドロップダウンはサーバー（lssn）単位で候補を表示します。csn 単位で選ぶものではなく、候補はインスタンスを作成した csn に所属するサーバーのみです。対象を増やすには、次の順序で PC/サーバーを準備します。

手順	やること	確認方法
①	対象 PC/サーバーに Docker をインストール	`docker version` が Client と Server の両方のバージョンを出力する
②	GIIP エージェントのインストール・登録（インスタンスの csn に所属）	lsvrdetail でその lssn の csn と最終チェックインを確認
③	`docker_usage` の報告を確認	kvslist の `kKey=<lssn>`、`kFactor=docker_usage` の最新行に `"dockerInstalled":true`
④	候補として表示されるか確認	インスタンスを Create した後、ドロップダウンにそのサーバーが表示される
⑤	[Provision now] を実行	手順②（リモート Provision now）を参照

OS 別の Docker インストール

OS	インストール対象	方法
Windows	Docker Desktop	公式ページ https://docs.docker.com/desktop/setup/install/windows-install/ からインストールするか、`winget install -e --id Docker.DockerDesktop` を使います。WSL 2 または Hyper-V（仮想化の有効化）が必要です。
macOS	Docker Desktop	公式ページ https://docs.docker.com/desktop/setup/install/mac-install/
Linux	Docker Engine	公式ドキュメント https://docs.docker.com/engine/install/ のディストリビューション別手順に従います。インストール後、ユーザーを `docker` グループに追加し（公式「Linux post-installation steps」）、再ログインして `docker version` がサーバーバージョンまで出力されることを確認します。

インストール後は Docker デーモンが起動している必要があります（Docker Desktop はアプリを起動したままにします）。

⚠️ 現在、Linux（Docker Engine）は候補一覧に表示されません。 確認の結果、giipAgentLinux（origin/main）には docker_usage を収集・報告するコードがなく、報告するのは Windows エージェント（giipAgentWin の CollectDockerMetrics.ps1）のみです。そのため Linux サーバーに Docker をインストールしてもドロップダウンの候補にはなりません。この場合は**手順①（手動）**で起動します。

候補の判定条件（Windows エージェント）

Windows エージェントは実行のたびに docker CLI が PATH にあるかを確認し、docker version --format '{{.Server.Version}}' がサーバーバージョンを返せば dockerInstalled=true を報告します。CLI がない、またはデーモンが停止している場合は false です。

GIIP エージェントのインストール

エージェントのインストールは本書ではなく、以下のガイドに従います。エージェントはインスタンスを作成した csn に所属している必要があります。

🤖 AI エージェント向け接続マニュアル（Provision now の対象サーバーが表示されないとき）

AI エージェントが人の代わりに「この PC を Docker インスタンスの対象として接続する」ときの手順です。すべての手順は読み取り専用で、値は推測せず直接調べます。

メッセージの意味

「この csn で Docker Desktop を検出したサーバーがまだありません」はエラーではなく、候補一覧が空という意味です。候補になるには次の3つをすべて満たす必要があります。

サーバー（lssn）が、インスタンスを作成した csn に属している。
そのサーバーの GIIP エージェントが docker_usage を報告しており、最新値に "dockerInstalled":true がある。
候補一覧 API（DockerCapableLsvrList）がサーバーにデプロイされている。

1. 対象 PC の lssn と csn を調べる

エージェント設定ファイル giipAgent.cfg の lssn を読みます（sk の値は出力しません）。Windows エージェントでは、タスクスケジューラの GIIP Agent Task (v3) の実行パスからフォルダーを探し、その親フォルダーの giipAgent.cfg を見ます。
csn は GIIP Web の lsvrdetail でその lssn の値を確認します。インスタンスを作成した csn と同じである必要があります。

2. エージェントと Docker の動作確認

Windows: Get-ScheduledTask 'GIIP Agent Task (v3)' | Get-ScheduledTaskInfo で LastTaskResult が 0（成功）または 267009（実行中）であること。
エージェントのログに、実行のたびに [CollectDockerMetrics] ... Successfully collected and uploaded Docker resource usage があること。
Docker Desktop が起動していること。docker version がサーバーのバージョンまで表示されるか確認します。

3. 報告された Docker 使用量の確認

GIIP Web の kvslist で kKey=<lssn>、kFactor=docker_usage を検索します。最新の行に "dockerInstalled":true があると候補になります。ない、または false の場合は手順 2 に戻ります。

4. すべて正常なのに一覧が空のとき（管理者）

候補一覧 API がデプロイされていない場合です。以前はこの場合も同じ案内が表示されて原因が隠れていましたが、現在は「候補一覧 API の応答が正しくありません」というエラーとして表示されます。管理者はストアドプロシージャ pApiDockerCapableLsvrListbyAK の有無を確認し、なければ giipdb の SP/pApiDockerCapableLsvrListbyAK.sql を mgmt/execSQLFile.ps1 でデプロイします。

5. 接続できるサーバーがないとき

対象 PC に GIIP エージェントがないと [Provision now] は使えません。エージェントを先にインストール・登録するか、**手順 ①（手動）**を使います。
エージェントが一度も接続したことのない lssn（最終チェックインが空）は候補ではありません。インスタンス作成時に事前登録される lssn がこれに当たるため、対象に選ばないでください。

AI が守ること

sk、インスタンスのトークン、キュー本文内のトークンを出力・記録しません。
別の csn の SK で参照・書き込みをしません（先に csn を確認します）。
値を推測せず、上の調査結果を根拠に報告します。

🤖 AI エージェントにこの文書の URL だけを渡す場合

ユーザーが AI エージェントにこの文書の URL だけを渡した場合（https://giip.littleworld.net/ja/guides/docker-instances、原文は https://giip.littleworld.net/help/docker-instances.ja.md）でも、AI は次の順序に従って対象サーバーを増やせます。

ユーザーが伝える必要があること: ① 作業 csn（インスタンスを作成する csn）② 対象 PC/サーバーへのアクセス方法（AI がその PC で直接実行するのか、リモート接続なのか）。

まず読み取り専用で調べます。 対象 PC の OS、Docker のインストール・デーモン状態（docker version）、GIIP エージェントのインストール・動作状態、giipAgent.cfg の lssn を確認します（sk は出力しません）。
足りない手順だけインストール・設定します。「対象サーバーを新しく増やす方法」の①〜③のうち、すでに満たしているものには触れません。インストールはユーザーの PC を変更する作業なので、実行前に何をインストールするかをユーザーに伝えます。
csn は推測しません。 lsvrdetail でその lssn の csn を確認し、インスタンスを作成した csn と同じか確認します。
候補として表示されることを確認してから報告します。 kvslist の docker_usage で "dockerInstalled":true を確認し、インスタンス作成後にドロップダウンへ候補として表示されるかまで確認します。Linux サーバーのように構造上候補になれない場合は、その事実と手順①（手動）を報告します。

AI が守ることは上記「AI が守ること」と同じです（sk・インスタンストークンの出力禁止、他の csn の SK の使用禁止、推測禁止）。

💡 参考

Last fetched ≠ リアルタイム生存状態: Last fetched は「最後に env を受け取った時刻」です。コンテナが停止してもこの値は変更されません。リアルタイムの状態は lsvrlist のハートビートで確認します。
Revoke は行を削除しません: Revoke はトークンを無効化するだけで一覧行を削除しません。監査証跡として Revoked バッジーと一緒に残ります。
Revokeしても実行中のコンテナは停止しません。 実際に停止するには対象PCで docker compose down を実行する必要があります。
コンテナ名: 手順 ①（手動）と既存のインスタンスは giip-fde-agent です。[Provision now] はインスタンスごとに giip-fde-agent-<diSn>（compose プロジェクト giip-fde-<diSn>）で起動するため、1台の PC で複数のインスタンスを動かせます。diSn は一覧表の diSn 列で確認します。

問題解決

症状	原因	解決
「この csn で Docker Desktop を検出したサーバーがまだありません」と表示される	(a) 対象 PC のエージェントが動いていない、または Docker Desktop が停止していて `docker_usage` がない (b) サーバーの csn がインスタンスの csn と異なる (c) 候補一覧 API がサーバーにデプロイされていない	下の「AI エージェント向け接続マニュアル」の手順 1〜4 で確認してください。すぐ進める場合は手順 ①（手動）を使います。
トークンを控えていなかった	再取得不可	既存のインスタンスを Revoke し、新規作成してください。
`docker compose up` は成功したが lsvrlist に表示されない	(a) `GIIP_ENABLE_AGENT=false` (b) `GIIP_SK` が空 (c) 最初のポーリング前 (d) 認証エラー(401)	`docker logs` の `/work/giipAgentLinux/log/cron.log` で 401 エラーを確認
`/work/giipAgentLinux` に `log/` だけがあり「空の抜け殻 clone」のように見える	エージェントブロックをスキップしたまま（`GIIP_SK` 未解決または `GIIP_ENABLE_AGENT=false`）起動した痕跡。正常な clone ならルートに `.git`＋7個のディレクトリがあり `ls -la` のリンク数は 10 だが、観測値 3（`.`＋`..`＋`log/` 1個）は clone ではなくログディレクトリだけが作られた状態	`docker logs` で `skipping giip agent` と `[entrypoint] summary:` ブロックの `giip agent: off (理由)` から原因を判定する（通常は `GIIP_SK` 未解決／トークン fetch 失敗）。原因を直して再起動すると、最新の entrypoint はその残骸を `.bak-<タイムスタンプ>` に退避してから自動で再 clone する（giip #2855）。旧イメージ（この修正以前）では、`not an empty directory` 拒否を解消するためにボリューム内のそのディレクトリを手動で削除する必要がある
再起動ごとに新しい lssn で登録される	`/work` ボリュームが消失	`docker-compose.yml` のボリュームが `giip-fde-agent-data:/work`（まるごと永続化）か確認
[Provision now] が失敗する	画面に表示される理由: `Forbidden: not a member of the instance csn` / `...target server csn`（その csn のメンバーではない）、`Target server has not reported Docker Desktop`（対象が Docker を報告したことがない — エージェントと Docker Desktop を確認）、`still pending`（前の要求が待機中 — 約5分後に再試行）、`Docker instance is revoked` / `not found`（失効済み、または存在しないインスタンス）	表示された理由に応じて対処してください。すぐ進める場合は手順 ①（手動 `docker compose up`）を使います。トークンは有効です。
[Provision now] は成功メッセージが表示されたのに、数分経ってもlsvrlistにもコンテナにも変化がない	(a) 対象lssnのエージェントが停止しており、そもそもポーリングしていない (b) このスケジュールだけが配給不可（BLOCKED）として隔離されている（giip #2557系）	(a) `lsvrdetail`でそのlssnの最終チェックイン時刻を確認 — 古ければ対象PCのエージェント/ネットワークをまず点検 (b) 管理者にそのlssn/csn基準で配給不可スケジュールがないか確認を依頼。数分待っても改善しなければ手順①（手動）に切り替える
Slack ボットが起動しない	`SLACK_BOT_TOKEN` と `SLACK_APP_TOKEN` の両方が必要	片方だけではどちらもスキップされます。
アクセス直後にホームにリダイレクト	`uLevel` が 70 未満	管理者アカウント（レベル 70+）でログインしてください。

バージョン: 1.3 最終更新: 2026-10-15（「対象サーバーを新しく増やす方法」「AI エージェントにこの文書の URL だけを渡す場合」を追加） ソースファイル: giipv3/public/help/docker-instances.ja.md