30 Go est-il maintenant trop petit pour une mise à niveau ?

J’ai un droplet Digital Ocean en cours d’exécution. Je suis actuellement sur la version v2.1.0.beta1 +149 et j’ai été invité à mettre à jour Docker (réussie) avant de passer à Discourse. Je ne peux plus effectuer de mise à jour en raison d’un manque d’espace (il indique 27 Go sur 30 Go et il faut un minimum de 5 Go).

Il s’agit d’un petit site avec quelques utilisateurs et très peu de pièces jointes multimédias. La liste des répertoires les plus volumineux me donne :

  • 16 Mo bin
  • 1,1 Go boot
  • 2,1 Go swapfile
  • 3,4 Go usr
  • 5,1 Go lib
  • 19 Go var

Ensuite, dans /var :

1,7 Mo backups
24 Mo log
66 Mo cache
2,4 Go discourse
16 Go lib

Puis dans lib/ :

42 Mo mlocate
125 Mo dpkg
144 Mo apt
16 Go docker

Y a-t-il quelque chose qui semble anormal dans ces données ?

Quelqu’un peut-il suggérer où je pourrais libérer suffisamment d’espace pour que la mise à jour fonctionne ? Passer d’un droplet de 30 Go chez Digital Ocean ne semble pas simple.

I believe there are existing topics on this, how to clear up space. The TL;DR version is:

/var/discourse/launcher cleanup
apt-get autoclean
apt-get autoremove

I was updating a droplet so here’s a before and after those three commands

root@talk:/var/discourse# df
Filesystem     1K-blocks     Used Available Use% Mounted on
udev             1005384        0   1005384   0% /dev
tmpfs             204812    21136    183676  11% /run
/dev/vda1       41153856 15600148  23440172  40% /
tmpfs            1024040      584   1023456   1% /dev/shm
tmpfs               5120        0      5120   0% /run/lock
tmpfs            1024040        0   1024040   0% /sys/fs/cgroup
cgmfs                100        0       100   0% /run/cgmanager/fs
tmpfs             204812        0    204812   0% /run/user/1000
none            41153856 15600148  23440172  40% /var/lib/docker/aufs/mnt/2a8
shm               524288        8    524280   1% /var/lib/docker/containers/f8f

here’s the result

root@talk:/var/discourse# df
Filesystem     1K-blocks     Used Available Use% Mounted on
udev             1005384        0   1005384   0% /dev
tmpfs             204812    21152    183660  11% /run
/dev/vda1       41153856 11923676  27116644  31% /
tmpfs            1024040     1304   1022736   1% /dev/shm
tmpfs               5120        0      5120   0% /run/lock
tmpfs            1024040        0   1024040   0% /sys/fs/cgroup
cgmfs                100        0       100   0% /run/cgmanager/fs
tmpfs             204812        0    204812   0% /run/user/1000
none            41153856 11923676  27116644  31% /var/lib/docker/aufs/mnt/2a8
shm               524288        8    524280   1% /var/lib/docker/containers/f8f

Thank you very much @codinghorror . Docker cleanup gave me back 6 GB or so & the Ubuntu cleanup showed up plenty of old kernels, so another 4GB or so. It’s now maintainable:

Filesystem     1K-blocks     Used Available Use% Mounted on
udev              487940        0    487940   0% /dev
tmpfs             101608    10880     90728  11% /run
/dev/vda1       30428648 14770996  15641268  49% /
tmpfs             508028     1028    507000   1% /dev/shm
tmpfs               5120        0      5120   0% /run/lock
tmpfs             508028        0    508028   0% /sys/fs/cgroup
tmpfs             101608        0    101608   0% /run/user/0
none            30428648 14770996  15641268  49% /var/lib/docker/aufs/mnt/800
shm               524288        8    524280   1% /var/lib/docker/containers/618

Doing this manually once a year or so seems painless enough, but could I configure unattended upgrades to deal with the kernels & docker? Is this wise on an instance that does nothing but run vanilla Discourse or might it conflict with Discourse upgrade scripts?