Date: Fri, 2 May 2014 16:47:03 -0400 From: Aleksandr Miroslav <alexmiroslav@gmail.com> To: "freebsd-questions@freebsd.org" <freebsd-questions@freebsd.org> Subject: Re: best configuration management tool for FreeBSD? Message-ID: <CACcSE1wJ-XMUdh8K8aHaeu8qTOw4OPEjxhUemFvONMMquPevxw@mail.gmail.com> In-Reply-To: <BD4A845C-21A3-4413-9A87-E0EDF7298057@gmail.com> References: <CACcSE1z%2BVKKgZ2cZxT-0HyuH4MwwpMaicyjk%2BM27yzfOjKgjSw@mail.gmail.com> <BD4A845C-21A3-4413-9A87-E0EDF7298057@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Thanks for the great info. I settled on ansible a few weeks ago, mostly because it was so easy to run out of the box and also because the configuration file format looks sane. Someone also mentioned to me in passing that ansible is the best supported config magnement tool on BSD systems. On Wed, Apr 30, 2014 at 5:47 PM, Matthew Pherigo <hybrid120@gmail.com> wrot= e: > On Apr 15, 2014, at 5:33 PM, Aleksandr Miroslav <alexmiroslav@gmail.com> > wrote: > > > hi, > > 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. > > 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). > > 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. > > 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.o= rg" > > > Hey Alex, > > There are several different options for that available. There's Puppet, > Ansible, 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 wa= nt > to do with your systems with only some very specific features being prese= nt > or not present. With that in mind, however, a big part of choosing the ri= ght > solution is not just what features are built-in, but considering what the > external factors are. The external factors that I'm thinking of specifica= lly > are add-ons, and community(which both heavily influence each other). If i= t > is easy to develop add-ons for the software (add-ons meaning specificatio= ns > for configuration management of certain applications or environments), an= d > there is a large community, then that means there'll be a lot of add-ons > posted online that you can use, and therefore not have to develop. > > With that said, that's why my preferred choice is Puppet. Puppet has a lo= t > of interest behind it, and it's accelerating pretty rapidly. You tell pup= pet > what you want on a server by putting it in a "manifest", which is a file > which declares what the server should be configured like. For example, yo= u > 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 > telling puppet what the server should look like; when this configuration = is > applied, 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 installed, then Puppet won't try to install it again (as opposed = to, > say, a shell script). > > It also has a git-based website called the Puppet Forge, where people can > post modules for use in puppet; for example, a module which allows you to > easily 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': > 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 > production environment will have a module already made for them, if it > wasn't already built in as part of Puppet itself. I use a ruby gem called > librarian-puppet that manages modules and dependencies for me. > > All this isn't to say that you shouldn't research all the other systems; > they all have strengths and weaknesses, and will be easier to use dependi= ng > on what 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 > for 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?CACcSE1wJ-XMUdh8K8aHaeu8qTOw4OPEjxhUemFvONMMquPevxw>