Docker Compose v2

[chriscroome]

Docker Compose v2 is available and compose-switch can be used via alternatives on Debian based distros to convert docker-compose commands to docker compose commands, I realise that the Mailcow update.sh script checks the version to use via this URL and I don't think this is an urgent or critical issue but I thought it probably deserved a feature request opening as some work might be needed in the future to update the way Mailcow installs and updates Docker Compose.

[MAGICCC]

Indeed its released and there's still an issue on compose side with IPv6: docker/compose#8721
Also I will link some closed issues here too: #4285 #4280

[nightah]

docker/compose#8721 can be worked around but surrounding ipv6 literals with square brackets and double quotes, which is common for Go applications.

The key issue which prevented IPv6 routing from working was docker/compose#8851 which has been resolved and merged in a newer version.

[HorayNarea]

Now that there are no (known 😅) bugs preventing the migration to v2… is there a plan to do this, maybe even a rough estimate when this will happen?

[StarkZarn]

It doesn't look like there are any issues preventing this migration. I'll echo what the above poster asked, is there a plan for this? It would increase support for arm-based setups.

[andryyy]

Am I missing something? Supporting v2 does help support ARM? ☺️

[StarkZarn]

Am I missing something? Supporting v2 does help support ARM? ☺️

Since compose v2 is in GO, there's native arm support. I know there was arm support from the pip package version of docker-compose v1, but it wasn't officially supported by docker, hence not having an arm release in the official packages.

It's just all-around better in my experience so far.

[spantaleev]

#4285 is still a problem, for which I've found some workaround.

I don't use IPv6, so I'm not hitting any other issues besides #4285 with Compose v2 + compose-switch so far.

---

Another minor issue (annoyance) with doing docker-compose up with Compose v2 is what I've fixed in #4457

[aminvakil]

How about setting both HTTP_BIND and HTTPS_BIND by default to 0.0.0.0?

[MAGICCC]

Something like that then

- "${HTTPS_BIND:-:}:${HTTPS_PORT:-443}:${HTTPS_PORT:-443}"
- "${HTTP_BIND:-:}:${HTTP_PORT:-80}:${HTTP_PORT:-80}"
+ "${HTTPS_BIND:-0.0.0.0}:${HTTPS_PORT:-443}:${HTTPS_PORT:-443}"
+ "${HTTP_BIND:-0.0.0.0}:${HTTP_PORT:-80}:${HTTP_PORT:-80}"

Would need to check if something will break obv.

[aminvakil]

Something like that then

- "${HTTPS_BIND:-:}:${HTTPS_PORT:-443}:${HTTPS_PORT:-443}"
- "${HTTP_BIND:-:}:${HTTP_PORT:-80}:${HTTP_PORT:-80}"
+ "${HTTPS_BIND:-0.0.0.0}:${HTTPS_PORT:-443}:${HTTPS_PORT:-443}"
+ "${HTTP_BIND:-0.0.0.0}:${HTTP_PORT:-80}:${HTTP_PORT:-80}"

Would need to check if something will break obv.

It didn't break for me and worked just fine.

[aminvakil]

I'm not sure about these though:

mailcow-dockerized/update.sh

Lines 701 to 703 in 880a68d

	# Checking old, wrong bindings
	sed -i --follow-symlinks 's/HTTP_BIND=0.0.0.0/HTTP_BIND=/g' mailcow.conf
	sed -i --follow-symlinks 's/HTTPS_BIND=0.0.0.0/HTTPS_BIND=/g' mailcow.conf

which has been added in
f3f6fb8 and I cannot realize what has been broken.

[aminvakil]

Ah, I think something will break if 0.0.0.0 is used for IPv6... I'm not sure though.

[aminvakil]

Seems like there is a problem:

mailcowdockerized-nginx-mailcow-1       "/docker-entrypoint.…"   nginx-mailcow       running             0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp

while

mailcowdockerized-postfix-mailcow-1     "/docker-entrypoint.…"   postfix-mailcow     running             0.0.0.0:25->25/tcp, 0.0.0.0:465->465/tcp, 0.0.0.0:587->587/tcp, :::25->25/tcp, :::465->465/tcp, :::587->587/tcp

(note the missing :::80>80/tcp where postfix has :::25>25/tcp)
but I've tested and it works (I can curl its IPv6, so 🤷).

[Cerberus-ik]

Is there any update on v2 support? Considering v2.5.0 is bundled in the current docker ce/desktop install. Having to install v1 in parallel is a bit awkward.

[andryyy]

I hope nobody saw you doing this. Must have been really awkward. :)

[aminvakil]

@Cerberus-ik I'm using docker-compose v2 and has no one problem with it expect IPv6 binding which has been fixed using this PR (#4531) as well.

I have tested and verified what I've done in the PR, but I don't know how test it using helper scripts as mentioned by @andryyy has said in the PR.

[Cerberus-ik]

@Cerberus-ik I'm using docker-compose v2 and has no one problem with it expect IPv6 binding which has been fixed using this PR (#4531) as well.

I have tested and verified what I've done in the PR, but I don't know how test it using helper scripts as mentioned by @andryyy has said in the PR.

So I either have to make the same changes as you or wait for it to get merged into the main branch?

[Cerberus-ik]

I hope nobody saw you doing this. Must have been really awkward. :)

Having to install deprecated eol "legacy" software for one application is awkward.

[hugalafutro]

Having to install deprecated eol "legacy" software for one application is awkward.

I concur, out of my 10+ physical/virtual machines, the one running mailcow is the only one where I have to maintain 2 versions of docker-compose (even if it's well documented and easy with compose-switch).

[Cerberus-ik]

I think this is especially a high priority problem because v1 will only get 4 more months of critical bug fixes and severe security updates. So every sane sysadmin will remove v1 before the end of the year.