devopstutor

Imported from juancrfig/devopstutor (AGENTS.md). Install upstream with npx skills add juancrfig/devopstutor. Copyright stays with the author.

AGENTS.md — devops_gym

Single shared Docker container for all DevOps/Linux gym tickets. Fresh build per session; --rm so no state persists between runs. Juanes opens the container himself — agents write guides, setup.sh broken states, and coach/assist Juanes through tickets.

Structure

devops_gym/
├── Dockerfile       ← ubuntu:24.04, user juanes (NOPASSWD sudo)
├── setup.sh         ← fabricates broken state; grows as tickets are added
├── run.sh           ← docker build + docker run --rm -it --hostname devops-lab
├── gym              ← TUI launcher; Leitner scheduling in .gym-ledger
└── pool/
    └── <topic>/<scenario>/guide.md

Container decisions (settled)

• One container, all topics. Base: ubuntu:24.04.
• Fresh build per session (./run.sh always rebuilds). --rm wipes on exit.
• No check.sh — concept questions go to Claude post-solve.
• setup.sh is one growing file. Refactor only when it hurts.
• Juanes opens the container himself; the gym TUI serves guides separately.
• Scheduling lives in .gym-ledger (Leitner, managed by gym). No external ledger — the old vault ledger is retired.
• Live incident processes (log flooder, zombie, respawner, traffic writer) are started by a guarded block in /etc/bash.bashrc at first shell.

Adding a ticket

1. pool/<topic>/<scenario>/guide.md — follow the format below.
2. Add broken state to setup.sh.
3. ./run.sh — verify the broken state lands correctly.

guide.md format (parsed by gym)

# <title>
## TICKET
<symptom — NEVER names a command>
## COMMANDS
cmd1 cmd2 cmd3
## QUESTIONS
1. <interview-style concept question>

Design rules

• Never name the command in the ticket. Symptoms only.
• Storm realism: tickets are incident scenarios, not drills. Multi-command solutions; force pipes, globbing, and redirection (>, >>, 2>, 2>&1).
• QUESTIONS: ~3–5 genuine mid-level DevOps interview questions probing fundamentals. No trivia.
• setup.sh should itself be good shell-scripting practice to read post-solve.

Mentoring & ticket assistance rules

When Juanes asks for help, hints, or questions while working through a ticket:

• Strictly follow "COMMANDS IN PLAY" (## COMMANDS): Always inspect the ticket's guide.md (the ## COMMANDS section, rendered as COMMANDS IN PLAY in the gym TUI). These commands were planned beforehand by his mentor specifically for Juanes to practice. Do not bypass or ignore them.
• Keep it simple — NO command vomiting: Do NOT spit out long, complex, or overly clever one-liners. Do NOT introduce unlisted tools (e.g., awk, sed, perl, python, etc.) or obscure flags unless they are explicitly listed in the ticket's command list.
• Nudge toward the solution: Guide Juanes step-by-step to build a solution using only the commands in play, basic flags, and core shell mechanics (pipes |, redirection >, >>, 2>, 2>&1, and globbing). Ask prompting questions or suggest which command from the list to investigate first instead of giving away complete answers.

Command inventory by topic

Planned topics (near future)

Missing for mid-level interview coverage; next expansion wave:

• networking — ss, curl, dig, ports, "service can't reach DB" scenarios
• ssh — keys, scp, config, agent
• systemd — hands-on units (unparks 06-services via the plan above)
• junior-gauntlet — [design by 2026-08-13] Combo incident: SSH into a wild server with multiple simultaneous issues — zombie processes, missing services, unusual memory usage, and dangerously high load averages. Mimics a real-world demanding scenario. Junior DevOps rite of passage. Mixes processes, files, text, and perms tools in one ticket.