Which is better and why?

[bellevillerc]

Newb question here...

 

So if there are apps such as sickbeard, plex, sabnzbd ect that can be ran as a plugin, then what is the benifits of using in docker instead?  Which is better and why? For what reason?

 

Thanks

 

Pete

[sureguy]

Plugins often cause unRAID to not fully boot in my experience (the system is waiting for the plugin to finish starting) , dockers shouldn't exhibit this behavior.

[bellevillerc]

That is a plus...

 

Anyone else have plus/minus'

 

Thanks,

 

Pete

[jonp]

Docker apps tend to consume less memory than their plugin equivalents.  I actually did a comparison test with a bunch of pHaZe plugins against docker container equivalents and was shocked to see that both at boot and after each container was started that docker consistently used less RAM than when compared to the plugins. Seems backwards for virtualization, but its true!!

 

[NAS]

A plugin can explode and cause system wide failure. When a docker container explodes it is isolated.

[bellevillerc]

I like that answer!

[gfjardim]

A plugin can explode and cause system wide failure. When a docker container explodes it is isolated.

 

Not completely right. Most of us think about Docker as a kind of virtualization, and that's not true.

 

Docker relies on something called "Namespaces" or "control groups" to isolate processes. But, in unRAID, both storage processes (emhttp, shfs, samba, nfsd, afp etc..) and docker run without any control group resource reservation, so a memory leak in one container can potentially consume all resources from the computer, and that can lead to a forced process exit (OOM kernel panic).

 

I've never experienced nothing like that in my system, but it's a possible scenario. Nevertheless, containers are a lot safer than their plugin counterparts.

[jonp]

Docker is a kind of virtualization.  It just isn't for virtual machines. Docker isn't a hypervisor either.  However, it most certainly is a method of virtualization.

[gfjardim]

Docker is a kind of virtualization.  It just isn't for virtual machines. Docker isn't a hypervisor either.  However, it most certainly is a method of virtualization.

 

It's a software virtualization: http://en.wikipedia.org/wiki/Operating_system%E2%80%93level_virtualization

 

When we speak about virtualization, 99% of users think about hardware virtualization (Xen, KVM, VMware, Hyper-V etc...). Because of that, I don't like to call it that way.

[jonp]

Virtualization permeates all technology.  We have VPNs (virtual private networks), virtual disk drives, virtual network cards, and more.  The folks that translate the term virtualization to mean virtual machines is like saying all operating systems are just Windows.

 

Edit:  not the greatest analogy.  I'll post a better one later.  Nonetheless, don't worry about it ;-)

[NAS]

A plugin can explode and cause system wide failure. When a docker container explodes it is isolated.

 

Not completely right. Most of us think about Docker as a kind of virtualization, and that's not true.

 

Docker relies on something called "Namespaces" or "control groups" to isolate processes. But, in unRAID, both storage processes (emhttp, shfs, samba, nfsd, afp etc..) and docker run without any control group resource reservation, so a memory leak in one container can potentially consume all resources from the computer, and that can lead to a forced process exit (OOM kernel panic).

 

I've never experienced nothing like that in my system, but it's a possible scenario. Nevertheless, containers are a lot safer than their plugin counterparts.

 

Yes but for the interests of the question the original one line answer was enough. (although be be fair I could have added the word "mostly")

[gfjardim]

A plugin can explode and cause system wide failure. When a docker container explodes it is isolated.

 

Not completely right. Most of us think about Docker as a kind of virtualization, and that's not true.

 

Docker relies on something called "Namespaces" or "control groups" to isolate processes. But, in unRAID, both storage processes (emhttp, shfs, samba, nfsd, afp etc..) and docker run without any control group resource reservation, so a memory leak in one container can potentially consume all resources from the computer, and that can lead to a forced process exit (OOM kernel panic).

 

I've never experienced nothing like that in my system, but it's a possible scenario. Nevertheless, containers are a lot safer than their plugin counterparts.

 

Yes but for the interests of the question the original one line answer was enough. (although be be fair I could have added the word "mostly")

 

That's why I used "Not completely right.". Mostly, but not completely right. 

 

Obviously, you're right. It was a comparison, plain and simple. 

[jonp]

Well, I disagree... its mostly, almost, pretty much, right....  Like yah know, 60% of the time its right every time...

[dmacias]

 

 

Docker apps tend to consume less memory than their plugin equivalents.  I actually did a comparison test with a bunch of pHaZe plugins against docker container equivalents and was shocked to see that both at boot and after each container was started that docker consistently used less RAM than when compared to the plugins. Seems backwards for virtualization, but its true!!

 

Could that be because the plugins load all their depends to the unraid file system which is in ram?  One plus for docker is you don't have to load all those dependencies for you plugins. So faster boot times. The dockers are usually on an ssd or spinner.

[jonp]

 

 

Docker apps tend to consume less memory than their plugin equivalents.  I actually did a comparison test with a bunch of pHaZe plugins against docker container equivalents and was shocked to see that both at boot and after each container was started that docker consistently used less RAM than when compared to the plugins. Seems backwards for virtualization, but its true!!

 

Could that be because the plugins load all their depends to the unraid file system which is in ram?  One plus for docker is you don't have to load all those dependencies for you plugins. So faster boot times. The dockers are usually on an ssd or spinner.

That is exactly why. The only elements loaded into actual RAM with Docker apps are the primary running apps themselves.

[lionelhutz]

I have run a number of apps on my server since v4.7 days before plug-ins even existed and I run some with plugins now and I have never had them cause a single system wide failure on my server.

[jonp]

I have run a number of apps on my server since v4.7 days before plug-ins even existed and I run some with plugins now and I have never had them cause a single system wide failure on my server.

There are many who have had the exact same experience as you, but there have been others that have had issues.  Quite frankly, its also a lot less work to build / maintain a docker container than a plugin.

 

Containers enable us to skip the process of "installing" applications and go directly to running them.

[lionelhutz]

Well, yes the whole philosophy of having unRAID run by unpacking the file system into ram makes it very difficult to install anything new to the base OS, so the Docker containers become an easier way to get around that whole issue. The popular Docker apps in the stick thread won't update themselves so it's not perfect either.

[NAS]

... The popular Docker apps in the stick thread won't update themselves so it's not perfect either.

 

We have to be careful with stuff like that. Whilst you are exactly right I dont think it tells the real story

 

I paraphrase for brevity...

 

The idea of a docker is that you build once and deploy something many times that is known to work. So if it works for me it will work for you even if our hardware and environment is completely different.

 

With this model you do not want it to be patched on random install as this will start to create non identical instances and in turn things may break.

 

This is the bit you refer to.

 

However what should happen is the original dev patches, tests and deploys a whole new container. This way you get the patches in a known working state again.

 

Now this is not done very well "yet" in docker land and some effort has been made by this community to inform users of updates but its still not slick.

 

But my prediction is in the not to distant future making this slicker will be a big focus of docker.

 

Something else to consider. The current addon system relys on every addon dev working as a team or at least being sensible. This is because I can install a dependency that breaks someone addons etc we handle this quite well this now because we are a samll community with a small amount of addon and active devs... but it simply doesnt scale well. Docker containers completely remove this entire problem. We should not underplay this advatage as we have seen this sepcific problems many many times.

[garycase]

Docker is a kind of virtualization.  It just isn't for virtual machines. Docker isn't a hypervisor either.  However, it most certainly is a method of virtualization.

 

Largely a question of semantics.  OS "virtualization" is the new buzz-phrase to describe multiple namespaces that provide a LOT of the isolation of virtual environments ... but not all.    A true hypervisor-based virtual machine is definitely "safer" than the container approach in terms of potential for bringing down the host; but I agree that Docker does an excellent job of minimizing this risk.    I'm an old school purist -- to me virtualization means a hypervisor with a truly isolated OS.    But I understand the newer uses of the term 

[dmacias]

I will say this and it's the reason I run kvm vm's now instead of dockers. I also moved to kvm from xen because you can map directories in kvm like in docker and not have to rely on xen networking. I had on occasion had a docker not be able to shutdown and thus not be able to stop the array. Had to go to the command line to kill it and shut down via powerdown. Never had a problem shutting down the vm's.