search

nuest / ten-simple-rules-dockerfiles

Ten Simple Rules for Writing Dockerfiles for Reproducible Data Science
https://doi.org/10.1371/journal.pcbi.1008316
Creative Commons Attribution 4.0 International
62 stars 15 forks source link

Disussion - Rule 8. End the `Dockerfile` with build and run commands #15

Closed psychemedia closed 4 years ago

psychemedia commented 4 years ago

This is an eminently sensible and practical rule, though it maybe also hints back to Rule 6?

The rationale is to make it easy for a novice to get started; as such, it makes sense to show how to:

Port mapping is something else to mention?

One note: don't do things like map: -p 8888:8888; for a novice, if I want to expose on localhost port 8899, which one do I change?

I think novices can also be confused by things in {}, things prefixed with $, etc; you also need to take care not to introduce platform shell dependencies in the way things are passed (Windows, Max/Linux vars / commands etc).

Generally, I try to remember to give an example of pretty much every likely command switch over several (explained/ contextualised) docker run commands.

If you are making your container available for other people to access from eg dockerhub, also provide a docker push command, along with relevant comments about tagging strategies used.

nuest commented 4 years ago

I concur the ordering of ports in -p is a commonly faced problem, but also one that is widely documented > included in #46

Good point about potentially confusing examples > added to final checks at #7

It would be great if you could help out adding the several example commands where you see fit!

I would advice against docker push, because it is not transparent. Can you live with that?

psychemedia commented 4 years ago

Sorry, yes, I should try to make changes direct. Just a thought that comes to mind on things I've seen from command line that I don't remember offhand are in a rule elsewhere: docker can copy over local context when you build from a local directory, so if you have a huge datafile in the directory, or a subdir with lots of stuff in it (like a .git folder), then that can be copied into the Docker build context even if you don't call on it. .dockerignore is your friend here... It can save time and potentially save you from copying all that private patient data over to a remote build system...