- TechOps Examples
- Posts
- Why Containers Are Designed for One Process Only
Why Containers Are Designed for One Process Only
Govardhana M K
April 29, 2025
In partnership with
TechOps Examples
Hey — It's Govardhana MK 👋
Along with a use case deep dive, we identify the remote job opportunities, top news, tools, and articles in the TechOps industry.
👋 Before we begin... a big thank you to today's sponsor PERFECTSCALE
GKE node pool sprawl is costing you time and money.
Most teams still manage their node pools manually. That means overprovisioning, underutilization, and spiraling cloud bills.
What if your cluster could just create the right node pools for you?
In this workshop, Chimbu Chinnadurai (DoiT) and Anton Weiss (PerfectScale) will show how GKE’s Node Auto-Provisioning (NAP) with Compute Classes can:
→ Dynamically create node pools
→ Match the right machine types to your workloads
→ Reduce waste and cost
👋 Excited to bring this Free AI Guide to you..
The Future of Voice AI Is Here
Discover why forward-thinking enterprises are rapidly adopting Voice AI Agents. This guide breaks down the $47.5B market shift, highlights emerging trends, and offers practical steps for successful implementation.
Learn how leading teams are using Voice AI to boost efficiency, elevate customer experience, and start delivering measurable results—in as little as 3 weeks.
IN TODAY'S EDITION
🧠 Use Case
Why Containers Are Designed for One Process Only
🚀 Top News
👀 Remote Jobs
Canonical is hiring a Site Reliability / Gitops Engineer
Remote Location: Worldwide
Terrascope is hiring a Senior Devops Engineer
Remote Location: India, Singapore, Malaysia, Philippines, Vietnam
📚️ Resources
📢 Reddit Threads
🛠️ TOOL OF THE DAY
gama - Manage your GitHub Actions from Terminal with great UI
It allows to list, trigger, and manage workflows with ease directly from the terminal.
🧠 USE CASE
Why Containers Are Designed for One Process Only
Yes, you can run multiple processes inside a container.
You can even install systemd, use a supervisor, and make it behave like a small virtual machine.
But that’s not how containers are meant to be used, imagine these technical scenarios:
📌 A container running a MySQL database and a logging service together experiences high memory usage.
📌 Your Flask application running alongside a cron job in one container leads to overlapping log files.
📌 A Dockerized application running multiple tightly coupled processes can’t handle a clean shutdown, leaving orphaned child processes.
Running into these kinds of scenarios is not uncommon but should be avoided, for sure.
In this era, from legacy tech to modern solutions, you can containerize any application with ease, but the core idea behind containers is process isolation and composability.
Principles of Container-Based Application Design whitepaper is a fantastic guide that every cloud native engineer should read to understand meaningful app design principles for modern infrastructure.
Principles of container-based application design
Why Keep Only One Process in a Container?
1. Isolation Makes Troubleshooting Easier
When a container has only one process, logs, resource usage, and failures point directly to that application.
Example: If a Node.js server fails, you can find the cause immediately without sorting through logs from unrelated processes.
2. Scaling Becomes Flexible
Each container can scale based on its own needs without affecting others.
Example: If you need more load balancers, you scale just the Nginx containers without unnecessarily scaling a database that is bundled inside.
3. Smaller Failure Impact
A failure in one container affects only that part of the system.
Example: If a background job worker fails, it will not affect your main web application, because they are running separately.
What Problems Arise When Multiple Processes Run in One Container?
📌 Docker and container engines monitor only the main process (PID 1). Other processes may continue running even if the main process crashes, leading to orphaned or zombie processes.
📌 Multiple processes inside one container can fight for CPU, memory, and disk I/O, causing instability.
📌 Logs from different processes mix together, making it harder to identify where an issue started.
Sometimes, combining processes cannot be avoided. In those cases:
Use a lightweight process manager like
tiniorsupervisordto properly manage child processes.Ensure signals like SIGTERM and SIGKILL are correctly handled to shut down all processes cleanly.
We are bringing a live workshop on GKE’s Node Auto-Provisioning (NAP) featuring Chimbu Chinnadurai (Senior Cloud Architect - DoiT) and Anton Weiss (Chief Cluster Whisperer - PerfectScale)