Should Plex and Emby be moved over to docker rather then jails...thoughts?

[Stux]

Docker on FreeBSD is a non starter.

Docker is an LXC based technology which exposes the host kernel to the docker containers own user land (which is shared with other containers, and inherited etc)

The key is the one thing you don't change in a docker container is the host kernel. It has to be Linux, or it won't work with all the docker images out there.

Docker for FreeBSD is probably jail based and uses the docker suite to do the same thing as docker, but docker it is not.

And Dan, the neat thing with docker is a container is disposable and cheap, in much the same way that snapshots and clones are to ZFS. The only piece of persistence you need is the docker file. Which is just a recipe to spin up a new instance, including all the inherited images.

Then mix in cheap image caching and cloning. In fact on Linux, docker can use ZFS as a backing store and when you download an image, it will use ZFS clones to clone it for an inherited image.

The true pity is that Linux docker on FreeBSD can't (currently) hit up ZFS for its shenanigans.

 

[danb35]

You're behaving like a petulant child,

This must be that "civil discussion" that @Magnus33 says everyone here (but me) is having. Good to know.

@Magnus33 is proposing Docker as a replacement for jails and/or plugins. Presumably he believes this is something that could or should happen in the relatively near term, not n years down the road if/when Docker on FreeBSD becomes stable. If so, then the fact that Docker runs on FreeBSD in an "experimental" status hardly seems relevant--if we're wanting to make a change in the near term, we're going to want to use a production-ready technology to do so. That means Docker on Linux, and that means a VM--and that means my points remain valid.

...and if you agree with all that, what was your point in mentioning Docker on FreeBSD in the first place?

 

[danb35]

the neat thing with docker is a container is disposable and cheap, in much the same way that snapshots and clones are to ZFS.

I can see how that could be handy in the abstract, but what does it bring to the party in the application under discussion? I don't think I want my media server to be disposable. I want to install it and let it do its thing, with as little manual maintenance as possible (I'm not particularly concerned about maintenance that can be automated, as long as it doesn't interfere with my use of the app). Being disposable doesn't seem to provide any benefit.

But what I think I'm starting to understand is that the dockerfile could be used, in a sense, as the plugin. The dockerfile would be prepared identifying what packages are needed, specifying where configuration data would be saved, and whatever other configuration details would be relevant/appropriate, and distributed in some repository. Users would download the dockerfile, and Docker would automagically do the rest. And that way, nobody needs to build a .pbi whenever a new release of something comes out (the "porting" that @Magnus33 keeps mentioning and incorrectly attributing to jails as a whole). Yeah, that would be a benefit.

But isn't that what iocage is supposed to do?

 

[zhnu]

Docker runs on FreeBSD in an "experimental" status hardly seems relevant

But isn't that what iocage is supposed to do?

Iocage is also experimental.

@Magnus33 is proposing Docker as a replacement for jails and/or plugins

You can have both there's no technical limitation there.

I can see how that could be handy in the abstract, but what does it bring to the party in the application under discussion

I don't see freenas including nvidia proprietary drivers in the release anytime soon those are needed for hardware acceleration on transcoding, running docker on a VM (when bhyve implements VGA passthrough) will allow just that, shouldn't've be a freenas concern after all is a plugin feature not a freenas core feature, and it will allow more niche situations like this to be handled more easily than in a jail that's dependent on system is running on.

(can't say that the FreeBSD port is perfect or proven that's why I use a VM)

If it's "experimental", it isn't mature or stable.

As I mentioned before yes docker is not stable on FreeBSD for now.

This must be that "civil discussion" that @Magnus33 says everyone here (but me) is having. Good to know.

I'm sorry about the personal remark, I wont do it again.

 

[danb35]

You can have both there's no technical limitation there.

Sure, but it doesn't seem likely that iX is going to work on more than one plugin system in parallel. They can stick with the existing system, they can move to iocage, they can move to Docker, but I don't see them doing two (or all three) of those at the same time. And that's even implicit in the subject of thread--should Plex and Emby be "moved over" to Docker. That indicates stopping work on the .pbi-based plugins, and working on docker-based ones instead.

But nothing stops you, today, from running these using Docker (and it sounds like that's what you're doing). As long as jail support is present, nothing stops anyone from manually setting up a jail (which, at least in the case of Plex, is trivially easy). Docker support isn't going away unless they kill VMs, and now that @jkh is gone, I doubt jail support is going away either. The question is really how the plugins should be handled.

 

[zhnu]

The question is really how the plugins should be handled

Well from what I see "plugins" aren't maintained by iX what they do is facilitate trough web-ui and probably some backend code their use, that been said the same can be done with docker (doesn't even need to be developed by iX they can simply include an iframe on the web-ui to a host/service running a docker management engine). To a point I don't even think iX should worry about plugins working or not, it isn't part of their core functionalities.
If the question really is only on the frontend side of things only a PO or a PM can tell you what they will do.

 

[danb35]

Well from what I see "plugins" aren't maintained by iX

"Maintained" might be a bit of an exaggeration, but they make the capability available, they build a bunch of .pbis, and they make them available to FreeNAS users. They market the feature fairly heavily, and the feature isn't very useful if there aren't any plugins to install. Certainly the same (or something comparable) could be done with Docker, and presumably it can with iocage as well (as iocage seems to be the direction the devs are headed).

 

[zhnu]

as iocage seems to be the direction the devs are headed

Actually by the roadmap both:
Docker: https://bugs.freenas.org/issues/23393
iocage: https://bugs.freenas.org/issues/20169
iocage seems to replace warden (supposedly iocage is also beta "This is beta quality software, there be dragons! Please report them." <- github), so your argument for stability doesn't seem to be a concern (Edit: IMHO Im glad I have both to choose from).

 

[danb35]

Actually by the roadmap both:

Both are going to be included? That's been known for a long time. What I understand is that iocage is where they're heading for the "official" (such as they are) plugins. I'm not aware of their intent to host/prepare their own dockerfiles for docker/plugins--have they said this? Because I don't see it in the bug you link.

supposedly iocage is also beta "This is beta quality software, there be dragons! Please report them." <- github), so your argument for stability doesn't seem to be a concern

Well, not all betas are created equal, but nonetheless that seems like it could be a questionable decision on their part. I guess we'll see.

 

[Stux]

I'm not aware of their intent to host/prepare their own dockerfiles for docker/plugins--have they said this?

Would not be impossible to port the FreeNAS 10 collection.

https://github.com/freenas/docker-images

Worth taking a peek at the various docker files.

 

[zhnu]

I'm not aware of their intent to host/prepare their own dockerfiles for docker/plugins--have they said this?

There's no need docker already provides all the things you need via docker hub. From what I understood it's a feature for 11.2 (at least it's marked that way can be postponed ofc), that creates you a VM with rancherOS, and then the UI to manage it would be provided by rancher itself (but note on the comments complains about not being an integrated solution as in Corral) so it leads me to believe they will incorporate some form of management in the freenas interface if it's going to be called plugins I don't know.

 

[zhnu]

Would not be impossible to port the FreeNAS 10 collection.

https://github.com/freenas/docker-images

Worth taking a peek at the various docker files.

Those can be used or published to docker hub they are only modified versions of the original dockerfile of the services with labels pertinent to the freenas system (like ports where the service runs and volumes it needs etc).

 

[Stux]

Those can be used or published to docker hub they are only modified versions of the original dockerfile of the services with labels pertinent to the freenas system (like ports where the service runs and volumes it needs etc).

Basically, the modifications enable GUI control. Which are a bonus I think. And is portable to a hypothetical 11.2 implentntation.