docker-to-sealos

Docker から Sealos テンプレートへの変換

概要

Docker Compose ファイルやインストール手順書を、本番環境向けの Sealos テンプレートに変換します。 不足している項目についてユーザーに確認することなく、分析、変換、検証、出力をエンドツーエンドで自動実行します。

ガバナンスとルールの優先順位

ルールの逸脱を防ぐため、以下の優先順位を適用します。

1. SKILL.md の MUST ルール（このファイル）
2. references/sealos-specs.md と references/database-templates.md
3. references/conversion-mappings.md と references/example-guide.md

優先順位の低いリファレンスが、優先順位の高い MUST ルールと矛盾する場合は、優先順位の低いファイルを更新してください。 矛盾するサンプルを残さないでください。

ワークフロー

ステップ 1：入力を分析する

Docker Compose／ドキュメントから以下を抽出します。

• アプリケーションサービスとデータベースサービス
• ボリューム／設定マウント／オブジェクトストレージの要件
• ポート、依存関係、サービス間通信
• 環境変数とシークレットの使用状況
• ブートストラップ認証情報、API キー、ソルト、シークレット、機能フラグに関する起動時の検証ルール
• マルチサービス Web の役割：ブラウザーのエントリーポイント、REST API、OpenAI/API ゲートウェイ、ドキュメント、ワーカー、単発ジョブ
• リソースの上限／リクエストとヘルスチェック
• 公式の Kubernetes インストール手順／マニフェストがある場合は、アプリのランタイム動作も抽出します（ブートストラップ管理者フィールド、外部エンドポイント／プロトコルの前提条件、ヘルスプローブ、起動／初期化フロー、マイグレーションの順序）

ステップ 2：メタデータを推定する

以下を推定し、正規化します。

• アプリ名、タイトル、説明、カテゴリ
• 公式 URL、gitRepo、アイコンのソース（アプリアイコン、ファビコン、アバターなど、正方形または円形でアイコンを主体とするアセットを優先し、長方形のワードマーク／テキストロゴは避けます）
• ロケール／i18n メタデータ

ステップ 3：厳密な順序でリソースを計画する

以下の順序でリソースを生成します。

1. Template CR
2. ObjectStorageBucket（必要な場合）
3. データベースリソース（ServiceAccount → Role → RoleBinding → Cluster → 必要な場合は Job）
4. アプリのワークロードリソース（ConfigMap/Secret → Deployment/StatefulSet → Service → Ingress）
5. App リソース（最後）

ステップ 4：変換ルールを適用する

references/conversion-mappings.md のフィールド単位のマッピングを適用します。以下を含みます。

• イメージのピン留めとアノテーションのマッピング
• ポート／サービス／Ingress の変換
• 環境変数の変換と依存関係の順序
• ストレージ変換と vn の命名（scripts/path_converter.py）
• サービス名から Kubernetes FQDN への変換
• DB URL/DSN 環境変数（例：*_DATABASE_URL、*_DB_URL）で、Kubeblocks の endpoint が host:port の場合、承認済みの secretKeyRef 環境変数を使って host／port／username／password を注入し、$(VAR) 展開で最終 URL を組み立てます
• エッジゲートウェイの正規化：Compose に Traefik のようなエッジプロキシとビジネスサービスが含まれる場合、プロキシのワークロードはスキップし、Sealos Ingress を介してビジネスサービスを直接公開します
• Sealos Ingress の TLS オフロードの正規化：ビジネスサービスが 80 と 443 の両方を公開している場合、公式の Kubernetes ドキュメントでサービスへのバックエンド通信に HTTPS が明示的に必要とされていない限り、ワークロード／サービスのポートから 443 を除外し、コンテナ内の TLS 証明書マウント（例：/etc/nginx/ssl、/etc/ssl、/certs）を削除します
• マルチサービス Web の正規化：検証済みのブラウザーエントリーポイントを App リソースで公開し、公開対象として意図されている場合に限り API／ゲートウェイ／ドキュメントを公開します。ワーカーは非公開にし、Service／Ingress を作成しません
• URL の構成：ブラウザー向け環境変数には公開 HTTPS URL を使用し、サーバー間の環境変数には、アプリが公開コールバックを明示的に必要とする場合を除いて Kubernetes Service FQDN を使用します
• 再現可能なワークロード構成のために kompose を必要とする、決定論的な変換のエントリーポイントとして scripts/compose_to_template.py --kompose-mode always を優先します
• 公式の Kubernetes インストール手順／マニフェストがある場合は、二つのソースを統合します。Compose をトポロジーのベースラインとして使用し、公式の Kubernetes ガイダンスに合わせてアプリのランタイムのセマンティクスを調整します

ステップ 5：データベース戦略を適用する

• データベースサービスは、KubeBlocks の Cluster リソースとして生成する必要があります。PostgreSQL／MySQL／MongoDB／Redis／Kafka の Compose データベースサービスを、Kubernetes の生の Deployment または StatefulSet ワークロードに変換してはいけません。
• PostgreSQL は、固定されたバージョンと構成の要件に従う必要があります。
• MySQL／MongoDB／Redis／Kafka では、references/database-templates.md のテンプレートとシークレットの命名規則を使用する必要があります。
• アプリケーションのデータベース初期化に必要な場合は、DB 初期化 Job／initContainer を追加します。
• カスタムデータベース（postgres 以外）の PostgreSQL では、初期化 Job は実行前に PostgreSQL の準備完了を待ち、対象データベースを冪等に作成する必要があります。
• アプリケーションの重要な互換性オブジェクトは、稼働中のデータベース状態で検証する必要があります。アプリケーションが毎回のコールドスタート時に必要とする互換性ビュー、レガシーテーブル／ビュー、インデックス、拡張機能、検索パス、ブートストラップ状態には、冪等な initContainer による自己修復を使用します。
• 一度だけ実行する初期化 Job では、初期データベースやシード状態を作成できますが、アプリケーションの起動ゲートでは、最終的なデータベースオブジェクトを直接検証する必要があります。TTL の期限が切れた Job は過去の証拠として扱い、受け入れ判断ではデータベース状態を基準にします。
• アプリケーションのマイグレーションに依存するワーカー、ゲートウェイ、バックグラウンドサービスは、データベースのポートだけでなく、必要なテーブル、マイグレーションマーカー、またはアプリケーション固有の準備完了オブジェクトを待つ必要があります。
• Redis の認証情報が準備完了確認に不要な場合、Redis の準備完了プローブまたは initContainer は、NOAUTH や Authentication required などの認証済み Redis 応答を許容する必要があります。
• PostgreSQL のブートストラップ用シェルでは、安全な引用符の使用方法に従う必要があります。可能な場合は、シェルレベルで存在確認を行い、単純な SQL 文を使用します。psql の変数展開には、シングルクォートのヒアドキュメントまたは SQL ファイルを使用し、ガードクエリで同じ処理を表現できる場合は、インラインシェルコマンドで PL/pgSQL の DO $$ ブロックを使用しないでください。
• :'var' の変数展開には、psql -c "..." を使用しないでください。psql -v name=value <<'SQL' ... :'name' ... SQL を使用するか、安全なリテラル SQL を渡してください。

ステップ 6：出力ファイルを生成する

必ず次を生成します。

• template/<app-name>/index.yaml
• 公式アイコンを特定できる場合は template/<app-name>/logo.<ext>。正方形／円形でアイコンを主体とするアートワークを優先し、長方形のワードマーク／テキストロゴは避けてください。

次のファイルは作成しないでください。

• template/<app-name>/README.md
• template/<app-name>/README_zh.md

README の作成はこのスキルの対象外です。Template CR で README の URL が必要な場合は、index.yaml の URL フィールドにのみ入力し、ファイルの作成は専用の README スキルに任せてください。

ステップ 7：出力前に検証する

テンプレートを出力する前に、バリデーターとセルフテストを実行してください。 検証に失敗した場合は、テンプレート／ルール／例を先に修正してください。

MUST ルール（要約）

名前とメタデータ

• テンプレートの metadata.name は小文字で直接指定してください。${{ defaults.app_name }} は使用しないでください。
• テンプレートの CR フォルダー名は metadata.name と一致させてください。
• テンプレートの CR には、必須のメタデータフィールド（title、url、gitRepo、author、description、icon、templateType、locale、i18n、categories）を含めてください。
• テンプレートの spec.readme は https://raw.githubusercontent.com/labring-actions/templates/kb-0.9/template/<app-name>/README.md を参照するようにしてください。
• テンプレートの spec.i18n.zh.readme は https://raw.githubusercontent.com/labring-actions/templates/kb-0.9/template/<app-name>/README_zh.md を参照するようにしてください。
• これらの README フィールドは index.yaml 内の URL 参照にすぎません。このスキルでは、参照先の README ファイルを作成または更新しないでください。
• icon URL は、kb-0.9 ブランチにある、このアプリのテンプレートリポジトリ内の raw パスを指す必要があります。
• template/<app-name>/logo.<ext> には、アイコンを主役にした正方形または円形の画像（アプリアイコン、ファビコン、アバターなど）を使用してください。長方形のワードマークやテキストロゴは使用しないでください。
• i18n.zh.description は簡体字中国語で記述してください。
• i18n.zh.title が title と同一の場合は省略してください。
• categories には、定義済みの値（tool、ai、game、database、low-code、monitor、dev-ops、blog、storage、frontend、backend）のみを使用してください。

App リソース

• App リソースでは spec.data.url を使用する必要があります。
• App リソースの spec.displayType は normal である必要があります。
• App リソースの spec.type は link である必要があります。
• App リソースの spec.data.url には、新規の Sealos 起動後にアクセスできるブラウザーのエントリー URL を指定する必要があります。アプリに safe-path、setup-path、または entrance-path の動作がある場合は、設定されたパスとルートパスを確認し、事前の非表示のページ遷移なしでログインまたは初回セットアップが可能な URL を選択してください。
• SSR／Next.js／React のサーバーアプリでは、サーバー側の例外を表示するパスを App URL または HTTP プローブに使用しないでください。HTTP ステータスが 2xx／3xx であっても、Application error、server-side exception、Internal Server Error、または Unhandled Runtime Error のテキストが表示される場合、そのエントリーパスは失敗とみなしてください。
• App リソースでは spec.template を使用しないでください。
• cloud.sealos.io/app-deploy-manager ラベルの値は、リソースの metadata.name と一致する必要があります。
• 管理対象のアプリワークロードでは、metadata.labels.app ラベルの値はリソースの metadata.name と一致する必要があります。
• 管理対象のアプリワークロードでは、プライマリのビジネスコンテナー名はワークロードの metadata.name と一致する必要があります。サイドカー／ヘルパーコンテナーには、異なる説明的な名前を使用できます。
• アプリケーションの Service リソースには metadata.labels.app と metadata.labels.cloud.sealos.io/app-deploy-manager を定義し、両方のラベルを spec.selector.app と一致させる必要があります。
• 実行時のコンポーネントスコープの ConfigMap リソースには metadata.labels.app と metadata.labels.cloud.sealos.io/app-deploy-manager を定義し、両方のラベルを metadata.name と一致させる必要があります。初期設定を永続ストレージにコピーするために init コンテナーだけが使用するブートストラップ専用の ConfigMap では、どちらのラベルも定義しないでください。
• アプリケーションの Service リソースでは、metadata.name、metadata.labels.app、metadata.labels.cloud.sealos.io/app-deploy-manager、および spec.selector.app で同じコンポーネント名を使用する必要があります。
• ルートパスの Ingress リソース（pathType: Prefix、path: /）では、metadata.name、metadata.labels.cloud.sealos.io/app-deploy-manager、およびバックエンドの service.name で同じコンポーネント名を使用する必要があります。ルート以外のパス、または Prefix 以外の Ingress ルールでは、別のバックエンドサービスにルーティングできます。
• Service の spec.ports[*].name は明示的に設定する必要があります（複数ポートのサービスでは必須です）。
• HTTP Ingress には、必要な nginx アノテーション（kubernetes.io/ingress.class、nginx.ingress.kubernetes.io/proxy-body-size、nginx.ingress.kubernetes.io/server-snippet、nginx.ingress.kubernetes.io/ssl-redirect、nginx.ingress.kubernetes.io/backend-protocol、nginx.ingress.kubernetes.io/client-body-buffer-size、nginx.ingress.kubernetes.io/proxy-buffer-size、nginx.ingress.kubernetes.io/proxy-send-timeout、nginx.ingress.kubernetes.io/proxy-read-timeout、nginx.ingress.kubernetes.io/configuration-snippet）を、想定されるデフォルト値で含める必要があります。
• CronJob リソースには cloud.sealos.io/cronjob、cronjob-launchpad-name、および cronjob-type のラベルを定義する必要があります。cloud.sealos.io/cronjob は metadata.name と一致し、cronjob-launchpad-name は ""、cronjob-type は image である必要があります。
• アプリケーションの公式ヘルスチェックが利用可能な場合、管理対象のワークロードには、公式のエンドポイント／コマンドに合わせて livenessProbe、readinessProbe、および（ブートストラップに時間がかかるアプリでは）startupProbe を定義する必要があります。

公式 Kubernetes との整合性

• 公式の Kubernetes インストールドキュメント／マニフェストが利用可能な場合、変換時にはそれらを参照し、テンプレートアーティファクトを出力する前に、重要な実行時設定を整合させる必要があります。
• 公式の Kubernetes ドキュメント／マニフェストと Compose の内容が異なる場合は、優先度の高い Sealos の MUST／セキュリティ要件に反しない限り、アプリの動作については公式 Kubernetes の実行時セマンティクス（ブートストラップ時の管理者フィールド、外部エンドポイント／環境変数／プロトコル、ヘルスプローブ）を優先してください。

イメージとプルポリシー

• :latest は使用しないでください。
• crane でバージョンを解決してください。明示的なバージョンタグ（例：v2.2.0）を優先し、決定的なバージョンタグがない場合に限り、ダイジェストで固定してください。
• 浮動タグ（例：:v2、:2.1、:stable）は避け、明示的なバージョンタグまたはダイジェストを使用してください。
• 管理対象ワークロードのイメージ参照は具体的な値にし、Compose 形式の変数式（例：${VAR}、${VAR:-default}）を含めないでください。テンプレート成果物を出力する前に、明示的なタグまたはダイジェストに解決してください。
• アプリケーションの originImageName はコンテナイメージと一致させてください。
• パブリックイメージを使用する管理対象アプリのワークロードでは、template.spec.imagePullSecrets を省略してください。プライベートレジストリのワークロードでは、アプリスコープのプル Secret ${{ defaults.app_name }} のみを参照できます。
• レジストリのプル Secret は、プライベート GHCR イメージ用のローカル gh CLI 認証情報を使用して、実行時に sealos-deploy が管理します。生成するテンプレートにレジストリ認証情報の生入力を含めないでください。
• すべてのコンテナで imagePullPolicy: IfNotPresent を明示的に設定してください。

ストレージ

• emptyDir は使用しないでください。
• ストレージが必要な場合は、永続ストレージパターン（volumeClaimTemplates）を使用してください。
• volumeClaimTemplates を持つ StatefulSet リソースでは、Template が PVC を追跡してクリーンアップできるよう、metadata.labels.cloud.sealos.io/deploy-on-sealos: ${{ defaults.app_name }} と、すべての volumeClaimTemplates[].metadata.labels.cloud.sealos.io/deploy-on-sealos: ${{ defaults.app_name }} を設定してください。
• PVC の要求サイズは、ソース仕様でそれより小さいサイズが明示的に指定されている場合を除き、<= 1Gi にしてください。
• ConfigMap のデータキーは、scripts/path_converter.py のような vn 命名規則に従い、/、-、. などの特殊文字も含めてください。
• 管理対象の Deployment／StatefulSet ワークロードでマウントする ConfigMap は、metadata.name == workload.metadata.name にしてください。
• ConfigMap を使用するワークロードのボリューム名は <workload-name>-cm にしてください。また、すべての ConfigMap data キーをそれぞれ独立した volumeMount としてマウントし、subPath をキーと完全に一致させてください。
• command／args に長い起動スクリプトやヒアドキュメントを直接記述しないでください。初期化スクリプトや起動スクリプトは ConfigMap ファイルに配置し、短いコマンドで実行してください。

環境変数とシークレット

• データベース以外の機密値／入力値には、直接 env[].value を使用します。
• ビジネスコンテナでは、データベース接続フィールド（endpoint、host、port、username、password）を、承認済みの Kubeblocks データベースシークレットから env[].valueFrom.secretKeyRef を使って取得する必要があります。例外として、Redis シークレットに認証情報しか含まれない場合は、Redis の host／port に Sealos Redis Service FQDN と 6379 を使用できます。また、MongoDB シークレットに認証情報しか含まれない場合は、MongoDB 接続 URL に Sealos MongoDB Service FQDN と 27017 を使用できます。
• ビジネスコンテナでは、承認済みの Kubeblocks データベースシークレットとオブジェクトストレージシークレットを除き、カスタムの環境変数／ボリュームの Secret 参照を使用してはいけません。
• 専用のアプリスコープのレジストリプルシークレットは、プライベートレジストリのイメージに限り使用できます。また、参照箇所は template.spec.imagePullSecrets のみにしてください。パブリックイメージにプルシークレットを追加してはいけません。
• データベースの接続／ブートストラップには Kubeblocks 提供のシークレットを使用できます。また、予約済みの Kubeblocks データベースシークレット名をカスタムの Secret リソースで再定義してはいけません。
• 環境変数は、参照する前に宣言する必要があります（例：URL を組み立てる前にパスワードを宣言します）。
• アプリの公式な環境変数の命名規則に従い、独自のプレフィックスを作成してはいけません。
• フロントエンド／API／ゲートウェイが分かれたアプリでは、公開ブラウザー URL と内部サービス URL を分けてください。フロントエンド／ブラウザーのコールバック変数には https://${{ defaults.<host> }}.${{ SEALOS_CLOUD_DOMAIN }} を使用し、バックエンド間の変数には http://<service>.$(SEALOS_NAMESPACE).svc.cluster.local:<port> または完全に展開された Service FQDN を使用します。
• アプリでファイルベースの設定システム（例：node-config の config/default.json、PHP 設定ファイル）を通じて公開 URL を設定する必要がある場合は、公開 URL を https://${{ defaults.app_host }}.${{ SEALOS_CLOUD_DOMAIN }} に設定した設定ファイルを含む ConfigMap を作成し、アプリの設定ディレクトリにマウントします。ConfigMap は標準の命名規則とラベル規則に従う必要があります。
• PostgreSQL のカスタムデータベース（postgres 以外）では、${{ defaults.app_name }}-pg-init Job を含め、起動時の安全性と冪等性を備えた作成ロジック（起動可能状態の待機＋作成前の存在確認）を実装してください。
• アプリ固有のデータベース互換性のため、ビジネスコンテナの起動前に必要なビュー、エイリアス、インデックス、拡張機能、権限、ロールの search_path、旧バージョンとの互換オブジェクトを冪等に作成または修復する initContainer または起動ゲートを含めてください。
• 管理対象アプリのメインコンテナの command／args は、イメージの公式エントリーポイントから大きく逸脱させてはいけません。公式の起動コマンド、Compose ネイティブの引数、または短い exec ラッパーのみを使用してください。ファイルの準備、権限の修復、データベースのブートストラップ、互換性の自己修復は、initContainer、Job、または ConfigMap スクリプトに移してください。
• メインのビジネスコンテナ内のシェルラッパーでは、シグナル処理が正しく行われるよう、最後のプロセスを exec で起動する必要があります。
• データベースのブートストラップ SQL は、シェル実行時にも安全でなければなりません。シェルレベルのガードクエリとシンプルな SQL を優先し、psql 変数を使用する場合はシングルクォート付きの heredoc を使い、無条件のインライン DO $$ ブロックは避けてください。
• psql -c に :'var' 形式の psql 変数構文を含めてはいけません。-v による補間が必要な SQL には heredoc を使用してください。

データベース固有の制約

• データベースサービスには、アプリケーションの Deployment や StatefulSet ワークロードではなく、KubeBlocks の Cluster リソースを使用する必要があります。StatefulSet はステートフルなアプリケーションコンポーネントには使用できますが、PostgreSQL/MySQL/MongoDB/Redis/Kafka のデータベースサービスには使用できません。
• PostgreSQL のバージョン：postgresql-16.4.0。
• PostgreSQL API：apps.kubeblocks.io/v1alpha1。
• PostgreSQL RBAC の統一された命名規則：${{ defaults.app_name }}-pg。
• PostgreSQL RBAC には、app.kubernetes.io/instance と app.kubernetes.io/managed-by のラベルが必要です。
• すべての KubeBlocks データベース Cluster には、kb.io/database、sealos-db-provider-cr、clusterdefinition.kubeblocks.io/name のラベルを含める必要があります。sealos-db-provider-cr は、dbprovider がデータベースを一覧表示して分類できるよう、metadata.name と一致させる必要があります。詳細ビューで表示するため、関連する Pod、Service、OpsRequest には app.kubernetes.io/instance=<database name> を設定してください。
• PostgreSQL ロールのワイルドカード権限要件は、現行の仕様で定義されているとおりです。
• PostgreSQL クラスターには、必須のラベルとフィールド（kb.io/database: postgresql-16.4.0、clusterdefinition.kubeblocks.io/name: postgresql、clusterversion.kubeblocks.io/name: postgresql-16.4.0、clusterVersionRef: postgresql-16.4.0、disableExporter: true、enabledLogs: [running]、switchPolicy.type: Noop、serviceAccountName）を含める必要があります。
• MongoDB クラスターは、アップグレード後の構造（componentDef: mongodb、serviceVersion: 8.0.4、kb.io/database と app.kubernetes.io/instance のラベル）に従う必要があります。
• MySQL クラスターは、アップグレード後の構造（kb.io/database: ac-mysql-8.0.30-1、clusterDefinitionRef: apecloud-mysql、clusterVersionRef: ac-mysql-8.0.30-1、tolerations: []）に従う必要があります。
• Redis クラスターは、アップグレード後の構造（componentDef: redis-7、componentDef: redis-sentinel-7、serviceVersion: 7.2.7、メインデータ PVC 1Gi、トポロジー replication）に従う必要があります。
• データベースクラスターのコンポーネントリソースには、ソースドキュメントで別途明示されていない限り、limits(cpu=500m,memory=512Mi) と requests(cpu=50m,memory=51Mi) を使用する必要があります。
• 管理対象のすべてのワークロードコンテナリソースには、Sealos のリソース段階を使用する必要があります。limits.cpu は 100m/200m/500m/1/2/3/4/8 のみ、limits.memory は 128Mi/256Mi/512Mi/1024Mi/2048Mi/4096Mi/8192Mi/16384Mi のみ使用できます。また、requests は limits から末尾の数字を1桁削って算出する必要があります（500m→50m、512Mi→51Mi、1→100m、1024Mi→102Mi、4096Mi→409Mi）。段階外の値を独自に設定しないでください。また、Sealos Template API のクォータプレビューで単位のない G が付いたメモリ値を 0 として解析する可能性があるため、2G/4G/8G/16G は使用しないでください。
• Secret の命名規則：
  • MongoDB：${{ defaults.app_name }}-mongo-mongodb-account-root（MongoDB クラスター名が -mongodb を使用する場合は ${{ defaults.app_name }}-mongodb-mongodb-account-root）
  • Redis：${{ defaults.app_name }}-redis-redis-account-default（後方互換性のため、旧形式の ${{ defaults.app_name }}-redis-account-default も許容される場合があります）
  • Kafka：${{ defaults.app_name }}-broker-account-admin
  • サポート対象の例外を除き、旧形式の命名規則は使用しないでください。

ベースラインのランタイム既定値

ソースドキュメントで別途明示されていない限り、軽量アプリケーション向けのリソース段階を使用してください。

• コンテナの limits：cpu=200m、memory=256Mi
• コンテナの requests：cpu=20m、memory=25Mi
• revisionHistoryLimit: 1
• 既定では automountServiceAccountToken: false にします。Kubernetes 統合設定、serviceAccountName、または sealos.io/service-account-token-reason ワークロードアノテーションによって、アプリケーションに Kubernetes API／サービスアカウントトークンの明示的な要件があることが確認できる場合に限り、true に設定してください。

より多くのリソースが必要な場合は、許可された別の limits の段階にのみ移行し、その limits の値から requests を再計算してください。

ブラウザー／リモートデスクトップリソースの検証

ブラウザー、VNC、WebRTC デスクトップ、Xvfb、Selkies、noVNC、Kasm、またはリモートデスクトップ形式のコンテナの場合：

• 短時間のスモークテストを、安定した最小メモリ値の証明として扱わないでください。
• パッチ適用済みのウォームポッドだけでなく、新規デプロイでメモリを検証してください。
• コールドスタートからレディネス状態になるまで、軽量なページ、実際の／中程度のページ、インタラクティブな／検索ページ、およびスモークテスト後の60秒間の安定性チェックを実施してください。
• スモークテスト中に観測された cgroup メモリ使用量が制限値の80%を超えた場合は、次に許可されている Sealos メモリラダーの値に引き上げてください。
• Sealos リソースラダーに従って、制限値を基にリクエスト値を設定してください。

例：

• 悪い例：Chrome が 512Mi で短時間のスモークテストに合格しても、使用量が 503Mi に達する場合、安定した最小値として 512Mi を採用するのは安全ではありません。
• 良い例：1024Mi に引き上げ、リクエストを 102Mi に設定し、スモークテストと安定性チェックを再実行します。

最大表示解像度が4Kの Chrome + Xvfb + Selkies では、少なくとも次を使用してください：

• limits: cpu=200m, memory=1024Mi
• requests: cpu=20m, memory=102Mi

デフォルト値と入力値

• 生成値（app_name、app_host、ランダムなパスワード／キー）には defaults を使用します。
• inputs は、ユーザーが実際に指定する運用値（メールアドレス／SMTP／外部 API キーなど）にのみ使用します。
• ユーザーがアプリケーションの管理者認証情報の入力を明示的に求める場合は、管理者のユーザー名／パスワードを spec.inputs で宣言し、直接の env 値として渡して、アプリケーションのドキュメントに記載されたブートストラップまたは初期化手順で適用してください。データベースの認証情報は KubeBlocks のシークレットに保存してください。
• テンプレート成果物内のすべての ${{ inputs.<name> }} 参照について、同じ Template CR 内に対応する spec.inputs.<name> 宣言が必要です。
• inputs.description は英語で記述してください。
• 起動に不可欠な inputs[*].default 値は、アプリケーションのドキュメントに記載された起動時の検証条件を満たす必要があります。複雑さの条件がある管理者／ブートストラップ用パスワードには、''、脆弱な例、または単独の ${{ random(n) }} を使用しないでください。生成される文字に必須の文字種が含まれるとは限らないためです。たとえば、ランダムな部分の前後に必須の文字種を含む決定的な文字列を付けてください（例："AppName@${{ random(16) }}!1"）。
• 必須の入力値が脆弱または空の場合にアプリケーションが終了するなら、入力のデフォルト値をランタイム契約の一部として扱ってください。実環境での検証では、生成されたデフォルト値を使って、初回起動時のログとログイン／セットアップ手順を確認してください。
• バイナリオブジェクトストレージを選択する場合は、ブール値の入力（例：enable_s3_storage）を使い、inputs.<name> === 'true' でテストしてください。

検証コマンド

最終回答の前に、すべてのチェックを実行してください：

1. python scripts/path_converter.py --self-test
2. python scripts/test_check_consistency.py
3. python scripts/test_compose_to_template.py
4. python scripts/test_check_must_coverage.py
5. python scripts/check_consistency.py --skill SKILL.md --references references --rules-file references/rules-registry.yaml
6. python scripts/check_consistency.py --skill SKILL.md --references references --rules-file references/rules-registry.yaml --artifacts template/<app-name>/index.yaml
7. python scripts/check_must_coverage.py --skill SKILL.md --mapping references/must-rules-map.yaml --rules-file references/rules-registry.yaml
8. （CI／一括実行）python scripts/quality_gate.py（デフォルトで template/*/index.yaml が必要です。成果物がない状態で開発／デバッグを行う場合に限り、DOCKER_TO_SEALOS_ALLOW_EMPTY_ARTIFACTS=1 を設定してください）
9. ライブデプロイの受け入れ確認：sealos-deploy でアプリを作成した後、成功を報告する前に、実際の App URL、Web アプリのログイン／セットアップ手順、最新のログ、期待されるデータベースオブジェクト、およびリソースの使用状況全体を確認してください。

check_consistency.py はレジストリ駆動型です。references/rules-registry.yaml を実装済みのルールと同期させてください。 レジストリのルール項目では、severity と、任意の scope.include_paths メタデータを設定できます。

出力契約

変換が完了したら、次の内容を提示します。

1. 変換の簡潔な概要
2. 対象ファイルのパス（template/<app-name>/index.yaml）
3. テンプレート YAML 全体
4. 曖昧さがあった場合に限り、主な判断内容

このスキルでは README の内容を作成または出力しないでください。README の生成は別のスキルに委任されています。

参照資料の確認（段階的な読み込み）

現在のタスクに必要な参照資料のみを読み込みます。

• references/sealos-specs.md
  • 順序、ラベル、App／Ingress／ConfigMap の規約に関する正式な仕様
• references/conversion-mappings.md
  • Docker から Sealos へのフィールド単位のマッピングと、境界ケースの変換
• references/database-templates.md
  • データベースのテンプレート、RBAC 構造、シークレットの命名パターン
• references/frappe-bench.md
  • Frappe／ERPNext／HRMS／bench の変換パターン、init リソース、冪等性のあるサイトのブートストラップ、一般的な障害の兆候
• references/example-guide.md
  • 例とパターンの解説（正式な仕様ではありません）
• references/rules-registry.yaml
  • 機械可読な検証対象範囲／ルール一覧
• references/must-rules-map.yaml
  • MUST 項目と適用ルールの対応表（ドリフト制御用の rule または manual）

スクリプトユーティリティ

• scripts/path_converter.py
  • パスを vn 名に変換します
  • 回帰チェック用のセルフテストに対応しています
• scripts/compose_to_template.py
  • compose／ドキュメントからテンプレートを決定論的に生成するエントリーポイントです
  • --kompose-mode auto|always|never をサポートします（既定値は always）。kompose convert のワークロード構造を再利用します
  • template/<app-name>/index.yaml を出力します
• scripts/test_compose_to_template.py
  • compose 変換動作の回帰テスト
• scripts/check_consistency.py
  • レジストリに基づく整合性バリデーター
• scripts/test_check_consistency.py
  • バリデーター動作の回帰テスト
• scripts/check_must_coverage.py
  • MUST 項目の対応表とレジストリルールを照合して検証します
• scripts/test_check_must_coverage.py
  • MUST 項目の対応表バリデーターの回帰テスト

境界ポリシー

• 不足しているフィールドについて、ユーザーに尋ねてはいけません。compose／ドキュメントとプラットフォームの規約から推定してください。
• App リソースは spec.data.url 形式にし、spec.template は使用しないでください。
• App リソースは spec.displayType: normal と spec.type: link にしてください。別の列挙値を推定してはいけません。
• ビジネス環境変数、オブジェクトストレージ、DB シークレットのポリシーは MUST ルールに準拠させてください。
• 正方形／円形のアイコンを優先したロゴ素材（アプリアイコン／favicon／アバター）を使用し、長方形のワードマークやテキストロゴは避けてください。
• 同梱のエッジプロキシより Sealos 管理の Ingress を優先します。Traefik ゲートウェイが Ingress／フロントプロキシとしてのみ機能し、ビジネスサービスが 1 つ以上存在する場合、Traefik のワークロードリソースは出力しないでください。
• コンテナ内の TLS より、Sealos Ingress でのゲートウェイ TLS 終端を優先します。HTTP／HTTPS のデュアルポートワークロードでは、HTTP サービスポートを残し、公式ドキュメントで HTTPS バックエンドが必須とされていない限り、冗長な HTTPS／証明書のマウントを削除してください。
• template/<app-name>/README.md または template/<app-name>/README_zh.md を作成してはいけません。テンプレートスキーマで必要な場合に限り、index.yaml 内の README URL 参照を残してください。
• 矛盾が見つかった場合は、例外を追加するより、参照資料や例を修正してください。
• 対象アプリの公式な Kubernetes インストールドキュメント／マニフェストがある場合は、無視してはいけません。Compose の既定値を超える実行時の動作を調整するために使用してください。
• プロジェクトで Frappe、ERPNext、HRMS、または bench に言及している場合、アプリのワークロードを生成する前に references/frappe-bench.md を読み込んでください。