Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docker.container: Recreate container when args change #1277

Draft
wants to merge 3 commits into
base: 3.x
Choose a base branch
from

Conversation

minor-fixes
Copy link

This PR allows the docker.container operation to tear down and
recreate the container when operation arguments change, instead of
reporting No change and doing nothing. This is intended to reduce the
possibility for human error/need for manual intervention when changing
args to docker.container operations.

Since it is not possible to extract all operation args from e.g. docker inspect output, this PR takes a similar approach to Docker Compose to
tackle this issue - it serializes the operation args in a deterministic
way, hashes the serialized bytes, and stores this as a label on the
container. If the hash differs from a currently-running container, the
container is recreated.

Tested: Added additional tests for behavior when args are
changing/static in different scenarios

This change refactors the way the `docker.container` operation manages
containers, in preparation for work to make recreation more intelligent.
This change is (mostly) a pure refactor; future changes will diff the
current container against the operation parameters to determine if a
container needs to be recreated. This will fix an issue where changing
any of the operation arguments does not result in actual container
changes upon execution.

In this refactor, container parameters are moved to a dedicated class,
which centralizes the `docker container` command-line argument
generation logic and the future diffing logic. The diff function is
roughed in, though it currently reports "no diff" (to match the
operation's current behavior). Since conditional recreation complicates
the operation's logic on which commands to execute, the decisions are
boosted into boolean variables to increase readability.

As a side benefit, supporting additional docker container parameters
should be more straightforward due to the centralization in said
dedicated class (I'm planning on adding support for container args, uid,
and other Docker params currently not supported).

The only behavioral change is that creating and starting a container is
no longer done in one exec (joined by `;`) but rather two separate
docker commands. This sidesteps questions about whether `;` is the
correct joiner (as opposed to `&&`) and reduces the amount of `kwargs`
fishing in the implementation.

Tested:
* `scripts/dev-test.sh` and `scripts/dev-test-e2e.sh` both pass, save
  for warnings also present prior to this change
This change adds an `args` parameter to the `docker.container` operation
that passes said supplied args to the container at creation time. This
allows the operation to support container images that have an entrypoint
expecting to receive additional arguments, without needing to build+push
a custom image that embeds said arguments.
This PR allows the `docker.container` operation to tear down and
recreate the container when operation arguments change, instead of
reporting `No change` and doing nothing. This is intended to reduce the
possibility for human error/need for manual intervention when changing
args to `docker.container` operations.

Since it is not possible to extract all operation args from e.g. `docker
inspect` output, this PR takes a similar approach to Docker Compose to
tackle this issue - it serializes the operation args in a deterministic
way, hashes the serialized bytes, and stores this as a label on the
container. If the hash differs from a currently-running container, the
container is recreated.

Tested: Added additional tests for behavior when args are
changing/static in different scenarios
@minor-fixes minor-fixes force-pushed the docker_container_reloading branch from 5147744 to 8ef9a23 Compare January 20, 2025 16:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant