Nextcloud and GitLab have both made me absolutely hate updating software, especially when it's running inside of Docker containers. The idea itself is pretty simple - since containers are largely immutable (except for data in volumes or bind mounts), you should just be able to download a newer version and just run it, right?
Well, no, not really. That's just now how the real world works. Sure, software detects that the DB schema is made against an older version of it and most of the time will try to update (please don't use software that requires manual updates, those are usually not worth it) but for a variety of reasons this breaks. For example, i was running Nextcloud 17 and wanted to update to Nextcloud 20, because it just kept nagging me with notifications (and because the next version has a number of nice integrations, such as Nextcloud Talk).
The idea was simple enough, i'd just change a single image parameter and call it a day:
image: nextcloud:17.0.2-apache image: nextcloud:20.0.2-apache
Well, no, because after trying to do that, i got the following error:
Okay, well, i guess that's fair enough - we can't always expect the software to include the necessary files, migrations and scripts to migrate from the oldest versions to the latest. So instead, i would just launch the container of the next major version after the one that i had installed. Initially, it even seemed to work:
However, once i tried accessing the actual web interface, it was proven that it was lies. The migration had simply failed silently and now i was left with an unusable instance of Nextcloud:
Now, the reasonable approach here is to panic and reset back to the previous version, right? Except that you really can't do that in like 90% of the software out there, because very few people ever consider creating backwards migrations for DB and application content. Nextcloud was one such piece of software:
You'll notice something even more sinister in the screenshot above - it didn't complain about the version that had seemingly migrated successfully, but rather the newest version that i had tried to migrate to initially. The version that informed me that it cannot be migrated to, because such a migration would span across multiple major versions. But shouldn't the migration be reset in that case? Apparently not!
So what did i do? Luckily, i knew how bad most software is and to never trust version upgrades, so i initially had created a .zip archive of the server files. After trying to restore backups of the Nextcloud server install from this, it turns out that i could not do that either - the
zip command had ignored files with root permissions, which had been bind mount by the PostgreSQL container, so i ended up without a DB. Thankfully, i also didn't trust that these ZIP backups would work (and didn't have time to test them beforehand), so i had all of my Nextcloud files downloaded locally and ready to upload to a new installation. Of course, i also had incremental tested backups of all of the Nextcloud files that were a few days old, but i wanted to store the latest ones in the new version.
So in the end, it was way easier to just nuke the old install and start anew. Except that it wasn't.
The new Nextcloud version seemed to install without a hitch, however i quickly found out that i could not connect any of my devices to it - neither the Android client, nor the Linux Desktop app allowed me to register. As it turns out, it's a problem with the web app itself:
It seemed to try to use HTTP instead of HTTPS, though the latter was explicitly set in the Nextcloud instance config through the UI. So this one bug left every device hanging while waiting for a successful grant of permissions to connect:
As it turns out, i'd have to manually edit configuration files for the Nextcloud instance. Which obviously doesn't make sense when you're talking about containerized software, because the changes would be overwritten on the next time a new container is created, unless i were to use a bing mount, which i thankfully did in this case:
It's not like i'm the only one using Nextcloud behind a reverse proxy with HTTPS and running it inside of Docker containers, right? And yet, stuff like this happens out of the box for the latest stable version. But it didn't end there. After trying to sync my local files, they appeared in the web UI, however i realized that they were completely empty:
So Nextcloud is a piece of software which is supposed to synchronize files and it fails at doing that. Marvellous. Turns out that i could get it to recognize them after renaming them a couple of times, which is pretty odd. In conclusion, there were way more problems than i'd care to encounter if i had to update between the minor versions of software. And yet, somehow it's one of the very few capable alternatives to something like Dropbox.
Personally, i think it's kind of absurd, that software keeps breaking in such stupid and weird ways. And yet, the very same thing has happened to me with GitLab updates and phpBB forum software, so if big corporations can't do it, what makes anyone think that software updates and SaaS are easy? I get the feeling that most updates should be avoided at all costs whenever you need the assurance that your self-hosted software won't break suddenly. For example, i've installed a version of LibreOffice on my computer a few years ago and haven't updated it since - it still works, just like i'd expect it to. Of course, all of this breaks down because of CVEs for server software, which are sadly an eventuality noone can escape.
There were further problems in the new version of Nextcloud, such as it taking 3-10 seconds for every page of files to load. As it turns out, i had the Talk application enabled, which for some reason is buggy and slows down the whole system even if it's not opened, in this version. The workaround here was to just disable it. That said, the app itself is nice, so it might eventually serve as a simplified alternative to Slack, if you need something like that.