How to use Docker in the development/deployment workflow?

Question

I'm not sure I completely understand the role of Docker in the process of development and deployment.

1. Say, I create a Dockerfile with nginx, some database and something else which creates a container and runs fine.

2. I drop it somewhere in the cloud and execute it to install and configure all the dependencies and environment settings.

3. Next, I have a repository with a web application which I want to run inside the container I created and deployed in the first 2 steps. I regularly work on it and push the changes.

Now, how do I integrate the web application into the container?

• Do I put it as a dependency inside the Dockerfile I create in the 1st step and recreate the container each time from scratch?
• Or, do I deploy the container once but have procedures inside Dockerfile that install utils that pull the code from repo by command or via hooks?
• What if a container is running but I want to change some settings of, say, nginx? Do I add these changes into Dockerfile and recreate the image?

In general, what's the role of Docker in the daily app development routine? Is it used often if the infrastructure is running fine and only code is changing?

Answer 1

I think there is no singl "use only this" answer - as you already outlined, there are different viable concepts available.

Deployment to staging/production/pre-production

a)

Do I put it as a dependency inside the Dockerfile I create in the 1st step and recreate the container each time from scratch?

This is for sure the most docker`ish way and aligns fully with he docker-philosophy. It is highly portable, reproducible and suites anything, from one container to "swarm" thousands of. E.g. this concept has no issue suddenly scaling horizontally when you need more containers, lets say due to heavy traffic / load.

It also aligns with the idea that only the configuration/data should be dynamic in a docker container, not code / binaries /artifacts

This strategy should be chosen for production use, so when not as frequent deployments happen. If you care about downtimes during container-rebuilds (on upgrade), there are good concepts to deal with that too.

We use this for production and pre-production intances.

b)

Or, do I deploy the container once but have procedures inside Dockerfile that install utils that pull the code from repo by command or via hooks?

This is a more common practice for very frequent deployment. You can go the pull ( what you said ) or the push (docker cp / ssh scp) concept, while i guess the latter is preferred in this kind of environment.

We use this for any kind strategy for staging instances, which basically should reflect the current "codebase" and its status. We also use this for smoke-tests and CI, but depending on the application. If the app actually changes its dependencies a lot and a clean build requires a rebuild with those to really ensure stuff is tested as it is supposed to, we actually rebuild the image during CI.

---

Configuration management

1.

What if a container is running but I want to change some settings of, say, nginx? Do I add these changes into Dockerfile and recreate the image?

I am not using this as c) since this is configuration management, not applications deployment and the answer to this can be very complicated, depending on your case. In general, if redeployment needs configuration changes, it depends on your configuration management, if you can go with b) or always have to go a).

E.g. if you use https://github.com/markround/tiller with consul as the backend, you can push the configuration changes into consul, regenerating the configuration with tiller, while using consul watch -prefix /configuration tiller as a watch-task to react on those value changes. This enables you to go b) and fix the configuration

You can also use https://github.com/markround/tiller and on deployment, e.g. change ENV vars or some kind of yml file ( tiller supports different backends ), and call tiller during deployment yourself. This most probably needs you to have ssh or you ssh on the host and use docker cp and docker exec

Development

In development, you generally reuse your docker-compose.yml file you use for production, but overload it with docker-compose-dev.yml to e.g. mount your code-folder, set RAILS_ENV=development, reconfigurat / mount some other configurations like xdebug or more verbose nginx loggin, whatever you need. You can also add some fake MTA-services like fermata and so on

docker-compose -f docker-compose.yml -f docker-compose-dev.yml up

docker-compose-dev.yml only overloads some values, it does not redefine it or duplicate it.

Depending on how powerful your configuration management is, you can also do a pre-installation during development stack up.

We actually use scaffolding for that, we use https://github.com/xeger/docker-compose and after running it, we use docker exec and docker cp to preinstall a instance or stage something. Some examples are here https://github.com/EugenMayer/docker-sync/wiki/7.-Scripting-with-docker-sync

If you are developing under OSX and you face performance issues due to OSXFS / code shares, you probably want to have a look at http://docker-sync.io ( i am biased though )