Date: Wed, 30 Apr 2014 16:47:58 -0500 From: Matthew Pherigo <hybrid120@gmail.com> To: Aleksandr Miroslav <alexmiroslav@gmail.com> Cc: "freebsd-questions@freebsd.org" <freebsd-questions@freebsd.org> Subject: Re: best configuration management tool for FreeBSD? Message-ID: <BD4A845C-21A3-4413-9A87-E0EDF7298057@gmail.com> In-Reply-To: <CACcSE1z%2BVKKgZ2cZxT-0HyuH4MwwpMaicyjk%2BM27yzfOjKgjSw@mail.gmail.com> References: <CACcSE1z%2BVKKgZ2cZxT-0HyuH4MwwpMaicyjk%2BM27yzfOjKgjSw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Apr 15, 2014, at 5:33 PM, Aleksandr Miroslav <alexmiroslav@gmail.com> w= rote: >=20 > hi, >=20 > We have a few (~15) FreeBSD boxes that we are running here. They are > all running 8.4, but they are up to date on their ports/patches. >=20 > We have some custom shellscripts (along with rsync) to deploy our > code and and content, but we recently decided to use a proper > configuration manager tool to run our cluster. Internally, we've had a > lot of debate about that and have no clear winners (puppet seems to > get the most votes though). >=20 > What is the best configuration management tool for FreeBSD? We make > heavy use of installing things from ports, so any tool that > understands how to install upgrade stuff from ports would be great. >=20 > Thank you. > Alex > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.or= g" Hey Alex, There are several different options for that available. There's Puppet, Ansi= ble, CFengine (much older than all the others), Chef, Salt, and a few others= . All of these things are going to handle at least 90% of what you could want t= o do with your systems with only some very specific features being present o= r not present. With that in mind, however, a big part of choosing the right s= olution is not just what features are built-in, but considering what the ext= ernal factors are. The external factors that I'm thinking of specifically ar= e add-ons, and community(which both heavily influence each other). If it is e= asy to develop add-ons for the software (add-ons meaning specifications for c= onfiguration management of certain applications or environments), and there i= s a large community, then that means there'll be a lot of add-ons posted onl= ine that you can use, and therefore not have to develop. With that said, that's why my preferred choice is Puppet. Puppet has a lot o= f interest behind it, and it's accelerating pretty rapidly. You tell puppet w= hat you want on a server by putting it in a "manifest", which is a file whic= h declares what the server should be configured like. For example, you might= write something like this: node 'www.example.com' { package { apache: ensure =3D> present, } file { '/usr/www/httpd.conf': ensure =3D> present, source =3D> 'puppet:///files/httpd.conf', } service { 'httpd': ensure =3D> running } } By using declarative language instead of instructional language, you are tel= ling puppet what the server should look like; when this configuration is app= lied, puppet will do the things it needs to do to make sure the server looks= right, and nothing more. For example, if the package "Apache" is already in= stalled, then Puppet won't try to install it again (as opposed to, say, a sh= ell script). It also has a git-based website called the Puppet Forge, where people can po= st modules for use in puppet; for example, a module which allows you to easi= ly declare an Nginx server to be set up on a certain machine, like: class { nginx: } # installs nginx if not present nginx::resource::vhost { 'www.puppetlabs.com':=20 www_root =3D> '/var/www/www.puppetlabs.com', } Since puppet has so much interest from so many people, it has quite a lot of= modules. Most of the things that you're going to want to use in the product= ion environment will have a module already made for them, if it wasn't alrea= dy built in as part of Puppet itself. I use a ruby gem called librarian-pupp= et that manages modules and dependencies for me. All this isn't to say that you shouldn't research all the other systems; the= y all have strengths and weaknesses, and will be easier to use depending on w= hat language they have their roots in (Puppet is based on Ruby). But, if you= don't find any preference towards any particular one, my advice is to go fo= r Puppet since it has the community and growth behind it. Sorry for writing such a long email. =C2=AF\_(=E3=83=84)_/=C2=AF --Matt=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BD4A845C-21A3-4413-9A87-E0EDF7298057>