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
dokku cleanup removed all "exited" containers #1220
Comments
How are we to detect that you're running a non-dokku provided container? |
Possible solution is to label (--label) containers created with Dokku, then modify clean-up to only remove those. Note that any plug-ins need to be modified to also label their containers. You'd need to modify dokku itself to accomplish this though. |
Is it possible to run all docker build commands with "--rm" option, it will automatically remove container after doing the work. so there won't be any need for cleanup. |
That would potentially leave images and containers, for example the Docker daemon crashing would prevent containers (with |
it's also very useful to have the intermediate images/containers around debug deployments. Dokku was never (from what I can tell) specifically written to "play nice" with non-dokku managed images and containers. Having said that, we can definitely label dokku core containers but as @3onyc mentioned, plugins will also need to be modified. Anybody else have thoughts on this? |
I have just been hit by that issue. Maybe the doc should say more clearly that dokku is not meant to work with other docker containers. |
@michaelshobbs Not sure I understand your first comment:
In any case, I would rather we just state in the docs that dokku doesn't play nice with externally-managed containers. We should definitely not delete data-only containers, though I'm not sure what we can do here. Maybe support a special, dokku-specific label that we'll use to ensure we don't kill certain containers? |
👍 for containers labelling |
not fan of the "dokku" label, imo it means it's managed by dokku, when it's not. I don't have another suggestion though :/ anyway this is just what i needed :) any date for next release ? :) |
OTOH, now I have to change all the tools I use beside dokku to add a I think it would be better if dokku could play nice with non-dokku images and containers. |
@Cactusbone No, I take that label to mean that it is related to dokku. Personally I assume anything in docker is somehow managed by dokku, and if it's not, then that's up to the user of dokku to figure out. This is just giving you all a simple way to skip those containers. @jazzzz We could disable the |
@josegonzalez I use many images and containers beside dokku: some are created and started with shells scripts, some with ansible, some directly from Docker Hub, some are manually created... It would make dokku much less useful for me if dokku needs to manage everything in docker. I think it would be better to tag dokku related containers and images with the Anyway, a plugin with a data-only container will need to set the |
@jazzzz I still don't understand how you would want dokku cleanup to work. We can either cleanup containers or we don't. In either case, someone is going to have issues. |
As well, we are only using this to remove exited containers. So if your container is running,it sticks around. |
@josegonzalez I would prefer if dokku only remove exited containers with the With the current implementation, if I use a docker container with a database in a data-only container (with a dokku plugin or not), because this container is not running, dokku will delete this container and I will lose my data. |
(Preface: IMHO) @josegonzalez what exactly needed to re-implemented for service containers? if a service container is running it doesn't get stopped or removed and i'd hope that service containers are using docker volumes for persistence in case the container does get 'accidentally' cleaned up by some other (user's or otherwise) action. |
Not sure if I was clear, I was talking about data volume containers. These containers are not running, thus dokku removes them. |
@michaelshobbs they persist data and config onto disk (in Re: container-management, I agree that I see dokku as the sole-arbiter of containers on a given host. The simplest thing I can think of is allowing people the ability to disable @jazzzz those containers are running for me?
|
@josegonzalez for me it's not running, Try with |
Interesting, I guess if there is no status, that is treated as exited by docker. What fun! |
Seems like there isn't a way to check if a container is a data-only container, as they are a convention, not an actual docker construct. |
Yeah, that's why I suggest that dokku creates a |
We don't want to remove the service plugins on boot of the server, hence the current hack. |
Rather than having a one-off hack for "blessed" containers, we should solve the issue properly. As that would take a bit more work, reverting to the previous state is preferred. Better that we solve a problem problem than with a hack that we'll need to roll back in the future. Refs #1220 [ci skip]
Rather than having a one-off hack for "blessed" containers, we should solve the issue properly. As that would take a bit more work, reverting to the previous state is preferred. Better that we solve a problem problem than with a hack that we'll need to roll back in the future. Refs #1220 [ci skip]
Rather than having a one-off hack for "blessed" containers, we should solve the issue properly. As that would take a bit more work, reverting to the previous state is preferred. Better that we solve a problem problem than with a hack that we'll need to roll back in the future. Refs #1220 [ci skip]
Rather than having a one-off hack for "blessed" containers, we should solve the issue properly. As that would take a bit more work, reverting to the previous state is preferred. Better that we solve a problem problem than with a hack that we'll need to roll back in the future. Refs #1220 [ci skip]
Rather than having a one-off hack for "blessed" containers, we should solve the issue properly. As that would take a bit more work, reverting to the previous state is preferred. Better that we solve a problem problem than with a hack that we'll need to roll back in the future. Refs #1220 [ci skip]
Rather than having a one-off hack for "blessed" containers, we should solve the issue properly. As that would take a bit more work, reverting to the previous state is preferred. Better that we solve a problem problem than with a hack that we'll need to roll back in the future. Refs #1220 [ci skip]
@michaelshobbs we can probably add the |
Yeah works for me |
@josegonzalez plugins would need to follow this as well, right? |
We're only going to cleanup apps started/stopped by dokku. If a plugin wants to opt into that cleanup, up to them. For example, the official service plugins shouldn't (because we might accidentally cleanup a stopped container during a deploy). |
Ok I noted in the docs of #1828 how to do it and why you might want. The language might need to be cleaned up a bit. |
@michaelshobbs worth adding this to 0.5.x or waiting till 0.6.x? |
@josegonzalez your call. PR created 😄 |
dokku should only remove containers created by dokku. It should not remove containers created by others.
I'm running host, with dokku and other docker images. I use 'data-only' container pattern to store data in a 'non-running' container. But dokku removes my non-running data container as well.
http://container42.com/2013/12/16/persistent-volumes-with-docker-container-as-volume-pattern/
https://github.com/progrium/dokku/blob/4aedb6507a3bdec1ff29be2ff60366075186a72e/dokku#L170
The text was updated successfully, but these errors were encountered: