[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6C48SPTARDXPM7F0EH2RRF1":3,"skill-same:01M6C48SPTARDXPM7F0EH2RRF1":66},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":34,"linkOnly":35,"markdownContent":36,"markdownBody":37,"frontMatter":38,"refName":44,"commitSha":45,"skillDirectory":5,"forksCount":46,"repositoryHtmlUrl":47,"repositoryHomepageUrl":6,"ownerHtmlUrl":48,"ownerBlogUrl":49,"ownerDescription":50,"updatedAt":51,"install":52,"resources":65},"01M6C48SPTARDXPM7F0EH2RRF1","dockerization",null,"Official Stakpak application containerization standard operating procedure, a step-by-step guidline to properly dockerize applications. This is a rule book curated by the Stakpak Team.","stakpak\u002Fcommunity-paks","stakpak","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F86326525?v=4","01M6C48005ADA10YG0BQQX0J4Q","Stakpak","01M6C4804JD6KKZR9AQ9TYS0BT",4,"MIT","https:\u002F\u002Fgithub.com\u002Fstakpak\u002Fcommunity-paks\u002Fblob\u002Fmain\u002Fdockerization\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署","SCENARIO","使用场景",[5,24,25,26,27,28,29,30,31,32,33],"docker","official","dev","cloud","applications","team","container","containerization","compose","cloud-native","2026-11-10 10:12:30",false,"---\nname: dockerization\ndescription: |\n  Official Stakpak application containerization standard operating procedure, a step-by-step guidline to properly dockerize applications. This is a rule book curated by the Stakpak Team.\nlicense: MIT\ntags:\n  - dockerization\n  - containerization\n  - docker\n  - compose\n  - cloud-native\n  - container\nmetadata:\n  author: Stakpak \u003Cteam@stakpak.dev>\n  version: \"1.0.2\"\n---\n\n# Application Dockerization RuleBook\n\n## Core Principles\n\n* **Analysis First**: Thoroughly examine application before starting work\n* **User Collaboration**: Involve users in decisions, avoid assumptions, confirm critical choices\n* **Documentation**: Record all configurations, generated values, and requirements\n* **Efficiency**: Use available tools and information before requesting input\n* **Error Analysis**: Identify root causes before retrying failed operations\n\n## Mandatory 9-Phase Workflow\n\n### 1. Application Analysis\n\n* Examine directory structure and key files\n* Identify programming language, framework, and dependencies\n* Document external services (databases, cache, message queues)\n* Create file\u002Fpurpose mapping table\n* Accumulate findings progressively\n\n### 2. Base Image Selection\n\n* Prefer official Docker Hub images\n* Choose Alpine\u002Fslim variants for smaller size\n* Consider security update frequency\n* Create comparison table with pros\u002Fcons\n* Document selection rationale\n\n### 3. Dockerfile Creation\n\n* Use multi-stage builds when applicable\n* Configure non-root user for security\n* Optimize layer caching and minimize size\n* Implement health checks\n* Address security concerns explicitly\n\n### 4. Docker Compose Configuration\n\n* Include application and dependent services\n* Configure networks and volumes properly\n* Set environment variables and secrets\n* Omit obsolete 'version' attribute\n* Enable service dependencies and restart policies\n\n### 5. Build Process\n\n* Use `docker compose build` (preferred method)\n* Tag images with human-readable names\n* Implement comprehensive .dockerignore file\n* Document build commands and process\n* Handle build errors systematically\n\n### 6. Container Execution\n\n* Start with `docker compose up -d`\n* Verify all services start successfully\n* Apply database migrations if required\n* Check container status and logs\n* Ensure port mappings work correctly\n\n### 7. Health Verification\n\n* Check container status and logs\n* Test application endpoints (expect 200 status)\n* Verify dependent service connectivity\n* Monitor resource usage\n* Consider network accessibility (avoid localhost assumptions)\n\n### 8. Resource Cleanup\n\n* Stop containers with `docker compose down`\n* Remove unnecessary volumes and images\n* Clean build cache and temporary files\n* Document cleanup procedures\n* Verify complete resource removal\n\n### 9. Documentation\n\n* List all required environment variables\n* Identify secrets and sensitive configurations\n* Document deployment and migration steps\n* Provide troubleshooting guidance\n* Create final summary report\n\n## Security Requirements\n\n* **Never run as root user**\n* Use specific image tags (avoid 'latest')\n* Implement proper .dockerignore\n* Store secrets securely (not in image layers)\n* Scan for vulnerabilities regularly\n* Set resource limits appropriately\n* Use minimal base images\n\n## Error Handling Guidelines\n\n* **Build Failures**: Analyze error messages, check Dockerfile syntax, verify base image availability\n* **Runtime Failures**: Check logs immediately, verify environment variables, test dependencies\n* **Performance Issues**: Monitor resources, check for leaks, optimize layers\n* Never repeat failed commands more than twice without changing approach\n\n## Tool Usage (For Agents)\n\n* State objectives before each tool call\n* Use `generate_code` for Dockerfile creation when available\n* Leverage persistent scratchpad for state management\n* Invoke multiple independent operations simultaneously\n* Provide regular progress updates via todo lists\n\n## Best Practices Summary\n\n**DO:**\n\n* Use official base images and specific tags\n* Implement health checks and resource limits\n* Document thoroughly and test systematically\n* Cache dependencies effectively\n* Monitor container health continuously\n\n**DON'T:**\n\n* Run containers as root\n* Store secrets in Dockerfiles\n* Use 'latest' tags in production\n* Skip security scanning\n* Ignore error root causes\n\n## Success Criteria Checklist\n\n* [ ] Container builds successfully\n* [ ] Application runs without errors\n* [ ] All health checks pass\n* [ ] Dependencies properly configured\n* [ ] Environment variables documented\n* [ ] Security measures implemented\n* [ ] Resources cleaned up\n* [ ] Complete documentation provided\n* [ ] Build images for the deployment target architecture (most likely amd64, unless the deployment target is arm-based) \n\n## Critical Workflow Rules\n\n1. **Analysis before action** - understand the application first\n2. **User involvement** - confirm decisions and tradeoffs\n3. **Progressive documentation** - record findings at each step\n4. **Error analysis** - identify causes before retry attempts\n5. **Security by design** - implement security measures throughout\n6. **Health verification** - test thoroughly before completion\n7. **Clean completion** - remove unnecessary resources and document fully\n\n***\n\n*Adapt based on specific application requirements and organizational policies. Always prioritize security and maintainability.*\n","# Application Dockerization RuleBook\n\n## Core Principles\n\n* **Analysis First**: Thoroughly examine application before starting work\n* **User Collaboration**: Involve users in decisions, avoid assumptions, confirm critical choices\n* **Documentation**: Record all configurations, generated values, and requirements\n* **Efficiency**: Use available tools and information before requesting input\n* **Error Analysis**: Identify root causes before retrying failed operations\n\n## Mandatory 9-Phase Workflow\n\n### 1. Application Analysis\n\n* Examine directory structure and key files\n* Identify programming language, framework, and dependencies\n* Document external services (databases, cache, message queues)\n* Create file\u002Fpurpose mapping table\n* Accumulate findings progressively\n\n### 2. Base Image Selection\n\n* Prefer official Docker Hub images\n* Choose Alpine\u002Fslim variants for smaller size\n* Consider security update frequency\n* Create comparison table with pros\u002Fcons\n* Document selection rationale\n\n### 3. Dockerfile Creation\n\n* Use multi-stage builds when applicable\n* Configure non-root user for security\n* Optimize layer caching and minimize size\n* Implement health checks\n* Address security concerns explicitly\n\n### 4. Docker Compose Configuration\n\n* Include application and dependent services\n* Configure networks and volumes properly\n* Set environment variables and secrets\n* Omit obsolete 'version' attribute\n* Enable service dependencies and restart policies\n\n### 5. Build Process\n\n* Use `docker compose build` (preferred method)\n* Tag images with human-readable names\n* Implement comprehensive .dockerignore file\n* Document build commands and process\n* Handle build errors systematically\n\n### 6. Container Execution\n\n* Start with `docker compose up -d`\n* Verify all services start successfully\n* Apply database migrations if required\n* Check container status and logs\n* Ensure port mappings work correctly\n\n### 7. Health Verification\n\n* Check container status and logs\n* Test application endpoints (expect 200 status)\n* Verify dependent service connectivity\n* Monitor resource usage\n* Consider network accessibility (avoid localhost assumptions)\n\n### 8. Resource Cleanup\n\n* Stop containers with `docker compose down`\n* Remove unnecessary volumes and images\n* Clean build cache and temporary files\n* Document cleanup procedures\n* Verify complete resource removal\n\n### 9. Documentation\n\n* List all required environment variables\n* Identify secrets and sensitive configurations\n* Document deployment and migration steps\n* Provide troubleshooting guidance\n* Create final summary report\n\n## Security Requirements\n\n* **Never run as root user**\n* Use specific image tags (avoid 'latest')\n* Implement proper .dockerignore\n* Store secrets securely (not in image layers)\n* Scan for vulnerabilities regularly\n* Set resource limits appropriately\n* Use minimal base images\n\n## Error Handling Guidelines\n\n* **Build Failures**: Analyze error messages, check Dockerfile syntax, verify base image availability\n* **Runtime Failures**: Check logs immediately, verify environment variables, test dependencies\n* **Performance Issues**: Monitor resources, check for leaks, optimize layers\n* Never repeat failed commands more than twice without changing approach\n\n## Tool Usage (For Agents)\n\n* State objectives before each tool call\n* Use `generate_code` for Dockerfile creation when available\n* Leverage persistent scratchpad for state management\n* Invoke multiple independent operations simultaneously\n* Provide regular progress updates via todo lists\n\n## Best Practices Summary\n\n**DO:**\n\n* Use official base images and specific tags\n* Implement health checks and resource limits\n* Document thoroughly and test systematically\n* Cache dependencies effectively\n* Monitor container health continuously\n\n**DON'T:**\n\n* Run containers as root\n* Store secrets in Dockerfiles\n* Use 'latest' tags in production\n* Skip security scanning\n* Ignore error root causes\n\n## Success Criteria Checklist\n\n* [ ] Container builds successfully\n* [ ] Application runs without errors\n* [ ] All health checks pass\n* [ ] Dependencies properly configured\n* [ ] Environment variables documented\n* [ ] Security measures implemented\n* [ ] Resources cleaned up\n* [ ] Complete documentation provided\n* [ ] Build images for the deployment target architecture (most likely amd64, unless the deployment target is arm-based) \n\n## Critical Workflow Rules\n\n1. **Analysis before action** - understand the application first\n2. **User involvement** - confirm decisions and tradeoffs\n3. **Progressive documentation** - record findings at each step\n4. **Error analysis** - identify causes before retry attempts\n5. **Security by design** - implement security measures throughout\n6. **Health verification** - test thoroughly before completion\n7. **Clean completion** - remove unnecessary resources and document fully\n\n***\n\n*Adapt based on specific application requirements and organizational policies. Always prioritize security and maintainability.*\n",{"name":5,"tags":39,"license":15,"metadata":40,"description":43},[5,31,24,32,33,30],{"author":41,"version":42},"Stakpak \u003Cteam@stakpak.dev>","1.0.2","Official Stakpak application containerization standard operating procedure, a step-by-step guidline to properly dockerize applications. This is a rule book curated by the Stakpak Team.\n","main","d9bbde9885439c55adad930456b2660b0c37c052",1,"https:\u002F\u002Fgithub.com\u002Fstakpak\u002Fcommunity-paks","https:\u002F\u002Fgithub.com\u002Fstakpak","https:\u002F\u002Fwww.stakpak.dev","AI that runs your Infra","2026-07-04 20:18:32",{"source":8,"skillName":5,"commands":53,"prompt":63,"zipAvailable":64},[54,57,60],{"tool":55,"command":56},"npx","npx skills add stakpak\u002Fcommunity-paks --skill dockerization",{"tool":58,"command":59},"bunx","bunx skills add stakpak\u002Fcommunity-paks --skill dockerization",{"tool":61,"command":62},"pnpm","pnpm dlx skills add stakpak\u002Fcommunity-paks --skill dockerization","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fstakpak\u002Fcommunity-paks\u002Fblob\u002Fmain\u002Fdockerization\u002FSKILL.md",true,[],[67,98,122,140,159,176],{"skillNo":68,"name":69,"nameZh":6,"description":70,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":71,"categories":72,"keywords":82,"publishedAt":34},"01M6C49TTAVC8Q9CTTC05F6VSR","vllm-deployment","Deploy vLLM for high-performance LLM inference. Covers Docker CPU\u002FGPU deployments and cloud VM provisioning with OpenAI-compatible API endpoints.","https:\u002F\u002Fgithub.com\u002Fstakpak\u002Fcommunity-paks\u002Fblob\u002Fmain\u002Fvllm-deployment\u002FSKILL.md",[73,76,77],{"categoryNo":74,"categoryName":75,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":78,"categoryName":79,"taxonomyType":80,"taxonomyTypeDesc":81},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[83,84,85,24,27,86,87,88,29,89,90,91,92,93,26,94,95,96,97],"vllm deployment","vLLM","deployment","openai-api","llm inference","learning","api","provisioning","machine-learning","gpu","openai","vm","deploy","performance","inference",{"skillNo":99,"name":100,"nameZh":6,"description":101,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":102,"categories":103,"keywords":105,"publishedAt":34},"01M6C49R31XN7KJ7Y0Y78XVYTQ","terrateam-usage-guide","A comprehensive guide for configuring and using Terrateam, an open-source GitOps CI\u002FCD platform for Terraform and OpenTofu. Covers configuration file structure, access control, workflows, OIDC authentication, drift detection, and best practices for managing infrastructure through pull requests.","https:\u002F\u002Fgithub.com\u002Fstakpak\u002Fcommunity-paks\u002Fblob\u002Fmain\u002Fterrateam-usage-guide\u002FSKILL.md",[104],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[106,107,108,109,110,29,111,112,113,114,115,26,116,117,118,119,120,121],"terrateam usage guide","guide","file","opentofu","access","open","detection","oidc","ci","pull","terraform","best practices","authentication","infrastructure","pull requests","workflows",{"skillNo":123,"name":124,"nameZh":6,"description":125,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":126,"categories":127,"keywords":128,"publishedAt":34},"01M6C49N78AMM570EGPDXEZZDY","simple-deployment-on-vm","How to do simple but secure deployments using virtual machines on different cloud providers","https:\u002F\u002Fgithub.com\u002Fstakpak\u002Fcommunity-paks\u002Fblob\u002Fmain\u002Fsimple-deployment-on-vm\u002FSKILL.md",[],[129,94,85,130,26,131,132,29,133,134,135,136,137,27,138,95,139],"simple deployment on vm","tls configuration","virtual","how","ec2","Providers","tls","aws","dns","secure","security",{"skillNo":141,"name":142,"nameZh":6,"description":143,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":144,"categories":145,"keywords":146,"publishedAt":34},"01M6C49J8PRVT623JWRTTKFNJV","nextjs-on-aws","This document compares various AWS deployment options for Next.js applications, analyzing costs, benefits, limitations, and providing recommendations based on different use cases.","https:\u002F\u002Fgithub.com\u002Fstakpak\u002Fcommunity-paks\u002Fblob\u002Fmain\u002Fnextjs-on-aws\u002FSKILL.md",[],[147,136,148,149,150,151,29,152,153,28,154,155,26,85,156,157,158],"nextjs on aws","nextjs","use","aws deployment","js","Next.js","analysis","analyzing","cost","architecture","migration","cost-analysis",{"skillNo":160,"name":161,"nameZh":6,"description":162,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":163,"categories":164,"keywords":165,"publishedAt":34},"01M6C49F5B4BF2CHNT4X08XP69","migrating-bitnami-to-bitnami-legacy","This rule book helps you migrate Bitnami Helm charts and container images from the bitnami repository to the bitnamilegacy repository.\n\nThis migration is necessary due to Bitnami's transition, effective August 28th, 2025, where existing images will be moved to the legacy repo","https:\u002F\u002Fgithub.com\u002Fstakpak\u002Fcommunity-paks\u002Fblob\u002Fmain\u002Fmigrating-bitnami-to-bitnami-legacy\u002FSKILL.md",[],[166,167,29,168,169,170,171,172,30,173,26,174,175],"migrating bitnami to bitnami legacy","container images","helm","migrate","bitnami-helm-charts","bitnami-legacy","bitnami","repo","repository","Charts",{"skillNo":177,"name":178,"nameZh":6,"description":179,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":180,"categories":181,"keywords":182,"publishedAt":34},"01M6C49CHCPGZZ42P5W1MTV3WS","k3s-backup","Backup and recovery solution for K3s clusters. Includes scheduled, pre-shutdown, and manual backup strategies with recovery procedures.","https:\u002F\u002Fgithub.com\u002Fstakpak\u002Fcommunity-paks\u002Fblob\u002Fmain\u002Fk3s-backup\u002FSKILL.md",[],[183,184,185,26,186,29],"backup","k3s","k3s backup","recovery"]