Merge remote-tracking branch 'origin/master'

Author: nuest

summary.Rmd

@@ -0,0 +1,42 @@
+Summary
+=======
+
+1. Use available tools
+    a. Use ready-made images (e.g. from Docker Hub)
+    b. Dockerfile generators (e.g. repo2docker)
+    c. Linters
+    d. Project templates (e.g. [cookie cutter](https://github.com/cookiecutter/cookiecutter)) [new]
+2. Use versioned images
+    a. Use version-tagged base images
+    b. Publish your own images with version tags [revise]
+3. Format for clarity
+    a. Use indentation, line breaks and unabbreviated arguments
+    b. Clarity is better than brevity
+    c. Group related commands
+4. Document within the Dockerfile
+    a. Add comments explaining the instructions
+    b. Use labels for metadata
+    c. Include usage instructions
+5. Specify software versions
+    a. Pin system library versions
+    b. Explictly list package versions to install
+    c. Comment why each is needed
+6. Use version control
+    a. Use Continuous Integration and automated testing
+    b. Include scripts (and requirements.txt) in the same repository
+7. Mount datasets at run time
+    a. Use bind mounts for accessibility
+    b. Keep large or sensitive datasets out with `.dockerignore`
+    c. Document expected mounts for external resources
+8. Make it one-click runnable
+    a. Set default behaviour with `CMD` and `ENTRYPOINT`
+    b. Document how to use it interactively
+9. Order the instructions
+    a. Least --> most changable for caching and fast builds
+    b. Regularly use `--no-cache` to catch problems [duplicate: 10b]
+10. Regularly use and rebuild containers
+    a. Use the container throughout each project for confidence in your workflow
+    b. Rebuild every 1-2 weeks with `--no-cache` to catch problems
+    c. Provide a `Makefile` or script for convenience
+    d. Ask a colleague to try it
+    e. Publicly archive the image used for the publication