[Swlug] Docker, containers, oh my!

[Dick Bain]

I'm shocked that this thing seems to be on topic, gah was looking forward
to the comparisons with Hitler LOL

On 21 Apr 2017 12:54, "David Goodwin via Swlug" <swlug at mailman.lug.org.uk>
wrote:

> ....
>
>> I think that covers my experience of LXC too - it’s rather like
>> tooling up for building full VMs. While it can do more, it’s a bunch
>> of parts that you need to tool up yourself, creating potential
>> problems with future maintenance and incuring quite a bit of
>> additional cost.
>>
>
>
> 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".
>
>
>  Though in operation each container feels like a full
>
>> OS. Ubuntu did product LXD which layers a more cloud-like interface
>> on top of LXC. While they say this should run on other distros, and
>> provide a nova plugin for Openstack to run LXD instances in the same
>> way as VMs. There has been little take up of this tech though (which
>> feels like a lot of the Canonical/Ubuntu initiatives).
>>
>
> Yes.
>
> 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.
>
>
>
>> The big 'win' from docker is the images - being able to
>>> quickly/easily deploy something in production and know it's
>>> identical to what you tested against.
>>>
>>
>> I think this is also the biggest risk - that the images are baked and
>> system is needed to patch them long after then become steady state in
>> production. That patch burden is lessened by the small footprint of
>> running and installed software, but there will still be critical bugs
>> in libraries that will need a full scale redeploy to resolve.
>> Different ways of working.
>>
>>
>
> 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.
>
> I doubt many people do 'docker build --pull .' or whatever it is either.
>
>
>
>> I work around update deployment by having a 'master' container
>>> image on each host which I update through ansible every so often.
>>> Each LXC container is rebuilt from that btrfs snapshot on a weekly
>>> basis.
>>>
>>
>> How did you store the data? Separate volume?
>>
>
> Yes. The Apache DocumentRoot is on a different volume that's mounted into
> the container at startup.
>
> 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.
>
>
> I think overlayfs is considered stable enough these days. The
>> alternatives - aufs
>>
>
> aufs - dropped from the kernel.
>
> 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.
>
> zfs - only a relatively recent addition to Ubuntu; apparently requires
> lots of memory
>
> lvm - not tried with lxc.
>
> David.
>
> _______________________________________________
> Swlug mailing list
> Swlug at mailman.lug.org.uk
> https://mailman.lug.org.uk/mailman/listinfo/swlug
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.lug.org.uk/pipermail/swlug/attachments/20170421/788bb60b/attachment.html>