search

Tapad / sbt-docker-compose

Integrates Docker Compose functionality into sbt (archived as unmaintained)
BSD 3-Clause "New" or "Revised" License
177 stars 36 forks source link

Implement `docker-compose down [--volumes]` #82

Open ches opened 7 years ago

ches commented 7 years ago

The plugin currently implements the dockerComposeStop command, which ultimately runs docker-compose stop, but it also deletes the stopped containers, their anonymous volumes, and the network for the Compose project instance (composition?) according to composeRemoveContainersOnShutdown and composeRemoveNetworkOnShutdown settings which default to true.

This essentially matches the semantics of docker-compose down, rather than docker-compose stop which leaves the resources around to be started back up again (one might intuitively expect dockerComposeRestart to do that).

I feel that a dedicated dockerComposeDown command would be less surprising for users with knowledge of Docker Compose, changing dockerComposeStop to not remove containers/network. IMO the two settings mentioned above should then go away entirely.

This would also open the way to resolve a current shortcoming: named volumes are never deleted. I have real-world Compose configs using those—see #81. The current implementation deletes the containers with:

docker-compose rm -v -f

That only deletes anonymous volumes. This would remove named ones as well:

docker-compose down --volumes

Without this, sbt-docker-compose will leave my CI agents with tons of orphaned Docker volumes over time if builds reference Compose configs containing named volumes.

Changing dockerComposeStop behavior would be backwards-incompatible, but to me the improved parity with docker-compose and named volume cleanup would be a worthy part of a major version bump. We could introduce dockerComposeDown initially in a minor version without yet changing dockerComposeStop or its settings, if desired.

kurtkopchik commented 7 years ago

The plugin was created before dockerComposeDown existed which is why I'm using dockerComposeStop instead. A lot of people are on older versions of Docker (especially build machines) so I would prefer to introduce dockerComposeDown in a minor version as you suggest and deprecate dockerComposeStop for eventual removal in a future major version release.

One thing I did like about dockerComposeStop is that you do have the ability to leave your containers behind which can be helpful when debugging an instance that fails to start.

As for the particular issue with named volumes it would also probably be pretty easy to add some code that gets the set of named volumes and explicitly removes them using docker volume rm <volumeName> command in the same fashion that I remove named networks during the execution of the dockerComposeStop.

kurtkopchik commented 7 years ago

Hi @ches, so that you are not affected by the current dockerComposeStop command leaving behind named volumes I made an update that attempts to remove them on shutdown in a similar fashion to how named networks are removed.

I haven't extensively tested it but released a 1.0.24-SNAPSHOT version for now. If it works for you I can look to get it included in the next official release.

resolvers += "Sonatype Snapshots" at "https://oss.sonatype.org/content/repositories/snapshots/"
addSbtPlugin("com.tapad" % "sbt-docker-compose" % "1.0.24-SNAPSHOT")
ches commented 7 years ago

Thanks a lot for doing this @kurtkopchik, I could have taken a stab at it but you beat me to it. Just getting back to it after a few days but I'm using the snapshot now and it's working well so far.

kurtkopchik commented 7 years ago

Hi @ches - Happy to help! This change is now included in an official release:

addSbtPlugin("com.tapad" % "sbt-docker-compose" % "1.0.24")