Skip to content

feat: allow container rebuild without downtime (blue/green via podman rename) #174

Description

@alehostert

Static Badge

Context / Problem

In version 0.1.3, rebuilding a container requires a manual and disruptive flow:

  1. Backup the container
  2. Stop and delete the old container
  3. 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    Status
    approved

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions