Here's a docker anecdote from the coalface... Inspired by Carl and Dirk's work, I wanted to use rstudio with boot2docker in a senior undergrad/grad student class I'm currently teaching to explore new ideas in reproducible research and preserve hard drive space by avoiding a big vm image. The students are social science majors with windows/mac machines and no prior experience with a command line interface. During testing we found the same problems noted just now by Dav and Aron (simple, reliable methods for forwarding ports and sharing folders with b2d are not available for the common-or-garden user), so we went for a lightweight vm (lubuntu in virtualbox, inspired by the BCE), and that's been excellent.

We discourage students from installing rstudio directly because we use devtools to get things from github, and for mac users that can require updating the OS, which can be very time consuming and distressful for some students. We also have a dependency on perl, which gets a similar reaction from windows users.

But things are moving fast with docker, which is encouraging, and hopefully the microsoft/docker collaboration will make boot2docker more accessible for windows users. That, and a more entry-level, how-to blog posts on doing science with docker (from those who are - not me! Carl is prolific on the topic [1]), might help lower the barriers to using docker, especially for researchers and students with novice computing skills.

Ben

[1]: http://www.carlboettiger.info/tags.html#docker



On 26/10/2014 11:01 AM, Dav Clark wrote:
Ultimately, the responses are very mixed, but the important thing is
that some of us can reliably get folks up and running quickly with a
consistent environment, even if they hit a snag with VirtualBox (which
is what we're using now for local installs). I need to be fairly
disciplined about this, as once folks are in the "trying to get software
to work on my laptop" mode, it's very hard to convince them to give up
(for the time being).

There's some nuance in doing all of this, though, and providing the same
setup can leave folks frustrated or very grateful depending on how it's
presented. I can't reliably communicate how to do that (and, honestly,
some of what I do may be mere "incantation"!). But part of what I
*think* works, is emphasizing that this is a full-featured, batteries
included environment (including some tricky installs, even for linux),
and that after we're done the training, we're happy to help configure
their laptop however they'd like.

Best,
D

On Sun, Oct 26, 2014 at 10:57 AM, Greg Wilson
<gvwil...@software-carpentry.org
<mailto:gvwil...@software-carpentry.org>> wrote:

    Thanks for the background, Dav - how are Windows users reacting to
    all this?
    Cheers,
    Greg


    On 2014-10-26 1:48 PM, Dav Clark wrote:
    As Aron suggested, we are actively considering the use of Docker
    now at Berkeley. In particular, boot2docker 1.3 has made some nice
    changes that allow for easier mapping from inside the inner
    container all the way to the host level (though it's still not
    there yet for port mapping). I apologize if I was part of the
    telling you "to get lost" crowd. I do have a set of concerns that
    are somewhat articulated above, but it boils down to the following
    two use-cases:

    1. Having an installation process that relies on familiar and
    reliable GUI operations to get started with the new programming
    environment.

    2. Having a more-or-less already configured VM / account for some
    users in "the cloud" (where, "the cloud" might be my development
    server in D-Lab).

    Docker may be useful for (2) now, but I think it's still not worth
    the extra work beyond either setting up your own multi-user
    server, or simply having a straight-up cloud VM (i.e., not
    Dockerized, but rather an EC2 AMI or DigitalOcean droplet, etc.).
    A lot of /instructors/ are not necessarily skilled sys-admin / ops
    types (like me, for example ;). So even though we are insulating
    our students in (2), we still should keep things simple for our
    instructors.

    But I agree that Docker is getting to where it's likely to be more
    useful than difficult soon, and I certainly don't want to
    discourage anyone from exploring how to make that easier! Perhaps
    it's important to distinguish between development efforts and
    current suggestions for provisioning student environments?

    FWIW, the above-mentioned pioneer, Carl Boettiger, has been
    submitting changes to the standard VM we're using at Berkeley to
    show us the way forward with Docker:

    https://github.com/dlab-berkeley/collaboratool/pull/90

    We certainly welcome folks to contribute / fork / extend our work
    there. We've made strong arguments about why it makes sense to use
    Packer as the BASE configuration tool (gloss: it can provision
    pretty much anything). But nothing is set in stone.

    Shine on, you crazy Dockers,
    D

    On Sun, Oct 26, 2014 at 10:07 AM, Aron Ahmadia <a...@ahmadia.net
    <mailto:a...@ahmadia.net>> wrote:

        Hi Trevor and Greg,

        My understanding from interacting with the tmpnb server [live
        demo at https://tmpnb.orge] is that it is a zero-install
        approach.  The installation/maintenance load is reshouldered
        onto system administrators, and the users can focus on getting
        work done.

        I think that assumption [1] There's no room in the
        schedule..., should probably be [1A There's no room in the
        schedule] OR [1B The learners will be working from this cloud
        infrastructure in the future].  It looks to me that a number
        of groups, from the D-Lab at Berkeley to JuliaBox at MIT, to
        DIT4C at University of Melbourne, are moving at full steam on
        providing this back-end support.

        Does this make sense?
        A

        On Sun, Oct 26, 2014 at 4:31 PM, W. Trevor King
        <wk...@tremily.us <mailto:wk...@tremily.us>> wrote:

            On Sun, Oct 26, 2014 at 12:20:39PM -0400, Greg Wilson wrote:
            > 5. The learners are already familiar with Linux,
            explicitly want to
            > learn it, or it's an authentic task worthy of a lesson
            in its own
            > right.

            Docker is trying to branch out beyond Linux.  For example,
            they're
            working with Microsoft on a Docker engine [1] and native
            client [2]
            for Windows Server.  Not that many of our students are
            likely to show
            up with the server-flavor installed on their laptop, but
            still, Docker
            is aiming to be a generic deployment framework like
            existing virtual
            machines, but without bundling kernels.  I don't know how many
            scientists use Windows Server boxes for their research,
            but I'm often
            surprised by support for non-free OSes ;).

            Cheers,
            Trevor

            [1]:
            
http://blog.docker.com/2014/10/docker-microsoft-partner-distributed-applications/
            [2]:
            
http://azure.microsoft.com/blog/2014/10/15/new-windows-server-containers-and-azure-support-for-docker/

            --
            This email may be signed or encrypted with GnuPG
            (http://www.gnupg.org).
            For more information, see
            http://en.wikipedia.org/wiki/Pretty_Good_Privacy

            _______________________________________________
            Discuss mailing list
            Discuss@lists.software-carpentry.org
            <mailto:Discuss@lists.software-carpentry.org>
            
http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org



        _______________________________________________
        Discuss mailing list
        Discuss@lists.software-carpentry.org
        <mailto:Discuss@lists.software-carpentry.org>
        
http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org




    --
    Dav Clark
    Data Scientist
    UC Berkeley D-Lab
    dlab.berkeley.edu <http://dlab.berkeley.edu>
    510-664-7000 <tel:510-664-7000>


    _______________________________________________
    Discuss mailing list
    Discuss@lists.software-carpentry.org  
<mailto:Discuss@lists.software-carpentry.org>
    
http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org


    --
    Greg Wilson
    Software Carpentry |http://www.software-carpentry.org/




--
Dav Clark
Data Scientist
UC Berkeley D-Lab
dlab.berkeley.edu <http://dlab.berkeley.edu>
510-664-7000


_______________________________________________
Discuss mailing list
Discuss@lists.software-carpentry.org
http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org


_______________________________________________
Discuss mailing list
Discuss@lists.software-carpentry.org
http://lists.software-carpentry.org/mailman/listinfo/discuss_lists.software-carpentry.org

Reply via email to