fin cleanup should only prune Docksal volumes and images

[dhavalgshah]

Description

fin cleanup prunes every unused volume. This may be okay if one only uses Docksal for all Docker usage. However, in many cases, devs have multiple additional Docker images, containers, volumes, and networks depending on their needs.

In Docker volumes pruning, "unused" volumes ares determined at the time when the command is run. There is no way to automagically determine if a volume is truly undesired.

In my case, I nearly lost all my reports, DB data, and shared configs stored on named volumes for which containers were stopped/removed. Thanks to backups, I didn't lost hours of test reports.

Steps to reproduce the issue:

0. Use a clean Docker installation.
1. Run some image with named volume. (Eg. try (Devilbox)[https://github.com/cytopia/devilbox/])
2. Install Docksal.
3. Stop and remove container from step 1 OR just restart your system.
4. Do fin cleanup.

Describe the results you received:

You would loose all your volumes (if any) from Step 1 even if they aren't related to Docksal.

Describe the results you expected:

Docksal commands should only affect items it creates and manages. Global system wide implications are undesirable. Further to this, there aren't any warnings shown to users before doing this destructive operation.

#582 discusses granular clean-up but does mainly focus on networking issues.

docker volume prune -f 2>/dev/null should be reconsidered as it removes all unused volumes.

Instead docker volume prune -f --filter 'label=io.docksal.project-root' 2>/dev/null or similar should be used so not to affect other volumes.

Output of fin config:

fin config output

n/a as this is not a project specific issue.

Output of fin sysinfo:

fin sysinfo output

███  OS
Linux Manjaro Linux 
Linux mindmantra-lp 5.0.9-2-MANJARO #1 SMP PREEMPT Sun Apr 21 07:11:08 UTC 2019 x86_64 GNU/Linux

███  ENVIRONMENT
MODE : Linux Kernel
DOCKER_HOST : 

███  FIN
fin version: 1.85.1

███  DOCKER COMPOSE
EXPECTED VERSION: 1.23.2
docker-compose version 1.23.2, build 1110ad01
docker-py version: 3.6.0
CPython version: 3.6.7
OpenSSL version: OpenSSL 1.1.0f  25 May 2017

███  DOCKER
EXPECTED VERSION: 18.09.2

Client:
Version:           18.09.5-ce
API version:       1.39
Go version:        go1.12.3
Git commit:        e8ff056dbc
Built:             Fri Apr 12 08:22:13 2019
OS/Arch:           linux/amd64
Experimental:      false

Server:
Engine:
Version:          18.09.5-ce
API version:      1.39 (minimum version 1.12)
Go version:       go1.12.3
Git commit:       e8ff056dbc
Built:            Fri Apr 12 08:21:24 2019
OS/Arch:          linux/amd64
Experimental:     false

███  DOCKSAL: PROJECTS
project             STATUS              virtual host        project root

███  DOCKSAL: VIRTUAL HOSTS
No virtual hosts found

███  DOCKSAL: DNS
ERROR: Requesting http://dns-test.docksal failed!

███  DOCKER: RUNNING CONTAINERS
CONTAINER ID        IMAGE                   COMMAND                  CREATED             STATUS                  PORTS               NAMES
0877350f06e9        docksal/ssh-agent:1.2   "docker-entrypoint.s…"   17 hours ago        Up 13 hours (healthy)                       docksal-ssh-agent

███  DOCKER: NETWORKS
NETWORK ID          NAME                DRIVER              SCOPE
915fe1125fd1        _default            bridge              local
f58f67590987        bridge              bridge              local
71ee0e8a81b0        host                host                local
4407f014d9dd        none                null                local

███  VIRTUALBOX
EXPECTED VERSION: 5.2.26
6.0.6r129722

███  HDD Usage
Filesystem      Size  Used Avail Use% Mounted on
dev             1.9G     0  1.9G   0% /dev
run             1.9G  1.5M  1.9G   1% /run
/dev/sda6        30G   23G  6.3G  79% /
tmpfs           1.9G   20M  1.9G   2% /dev/shm
tmpfs           1.9G     0  1.9G   0% /sys/fs/cgroup
tmpfs           2.0G   56M  2.0G   3% /tmp
/dev/sda7        29G   19G  8.8G  68% /home
/dev/sda2        80G   71G  9.2G  89% /media/windows
/dev/sda3        61G   50G   12G  82% /media/data
/dev/sda5        29G   19G  8.8G  68% /media/vm
tmpfs           374M   36K  374M   1% /run/user/1000


Error response from daemon: Container 306820fc54df17e9d5fd9c05865e1feee5cec0604493c4fdc3c1c62c409a0a47 is not running
curl: (6) Could not resolve host: dns-test.docksal

[achekulaev]

Why do you want to keep a volume that is not used in any container?

[dhavalgshah]

@achekulaev

While there can be number of reasons to have such volumes, mine is that they house data common to my workflow. I attach them to different projects as and when I need them.

Sometimes they are dangling if I accidentally restarted my system without executing proper shutdown process for containers. But there are also days where I don't have any containers where I have them attached.

I use plain Dockerfiles, docker-compose.yml, Ansible, and Devilbox as needed. Being a contractor, I often find myself in situation where I have to follow existing devops guideline of my clients. As such, I would have a lot of non Docksal images/containers/networks/volumes on my system which I don't want Docksal to manage.

TBH volumes are the an aspect of Docker which is not outright disposable in dev environments.

I think the gist of opening this issue was to express a concern that "Should Docksal, or any wrapper utility, manipulate things which it has not created or is not controlling, especially when the action is destructive?".

[achekulaev]

I understand the gist, bit I wanted to see if it was purely theoretical use case or a real-world use case that you meet more than once. Thanks.

[dhavalgshah]

My apologies if I went overboard. It wasn't intentional. I wanted to describe the use-case as much as I can and mainly the side-effects.

Also, I need to better manage tabbing. Closing the issue wasn't intentional either. (p.-)

[achekulaev]

On one hand cleanup was intentionally made to be far reaching beyond Docksal. So by default there is nothing to fix. If you don't want to cleanup all unused Docker things then do not use fin cleanup, and use fin project remove to remove undesired project containers and volumes instead.

However on the other hand we use cleanup in the update, and that might lead to unintended consequences like the ones described above.

So action items for this ticket will be:

1. Rework cleanup function so that by default it would only cleanup Docksal containers, images and volumes.

2. Make --all (--all-unused?) option to cleanup all unused and dangling images and volumes (the way it works currently without params), and then the existing --hard (should it be --all, --purge?) option to delete all stopped containers and then cleanup.

The vision might shift but it should set the direction for this enhancement.

[dhavalgshah]

Adding new flags may break some existing workflows IMHO.

Adding the current destructive volumes pruning behavior to --hard may work better. It should have warning that it affects all Docker images/containers/volumes/networks. An additional user prompt might be a good option.

While with just fin cleanup we can use --filter argument to remove only Docksal volumes of projects. E.g. docker volume prune -f --filter 'label=io.docksal.project-root' 2>/dev/null.

OR code below can be changed to
docker ps -qa --filter "label=com.docker.compose.project=${project_name}" | xargs docker rm -vf

docksal/bin/fin

Line 1321 in 17edb35

docker ps -qa --filter "label=com.docker.compose.project=${project_name}" | xargs docker rm -f

Adding -v flag would make docker to remove any volumes attached to particular container. Although, this would not remove any named volumes attached to that container as per Docker docs.

[dhavalgshah]

On one hand cleanup was intentionally made to be far reaching beyond Docksal. So by default there is nothing to fix. If you don't want to cleanup all unused Docker things then do not use fin cleanup, and use fin project remove to remove undesired project containers and volumes instead.

fin cleanup does not inform users that it will be far reaching beyond Docksal. Neither do documentation.

However on the other hand we use cleanup in the update, and that might lead to unintended consequences like the ones described above.

Documentation also lists fin cleanup as a step for Uninstall.

Imagine a use-case where a Dev or Ops person wanted to try Docksal because they hear great things about it at a meetup. Now, after their testing they may want to remove it for time being. While following the docs to the letter they will be left with all their other data pruned. This is an unwarranted side-effect. And this was me today.

About design choices

In development tools it is okay to have some non-destructive side-effects, such as performance hit due to Xdebug or large project size due to node packages.

Although, touching non core items is always a bad design choice with unwarranted side-effects. This can lead someone to debugging hell.

Those who don't really know much about Docker internals would not know why their data from other non-Docksal project vanished. Those with know-how, may also loose essential work/data because they might already are an advance user with customization here & there.

[achekulaev]

Documentation on cleanup clearly states that cleanup Removes unused Docker images and projects, Removes unused docker images and orphaned containers to save disk space and that is exactly what it does at the moment (update: it doesn't mention volumes, it should)

Those who don't really know much about Docker internals would not have a volume they need that is unattached to a container, since it is a very advanced use case IMHO.

The use of cleanup in install and uninstall procedures is the only reason why I am opting into changing the default cleanup behavior.

[lmakarov]

@dhavalgshah thanks for bringing this up.

While the "valuable dangling volume" use case is indeed advanced and most users won't ever run into it, we definitely do not want the default behavior for fin cleanup to lead to destructive results for advanced users.

Adding -v flag would make docker to remove any volumes attached to particular container. Although, this would not remove any named volumes attached to that container as per Docker docs.

It used to be that way, but had to be changed exactly because named volumes would not be removed with the -v flag.

with just fin cleanup we can use --filter argument to remove only Docksal volumes of projects. E.g. docker volume prune -f --filter 'label=io.docksal.project-root' 2>/dev/null.

This sounds like the best course of action, except we'll have to start labeling all volumes managed within Docksal with a single consistent label (e.g., label=io.docksal.volume). This is the only way to reliably know whether a volume is/was part of a Docksal managed docker-compose project or not:

docker volume prune -f --filter 'label=io.docksal.volume' 2>/dev/null

[lmakarov]

My take on the solution ^ (#1058)