-
Notifications
You must be signed in to change notification settings - Fork 5.2k
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
Conversation
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 <[email protected]>
pkg/compose/down.go
Outdated
@@ -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 |
There was a problem hiding this comment.
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.
There was a problem hiding this 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?
Signed-off-by: Milas Bowman <[email protected]>
Signed-off-by: Milas Bowman <[email protected]>
Signed-off-by: Milas Bowman <[email protected]>
dc1397d
to
8016786
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
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 builtall
: 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
--rmi
doesn't remove images when used together with-p
#9655down
with--rmi
#9715(not mandatory) A picture of a cute animal, if possible in relation with what you did