[Lxc-users] Proper way to use LXC to serve multiple apps execution from outside
Ben Butler-Cole
ben at bridesmere.com
Wed May 9 17:42:53 UTC 2012
On 8 May 2012 10:13, Đỗ Hoàng Khiêm <dohoangkhiem at gmail.com> wrote:
> Suppose that I want to build a system to serve many app. execution
> requests from outside, and I want each app will have an isolated
> environment to run, so each time process an execution request I have to
> create a container for this request then execute app and destroy container?
> Or create one container to serve all?
>
Unless your application really needs a completely clean environment for
each request, it is probably better to have a single container handling
multiple requests. Otherwise the overhead of creating a new container will
unnecessarily increase your latency for each request and the load on your
server.
There are advantages, though, in doing as you suggest and creating a
separate container for each application. It gives you an easy way to impose
strict isolation of the applications, constrain the resources available to
them and simplify management of them as atomic systems.
If I create an own container for each app, is there any problem if many
> apps run at same time, as I see that each container has its own rootfs in
> /var/lib/lxc with size about 300MB in my machine (I've to installed some
> additional packages, runtime environments in the container, eg. Python,
> Ruby runtime env.), so 100 apps. run at same time will consume about 30GB
> in hard drive?
>
You could possibly limit the disk space required by using btrfs. But you
need to consider the memory requirements as well (and the CPU requirements
if many of the applications are likely to be handling requests at the same
time).
100 applications (running in 100 separate containers) sounds like an awful
lot to me.
-Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20120509/9467f5aa/attachment.html>
More information about the lxc-users
mailing list