New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
docker-compose bundle warnings #3680
Comments
Bundles are still experimental right now. They are intended to represent 'portable' deployable services. I don't know, but my guess is that those things won't be supported as they are things that tend to tie containers to either a specific host or a specific number of instances or a specific topology. 'container_name' - Only really works for one instance |
@johnharris85 thanks! |
Bummed that volumes is missing. Makes it not useable for a good 1/3 of our current apps. Would also like to see it support the new global swarm mode. (Think deploying something like cadvisor or other monitoring stacks.) |
It seems like pretty much everything is missing right now (especially security configurations!), at least on our docker-compose.yml :
So I'm really not sure how one is supposed to use docker swarm in practice except for launching a single service by hand. |
It looks like volumes are supported in But how does it work exactly?
These questions need to be answered before we expect |
Here's some interesting information: https://forums.docker.com/t/docker-1-12-swarm-storage-options-with-dab-distributed-application-bundles-on-gce/16204/3 |
Also related to moby/moby#24089 |
Has anyone seen a Roadmap showing from which future version will the bundle feature actually become usable fully? docker-compose 1.9.0-rc4 doesn't seem to support any new options and therefore it seems impossible right now to migrate to swarm with 1.13 if you care about security or any other options. |
FYI I make a similar request for |
So, swarm-mode strips functionality that was present using docker-compose and, while swarm-mode supports compose files, it ignores most of what makes one use compose files in the first place. I love Docker, I really do, but swarm-mode is a complete regression. |
I don't think we'll do any more work on the bundles / DAB format at this point.
A lot of the options that were removed in v3 aren't applicable to distributed environments (clusters). Other things are a work in progress (happening here: https://github.com/docker/swarmkit) |
I respectfully disagree 100%. The missing piece is that things aren’t fully shared across the swarm. Docker Hub credentials, cached images, etc. Further, how are things like env files and builds not applicable to a distributed environment? But, in the end, swarm-mode is dead anyway, so it really doesn’t matter much, does it? |
Not sure what that specific piece has to do with Compose. It's also a one-time setup thing.
You mean pulled images? Ideally I agree this would be handled. Pretty sure it's covered under the "work in progress" clause.
??? https://docs.docker.com/compose/compose-file/#env_file
If node A goes down and node F goes up to replace it and needs to start a task for service X, it's unlikely it'll have the files to build the underlying image. It makes sense that services would instead rely on pullable images.
k |
You closed this as development has been moved to swarmkit, ergo I brought it up. Anyway, credentials are not necessarily a one-time thing and, even then, that has nothing to do with all swarm members not having access to the credentials. Basically, it shouldn't be required to pass
Env file parsing and var substitution/interpolation are not handled when using swarm...which IS a function of compose.
You store the built image and make it available to all nodes. How does that not make sense. The simple fact is that, if I'm using swarm-mode, I MUST have some external registry, somewhere. It adds layers of complexity and dependencies that shouldn't be needed.
And yes, Kubernetes won this war, unfortunately. Swarm was much simpler for smaller deployments, but it's mired in slow progress and was probably rolled out before it should have been. Progress is slow as the project has gotten larger. Feature velocity has increased, but the features seem to be missing the mark for a pretty large chunk of the user base. Lastly, the fact that full compose functionality is not supported in swarm-mode, combined with the lack of DAB development, and the fact that over a year has gone by and there's still no good way to deploy stacks in an automated fashion severely limits the usefulness of this in a production environment. I don't have the answers, and not even sure if anyone cares, but look at the Slack channel and Github you'll see just how disappointed many users are with the current state. |
I'm trying out the
docker-compose bundle
command but am getting some bunch of WARNINGS below:WARNING: Unsupported key 'container_name' in services.master - ignoring
WARNING: Unsupported key 'volumes_from' in services.config - ignoring
WARNING: Unsupported key 'volumes' in services.config - ignoring
WARNING: Unsupported key 'container_name' in services.config - ignoring
WARNING: Unsupported key 'links' in services.keycloak - ignoring
Now, when I deploy the generated bundle, the services / containers doesn't work and I feel the WARNINGS are kind of errors that my docker-compose file isn't compatible with the new bundle file requirements. I can fix the warnings on container_name, but not sure how I would fix the warnings on volume_from, volumes and links in my compose file.
How do I fix the warning message and Is there any sort of reference for the new
docker-compose bundle
command ?Here is my docker-compose file:
The text was updated successfully, but these errors were encountered: