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

build: label built images for reliable cleanup on down #9819

Merged
merged 5 commits into from Sep 14, 2022

Conversation

milas
Copy link
Contributor

@milas milas commented Sep 7, 2022

What I did
When running compose down, the --rmi flag can be passed, which currently supports two values:

  • local: remove any implicitly-named images that Compose built
  • all : remove any named images (locally-built or fetched from a remote repo)

Removing images in the local case can be problematic, as it's historically been done via a fair amount of inference over the Compose model. Additionally, when using the "project-model" (by passing --project-name instead of using a Compose file), we're even more limited: if no containers for the project are running, there's nothing to derive state from to perform the inference on.

As a first pass, we started labeling containers with the name of the locally-built image associated with it (if any) in #9715. Unfortunately, this still suffers from the aforementioned problems around using actual state (i.e. the containers might no longer exist) and meant that when operating in file mode (the default), things did not behave as expected: the label is not available in the project since it only exists at runtime.

Now, with these changes, Compose will label any images it builds with project metadata. Upon cleanup during down, the engine image API is queried for related images and matched up with the services for the project. As a fallback for images built with prior versions of Compose, the previous approach is still taken.

Related issue

(not mandatory) A picture of a cute animal, if possible in relation with what you did
a seal swimming towards the camera

When running `compose down`, the `--rmi` flag can be passed,
which currently supports two values:
 * `local`: remove any _implicitly-named_ images that Compose
            built
 * `all`  : remove any named images (locally-built or fetched
            from a remote repo)

Removing images in the `local` case can be problematic, as it's
historically been done via a fair amount of inference over the
Compose model. Additionally, when using the "project-model"
(by passing `--project-name` instead of using a Compose file),
we're even more limited: if no containers for the project are
running, there's nothing to derive state from to perform the
inference on.

As a first pass, we started labeling _containers_ with the name
of the locally-built image associated with it (if any) in docker#9715.
Unfortunately, this still suffers from the aforementioned problems
around using actual state (i.e. the containers might no longer
exist) and meant that when operating in file mode (the default),
things did not behave as expected: the label is not available
in the project since it only exists at runtime.

Now, with these changes, Compose will label any images it builds
with project metadata. Upon cleanup during `down`, the engine
image API is queried for related images and matched up with the
services for the project. As a fallback for images built with
prior versions of Compose, the previous approach is still taken.

See also:
 * docker#9655
 * docker#9715

Signed-off-by: Milas Bowman <milas.bowman@docker.com>
@milas milas requested a review from a team September 7, 2022 22:00
@milas milas self-assigned this Sep 7, 2022
@@ -190,17 +201,108 @@ func (s *composeService) removeNetwork(ctx context.Context, name string, w progr
return nil
}

func (s *composeService) getServiceImagesToRemove(options api.DownOptions, project *types.Project) map[string]struct{} {
images := map[string]struct{}{}
//nolint:gocyclo
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

😬 😬 😬

I've tried to overly comment this method, and it's actually quite procedural despite the high cyclomatic complexity, but I'm interested in suggestions and am happy to refactor, as I do realize it's quite long.

Copy link
Member

@nicksieger nicksieger left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code looks correct, but I think the "1/2/3" comment blocks are a bit of a smell. Maybe it's time for a ImageRemover helper struct that has some methods for each case to break up the logic a bit?

pkg/compose/down.go Outdated Show resolved Hide resolved
Signed-off-by: Milas Bowman <milas.bowman@docker.com>
Signed-off-by: Milas Bowman <milas.bowman@docker.com>
Copy link
Contributor

@glours glours left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants