Docker compose V2 upgrade problems on Synology NAS

[clukas1967]

Sharing my experience for all the other Synology NAS users of PWD since you're gonna hit this too.

TL;DR

• In PWD v4.2.1 Jason migrated the docker compose requirement from V1 to V2. PWD upgrades beyond this point fail without V2.
• Due to (1) Synology's custom docker packaging; and (2) lack of support for docker compose there is no simple way to update this component under DSM
• While there are several procedures online you can google that claim to do this, not one of them worked for me
• I had to hack together my own procedure which I am sharing here.
• Also - beware that going from 4.1.x or previous to 4.5.x or later involves some pretty substantial script and DB work and results in many many apparent (but spurious) CLI error messages when firing up post-install. And the Grafana dash looks horribly busted. Just hang on and be patient as these will all resolve themselves within about 10 minutes.

Discussion

I think the thing I love most about my Synology is that the Unix distro and package system it runs are just different enough from any mass Linux distro or package managers to completely break most bespoke app stacks (e.g. Powerwall Dashboard) and I get to constantly test how good my raw Unix foundational skills are by solving the puzzle of each install or upgrade that breaks for some totally obscure and ultimately easily correctable reason that is platform-specific to Synology. So far I am undefeated but it's required a lot of alcohol to get there!

Case in point ==> what should have been a straightforward periodic upgrade of PWD. I have been running 4.1.1 for a while (since I wrote up my problems attempting to restore PWD after a Synology volume migration blew up the whole install in issue #529. I noticed several of the panels have broken, which usually indicates it's time to upgrade PWD due to some mismatch with the never-ending Tesla firmware updates. So time for PWD 4.5.5.

The problem is the mandatory pre-requisite for the 4.5.5 upgrade which is getting docker compose from V1 to V2. Starting with v4.2.1, running the upgrade.sh script will fail without this being done first.

Upgrading this component is not straightforward because Synology (1) has its own docker implementation that is nonstandard; and (2) does not normally support docker compose anyway.

If you're reading this and have PWD working on your Synology that means you have already solved the problem of getting docker compose V1 onto your box. In my case, it ended up in /var/packages/Docker/target/usr/bin.

There are a number of online writeups and Youtube videos purporting to show how to do the docker compose update on Synology. None of them worked for me, I had to stich together ideas/commands from several different sources. Two of the better ones that are at least useful for context are:

• How to Update Docker Compose on a Synology NAS - WunderTech
• Trying to Install Docker Compose on Synology : r/docker

The "CLI plugin" route totally bombed out for me. AFAICT, Synology's docker does not scan for or support a $HOME/.docker directory. And even after I managed to successfully curl down the right compose V2 binary (after several failed attempts) I couldn't get PWD upgrade script to find it even when I put it straight over top of the compose V1 binary.

My final solution was simply to modify the global PATH variable in /etc/profile to include the docker compose directory (/var/packages/Docker/target/usr/bin).

One final note. Beware that going from 4.1.x or previous to 4.5.x or later should be treated as a major version upgrade. I highly recommend doing a full PWD backup before starting the upgrade so you've got a way out of the jungle.

This is due to very substantial internal changes by Jason to address Tesla API issues, docker compatibility, and improve overall internal performance, the upgrade involves some pretty substantial script and DB work. This in turn (at least on my box) resulted in many many many CLI error messages when firing up the containers post-install. And the Grafana dash looks horribly busted. This went on so long that I Ctrl-C aborted the upgrade, did a PWD shutdown, and went back through all the error messages looking for some mistake by me. I re-verified Powerwall IP connectivity and password, spent time scrolling through all the discussions here about PW firmware version conflicts, etc. When I couldn't find any (more) obvious errors on my part I just crossed my fingers and ran the upgrade script again.

Turns out I needn't have cancelled. These errors are all normal at least in my case. Just hang on and be patient as these will all resolve themselves within about 10 minutes. Eventually the PWD Grafana will clear up and all will be right in the universe.

Procedure

So the docker compose V2 procedure that ultimately worked in my case was to do an in-place replacement of the V1 binary and update the global PATH with that location to find it.

Before the CLI commands, some notes:

• All of the following should be done as your normal login user, do NOT sudo this or you'll have to go fix file ownership.
• Note I have hardwired the docker compose version at 2.30.3. There are scripts available online that will automatically grab the version # for you but I was in debug-by-simplify mode at this point
• I have also hardwired the OS and platform in the curl command._ (e.g. "-linux" and "-x86_64" in curl command below). These are automatable but I couldn't get the uname inline calls to work with the curl syntax. Think it was capitalization issue between how DSM returns uname results and what the online github binary repo wants. I gave up being elegant and just went for functional. HOWEVER - if your Synology box has a different CPU platform then the x86_64 may break in your case and need to be adjusted.

cd /var/packages/Docker/target/usr/bin
mv docker-compose docker-compose-v1-deprecated
curl -SL https://github.com/docker/compose/releases/download/v2.30.3/docker-compose-linux-x86_64 -o docker-compose
chmod 755 docker-compose

Edit /etc/profile to make sure that /var/packages/Docker/target/usr/bin is in the PATH variable.

That's it. If everything worked correctly, then both of these commands should yield the same output and should work from any directory since the binary is now in the search path. (Note one command below is hyphenated and one is not - you're testing two different calling paths.)

You can now proceed to the normal PWD upgrade procedure.

[jasonacox]

Excellent write-up @clukas1967 - thank you!