Containers have improved my ‘home lab’ significantly. I’ve run a server at home (exposed to the internet) for many years. Linux has made this both easy to do, and fairly secure.<\/p>\n
However, in the old – “I’ll just install these packages on my linux box” – model, you’d end up with package A needing some dependency and package B needing the same one, then you’d have version conflicts. It was always something you could resolve, but with enough software you’d have a mess of dependencies to figure out.<\/p>\n
Containers solves this by giving you a lightweight ‘virtualization’ isolating each of your packages from each other AND it also is a very convenient distribution mechanism. This allows you to easily get a complete functional application with all of it’s dependencies in a single bundle. I’ll point at linuxserver.io<\/a> as a great place to get curated images from. Also, consider having an update policy to help you keep current, something like DUIN<\/a>, or fully automate with watchtower<\/a>.<\/p>\n Watchtower does have the ability to do some cleanup<\/a> for you, but I’m not using watchtower (yet). I have included some image clean up into my makefiles<\/a> because I was trying to fight filesystem bloat due to updates. While I don’t want to prematurely delete anything, I also don’t want a lot of old cruft using up my disk space.<\/p>\n I recently became aware of the large number of docker volumes on my system. I didn’t count, but it was well over 50 (the list filled my terminal window). This seemed odd, some of them had a creation date of 2019.<\/p>\n Let’s just remove them What? If I sub in a volume id that I know is attached to a container, I do get the container shown to me. This feels like both Thankfully the internet is helpful if you know what to search for. Stackoverflow helped me out<\/a>. It in turn pointed me at a github issue<\/a>. Here is what I understand from those.<\/p>\n Docker has both anonymous and named volumes. Unfortunately, many people were naming volumes and treating them like permanent objects. Running In my case, I had some container images which had mount points that I wasn’t specifying as part of my setup. An example is a \/var\/log mount – so when I create the container, docker is creating a volume on my behalf – and it’s a named volume. When I recreate that image, I’m getting a new volume and ‘leaking’ a named volume which is no longer attached to a container. This explains why I had 50+ volumes hanging out.<\/p>\n You can easily fix this<\/p>\n Yup, now I have very few docker volumes on my system – the remaining ones are associated with either a running or a stopped container.<\/p>\n","protected":false},"excerpt":{"rendered":" Containers have improved my ‘home lab’ significantly. I’ve run a server at home (exposed to the internet) for many years. Linux has made this both easy to do, and fairly secure. However, in the old – “I’ll just install these packages on my linux box” – model, you’d end up with package A needing some … Continue reading “Docker system prune – not always what you expect”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6],"tags":[],"class_list":["post-2281","post","type-post","status-publish","format-standard","hentry","category-computing"],"_links":{"self":[{"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/posts\/2281","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/comments?post=2281"}],"version-history":[{"count":2,"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/posts\/2281\/revisions"}],"predecessor-version":[{"id":2284,"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/posts\/2281\/revisions\/2284"}],"wp:attachment":[{"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/media?parent=2281"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/categories?post=2281"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/lowtek.ca\/roo\/wp-json\/wp\/v2\/tags?post=2281"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}docker volume prune<\/code> – yup, remove all volumes not used by at least one container. Hmm, no – I still have so many. Let’s investigate further.<\/p>\n$ docker ps -a --filter volume=efd0e9391281d9d6c9f3270be983dffd7830ea5196da44e9be7bf8d7c56db593\r\nCONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES<\/pre>\n
docker system prune<\/code> and docker volume prune<\/code> are broken.<\/p>\ndocker system prune<\/code> was removing these named volumes if there wasn’t a container associated with it. Losing data sucks, so docker has changed to not remove named volumes as part of a prune operation.<\/p><\/blockquote>\ndocker volume prune --filter all=1\r\n\r\n[lots of output]\r\n\r\nTotal reclaimed space: 53.13MB<\/pre>\n