Evaluate and Implement On-Demand Service Booting
Description
To optimize resource utilization on our server—specifically RAM—we need to implement a mechanism to boot infrequently used, resource-heavy services only when they are actively requested.
Target Services
- Stirling PDF: This service is known to be RAM-intensive but is likely not used constantly.
- (List any other potential candidate services here)
Proposed Solutions
We have two primary architectural paths to achieve scale-to-zero / wake-on-traffic functionality. We need to decide which path best fits our workflow:
Option A: Docker-Based Approach (Sablier / Lazytainer)
If we host these services within a Docker environment, we can use container management tools that integrate with our reverse proxy:
- Sablier: An API that starts containers on demand and stops them after a period of inactivity.
- Lazytainer: A tool that monitors network traffic and wakes up sleeping containers when a request is made.
Option B: Native LXC Approach (Systemd Socket Activation)
If we prefer to keep services like Stirling PDF in their own native LXCs (avoiding Docker), we can use native Linux networking.
- Systemd Socket Activation: We can configure
systemd to listen on the service's specific port (e.g., 8080 for Stirling PDF).
- The actual service remains completely dead (consuming 0 RAM) until a network packet hits that port.
- The moment
systemd detects the network traffic, it rapidly spins up the service and hands the socket over to it.
Action Items
Evaluate and Implement On-Demand Service Booting
Description
To optimize resource utilization on our server—specifically RAM—we need to implement a mechanism to boot infrequently used, resource-heavy services only when they are actively requested.
Target Services
Proposed Solutions
We have two primary architectural paths to achieve scale-to-zero / wake-on-traffic functionality. We need to decide which path best fits our workflow:
Option A: Docker-Based Approach (Sablier / Lazytainer)
If we host these services within a Docker environment, we can use container management tools that integrate with our reverse proxy:
Option B: Native LXC Approach (Systemd Socket Activation)
If we prefer to keep services like Stirling PDF in their own native LXCs (avoiding Docker), we can use native Linux networking.
systemdto listen on the service's specific port (e.g., 8080 for Stirling PDF).systemddetects the network traffic, it rapidly spins up the service and hands the socket over to it.Action Items