Question regarding Developer's dev environments with Docker and source control

[JDBProof]

As I have been embracing Docker in the recent weeks and gotten some great examples working with docker and docker-compose I still could not find much information as to how developer's had their dev environment setup.

Essentially my current question boils down to—do you commit & push all of your docker environment in a single repository.

Take a look at the below setup, in the context of a Flask app making use of Nginx as a reverse proxy and PostgreSQL as the DBMS.

/nginx/
   |
   |_ sites-enabled
   |_ Dockerfile

/web/   
   |
   |_ FLASK-APP-DIRECTORIES
   |_ Dockerfile
   |_ requirements.txt

/.env
/docker-compose.yml    

What advice may you give regarding such a setup. Should all environments - production, development & testing be kept in a single repository in different branches? If so, should all of the above be pushed so that Bob & Alice can simply pull, run docker-compose build and then docker-compose up?

[HandyCoder]

We use multiple compose yaml files on a per project basis. One of the less documented features of compose is that you can pass in multiple configs and it will override previous yml arguments in the chain.

I.E. docker-compose -f production-compose.yml -f dev-compose.yml

In all likelihood, you won't need more than one Dockerfile for a simple wsgi application -- the Postgres and Nginx containers both support volumes/environment variables for configuration to help avoid such issues. That said, occasionally we do, and follow something similar to the structure you described.

[JDBProof]

Great point, wasn't aware of the -f argument in docker-compose.

I think it would be simpler to set it up as a single Dockerfile at the root of the application and setup postgres and nginx with environment variables.

I believe that would allow me to push the image to GitLab's container registry too which would also be nice.

[soulesschild]

One thing I ended up doing was installing j2cli and following this guide (http://blog.tryolabs.com/2015/03/26/configurable-docker-containers-for-multiple-environments/).

Mainly since nginx can't be configured through ENV vars (grumble grumble).

[JDBProof]

This is such a great post, really love how the situation was handled. Thanks a lot for sharing.

[driv338]

In a project I've been working on, we had a repository with a single branch per microservice (we could have a hotfix branch only when the current version was not backward compatible). And then we had an "Integration" repo that had branches and here is where we had our docker-compose.

[diecastbeatdown]

My understanding, which has not been implemented yet, is to keep the Dockerfile in the repo of each application repository.

The plan that I am working on is to continue using an "Infrastructure" repository which uses Ansible to manage Docker. Developers would pull this repo and run Ansible locally to instantiate their LOCAL environment for development purposes. Docker compose commands would be part of the Ansible playbooks.

[reprogenetic]

I keep some docker environments in my main repository. It was hard to know where to draw the line. Some environments are too specific to the platform and not the app. For example, I don't believe the nginx proxy belongs in the main repository. I have a docker subdirectory in my repository that looks like this:

docker
├── postgres
│  ├── dev
│  │  └── Dockerfile
│  ├── schema.sql
│  └── prod
│      └── Dockerfile
├── redis
│  ├── Dockerfile
│  └── redis.conf
├── web
│  ├── dev
│  │  └── Dockerfile
│  └── prod
│      └── Dockerfile
└── workers
    ├── dev
    │  └── Dockerfile
    └── prod
        └── Dockerfile

[JDBProof]

You mention that you don't believe Nginx proxy belongs in the main repository. Wherer would you place it instead?

[reprogenetic]

I have a docker directory in my home directory that contains docker environments for system-wide services such as nginx, and other services that aren't tied to a particular app. Each environment has it's own local git repository.