<div dir="auto">You win. Nice set of good uses. The python use case was the clincher as I&#39;ve got groups that each use different versions of Python and the main code. <div dir="auto"><br></div><div dir="auto">Time to learn how to toss containers around on the HPC.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On May 16, 2017 1:02 AM, &quot;Ted W.&quot; &lt;<a href="mailto:ted-lists@xy0.org">ted-lists@xy0.org</a>&gt; wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">&gt; I&#39;ve yet to find a use case in our setup for it that wasn&#39;t either:<br>
&gt; 1.  &quot;Containers are cool, we need to use them!&quot;<br>
&gt; 2.  Incoherent string of buzzwords from someone who just got back from a conference.<br>
<br>
Of course every environment is different but I hear this sentiment a lot<br>
and I thought your comment made a good launching off point for another<br>
mini rant on how containers can be useful. I&#39;ll list a few examples<br>
below and try to explain in some detail why containers are a great fit<br>
in each situation.<br>
<br>
Bootstrapping a development environment:<br>
        Let&#39;s say I build an application in python and I post it on<br>
        GitHub for others to download and contribute. To build my Python<br>
        application you need several python dependencies and sometimes<br>
        these dependencies conflict with the versions installed on your<br>
        system from your package repository or that you have installed<br>
        manually to build some other Python application. Normally, you<br>
        would have to know how to setup a separate python environment<br>
        using a tool like pyenv to get an isolated environment. At best,<br>
        you already know how to do this.  At worst, I have to write a<br>
        bunch of extra documentation or a script to do it for you. I<br>
        have to then keep up with this and make sure it remains accurate<br>
        as the project evolves.<br>
<br>
        If I&#39;m using Docker in this scenario, I can write a Dockerfile<br>
        that contains all of my dependencies and ship that in the same<br>
        repository as my code. I don&#39;t have to care about what operating<br>
        system you&#39;re running. I don&#39;t have to worry about what<br>
        environment variables you have set or what package versions you<br>
        have that might cause weird issues that will get reported as<br>
        bugs. Additionally, if someone contributes code to the project<br>
        that changes the build process, they are also empowered to<br>
        change the build environment because it&#39;s clearly defined in a<br>
        single text file. When someone later tries to build the<br>
        repository, after pulling down the updates, they run docker<br>
        build (or some wrapper script provided in the repository) and<br>
        the container builds with these new dependencies and the<br>
        application build Just Works because the developer knew exactly<br>
        what the build environment looked like.<br>
<br>
Deploying application updates:<br>
        You have an application you need to update. On a traditional<br>
        system, you have an operating system on a machine and you update<br>
        the application either through your package manager or through<br>
        some code deployment workflow. Once it&#39;s deployed, you find an<br>
        issue. With packages, you might be able to `yum downgrade` or<br>
        equivalent but what if it&#39;s a code change to your internal<br>
        application? What changed between the last version and this<br>
        version of the code? Can you easily revert these changes?<br>
        Maybe, if you had built it in to a package for the OS before<br>
        deployment.<br>
<br>
        If you&#39;re using containers to run your application, you build a<br>
        new version of your container which has the new version of your<br>
        code as well as any dependency updates. You shoot the old<br>
        container in the head and you start up the new container. If you<br>
        find a problem. You shoot this new one in the head and start the<br>
        old one up again. You can also use one of the many container<br>
        management platforms on the market (Swarm, Rancher, etc.) to<br>
        define a percentage of the containers running the application<br>
        which should be replaced by the new version to roll out the<br>
        application gradually.<br>
<br>
Security<br>
        Containers are just processes on a host OS that are isolated<br>
        using cgroups and kernel namespaces. If you don&#39;t want your<br>
        container to do something, you can set the appropriate<br>
        restrictions on the host operating system. There are even tools<br>
        emerging now to improve this experience. Liz Rice recently gave<br>
        a talk this past week at OSCON [1] about restricting the syscalls<br>
        your container can make to the host kernel.<br>
<br>
        As someone already pointed out in another thread, you do have to<br>
        be aware of where your containers come from. In production, you<br>
        should really build your containers from the scratch image or<br>
        directly from the official (Alpine|CentOS|Debian|.*) container<br>
        repository. **<br>
<br>
        [1] <a href="https://conferences.oreilly.com/oscon/oscon-tx/public/schedule/detail/56840" rel="noreferrer" target="_blank">https://conferences.oreilly.<wbr>com/oscon/oscon-tx/public/<wbr>schedule/detail/56840</a><br>
        ** There are differing opinions on this<br>
<br>
On Mon, May 15, 2017 at 01:41:09PM +0000, Beddingfield, Allen wrote:<br>
&gt; I&#39;ve yet to find a use case in our setup for it that wasn&#39;t either:<br>
&gt; 1.  &quot;Containers are cool, we need to use them!&quot;<br>
&gt; 2.  Incoherent string of buzzwords from someone who just got back from a conference.<br>
&gt; Allen B.<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt; Allen Beddingfield<br>
&gt; Systems Engineer<br>
&gt; Office of Information Technology<br>
&gt; The University of Alabama<br>
&gt; Office <a href="tel:205-348-2251" value="+12053482251">205-348-2251</a><br>
&gt; <a href="mailto:allen@ua.edu">allen@ua.edu</a><br>
&gt;<br>
&gt; On 5/15/17, 8:29 AM, &quot;<a href="mailto:ale-bounces@ale.org">ale-bounces@ale.org</a> on behalf of Jim Kinney&quot; &lt;<a href="mailto:ale-bounces@ale.org">ale-bounces@ale.org</a> on behalf of <a href="mailto:jim.kinney@gmail.com">jim.kinney@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt;     I still see &#39;containers&#39; as a blend between a chroot and a virtual machine.<br>
&gt;<br>
&gt;<br>
&gt;     As an admin, user willingness to download any old container they found on the tubes that has their solution stuffed into it is a terrifying idea.<br>
&gt;<br>
&gt;<br>
&gt;     On Mon, 2017-05-15 at 09:22 -0400, leam hall wrote:<br>
&gt;<br>
&gt;     On Mon, May 15, 2017 at 9:16 AM, Beddingfield, Allen &lt;<a href="mailto:allen@ua.edu">allen@ua.edu</a>&gt; wrote:<br>
&gt;<br>
&gt;     Since I&#39;m a SUSE guy, I would automatically say SUSE/openSUSE, but I&#39;m sure you will get that answer from each person with their preferred distro(s).<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;     &quot;If I knew SuSE like you know SuSE...&quot;   Sorry, couldn&#39;t resist.<br>
&gt;<br>
&gt;     Remeber those Sun boxes? This will be going on them. We now have a<br>
&gt;     garage to deal with the sound issue.   :)<br>
&gt;<br>
&gt;     After a couple decades I&#39;m not sure the current distro vendors get it.<br>
&gt;     RH seems to be moving away from being on the hardware or a VM, and<br>
&gt;     wants to go theri own way like Solaris. If I&#39;m going to go somewhere<br>
&gt;     might as well go all the way.<br>
&gt;<br>
&gt;     Leam<br>
&gt;     ______________________________<wbr>_________________<br>
&gt;     Ale mailing list<br>
&gt;     Ale@ale.orghttp://<a href="http://mail.ale.org/mailman/listinfo/ale" rel="noreferrer" target="_blank">mail.ale.<wbr>org/mailman/listinfo/ale</a><br>
&gt;     See JOBS, ANNOUNCE and SCHOOLS lists at<br>
&gt;     <a href="http://mail.ale.org/mailman/listinfo" rel="noreferrer" target="_blank">http://mail.ale.org/mailman/<wbr>listinfo</a><br>
&gt;<br>
&gt;     --<br>
&gt;     James P. Kinney III<br>
&gt;<br>
&gt;     Every time you stop a school, you will have to build a jail. What you<br>
&gt;     gain at one end you lose at the other. It&#39;s like feeding a dog on his<br>
&gt;     own tail. It won&#39;t fatten the dog.<br>
&gt;     - Speech 11/23/1900 Mark Twain<br>
&gt;<br>
&gt;     <a href="http://heretothereideas.blogspot.com/" rel="noreferrer" target="_blank">http://heretothereideas.<wbr>blogspot.com/</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; ______________________________<wbr>_________________<br>
&gt; Ale mailing list<br>
&gt; <a href="mailto:Ale@ale.org">Ale@ale.org</a><br>
&gt; <a href="http://mail.ale.org/mailman/listinfo/ale" rel="noreferrer" target="_blank">http://mail.ale.org/mailman/<wbr>listinfo/ale</a><br>
&gt; See JOBS, ANNOUNCE and SCHOOLS lists at<br>
&gt; <a href="http://mail.ale.org/mailman/listinfo" rel="noreferrer" target="_blank">http://mail.ale.org/mailman/<wbr>listinfo</a><br>
<br>______________________________<wbr>_________________<br>
Ale mailing list<br>
<a href="mailto:Ale@ale.org">Ale@ale.org</a><br>
<a href="http://mail.ale.org/mailman/listinfo/ale" rel="noreferrer" target="_blank">http://mail.ale.org/mailman/<wbr>listinfo/ale</a><br>
See JOBS, ANNOUNCE and SCHOOLS lists at<br>
<a href="http://mail.ale.org/mailman/listinfo" rel="noreferrer" target="_blank">http://mail.ale.org/mailman/<wbr>listinfo</a><br>
<br></blockquote></div></div>