"Containers isolate and encapsulate your application workloads from the host system. Think of a container as an OS within your host OS in which you can install and run applications, and for all practical purposes behaves like an virtual machine. Containers decouple your applications from the host OS."
Wrong wrong wrong. Containers do not encapsulate (in the security sense). You can get some security by layering SELinux underneath, but you're still wide open to a range of kernel exploits. A container is not "an OS within [an] OS". Containers do not "for all practical purposes behave like a VM" since you can't run another kernel, BSD, Windows, etc on them. Containers do not decouple your app from the host OS, you are very much dependent on features compiled into your host kernel. Subtle userspace<->kernel ABI regressions will cause you days of debugging (I've been there several times).
"[VMs] .. at a performance penalty and without the same flexibility"
After boot, there's almost no difference in performance. Boot time is a huge factor, but don't confuse the two.
Containers have their place, are useful and very fast to provision, when you understand and accept their limitations (as many do), but don't spread nonsense like this.
Hi, I am the author of the article. It does not state containers encapsulate applications from a 'security sense'. You make a point which is not stated to draw conclusions which were not made.
It states 'Containers decouple your applications from the host OS, abstracts it and makes it portable across any system that supports LXC'. You can run the app in the container in any other system that supports LXC, isn't that what decoupling is?
I think you are looking at this from a technical perspective and not an end user perspective. Why don't you download and try some of the Flockport containers available on the website, those apps are decoupled from your Linux OS and will work in any LXC environment.
This is an article about containers for end users, not technical users, to help them understand the concept of containers and how LXC differs from Docker.
If security, multi-tenancy, running other OS's or specific kernels are your core use cases, virtualization makes more sense as is stated a few paragraphs below that quote, and in the LXC getting started guide on the same site.
You're right. It's more like a docker philosophy or best practice, not a restriction. And a best practice not everybody agrees on that is [1][2]. I'm using some docker containers based on Phusions base image myself. It works fine. Others of my containers are just running one process. I found it feels like a cleaner architecture when I manage to bundle concerns in a way so the resulting containers are stateless. But when I don't achieve that I don't pull my hair out over it. Whatever floats your boat.
This seems like a selective quote (and it's certainly not a direct quote), because later in the post, the author mentions (albeit somewhat offhandedly) that it's possible to run multiple processes using a supervisor (supervisord, etc) or a shell script.
Although I don't think that's completely wrong as I'm under the impression from my limited experience with Docker that it's intended to containerize applications rather than work analogously to, say, FreeBSD jails.
No they're not __restricted__ at all, you can certainly run multiple apps in a single container.
It is accurate to say Docker is focussed on the deployment of a single app per container. But the article does repeat it that it is single process.
The difference to be honest has really got thing to do with what you can do but what your aim is.
You can put sshd in your docker container, you can run init scripts. All these things are perfectly easy to do. It's just as a rule that's not your focus when working with Docker.
Again I think the article is misleading in this way.
Hmm, thought for sure I'd searched your exactly quote, but I apologize that I missed it.
It seems the author of the article in question replied to my comment as well, and it's worth noting because his intent is (more or less) what I got out of reading the post [1]. I don't find it misleading. I think your point of contention may therefore be with the interchange between application and process as synonyms throughout the post. By implication, I took it to mean application in the context of a single cohesive unit (maybe not just simply a process, though it can be) that is run via a supervisor or alone.
(That said, using LXC directly is something of an exercise in frustration as the CLI tools are a bit... kludgy--Docker is far more polished.)
> You can put sshd in your docker container, you can run init scripts.
I seem to recall that running sshd from a Docker instance isn't exactly the intended use case of Docker [2] and is generally frowned upon.
Hi Zancarius, my apologies, I mistakenly replied to you when it was intended for neilellis.
Imho if your use case is not statelessness and you need a container as a lightweight VM, LXC tools are actually quite simple and easy to use.
Nielellis - I am sorry you feel the article is misleading. It describes the default behavior. The default Docker template has limitations, that the user should be aware or you get questions like this - http://stackoverflow.com/questions/21280174/docker-centos-im...
Docker base template is not a multi process multi app environment, it executes the application specified on the docker command line and exits. Which is why you can't run apps in daemon mode and have to explicitly disabled, and need a separate process manager.
'Docker restricts the container to a single process only. The default docker baseimage OS template is not designed to support multiple applications, processes or services like init, cron, syslog, ssh' When it comes to applications for a LAMP container you would need to build 3 containers that consume services from each other, a PHP container, an Apache container and a MySQL container. Can you build all 3 in one container? You can, but there is no way to run php-fpm, apache and mysqld in the same container without a shell script or install a separate process manager like runit or supervisor."
It's all in the same paragraph. There is no attempt to mislead. This is how Docker works.
This article is not meant to trash Docker and I urge readers not to read it as such. It does not do that.
I have tons of respect for Docker, and any project involving hundreds and thousands of man hours of effort. It's an interesting use case of containers to build stateless applications, but its a single use case.
While researching this piece I came across significant confusion online including by technically minded folks and entire projects that persistently misrepresent LXC as 'low level kernel capabilities' or Docker as a 'front end user friendly' interface to LXC.
This kind of confusion does a disservice to both projects by not articulating Docker's core stateless benefits on top of normal LXC containers and misrepresent the LXC project, and undermine informed discussion on Linux containers.
> Docker restricts the container to a single process only.
> When it comes to applications for a LAMP container you would need to build 3 containers that consume services from each other, a PHP container, an Apache container and a MySQL container.
While people contemplate things like containers, it's worth noting that modern hardware virtualization imposes a performance overhead of low single digital percentage points, and with some technologies like deduplication of storage and memory can paradoxically improve performance over bare metal in many scenarios.
Containers are interesting and the technology is emerging, but for 1-2% overhead it just isn't as critical as its often held.
You may nave a point, but you're making up numbers and forget other scenarios. How much ram and HD overhead there is to virtualize ping? How much time do I need to spawn the vm? Vms are great, but there are problems better solved by containers. Use both.
Why would anyone ever virtualize or containerize ping? In the real world, we use containers for largely the same things that we use virtualization -- the web server, the database server, the VPN host, and so on. The overhead is negligible to begin with-
-but with de-duplication of a solution like vmware, approaches 0.
Containerization seems like a massive win when you're trying to fit a bunch of stuff in a single Digital Ocean VM, etc. When you're running many machines in a data center, though, it becomes dramatically less valuable.
Ping is actually an excellent candidate for virtualization/containers/SELinux since it has to run as root. A bug in ping could mean a carefully crafted response could lead to a remote exploit. There are obviously also a number of local exploits that take advantage of setuid binaries like ping: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-2851
Come on... ping was obviously chosen as a ludicrously simple example. You'd never containerize ping. But you could imagine some simple user application that would be easily deployed as a container, but that would be horrible overkill to wrap in a virtual machine.
You're right that once you've hit rack levels of virtualization, you've already hit the management overhead requirements to use VMs.
In my mind, it isn't about processing or IO overhead. It's about the overhead for management. It's a trade-off. Some applications are better managed as whole systems (VMs), whereas others are more building block-ish and probably better as containers. The two technologies are pretty complimentary.
Hardware virtualized I/O is a thing now as well, and in that case as well the overhead has shrunk to marginal. Add external storage (iSCSI), and things get much more complex.
Much of the argument about virtualization is about ten years+ old. It once represented a significant additional overhead, but that simply isn't true at all now.
Looking at it from a public cloud perspective, I doubt we'll ever be able to use SR-IOV. By the time a particular function has been driven into hardware there are new functions we need that aren't in hardware, like sophisticated overlay networking.
