Allow selection of BE through env var

[minottic]

I started to have a look at this #107 and I think the PR here could work well.

It is split into commits to ease the review, I will open dedicated PRs if this looks ok.

The idea is to enable only one backend at a time, which can be configured through an ENV var. Then the other containers will connect to it without noticing the change (also the code does not require much change).

This relies on an include rule which depends on the ENV provided and on the fact that both be_next and be expose a container named backend, which the others connect to. This might also simplify in the future the connection to the archivemock

I still have to update the README (both the global and the backend one) and the CI

The drawback of this is that it does not support running both BEs at the same time, but this can be circumvented (I think) in a later PR by making the traefik port custom and setting the docker compose project-name. In this way, one can run:

docker-compose up -d 

which will run the services with the old BE

and then run, e.g.

export BE_VERSION=backendnext
export TRAEFIK_PORT=81
docker-compose -p $BE_VERSION up -d 

which will run the services with the new BE and expose them on port 81, ultimately creating 2 envs with all the services, one relying on the new BE and on port 81, another relying on the old BE and on port 80.

[fpotier]

Just wondering how does it compare to the solution with profiles? I liked the idea of using them but I'm unsure they offer the same features

[consolethinks]

Is there a need for both BE's to run at the same time?

[fpotier]

I don't think so

[minottic]

I think the differences are:

1. we don't need to duplicate all services for the 2 bes
2. we don't need to tell the user what subdomain to use in each case
3. we avoid the --profile * problem which would spin un both bes at the same time, making it confusing

I don't think we need both bes at the same time, but rather the 2 envs potentially, which could be covered by my example above

I think we will use profiles in the future, probably to bundle envs together, e.g. the one with the zip-service, the one without, but I think here we are in a slightly different use cases as we want to have different configurations (profiles) basing them on different BEs, so choosing the profile and the be it uses should be set by two different flags.

So, in general, I reckon useful to be able to select the BE, only allow one, and call the service backend, no matter the flavour (so that other services don't really care what flavour it is). Schematically:

1. I think we should call both new BE and old BE service backend
2. we can either make the user decide which through profile (if it works) or through the env. (the other advantage of the env var is that it has defaults, so in most cases the users will have to do nothing.

[minottic]

it will be closed by relative atomic PRs

[minottic]

closed by related PRs