Hacker News Reader

Comment by stephen-mw | Hacker News Reader

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

View on HN

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.

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/

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.

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.

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.

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.

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.

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).

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.

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.

> 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.

> 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...

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.

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.

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.

I agree with most of your statement, except the part about "good tools" and the assumption that it will be done wrong forever. Mistakes will be made, but current nix tools aren't really anymore ready for the distributed paradigm.

What I meant is that the current Docker-based solutions are often done without much experience. I'm certainly not against experimenting, but I think that that there are many benefits of running a containerized environment and LXD takes the pragmatic approach that can be used right know with the tools everybody knows.

> you're likely decreasing modularity by introducing interdependencies via the file system.

Unless dependencies are already there. Then needlessly separating them into containers just makes the system have a higher overhead and have a higher fragility.

Say should the monitoring software be in a different conainter? But it looks at logs, so now it needs to mount a shared folder or coordinate sending logs via sockets. Or maybe it is a helper process. Like an indexer. Putting that in a separate container with its isolated OS dependencies might not make sense. It requires to reading from the file structures of the main process.

> you're just doing it through a different OS/process management system.

There is already software that does it. It is init, systemd and others. You can specify if restart on failure should happen, can specify dependencies between then and so on.

> Unless dependencies are already there. Then needlessly separating them into containers just makes the system have a higher overhead and have a higher fragility.

Advantages to the Docker approach are that the dependencies are explicitly exposed and you can homogenize your file systems. Ideally you're getting rid of using files in the first place. Unless you're using local storage on AWS, you're already going over the network.

> There is already software that does it. It is init, systemd and others.

It's hard to disagree that the old systems aren't more mature. They aren't as ready for distributing processes though. And that's where most everything is headed anyway.

> Or maybe it is a helper process. Like an indexer.

This is the motivation for the concept of pods that appears within rkt and kubernetes. Things like indexers, monitoring agents, service discovery ambassadors, syncers for static content file servers, etc. There are a number of use cases for multiple processes that live side-by-side and share a lifecycle. And these containers don't need to be coupled but it is nice if they can share a localhost interface and paths on a filesystem.

If you want to have a single process that you care about, there is this thing called a process that fits the bill admirably. You can start them up very quickly, and kill them when you don't need them.

I think Docker is a great tool, but I also think the perceived benefits it brings get discussed a lot more often than the complexities it introduces.

Pushing your complexity to different parts of your stack does not reduce it - it just moves it. In many cases, that's perfectly fine and works better - but it's no panacea.

> 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.

Reply on news.ycombinator.com