Recently, I dug my head into docker. For those who don't know it yet: the idea behind docker is to encapsulate an application's execution environment into a so-called container.
It's like virtualization, yet without the actual machine emulation - for example, docker uses the same kernel as the host system. Other people have already explained what it is and how it works in much greater detail, so I won't embarrass myself too much here and simply point to the really good, official documentation:
Docker Documentation

Anyway, this allows containers to be constructed as minimalistic as possible - everything that is not required by the app payload that is to be run can be left out. Most containers to not even contain an editor!

Very often, building a docker image (nomenclature: image: persistent, static set of layers defining the environment and its content ; container: an instance of an image) involves two phases:

1. Defining the execution environment itself. From choosing a base image, to package installation and configuration - this is the most essential step.
   


2. Deploying the actual application that will run inside the container. It is fairly common to simply clone a git repository and make it available to the docker image in order to deploy the code.
   

Now, for the funky part: fabric.

Fabric's main purpose is "remote machine instrumenting" - basically, that means running a set of commands on remote machines that are accessible via SSH.
Of course, fabric also provides the local function for running code on the local machine only.

Turns out, fabric can easily be used to prepare docker's image building process. This approach may be useful if the application payload for the image is subject to change (and seriously, it is going to change).

1. First, prepare your image's execution environment as suits you
   


2. Probably, you will have specified some destination for you application's code. Let's assume it is app inside your docker build context.
   


3. Define a fabric task for cloning the code to your app directory.
   If you don't need the full-fledged repository but are satisfied with the state of one specific tag or branch, try
   

   
   git clone -b <tag_or_branch> --depth=1 <repository> <destination>
   
   

   in order to retrieve a "shallow" clone, i.e. without the history of tag_or_branch
   



4. Define a fabric task for building the docker image. Probably, you want to make sure it is properly tagged on creation (something I forgot the first 10-20 times I ran docker build .... Why not use a timestamp as the image's tag?
   This could look maybe like this:
   

   
   def build_image():
       run("docker build -t docker.my-domain.net"
           + "/image-name:{:%Y-%m-%d}".format(datetime.now()) + " .")
   
   

All in all, this is not much. But it provides a lot of simplification and is immediately ready for remote-invocation of image builds, too.

edit: to be fair, I updated instructions in the fabric task to use run instead of local.
There is no need to put up this kind of articial limitation on oneself - you can always specify "localhost" for running locally, anyway.