Quoting Dan Kegel (d...@kegel.com): > I'm configuring a buildbot for projects that (alas) are using > .deb packages for their internal build dependencies, > and the build & test script for the project does stuff like > sudo apt-get install foo > make > make test > sudo dpkg -r foo > So I'm looking at chroots or lxc along with aufs or overlayfs to > get a fresh build container every time. I could stand a second > of overhead per build, which is what lxc-execute seems to have. > > I see there's a handy lxc-start-ephemeral script in ubuntu > which uses aufs or overlayfs to create an ephemeral container > that goes away when you stop it, but I was hoping to avoid > having separate steps for creating/starting the container, > running a command in it, and destroying it. > > It seems like a very small leap from lxc-start-ephemeral to > lxc-execute-ephemeral. > Has anyone tried writing one?
Is your main objection the extra time it takes for the distro-provided init to run over lxc-init, or using separate commands as you mention above? lxc-start-ephemeral takes arguments to execute, so you can just do lxc-start-ephemeral -o q1 -- ps -ef which will create the container, run the command, and destroy the container, or lxc-start-ephemeral -o q1 -u <username> -- ps -ef > psout which will leave the output in username's ~/psout If you want to use lxc-init, it an lxc-execute-ephemeral shouldn't be too hard to whip up. -serge ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
