So… what is the safe/correct way to delete the unnecessary stuff (shutting down the containers or restarting the server does not seems to have any effect)?
@rfvieira thanks for the link! I had read the suggestions in that thread, but my doubts remain: is there any official ODK guideline about how to clean up the overlay2 folder?
I’m not the software architect here, so probably not the most qualified to say out loud, but from my understanding there is no way ODK could have such guide.
ODK implementation is ON TOP of docker engine, it creates many docker containers for different purposes and orchestrates their configuration to provide Central and it’s components (containers) as a single web application.
The content of /var/lib/docker/overlay2 is controlled by the Docker Engine running in your server. This is why you have to use docker related commands like docker image prune to cleanup and also have some experience using Docker to host and manage your own server.
@rfvieira thanks for the reply, but I respectfully disagree, as a user. I have seen this argument from devs in other projects I use or I’m involved in and from a user point of view this is really frustrating. Yes sure, is clear that in this case some specific docker command must be used, but what command exactly so that a user does not risk to kill his/her Central installation? It is not necessary to cover all possible scenarios, it would be enough to cover one, for example the one for a typical installation on DigitalOcean, as already covered by the installation docs. I can do a PR against ODK docs, but I need to be sure about what to write, seems to me that is well worth a paragraph, no one wants tens of GB of useless files taking up valuable disk space in their servers/VMs. I have seen a few times here in the forum the argument that the ODK project does things to prevent/protect users from making mistakes, I think that this case applies also. Cheers!
@manghig how did you determine the files were useless?
I ask because it seems like you want a guide to shrink core parts of the containers, but that is not usually how you interact with containers - the common workflow is to build once and then not touch the overlays. Deleting things can break core components of the containers.
If you want to shrink your ODK instance, I would recommend you take a backup of the database, delete your ODK installation, prune all docker images/volumes/artifacts, and recreate the containers from scratch. This will be the only way to safely ensure you have the minimal size application running.
Could you try that and see if your install size shrinks? Otherwise, I would assume most of the size comes from libraries and tools that are important to making ODK work.
There is definitely a thin line between what has to be covered in the docs and what's not and our expectations might vary from person to person.
But looking at this question from a different perspective, is like playing with the content of /var/lib/postgresql/17/main (the folder where PostgreSQL 17 usually stores data on the filesystem) to cleanup a database instead of learning SQL and using psql for example.
The command docker image prune (and others like docker compose pull && docker compose build --pull") are needed to execute updates and Central's installation.
The image prunning is a process that cleans the local image repository on your server deleting unused images and the temporary ones that are usually created during Central's update.
You might take care using that command too if your server is not running only Central’s but also other containers, which is totally fine depending on your setup.
To get more details on overlay2 and the more recent OverlayFS used by the latest Docker Engine this article is a good place to start:
@rfvieira no offense taken, in fact on second thoughts I was probably the rude one.
Thanks all for the answers and pointing me to the reference of docker image prune in the upgrade docs. I will try and see if it also helps not necessarily only when upgrading (in getting rid of unused images).
did not helped much, in fact it didn’t at all. On the other hand
docker builder prune
that removes unused build cache only seems to have removed a lot of unused stuff helping recovery a good chunk of disk space. It doesn’t seems to have killed my Central instance.
