I've pieced together a test server to audition the new v6 betas, and have been playing with dockers AND plugins for my BIG3 (sabnzbd/sickbeard/PLEX)....and I've also been looking at Sonarr and nzbget.

 

First thing I noticed- my sickbeard plugin doesn't seem to want to start automatically- which is what ultimately led me to try dockers & Sonarr.  As a docker, all the programs start fine on the first attempt. 

 

I'm not one to experiment with my setup once it's running, so I prefer the option which will result in the least maintenance and the easiest repair.  I like my concept of a docker- which is a single 'file' that I could, in theory, COPY/BACK-UP to preserve a running app setup.....useful for those times when I've just exploded a working setup either by upgrade or stupidity.  (The thought that I could simply restore a single file and revert to a working setup- is VERY appealing.  But that's MY CONCEPT of a docker- which may be wrong!  I say all that to convey my level/lack of expertise and to frame my question.

 

 

Which is better- docker or plugin? 

 

[glow=red,2,300]Conclusion- based on two particularly relevant responses:[/glow]

 

VMs are heavy. They take a lot of resources, because they run a whole OS.

Dockers are lighter since they re-use the OS, but bundle all the dependencies.

Plug-ins are lightest, but conflicting dependencies will block/break others.

 

[glow=red,2,300]Secondly, [/glow]

 

Your concept of Dockers is wrong. You don't have a Docker file you can save with the setup.

You map a directory on the server into the Docker and the application will save the settings into this directory.

 

Thanks to everyone that responded

Don't forget VMs

It's really based on what you want to do or be able to do. If you want to run Plex, you have the option of installing it as a Docker container which would run Plex and only Plex or you can create a VM which would run Plex but give you the option to do other things such as a mail server or Plex Media Server with video card passthrough.

VMs are heavy. They take a lot of resources, because they run a whole OS.

Dockers are lighter since they re-use the OS, but bundle all the dependencies.

Plug-ins are lightest, but conflicting dependencies will block/break others.

 

The best is the one you need, which works.

Is there a significant difference in processor loading between docker & plugin?  My server's processor speed seems to be a limiting factor moreso than memory or drive space.

 

And is my concept of a docker correct?  [Can] I save a single docker file and in doing so, save a plug-and-play, working configuration of, say, Sickbeard?  Because I would really like to be able to save 'snapshots' of my apps on-occasion

I don't think there is much advantage processor wise for either.

 

Your concept of Dockers is wrong. You don't have a Docker file you can save with the setup. Well, I suppose you could build a docker with all the setup hard coded inside, but then it can't be shared or used with anyone else.

 

You map a directory on the server into the Docker and the application will save the settings into this directory. You can map more directories for the output from the docker if that is required. So, you have a docker which runs to perform the task with the setup data stored in a directory on the server. So, if you save that directory setup data you can just point a re-installed docker at the data and restore whatever you had before.

 

It's like a smaller version of you mapping a server share on your PC and then having an application on your PC use the mapped drive. You PC might have a directory called M: which more or less appears to be a local drive, but it's really just a link to the Movies share on your server.

 

 

One other thing - there are some official dockers for certain applications and they're the best choice if they exist. For example, I use the MediaBrowser Server docker that comes  from the MediaBrowser team because it's the official up to date release and not the template'd docker created by a user here because it can be out of date unless that user updates it.

Docker is the way forward.  Period.

 

Running a VM on top of unRAID just to run something like Sickbeard is a total waste of time and resources.

Docker is the way forward.  Period.

 

Running a VM on top of unRAID just to run something like Sickbeard is a total waste of time and resources.

Agreed that running a full VM just for one app is dumb. However... some of us run most or our apps in one VM. Whether or not this is better or worse than multiple dockers is a personal preference thing.

Docker is the way forward.  Period.

 

Running a VM on top of unRAID just to run something like Sickbeard is a total waste of time and resources.

 

Careful with statements like these. The same can be said for running dockers on top of an OS. If unraid had a base OS with a package manager and community support like ubuntu or debian, then running a docker is more trouble than doing "apt-get packagename".

Docker is the way forward.  Period.

 

Running a VM on top of unRAID just to run something like Sickbeard is a total waste of time and resources.

 

Careful with statements like these. The same can be said for running dockers on top of an OS. If unraid had a base OS with a package manager and community support like ubuntu or debian, then running a docker is more trouble than doing "apt-get packagename".

But doing apt-get is more risky and more limiting than docker or vms.

 

By using apps in the native OS, you can have software dependency conflicts and you are limited to app selection made available within that particular distro.

 

With Docker and VMs we can install any app from any OS, control its access to system resources like memory and CPU (far easier and better than native apps), we can keep applications running in isolated operating environments preventing software conflicts due to things like dependencies, we can increase the ease of installing a wider array of apps, and if we want advanced capabilities with hardware, we can use VMs with PCI pass through to supply drivers for that hardware independent of our OS.  All from an OS that is ~ 90mb compressed. Apt-get ain't got nothing on this!!

@jonp, my point was throwing out such dismissive statements as that isn't the full picture. That is all. I guess that point was missed.

 

I'm not going to get into the discussion as to merits of VMs vs Dockers vs Plugins vs Packages again. Each has their own pros and cons. It's a good thing that unRAID allows the choice of such up to each individual user. I appreciate the effort that LimeTech has put forth in these areas.

 

 

@jonp, my point was throwing out such dismissive statements as that isn't the full picture. That is all. I guess that point was missed.

 

I'm not going to get into the discussion as to merits of VMs vs Dockers vs Plugins vs Packages again. Each has their own pros and cons. It's a good thing that unRAID allows the choice of such up to each individual user. I appreciate the effort that LimeTech has put forth in these areas.

 

My point was that running a single headless app (like Sickbeard) inside a VM is technically a waste of resources because there is a viable alternative (Docker) that makes it easier to install, consumes less resources, but doesn't force you to give up the benefit of application isolation or OS independence.

 

With apt-get, your are trading out that control for chroot which still isn't perfect and puts back the OS limits.

 

My point in counter was simply that Docker doesn't force the same level of sacrifice (not even close) as an apt-get method would when both are compared to VMs.

 

Let's also not forget the bloat that would have to go into our base OS to move to another platform.

And my point still is throwing out blanket statements as to what is best for everyone without taking their individual needs into consideration as if it is fact and an end all be all, really shouldnt happen.

 

Not that you had or did, but that HellDiverUK did.

And my point still is throwing out blanket statements as to what is best for everyone without taking their individual needs into consideration as if it is fact and an end all be all, really shouldnt happen.

 

Agreed.  This is one of the big benefits of the way we're building the platform.  Each component (plugins, containers, and VMs) have their place for providing various levels of functionality (plugins = core, containers = headless linux apps, vms = everything else).  However, if someone just wants to use VMs for everything because that's what they are used to, go for it!  If you want to do everything Docker and no VMs at all?  You got it!  Want a traditional NAS that doesn't run any apps?  Got that too!

 

No one should be prescribing a specific use of the technologies we've included as the only way to do things.  That said, for newcomers that are looking to be guided, HellDiverUK is probably right, and they should start with Docker for apps like Sickbeard because it's the easier / fastest way to get going.  Once a newcomer is experienced enough with our solution and all the various tools we provide, they can decide for themselves what is the best approach to managing apps.

 

Hell, someone could setup a Docker container for Sickbeard, use it for months, wake up one day and say, "you know what, I want an Ubuntu VM for all this stuff."  They could then set up a VirtFS mapping to the same appdata folder they used with their container and very likely have a running Sickbeard with no reconfig (being moved from Container to VM without a reconfigure of the app settings).

 

I guess my whole point in replying to begin with was to point out that the apt-get method you mentioned, while a neat way to install apps, isn't the best solution to just run them.  They call it docker run for a reason ;-)

Yeah, I agree, it's horses for courses.

 

I run a few dockers and a VM for other stuff and I can see me running webserver stuff and reverse proxy stuff on a VM when I get a chance instead of using dockers.

 

Pick the best tool for the job and all that.

Aguing about about app-get when talking unRAID is pointless. There is no application manager and when you consider how unRAID is customized to run from a flash drive, even if Slack had a package manager it wouldn't work.

 

Plugins are unRAID specific and rely on the developer to keep it up to date. The often end-up left unsupported and they also get broken with unRAID updates.

 

You can go to the Docker repository and pick any docker you want. When you consider how they are universal, the chances a docker for a specific application stays up to date are much more likely.

 

A VM can be very useful if someone wants to run more complex applications or a lot of applications.

 

One point I have not seen emphasised directly in this thread is that plugins (although supported) are now effectively deprecated for apps.  This is implied by the tone of the answers but not explicitly stated. 

 

With v6 plugins should only really be used for the core system level functionality that is provided by LimeTech who will have resolved all dependency issues (the big downside of plugins).  LimeTech is using plugins as a way of upgrading specific core components without the need to make a full release leading (at least in theory) to a more modular upgrade approach.