Add an argument to specify docker-compose using URL

[arun-gupta]

Currently docker-compose only takes docker-compose.yml that has to be on the local file system. Just like docker build, it'll be good to provide a context for docker-compose up -d. This will allow to run an application from a github project.

[dnephin]

I like this idea, I proposed the same thing here: #1818 (comment)

There are still things to work out though. Should the file that is downloaded be saved locally?

[arun-gupta]

@dnephin The file can be cached, and downloaded again based upon timestamp.

[astewart-twist]

This is a great idea, and feels like a very natural way to deploy.

[zysimplelife]

I would like to say I am facing same problem. If docker-compose support external URL I can release internal tools by only one command rather than a complex config

[astewart-twist]

I think a nice model for github url based docker-compose deployments could that used by next flow (http://www.nextflow.io/blog/2014/share-nextflow-pipelines-with-github.html).

[summergirl21]

It seems like this could be very useful for deploying docker-compose apps. I'm interested in implementing this. Adding an option for docker-compose up --url <url>, that would cache the yml file at the provided url and run the application. Would this be useful? Are there any specific design concerns related to this?

[summergirl21]

After looking at implementation of yml parsing, it seems like this would be better as an option on docker-compose itself. docker-compose --url <url> [COMMAND]. Would this make sense and be a reasonable solution?

[pwagland]

@shin- This seems to have gotten stuck on the PR, which was closed because of some vaguely specified concerns about cross file loading, and possible unknown side effects and related security concerns.

Is there any way that this could move forward? For example, by specifying that files that are loaded by --url cannot reference other files? And cannot use a local .env file without it being explicitly specified. Having functionality like this would be incredibly useful for us internally, since then we could just tell our internal users to:

docker-compose --url https://minio.internal.lan/release/software/version/docker-compose.yml

And they could start a test instance of any version of the software. As it is now, they need to create a new directory, download the docker-compose.yml to it, cd to that directory, and finally docker-compose up from that. Not impossible, but not as easy.

[stormeyes]

This feature is quite important and useful, is there any way to make it move forward?

[shin-]

I don't think this will make it into Compose for the reasons I outlined in #5441, but you should take a look at app packages which should answer most of the use cases mentioned in this thread.

[docktermj]

This would be very useful. I'm trying to make demonstrations using docker-compose for folks that don't have the savvy to do git clone to clone a repository to get the docker-compose.yaml file.

[psychemedia]

I thin this would be really useful: one advantage of docker run is that you don't need to share any files, just the run command.

docker app doesn't seem to have received any attention in recent months, and from the README looks like it requires its own laboured install.

My use case is trying to share teaching environments to students via containers. Every download, every extra step causes a chance of failing to engage that student.

(Given docker's recent re-emphasis on "the developer", for "student" read "not very confident newly qualified developer who has never used docker before".)

[GD-HCK]

I tried to work out a way to achieve this today and then soon realised it was on a roadmap but not yet finalised.

Would be very useful to pull info from github rather than cloning a repository as many have said.

Cheers.