Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
245 changes: 39 additions & 206 deletions rh-developer/skills/containerize-deploy/SKILL.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,10 @@
name: containerize-deploy
description: |
Complete end-to-end workflow for containerizing and deploying applications to OpenShift or standalone RHEL systems. Orchestrates /detect-project, /s2i-build, /deploy, /helm-deploy, and /rhel-deploy skills with user confirmation checkpoints at each phase. Supports S2I, Podman, Helm deployment strategies for OpenShift, and Podman/native deployments for RHEL hosts. Use this skill when user wants to go from source code to running application in one guided workflow. Supports resume after interruption and rollback on failure. Triggers on /containerize-deploy command.
model: inherit
color: green
metadata:
user_invocable: "true"
---

# /containerize-deploy Skill
Expand All @@ -11,119 +15,25 @@ Provide a complete, guided workflow from local source code to running applicatio
## Overview

```
[Intro] → [Detect] → [Target] → [Strategy] ──┬─→ [OpenShift Path] ─────┬─→ [Complete]
│ │ [S2I/Podman/Helm] │
│ │ │
│ └─→ [RHEL Path] ───────────┘
│ (/rhel-deploy)
User chooses target:
- OpenShift → Strategy selection (S2I/Podman/Helm)
- RHEL → Delegate to /rhel-deploy skill
[Intro] → [Detect] → [Target] → [Strategy] ──┬─→ [OpenShift: S2I/Podman/Helm] ──┬─→ [Complete]
└─→ [RHEL: /rhel-deploy] ──────────┘
```

**Deployment Targets:**
- **OpenShift** - Deploy to OpenShift/Kubernetes cluster (S2I, Podman, or Helm strategies)
- **RHEL Host** - Deploy to standalone RHEL system via SSH (delegates to /rhel-deploy)
## When to Use This Skill

**OpenShift Deployment Strategies (if OpenShift target selected):**
- **S2I** - Source-to-Image build on OpenShift, then deploy (Phases 3-7)
- **Podman** - Build from Containerfile/Dockerfile on OpenShift, then deploy (Phases 3-7)
- **Helm** - Deploy using Helm chart (Phase 2-H)
Use `/containerize-deploy` when a user wants a complete guided workflow from source code to running application on OpenShift or standalone RHEL systems. This skill orchestrates project detection, build strategy selection, and deployment with user confirmation at each phase.

## Critical: Human-in-the-Loop Requirements

See [Human-in-the-Loop Requirements](../docs/human-in-the-loop.md) for mandatory checkpoint behavior.

**IMPORTANT:** This skill requires explicit user confirmation at each phase. You MUST:

1. **Wait for user confirmation** before executing any actions
2. **Do NOT proceed** to the next phase until the user explicitly approves
3. **Present options clearly** (yes/no/modify) and wait for response
4. **Never auto-execute** resource creation, builds, or deployments
5. **Never skip configuration questions** even if user seems to know what they want

If the user says "no" or wants modifications, address their concerns before proceeding.

### Anti-Patterns to Avoid

**CRITICAL - DO NOT DO THIS:**

- If user says "yes do helm deployment to namespace X" - do NOT skip configuration questions
- If user seems experienced or decisive - do NOT assume they've considered all options
- If user provides strategy choice early - do NOT skip environment type question
- If user gives multiple answers at once - still ask each checkpoint question individually

**The user specifying WHAT to deploy does not mean they've decided HOW to configure it.**

Strategy choice ≠ Configuration approval. Always ask:
1. Environment type (dev/staging/prod)
2. Resource limits appropriate for environment
3. Runtime vs build-time configuration
4. Replicas and scaling
5. Any customizations before proceeding

## Phase Execution Rules

**MANDATORY:** Execute phases in order. Each phase MUST:

1. Display the phase information to the user
2. Ask the specific question for that phase
3. Wait for user response
4. Only then proceed to next phase

**Even if user provides information for multiple phases at once:**
- Acknowledge what they said
- But still display each phase's confirmation prompt
- Get explicit "yes" for each phase before executing

Example:
- User: "yes do helm to test-app namespace"
- AI: "Great, you've chosen Helm strategy and test-app namespace. Let me confirm the configuration details..."
- [Still show Phase 1.7 Configuration Review]
- [Still ask environment type, config approach, etc.]
See [Human-in-the-Loop Requirements](../../docs/human-in-the-loop.md) for mandatory checkpoint behavior.

## Workflow

### Phase 0: Introduction

```markdown
# Containerize & Deploy

I'll help you containerize and deploy your application to OpenShift or a standalone RHEL system.
Present the workflow overview and available deployment targets/strategies. Ask: **Ready to begin?** (yes/no)

**What this workflow does:**
1. **Detect** - Analyze your project and determine the best deployment strategy
2. **Choose Target** - Deploy to OpenShift cluster or RHEL host
3. **Build** - Build container image (S2I or Podman) or skip if using Helm with existing image
4. **Deploy** - Deploy using Kubernetes resources, Helm chart, or systemd services

**Deployment Targets:**
- **OpenShift** - Deploy to OpenShift/Kubernetes cluster
- **RHEL Host** - Deploy directly to a RHEL system via SSH

**OpenShift Strategies:**
- **S2I (Source-to-Image)** - Build and deploy from source code
- **Podman** - Build from existing Containerfile/Dockerfile
- **Helm** - Deploy using Helm chart

**RHEL Strategies:**
- **Container** - Run with Podman + systemd
- **Native** - Install with dnf + systemd

**What I need from you:**
- Confirmation at each step before I make changes
- Access to an OpenShift cluster OR SSH access to a RHEL host
- Your project source code

**Ready to begin?** (yes/no)
```

**WAIT for user confirmation before proceeding.** Do NOT continue to Phase 1 until user explicitly confirms.

- If user says "yes" → Proceed to Phase 1
- If user says "no" → Ask what concerns they have
- If user gives multiple answers at once (e.g., "yes helm to namespace X") → Acknowledge their choices but still proceed through each phase individually
**WAIT for user confirmation before proceeding.**

### Phase 1: Project Detection

Expand Down Expand Up @@ -169,7 +79,7 @@ Where would you like to deploy this application?

Store `DEPLOYMENT_TARGET` in session state.

**WAIT for user confirmation before proceeding.** Do NOT assume target based on earlier statements.
**WAIT for user confirmation before proceeding.**

**If user selects "RHEL":**
- Store `DEPLOYMENT_TARGET = "rhel"` in session state
Expand Down Expand Up @@ -209,7 +119,7 @@ Based on my analysis, you have these options:

Store `DEPLOYMENT_STRATEGY` in session state.

**WAIT for user confirmation before proceeding.** Do NOT skip to Phase 1.7 without explicit strategy selection.
**WAIT for user confirmation before proceeding.**

### Phase 1.6: Image Selection (S2I/Podman only)

Expand Down Expand Up @@ -288,10 +198,7 @@ Before I proceed, let me confirm the deployment configuration:
2. Customize resources
```

**WAIT for user to answer ALL questions above before proceeding.** Do NOT continue to Phase 2 until user has confirmed:
- Environment type
- Configuration approach
- Resource settings
**WAIT for user to answer ALL questions above before proceeding.**

Store: `ENVIRONMENT_TYPE`, `CONFIG_APPROACH`, `RESOURCE_PROFILE` in session state.

Expand Down Expand Up @@ -543,102 +450,28 @@ Proceeding with Helm deployment...

### Phase 8: Completion

```markdown
## Deployment Complete!

Your application is now running on OpenShift.

---

**Application Summary:**

| Setting | Value |
|---|---|
| Name | [app-name] |
| Namespace | [namespace] |
| Language | [language] |
| Framework | [framework] |

---

**Access URLs:**

| Type | URL |
|---|-----|
| **External** | https://[route-host] |
| Internal | http://[app-name].[namespace].svc.cluster.local:[port] |

---

**Resources Created:**

| Resource | Name | Status |
|----|---|-----|
| ImageStream | [app-name] | Ready |
| BuildConfig | [app-name] | Ready |
| Deployment | [app-name] | 1/1 Running |
| Service | [app-name] | Active |
| Route | [app-name] | Admitted |

---

**Quick Commands:**

```bash
# View logs
oc logs -f deployment/[app-name] -n [namespace]

# Scale up
oc scale deployment/[app-name] --replicas=3 -n [namespace]

# Trigger rebuild (after code changes)
oc start-build [app-name] -n [namespace]

# Delete everything
oc delete all -l app=[app-name] -n [namespace]
```

---

**Next Steps:**
- Open your app: [route-url]
- Set up Git webhooks for automatic builds
- Add environment variables: `oc set env deployment/[app-name] KEY=value`
- Configure autoscaling: `oc autoscale deployment/[app-name] --min=1 --max=5`

---

Congratulations! Your application is live.
```

## MCP Tools Used

All tools from child skills:

| Phase | Tools |
|---|---|
| Detect | `run_terminal_cmd` (optional clone) |
| Connect | `resources_list` (namespaces) |
| Build | `resources_create_or_update`, `pod_logs`, `events_list` |
| Deploy | `resources_create_or_update`, `pod_list`, `pod_logs` |
| Helm | `helm_install`, `helm_upgrade`, `helm_status`, `helm_list`, `pods_list` |
| Rollback | `resources_delete`, `helm_uninstall`, `helm_rollback` |

## Related Skills

| Skill | Use When |
|-------|----------|
| `/debug-pod` | Pod failures (CrashLoopBackOff, OOMKilled, ImagePullBackOff) |
| `/debug-build` | S2I or Podman build failures |
| `/debug-network` | Service connectivity issues (no endpoints, 503 errors) |
| `/debug-rhel` | RHEL deployment failures (systemd, SELinux, firewall) |

## Reference Documentation

For detailed guidance, see:
- [docs/builder-images.md](../docs/builder-images.md) - Language detection, S2I builder images
- [docs/image-selection-criteria.md](../docs/image-selection-criteria.md) - Image variant selection, LTS timelines
- [docs/python-s2i-entrypoints.md](../docs/python-s2i-entrypoints.md) - Python S2I configuration
- [docs/rhel-deployment.md](../docs/rhel-deployment.md) - RHEL host deployment (when delegating to /rhel-deploy)
- [docs/debugging-patterns.md](../docs/debugging-patterns.md) - Common error patterns and troubleshooting
- [docs/prerequisites.md](../docs/prerequisites.md) - All required tools by skill
Present a summary including:
- Application name, namespace, language, framework
- Access URLs (external route, internal service DNS)
- Resources created with status (ImageStream, BuildConfig, Deployment, Service, Route)
- Quick commands: view logs, scale, rebuild, delete
- Next steps: open app URL, set up webhooks, add env vars, configure autoscaling

## Dependencies

### Required MCP Servers
- `openshift` - cluster resource management for OpenShift deployments

### Related Skills
- `/debug-pod` - Pod failures (CrashLoopBackOff, OOMKilled, ImagePullBackOff)
- `/debug-build` - S2I or Podman build failures
- `/debug-network` - Service connectivity issues (no endpoints, 503 errors)
- `/debug-rhel` - RHEL deployment failures (systemd, SELinux, firewall)

### Reference Documentation
- [docs/builder-images.md](../../docs/builder-images.md) - Language detection, S2I builder images
- [docs/image-selection-criteria.md](../../docs/image-selection-criteria.md) - Image variant selection, LTS timelines
- [docs/python-s2i-entrypoints.md](../../docs/python-s2i-entrypoints.md) - Python S2I configuration
- [docs/rhel-deployment.md](../../docs/rhel-deployment.md) - RHEL host deployment
- [docs/debugging-patterns.md](../../docs/debugging-patterns.md) - Common error patterns and troubleshooting
- [docs/prerequisites.md](../../docs/prerequisites.md) - All required tools by skill
Loading