Paraphraser
commented
1 year ago First off, if you want to run your system that way, please do so. You don't need to change anything.
However, the x- prefix in the template is not a mistake. I think the most likely explanation for why you're seeing a problem is because your docker-compose is out-of-date.
You can check this by running:
$ docker-compose version
$ docker compose versionWhat you should see is:
$ docker-compose version
Docker Compose version v2.18.1
$ docker compose version
Docker Compose version v2.18.1What I suspect you will see will be something like 1.29.2 or earlier for the first command, and possibly Docker saying that "compose" isn't a command for the second.
Please also run:
$ docker version -f "{{.Server.Version}}"
24.0.2If you see a version string like "20.10.5+dfsg1", the "+dfsg1" bit means your Docker version is pinned and isn't being upgraded on routine apt upgrade.
It might also be useful to confirm Buster vs Bullseye and 32-bit vs 64-bit mode via:
$ grep "PRETTY_NAME" /etc/os-release
$ uname -aEverything I'm writing here assumes Bullseye. I don't think the 32- vs 64-bit matters but it's a long time since I tested any scripts on Buster so, if you're still running Buster, please be cautious.
If I have guessed correctly about either docker-compose being out-of-date (ie not v2.18.1) and/or not having been installed correctly (ie not getting the same answer for both commands), and/or Docker being pinned or otherwise out-of-date then I recommend reading PiBuilder's reinstallation document, and doing what it says.
There's a weird history behind all of this which I don't pretend to understand fully but it goes something like this:
- Way back in the mists of time, both
dockeranddocker-composewere installed viaapt, anddocker-composewas a compiled binary. That combo leads to the "pinned" version ofdockerand neither it nordocker-composeis ever upgraded by routineapt upgrade. - Then came an interim version of
docker-compose(1.29.x) which was a Python script. If you installeddockerusing the official "convenience script" anddocker-composewithpip, thendockerwould be upgraded via routineapt upgrade, anddocker-composecould also be upgraded bypip(not that it changed much). - The situation right now is, if you run the official "convenience script" you get
dockeranddocker-compose-plugin, both of which are upgraded by routineapt upgrade. This is "modern"docker-composewhich is a compiled binary. However, the convenience script only gets you thedocker composecommand. It doesn't also set up thedocker-composecommand, and its absence breaks a lot of scripts and means instructions in documentation don't work as written.
The purpose of the reinstallation document and the scripts it tells you to run is to try to sort out any historical mess and get your system to the point where you have up-to-date docker and docker-compose-plugin, both of which will be kept up-to-date via routine apt upgrade, plus a symlink to make the docker-compose command work.
So, how does all of the above answer your original question? Well, the relevant lines in the syncthing service definition are:
x-ports:
- 8384:8384 # Web UI
- 22000:22000/tcp # TCP file transfers
- 22000:22000/udp # QUIC file transfers
- 21027:21027/udp # Receive local discovery broadcasts
network_mode: hostWhat the x- prefix means is "this entire clause is commented-out". It's exactly the same as doing this:
# ports:
# - 8384:8384 # Web UI
# - 22000:22000/tcp # TCP file transfers
# - 22000:22000/udp # QUIC file transfers
# - 21027:21027/udp # Receive local discovery broadcasts
network_mode: hostUsing x- is an easy way of accomplishing a couple of goals:
-
Make it simple to switch between host mode (the default for syncthing) and non-host mode:
ports: - 8384:8384 # Web UI - 22000:22000/tcp # TCP file transfers - 22000:22000/udp # QUIC file transfers - 21027:21027/udp # Receive local discovery broadcasts x-network_mode: hostJust a subtle rearrangement of
x-prefixes! -
Document the actual ports in use even when a container is in host mode. Once you learn to interpret it, it's actually telling you that, when syncthing is running in host mode, the container will bind to all those right-hand-side ports (ie the "y" in "x:y"). Not every container has a 1:1 mapping where x=y so this can be a handy reference. Otherwise, you often have to ferret about to find this information (usually when you're trying to solve a port conflict).
However, support for x- depends upon "modern" docker-compose. That's why your question makes me suspect your version is out of date.
In turn, the need for either wholesale commenting-out of ports or something like the x- prefix, was all brought about by modern docker-compose insisting that a service definition could have either a ports list or a network_mode: host clause, but not both.
"Pre-modern"
docker-composecheerfully accepted both an active ports list and and active host-mode statement, with the latter taking precedence. I have no idea why the maintainers decided to make it an either/or choice in "modern"docker-compose. They just did.
Last thing. You might find it helpful to also read IOTstack menu maintenance because you might run into that problem as well.
Hope this helps.
PhilBrk8
within the syncthing section of the docer-compose.yml somehow the yml gets written to: "x-port: -...... -...... " instead of just "port: -..... -..... "
When removing the "x-" manually after building and starting the stack again, it works.