Convert Docker Compose files or installation docs into production-grade Sealos templates with role-specific personal low-load resource sizing, official route and runtime semantics, KubeBlocks database and Job gates, and managed or optional S3 storage contracts. Use when user has a docker-compose.yml

Docker to Sealos Template Converter Identity and Discovery Owner: docker to sealos ( /docker to sealos and Compose, install doc, or Sealos template conversion requests). Class: local artifact mutation with a validated template handoff to sealos deploy . Canaries: DTS RULE PRECEDENCE , DTS MUST MAP , and DTS QUALITY GATE . Scope and Boundaries Accept Docker Compose, installation documentation, or an existing template update request and write the named template artifact under template/<app /index.yaml plus owned validator evidence. Do not perform a live cloud mutation. Keep rule provenance, database topology, resource order, declared inputs, and secret boundaries inside this skill. A template is a handoff candidate only after all required gates pass. Risk and Confirmation The governance order remains entry MUST rules, Sealos specs/database templates, then mappings/examples. references/must rules map.yaml and references/rules registry.yaml are coupled load bearing sources. Public exposure, destructive changes, credential changes, and system tool installation retain explicit confirmation; generated values and connection data remain redacted. Lifecycle Workflow For each request, analyze input, infer metadata, plan resources, apply conversion rules, validate the final artifact, and hand off only after the complete quality gate passes. Emit request scoped success , stopped , or error ; each result carries source provenance, artifact paths, validator evidence, and redaction status. The existing analysis → inference → resource planning → conversion workflow remains the domain extension below. Progressive Disclosure Load the relevant owned reference family one level deep after the core canaries are visible. Preserve the MUST map and rules registry coupling, rule precedence, and existing validator scripts; do not replace them with a generic converter or railpack build path. Output, Stop, and Error States success : source/provenance, final Template YAML, conversion summary, declared inputs, topology/storage/database evidence, consistency/MUST map/registry/quality gate evidence, and redaction result. stopped : missing input, unresolved source, or confirmation boundary with observed evidence, redaction result, and safe next action; do not hand off an unvalidated artifact. error : failed rule, registry, topology, artifact, or quality gate with named source/artifact, sanitized diagnostic, redaction result, and recovery action. Handoffs Send the complete typed handoff below for direct conversion. Deploy re checks its own auth, scope, and Runtime Truth gates. Verification Run consistency, MUST coverage, and quality gate.py against the exact final template. Use baseline cases docker to sealos positive quality gate and docker to sealos violating missing rule ; missing registry/MUST evidence blocks deployment. Overview Convert Docker Compose files or installation docs into production grade Sealos templates. Execute analysis, conversion, validation, and output automatically when the required inputs and confirmations exist; stop with a safe next action when a required input or gated operation is unresolved. Governance and Rule Priority Use the following precedence to prevent rule drift: 1. SKILL.md MUST rules (this file) 2. references/sealos specs.md and references/database templates.md 3. references/conversion mappings.md and references/example guide.md If lower priority references conflict with higher priority MUST rules, update the lower priority files. Do not keep conflicting examples. Source Precedence and Branch Boundary Use this source precedence for every conversion and record the selected source in the conversion report: 1. Existing template topology and explicit user intent for an update. 2. Entry MUST rules and the coupled must rules map.yaml / rules registry.yaml . 3. Official Kubernetes installation/runtime documentation. 4. Compose or install documentation selected for the request. 5. Repository config, README, Dockerfile, and lockfile evidence. 6. Normalized analysis.json.build environment evidence when the prepare only branch supplies it. Raw Railpack JSON is not a conversion source. On brain deploy preview , retain explicit config/README/Dockerfile/lockfile precedence, consume normalized build environment evidence, and keep the Dockerfile plus sandbox Kaniko path. The preview flow does not replace this path with railpack build , BuildKit, or live deployment behavior. Conversion Payload Keep this payload request scoped and repository relative so deploy can reuse the discovery result: The payload and final artifacts contain no passwords, tokens, kubeconfig contents, environment values, complete connection strings, or validator only secrets. Workflow Step 1: Analyze input Extract from Docker Compose/docs: application services vs database services volumes/config mounts/object storage requirements ports, dependencies, service communication env vars and secret usage startup time validation rules for bootstrap credentials, API keys, salts, secrets, and feature flags account bootstrap mode from the exact selected release: functional first user signup, mandatory bootstrap credentials, or optional root reconciliation/bootstrap multi service web roles: browser entry, REST API, OpenAI/API gateway, docs, workers, and one shot jobs resource limits/requests and health checks if official Kubernetes installation docs/manifests are available, also extract app runtime behavior from them (bootstrap admin fields, external endpoint/protocol assumptions, health probes, startup/init flow, migration ordering) if official compose/docs provide multiple cooperating services, record the official runtime bundle source, component list, image versions, public entry routes, and critical env vars record the selected source topology: topology bearing resource roles, feature conditions, and application or database component replica counts Step 2: Infer metadata Infer and normalize: app name, title, description, categories official URL, gitRepo, icon source (prefer square/circular icon first assets such as app icons, favicons, or avatars; avoid rectangular wordmark/text logos) locale/i18n metadata Step 3: Plan resources in strict order Generate resources in this order: 1. Template CR 2. ObjectStorageBucket (if needed) 3. Database resources (ServiceAccount → Role → RoleBinding → Cluster → Job if needed) 4. App workload resources (ConfigMap/Secret → Deployment/StatefulSet → Service → Ingress) 5. App resource (last) Step 4: Apply conversion rules Apply field level mappings from references/conversion mappings.md , including: image pinning and annotation mapping port/service/ingress conversion env var conversion and dependency ordering storage conversion and vn naming ( scripts/path converter.py ) service name to Kubernetes FQDN conversion for DB URL/DSN envs (for example DATABASE URL , DB URL ), when Kubeblocks endpoint is host:port, inject host / port / username / password via approved secretKeyRef envs and compose the final URL with $(VAR) expansion edge gateway normalization: when Compose includes Traefik like edge proxy plus business services, skip the proxy workload and expose business services via Sealos Ingress directly TLS offload normalization for Sealos Ingress: when a business service exposes both 80 and 443, drop 443 from workload/service ports and remove in container TLS certificate mounts (for example /etc/nginx/ssl , /etc/ssl , /certs ) unless official Kubernetes docs explicitly require HTTPS backend to service traffic multi service web normalization: expose the verified browser entry in the App resource, expose API/gateway/docs only when they are intended public surfaces, and keep workers private with no Service/Ingress URL topology: browser facing env vars must use public HTTPS URLs, while server to server env vars must use Kubernetes Service FQDNs unless the app explicitly requires public callbacks WebSocket ingress normalization: when the public entry is ws:// , wss:// , CDP/Chrome DevTools, a game socket, or a WebSocket named port/service, expose it with WebSocket nginx ingress annotations StatefulSet service identity: for a single component app with no documented headless or stable per Pod DNS requirement, use the public application Service as spec.serviceName and keep the workload, Service, root Ingress, and manager identity aligned; preserve documented HA/headless governing Services and expose them through a separate public application Service prefer scripts/compose to template.py kompose mode always as deterministic conversion entrypoint (require kompose for reproducible workload shaping) for existing template updates, keep the current template's topology bearing resources, feature conditions, and replica counts as the baseline for new conversions, keep the selected Compose services and deploy.replicas values as the topology baseline use official Kubernetes installation docs/manifests to align app runtime semantics such as bootstrap fields, endpoints, probes, and startup ordering keep optional or recommended workers, caches, and HA replicas outside the emitted topology unless the selected source topology or explicit user intent includes them keep every feature input scoped to its documented capability; database and object storage inputs must not add unrelated workloads, caches, or replicas when official compose/docs define a multi component runtime bundle, keep runtime required components, entry routes, critical env vars, and component image versions aligned to one official release/compose source before converting a host directory mount to persistent storage, verify whether the image already ships required files at that target path; avoid hiding image bundled manifests, dependency lists, or config defaults behind a fresh empty PVC Step 5: Apply database strategy Database services must be generated as KubeBlocks Cluster resources. Do not convert PostgreSQL/MySQL/MongoDB/Redis/Kafka Compose database services into raw Kubernetes Deployment or StatefulSet workloads. PostgreSQL must follow the pinned version and structure requirements. MySQL/MongoDB/Redis/Kafka must use templates and secret naming from references/database templates.md . Add DB init Job/initContainer when application database bootstrap requires it. For PostgreSQL custom databases (non postgres ), the init Job must wait for PostgreSQL readiness before execution and create the target database idempotently. Database client images may be used in app initContainers and init/migration/bootstrap Jobs for readiness and bootstrap gates. Critical application compatibility objects must be verified in live database state. Use idempotent initContainer self healing for compatibility views, legacy tables/views, indexes, extensions, search paths, and bootstrap state that the app requires on every cold start. One shot init Jobs may create initial databases or seed state, but app startup gates must verify the final database objects directly. Treat TTL expired Jobs as historical evidence and rely on database state for acceptance. Worker, gateway, and background services that depend on app migrations must wait for the required tables, migration markers, or app specific readiness objects, not only for the database port. Redis readiness probes or initContainers must tolerate authenticated Redis responses such as NOAUTH or Authentication required when credentials are not needed for readiness. PostgreSQL bootstrap shell must use safe quoting patterns. Prefer shell level existence checks plus simple SQL statements when possible. Use single quoted heredocs or SQL files for psql variable interpolation, and avoid PL/pgSQL DO $$ blocks in inline shell commands when a guard query c

docker-to-sealos