<div dir="auto">I'm shocked that this thing seems to be on topic, gah was looking forward to the comparisons with Hitler LOL</div><div class="gmail_extra"><br><div class="gmail_quote">On 21 Apr 2017 12:54, "David Goodwin via Swlug" <<a href="mailto:swlug@mailman.lug.org.uk">swlug@mailman.lug.org.uk</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">....<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think that covers my experience of LXC too - it’s rather like<br>
tooling up for building full VMs. While it can do more, it’s a bunch<br>
of parts that you need to tool up yourself, creating potential<br>
problems with future maintenance and incuring quite a bit of<br>
additional cost.<br>
</blockquote>
<br>
<br>
Yes. It also made it easier for me to adopt it. As I thought of the LXC instance being like a virtual machine .... whereas with Docker you only have one process by default - so e.g. "How would your PHP/Apache process send an email out if there's not some sort of MTA within the container.....  with LXC I can just install postfix and that problem's solved".<br>
<br>
<br>
 Though in operation each container feels like a full<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
OS. Ubuntu did product LXD which layers a more cloud-like interface<br>
on top of LXC. While they say this should run on other distros, and<br>
provide a nova plugin for Openstack to run LXD instances in the same<br>
way as VMs. There has been little take up of this tech though (which<br>
feels like a lot of the Canonical/Ubuntu initiatives).<br>
</blockquote>
<br>
Yes.<br>
<br>
I'm also not sure OpenStack has much of a future.... at least Rackspace aren't really doing anything with it any more - and I thought they were one of the main supporters/drivers.<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The big 'win' from docker is the images - being able to<br>
quickly/easily deploy something in production and know it's<br>
identical to what you tested against.<br>
</blockquote>
<br>
I think this is also the biggest risk - that the images are baked and<br>
system is needed to patch them long after then become steady state in<br>
production. That patch burden is lessened by the small footprint of<br>
running and installed software, but there will still be critical bugs<br>
in libraries that will need a full scale redeploy to resolve.<br>
Different ways of working.<br>
<br>
</blockquote>
<br>
<br>
Yes. Obviously you can hope you're protected by the microservice not being directly connected to the internet, and thought use of something like linkerd, but I doubt that's sufficient.<br>
<br>
I doubt many people do 'docker build --pull .' or whatever it is either.<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I work around update deployment by having a 'master' container<br>
image on each host which I update through ansible every so often.<br>
Each LXC container is rebuilt from that btrfs snapshot on a weekly<br>
basis.<br>
</blockquote>
<br>
How did you store the data? Separate volume?<br>
</blockquote>
<br>
Yes. The Apache DocumentRoot is on a different volume that's mounted into the container at startup.<br>
<br>
I experimented with using AWS's EFS for the DocumentRoot, but it didn't seem to have all that great performance so have held off on that.<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think overlayfs is considered stable enough these days. The<br>
alternatives - aufs<br>
</blockquote>
<br>
aufs - dropped from the kernel.<br>
<br>
overlayfs(2) - seen weird notice messages upon e.g. removing a .deb within the container; requires a one line kernel patch to allow privilege separation; requires either Debian backports or custom kernel.<br>
<br>
zfs - only a relatively recent addition to Ubuntu; apparently requires lots of memory<br>
<br>
lvm - not tried with lxc.<br>
<br>
David.<br>
<br>
______________________________<wbr>_________________<br>
Swlug mailing list<br>
<a href="mailto:Swlug@mailman.lug.org.uk" target="_blank">Swlug@mailman.lug.org.uk</a><br>
<a href="https://mailman.lug.org.uk/mailman/listinfo/swlug" rel="noreferrer" target="_blank">https://mailman.lug.org.uk/mai<wbr>lman/listinfo/swlug</a><br>
</blockquote></div></div>