Advanced Deployments - Implementing Splunk: Big Data Reporting and Development for Operational Intelligence - page 361

If you are deploying configurations to indexers, be sure to only deploy
configurations when downtime is acceptable, as you will need to restart
the indexers to load the new configurations, ideally in a rolling manner.
Do not deploy configurations until you are ready to restart as some (but
not all) configurations will take effect immediately.
Using Splunk deployment server
If you do not have a system for managing configurations, you can use the
deployment server included with Splunk.
Some advantages of the included deployment server are as follows:
• Everything you need is included in your Splunk installation
• It will restart forwarder instances properly when new app versions
are deployed
• It is intelligent enough to not restart when unnecessary
• It will remove apps that should no longer be installed on a machine
• It will ignore apps that are not managed
• The logs for the deployment client and server are accessible in Splunk itself
Some disadvantages of the included deployment server are:
• As of Splunk 4.3, there are issues with scale beyond a few hundred
deployment clients, at which point tuning is required
• The configuration is complicated and prone to typos
With these caveats out of the way, let's set up a deployment server for the apps we
laid out before.
Step 1 - Deciding where your deployment server
will run
For a small installation with less than a few dozen forwarders, your main Splunk
instance can run the deployment server without issue. For more than a few dozen
forwarders, a separate instance of Splunk makes sense.
Ideally, this instance would run on its own machine. The requirements for this
machine are not large, perhaps 4 gigabytes of RAM and two processors, or possibly
less. A VM would be fine.