DISCUSSION: Compose > v2 support

[ghost]

Is your feature request related to a problem? Please describe.
Libcompose, the library we currently use for deploying stacks on docker standalone is deprecated and is causing a TONNE of issues. Something needs to be done, as a broken implementation of stack deploy on standalone is not user-friendly nor is it a feasible for support reasons.

Issues that will be solved by this outlined below:

• Explicit IPv6 address in ports compose fails to deploy stack #3533
• Can't deploy a Compose stack via Portainer Agent without Swarm #3382
• Using a git repository as build context fails with "Could not locate dockerfile" #3242
• Network 'priority' not supported #2603
• Cannot set default network subnet when deploying non-swarm stack #2381
• Internal network option "internal=true" not supported in docker-compose.yml #2339
• Update v2 stack gives error Failure Volume "volume" needs to be recreated - driver has changed #2289
• Cannot use external networks in docker-compose.yml to create stack #2041
• Compose stack does not work - caused by mem_swappiness #2039
• Volume defined in a stack deployed by a non admin incorrectly assigned to administrator #2608
• With compose.yml, volumes are created twice with and without stack prefix #1989
• Something in the latest Docker for Win broke compatibility with Portainer's Stack editor #3740
• Stack: "Error response from daemon: sandbox ...a1b2c3... not found" when updating the stack #3768
• I can't connect/ping from a container to an other container by its name even if it is in the same network #4137
• Standalone Hosts: Stack Migrate Fails, x509 error #4631

Describe the solution you'd like
I think there are two obvious paths we can take, but there could also be alternate solutions to this (feel free to comment with suggestions);

1. Replace Libcompose with the docker-compose binary and wait for the docker-compose go library to be released tracked here. The limitation of this approach is the docker-compose binary is only compiled for Linux and Windows.
2. Hide the stack deploy UI for standalone endpoints while we wait for the docker-compose go library to be released tracked here

[Codelica]

Option 2 "Hide the stack deploy UI for standalone endpoints" would definitely require us to freeze at a previous release until things are sorted out. :) At this point Portainer's standalone compose implementation is "usable" but with a variety of quirks and limitations (as mentioned), some of which can be worked around. So personally I like option 1, assuming building things out against binary for now isn't too involving. If that's more work than it's worth, I'd say leave things as they are until the Go lib is available. Just my .02

[deviantony]

@Codelica agree. Actually our idea was to hide the stack deploy UI only for specific plaforms.

The docker-compose binary is only built for Linux, Mac and Windows (see https://github.com/docker/compose/releases). This means that if we want to leverage it and embed it in Portainer, we'd only support stack deployment on these platforms which would mainly impact arm, arm64 and our other platform users. This is why we wanted to hide the UI in that specific case.

Another alternative would be to fallback to libcompose if the platform is not supported by docker-compose.

[mateuszdrab]

@deviantony Considering the other issue we talked about recently when it comes to the stack feature pulling from Git hosted on VSTS - it seems like it might be just better to go with executables and disable certain features on certain platforms. No point making some x64 users sacrifice useful features like this so that someone can run Portainer on the Raspberry Pi - I'd say a Raspberry Pi user is less likely to need stack deployment anyway.

[Codelica]

Not that our use is necessarily typical, but we do deploy under linux across x86_64, arm32v7, and arm64v8 with custom app templates for each arch that include v2 compose recipes (working around limitations we've hit). So personally I'd love to see this approach for now:

"Another alternative would be to fallback to libcompose if the platform is not supported by docker-compose."

IMO the current compose lib isn't useless for ARM -- just a little "special" :) So if it's possible to keep around for ARM (with disclaimer?) until the Docker Go lib is available, that would be great for us.

BTW, the recent issue triage is noticeable. Thanks!

[mateuszdrab]

@Codelica I agree, automatic fallback and a little red disclaimer at the stack deployment page about limited functionality due to library issue sounds like a good solution.

[pedrolamas]

I've also tried compiling this directly on my NanoPi M4V2, as @akutruff pointed out, I had to add the scons package and change the lib path to "aarch64-linux-gnu", after that it compiled perfectly.

To build I used:

docker build --force-rm -t dc_test:latest .

Then following @sbusso comments, I tried running it with:

docker run --rm -v "/tmp:/tmp" dc_test

but that failed with:

[7] Cannot open self /tmp/staticx-ZMRSSr/docker-compose or archive /tmp/staticx-ZMRSSr/docker-compose.pkg

Any ideas?

[akutruff]

@pedrolamas I ended up bailing after trying to fix this issue for hours. I even tried running the build docker-compose binary inside the build container as a test to see if scratch was causing the problem.

I got the same error about tmp. I looked and looked for these mythical tmp files generated by staticx and they were no where to be found in the build container or the final image.

I tried using the latest python image for the builder. Nothing changed. I was going to see if using absolute paths would change anything, but I couldn't devote any more time to this.

[sbusso]

[7] Cannot open self /tmp/staticx-ZMRSSr/docker-compose or archive /tmp/staticx-ZMRSSr/docker-compose.pkg

This issue is due to missing libraries inside the staticx package. After running the compilation with debug mode, I ended up adding all libraries manually. At the end I got another segment fault.

[akutruff]

More reasons to use alpine:

Official image for arm64 is an open issue:
docker/compose#6831

linuxserver.io uses full ubuntu.
https://github.com/linuxserver/docker-docker-compose/blob/master/Dockerfile.aarch64

[akutruff]

@sbusso can you share your latest Dockerfile?

[sbusso]

@akutruff unfortunately the version with debug and libraries died with my RPi while I was trying all compilation options end of the year.

[akutruff]

@sbusso Bummer. So what's the chance of using alpine to unblock this issue?

[deviantony]

@akutruff very low at the moment for the reasons exposed in the comment above: #3750 (comment)

As a first step, we're bringing support for docker-compose for Linux AMD64 / Windows AMD64 first in CE 2.1 and we're still considering adding support for it in Linux ARM64 but that will come later in another release.

Unless someone is able to crack the solution for this ARM64 compilation, it is highly probable that we'll wait for the Go implementation of docker-compose to be ready.

Refs:

• [Docker Compose] Build Docker Compose in Go  docker/roadmap#15
• https://github.com/compose-spec/compose-go

[tcurdt]

The idea was not to switch to alpine as the base image - but to build the static binary on it. That's a big difference. I've built rust binaries on alpine to be able to run them on a scratch image.

Without a proper log of what you actually have tried and what the error was there is no way to say if this could be a similar problem. How about some ldd output to start with?

[sebdanielsson]

Looks like docker-compose in now written in go with feature parity with the Py version. Could this help?
docker/roadmap#15 (comment)

[hugalafutro]

Hi,
pardon my technical ineptitude, but I follow this discussion as I'm very interested in finally being able to ditch using CLI for the management of my stacks in favour of the portainer GUI. I'll admit most of it is going way over my head technically; and my focus is on usability over security; but why can't portainer webui just issue commands to the docker-compose already present on every system I use portainer on ? I mean can't the webui detect if the system has docker-compose? If so, then use it, if not then revert to current behaviour?

Sorry if it's stupid question.

[kernal64]

Apology accepted. ;-) It looks like you have NO unserstanding of containers. Portainer itself "lives" in a container and has no access to the commands on the host. rgds Kai 22. Januar 2021 09:33, "hugalafutro" <[email protected] (mailto:[email protected]?to=%22hugalafutro%22%20<[email protected]>)> schrieb: Hi, pardon my technical ineptitude, but I follow this discussion as I'm very interested in finally being able to ditch using CLI for the management of my stacks in favour of the portainer GUI. I'll admit most of it is going way over my head technically; and my focus is on usability over security; but why can't portainer webui just issue commands to the docker-compose already present on every system I use portainer on ? I mean can't the webui detect if the system has docker-compose? If so, then use it, if not then revert to current behaviour? Sorry if it's stupid question. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub (#3750 (comment)), or unsubscribe (https://github.com/notifications/unsubscribe-auth/AKCIZX4GXTL4IWZZBUHXHRTS3EZ6NANCNFSM4MP2SO4Q).

[hugalafutro]

You're completely right I've first come into contact with docker about month ago and I just like the portability of it how it's all in it's own space and leaves the rest of system clean so I keep tinkering with it by moving all my services to it and naturally came across Portainer.

Anyways I'll leave you fine folks to iron out the technical details under the hood and hopefully a day where v3 stacks will be manageable from ui won't be far off.

[ghost]

Not sure if anyone has noticed, but there is a PR open bringing support for compose v3 docker standalone stacks on linuxAMD64 and WindowsAMD64 with fallback to old behavior on arm arch's.

Even better, I am in the middle of testing it so its ready for our 2.1 release at the end of the month :-)

[deviantony]

Work on this is finally done for Linux AMD64 as well as Windows AMD64 ! Done via #4713 and will be available in CE 2.1.0.

I'll open a separate issue to enhance our support for the different platforms (mainly arm64) so that we can continue our discussion/investigation in there.

[sebdanielsson]

When is the release for CE 2.1?😃

[deviantony]

Codebase is currently frozen and we've started the release testing for version 2.1.0.

It was originally planned for the 28/01/2021 but might be a few days later so early February max.

[sebdanielsson]

Awesome work guys! I’m currently running Portainer in Docker. Will 2.1 be released on Docker Hub as well or which installation method is most up-to-date?

[deviantony]

Usual installation method yes, it will be published on DockerHub under the portainer/portainer-ce repository.

[ghost]

If anyone wants to get their hands on the pre-release image to try it out, you can do so with the following tag portainerci/portainer:2.1

Please note this is a PRE-RELEASE image not intended for production use, so use at your own risk! 👍🏻

[ghost]

Also for everyone watching, there is a known issue when using the build parameter in yml in conjunction with a git repo containing a Dockerfile against agent/edge agent standalone docker windows endpoints. Code is frozen for this release, so it will be mentioned in the release notes and addressed in a future release.
None-the-less, any insight from the community into the cause would be much appreciated!

[basudip]

Really solid work. Thanks all of you for the hard work 😃.

One question, is it compatible with ARM architecture from day 1? Or the development of that branch still WIP?

[deviantony]

@basudip we'll only support Linux AMD64 and Windows AMD64 in the next version for the reasons stated above.

Here's the follow-up item for Linux ARM64 support: #4776

[aptalca]

linuxserver.io uses full ubuntu.
https://github.com/linuxserver/docker-docker-compose/blob/master/Dockerfile.aarch64

Linuxserver.io uses and publishes binaries for both Ubuntu and alpine 😉

[xZero707]

Guys, absolutely briliant work with docker-compose support. I can finally say that it works as it should; A lot of issues are gone. Thank you!