Are there any specific reasons for not promoting Puppet and/or Chef to
main in the next release or two? I'm leaning on Puppet because that's
what I'm using, because it's easier to learn somehow (more books about
it, better documentation, and just falls together); Chef, Ansible, and
cfengine are fairly popular as well.
These tools centralize configuration. Puppet is declarative (you tell
it what you want the system to look like) and idempotent (you WILL get
the same results no matter what order things are executed in, no matter
how many times you execute them); Chef is imperative (you tell it how to
do it); the others are unknown to me.
In Puppet specifically, a pile of stuff goes into the modules describing
what the system should look like and which bits depend on which other
bits. The modules specify packages to install, configuration files
(from files or from templates modified by parameters), services that
must be running, and relationships (dependencies, alerts i.e. for the
purpose of restarting services when a configuration file is changed,
etc). Classes in the modules may take parameters, allowing for
interesting configuration--a Web server node could include
nodes/web-01.example.com/vhosts/*, which are a bunch of .pp files
importing the apache::config::vhost class with different parameters,
thus generating a bunch of files for the vhosts configured on the server.
This allows you to stand up a system instantly by pointing the Puppet
agent at Puppetmaster. All required packages are installed,
configuration files are brought in, and services are started. Modifying
any configuration files on the Puppetmaster server will produce updates
on the given node; these updates may cause services to restart, if
necessary.
Puppet examines the remote system and makes decisions about what kind of
configuration it needs. It can decide if apt-get, emerge, yum, pkginst,
or the like is needed to install a package. It will inform the modules
of many OS parameters including type, version, processor type, and other
things, so that decisions can be made--for example, to use a RedHat
specific config file, or to use a different package name on Solaris than
on Ubuntu, or to generate the /etc/apt/sources.list.d/ files with
'debian' or 'ubuntu' and with 'squeeze' or 'edgy' or 'precise'.
A TLS certificate is generated, signed by the puppet server, and placed
on the remote server; the common name in the certificate is used as the
node name. Puppet can automatically generate a signed certificate for a
new node, using its hostname as a common name, and push it to the
agent. It is preferable to manually generate the certificate in
high-security settings. Puppet has an access control list based on
whether an agent is "authenticated" (i.e. presents a signed, known
certificate) or not, which provides four of the primary security
guarantees (Authentication, Authorization, Confidentiality, Integrity).
You can also create a subversion repository for /etc/puppet/modules and
/etc/puppet/manifests. Check out your modules or your manifests, make
changes, then check them in and have subversion respond to a check-in by
pushing an update to the Puppet server. Chef allows you to store
Cookbooks in a git repository, so you can always roll back to a previous
Cookbook version and apply different versions of Cookbooks to different
servers.
Bringing Puppet into main and giving puppet and puppetmaster their own
Tasksel entries in Ubuntu Server would represent a significant step
forward. Chef is more of an unknown to me, as I had difficulty getting
started with it; I know of a few places that do use Chef and, as well,
Ansible and cfengine, so there is market for all such tools. Puppet
seems to have the greatest mind share at the moment; and of course,
obviously, as stated, I have my own preference for it at the moment.
There are also excellent books on Puppet such as Pro Puppet by John
Turnbull.
And whatnot.
Did anybody actually not know what these things are?
--
Ubuntu-devel-discuss mailing list
Ubuntu-devel-discuss@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
