[BUG] Remove orphans is stopping containers unrelated to DockSTARTer

[hannonq]

Bug report

Describe the bug
When running ds -c up, existing containers (created outside of DockSTARTer) are being removed.

To Reproduce
Steps to reproduce the behavior:

• Run docker-compose up -d for a stack outside of DockSTARTer e.g. traefik
• Check that it's running with docker ps
• Run ds -v -c up on your existing stack
• See error below in logs:

2021-06-12 13:48:33 [INFO  ]   Downloading run compose script.
latest: Pulling from linuxserver/docker-compose
Digest: sha256:57d36dd05592ac6e7763f470a91394d585fd33c043a53dda40b0480681d8ee66
Status: Image is up to date for ghcr.io/linuxserver/docker-compose:latest
ghcr.io/linuxserver/docker-compose:latest
Removing orphan container "pgadmin"
Removing orphan container "socket-proxy"
Removing orphan container "traefik"
Removing orphan container "redis"
Removing orphan container "postgres"
Removing orphan container "nextcloud"
Removing orphan container "authelia"
Creating dozzle ...
Creating transmissionvpn ...
Creating heimdall        ...
Creating filebrowser     ...

Expected behavior
DockSTARTer shouldn't touch existing containers created in a different stack. DS containers should start up without the --remove-orphans

I see that this behavior is intentional and was introduced in PR 210. It's a nice to have, but I think it should be optional. So, ds -c up should accept run without the --remove-orphans flag and accept this flag if it is desired by the user: ds -c up --remove-orphans.

System
(please complete the following information):

• OS: Ubuntu Server
• Version 20.04 LTS

Additional context
Not sure if this is relevant, but I'm running docker-compose in my system via the linuxserver image.

[nemchik]

This is a valid concern. We also have a prune option via ds -p which shouldn't stop any running containers, but does cleanup unused resources. (kind of an aside)

I think a concern is if you disable something in DS, right now the workflow is you just run ds -c and it removes old things and adds new things at the same time. The only way I can think to accomplish this without a ton of extra logic would be to run docker-compose down followed by docker-compose up. The downside there is containers that would normally have been unaffected will be taken down and recreated for no reason.

Since the main goal of DS is to be user friendly I do feel like seeking some kind of solution is needed. On the other hand, I want DS to be friendly for more advanced users as well, and this issue is definitely something that should be considered.

For now, I can recommend a band-aid fix for your immediate needs: https://dockstarter.com/overrides/introduction/
tl;dr (although I really recommend you do read the docs) create a ~/.docker/compose/docker-compose.override.yml and put the entire compose file you created for traefik, etc. into that file as if it were a separate compose file. With this, DS will create the containers for you when you run ds -c and it will be considered part of the stack DS is meant to manage, but you have free reign over the entire compose in the override file (it merges the override file with DS's compose file). A downside to this is that you may prefer the separation for various reasons, and depending on what you do in your other compose, if you prefer separation of docker networks and things, this method may require additional compose configurations (it can be done, it just might be more work for you).

I'll think on this and look around for options.

[hannonq]

Thanks for your quick reply.
I hadn't thought of those implications.

I am familiar with the override file. I'm using it already to add traefik labels to some DS services. I'll see if it's worth moving my other services into the override file to work around the problem. Thanks for the tip.

I'll keep an eye open in case you come up with a more elegant alternative. And of course, I'll let you know (or send a PR) if I think of a better solution myself.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[nemchik]

This doesn't need to be stale.