Stop a Docker Resource also removes container even though it is set to only stop it

Legacy Containers
1

Hi there,

We are trying to use Octopus to deploy Docker containers (on linux). As a part of deployment we are trying to use Stop a Docker Resource step to stop currently running container (from a previous deployment) but even though we configured the step only to stop container it also deletes it.
Here are the relevant parts of the deployment log:

Octopus Server version: 2019.6.8+Branch.tags-2019.6.8.Sha.2813706b187ebc8c2f63ed14cd888df3dc271563
Using Calamari.linux-x64 6.0.0
OperatingSystem: Linux ip-172-31-1-171.ap-southeast-2.compute.internal 4.14.138-114.102.amzn2.x86_64 #1 SMP Thu Aug 15 15:29:58 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
Docker version 18.06.1-ce, build e68fc7a215d7133c34aa18e3b72b4a21fd0c6136
Using filter: --filter label=Octopus.Project.Id=Projects-81 --filter label=Octopus.Environment.Id=Environments-2
Stopping container: /suspicious_chaplygin
Removing container: /suspicious_chaplygin

The last line is unexpected and unwanted but we are not sure why it happens and how to force the step only to stop the container.

Also a question regarding retention policy in relation to Docker containers deployed over SSH: does it have any affect on them? I.e. will the containers/images be deleted when retention policy deletes the release?

3

Hi Eduard

Thanks for getting in touch! Sorry to see you’re having issues here - it seems that you’re definitely hitting a bug. Looking at the code, it seems to not pay any attention to the “stop” vs “stop and remove” options - it always hits the “stop and remove”.

Can you outline your use case a bit more here, so I can understand what you’re trying to do?

The script we’ve got:

  1. removes the network matching the filter
  2. stops the containers matching the filter
  3. removes the containers matching the filter

In the stop only scenario, would you expect the network to be removed? I assume no, but will be good to understand your expectations here.

I’ve logged an issue which you can follow to get notified when this is fixed.

For now, I would suggest using a script step that runs docker stop --filter label=Octopus.Project.Id=Projects-81 --filter label=Octopus.Environment.Id=#{Octopus.Environment.Id} - that should have the desired behavior.

Looking forward to your feedback on making this better.

Regards,
Matt

4

Hi Matt,

Thank you for your response and raised issue.

As for the use case, it is rather typical: we are moving our infrastructure from Windows to Linux + Docker and would like to continue using Octopus Deploy for our deployments (now via SSH targets), which means we would expect Octopus to act in a similar fashion it does with Windows targets:

  1. When new release is deployed the previous release’s container is stopped but retained on the target machine until pre-configured retention policy kicks in and removes it (e.g. we should be able to specify, say, 5 old releases to be kept on the target)
  2. When retention policy removes the release we would expect it to remove both the container and the image.

We are not sure how Octopus handles Docker images when retention policy is supposed to remove the release: we’ve never seen in logs any events indicating that the Docker image or even release is removed hence the last part of my previous post: does Octopus Deploy support cleaning up of old Docker images? And if it does not, are there any plan to implement it? Is there a workaround?
If it is not supported I suspect we can just add a deployment step which deletes the image from the previous release but it would be nice if Octopus took care of it as it does on Windows, otherwise the target machine would become polluted with old images after prolonged use.

Regards,
Eduard

6

Hi Eduard,

To answer your question regarding the retention policy for Docker -

does Octopus Deploy support cleaning up of old Docker images? And if it does not, are there any plan to implement it? Is there a workaround?

Unfortunately we don’t support retention policies on Docker Images or Containers.

Although it is a very good idea, we currently have no plans to implement this functionality.

A workaround to this would be to manually remove the containers and/or images yourself, you could do this using the “Run a Script” step in your deployment process.

Some helpful docker commands you could use are -

docker container prune // https://docs.docker.com/engine/reference/commandline/container_prune/
//or
docker image prune // https://docs.docker.com/engine/reference/commandline/image_prune/

Thank you,
Ankith