Topics on the Merits and Downfalls of Containerization



  • So in this article the author describes what he feels to be a rather poor approach by pretty much all current IT personal in the world, excluding Containerization Experts.

    Do you folks agree with what the author is saying?





  • I think his points are valid and the same gotchas that seem to accompany any new technology that directly impacts an industry at such a scale.



  • Overall yes, I would agree. Containers are all hype right now. It's great technology but technology we have had for a long time and is super useful when used correctly. When abused it is just ridiculous. Containers are a bit too complex for average SMBs and are going to do bad things in the enterprise as well as in the SMB. People who need containers probably have been wanting them or even using them for a while.

    His thoughts about the ability to allow legacy apps to linger for forever without maintenance is a big deal and a great thing to think about.



  • I think the article comes across as cynical... but he does make a few good points -- especially about keeping legacy applications around... But you can do that with Virtualization too... not much difference.

    I haven't gotten around to deciding whether or not I like Containers yet... I'm struggling to see the benefits vs using VMs + Puppet / Chef / Ansible, et al.



  • To play the devils advocate here: If an application so valuable must be built into a container (such as Docker) and you build it on Ubuntu for example, wouldn't maintaining it be very simple.

    You download it and go. Download the updated one and go. Rinse and Repeat as the software is updated. Yes the old version is there, but why wouldn't you update if you had it there.

    This seems a lot like "you're building Frankenstein, by allowing an application to be around well past the supported OS has gone."



  • @DustinB3403 said:

    To play the devils advocate here: If an application so valuable must be built into a container (such as Docker) and you build it on Ubuntu for example, wouldn't maintaining it be very simple.

    Not if designed properly. Or should I saw "as designed."



  • @DustinB3403 said:

    You download it and go. Download the updated one and go. Rinse and Repeat as the software is updated. Yes the old version is there, but why wouldn't you update if you had it there.

    Because containers are not designed to be logged into or updated. It's conceptually not how they are meant to be used. So you would need people mistreating them as VMs and really defeating the purpose in order to make that possible and then you'd have to ask... why are we doing this?



  • By "maintained" I mean, you go and download the updated container and be done with it.

    You'd simply delete the "old" one.



  • @DustinB3403 said:

    By "maintained" I mean, you go and download the updated container and be done with it.

    You'd simply delete the "old" one.

    Oh okay. That works fine in scenarios where you are deploying code containerized by others. Everyone I've worked with deploying Docker is using it to deploy their own code.



  • @scottalanmiller said:

    @DustinB3403 said:

    You download it and go. Download the updated one and go. Rinse and Repeat as the software is updated. Yes the old version is there, but why wouldn't you update if you had it there.

    Because containers are not designed to be logged into or updated. It's conceptually not how they are meant to be used. So you would need people mistreating them as VMs and really defeating the purpose in order to make that possible and then you'd have to ask... why are we doing this?

    I know Docker is that way, but I don't think that's how LXC is designed to be used. You set up the container and use either lxc-attach or lxc-console to connect to a tty.



  • Correct, LXC is an old, traditional container like we've used for a decade or more and is just like any other VM technology. You can ignore that it is a container 🙂



  • I think for SMB and some other places LXC, jails, and zones make sense. However Docker does seem like it would be more work than it's worth.

    I've heard Rocket is supposed to be easier than Docker, but I haven't had a chance to play with it (or really had a reason to).



  • @johnhooks Docker is great for DevOps shows and totally built for them. Zones, Jails and LXC are for big UNIX admins to use for super high performance VMs. 🙂



  • Yup, I have heard that about Rocket but have not had a chance to look at it. Can't wait for the lab to be up!!



  • @scottalanmiller said:

    @johnhooks Docker is great for DevOps shows and totally built for them. Zones, Jails and LXC are for big UNIX admins to use for super high performance VMs. 🙂

    It seems like lxc & family are soon to get live migration as well...



  • Yeah, some definitely will.



  • @scottalanmiller said:

    Yeah, some definitely will.

    I wonder what that will do against Virtualization platforms like XenServer, VMware, et al...

    if an lxc-container is functionally equivalent to a VM... Would it be possible to run Windows in an lxc-container... That type of thing.



  • @dafyre said:

    @scottalanmiller said:

    Yeah, some definitely will.

    I wonder what that will do against Virtualization platforms like XenServer, VMware, et al...

    if an lxc-container is functionally equivalent to a VM... Would it be possible to run Windows in an lxc-container... That type of thing.

    No, we've had those containers for a decade and we are nowhere near having Windows in them. They all share the parents' kernel by definition. So no Windows coming on Linux containers. Much closer to PV Windows on Xen, at least that has been done in a lab.



  • @scottalanmiller said:

    No.... They all share the parents' kernel by definition.

    So does the container get the same security updates that the host is due for? What if one of those updates is a newer version of the contained application?



  • @scottalanmiller said:

    @dafyre said:

    @scottalanmiller said:

    Yeah, some definitely will.

    I wonder what that will do against Virtualization platforms like XenServer, VMware, et al...

    if an lxc-container is functionally equivalent to a VM... Would it be possible to run Windows in an lxc-container... That type of thing.

    No, we've had those containers for a decade and we are nowhere near having Windows in them. They all share the parents' kernel by definition. So no Windows coming on Linux containers. Much closer to PV Windows on Xen, at least that has been done in a lab.

    What about Containerization on Windows? Didn't OpenVZ or Virtuozzo...used to offer something like that?



  • @DustinB3403 said:

    @scottalanmiller said:

    No.... They all share the parents' kernel by definition.

    So does the container get the same security updates that the host is due for? What if one of those updates is a newer version of the contained application?

    No, the DevOps model, and by extension the Docker model, is that the containers never get updates, never change. They are disposable. You replace them, you do not update or maintain them. Same as Devops with Vms.



  • @dafyre said:

    @scottalanmiller said:

    @dafyre said:

    @scottalanmiller said:

    Yeah, some definitely will.

    I wonder what that will do against Virtualization platforms like XenServer, VMware, et al...

    if an lxc-container is functionally equivalent to a VM... Would it be possible to run Windows in an lxc-container... That type of thing.

    No, we've had those containers for a decade and we are nowhere near having Windows in them. They all share the parents' kernel by definition. So no Windows coming on Linux containers. Much closer to PV Windows on Xen, at least that has been done in a lab.

    What about Containerization on Windows? Didn't OpenVZ or Virtuozzo...used to offer something like that?

    You can, in theory, make Windows containers on Windows. But you have to be on Windows already.