[lxc-users] Thoughts on containers to virtualize a Load Balancer's virtual contexts

Steve Hayman steve at zoeycommerce.com
Fri Jan 22 15:09:22 UTC 2016


Hi Nicola,

New to this Mailing list, but not so new to LXC. I'm currently running 1270
LXC containers in my production environment, all serving a similar function
to that which you describe. For about a year and a half now we have been
using LXC to host isolated instances of our web app. We have a deployment
script that clones new containers on a host from a base container
pre-populated with things like keys and ssl certs and local ansible setup
scripts, adds his ip to DNS masq on the host, and deploys our production
code to the container. Each of our hosts is a VM in our OpenStack private
cloud. We use nginx as a proxy running locally on each Host VM and he
proxies traffic in to the internal network where the containers reside.

To answer your questions directly:
1.Seems ok to me!
2.I have not had a chance to play with LXD yet, but it's being developed
based on LXC by the same folks who built LXC. Maybe wait for them to
announce a 1.0 though? (However the filesystem quota changes in .27 are
enticing)
3.Ansible/bash and the LXC clone function are extremely useful for this!
4.We specifically have some ansible scripts that create the base container
on each new host, pre-seeded with all the other keys and setup scripts.
When we need a new container we clone this one and then execute the setup
scripts passing in the relevant variables.

I'd be happy to go into greater detail if you were interested in hearing
more granular details about how we make it all work!

Thanks,
-Steve

On Fri, Jan 22, 2016 at 4:46 AM, Nicola Volpini <nicola.volpini at kambi.com>
wrote:

> Hello,
>
> I've been closely observing LXC's development and I'm thrilled by how
> fast it grew. Well done!
>
> We are currently planning to deploy a software load balancer solution.
> The LB will serve various VIPs, some exposed to the internet, some used
> internally.
> Based on this, we would like to use LXC unprivileged containers to
> isolate the load balancer processes, in a setup like this:
>
> Host:
> Br0 - connected to the internal network
> Br1 - exposed to the internet
>
> Container0:
> eth0 - attached to br0
>
> Container1 (internet facing):
> eth0 - attached to br0
> eth1 - attached to br1
>
> I initially ruled out LXD since it's apparently very young and wanted to
> base everything on LXC, solid and tested.
> Playing with LXD, though, I realized how much more convenient it is from
> an automation point of view: we could configure our containers in
> non-modal mode via ansible instead of creating/editing files, and stuff
> like that.
>
> So, a few questions:
> 1. would the setup layout described above make sense?
> 2. would it be a risky bet to base the project on LXD instead of pure
> LXC? Since LXD uses LXC, I can't see any big security/stability risks. I
> suppose the only concern would be related to changes in the file format
> or in the CLI in later versions.
> 3. would it be convenient to build our own templates? I need to be able
> to preseed certain files like the monitoring agent, the authentication,
> and so on into the containers during the installation. An alternative
> would be to use Ansible but that would require me to specify the initial
> users anyway, one way or another.
> 4. related to templates: I can't find any documentation in the wild. Any
> good resource you can point me to, so I can start studying?
>
> Thank you!
>
>
> CONFIDENTIALITY NOTICE: This email message (and any attachment) is
> intended only for the individual or entity to which it is addressed. The
> information in this email is confidential and may contain information that
> is legally privileged or exempt from disclosure under applicable law. If
> you are not the intended recipient, you are strictly prohibited from
> reading, using, publishing or disseminating such information and upon
> receipt, must permanently delete the original and destroy any copies. We
> take steps to protect against viruses and other defects but advise you to
> carry out your own checks and precautions as Kambi does not accept any
> liability for any which remain. Thank you for your co-operation.
> _______________________________________________
> lxc-users mailing list
> lxc-users at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users




-- 

Stephen Hayman | Zoey Commerce | Ops

http://www.zoeycommerce.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20160122/5b9a84da/attachment.html>


More information about the lxc-users mailing list