sealos-deploy

Sealos のデプロイ

GitHub プロジェクトをソースコードから実行中のアプリケーションまで、1 つのコマンドで Sealos Cloud にデプロイできます。

kubectl の安全ルール（すべてのフェーズ）

すべての kubectl コマンドで Sealos の kubeconfig を使用する必要があります：

KUBECONFIG=~/.sealos/kubeconfig kubectl --insecure-skip-tls-verify

システムツールのインストールには、ユーザーの確認が必要です。docker、gh、または kubectl が見つからず、このスキルで現在のプラットフォームにインストールできる場合は、まず確認を求め、ユーザーが明示的に y と返信した後にのみインストールコマンドを実行してください。

kubectl delete の実行にはユーザーの確認が必要です。 リソース（デプロイメント、サービス、Ingress、PVC、データベースなど）を削除する前に、必ず次のように確認してください：

WARNING: About to delete <resource kind>/<resource name>. This data cannot be recovered. Confirm? (y/n)

ユーザーの確認後にのみ続行してください。パイプラインのロジックで削除が提案されている場合も同様です。必ず事前に確認してください。

使い方

/sealos-deploy <github-url>
/sealos-deploy                    # deploy current project
/sealos-deploy <local-path>

クイックスタート

モジュールを順番に実行します：

1. modules/preflight.md — 環境チェックと Sealos 認証
2. modules/pipeline.md — デプロイパイプライン全体（フェーズ 1～6）

ログ

実行ごとに、~/.sealos/logs/deploy-<YYYYMMDD-HHmmss>.log にログファイルを作成する必要があります。

実行の開始時に、ログファイルを一度だけ作成します：

mkdir -p ~/.sealos/logs
LOG_FILE=~/.sealos/logs/deploy-$(date +%Y%m%d-%H%M%S).log
echo "[$(date '+%Y-%m-%d %H:%M:%S')] Deploy started" > "$LOG_FILE"

重要：ログファイルを作成するのは開始時の一度だけにしてください。以降の書き込みはすべて、同じ $LOG_FILE に追記（>>）する必要があります。2 つ目のログファイルは作成しないでください。

各フェーズの境界で、同じファイルに Bash の >> でログエントリーを追記します：

[2026-03-05 14:30:01] === Phase 0: Preflight ===
[2026-03-05 14:30:01] Docker: ✓ 27.5.1
[2026-03-05 14:30:01] Node.js: ✓ 22.12.0
[2026-03-05 14:30:02] Sealos auth: ✓ (region: <REGION from config.json>)
[2026-03-05 14:30:02] Project: /Users/dev/myapp (github: https://github.com/owner/repo)

[2026-03-05 14:30:03] === Phase 1: Assess ===
[2026-03-05 14:30:03] Score: 9/12 (good)
[2026-03-05 14:30:03] Language: python, Framework: fastapi, Port: 8000
[2026-03-05 14:30:03] Decision: CONTINUE

[2026-03-05 14:30:04] === Phase 2: Detect Image ===
[2026-03-05 14:30:05] Docker Hub: owner/repo:latest (arm64 only, no amd64)
[2026-03-05 14:30:05] GHCR: not found
[2026-03-05 14:30:05] Decision: no amd64 image → continue to Phase 3

[2026-03-05 14:30:06] === Phase 3: Dockerfile ===
[2026-03-05 14:30:06] Existing Dockerfile: none
[2026-03-05 14:30:07] Generated: python-fastapi template, port 8000

[2026-03-05 14:30:08] === Phase 4: Build & Push ===
[2026-03-05 14:30:08] Registry: ghcr (auto-detected via gh CLI)
[2026-03-05 14:30:30] Build: ✓ ghcr.io/zhujingyang/repo:20260305-143022
[2026-03-05 14:30:32] GHCR pullability: private package detected — deploy will auto-create image pull Secret from gh CLI
[2026-03-05 14:30:33] IMAGE_REF=ghcr.io/zhujingyang/repo:20260305-143022

[2026-03-05 14:30:34] === Phase 5: Template ===
[2026-03-05 14:30:35] Output: .sealos/template/index.yaml

[2026-03-05 14:30:36] === Phase 6: Deploy ===
[2026-03-05 14:30:36] Deploy URL: https://template.gzg.sealos.run/api/v2alpha/templates/raw
[2026-03-05 14:30:38] Status: 201 — deployed successfully
[2026-03-05 14:30:38] === DONE ===

エラー発生時は、停止する前にエラーの詳細を記録します：

[2026-03-05 14:30:10] === ERROR ===
[2026-03-05 14:30:10] Phase: 4 (Build & Push)
[2026-03-05 14:30:10] Error: docker buildx build failed — "npm ERR! Missing script: build"
[2026-03-05 14:30:10] Retry: 1/3

実行の最後に、ログの保存場所をユーザーに伝えます：

Log saved to: ~/.sealos/logs/deploy-20260305-143001.log

スクリプト

このスキルディレクトリ内の scripts/ にあります（<SKILL_DIR>/scripts/）：

スクリプト	使い方	目的
score-model.mjs	node score-model.mjs <repo-dir>	準備状況を決定論的にスコア化します（0～12）
validate-artifacts.mjs	node validate-artifacts.mjs --dir <work-dir>	.sealos JSON アーティファクトを適用対象のスキーマに照らして検証します
detect-image.mjs	node detect-image.mjs <github-url> [work-dir] または node detect-image.mjs <work-dir>	既存の Docker/GHCR イメージを検出します
build-push.mjs	node build-push.mjs <work-dir> <repo> [--registry ghcr|dockerhub] [--user <user>]	amd64 イメージをビルドして選択したレジストリにプッシュします（Docker Hub のパスでは、デプロイ時に公開イメージがあることを前提とします。--registry を省略すると自動検出の動作が維持されます）
ensure-image-pull-secret.mjs	node ensure-image-pull-secret.mjs <namespace> <secret-name> <image-ref> [deployment-name]	アプリ単位の GHCR プル Secret を作成または更新し、任意で既存の Deployment がそれを参照するようパッチを適用します
gh-refresh-scopes.mjs	node gh-refresh-scopes.mjs write:packages	現在の TTY で GHCR パッケージへのアクセス権を更新します。このワークフローでは、プッシュとプライベートプルの両方に write:packages で十分です
deploy-template.mjs	node deploy-template.mjs <template-path> [--dry-run] [--args-json '{"KEY":"value"}'|--args-file <file>]	~/.sealos/auth.json から現在のリージョンを解決し、適切な Template API URL を構築して、ローカルのテンプレート YAML を送信します
sealos-auth.mjs	node sealos-auth.mjs check|login|list|switch	Sealos Cloud の認証とワークスペースの切り替え

すべてのスクリプトは JSON を出力します。Bash 経由で実行し、結果を解析してください。

内部スキルの依存関係

このスキルは、同時にインストールされた内部スキルのナレッジファイルを参照します。これらはユーザー向けではありません。特定のフェーズで必要に応じて読み込まれます。

<SKILL_DIR> は、この SKILL.md を含むディレクトリを指します。同階層のスキルは <SKILL_DIR>/../ にあります：

<SKILL_DIR>/../
├── sealos-deploy/           ← this skill (user entry point) = <SKILL_DIR>
├── dockerfile-skill/        ← Phase 3: Dockerfile generation knowledge
├── cloud-native-readiness/  ← Phase 1: assessment criteria
└── docker-to-sealos/       ← Phase 5: Sealos template rules

pipeline.md で使用するパスは、次のパターンに従います：

<SKILL_DIR>/../dockerfile-skill/knowledge/error-patterns.md
<SKILL_DIR>/../dockerfile-skill/templates/<lang>.dockerfile
<SKILL_DIR>/../docker-to-sealos/references/sealos-specs.md

フェーズの概要

フェーズ	アクション	スキップする条件
0 — 事前確認	機能のスキャン、パス固有の警告、Sealos 認証	初期ブロッカーが解消済み
1 — 評価	リポジトリをクローン（または現在のプロジェクトを使用）し、デプロイ可能性を分析	スコアが低すぎる場合 → 停止
2 — 検出	既存のイメージを検索（Docker Hub / GHCR / README）	見つかった場合 → フェーズ 5 へ進む
3 — Dockerfile	Dockerfile がない場合は生成	すでにある場合 → スキップ
4 — ビルドとプッシュ	docker buildx → GHCR（gh CLI 経由で自動）または Docker Hub（フォールバック）	—
5 — テンプレート	Sealos アプリケーションテンプレートを生成	—
5.5 — 設定	アプリの環境変数と入力項目の設定をユーザーに案内	入力項目が不要
6 — デプロイ	Sealos Cloud にテンプレートをデプロイ	—

判断フロー

Input (GitHub URL / local path)
  │
  ▼
[Phase 0] Preflight ── fail → guide user to fix and STOP
  │ pass
  ▼
[Phase 1] Assess ── not suitable → STOP with reason
  │ suitable
  ▼
[Phase 2] Detect existing image
  │
  ├── found (amd64) ────────────────────┐
  │                                     │
  ▼                                     │
[Phase 3] Dockerfile (generate/reuse)   │
  │                                     │
  ▼                                     │
[Phase 4] Build & Push to registry      │
  │                                     │
  ◄─────────────────────────────────────┘
  │
  ▼
[Phase 5] Generate Sealos Template
  │
  ▼
[Phase 5.5] Configure ── present env vars → ask user for inputs → confirm
  │
  ▼
[Phase 6] Deploy to Sealos Cloud ── 401 → re-auth
  │                                  409 → instance exists
  ▼
Done — app deployed ✓

実行ルール： フェーズ 0 の未解決の開始ブロッカーが残っている間は、フェーズ 1 を開始してはいけません。Docker、gh、ビルダー、レジストリに関する問題は早い段階で報告する必要がありますが、その実行でローカルでのビルドやプッシュが必要になった場合にのみ、ハードブロッカーとなります。