How can we optimize/clean disk usage from Docker and more?

[girish]

@d19dotca can you try docker volume prune -a ? Looks like we have some unused volumes storage from the past.

[d19dotca]

@girish That worked well for the volumes, it cleared up the 1.666GB of storage space. Thank you!

What about the images though? It says over 2 GB is reclaimable but it doesn't seem like it is from what I can tell. If I tried to do a similar command specific to images such as docker image prune -a it still gave me a 0 byte response showing it cleaned up nothing. Am I missing something when it comes to reclaimable images in Docker?

[d19dotca]

Here is my docker image list by the way in case this points to any issues at all:

$ sudo docker image ls
REPOSITORY                                     TAG                         IMAGE ID       CREATED        SIZE
cloudron/org.nodebb.cloudronapp                20240403-154317-254cac2fd   3b7a24812a6e   32 hours ago   2.86GB
cloudron/com.invoiceninja.cloudronapp2         20240401-092303-3942cee63   dcda0788296b   3 days ago     3.6GB
cloudron/io.gitea.cloudronapp                  20240326-072227-110a2e6cd   7ed238e459fa   9 days ago     2.74GB
cloudron/sh.ntfy.cloudronapp                   20240326-072218-802b89e89   807661895891   9 days ago     2.26GB
cloudron/org.wordpress.unmanaged.cloudronapp   20240319-202918-2976247a8   1117a989fc3a   2 weeks ago    2.3GB
cloudron/org.radicale.cloudronapp2             20240319-154937-11289c349   036b57520b5b   2 weeks ago    2.22GB
registry.docker.com/cloudron/postgresql        5.2.1                       333f887a27f7   3 weeks ago    2.75GB
cloudron/org.piwik.cloudronapp                 20240308-102528-2182681db   3ddaa6276ff3   3 weeks ago    2.51GB
cloudron/is.umami.cloudronapp                  20240307-081949-7105f94d1   d0512bd1a4c1   4 weeks ago    6.57GB
registry.docker.com/cloudron/sftp              3.8.6                       b735f2120189   4 weeks ago    2.23GB
cloudron/com.github.bitwardenrs                20240303-104654-927b1cf62   1393b91919fa   4 weeks ago    3.51GB
registry.docker.com/cloudron/mail              3.12.1                      ea18fc4dd1c7   5 weeks ago    2.96GB
registry.docker.com/cloudron/mongodb           6.0.0                       4b95d24318a2   8 weeks ago    2.69GB
cloudron/net.roundcube.cloudronapp             20240121-133422-3162a79c7   29ad5d8091ed   2 months ago   2.23GB
cloudron/louislam.uptimekuma.app               20240102-093304-840efe2c0   0e7aea4082d9   3 months ago   3.29GB
cloudron/tech.ittools.cloudron                 20231221-163307-91643bd95   961340a3d920   3 months ago   2.22GB
cloudron/io.cloudron.surfer                    20231216-181458-705d2061b   8a2725a40c45   3 months ago   2.39GB
registry.docker.com/cloudron/graphite          3.4.3                       dbd026164ada   5 months ago   2.28GB
cloudron/net.jirafeau.cloudronapp              20231013-024132-1436ee8da   4155ebdab88f   5 months ago   2.21GB
registry.docker.com/cloudron/redis             3.5.2                       80e7a4079e6b   6 months ago   2.22GB
registry.docker.com/cloudron/mysql             3.4.2                       c7085a52532b   6 months ago   2.53GB
registry.docker.com/cloudron/turn              1.7.2                       152b1fb9690e   6 months ago   2.22GB

[d19dotca]

I'm curious why the Umami app is so massive. It's such a lightweight application... is it expected to be that large? I wonder if this is somehow a contributor to the issue of reclaimable space but not actually being removed since it's still active? Just throwing against a wall though, not sure if that's valid. haha.

[girish]

@d19dotca for volumes, thee was a bug. I fixed this in master yesterday - https://git.cloudron.io/cloudron/box/-/commit/030e4688294d0ffe1c34468e6622c4b1b22fd357

[girish]

@d19dotca speak of the devil... there is a new version of umami, let me check why it's so big.

[jdaviescoates]

@d19dotca said in How can we optimize/clean disk usage from Docker and more?:

docker image prune -a it still gave me a 0 byte response showing it cleaned up nothing.

Just to say, I'm pretty sure that in the past I've done this and got a 0 byte response too, but then there actually was more space available.

[girish]

Just the node modules is 1.4G

root@aaa028f2-b8bc-41cf-82be-a23f59293d39:/app/code# du -hcs *
4.0K	Dockerfile
4.0K	LICENSE
4.0K	README.md
4.0K	app.json
36K	cypress
4.0K	cypress.config.ts
160K	db
8.0K	docker
4.0K	docker-compose.yml
51M	geo
4.0K	jest.config.ts
4.0K	jsconfig.json
4.0K	lang-ignore.json
4.0K	netlify.toml
4.0K	next-env.d.ts
4.0K	next.config.js
1.3G	node_modules
4.0K	package.components.json
8.0K	package.json
4.0K	postcss.config.js
68K	prisma
4.5M	public
4.0K	rollup.components.config.mjs
4.0K	rollup.tracker.config.mjs
60K	scripts
3.2M	src
4.0K	tsconfig.json
532K	yarn.lock
1.4G	total

[d19dotca]

@girish does that mean the image should only be about 1.4 GB in size rather than the 6+GB I’m seeing currently? Very odd if that’s the case, I wonder how that exploded in size.

[d19dotca]

FWIW, I uninstalled the app so that the image would be removed, confirmed it was removed, and then re-installed. The image size changed slightly from 6.57 GB to 6.51 GB, but still quite large. I may be doing in the wrong area though if we don't think this is a huge concern, just really strange to me why it's so much larger than all the other images when it's supposedly a fairly lean app.

For the life of me I cannot seem to reclaim the over 2 GB of disk space from images in Docker, I am puzzled as to why that is happening.

[girish]

@d19dotca it seems the yarn cache was note cleared. Clearing it brought down the size . It's in the new package.