3 ms·
I have also found that if you stick to the core functionality it works fine. As soon as I started to add apps from the store it starts to be a pain. An upgrad
by doubled112 2y ago
I have also found that if you stick to the core functionality it works fine.
As soon as I started to add apps from the store it starts to be a pain. An upgrade comes out and you’re stuck on that version until they all update, OR you update not realizing and lose the functionality for some time.
Since I self-host a bunch of apps, it made more sense to use different apps dedicated to those features, like Miniflux or Navidrome. Not for everybody though.
- kQq9oHeAz6wLLS 2y agoYou haven't necessarily gained anything by going to managing standalone apps individually, though. You've removed the unifying layer, but you're now having to keep up with the app versions and upgrade them individually by hand instead of letting the unifying layer handle it.
- BrandoElFollito 2y agoIf you use docker + watchtower all this is done automatically
- doubled112 2y agoI don’t use Watchtower, but a script that takes a btrfs snapshot before doing a docker compose pull, then docker compose up. Same idea, just safer and fewer surprises.
- sach1 2y agoThat's nice and simple, do you have a shareable version of this script or some advice on btrfs pointers/pitfalls?
- doubled112 2y agoIt's really just those three steps in a loop, nothing fancy SHOT_TIME="$(date +'%Y-%m-%d_%H-%M')" for dir in /docker/* do cd $dir; btrfs subvolume snapshot "${dir}" "/docker/.snapshots/$(basename $dir)-${SHOT_TIME}" docker compose pull --quiet docker compose up -d done I mount a btrfs subvolume at /docker, and create a .snapshots subvolume inside. Each subvolume is an app and its dependencies, you want everything snapshotted as one. This is probably the biggest pitfall, if you don't take that snapshot of all the pieces. /docker |--> .snapshots |--> app_one-2024-08-28_12-34 |--> app_one |--> compose.yaml |--> volumes |--> app_one-config |--> app_one-db |--> app_two |--> compose.yaml |--> volumes |--> app_two-config |--> app_two-db
- doubled112 2y agoI gained working music and RSS that week.
- jerf 2y agoI ran NextCloud for some years, just for the file sharing. I was the only user. About every third upgrade cocked up in some critical way that required bespoke DB fixes. Twice I basically blew away all state and recreated my entire file store from scratch from a backup because it was easier than fixing the install. Worked for me but is infeasible for any larger install. I tried using the office functionality for one document and I lost the document entirely on an upgrade because apparently the mirroring as a file is an illusion and the real office data is stored buried in the database in a way I never did manage to recover; I ended up just recreating the document. Thank goodness it was just the one document. It is constantly screaming for upgrades but I don't know what they are doing with those upgrades because it doesn't seem to make the core any more reliable. It's just an opportunity for the upgrade to fail and lose data, which it frequently took advantage of. The key thing that really annoyed me is that I couldn't hardly have used it more lightly than I did, and it took about every other opportunity to fall over and lose data. I can't even imagine the plight of someone trying to run this in an office environment.