chore: parametrize services Dockerfile path

[rogercoll]

Changes

Define services paths and Dockerfiles using and environment variable so it can be easily overridden. With the added variables, a vendor can easily point to another Dockerfile using the .env.override file:

PAYMENT_SERVICE_DOCKERFILE=./src/paymentservice/Dockerfile.custom

That would help to make changes additive, thus minimizing merge conflicts.
In addition, the demo can also benefit from it and add different Dockerfile for the services and reflect different Otel deployment strategies.

The PR also aligns the emailservice Dockerfile with the other's services strategy by expecting to be built from the root's repository path.

Merge Requirements

For new features contributions please make sure you have completed the following
essential items:

* [ ] CHANGELOG.md updated to document new feature additions
* [ ] Appropriate documentation updates in the docs
* [ ] Appropriate Helm chart updates in the helm-charts

Maintainers will not merge until the above have been completed. If you're unsure
which docs need to be changed ping the
@open-telemetry/demo-approvers.

[julianocosta89]

Hey @rogercoll 👋🏽

This is interesting, and I like where this is going.
One note thought, would you be able to change the env vars to contain the whole path?

That would avoid the concatenation in the compose file and it would help when things do not go as expected.
WDYT?

[rogercoll]

One note thought, would you be able to change the env vars to contain the whole path?

Definitely, it will be even more helpful for vendors that want to completely move a service to a different directory. Something like 8a40cd0 ?

PS I will bring this PR/idea to today's SIG meeting

[julianocosta89]

@rogercoll, with 2 env vars to do the solution you mention we would need to update 2 places:

PAYMENT_SERVICE_DOCKERFILE=./src/paymentservice/Dockerfile.custom

My initial thought was having 1 env var containing the full path, do you see other use cases where having 2 would make more sense?

[rogercoll]

do you see other use cases where having 2 would make more sense?

Just the ability to point the whole service to another directory, for example, let's say we do a copy of the payment service into ./src/payment-custom. Although the repository is not fully prepared for this feature (we would need to use the env inside the services Dockerfiles), it would allow overriding the whole service's path, not only the Dockerfile.

we would need to update 2 places

That would not be mandatory, as only the *_DOCKERFILE environment variable is used in the docker-compose files. In your .env.override file, you will just need to change the *_DOCKERFILE variable. The following solutions would work:

PAYMENT_SERVICE_DOCKERFILE=./src/paymentservice/Dockerfile.custom

or

PAYMENT_SERVICE_DOCKERFILE=${PAYMENT_SERVICE_PATH}/Dockerfile.custom

I don't have a strong opinion on the *_PATH environment variables, if you think it could complicate the usability we could go with a single environment variable pointing to the Dockerfile path for now, and revisited if/when needed. @julianocosta89

[puckpuck]

I would like to use a single variable for each service containing the path and name of the Dockerfile. If someone needs to update this, they only need to update a single spot to reflect either a new folder or a new Dockerfile name.

[julianocosta89]

I would like to use a single variable for each service containing the path and name of the Dockerfile. If someone needs to update this, they only need to update a single spot to reflect either a new folder or a new Dockerfile name.

me too!

[rogercoll]

@julianocosta89 @puckpuck 👍 We can keep it simple for the moment and just use the Dockerfile variable.

Path environment variable removed in d328586

[puckpuck]

Thanks for this.