On 2012-09-04 17:26, Bai Shen wrote: > I've gotten an install of solr working, but it's pretty much a hack job > at the moment. If y'all could give me your thoughts on how to improve > my setup, I'd appreciate it. apache-tomcat is an rpm of Tomcat 7 that > references the oracle jdk instead of openjdk.
I don't know Solr so I am not exactly sure how it is set up and run, so take the following only as guidelines, not as explicit instructions. It seems Solr requires Tomcat, so you could either implicitly manage Tomcat within your Solr module (bad), or have a separate Tomcat module with which your Solr module can interface (good). You would then bring the modules together in a separate profile or role class. Regardint that, have a look at this insightful blog post by Craig Dunn: http://www.craigdunn.org/2012/05/239/ > class solr { I recommend you follow best practices and not manage every aspect of your Solr resource in a single class, but split it up into subclasses, probably at least: solr::install (install.pp), solr::config (config.pp), solr::service (service.pp). The solr class (init.pp) then includes all subclasses and explicitly declares their dependencies among each other, like so: class solr { include 'solr::install' include 'solr::config' include 'solr::service' Class['solr::install'] -> Class['solr::config'] ~> Class['solr::service'] } This makes it easier to manage and change later on. > service { 'iptables' : > ensure => stopped, > } This is strange, as John has noted. Why should Solr have anything to say about the iptables service on the machine? At most it should interface with an iptables module to, e.g., open or close ports. > file { '/opt/apache-tomcat/conf/Catalina': > ensure => directory, > } > > file { '/opt/apache-tomcat/conf/Catalina/localhost': > ensure => directory, > } These directories are fairly standard for Tomcat, are they not? Thus they should be created by your apache-tomcat package, not managed explicitly by Puppet. > file { '/opt/apache-tomcat/conf/Catalina/localhost/solr.xml': > source => 'puppet:///modules/solr/solr.xml', > owner => 'tomcat', > group => 'tomcat', > mode => '644', > notify => Service['apache-tomcat'], > require => Package['apache-tomcat'], > } This would go into solr::config. It is better, IMHO, to use explicit dependencies here as well, i.e. not "notify" and "require", but something like this: Package['apache-tomcat'] -> File['/opt/apache-tomcat/conf/Catalina/localhost/solr.xml'] ~> Service['apache-tomcat'] I guess that depends on your preferences. But that points out the problem that your module mixes quite a few resources, but not wholly implicitly. Again I refer you to the blog post above. > file { '/opt/apache-tomcat/conf/server.xml': > source => 'puppet:///modules/solr/server.xml', > owner => 'tomcat', > group => 'tomcat', > mode => '644', > notify => Service['apache-tomcat'], > require => Package['apache-tomcat'], > } Also something that should go into a config class. Either solr::config or apache-tomcat::config. > file { '/opt/solr': > ensure => directory, > recurse => true, > purge => true, > source => 'puppet:///modules/solr/solr', > owner => 'tomcat', > group => 'tomcat', > mode => '644', > notify => Service['apache-tomcat'], > require => Package['apache-tomcat'], > } > file { '/opt/solr/solr.war': > ensure => 'link', > target => '/opt/solr/apache-solr-3.6.1.war', > } > > file { '/solr': > ensure => directory, > owner => 'tomcat', > group => 'tomcat' > } > } Again solr::config. Also, see above. Well-designed modules are rare and take time and experience to create. I myself have written around 60 modules over the past nine months but I would never dare publish any of them on Puppetforge or even Github. It's hard to make a module of publishable quality (i.e. one that can be used by someone else without having to look at or change the code). Andreas
signature.asc
Description: OpenPGP digital signature
