sealtun

Sealtun

最初の判断

回答または編集を行う前に、リクエストを分類してください。

• ユーザー操作：インストール、シェル補完、TUI／コンソール、ガイド付き初期化、ログイン、up、ローカルポートの検出、HTTPS の公開、リモート HTTP アップストリームのターゲット、SSH、汎用 TCP、connect によるクラスター内部の Service／Pod へのアクセス、サービスレベルのリージョン間 Mesh の構築、プロトコルテンプレートの生成、公開 HTTP トラフィックの保護、ポリシーの表示／設定、アクセスの監査、一時共有リンクの作成／一覧表示／取り消し／ローテーション、サーバーシークレットのローテーション、カスタムドメインの計画／追加／検証、状態の確認、ステータスの監視、リソースの表示または調整、停止／開始／再開、クリーンアップ、YAML のエクスポート。references/cli.md を参照してください。
• 宣言型の設定：sealtun.yaml、apply -f、diff -f、export、複数のトンネルの管理、安定した名前、ttl、Pod リソース、HTTPS アクセスポリシー、SSH トンネルの宣言、汎用 TCP トンネルの宣言。references/declarative.md を参照してください。
• トラブルシューティング：ログイン／プロファイルの不一致、デーモン／セッションの問題、ローカルポートの検出／失敗、SSH／TCP の直接的な NodePort の問題、リモート Kubernetes の問題、リソース一覧／リソースの占有、DNS、Ingress、証明書、ログ、メトリクス、イベント。references/troubleshooting.md を参照してください。
• スキルの保守または品質レビュー：このスキルのトリガー精度、ワークフローのスコアリング、回帰プロンプト。references/evals.md を参照してください。

Sealtun リポジトリ内でのリクエストでは、これらのリファレンスと内容が異なる場合、現在のソースツリー、README、QuickStart ドキュメントを優先してください。CLI の使用方法に関するガイダンスを変更する前に、rg を使って Cobra のコマンドとフラグを確認してください。

安定性に応じた案内

• 通常のガイダンスと自動化では、Stable コマンドを優先してください。
• 現在 Alpha のエントリーポイントは、init、tui／console、connect、mesh、ssh connect、および単独の discover、template、export、events、metrics、resources、watch コマンドです。これらの機能は引き続き利用できますが、後方互換性の保証なしにインターフェースが変更または削除される場合があります。Alpha の方法を推奨する前に、その旨を簡潔に伝えてください。
• repair、domain set、トップレベルの disconnect は、互換性維持のための非推奨コマンドです。新たな利用では推奨せず、代わりに doctor <id> --fix、domain add、connect disconnect を使用してください。
• Alpha は、壊れている、または未完成という意味ではありません。ユーザーの明示的なリクエストに固有の形で応える Alpha 機能がある場合は、その機能を使用し、Stable 機能と同じ事前確認、変更、検証のルールを適用してください。

意図に応じたルーティング

ユーザーの意図に応じて、最短で安全な方法を選択します。

ユーザーの意図	主な方法	次の方法で確認
ローカルの Web アプリ、開発サーバー、コールバック、プレビュー、または Webhook を公開する	対話型／開発用途では status -> up、スクリプトでは expose <port>	出力された URL、list --check、inspect <id>
対話型ターミナルからトンネルを管理する	Alpha の tui または console	Alpha のステータスを明示する。選択したトンネルの状態、確認済みの操作結果、list --check
このマシンから HTTP サービスにパブリックにアクセスできるようにする	開発用途では status -> up --target http://host:port、スクリプトでは expose --target	出力された URL、inspect <id>、保護されたリクエストの動作
Basic Auth、Bearer トークン、IP ルール、レート制限、監査、または一時リンクを追加する	HTTPS の expose、policy、share、または YAML アクセスポリシー	inspect <id>、policy show/audit、保護されたリクエストの動作
SSH を直接公開する	expose 22 --protocol ssh	表示された SSH ホスト／ポート、inspect <id> --remote、ユーザーの SSH クライアント出力
データベース、キュー、MQTT、または任意の TCP を公開する	Alpha の template <protocol> でガイダンスを確認してから、安定版の expose <port> --protocol tcp を使用	template の Alpha ステータスを明示する。表示された <host>:<node-port>、プロトコルクライアント、list --check
アクティブな Sealos 名前空間内の Service／Pod にローカルツールからアクセスする	Alpha の connect --check を実行してから、Linux で sudo sealtun connect を実行	Alpha のステータスを明示する。Service の FQDN、ClusterIP、または Pod IP への TCP アクセス。SOCKS／プロキシ設定は使用しない
Sealos のリージョンをまたいで Kubernetes Service をインポートする	Alpha の mesh init、mesh login、mesh up を実行してから、mesh service publish/check を実行	Alpha のステータスを明示する。インポートされた mesh-<name> ClusterIP Service と mesh service check
多数のトンネルまたは安定した設定を管理する	sealtun.yaml を編集してから、apply --dry-run、diff を実行する。実際の apply は要求された場合のみ実行する	apply の出力、list、inspect
カスタムドメインを設定する	まず domain plan を実行する。変更が要求された場合のみ domain add --wait を実行する	domain verify/status、DNS CNAME、証明書のステータス
トンネル Pod のリソースを調整する	まず Alpha の resources <id> を実行してから、要求に応じて resources set または YAML の resources を使用する	Alpha のステータスを明示する。resources <id>、ロールアウト／起動の動作
接続または不明瞭な状態をデバッグする	まず安定版のチェックを実行する：status、list --check、inspect、doctor、logs。Alpha の resources/events/metrics は必要な場合のみ使用する	使用した場合は Alpha のステータスを明示する。レイヤーごとの検出内容と次のアクション
トンネルの状態を監視または修復する	状態変化の確認には Alpha の watch を使用する。実行前に安定版の doctor <id> --fix --dry-run を実行する	watch の Alpha ステータスを明示する。dry-run の計画を確認してから、検証済みの状態を確認する

必須の実行フロー

スキルが起動した後は、次のフローに従ってください。

1. 対象範囲の確認：ローカル／開発サービスをパブリックにアクセス可能にすること、Sealtun トンネルの操作、Sealtun のトラブルシューティング、または宣言型の Sealtun 設定に関する依頼かどうかを確認します。一般的な本番環境へのデプロイ、ドメインの購入、DNS のみの設定、一般的な Kubernetes、または Sealtun のトンネリングを伴わない一般的な SSH のみの場合は、回答に Sealtun を無理に含めないでください。
2. 実行前にモードを 1 つ選択します。
   • ガイダンスモード：ユーザーが Sealtun の使い方を尋ねています。該当するリファレンスを読み込んでコマンドを提示し、ライブトンネル／クラウドコマンドは実行しないでください。
   • ライブ操作モード：ユーザーが実行、作成、適用、停止、クリーンアップ、またはドメインの紐付けを明示的に依頼しています。まず事前チェックを実行し、次に依頼されたコマンドを実行してから、検証します。
   • トラブルシューティングモード：ユーザーが問題を報告しています。まず変更を伴わない診断を実行して、問題が発生している可能性の高いレイヤーを特定し、依頼内容が明確な場合に限って修正を提案または実行します。
3. 必要最小限のコンテキストを収集します。このリポジトリ内では、リファレンスに頼る前に、現在のコード／README／QuickStart ドキュメントを確認します。リポジトリ外では、コマンドの情報源としてリファレンスを使用します。sealtun --version、sealtun status、sealtun profile current、sealtun region current、sealtun list、sealtun inspect、sealtun doctor など、安定していて変更を伴わないチェックを優先します。Alpha の sealtun discover、sealtun resources、sealtun init は、それぞれの検出、リソース、または初回実行の出力が役立つ場合にのみ使用します。
4. 初回の認証には丁寧に対応します。status で未ログインと表示された場合は、クラウドリソースを作成する前に Sealtun の認証と kubeconfig が必要であることを説明します。ユーザーを sealtun login、またはリージョン／プロファイルが重要な場合は sealtun login <region> --profile <name> へ案内します。ブラウザー／デバイス認証フローが開いた場合は、ブラウザーで認証を完了して待つように伝えます。待機状態を失敗として扱わないでください。ログイン後、sealtun status、sealtun region current、必要に応じて sealtun profile current で確認します。
5. 変更操作を制御します。ユーザーが現在のタスクでその操作を明示的に依頼していない限り、sealtun up、sealtun expose、実際の sealtun apply、Alpha の sealtun mesh up/down、Alpha の sealtun mesh service publish/unpublish、Alpha の sealtun resources set/unset、sealtun share create/revoke、sealtun domain add/clear、sealtun stop、sealtun cleanup、sealtun logout は実行しないでください。Alpha の sealtun template、Alpha の sealtun export、sealtun domain plan、Alpha の sealtun mesh status、Alpha の sealtun mesh service list/check、sealtun share list、apply --dry-run、diff、読み取り専用の診断は、安全なガイダンス手順です。宣言型の変更では、実際の apply の前に apply --dry-run と diff を優先します。
6. 完了を検証します。ライブ操作後は、以下の契約に従って確認し、シークレットを表示せずに、正確なコマンドの実行順序と最終状態を報告します。

検証契約

• up／expose：トンネル ID、公開エンドポイント、プロトコル固有の出力を記録し、sealtun list --check と sealtun inspect <tunnel-id> で検証します。up では、.sealtun/state.json を再利用したのか、検出されたポートを選択したのか、明示的なポート／ターゲット入力を使用したのかを伝えます。
• apply：最初に apply --dry-run と diff を実行するか、実行を推奨します。実際に適用した後、意図したすべてのトンネルを list と inspect で検証します。
• domain add/clear：domain status または domain verify で検証します。add --wait では、DNS／CNAME と証明書の準備状況を分けて報告します。domain set は Deprecated の別名としてのみ扱います。
• share create/revoke/rotate：share list で検証します。ワンタイム共有トークンは、そのコマンドの直接の出力である場合を除き、絶対に繰り返し表示しません。
• stop/start/cleanup：list または inspect で検証します。stop はエントリーのリソースを保持しますが、cleanup は停止済み、期限切れ、古い状態、またはエラーのトンネルリソースを削除することに注意してください。
• アルファ版の resources set/unset：安定性に関する注記を明示し、resources <id> で検証します。停止中のトンネルは、Deployment テンプレートの更新中もスケール 0 のままです。
• アルファ版の mesh：安定性に関する注記を明示したうえで、mesh auth status、mesh status、mesh service check <name> --from <region> で検証します。Mesh v1 はサービスレベルの HTTP/TCP インポートであり、透過的な Pod IP/CNI ルーティングではないことを説明します。
• トラブルシューティング：変更を提案する前に、障害が発生しているレイヤー（ローカルのログイン／プロファイル、ローカルポート、デーモン／セッション、リモートリソース、DNS／証明書、アクセス制御、ユーザープロトコル／認証）を示します。ユーザーがサポート用の情報を秘匿化して作成する必要がある場合は、doctor <id> --report を使用します。

運用ルール

• 最終回答、ログ、コミット、生成されたドキュメントにユーザーの秘密情報を含めないでください。ユーザーがその場限りのインライン例を明示的に希望している場合を除き、パスワードやトークンには *Env フィールドと環境変数を優先してください。
• Sealtun のパブリックアクセス制御は、Ingress アノテーションではなく Sealtun サーバーのプロキシ層で適用されることを説明してください。この制御は、--target の上流トラフィックを含む HTTPS のパブリックな業務トラフィックを保護しますが、内部の /_sealtun/ws 制御チャネルや、SSH/TCP の直接 NodePort トラフィックは保護しません。
• SSH を公開する場合は、リージョンがパブリック TCP NodePort に対応していれば、安定版の sealtun expose 22 --protocol ssh を優先してください。Alpha の sealtun ssh connect <tunnel-id> は WebSocket ProxyCommand のフォールバックとしてのみ使用し、その安定性について明記してください。
• 汎用 TCP を公開する場合は、sealtun expose <port> --protocol tcp を優先し、生成された <public-host>:<node-port> エンドポイントを提示してください。
• 宣言型の作業では、可能であれば実際に適用する前に sealtun apply -f sealtun.yaml --dry-run と sealtun diff -f sealtun.yaml を実行するか、実行を推奨してください。
• HTTPS ポリシーの操作には、policy show、policy set --rate-limit 60/m --audit、policy audit --since 10m を使用してください。監査出力に平文のトークン、Authorization ヘッダー、Basic Auth のパスワードを含めてはいけません。
• 一時共有リンクには、HTTPS トンネルに限り sealtun share create <tunnel-id> --ttl 1h --name review を使用してください。Sealtun はトークンのハッシュのみを保存するため、URL は一度しか表示されないことをユーザーに伝えてください。古いトークンを無効にして新しい一度限りの URL を表示するには share rotate、メタデータを表示するには share list、名前を指定して取り消すには share revoke を使用してください。
• サーバーのシークレットをローテーションする場合は、sealtun rotate <tunnel-id> --server-secret を使用してください。新しいシークレットは一度しか出力されず、SSH/TCP のアクセス ポリシーは変更されないことを伝えてください。
• Alpha の設定エクスポートでは、安定性について明記し、sealtun export <tunnel-id> または sealtun export --all -o sealtun.yaml を使用してください。保存されたパスワードやトークンのハッシュは復元できず、--include-secret-placeholders は環境変数のプレースホルダーを出力することを説明してください。
• Alpha のクラスター内部アクセスでは、安定性について明記し、sealtun connect --check を実行してから、Linux では sudo sealtun connect を実行してください。停止するには sudo sealtun connect disconnect を使用します。TCP の Service FQDN、Service ClusterIP、Pod IP へのトラフィックを Kubernetes の pods/portforward 経由で透過的にリダイレクトすることを説明してください。これは SOCKS/HTTP プロキシの設定ではなく、ICMP/ping や UDP には対応していません。
• Alpha のクロスリージョン Mesh では、安定性について明記してから、sealtun mesh init --regions ...、mesh login、mesh up、mesh service publish <name> --from <region> --k8s-service <namespace>/<service>:<port> --import ... を使用してください。リージョンごとにゲートウェイを 1 つ作成し、他のリージョンでは Service を mesh-<name> という ClusterIP Service としてインポートすることを説明してください。
• 初めて利用するユーザーには、わかりやすい手順を優先してください。インストールし、sealtun login を実行した後、対話的なローカル開発には安定版の sealtun up、コマンドで正確に作成する場合は sealtun expose を使用します。読み取り専用のコマンド／YAML の提案をユーザーが求めている場合に限り、Alpha の sealtun init を使用してください。ログイン情報は ~/.sealtun に保存され、プロジェクトのトンネル状態は .sealtun/state.json に保存されること、また複数の Sealos アカウント、リージョン、ワークスペースを使う場合にはプロファイルが便利であることを伝えてください。
• 手順を変更する際は、リポジトリに記載された正確なコマンド名とフラグを使用してください。対応しているトンネルプロトコルは https、専用の ssh、汎用の tcp です。リポジトリで追加されない限り、UDP/gRPC はサポートされていません。

回答形式

使い方に関する質問には、動作する短いコマンド手順を示し、関連する注意点のみを説明してください。トラブルシューティングでは、まずコストの低いローカルでの確認から始め、その後、リモートの Kubernetes 診断へ進んでください。