add a docker system prune with configurable options to undeploy step of lifecycle #417
Labels
No Label
abra
abra-gandi
awaiting-feedback
backups
bug
build
ci/cd
community organising
contributing
coopcloud.tech
democracy
design
documentation
duplicate
enhancement
finance
funding
good first issue
help wanted
installer
kadabra
performance
proposal
question
recipes.coopcloud.tech
security
test
wontfix
No Milestone
No project
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: coop-cloud/organising#417
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Perhaps
abra app undeploy --prune? Andabra system prune [--all] [--volumes](for the case where the app local configs are completely deleted andabrahas no way to knowing which apps are deployed?) In general I'd like a separate command for this as it get hards to debug when the functionality is mixed? But yeh, happy to see some UI/UX proposals on this!Should this be
abra server prune <server name>there is currently no system command and I don't know if a datapoint of 1 is justifcation for a new sub command?Oh yeh, that's nice @codegod100! Perhaps
rmvs.prunemight be confusing there, so feel free to try another wording. But probably docs on the sub-command can solve this.+1 for an abra prune command (I have to ssh on to the server and run it often because of deploying incremental and the old docker images taking up space)
It would be nice to show a list of running containers, explaining that all containers not currently running will be deleted (including their stored secrets) and prompt to continue (yeah been burned before 😅)
@mayel currently it doesn't remove secrets. Is that something I should add? Right now I'm calling the built in prune commands on the docker client. "Pruning" secrets is kind of a non-concept. I can add a prompt to continue and a container list.
Well I'm not sure what's expected behaviour but in my experience I had to recreate or readd the secrets after redeploying an accidentally pruned
I'm pretty sure there is no prune functionality for docker secrets maybe it was #405 ?
I found an open ticket about possibly pruning secrets in the future https://github.com/moby/moby/issues/38007
I don't mean as an abra thing, just when running
docker system prunedirectly on the server when your app isn't runningI'm pretty sure
docker system prunedoesn't touch secrets unless I'm misunderstanding you.Well maybe it doesn't actually remove them, but if you remove a stoppedcontainer they don't get re-associated correctly when you redeploy it?
By contrast when that happened the volumes got correctly re-associated
I haven't really messed with docker secrets because my primary development app doesn't use secrets. If this is the case it's definitely good to be mindful of. I'll look into it.
May be good to also expose
docker image prune(ideally even as a flag to autorun after a deploy) which should be enough for cases where you didn't undeploy and just need to keep a handle on storage space. Bit of a tangent from the original issue, but it's beenI undeployed an app with secrets and did a system prune and verified that all images and containers relating to it were gone and then redeployed and the secrets still worked. I'll keep my eye on it to see if I see a pattern somewhere.