Open jonpugh opened 9 years ago
I'd suggest just using the docker-compose.yml
file if it exists.
We'd still need the option of setting it in the .terra.yml
file in case you want to use a different file name. And setting it to null ("~") could make terra ignore a project docker-compose.yml
and fall back its own.
First use case was to add a container linked to the app container, I've successfully added code to do this:
docker-compose:
app_services:
redis:
image: redis
Because we need to always link these addon services to the app container, I called the property app_services
. These are added directly to the docker-compose.yml
file, and the service is linked to the app container automatically.
There's still more work to do to allow apps to totally override their docker setup. I welcome others to help on this, as it's not a priority for me at this point.
I was reminded recently that docker doesn't require microservices. One might as well run everything in one container. Which might be a bit of an advantage if one's using containers designed to be as close to an existing production environment as possible.
Maybe the concept of environment templates is something that'll be needed at some point?
Absolutely. I'd like the EnvironmentFactory to be completely swappable actually, so users wouldn't even have to use docker.
Just needs work to get there.
The flip side is, that I'd like for the default to be scalable. Once you are locked into a single container, it's hard to get out.
I've gotten this working for attaching services to the app container automatically.
It is not able to fully override docker-compose yet.
See https://github.com/terra-ops/terra-app/blob/master/docs/.terra.yml#L29 for an example .terra.yml
The .terra.yml file could have something like this
or
which would automatically merge with the generated compose.yml file.
Feedback welcome.