LXC Directions

Dustin Kirkland kirkland at canonical.com
Mon Jul 18 21:31:07 UTC 2011

On Mon, Jul 18, 2011 at 4:00 PM, Serge E. Hallyn <serge at hallyn.com> wrote:
> Quoting Clint Byrum (clint at ubuntu.com):
>> LXC has been something I've heard mentioned hand in hand with Ensemble
>> since the very first time I heard about Ensemble at UDS-M. I think I
>> understand the directions that have been proposed, and I think its time
>> we had the discussion so that we can enable LXC for local dev at the very
>> least, and hopefully also for many other purposes in Ensemble.
>> Here are the ways I see LXC being useful in Ensemble:
>> ::Unit isolation
>> Multiple units per machines isn't just about saving money, but also about
>> being able to serve multiple services with a single machine. "Cloud in the
>> cloud". :) As some people have suggested, the wordpress example does not
>> need two machines.  (Or even 4 if you were to go High-Availability). But
>> putting the db server and the app server on the same box means there's a
>> potential for privilege escalation.  The app server is probably going to
>> be exposed to the internet, at which point it will be quite vulnerable. If
>> its ever compromised, this may lead to an attacker finding the database
>> available locally, and compromise of said data.
>> LXC at least would hide the existence of the database server from the
>> web app server. As far as the attacker is concerned, its just another
>> host that will have to be compromised over the network, instead of
>> locally. LXC's security model is not actually much stronger than chroot's,
> It also might be worth the time to enhance your uec template to add some
> apparmor isolation.  It won't help with the problem of system call
> abuses, but we could clamp down on some /proc and /sys/ stuff.
>> The really confusing part for me is how to do the network. Right now you
>> have a hostname, and that hostname is useful, as it resolves to the IP
>> that one can contact your machine on.
>> But if you create a container, it needs an IP. You can't use NAT, because
>> now you have to make sure ports don't collide. On EC2, I'm not aware of
>> a way for a single machine to get more than one internal IP. There are
>> elastic IPs for public access, but if you use these from inside EC2,
>> you are going to pay bandwidth charges.
>> Another option I see is to create a VPN between all of the machines
>> so that all of the containers can directly address all of the other
>> containers on a network. This seems overly complex. Because its being
> Do you think it's feasible to pick a large private subnet (say
> 10.90.x.y), give each ec2 host a 10.90.x.0/24 subnet, give each lxc
> container a 10.90.x.y ip address, and have an agent on each ec2 host
> maintain forwarding rules?  That's just for communication between
> the containers, of course.  Service access from the outside would
> require intelligent forwarding by some external facing agent.

I started a reply earlier this morning, context switched, and forgot
about it.  But basically I was proposing something similar.  I think
it's quite a reasonable idea, and fairly similar to what Eucalyptus,
virt-manager/libvirt do with their private, intra-machine subnets.
The external facing agent would require a bit of additional
logic/routing, but as you mention, openvswitch should be able to help

> There might be a clever way to use openvswitch here, perhaps Nick will
> speak up :)
> -serge
> --
> Ensemble mailing list
> Ensemble at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ensemble


Dustin Kirkland
Manager, Systems Integration
Corporate Services
Canonical, LTD

More information about the Ensemble mailing list