Date: Sun, 25 Jan 2015 11:41:24 -0800 From: Sean Chittenden <seanc@groupon.com> To: jail@freebsd.org Cc: "Michael W. Lucas" <mwlucas@michaelwlucas.com> Subject: Re: preferred jail management tool Message-ID: <CACfj5vKjiQHsy9VbOKFFcrBpyr3dmbkOOxTxCYhSyZrnrjRiaQ@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
Well this is a rather trendy topic of late and timely. I'm very happy to see a renaissance and renewed interest in container administration for FreeBSD. Last week at work we began an evaluation of the tooling and administration of FreeBSD containers. Despite being depreciated, we're still evaluating ezjail along with bsdploy, qjail, and manually creating jails (via ansible). Ideally we're looking for something with administrative parallels between bhyve and jails, and easy to integrate in to tooling. We're settling on a technology by Wednesday this week. For years I've used and endorsed ezjail, but as stated, it is depreciated. For a book, excluding ezjail would exclude a huge portion of the user base and seems like it would hurt credibility given its dominance as the preferred tool for jail administration. Until yesterday, I'd never seen iocage but in reviewing the implementation, I really like its use of ZFS attributes as the method of persisting jail attributes and properties. This provides a really clean encapsulation mechanism that works well with `zfs send`. "Thick" containers are not opaque at rest or at runtime, are easy to reason about for new administrators on the team (not layered via nullfs at runtime, space is cheap), and the configuration file is included in the dataset itself. Administratively iocage looks simple to use and it fits in well with our configuration tooling (Ansible). I think we will write an iocage ansible module to query and set attributes, at which point iocage will be very clean for our tooling. iocage is built on top of the OS primitives and utilities, was written in shell, and looks very clean in the code's structure. Applying changes to running jails without a restart is also nice. The "feel" of the interface, control, and abstraction provided by iocage sets it apart in my mind. The examples for future administrators is also important and lend itself well to HOWTO-like guides, which adds to the pragmatism of the utility. Again, because it's a single shell script calling OS primitives, it makes it easy to version internally and provide stability guarantees going forward. Support for vnet is nice but not something we're planning on using (instead we're going to advertise container IPs via BGP to TORs). Based on some of the reasoning above and provided there aren't any unaddressable concerns by the rest of the team, I expect we will adopt iocage. My quick $0.02. -sc -- Sean Chittenden
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACfj5vKjiQHsy9VbOKFFcrBpyr3dmbkOOxTxCYhSyZrnrjRiaQ>