-
Notifications
You must be signed in to change notification settings - Fork 0
Have a dedicated docker compose.yml for development
Your development environment will be a different deployment definition than your production environment and thus will need a dedicated docker-compose.yml.
Let's call it docker-compose-dev.yml.
As you can see in the example app, docker-compose.yml and docker-compose-dev.yml are very similar. In fact, they define the same containers but provide a different build context and service options.
You do not have to create a new Dockerfile for each of your image, but just for the one you want to change the behavior in dev mode.
For each of these images, create a Dockerfile-dev.
These dev images should be built FROM the production images. (see https://github.com/dynamiccast/docker-dev/blob/master/backend/Dockerfile-dev as an example). This allows to keep the current production build process which actually works and just add more stuff onto it.
Your images build by docker-compose should be given a name. This works out of the box with docker-compose if a build instruction and an image instruction are provided at the same time for a single service. (See https://github.com/dynamiccast/docker-dev/blob/master/docker-compose.yml#L23).
In you Dockerfile-dev you can really add anything you'd like to be available in your dev env. The first important thing will be a code live reloading mechanism.
Whereas production images should not necessarily contain your source code, development contains should mount source code from the host to the container file system. This will allow you to edit the source code on your host with your favorite text editor and have your code edited at the same time in your container.
Just add a volume instruction to your docker-compose-dev.yml for each of your services. (example: https://github.com/dynamiccast/docker-dev/blob/master/docker-compose-dev.yml#L30).
Now the source code is "synced" between your host and your container, you will need to execute a different command on container startup so that your actual CMD is restarted on file system changes. (Example with a node.js app and forever https://github.com/dynamiccast/docker-dev/blob/master/backend/Dockerfile-dev#L9).
Look what is available for your language/framework. In case you find nothing, you can always fallback to a good old inotifywait to trigger your rebuild on file change.