Building fully automated local development increases the feedback loop because finding and fixing issues earlier in development lifecycle prevents issues from becoming catastrophic in production. Here at nClouds, we focus on building a local environment that’s similar to your production environment. Or else you continue to run into issues like “it works on my machine`. Rather than pointing developers to a wiki, you can tell them to just follow Readme in the repo and type in a few commands to build a local environment that increases productivity.
Docker-compose helps to enforce better processes. We use it as a handoff between developers and Ops. We work with developers to build fully functional local environment with all the dependencies like Elastic search, Redis, etc. And provide an end point to test the app locally. And Ops can focus on replicating the environment and building the entire deployment pipeline. Trust us, this is much easier debugging the app in ECS!
Since the local environment is built using same config management, it enforces consistency across the entire environment. Docker also provides more flexibility to destroy and create containers quickly which allows developers to do quicker experimentation.
We heavily leverage one of the neat features of Docker-compose — the ability to override settings using multiple files . This makes it easy to override setting for local development. For example, you can mount the local files system in document root for local development.
Docker compose layout:
If we are using ECS, we follow this blueprint to organize services and infrastructure. Check out our other blog post around how to continuous delivery pipeline on ECS using Jenkins. This blueprint also really suitable if you are using micro services. Code for this blog post is on github. As you can see, this is how docker-compose.yml looks like in the root of the directory.
version: "2"
services:
jenkins:
extends:
file: services/docker-compose.yml
service: jenkins
environment:
slaveName: ""
JENKINS_PASSWORD: admin123!
As you can see from the file above, we are extending compose file from services/docker-compose.yml.
Here is how the docker-compose file looks in the service directory.
version: "2"
services:
jenkins:
build:
context: src
dockerfile: Dockerfile
container_name: jenkins
ports:
- "8080:8080"
Developers can also launch resources using multiple compose files `docker-compose -f docker-compose-app.yml -f docker-compose-local.yml up`, for example here is how docker-compose-local.yaml looks like:
version: "2"
services:
jenkins:
volumes:
- ./services/src/jobs:/usr/share/jenkins/ref/jobs/seed-job/workspace/jobs/
You can also have another compose file for a different environment. For example, if you already have some databases running on QA and you want to use them, you could only add them as extra hosts to your application instead of creating them as containers in the compose file. This is how docker-compose-qa.yml could be.
version: "2"
services:
jenkins:
extends:
file: services/docker-compose.yml
service: jenkins
environment:
slaveName: ""
JENKINS_PASSWORD: qa124
From our experience, the ability to spin up the entire local development environment with the docker-compose command improves your ability to build software faster and more consistently.
If you have any additional tips and tricks related to docker-compose, feel free to drop a comment below.
