When transitioning from a virtual machine based deployment model to a container based model there are at least two ways to version an application - versioning the container image or versioning packages that the container downloads at startup.
Incrementing the container image version has the advantage that a cluster administrator can easily determine which version of an application is deployed by querying which version of the image the container is running. Similarly the cluster admin can automate upgrades and rollbacks with scripts that spin up and bring down different versions of a container. The disadvantages of this approach include the need to integrate automated image builds into the continuous integration pipeline (Jenkins or whatever), and the proliferation of dev-only and broken image versions within the Docker registry.
As a first step toward deploying applications with containers the project I'm involved with is moving toward infrequently publishing a container image for each application which contains the application's envelope dependencies. We take advantage of the Chef scripts we already have to build virtual machines by running chef-client (in chef-zero local mode) during the image build, and wiring up the image with an entry-point that once again runs chef-client to update the container at startup time. The Chef scripts download the latest versions of the application and its dependencies into the container as RPM packages from YUM repositories that our continuous integration pipeline already maintains to support our virtual machine devops workflow.
