7 ms·

Someone here on HN encouraged others to check out LXD in a previous thread a week ago. I did it and was really blown away. It really did feel like I was running

Someone here on HN encouraged others to check out LXD in a previous thread a week ago. I did it and was really blown away. It really did feel like I was running virtual machines from an extremely fast hypervisor. What mattered to me most was getting away from "1 process per container" mentality. Phusion realized right away that this was an unnecessary constraint and built their base image[0] to help others. With LXD you really get the best of both worlds. You can containerize your applications without having to re-write your entire stack because it also requires cron or a few other processes. Ain't nobody got time for that. 0: https://github.com/phusion/baseimage-docker https://github.com/phusion/baseimage-docker

notsony 11y ago
So should I use LXD or Docker? I just want to package up an app with dependencies and make it easy for others to use/test.
- stephen-mw 11y ago
  Without a doubt use Docker. It has the ecosystem, which is extremely important. It also has the support and community. For devops engineers looking to build an entire enterprise around containers, LXD will be a great option when it reaches maturity and its ecosystem matures. It's not there yet, and probably won't be for a few years. Another great company that's doing extremely cool things with LXC minus Docker is Flockport[0] [0] http://www.flockport.com/ http://www.flockport.com/
  - notsony 11y ago
    So flockport is a competitor to Docker? Seems to do what Docker does. So many choices. CoreOS too . Docker has the momentum and VC$. Hard to really know what the "right" choice is.
- jaytaylor 11y ago
  You could also write an Ansible role for your app which automates the setup and installation. Then installing your app becomes as simple as a single Ansible command without additional dependencies.
  - ossreality 11y ago
    No, no, no.
  - notsony 11y ago
    Is this open-source or do I have to pay? Not clear from the web-site. If I have to coordinate multiple apps (three apps in this system, have to speak with each other over ports) and I want to run each app in its own container, on the same server, or distributed, can Ansible help me? Thanks.
    - jaytaylor 11y ago
      Ansible is FOSS - so yes, open-source and free for you to use. Ansible is an automation tool which lets you create one or more playbooks for automatically configuring and deploying applications. You certainly could use it to automate the configuration of these apps in containers, and for the case of distributed multi-machine arrangement it will improve your life.
- jcastro 11y ago
  If you just want to package an app use docker. The general rule of thumb I use is "Will I need to ssh into this?" If so, LXD. "Am I just running one application?" Docker.
- rdtsc 11y ago
  Use LXD, it is more flexible. Can have application structured as multiple processes so can map VM patterns to it easier, without creating unnecessary containers. Believe you also get better security between containers Also LXC has been in the kernel longer and seems more mature (since 2.6.20-something).
  - stephen-mw 11y ago
    I like LXD a lot, but it's simply too new to rally behind it fully. You have to backport it to Ubuntu 14.04 if you even want to run it on an LTS operating system. That being said, I think Canonical has good vision and will execute. LXD combines the best from old and new school.
  - vezzy-fnord 11y ago
    Also LXC has been in the kernel longer and seems more mature (since 2.6.20-something). LXC in the kernel? It's a userspace toolkit that makes use of kernel technologies (namespaces, pivot_root, cgroups...), but I don't recall it being bundled as a part of it.
    - rdtsc 11y ago
      > LXC in the kernel? Sorry, I meant LXC support. Yeah it is comprised of a set of a features supported by regular Linux kernels + userspace tools. The feature set has been there for a quite a while. > but I don't recall it being bundled as a part of it. But it is in contrast to say OpenVZ which required patching the kernel to work.
altcognito 11y ago
> What mattered to me most was getting away from "1 process per container" mentality. Phusion realized right away that this was an unnecessary constraint It's a necessary constraint because otherwise developers continue to utilize a monolithic application development process. The goal should be isolated, interchangeable processes, not an entire virtual environment. It's just delaying the inevitable. Makes scaling a lot more straightforward as well etc...
- rdtsc 11y ago
  But since they can have only one process they will cram everything in that process. Possibly spawning hundreds of threads with mutexes. Multiple processes on the other hand can encourages fault tollerance and modularization. To put it another way, having just one process doesn't mean it is simpler. I have seen single processes applications built from millions of lines of C++ code.
  - altcognito 11y ago
    Whether you have a single process or not, the "parent" application will responsible for maintaining and executing subprocesses/subroutines. Applications still have the ability to spawn processes with single process containers, you're just doing it through a different OS/process management system. By keeping the multiple processes in the same container, you're likely decreasing modularity by introducing interdependencies via the file system.
    - lukaslalinsky 11y ago
      The thing is, we already have good tools for process management in UNIX-like operating systems. We have cron, process supervisors, systems for log handling. If you need a separate container for every single process you run, you need to get rid of all the standard UNIX tools and start from scratch. The alternatives for docker-style world do not exist yet and where they exist, they are far from stable. So you will end up reinventing them and most likely do it wrong.
      - 11y ago
jacques_chester 11y ago
> What mattered to me most was getting away from "1 process per container" mentality. As I understand, when Garden used to be called Warden, the team looked at the very early versions of Docker. They talked to the Docker team and didn't decide to use Docker as the substrate of Cloud Foundry because of the single-process model. Makes it hard to sideload agents. That said, the next-gen Cloud Foundry guts (Diego) can take Docker images as native currency, so YMMV.

notsony 11y ago

So should I use LXD or Docker? I just want to package up an app with dependencies and make it easy for others to use/test.

stephen-mw 11y ago
Without a doubt use Docker. It has the ecosystem, which is extremely important. It also has the support and community. For devops engineers looking to build an entire enterprise around containers, LXD will be a great option when it reaches maturity and its ecosystem matures. It's not there yet, and probably won't be for a few years. Another great company that's doing extremely cool things with LXC minus Docker is Flockport[0] [0] http://www.flockport.com/ http://www.flockport.com/
- notsony 11y ago
  So flockport is a competitor to Docker? Seems to do what Docker does. So many choices. CoreOS too . Docker has the momentum and VC$. Hard to really know what the "right" choice is.
jaytaylor 11y ago
You could also write an Ansible role for your app which automates the setup and installation. Then installing your app becomes as simple as a single Ansible command without additional dependencies.
- ossreality 11y ago
  No, no, no.
- notsony 11y ago
  Is this open-source or do I have to pay? Not clear from the web-site. If I have to coordinate multiple apps (three apps in this system, have to speak with each other over ports) and I want to run each app in its own container, on the same server, or distributed, can Ansible help me? Thanks.
  - jaytaylor 11y ago
    Ansible is FOSS - so yes, open-source and free for you to use. Ansible is an automation tool which lets you create one or more playbooks for automatically configuring and deploying applications. You certainly could use it to automate the configuration of these apps in containers, and for the case of distributed multi-machine arrangement it will improve your life.
jcastro 11y ago
If you just want to package an app use docker. The general rule of thumb I use is "Will I need to ssh into this?" If so, LXD. "Am I just running one application?" Docker.
rdtsc 11y ago
Use LXD, it is more flexible. Can have application structured as multiple processes so can map VM patterns to it easier, without creating unnecessary containers. Believe you also get better security between containers Also LXC has been in the kernel longer and seems more mature (since 2.6.20-something).
- stephen-mw 11y ago
  I like LXD a lot, but it's simply too new to rally behind it fully. You have to backport it to Ubuntu 14.04 if you even want to run it on an LTS operating system. That being said, I think Canonical has good vision and will execute. LXD combines the best from old and new school.
- vezzy-fnord 11y ago
  Also LXC has been in the kernel longer and seems more mature (since 2.6.20-something). LXC in the kernel? It's a userspace toolkit that makes use of kernel technologies (namespaces, pivot_root, cgroups...), but I don't recall it being bundled as a part of it.
  - rdtsc 11y ago
    > LXC in the kernel? Sorry, I meant LXC support. Yeah it is comprised of a set of a features supported by regular Linux kernels + userspace tools. The feature set has been there for a quite a while. > but I don't recall it being bundled as a part of it. But it is in contrast to say OpenVZ which required patching the kernel to work.

altcognito 11y ago

> What mattered to me most was getting away from "1 process per container" mentality. Phusion realized right away that this was an unnecessary constraint It's a necessary constraint because otherwise developers continue to utilize a monolithic application development process. The goal should be isolated, interchangeable processes, not an entire virtual environment. It's just delaying the inevitable. Makes scaling a lot more straightforward as well etc...

rdtsc 11y ago
But since they can have only one process they will cram everything in that process. Possibly spawning hundreds of threads with mutexes. Multiple processes on the other hand can encourages fault tollerance and modularization. To put it another way, having just one process doesn't mean it is simpler. I have seen single processes applications built from millions of lines of C++ code.
- altcognito 11y ago
  Whether you have a single process or not, the "parent" application will responsible for maintaining and executing subprocesses/subroutines. Applications still have the ability to spawn processes with single process containers, you're just doing it through a different OS/process management system. By keeping the multiple processes in the same container, you're likely decreasing modularity by introducing interdependencies via the file system.
  - lukaslalinsky 11y ago
    The thing is, we already have good tools for process management in UNIX-like operating systems. We have cron, process supervisors, systems for log handling. If you need a separate container for every single process you run, you need to get rid of all the standard UNIX tools and start from scratch. The alternatives for docker-style world do not exist yet and where they exist, they are far from stable. So you will end up reinventing them and most likely do it wrong.
    - 11y ago

jacques_chester 11y ago

> What mattered to me most was getting away from "1 process per container" mentality. As I understand, when Garden used to be called Warden, the team looked at the very early versions of Docker. They talked to the Docker team and didn't decide to use Docker as the substrate of Cloud Foundry because of the single-process model. Makes it hard to sideload agents. That said, the next-gen Cloud Foundry guts (Diego) can take Docker images as native currency, so YMMV.