The environment could have been a standalone project. This was an experiment, a challenge, and a proof-of-concept for a better, more portable infrastructure — built from the ground up in containers, under pressure, in an air-gapped zone.

✅ Real-World Advantages

1. Mobility: Infrastructure-agnostic by design

Containers can be moved across hosts with minimal disruption — an ideal fit for environments expecting SAN/NAS migrations or changing virtualization platforms.

2. Repeatability: Consistent environments, every time

From development to staging to final deployment, the same container image can be used without config drift or environment surprises. Our Kickstart + Repo + Container combo becomes a lab we can clone.

3. Simplified maintenance: Start, stop, swap

Containers are disposable by nature. Updates can be tested in parallel, deployed cleanly, and restarted without long outages or messy in-place upgrades.

4. Perfect for Admin Tools

This setup isn't just for apps — it supports operations too. Cleanup tools, log readers, API triggers — they can all live in lightweight, task-focused containers like the already under-construction OpsCan.

5. Future-ready — without forcing change

We didn’t expect to containerize everything. We built a side-environment that:

  • Coexists with legacy systems
  • Proves its value in staging and tools
  • Gives sysadmins and devs a way to try containers with low risk

❌ Disadvantages

1. Lack of official support

No formal production support for containers yet. That means we don't have the means for cross-training and orchestration structure building.

2. Persistence & Networking take more care

Without orchestration, volume management and network visibility require planning. But we’ve done that — step0, step1, isolated volumes, port remaps — it’s already working.


🐧 Do Containers Belong Here?

Yes — and here’s why:

  • We need fast, consistent admin tools
  • We want to move this setup (and others) across changing infrastructure
  • We don’t want to wait for VM provisioning or config approvals every time you test something new
  • We’ve already demonstrated that containers can live inside a compliant, well-documented, certifiable workflow

Maybe containers won’t run every app. But they’ll run ours — and the tools that support it. That’s the real story of this project.

This is the last page of the MediaWiki migration story. But it's also the first page of what happens next.