arn-infra-containerize

Arness Infra Containerize

Generate production-ready Dockerfiles, docker-compose configurations, and .dockerignore files for the application. This skill produces security-audited, multi-stage container configurations adapted to the application's technology stack and topology.

This skill reads the application context (codebase patterns, architecture, technology stack) based on the project topology, invokes the arn-infra-specialist agent for container configuration generation, and the arn-infra-security-auditor agent for security review. All generated files are presented for user approval before being written.

Prerequisites

Read ## Arness from the project's CLAUDE.md. If no ## Arness section exists or Arness Infra fields are missing, inform the user: "Arness Infra is not configured for this project yet. Run /arn-infra-wizard to get started — it will set everything up automatically." Do not proceed without it.

Check the Deferred field. If Deferred: yes, inform the user: "Infrastructure is in deferred mode. Containerization is not available until infrastructure is fully configured. Run /arn-infra-assess to un-defer." Stop.

Extract:

• Project topology -- how to resolve the application project (monorepo, separate-repo, infra-only)
• Application path -- path to the application project root
• Experience level -- derived from user profile. Read ~/.arness/user-profile.yaml (or .claude/arness-profile.local.md if it exists — project override takes precedence). Apply the experience derivation mapping from ${CLAUDE_PLUGIN_ROOT}/skills/arn-infra-ensure-config/references/experience-derivation.md. If no profile exists, check for legacy Experience level in ## Arness as fallback.
• Providers -- informs container registry selection and platform-specific optimizations
• Tooling manifest -- path to check for Docker/container tools availability

Workflow

Step 1: Resolve Application Context

Resolve the application project based on topology to understand the technology stack, services, and dependencies.

Monorepo (Application path: .):

• Read codebase patterns from the local code-patterns directory (path from ## Arness config)
• Read architecture.md for technology stack, services, and dependencies
• Scan the source tree for: package.json, requirements.txt, pyproject.toml, go.mod, Cargo.toml, pom.xml, *.csproj, Gemfile
• Identify application entry points, build commands, and runtime requirements

Separate repo:

• Navigate to Application path
• Read the application's ## Arness config, code patterns, and architecture
• Scan for the same dependency/entry point files
• If the path is unreachable, inform the user and ask them to describe the application stack manually

Infra-only:

• No application to analyze directly
• Ask the user to describe: language/framework, services (web, API, workers), databases, build commands, runtime requirements
• Proceed with user-provided context

Step 2: Check Existing Container Configurations

Scan for existing container files:

• Dockerfile, Dockerfile., .Dockerfile
• docker-compose.yml, docker-compose.yaml, compose.yml, compose.yaml, docker-compose.*.yml
• .dockerignore

If existing files found: Present findings: "I found existing container configurations: [list files]."

Ask (using AskUserQuestion):

"What would you like to do with existing container configurations?"

Options:

1. Replace -- Generate new configurations (existing files will be overwritten after your approval)
2. Augment -- Keep existing files and add missing configurations
3. Review only -- Run a security audit on the existing files without generating new ones

If the user chooses Review only: Skip to Step 5 (security audit) with existing files.

If no existing files found: Continue to Step 3.

Step 3: Determine Container Strategy

Based on the application analysis from Step 1, determine what container files are needed.

Single-service applications:

• Generate: Dockerfile, .dockerignore
• Optionally generate docker-compose.yml if the app depends on external services (database, cache, queue)

Multi-service applications:

• Generate: one Dockerfile per service (or Dockerfile.<service>)
• Generate: docker-compose.yml with all services
• Generate: .dockerignore

Ask the user to confirm the container strategy:

"Based on your application, I plan to generate:

• [list of files to generate]
• Multi-stage builds for [production optimization / smaller images]
• [Development docker-compose with hot reload / Production-only compose]

Does this look right, or would you like to adjust?"

Step 4: Invoke Specialist Agent for Generation

Load the appropriate reference files based on the detected technology stack:

Read the local override or plugin default for dockerfile-patterns.md.

If multi-service or compose is needed:

Read the local override or plugin default for compose-patterns.md.

Invoke the arn-infra-specialist agent via the Task tool, passing the model from .arness/agent-models/infra.md as the model parameter (see plugins/arn-infra/skills/arn-infra-ensure-config/references/ensure-config.md "Dispatch convention" for fallback). Context:

--- APPLICATION CONTEXT --- Technology stack: [language, framework, runtime version] Services: [list of services with roles] Build commands: [build steps for each service] Entry points: [start commands for each service] Dependencies: [external services -- databases, caches, queues] Environment variables: [required env vars, without values] Ports: [exposed ports per service] --- END APPLICATION CONTEXT ---

--- CONTAINER PATTERNS --- [content from dockerfile-patterns.md, filtered to relevant language(s)] [content from compose-patterns.md, if multi-service] --- END CONTAINER PATTERNS ---

--- INFRASTRUCTURE CONFIG --- Experience level: [derived from user profile] Providers: [from ## Arness -- for registry and platform hints] --- END INFRASTRUCTURE CONFIG ---

--- INSTRUCTIONS --- Generate container configurations for the application. For each Dockerfile:

• Use multi-stage builds (builder stage + production stage)
• Pin base image versions (no :latest tags)
• Run as non-root user in the production stage
• Order layers for optimal cache utilization (dependencies before source code)
• Include health check instructions
• Minimize image size (use alpine/slim/distroless where appropriate)

For docker-compose.yml (if multi-service):

• Define all services with proper dependency ordering
• Use named volumes for persistent data
• Configure networks for service isolation
• Include health checks for dependent services
• Add environment variable placeholders (never hardcode secrets)

For .dockerignore:

• Exclude version control, IDE files, test directories, documentation
• Exclude secrets files (.env, .pem, .key)
• Exclude build artifacts and node_modules / venv / target directories

Adapt comment verbosity to the experience level. --- END INSTRUCTIONS ---

Step 5: Security Audit

Load the security checklist:

Read ${CLAUDE_PLUGIN_ROOT}/skills/arn-infra-containerize/references/container-security-checklist.md for container security requirements.

Invoke the arn-infra-security-auditor agent via the Task tool, passing the model from .arness/agent-models/infra.md as the model parameter (see plugins/arn-infra/skills/arn-infra-ensure-config/references/ensure-config.md "Dispatch convention" for fallback). Context:

--- FILES TO AUDIT --- [generated Dockerfile content(s)] [generated docker-compose.yml content, if any] [generated .dockerignore content] --- END FILES TO AUDIT ---

--- SECURITY CHECKLIST --- [content from container-security-checklist.md] --- END SECURITY CHECKLIST ---

--- INSTRUCTIONS --- Review the generated container configurations against the security checklist. Check for:

• Running as root user
• Unpinned base image version