lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Stults <sstu...@opensourceconnections.com>
Subject Thoughts on production deployment?
Date Thu, 31 Jan 2013 10:13:58 GMT
Part of this is a rant, part is a plea to others who've run successful production deployments.

Solr is a second-class citizen when it comes to production deployment. Every recipe I've seen
(RPM, DEB, chef, or puppet) makes assumptions that in one way or another run afoul of best-practices
when it comes to production use. And if you're not using one of these recipe formats to deploy
Solr you're building a SnowflakeServer (Martin Fowler's term).

Granted, Solr _can_ be deployed into any vanilla JEE container, so the deployment spec responsibility
may be erroneously assigned to whichever you choose. BUT, if you want to get the maximum out
of Solr you'll want to put it on its own box, running in its own tuned container, and that
container should be the one that Solr's been tested on repeatedly by an army of build bots.
Right now that blessed container is Jetty version 8.1.2.v20120308.

So the first problem with the recipes is that they make a generic dependency of Jetty or Tomcat.
The assumption there is that either can be treated as a generic OS facility to be shared with
other apps. That's not true because Solr is the driving force behind which version is deployed.
The container can't be up- or downgraded without affecting Solr, and any other app running
in there needs to be aware that Solr is taking first priority.

The next problem is that most recipes don't make a distinction between collections. "Solr"
configuration goes in one folder, "Solr" data goes in another, and the logs and container
stuff gets scattered likewise. In reality, every collection can be configured differently
and there is no generic "Solr" data. 

Lastly, the package maintainers of all the major OS distributions have ignored Solr since
around version 1.4. That means if you want a newer version you're going to download a tarball
and make another snowflake. This might be attributable to thinking of Solr as just another
web app that doesn't need special packaging. Regardless, the consequence is that the only
people who are deploying Solr according to best-practices are those intimately familiar with
Solr.

So what's the best way to fix this situation? Solr already ships with everything it needs
except Java and a start-up script. Maybe the first step is to include a generic "install.sh"
script that has a couple distro-specific support scripts. That would be fairly agnostic toward
package management systems and it would be useful to sysadmins right away. It would also help
package maintainers update their build specs.

What do _you_ think? 


-Scott
Mime
View raw message