Proper workflow for web development with Docker

Question

I started learning Docker today and I've been able to create my first custom image with a Python stack based on ubuntu:14.04 after a couple of hours, by experimenting with both Dockerfile build and by modifying an existing image and save it using the commit command.

My Dockerfile is the following:

FROM ubuntu:14.04
MAINTAINER Davide Zanotti <***@gmail.com>
ENV DEBIAN_FRONTEND noninteractive
RUN apt-get update && apt-get install -y \
        software-properties-common \
        build-essential \
        automake \
        checkinstall \
        git \
    && add-apt-repository -y ppa:fkrull/deadsnakes && apt-get update && apt-get install -y python3.5 \
    && cd /usr/bin && ln -s python3.5 python \
    && apt-get clean && rm -rf /var/lib/apt/lists/*

So far so good, but now I'm wondering which should be the proper workflow for web development using Docker!

I tried the sample application built by Docker using Flask (docker hub, git source), but I have several concerns about it... the app is bundled directly in the Docker container and IMO is not a feasible approach (at least during development!), because each time I edit the app code I have to rebuild the whole container (right?).

What I would like to achieve is instead a base container, with a specific python installation and all the third-party libraries my app needs (like database drivers and so on), and in this container have my app injected dynamically (ideally via git once deployed, but maybe in alternative way when developing locally in order to speed things up).

So what's the proper way to (or... how do you) approach web development using Docker? (I didn't find anything helpful regarding this topic in the official documentation and the online articles looks too basic IMO... I would like to hear about real world examples from people that are actually using Docker for their apps! :P)

Answer 1

I'm going to suggest you a few things regarding you question.

In your case, you may use two options:

1. Yes, you'll have to rebuild the whole container. To be more correct, you'll have to rebuild an image, that is used for container launching. But Docker allows you to rebuild an image incrementally, using layers, that are like slices lying one on one. That allows you to use less amount of disk space and this operation will take less time (because only NEW changes are added to the image).

Pros: Your image will be completely shippable - you may prepare it and use it everywhere - everything you need is bundled inside.

Cons: Yes, you'll have to rebuild the container. In a case of an active development process that might be not so comfortable and flexible for you.

2. You may mount the shared directories from your host machine. I may recommend you ti read this guide, but I'll also describe you in brief how does it work - your local directories (with your code for example), will be "visible" inside of your container. The application, that should use that code will work with it like with a "local" code, so you won't have necessity to rebuild the container after every code change.

Pros: Yes, it speeds up your development process - you may test your code immediately in your container.

Cons: That is not a portable, shippable and universal solution. If you're going to use that container on more than one host (for example, you have a flow with Dev -> Staging -> Production environments), you won't have possibility to simply use the same bundled container on these hosts - you will also have to deliver the code on that nodes, that should be used inside of the container.

Going to summarize the things, described above - you may use Docker containers in a classic ("bundled") case if you have the stateless applications - if you're going to implement any static changes in it - you'll have to rebuild the source image and relaunch the container.

If you'd like to run some stateful applications or you'd like to store some data using Docker containers (don't forget, you can't store any data in a container itself - it might be killed and relaunched anytime, and its state will be reverted to the original image state!), you may use the shared volumes in Docker or you'll have to refuse Docker usage in this case.

Docker is not a silver bullet - it is really useful in a lot of cases, but there are a lot of other cases, where you may use other, more convenient technology.

PS. One flow sample, that I've used on one of my previous projects, where we had to build a complex web-based application with load balancers, frontend, backend and database applications. We haven't used the Docker shared volumes - your developers have written the code, committed it to Git repo, Jenkins caught that commit and built a new image, that has been committed to our self-hosted Docker Registry. These images have been marked by different labels, depending on the environment, where they have to be used (dev, stage, prod), and they have been deployed on "their" environment by the configuration management system.

PSS. For the whole flow, I may also recommend you to use some container management tools like Kubernetes, instead of pure Docker usage. Kubernetes will provide you possibilities to manage your inter-container network, deploy containers on the multiple environments and/or with the multiple providers, load-balance your container-based applications etc.