Is it possible to specify the stack name in a file (rancher-compose.yml) or as a label in docker-compose.yml? When working with another user I noticed their root folder had a different name which presents a different stack name by default. I know I can just have people add -p to rancher-compose. But it would be nice to just stick it somewhere by default.
the rancher-compose -p option will set the stack name
Sure, I am ware of -p. But I’d love to be able to specify stack name via label or other option in rancher-compose.yml. If not possible now, then consider a feature request so I don’t have to specify -p.
Not only -p option but env COMPOSE_PROJECT_NAME too.
I have a different use case for this request. I have our architecture spanned over several projects using the same compose file. While this works fine, I do have to be careful to specify the stack when running compose commands otherwise it creates some stacks that I only want in one project. I know the docker-compose file needs to remain native to docker but the rancher-compose could allow for you to specify a project for a stack. Default could be to deploy in any project specified if the projects line didn’t exist. If the projects line exists it would only deploy if the project specified on the command line matched.
I was thinking about that and chose to have git repository with submodules in it referencing stacks repos.
That way I have single source of truth in repository managing the project/environment while simple way to upgrade and commit latest definitions of stacks.
Directory layout looks like this:
# [root repo]
production:
app: [stack-x@v0.1.0]
monitoring: [service-monitoring@v0.5.6]
storage: [service-storage@v0.3.0]
Note: I was very lucky beginning on a greenfield so I was able to utilize features like external_links and services etc. So this might not work well with apps that were not designed for Rancher from start.
There is this issue open in Github, which would let you use a stack name label and have that pick the stack.
I believe that @mishak’s use case would be different request.
Ah, I didn’t find that issue in searching. That would indeed help my case. Even if I have to explicitly set the label per service would be fine. Following that issue, thanks @denise!