Source workflows are usually different from company-to-company, but generally I recommend single repo per service and multiple-branch approach, so you can easily merge features to the master
(eg: prod) branch from your feature
branches which might be dedicated per environment.
Regarding static configuration I recommend to create a generic, non-environment specific container images that picks up all environment specific configuration from environment variables at startup and runtime.
On the port mapping, within the container you should always use the same ports (eg: build your image build with 82
and 83
), and only change those when you expose
it to the host during the composition.
When you build your docker images, you can use labels
to set which one is the dev
, prod
revision of those images, so you can target those easier, with imagename:label
With this you can specify multiple docker compositions per environment, by creating the following files:
docker-compose.dev
.yml:
version: '3'
services:
web:
image: "webapp:dev"
ports:
- "8082:82"
- "8083:83"
environment:
- DEBUG=true
- ENVIRONMENT_NAME=dev
docker-compose.prod
.yml:
version: '3'
services:
web:
image: "webapp:prod"
ports:
- "8182:82"
- "8183:83"
environment:
- DEBUG=false
- ENVIRONMENT_NAME=prod
With this configuration you can create your service compositions based on the same or similar images by running docker-compose
:
# To start a DEV service composition
docker-compose up -f ./docker-compose.dev.yml
# To start a DEV service composition
docker-compose up -f ./docker-compose.prod.yml
See more info about these: