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

Improve cleanup for docker-compose. #394

Merged
merged 5 commits into from
Jul 9, 2017
Merged

Conversation

rnorth
Copy link
Member

@rnorth rnorth commented Jul 8, 2017

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!

@rnorth rnorth added this to the 1.4.0 milestone Jul 8, 2017
@rnorth rnorth requested a review from bsideup July 8, 2017 18:34
@@ -417,7 +432,7 @@ public ContainerisedDockerCompose(List<File> composeFiles, String identifier) {
}

@Override
public void start() {
public void invoke() {
Copy link
Member Author

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.

Copy link
Member

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") ?

Copy link
Member Author

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.
.getExitCode();

if (exitCode == null || exitCode != 0) {
throw new ContainerLaunchException(
Copy link
Member Author

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();
Copy link
Member Author

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.

Copy link
Member

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));
Copy link
Member Author

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.

@rnorth
Copy link
Member Author

rnorth commented Jul 8, 2017

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();
Copy link
Member

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) {
Copy link
Member

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

Copy link
Member Author

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));
Copy link
Member

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 :)

Copy link
Member Author

Choose a reason for hiding this comment

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

Ah interesting - done :)

Copy link
Member Author

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() {
Copy link
Member

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)) {
Copy link
Member

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) {
Copy link
Member

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?

Copy link
Member Author

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 {
Copy link
Member

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

Copy link
Member Author

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
@bsideup bsideup merged commit 552937e into master Jul 9, 2017
@bsideup bsideup deleted the improve-compose-cleanup branch July 9, 2017 19:46
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

2 participants