[nycbug-talk] New Setup Questions

[Pete Wright]

On 27-May-09, at 12:59 PM, Matt Juszczak wrote:

> Hi all,
>
> Two more questions for everyone.
>
> Just an update a month later - we've been working hard on the  
> migration
> project, but we're coming down to the wire.
>
> I've gotten everything setup nicely - internal DNS, everything uses  
> LDAP,
> I'm using package distribution (via NFS) with custom FreeBSD packages,
> everything is in sync and config'd the same, tuned, etc.
>
> The two things I haven't been able to complete that I wanted to are:
>
> 	- A good dev environment
> 	- using puppet
>
> At this point, I need to find a temporary solution for us to keep our
> webserver configuration and code in sync.  For now, I was thinking of:
>
> - configuring puppet on the webs so that /usr/local/etc/apache22 is
> managed 100% by puppet (since its 100% identical across all  
> webservers).
> The other option would just be to temporarily make this directory an  
> svn
> checkout, but ... eh....
>
> - putting all of our code in an SVN repository (temporarily) and  
> checking
> it out to all the webs.  Somehow, I would need to tell the webs when  
> it's
> ok to run "svn update" and on which directory to do that.  I could  
> do that
> with a script, or I could do it via puppet potentially?
>
> I haven't had much time to play with puppet, and we only have a few  
> more
> days.  Can someone with puppet experience let me know if the temporary
> solution I propose above is an ok idea, or if it would be better to go
> another route?

my general rule of thumb is that having all of your configuration data  
stored in puppet/cfengine/etc is a good thing for sure.  I would not  
suggest having all of your servers depend upon svn to keep their  
configs in sync.

now, having all of your puppet configs in svn is probably a good thing  
- and setting up some post commit triggers in svn could even be done.   
for example:
- all of /usr/local/apache/ is managed via puppetd on client side, and  
all configs are in svn on the puppet server side
- admin updates $PUPPET_HOME/modules/apache2/some-config-file and  
checks it into svn
- you have a svn hook (or call back) that pushes this new config to  
puppet and automatically gets pushed to your web servers.

i'd have a hard think about the last part though as if used improperly  
you can really shot yourself in the foot :)

regarding puppet configuration schema it's pretty straight forward.   
something like this may work...

define all of your httpd systems somewhere like $PUPPET_HOME/manifests/ 
httpd.pp

node my_server {
# common configs for all servers in production
        include generic-server-config
# snmpd config files
        include snmpd
# apache configs
        include apache2
}

then create a httpd config class (i think puppet uses the term  
"module").  here is one we use which may help:

$ find $PUPPET_HOME/modules/apache2/
apache2/
apache2/manifests
apache2/manifests/init.pp
apache2/files
apache2/files/apache-testfile
$ cat apach2/manifests/init.pp
class apache2 {

         package {
                 apache2: ensure => installed
         }

         file { "/etc/apache2/testfile":
                 source => "puppet://$servername/apache2/apache- 
testfile"
         }

}


in this example we just have a dummy apache test file, you could  
obviously have your httpd.conf, sites-enabled/site-config and such in  
there.  you also may, or may not want the package{} statement.


HTH
-pete


ps -> i'm relatively new to puppet (coming from cfengine), so if any  
puppet guru's out there some obvious mistakes don't hesitate to let me  
know!