
Context / Problem
In version 0.1.3, rebuilding a container requires a manual and disruptive flow:
- Backup the container
- Stop and delete the old container
- Create a new container with the same hostname
This creates a window of downtime and increases the Mean Time to Repair (MTTR). If the new container fails, the old one is already destroyed, making rollback slow and risky.
Proposed Solution
Use podman rename to enable a Blue/Green pattern, renaming the old container and keeping it running.
The user, will have to manually:
- Start the new container with the original name
- Wait for the healthcheck
- Stop the old container.
Analysis of Risks and Side Effects
1. Port Binding Conflict
podman rename does not release the host port binding. If the old container is bound to -p 8080:80, the new container cannot bind to port 8080.
However, in Ez this is not an issue because Ez automatically assigns free ports and manages the actual routing through its mappings (NGINX).
Therefore, the only requirement for Ez is to update:
- All NGINX
.conf files that reference the old container hostname
- Ez's internal database that tracks the mapping between hostname/container
systemd unit file
- (somewhere else I might be forgetting)
This can be done after the rename.
2. Rollback Flow
The old container continues running. If the new container fails, the user will just need to remove the failed one and rename the old container back to the original name. Zero data loss.
Context / Problem
In version 0.1.3, rebuilding a container requires a manual and disruptive flow:
This creates a window of downtime and increases the Mean Time to Repair (MTTR). If the new container fails, the old one is already destroyed, making rollback slow and risky.
Proposed Solution
Use
podman renameto enable a Blue/Green pattern, renaming the old container and keeping it running.The user, will have to manually:
Analysis of Risks and Side Effects
1. Port Binding Conflict
podman renamedoes not release the host port binding. If the old container is bound to-p 8080:80, the new container cannot bind to port 8080.However, in Ez this is not an issue because Ez automatically assigns free ports and manages the actual routing through its mappings (NGINX).
Therefore, the only requirement for Ez is to update:
.conffiles that reference the old container hostnamesystemdunit fileThis can be done after the rename.
2. Rollback Flow
The old container continues running. If the new container fails, the user will just need to remove the failed one and rename the old container back to the original name. Zero data loss.