Nous utilisons ici singularity http://singularity.lbl.gov/ , dans un cadre de portage d'application vers du HTC/HPC sous forme de conteneur. Ce n'est pas du docker (pas de démon, images qui peuvent être lancées en tant que simple utilisateur...), mais vous pouvez importer des images docker. Singularity a son propre langage de recette, mais il existe des convertisseurs depuis/vers docker. Les images peuvent être transportées très facilement (soit par dépôt/registre, soit par (s)cp / ftp ...); une fois produite, l'image est un simple fichier exécutable.

Si j'ai bien compris ton besoin, cette solution permet d'avoir ce que tu recherches (même si, dans notre cas (HPC), nous portons rarement des applis type bdd) :
  - une image immuable en read-only par défaut au format squashfs (peut être transformé en sandbox ou ext3),
  - des overlayfs au besoin,
  - plusieurs formes de lancement (image en démon avec image.start ou bien le temps de l'exécution avec run ou exec).

Nous utilisons NFS pour partager nos images. Par contre, en cas d'installation de singularity par NFS, il faut penser à créer un dossier local (localstatedir) pour les données temporaires sur chaque client NFS.

J'ai produit un TP accessible ici pour se former rapidement à cette solution : http://mbb.univ-montp2.fr/ust4hpc/tpSingu.html

En terme de performances, il n'y a pas de perte et les recettes sont claires (le contenu est découpé en sections commençant par "%" et les les lignes qui suivent sont en bash).

En terme de répétabilité, c'est également assez appréciable d'avoir des recettes propres qui incluent des sections %test. Dans ce cadre, l'utilisation des overlayfs au-dessus de l'image (qui ne sont pas sous la forme d'une recette), diminuent la lisibilité du conteneur (attention à l'effet boîte noire avec le temps).