Instead of a ruby script wrapped around docker compose, wouldn't a docker compose environment file work the same? docs.docker.com/compose/environmen...
I can't remember specifically why, but I thought there was a reason the environment variables alone weren't enough for our environment. We do have separate environment files, and our developers can have a "local.yml" file that doesn't get checked in with local-specific configuration; that "local.yml" gets combined with the others to create the new compose file.
But, I think you're right, leveraging environment variables would probably accomplish the same goal. The separate script does provide the nice feedback of just saying "./application up" (for the name of the script) and the application starts, and makes it easy for non-members of the development team (who are often not familiar with Docker) to know what's going on.
Instead of a ruby script wrapped around docker compose, wouldn't a docker compose environment file work the same? docs.docker.com/compose/environmen...
I can't remember specifically why, but I thought there was a reason the environment variables alone weren't enough for our environment. We do have separate environment files, and our developers can have a "local.yml" file that doesn't get checked in with local-specific configuration; that "local.yml" gets combined with the others to create the new compose file.
But, I think you're right, leveraging environment variables would probably accomplish the same goal. The separate script does provide the nice feedback of just saying "./application up" (for the name of the script) and the application starts, and makes it easy for non-members of the development team (who are often not familiar with Docker) to know what's going on.
Docker compose also provides a way to extend a base compose file: docs.docker.com/compose/extends/