A few quick thoughts

[cboettig]

Just taking a quick look over this, looks very nice.

Will you cover linking local directories? In my experience, this helps the whole thing feel a lot more native to users than the typical virtualbox approach. https://github.com/rocker-org/rocker/wiki/Sharing-files-with-host-machine

Curious what you think about one thing: our docs show using the 8787 port, but I can't decide if it would be easier for users if we just mapped to port 80 instead (e.g. -p 80:8787 instead of -p 80:8787) to avoid that extra step of appending a port onto an IP (which sounds pretty convoluted the first time anyhow). But maybe that's asking for trouble.

Good that you cover the basics of listing and killing a container; I've seen a new user be confused by trying to launch a second instance and not realizing one is already running (and getting the error about port already bound). However, seems you should really emphasize that this destroys any data in the container (unless you link local volumes; which is one reason why I like to teach that part).

Personally I would probably teach docker commit and docker push before teaching anything about Dockerfiles. This way users can install software on an image interactively via RStudio and save the image. Note that commit saves changes to files on the container unless those files are actually on a linked local volume, in which case they are external to the container and then not saved. Maybe easier not to teach linking local volumes so you don't hit that issue... If you are not linking local files, this is another convenient way to save your work and even move it between machines (particularly cloud instances); though you'll want to use the 1 free private DockerHub repo to push to if you include the local data.

I would also consider teaching a few docker-machine commands. Given that Docker Toolbox is now docker-machine under the hood, this makes the leap from local to cloud instance crazy easy. You can get some free cloud credits or just practice via virtualbox.

Minor thing, but in your "Writing Dockerfiles" section, perhaps your goal is to stick to generic commands, but we usually find it easier to add additional packages with littler, e.g. install2.r -e gapminder instead of wget + R CMD INSTALL (e.g. see our Dockerfiles). But maybe it's worse to introduce littler and Dockerfiles.

[bkatiemills]

Thanks, @cboettig! A few quick responses:

Will you cover linking local directories?

Yep, right here; students are definitely going to want to be able to pull files (results) out of the docker bubble universe, and this is the simplest way.

• Ports: I don't think it's a big deal, I wouldn't worry about it.
• Docker commit, push and dockerhub: all super important - for lesson 2. My goal here is to get people spinning up images and getting those images interacting with some code and data, and (AFAIK) you need a Dockerfile to make an image that isn't plain vanilla from someone else. We can worry about communicating with the rest of the world next time; I do plan to advertise this, though.
• docker-machine: if there's time (60 minute cap) and if people don't seem too confused already - good idea!
• littler: oooo I hadn't seen that! Does it help with resolving dependencies of R packages? That's one speedbump I don't have a great answer for yet (someone is definitely going to ask why not just do install.packages('foo')).

Thanks again, great suggestions all!

[cboettig]

Yup, littler handles R dependencies, littler's install2.r script is just a wrapper around install.packages().

[griz1112]

Its not necessary to prefix the docker command with sudo on Linux. Add your username to the docker group in /etc/groups and reboot the machine and you no longer need to use sudo.