Introduce project-name in docker-compose.yml file (fixes #745)

[estarter]

Added project_name property to the docker-compose.yml file.
Added new schemas with the property: 2.4 and 3.6

project_name property has a lowest prio (expect dir name - which is a default option):

1. the value of -p
2. the value of COMPOSE_PROJECT_NAME from your environment OR .env file
3. (NEW) the value of project_name from docker-compose.yml file
4. the current directory name

Example of docker-compose.yml v.2:

version: "2.4"
project_name: 'myproj'
services:
  elk:
    image: sebp/elk
  ... etc ...

Example of docker-compose.yml v.3:

version: "3.6"
project_name: 'myproj'
services:
  elk:
    image: sebp/elk
  ... etc ...

[estarter]

Should project_name property be renamed to x-project-name so that there's no need in introducing new schema versions?

[shin-]

Hi @estarter !

First off, thank you for contributing this PR.
As you probably read in the #745 thread, there's a bit of a contention with making the project name settable directly inside the Compose file. Unfortunately, it's not the direction we want to take for this feature. I would prefer if we worked off the base set by #5378 and find an acceptable solution from there.

Thank you for your understanding!

[estarter]

Hi @shin- !

Thanks for the explanation. It's not an easy case for you guys to take deal with!
As you guessed in the #745 thread it's not my favoured solution, but it doesn't have to be, I just hope it can cover my use-case.
I appreciate a lot that you are making this issue fixed. Thank you! 👏

It would be great if you could clarify maintainer's position on the question ( one , two ). Let me formulate it as brief as possible:

ls PR_5378
# .env
# docker-compose.yml
# docker-compose2.yml
cat .env
# COMPOSE_X_PROJECT_NAME=1

COMPOSE_X_PROJECT_NAME=1 docker-compose -f PR_5378/docker-compose.yml -f PR_5378/docker-compose2.yml down
# => project name: myproj --- GOOD, perfect!
docker-compose -f PR_5378/docker-compose.yml -f PR_5378/docker-compose2.yml down
# => project name: pr5378 --- FAIL, How I can make it work?
cd PR_5378 && docker-compose -f docker-compose.yml -f docker-compose2.yml down
# => project name: myproj --- GOOD, perfect!

The problem is that the solution requires COMPOSE_X_PROJECT_NAME env variable. Possible solutions:

1. persist the env variable in the project's folder. I tried .env file but it doesn't work when docker-compose is called from another location (see commands example , compose files)
2. define COMPOSE_X_PROJECT_NAME globally (.profile or equivalent). That would work but it can't be specified in the project, i.e. it's not a solution for our use-case defined by the project, that can be checked in
3. is there another option?

In #745 (comment) you mentioned docker-compose.env - i don't know if it works differently from .env

Hope you'll find time for answer. Thanks!

[shin-]

If we went ahead with adding docker-compose.env, it would work identically to the current .env file. But I'm sensible to your use-case, although I'm not yet sure what a good answer would be.
If I may ask - why is having .env (or docker-compose.env) in the parent folder not an option for you? More broadly, can you give me some insight into your project's folder architecture?

[estarter]

More broadly, can you give me some insight into your project's folder architecture?

Here's what i have for our main project. It's a maven project creating a zip file with our deliverables - it's ~2GB and corresponds to dozen of different docker images (servers, j2ee, flyway, standalone, ...).
We are using following structure + helper scripts (- for files, + for folders):

- docker-compose1.yml
- docker-compose2.yml
- docker-compose3.yml
+ docker
-- dbash
-- dbuild
-- ...
-+ images
--+ container1
---- Dockerfile
--+ container2
--+ container3
--+ containerN

docker-composeX.xml file defines a logical slice of the system (could be dependent on docker-composeY.xml).

in the docker folder there are docker helper scripts, you can guess the purpose from the name: dbash / dbuild / dcleanup / dclient / ddeploy / dlog / down / dset / dstop / dup
I think original reason for these scripts was to persist the project name 😄

With time these scripts become more advance, now it allows a developer to define the scope and works with it (e.g. I work with docker-compose1.yml and docker-compose3.yml ; docker-compose2.yml containers are not interested for me in my current work).

Today we mostly using this scripts instead of docker / docker-compose commands for the common actions. Scripts are printing out the docker / docker-compose command for the convenience.
It's typical to have scripts folder in the PATH so that they can be called from any place.

why is having .env (or docker-compose.env) in the parent folder not an option for you?

That's a good option for me. The issue is that the restriction to call docker-compose file from specific location (hidden conventions, which would result in frustration).
Especially with hidden .env file, but visible docker-compose.env would not help much - if this file is not on the command line, than user runs the same command from two locations (parent folder / child folder) and have different result.

BTW for docker-compose -f docker-compose.yml, why do you assume that execution's location is the project's folder at all? 🙃

P.S. Sorry for the long answer, hope you find anything useful here.

[estarter]

Hi @shin- !

I was thinking hard about this issue and found another use-case from our real env that can be interesting for you - for the #745 itself and usage of x-project-name

We have some heavy proprietary server (let's call it srv). It's not on our control, we managed to docker-ize it, but it's still heavy (long start up time, long build time, recreation of container not always straight-ahead... we are constantly improving the situation, but things are still far perfect).
One important thing to mention here is that we should support several versions of this server.

1. This server comes in docker-compose-srv.yml (server + db + ...).
2. But you would not be able to docker-compose docker-compose-srv.yml alone - it must be accompanied by version file docker-compose-srv_vX.yml. Version file defines build-args with version that are passed to the Dockerfile.
3. Dockerfile itself uses passed version number to define the image.

Here's the structure:

docker-compose-srv.yml
# services:
#     srv:
#         build:
#             context: docker/images/srv
#     db_srv:
#         build:
#             context: docker/images/db_srv
# ....
docker-compose-srv_v1.yml
# services:
#     db_srv:
#         build:
#             args:
#                 SRV_VERSION: 1
#     srv:
#         build:
#             args:
#                 SRV_VERSION: 1
# ....
docker-compose-srv_v2.yml
# ....
docker-compose-srv_v3.yml
# ....
+ docker
-+ images
--+ srv
---- Dockerfile
     # ARG SRV_VERSION
     # FROM internal.docker.repo/srv:${SRV_VERSION}
     # ...
--+ db_srv
---- Dockerfile
     # ARG SRV_VERSION
     # FROM internal.docker.repo/db_srv:${SRV_VERSION}
     # ...

To this structure it's kind of natural to have x-project-name in docker-compose-srv_vX.yml files. That allows us to add a 'second dimension' to the containers and manage multiple versions of srv in multiple containers.
* same 'second dimension' can be done with -p option but in practice it's too difficult to use in our project.

So I'm looking forward for the new docker-compose with #5378 merged!