-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Improve cleanup for docker-compose. #394
Conversation
@@ -417,7 +432,7 @@ public ContainerisedDockerCompose(List<File> composeFiles, String identifier) { | |||
} | |||
|
|||
@Override | |||
public void start() { | |||
public void invoke() { |
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.
Changed this (internally used) method name, as it's always a blocking operation and invoke
seems more accurate.
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.
that's a good change, I was confused by getDockerCompose(...).start(...)
constructions :)
P.S. do we use anything else besides invoke()
on getDockerCompose
's return value? Is not, maybe we can simplify it to something like runWithCompose("down -v")
?
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.
Good call, will do!
Reduce unnecessary cleanup attempts which cause errors to be logged. docker-compose down is now trusted to have cleanup up properly if it exits with a 0 status code.
3944eac
to
a7dbb82
Compare
.getExitCode(); | ||
|
||
if (exitCode == null || exitCode != 0) { | ||
throw new ContainerLaunchException( |
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.
As with LocalDockerCompose
, we now throw an exception if a failure occurred. This allows us to detect a failure of docker-compose down
.
@@ -143,13 +146,6 @@ public void removeNetworks(String identifier) { | |||
|
|||
private void removeNetwork(String networkName) { | |||
try { | |||
try { | |||
// First try to remove by name | |||
dockerClient.removeNetworkCmd(networkName).exec(); |
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.
This seems to always fail and causes an error log. I'm just running some checks that this doesn't let any excess containers survive cleanup.
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.
@rnorth ouch. It doesn't fail when recently added Docker Networks support is being used (because we know the IDs), so I wouldn't remove it.
Since we list networks in Docker Compose's implementation, maybe we can use the IDs there as well?
// If we reach here then docker-compose down has cleared networks and containers; | ||
// we can unregister from ResourceReaper | ||
spawnedNetworkIds.forEach(id -> ResourceReaper.instance().unregisterNetwork(identifier)); | ||
spawnedContainerIds.forEach(id -> ResourceReaper.instance().unregisterContainer(id)); |
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.
This is the core of the change - we unregister containers and networks if docker-compose down
seems to have worked.
This should fix #342 |
@@ -143,13 +146,6 @@ public void removeNetworks(String identifier) { | |||
|
|||
private void removeNetwork(String networkName) { | |||
try { | |||
try { | |||
// First try to remove by name | |||
dockerClient.removeNetworkCmd(networkName).exec(); |
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.
@rnorth ouch. It doesn't fail when recently added Docker Networks support is being used (because we know the IDs), so I wouldn't remove it.
Since we list networks in Docker Compose's implementation, maybe we can use the IDs there as well?
// we can unregister from ResourceReaper | ||
spawnedContainerIds.forEach(id -> ResourceReaper.instance().unregisterContainer(id)); | ||
spawnedNetworkIds.forEach(id -> ResourceReaper.instance().unregisterNetwork(identifier)); | ||
} catch (ContainerLaunchException e) { |
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.
maybe catching just Exception
will be better here? Any Exception in invoke
will prevent Reaper from being called
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.
👍
ResourceReaper.instance().removeNetworks(identifier); | ||
// If we reach here then docker-compose down has cleared networks and containers; | ||
// we can unregister from ResourceReaper | ||
spawnedContainerIds.forEach(id -> ResourceReaper.instance().unregisterContainer(id)); |
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.
FYI spawnedContainerIds.forEach(ResourceReaper.instance()::unregisterContainer);
is also valid here :)
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.
Ah interesting - done :)
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.
Not quite sure I follow this:
Since we list networks in Docker Compose's implementation, maybe we can use the IDs there as well?
But I'd interpret this as 'let's only register network IDs, not names'. Is that right? I'll change and make sure we use IDs throughout, then I think we should be OK.
@@ -417,7 +432,7 @@ public ContainerisedDockerCompose(List<File> composeFiles, String identifier) { | |||
} | |||
|
|||
@Override | |||
public void start() { | |||
public void invoke() { |
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.
that's a good change, I was confused by getDockerCompose(...).start(...)
constructions :)
P.S. do we use anything else besides invoke()
on getDockerCompose
's return value? Is not, maybe we can simplify it to something like runWithCompose("down -v")
?
@@ -173,17 +175,20 @@ private void registerContainersForShutdown() { | |||
|
|||
// Ensure that the default network for this compose environment, if any, is also cleaned up | |||
ResourceReaper.instance().registerNetworkForCleanup(identifier + "_default"); | |||
spawnedNetworkIds.add(identifier + "_default"); | |||
|
|||
// Compose can define their own networks as well; ensure these are cleaned up | |||
dockerClient.listNetworksCmd().exec().forEach(network -> { | |||
if (network.getName().contains(identifier)) { |
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.
not related to this PR, but AFAIK we shouldn't use contains
here, but startsWith
or whatever the rule for Docker Compose, otherwise if identifier if "a", then it will delete all networks with "a" character in name :D
*/ | ||
public void registerNetworkForCleanup(String networkName) { |
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.
Since this method was semi-public, maybe it worth keep the old one and mark as deprecated, at least until 1.5.0?
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.
Yep - will reinstate all public methods as they were and deprecate, 👍
try { | ||
try { |
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 think this block should do the job when parameter is id, and "list with filter" is not required anymore
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.
It could be clearer - I'll do that.
I think we still need to keep the list-with-filter operation though: if the network has already been removed for any reason, dockerClient.removeNetworkCmd
will log out an error. So we need to do something to check for the existence of the network first that won't log an error.
Improve comments to aid clarity in removeNetwork method
Reduce unnecessary cleanup attempts which cause errors to be logged.
docker-compose down is now trusted to have cleanup up properly if it
exits with a 0 status code.
I hope we can squeeze this in to 1.4.0!