I’m deploying docker and execute docker-compose up as part of deployment. But before the deployment itself, I have a step that makes docker-compose down for a previous deployment. To be able to execute docker-compose down for the currently running docker I have to deploy into a specific folder which is not a recommended approach. I was wondering if there’s a cleaner way to do it in Octopus
Hi,
If I understand correctly, you’re saying you need to execute the docker-compose down command in the folder that was created by a previous deployment, in order to remove the correct containers, networks, etc.
Rather than thinking of it as deploying into a specific folder, would it make more sense to think of it as stashing the current docker-compose file somewhere on the machine? In other words, you can deploy to any folder, but the final step of a successful deployment is to copy the compose file to a well-known location. This may be in a folder, or even into an environment variable.
This is quite nice, as even outside of Octopus you can then run docker-compose down/stop if necessary.
The other option I can think of is to use the –project-name argument. This prefixes the resources created by the docker-compose with the specified value. As an example, you could use something like #{Octopus.Project.Name}-#{Octopus.Release.Number} to get a value like Acme-1.4.0. And you could create the previously deployed project name using #{Octopus.Project.Name}-#{Octopus.Release.CurrentForEnvironment.Number}
This would possibly let you remove the resources without needing the original compose file, using an approach similar to the one suggested by this post.
I’d welcome your thoughts on these options?
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.