Examples about ten-simple-rules-dockerfiles HOT 16 OPEN

I'm working on https://github.com/neural-reckoning/vcn_regularity/blob/master/Dockerfile from the list above and will have it by the end of the week.

from ten-simple-rules-dockerfiles.

I don't think most of the Dockerfiles that I write satisfy these conditions, to be honest (and ironic)! Maybe one that has a few (cleaning up, small reliable base, multistage build, label) would be https://github.com/singularityhub/singularity-docker/blob/v3.5.3-slim/Dockerfile.

from ten-simple-rules-dockerfiles.

In my own dabblings, I've started forsaking Dockerfiles and moving to REES / MyBinder builds (apt.txt, requirements.txt, postBuild etc). These have the upside of being largely syntax free and quick to produce in an ad hoc fashion, but with the downside of not providing a linear narrative, as well as separating out elements that are grouped (eg grouping together a Linux package installed wrapped by a Py API/extension that is enabled in a Jupyter environment via postBuild and with a service enabled in start. It could be useful to tag lines at the end so they could be grouped in someway, perhaps? (Thinks: @betatim do we need a 10 simple rules for REES configs?!))

The most complex setups I did were still quite simple, for personal use only, and tended to use docker-compose (so that I could reuse other people's containers (example).

The other extreme are really simple single app containers, which I guess could be interesting trying to "bring up to spec" (candidate example?.

The most complex single container builds I done have also tended to be experimental in the way I've constructed them, essentially based on a flakey "stack" model (example).

FWIW, I'm happy for any of the Dockerfiles I've created to be used as examples of bad practice (I tend to share all my work in progress because the bad practice / errors are useful reference points when it comes to writing teaching materials ("pragmatically, you might think you should do X, because Y, but actually, that sucks because Z". (My own work rarely gets past Y...;-))

I also note that a lot og good practice comes from good habits, eg always starting a file with X (eg some metadata) always finishing it with Y (an example of usage for example) which can come from good cookie cutters / templates and, if you use them (auto)linters.

from ten-simple-rules-dockerfiles.

@vsoch The fact that most of the Dockerfiles won't satisfy the conditions is the idea behind have "before and after" in the examples directory.

@psychemedia Thanks for the example links, especially if you consider them "bad" practice (though they worked for you, right?). Will you rewrite them yourself to demonstrate the rules?

from ten-simple-rules-dockerfiles.

https://github.com/sje30/eglen2015/blob/master/Dockerfile (suggested by @sje in #6 (comment))

from ten-simple-rules-dockerfiles.

Candidate for rewrite: https://github.com/nuest/docker-qgis-model/blob/master/workspace/example/Dockerfile based on https://github.com/nuest/docker-qgis-model/blob/master/ubuntu/Dockerfile.xenial used in https://www.mdpi.com/2072-4292/9/3/290/htm

from ten-simple-rules-dockerfiles.

Candidate for rewrite: https://science.sciencemag.org/content/suppl/2020/04/22/368.6489.420.DC1 is a supplement to a paper with a Dockerfile and even an image tarball.

from ten-simple-rules-dockerfiles.

@psychemedia I took a look at the Ergast F1 example, and don't think it is a good fit for a rewrite because the goal seems to be a job for regularly updating a copy of a database.

I did a review of the OpenRefine Dockerfile, let me know what you think: #75

Checklist for me (or anyone who gets to them first):

• https://github.com/mrc-ide/covid-sim/blob/master/Dockerfile @nuest
• https://github.com/sje30/waverepo/blob/master/Dockerfile (not too different from existing examples
• https://github.com/sje30/eglen2015/blob/master/Dockerfile done by @sje30
• https://github.com/nuest/docker-qgis-model/blob/master/workspace/example/Dockerfile together with https://github.com/nuest/docker-qgis-model/blob/master/ubuntu/Dockerfile.xenial (paper: https://www.mdpi.com/2072-4292/9/3/290/htm) @nuest
• https://science.sciencemag.org/content/suppl/2020/04/22/368.6489.420.DC1 @nuest
• https://github.com/neural-reckoning/vcn_regularity/blob/master/Dockerfile @bdevans

from ten-simple-rules-dockerfiles.

Here is a nice example of how to use target for multistage builds, although I've never done one like that. https://www.hackdoor.io/articles/1vpakaJw/docker-multi-stage-build-to-create-optimal-images-for-dev-and-production

from ten-simple-rules-dockerfiles.

Thanks @bdevans - I was just about to start with that one :-) Will instead spend some time on https://github.com/nuest/docker-qgis-model/ and https://science.sciencemag.org/content/suppl/2020/04/22/368.6489.420.DC1

from ten-simple-rules-dockerfiles.

Hi @nuest, so I applied the rules to the VCN regularity Dockerfile last night and then found out that the original no longer builds (could be due to disappearing Python 2 libraries or a change in the conda dependency solving algorithm). Presumably you only want Dockerfiles that build included in the examples, right? If so, do you have any other good candidates in mind to work on instead? It also occurred to me that it could be nice to have a no-Dockerfile example i.e. demonstrate Rule 1 by reducing an existing Dockerfile to a simple environment.yml for use with Binder. What do you think?

from ten-simple-rules-dockerfiles.

from ten-simple-rules-dockerfiles.

Hi @bdevans It would be nice if they build, but if you make it clear in the corresponding README why it does not build, and can point out how to avoid that problem as much as possible in the "updated" verison, then I'd say it is useful to include.

I really like the idea to have examples for Rule 1! 👍 That should be pretty straightforward for the VCN example as they already have a Binder button, right? I think the repo predates some features that MyBinder has today.

from ten-simple-rules-dockerfiles.

@sje30 The repo https://github.com/sje30/rescience-hor is already the "after", right? Can you point to some supplemental material where there is the "before" state? I think then we can just have a example-name/README.md explaining what you did, and actually don't need a before Dockerfile.

from ten-simple-rules-dockerfiles.

Ok, I'll submit a PR with the revamped Dockerfile (and other minor edits for now) but happy to take a look at replacing it with a no-Dockerfile example once Dan and I upgrade everything to work again.

from ten-simple-rules-dockerfiles.

@nuest there was no before! but given that we are talking about not writing a dockerfile, it is okay I think.

from ten-simple-rules-dockerfiles.