Manual label cleanup vs automated cleanup script for Portainer scheduler
0 reputation · 12 Sept 2020, 21:12 UTC
0 reputation · 12 Sept 2020, 21:12 UTC
Goal: Ensure that disabling Portainer’s built‑in scheduler does not leave residual labels that could trigger unintended container restarts.
When the scheduler is active, Portainer adds labels such as io.portainer.scheduler.action to managed containers to track the desired scaling state. Disabling the scheduler through the UI or API does not automatically remove these labels, so they remain on the containers unless explicitly cleared.
Constraint: Administrators must decide whether to perform manual label inspection and removal after scheduler disablement or to implement an automated cleanup mechanism that guarantees label removal without ongoing operational overhead.
Uncertainty: The trade‑off between the simplicity of a manual process and the reliability of an automated script, especially in environments with many hosts and frequent scheduler toggles.
What are the operational costs and risk profiles of manual versus automated label cleanup? How can we verify that no scheduler‑added labels persist after the scheduler is turned off? Which approach best balances minimal administrative effort with guaranteed avoidance of unintended restarts?
35275 reputation · 13 Sept 2020, 07:04 UTC
For most production environments, an automated cleanup script is the superior choice. While manual cleanup is simpler for a handful of containers, the risk of human error and the operational overhead in multi-host environments make automation the only scalable way to guarantee that residual io.portainer.scheduler.action labels do not trigger unintended container behavior.
| Metric | Manual Cleanup | Automated Script |
|---|---|---|
| Admin Effort | High (per-container inspection) | Low (initial setup, then zero) |
| Reliability | Low (prone to oversight) | High (consistent application) |
| Risk | Missing a label leads to drift | Over-aggressive filtering may remove valid labels |
| Scalability | Poor (linear time increase) | Excellent (constant time) |
To ensure no scheduler labels persist, follow these steps based on your chosen method:
io.portainer.scheduler.action key.docker inspect to check for scheduler labels.Regardless of the method, verify the cleanup using a scoped filter. Assuming a Linux environment with Docker installed, run:
docker ps --filter "label=io.portainer.scheduler.action"
If the output is empty, all scheduler-managed labels have been successfully removed.
To refine this recommendation: How many unique hosts and total containers are currently managed by your Portainer instance? If the count is under 10 containers across a single host, the manual approach is acceptable; otherwise, automation is required.
Use comments to ask for clarification. Post a solution as an answer.
6,160 reputation · 13 Sept 2020, 08:29 UTC
A filtered docker ps only inspects running containers, so stopped or exited containers with residual io.portainer.scheduler.action labels can escape a quick audit. Verification should use docker ps -a with the same label filter, or inspect the full container inventory on each managed host.
In multi-host setups, verifying a single node is not enough. The cleanup scope must match the scheduler's scope; otherwise, labels left on an unverified endpoint can reintroduce drift when the scheduler is re-enabled.