Deployment Architecture

Is it a good idea to use deployment server to manage Splunk server (indexer, search head, forwarder) system config?

Builder

Hi,

I am doing a major overhaul of our Splunk infrastructure from a clone pair of standalone indexers to a multi-indexer, multi-dedicated-search-head (not pooled), deployment server.

In an attempt to reduce the level of manual configuration of the new servers, I've reduced the process to simply install the rpm, run a couple of setup commands and point Splunk at our deployment server (which would be done by puppet or equivalent). The deployment server contains all the "system" config for the various different Splunk roles, including web.conf, outputs.conf, inputs.conf, indexes.conf, server.conf, authorize.conf, authentication.conf, limits.conf. The freshly installed Splunk pulls down all its config, restarts and is all configured correctly. Great!

...But I just came across this piece of documentation that advises caution when using deployment server, so I thought I'd get some second opinions.
http://docs.splunk.com/Documentation/Splunk/4.3.1/Deploy/Updateconfigurations#App_management_issues

Is what I'm doing a good idea (apart from the not insignificant risk of messing up serverclass.conf and destroying everything)? Is there a "best practice" document for managing this kind of setup while reducing manual intervention?

Cheers,

Glenn

1 Solution

Contributor

I have personally experienced what the referenced article speaks to and it works just as is described. And knowing this in advance, I now know that I need to make a different change if I want to "pause" an App versus remove it from the system.

I use the Deployment Server to manage most of my Splunk implementation. I currently have one Search Head and two Indexers which will soon change to two Search Heads (pooled) and three Indexers. I use the Deployment Server to manage not only my apps (and I have several) but also my indexes; I don't use the Web UI to create my indexes, I edit an indexer app that deploys them to all my Indexers for me. I use the Deployment Server as much as I can so that I don't have to go to each machine to do what Splunk can do for me. I wish the Deployment Server did a little bit more than what it does now; updating the Forwarder to a new version would be at the top of my wish list.

View solution in original post

Contributor

We use the deployment server to manage our entire Splunk deployment which currently uses 2 load balanced indexers, a couple of search heads (one is test) and a heavy forwarder. Soon, we'll be adding Enterprise Security on an additional dedicated search head. All of our universal forwarders are also managed by the deployment server. The only apps I don't push with the deployment server are the apps that contain visual elements that are only being put on a particular search head such as the *nix app. This has worked really well. I didn't have any issues managing indexes, license slaves, search heads or any other splunk configuration so far with the deployment server.

Builder

Well that's pretty much what I'm doing as well, so good. I just worry that someone could make some mistake one day with the serverclasses and accidentally undeploy all my Splunk infrastructure. Hopefully not soon 😄

0 Karma

Contributor

I have personally experienced what the referenced article speaks to and it works just as is described. And knowing this in advance, I now know that I need to make a different change if I want to "pause" an App versus remove it from the system.

I use the Deployment Server to manage most of my Splunk implementation. I currently have one Search Head and two Indexers which will soon change to two Search Heads (pooled) and three Indexers. I use the Deployment Server to manage not only my apps (and I have several) but also my indexes; I don't use the Web UI to create my indexes, I edit an indexer app that deploys them to all my Indexers for me. I use the Deployment Server as much as I can so that I don't have to go to each machine to do what Splunk can do for me. I wish the Deployment Server did a little bit more than what it does now; updating the Forwarder to a new version would be at the top of my wish list.

View solution in original post