From owner-freebsd-questions@FreeBSD.ORG Fri May 2 20:47:04 2014 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DA82141C for ; Fri, 2 May 2014 20:47:04 +0000 (UTC) Received: from mail-vc0-x235.google.com (mail-vc0-x235.google.com [IPv6:2607:f8b0:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 993FA1955 for ; Fri, 2 May 2014 20:47:04 +0000 (UTC) Received: by mail-vc0-f181.google.com with SMTP id hy4so5879056vcb.40 for ; Fri, 02 May 2014 13:47:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=Ap0xcWfmSDkX7gclHc97vmjd4Zry7XH6RazzkHgsSpo=; b=SZa7en4zvxKEPA9VMnx+8o42iD8mn5CkQ96idzLalcKM2jcWfwIR8s9y7KlEezAPNS crH49zBm2Hgk65Z7wOIsMnBOVQ7txuhy0KrMZuWjE62fqxKo/RO9ry3fxcAYGnC35Mr3 1L0Ury0xY8/eidFCR2jbnTaAk4u+hlYweNWwCbiOJ6md10sWO7Uz50OUYghiGUOIuJTS opyzjAW7pst/u4jmR0pY9XqD8+w1+hGjZox22LZ0Zhzf5WuTOzpgORrVxMbmXMV4V8vB phs0dc1EL8DuTI/C46XyrVC2OTdAyziFueN7IWBQUiRoNE3ki6sV5guWhGqBirm2j+Gk mcCw== MIME-Version: 1.0 X-Received: by 10.221.26.10 with SMTP id rk10mr14669676vcb.0.1399063623671; Fri, 02 May 2014 13:47:03 -0700 (PDT) Received: by 10.58.227.230 with HTTP; Fri, 2 May 2014 13:47:03 -0700 (PDT) In-Reply-To: References: Date: Fri, 2 May 2014 16:47:03 -0400 Message-ID: Subject: Re: best configuration management tool for FreeBSD? From: Aleksandr Miroslav To: "freebsd-questions@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 20:47:04 -0000 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 wrot= e: > On Apr 15, 2014, at 5:33 PM, Aleksandr Miroslav > 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