Nextcloud: Jail vs. VM

[sdgenxr]

I want to install an instance of Nexcloud and would like to know the pro's and con's of installing it in a jail setting and a VM setting. The basic understanding I have is that a VM is less likely to have issues during a FreeNAS update. Whereas a jail, I've had issues in the past with system updates.

Thanks for any input and thoughts on this!

 

[Rickinfl]

I'm running Ubuntu in a vm that I have setup in a dmz. I have a little bit different options than most due to I'm running laggs with vlans on Cisco switches. But I looked into jails but it wasn't for me due to older versions nextcloud and after reading on here how hard it was to get the newest version in a jail I just don't have that time to force it to work. Some will tell you don't listen to me it's not hard, but everyone doesn't have their skill sets to do it some just want to install it and it works. If you do setup a vm just make sure if it goes outside you protect yourself like I use a dmz.

So it depends on what you want to do and your hardware setup. Vm's do use more resources but I have plenty to spare so no biggy to me. Trust me this question is asked a lot and really no straight answer. My option is it depends on your hardware setup.

 

[starkita]

VM: A whole system running, more ram usage, more flexibility
Jail: not a whole system running, less usage, less flexibility.

I'd go with the jail route, my services are all in jails, and I'll move them iocage soon.

 

[danb35]

IMO, the only reason to put software in a VM is if it requires a non-FreeBSD operating system. An obvious example would be Windows software, but there are features in Plex that are available under Windows or Linux that aren't in the FreeBSD version. That isn't the case with Nextcloud--it, and all its dependencies (some web server, PHP, some database), run just fine under FreeBSD, with no degradation of features or performance. Therefore, if you're going to run it on FreeNAS at all (I don't), I'd suggest putting it in a jail. Perhaps with a scripted installation (shameless plug).

The issue with jails is that historically, you haven't been able to update the underlying FreeBSD template used in the jail. iocage changes that, so you shouldn't be seeing the problems you've had in the past going forward.

 

[sdgenxr]

Thanks everyone for your input!! Your viewpoints have definitely helped me figure out what direction I should go with this installation, as well as future deployments.

 

[appoli]

I considered using Nextcloud using the plugin (jail) for a while, but went with a VM (docker specifically) for a few reasons which are as follows:

When I first installed FreeNAS (which was when corral first came out) I added Nextcloud, but used the standard sql server (sqlight). That was very slow and after reading about the drawbacks of sqlight (such as being able to do one operation at a time) I went the rout of creating a MySQL container originally. Afterwards it was a good chunk faster.

Now given the way Docker is implemented in FreeNAS I have a few different VMs/Nodes (it was easier to specify specific MAC addresses previously. Now I don’t have the time/desire to get the macvlan network operational via Docker so that I can specify different MACs per container). I created a Docker VM (so RancherOS) running Postgre (as its alledgedly one of the best/stable/secure SQL platforms) & Nextcloud within the VM. I gave it access to 3gb of ram and I believe all the cores. With this it hasn’t gone over 1.5gb of ram (2 users, 1-200gb of data, 6.5gb datatabase) and it works very well.
It could be faster, I generally get a transfer speed of like 50 megabits (not bytes). Not sure what the limitation of that is, forgot, but due to the setup it doesn’t actually need to go out of the NIC. There is something I can do to get it faster, but haven’t had the need to do anything about it. And I have easy access to the DB itself if I need to make any adjustments.

Regarding the plugin you have the advatange of not having to use NFS/SMB to access a FreeNAS share (but as I said the data doesn’t actually leave the NIC so the effect of this isn’t as massive as I feared), but I’m quite sure that the SQL dB used is SQLite which has a number of disadvantages, as previously mentioned. The Docker nodes allow for more precise control of system resources assigned to it & updating any of the containers is super easy (which includes adding non-factory Nextcloud containers with other features built in).

Those are my two cents, but I feel like it’s the way to go if you don’t mind having to work a little harder than just clicking “install” in the plugins. The VMs don’t really use that many resources, but that’s on my machine which has a xenon E3 1245 v6 processor wise (and pc2133 ram, not the fastest one available).

 

[danb35]

I considered using Nextcloud using the plugin (jail)

Nobody's talking about the plugin installation, which is admittedly suboptimal in many ways. All plugins are jails, but not all jails are plugins. The question is a manual/scripted jail installation vs. anything in a VM.

 

[appoli]

Nobody's talking about the plugin installation, which is admittedly suboptimal in many ways. All plugins are jails, but not all jails are plugins. The question is a manual/scripted jail installation vs. anything in a VM.

Apologies, jumped to a conclusion (been drinking....), however some of what I have said still holds some relevance (such as using containers/Containers with extra features built in, being able to control resource allocation). And being limited to the FreeBSD port tree/versions available in the port tree.

Apologies for that

 

[danb35]

Yes, resource limits are available for VMs, but not for jails. If you see that as a benefit, then that's a point in VMs' favor. As to the "extra features", without any examples, it's hard to say whether this favors VMs or not. No, jails don't limit you to what's in the ports tree; you can always just build from released source. Certainly it's easier to use the ports, though, and I'm not aware of any relevant packages for which the ports are significantly out-of-date.

I think most of the guides for setting up Owncloud/Nextcloud have it using MySQL/MariaDB rather than Postgres, but that would be a rather trivial change if someone really wanted Postgres instead.

 

[moelassus]

I'd suggest putting it in a jail. Perhaps with a scripted installation (shameless plug).

Thanks for this resource. It states that it is not known to work with 11.1-U4. Has anyone confirmed whether this works or not?

 

[appoli]

Yes, resource limits are available for VMs, but not for jails. If you see that as a benefit, then that's a point in VMs' favor. As to the "extra features", without any examples, it's hard to say whether this favors VMs or not. No, jails don't limit you to what's in the ports tree; you can always just build from released source. Certainly it's easier to use the ports, though, and I'm not aware of any relevant packages for which the ports are significantly out-of-date.

I think most of the guides for setting up Owncloud/Nextcloud have it using MySQL/MariaDB rather than Postgres, but that would be a rather trivial change if someone really wanted Postgres instead.

Depends on how familiar/good you are with FreeBSD/using the CLI. When a container of what I am looking for exists it generally makes my life much easier (assuming there are instructions in the readme...).

The ports tree isn’t that hard to use & as you mentioned you can go Outside of it, but I have had some bad experiences. The first program I used in a jail was Emby. In this case the versions were lagging quite behind in the port tree and there are some serious issues (specifically when using the port tree, I didn’t use tbe plugin so I can’t comment). Myself, and a fairly large number of people, that installed Emby in a jail were having to reboot the jail daily because Emby would stop working. We were told future updates would fix it (an instance where waiting for the port tree version to be updated was a nuisance), were also told that processing power was the issue (ended up buying a different CPU to no avail), etc etc.

However, all that being said (can probably tell that I like Docker/seperate VMs a lot) I would prefer to use a jail over the others as a first resort.
I know recently I haven’t considered it because of the changes in the jail infrastructure (I access my system via my mobile and the new interface barely worked on it at the time which was a requirement for the new jail infrastructure) along with waiting for a conversion app/dealing with whatever issue come from that.

So, especially since they don’t have p9 anymore I really would prefer jails if/when that method is static. However, my needs led me to Docker and I do enjoy a number of the benefits it offers (just trying to fix the inactive ram issue/waiting on tbe release of the fix).
Good luck!

 

[danb35]

It states that it is not known to work with 11.1-U4. Has anyone confirmed whether this works or not?

With the workaround commands given on the github page (which update iocage to a more recent, less buggy, version than ships with 11.1-U3 and -U4), it seems to work with -U3 and -U4.

 

[appoli]

A little update:

Using the info from a Reddit page mentioned in one of the links I added a few tuneables:
vm.v_inactive_target (target size for the inactive queue)
vm.v_free_min (similar to free target, but specifies a hard limit as I understand it).

I pulled the free target back up to 65k pages and made the free min half that (since 256megs isn’t a very lofty amount for a free target all things considered) & set the inactive target initially to 10gb then lowered it to 8gb.
I haven’t had a chance to run the system through it’s paces too much (based on what I read the laundry queue gets cleaned once there is memory pressure & it has to be at least 1% the size of the inactive queue - with these updates the laundry queue has been slower to fill up).

The good news is that once the inactive queue gets to be pretty large the system seems to be cleaning it up. See the screen shots attached.
I haven’t had a chance to see what will happen once the inactive queue gets large when there is 1% of it in the laundry queue, but I will soon.

Also, generally no swap useage. Before I adjusted the inactive target tuneable from 10gb to 8gb there was a small amount of swap useage. But this time around I believe there is none.