Best-practices tweaks to Dockerfiles

[cboettig]

The Best-practices repo suggests we

• Avoid ever using apt-get dist-upgrade
• Update on the same line as any install call, e.g. RUN apt-get update && apt-get install -y, such that the cache is always invalidated and the latest versions of those packages will thus be installed.
• List each install on a new line (with \), sorted alphanumerically...

Other than that, we're more-or-less doing okay.

• I should see if I can use an ENTRYPOINT in rstudio to run the script, rather than the current supervisord thing, in order to get a persistent rstudio instance running. (one disadvantage is that I believe that would run the script to launch RStudio even when the container is run interactively)

I'm also warming up to the idea of just canning the Ubuntu branch and being able to simplify the namespace and the complexity of the project in general as a result...

[eddelbuettel]

What is its problem with dist-upgrade? Never upgrade? Or prefers apt-get upgrade? I have strong preference for dist-upgrade over upgrade, and I think not upgrading is back ("staleness").

I haven't had time to read up on detail -- I saw ENTRYPOINT and agree that that could be our new friend.

Re reducing to one flavor: time will tell. Next up for me is adding r-devel-san, may not get to it for a few days though.

[cboettig]

From the docs:

Avoid RUN apt-get upgrade or dist-upgrade, since many of the “essential” packages from the base images will fail to upgrade inside an unprivileged container. If a base package is out of date, you should contact its maintainers. If you know there’s a particular package, foo, that needs to be updated, use apt-get install -y foo and it will update automatically.

Meanwhile always pairing apt-get update in the same AUFS layer as apt-get install will make sure that anything we install explicitly is updated. Also notes:

Don’t do RUN apt-get update on a single line. This will cause caching issues if the referenced archive gets updated, which will make your subsequent apt-get install fail without comment.

[eddelbuettel]

I think I disagree with that. We'll see how it goes -- in any even we do use current base containers (ie debian/testing), so we should be good.

[cboettig]

seems like I still need supervisord to prevent the container from just exiting after it runs rserver. Meanwhile I made the simple formatting / apt-get update changes to debian-rstudio and debian-hadleyverse

[cboettig]

Yeah, I'm not clear what they mean by 'essential packages will fail to update in an unprivileged container', seems like the packages will update just fine... OTOH, it does seem like everything should be updated already since we're using a good base image and then running apt-get update && apt-get install together. You're the guru on this stuff though so I'm happy to stick with whatever you'd recommend.

[eddelbuettel]

I like the updates you just make; I made one more minor iteration on the rstudio one.

As for breaking or not when updating: I have yet to see that, either at Travis or here. Timeouts, sure. Actual breakage: naah.

[cboettig]

nice, thanks for cleaning up those lines.

Um, on the author line, is it possible to put both our names in the actual
Maintainer line? (so that it's part of the image metadata?) Perhaps people
are more likely to read the Dockerfile than the image metadata, but still...

On Thu, Oct 2, 2014 at 3:33 PM, Dirk Eddelbuettel notifications@github.com
wrote:

I like the updates you just make; I made one more minor iteration on the
rstudio one.

As for breaking or not when updating: I have yet to see that, either at
Travis or here. Timeouts, sure. Actual breakage: naah.

—
Reply to this email directly or view it on GitHub
#17 (comment).

Carl Boettiger
UC Santa Cruz
http://carlboettiger.info/

[eddelbuettel]

Why not -- just sent another commit to that effect.

[cboettig]

I think we've largely hit this. We still run a few apt-get dist-upgrades because we feel that's still a good idea.

I looked at getting away from supervisord for rstudio using Entrypoints but it doesn't seem possible. Sticking with the default entrypoint for now seems advisable and flexible.