sealos-deploy

Sealos Deploy

互換性

デプロイにはSealosの認証情報とワークスペースが必要です。Docker、buildx、gh CLIが必要になるのは、選択した手順でローカルでのビルド／プッシュが必要な場合のみです。GitHub URLからクローンする場合、またはGitのメタデータが必要な場合は、gitが必要です。Node.js 18+とPython 3.8+は、引き続き任意で利用できる高速化ツールです。

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

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

すべてのkubectlコマンドでは、Sealosのkubeconfigを必ず使用してください。

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

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

**kubectl deleteにはユーザーの確認が必要です。**リソース（deployment、service、ingress、PVC、databaseなど）を削除する前に、必ず次のように確認してください。

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

ユーザーの確認を得てから続行してください。パイプラインのロジックで削除が示されている場合でも、必ず事前に確認してください。

Template APIのクリーンアップにはInstance CRも含める必要があります。scripts/deploy-template.mjsで作成されたデプロイでは、App／ワークロードリソースに加えてinstances.app.sealos.io/<app-name>も作成されます。instances.app.sealos.io、apps.app.sealos.io、ワークロード、Services、Ingresses、PVC、Podsをすべて確認するまでは、クリーンアップは完了していません。

Template APIのテストデプロイをクリーンアップする際は、次の確認を使用してください。

KUBECONFIG=~/.sealos/kubeconfig kubectl --insecure-skip-tls-verify -n "$NS" \
  get instances.app.sealos.io,app,statefulset,deployment,svc,ingress,pvc,pod | grep "$APP"

確認後、次の順序で削除してください。

KUBECONFIG=~/.sealos/kubeconfig kubectl --insecure-skip-tls-verify -n "$NS" delete instances.app.sealos.io "$APP" --ignore-not-found --wait=false
KUBECONFIG=~/.sealos/kubeconfig kubectl --insecure-skip-tls-verify -n "$NS" delete app "$APP" --ignore-not-found --wait=false
KUBECONFIG=~/.sealos/kubeconfig kubectl --insecure-skip-tls-verify -n "$NS" delete statefulset "$APP" --ignore-not-found --wait=false
KUBECONFIG=~/.sealos/kubeconfig kubectl --insecure-skip-tls-verify -n "$NS" delete deployment "$APP" --ignore-not-found --wait=false
KUBECONFIG=~/.sealos/kubeconfig kubectl --insecure-skip-tls-verify -n "$NS" delete ingress "$APP" --ignore-not-found --wait=false
KUBECONFIG=~/.sealos/kubeconfig kubectl --insecure-skip-tls-verify -n "$NS" delete svc "$APP" --ignore-not-found --wait=false
KUBECONFIG=~/.sealos/kubeconfig kubectl --insecure-skip-tls-verify -n "$NS" get pvc -o name | grep "$APP" | while read -r PVC; do
  KUBECONFIG=~/.sealos/kubeconfig kubectl --insecure-skip-tls-verify -n "$NS" delete "$PVC" --ignore-not-found --wait=false
done

悪い例：app,statefulset,svc,ingress,pvc,podだけを確認して、クリーンアップが完了したと報告しないでください。これではinstances.app.sealos.io/<app-name>を見落とし、SealosのInstanceレイヤーが残ったままになります。

使い方

/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にログファイルを作成してください。

実行開始直後に、ログファイルを1回だけ作成してください。

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"

重要：ログファイルは開始時に1回だけ作成してください。それ以降の書き込みはすべて、同じ$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-footprint.mjs	node sealos-footprint.mjs --namespace <ns> --app <app>	デプロイのデバッグとクリーンアップ計画用に、Instance/App/workloads/Jobs/KubeBlocks/PVCs の読み取り専用インベントリを取得します
sealos-live-smoke.mjs	node sealos-live-smoke.mjs --url <url> [--captcha-path <path>] [--login-path <path>] [--username <user>] [--password <pass>] [--auth-path <path>]	実際の Sealos App エントリー URL に対する読み取り専用、または認証情報を使用した HTTP スモークテストを実行します
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 にデプロイ	—
6.5 — ランタイムの実態確認	実際の Sealos ランタイム、ログ、App URL、ログインパス、リソースの使用状況を確認	ユーザーがデプロイのみの出力を明示的に要求した場合

判断フロー

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
▼
[Phase 6.5] Runtime Truth Pass ── runtime/log/login issue → debug template or runtime config
│
▼
Done — app deployed ✓

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