feat(docker): global compose file

[arnesetzer]

👋 I did some awesome work for the Pelias project and would love for everyone to have a look at it and provide feedback.

---

Here's the reason for this change 🚀

As mentioned in #253 it would be nice to remove at least the docker-compose.yml from each project directory since it is more or less the same in each for each region.
I will use the terms "project", "region" and "local" synonymously. They all describe a thing in the project directory (e.g. portland-metro)

---

Here's what actually got changed 👏

• In the pelia compose exec function (https://github.com/arnesetzer/pelias_docker/blob/33f032c1e5380930ef245e5be0171f0cacfeac74/cmd/docker.sh#L20), a check has been added to see if a region-specific 'docker-compose.yml' file exists. If so, this file will be used. Otherwise, the new 'global' compose file in the root directory will be used. So it is backwards compatible.
  Currently, there is some echoing to easily determine which file is being used. This should be removed before going to production.
• The new 'global' compose file supports custom ports via the .env file. If these are not set, the default ports will be used.
• All .env files have been updated with the variables to change the ports.
• All local docker-compose.yml are removed. The compose file in the root dir will be used. If a local file is present it will append/overwrite the global one.

---

Here's how others can test the changes 👀

1. Checkout the PR
2. Select a project
3. You should see the message "No local file. Using global compose file." when executing a pelias command (e.g. pelias download wof)

[orangejulius]

Nice, we definitely do want this.

I think instead of cd-ing around and keeping track of a path to each project in its .env file, we can do something much simpler and just pass either the local or global file to docker compose as an argument to the -f parameter. In fact it seems that param can be specified multiple times, so we could possibly use that to allow overriding just components necessary.

In general though, I would prefer to see all the project-specific docker-compose.yml files in this repo removed, and a single global one used. The flexibility would be nice though.

in terms of other things, the port specification is also a great feature, but let's keep that out of this PR and do it later. With so much backwards compatibility required in this PR, we want to keep every PR small and focused.

[arnesetzer]

Thanks for the feedback. I just let the local compose files in to keep the backwards compability. But I would love to remove them as well. I will split the PR in two and a small one (for f7723a7).

[arnesetzer]

I'm not that happy with the solution, since it's not very readable. However, it's the best way I could think of to avoid some code duplication.

[orangejulius]

what's the peliasRegion variable used for?

My understanding is as long as we require people to cd projects/someProject, we don't need to consider this relative path anywhere. Am I missing something?

[arnesetzer]

We need this variable to properly mount the directories into the docker container. E.g.

docker/docker-compose.yml

Line 17 in 30d952f

- "./${peliasRegion}/pelias.json:/code/pelias.json"

[orangejulius]

I'm gonna play with this a bit, I feel like there's got to be a way to remove it, right?

I find it really surprising that docker would base the mount directories from where the docker-compose.yml file is located rather than the current working directory where the docker compose command is run from.

Let me know if you've played around with it more.

[orangejulius]

Okay, looks like they do use the path relative to docker-compose.yml, which is annoying, but presumably they have their reasons 😆

I've made a few changes so will likely open my own PR so we can iterate more quickly on this.