<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Dec 14, 2016 at 12:51 AM, Volker Cordes <span dir="ltr"><<a href="mailto:mail@vcordes.info" target="_blank">mail@vcordes.info</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
I would like to set up a hosted web app with lxd. I was thinking of<br>
using a separate container for each user by creating a base container<br>
with the webapp preinstalled, publishing it as an image and create the<br>
user containers using this image. While thinking about this, some<br>
question came into mind:<br>
<br>
- Is it correct, that when the base container has to be updated, I still<br>
have to update every user container, </blockquote><div><br></div><div>Yes</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">because zfs is block based and not<br>
file based? </blockquote><div><br></div><div>Not really</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Would it be better to use overlayfs as a backend?<br>
<br></blockquote><div><br></div><div>I wouldn't recommend that. Using overlayfs, and updating the base, might actually lead to unpredicatable results in some cases. In general, if you're using overlayfs/aufs/similar, you shouldn't touch the base.</div><div><br></div><div>IIRC solaris zones allows update-in-the-hosts to propagate to the guest (non-global zone). But they achieve that by read-only-bind-mounting /usr from the global zone.</div><div><br></div><div>Docker has something similar to "upgrade one image, upgrade all" feature. But they achieve it basically by rebuilding the container when one of the base image is updated.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- I would like to have a separate data partition inside each user<br>
container, where user specific data is stored. </blockquote><div><br></div><div>Yes</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Is it possible to create<br>
manual file systems inside the lxd zfs pool? Or could it happen that<br>
they get lost (deleted by lxd for example) so that I should use a<br>
different zfs pool for that? </blockquote><div><br></div><div>Use different dataset</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">How can I mount the filesystem inside the<br>
container - is this supported by the disk device or do I have to mount<br>
them on the host and use a bind mount? </blockquote><div><br></div><div>Basically bind mount. Even if you specifiy a block device, it will be mounted on the host first, and then bind-mounted to the container.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">This would allow me to update<br>
only the base image, create a new container and just mount the data<br>
partition, so I wouldn't have to update every user container.<br>
<br></blockquote><div><br></div><div>lxc config edit ...</div><div><a href="https://github.com/lxc/lxd/blob/master/doc/configuration.md">https://github.com/lxc/lxd/blob/master/doc/configuration.md</a><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- How do I back up the data? Would zrep work? If yes, is it possible to<br>
back up the whole pool or do I have to backup the containers and the<br>
images filesystem separately? For fast recovery it would be nice to just<br>
mirror the whole pool to another server. Or should I use DRBD for that?<br>
<br></blockquote><div><br></div><div>Depends on what you need.</div><div><br></div><div>If you backup the whole dataset used by lxd (e.g. data/lxd and its children), as well as /var/lib/lxd (I put this on zfs too, on a separate dataset, e.g. data/lib/lxd), and other relevant host-side config (e.g. ufw's NAT config for the containers), then you should be able to bring up the complete containers on another host using backup data. If you ONLY need to backup ONE container, then just use whatever method to backup that one dataset, as well as the lxc config (lxc config show ... )</div><div><br></div><div>Based on my experience with drbd, I wouldn't use that (added complexity, reduced performance esp. in dual-active setup). At least, not if you don't need (near)-realtime backups.</div><div><br></div><div>I'd just use zfs incremental send (using whatever frontend you're familiar with), with the consequence that you have some delay (e.g. 1 hour, 1 day, whatever), depending on your sync schedule.</div><div><br></div><div>-- </div><div>Fajar</div></div></div></div>