Managing Solaris Zones
I almost named this article "Automating Solaris Zones", but I realized that there are already sites that talk about that, and this is somewhat different.
First, what are Solaris zones? Well, they're somewhere betwen full virtual
machines and chroot jails, and (this is kinda the cool part) you get to
basically move the slider toward one or the other. If you want, you can build
a zone that has almost no per-zone data, reusing /usr, /lib, /sbin, and
anything else from the global zone (yes, that's the offical name), with
all of it read-only. Or, you can reuse nothing, and have a clean zone where
everything is read-write. Any zones always share the kernel, init process,
and the service manager with the global zone, though, which is one big
difference between zones and VMs -- there's only one kernel, no matter how
many zones you have. This sets a limitation on zones, in that they will never
be able to be moved while running to a new machine, because the kernel isn't
virtualized.
I still don't completely understand them yet -- they seem to do some package shenanigans that I don't get (e.g., when installing a package in a global zone, you get messages that imply that it's being installed in all other zones, even though there's no "install packages in all zones" command). In looking at the man page for pkgadd (I can't seem to find a recent copy online), this information is apparently handled in the package database, and can even be manipulated by individual packages, which is pretty weird.
So anyway, we're talking about managing zones, not automating them. What's the difference? There really isn't one, since neither of these has a clear definition, but the word "manage" seems to be more encompassing than "automate", and all of the zone automation I've seen so far has been pretty simple -- create a zone.
Puppet can do quite a bit more than that already. Particularly, you can specify the directories that the zone should inherit, you can configure the ip addresses for the zone, and you can specify the state that the zone should be in (e.g., configured, installed, running, absent):
zone { myzone:
inherit => ["/usr", "/sbin", "/platform", "/lib"],
ip => "e1000g0:192.168.0.101",
ensure => running
}
You can see I had to do some skullduggery there -- the IP field is complex, which I do not like at all but do not see a good way around. I'm going to have to address this better when I look at managing local filesystems, since they have three fields, and it's really quite unacceptable to use that kind of mechanism at all, much less for three fields.
But the real point is, this will create a zone for you. And if you change list of ip addresses or inherited directores, puppet will change the zone's configuration. Alternatively, if you want to move a zone from running to just installed, Puppet will do that for you, too.
Heck, say you don't care about any of this, but you're messing around with zones on Solaris and you're wondering what the fastest way to create a simple zone is; welcome to the one-liner:
puppet -d -e 'zone { myzone: ensure => running }'
This won't get any inherited directories or any network addresses, but you can always add them later:
puppet -d -e ' zone { myzone: ensure => running, inherit => ["/usr", "/sbin"] }'
Yes, that will modify the configuration of your existing zone, not try to create a new one or any some such.
I put the '-d' in there because some of these commands (well, the "install" command) take a long time to run, and debugging prints the commands being executed, so you don't think Puppet has hung or something. Not a problem with non-interactive code, but for interactive stuff it can be confusing.
This is in the main branch of the subversion trunk, and will hopefully be released this week.
Tue, 06 Jun 2006 | Tags: sysadmin
hello,
Your example is wrong. The type reference:
http://reductivelabs.com/trac/puppet/wiki/TypeReference#zone
shows that it is inherit. NOT inherits.
this page is the first page returned via google search, you should change this example.
jason.
Tags
