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.
I like this idea, I proposed the same thing here: https://github.com/docker/compose/issues/1818#issuecomment-128416833
There are still things to work out though. Should the file that is downloaded be saved locally?
@dnephin The file can be cached, and downloaded again based upon timestamp.
This is a great idea, and feels like a very natural way to deploy.
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
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).
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?
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?
@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.
This feature is quite important and useful, is there any way to make it move forward?
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.
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.
Most helpful comment
@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: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 finallydocker-compose up
from that. Not impossible, but not as easy.