Deployment Architecture

[confma812]

I've seen documentation that mult-tenated/silo-ed or a hierarchical architecture can be created with Splunk deployment servers, but I haven't seen any useful examples of how this can be configured.

My overall goal is to have a single deployment server overall. Otherwise I would have a deployment server on a per-site basis. The goal with the first deployment server is to to tell the secondary deployment server how to handle the forwarders or indexers.

So let's assume I've already got the systems talking, as I've already figured out that piece. Now how can I have a configuration deploy from the first to second deployment server, and then to the forwarder (and if possible, any configurations to the indexer, such as a change in a transform)?

-----------------------
| Deployment_Server_1 |
-----------------------
          |
          |
          |
-----------------------
|       Indexer       |
| Deployment_Server_2 |
-----------------------
          |
          |
          |
-----------------------
|   Forwarder (UF)    |
-----------------------

• Systems are already communicating, and show in list deploy-clients
  • Server classes are already made:
  • Linux
  • Windows
  • App-1-Windows
  • App-1-Linux
  • App-2-Windows

Any assistance in this matter would be greatly appreciated!

[martin_mueller · Accepted solution]

If you want more control over DS2, including setting its serverclass.conf from DS1, you can do this:

On UF you tell it to deploy-poll to DS2, and on DS2 you tell it to deploy-poll to DS1 - you've probably done that already. That's all you'll configure on UF and DS1.

On DS1 you'll build a serverclass.conf that contains your secondary deployment servers, so there will be an entry for DS2. You'll send all the apps to DS2 that are required on its deployment clients, ie UF, in a disabled state. Additionally, you create an app called DS2-app that gets deployed to DS2 in an active state.

serverclass.conf on DS1:

[serverClass:DS2]
whitelist blah blah

[serverClass:DS2:app:DS2-app]
stateOnClient = enabled

[serverClass:DS2:app:someapp]
stateOnClient = disabled

The app someapp gets sent to DS2's app directory, but is kept disabled - it will be sent on to the UF and enabled there.
The DS2-app contains the following:

deploymentclient.conf to reload DS2 whenever DS1 sends new apps:

[deployment-client]
disabled = false
reloadDSOnAppInstall = true

serverclass.conf to send apps deployed by DS1 on to DS2's deployment clients, ie UF:

[global]
repositoryLocation = $SPLUNK_HOME/etc/apps

[serverClass:UF]
whitelist blah blah

[serverClass:UF:app:someapp]
stateOnClient = enabled

This kind of deployment chain isn't that easy to maintain because you need to think around a lot of corners when things get more complex. On the upside you can in principle control the world from a single deployment server... just prepare for long delays until everything is deployed everywhere.

[martin_mueller]

Another common use case for this is a combination of secondary deployment server and intermediate forwarder, e.g. in a DMZ. That way you only need to drill two holes in the firewall for 8089 and 9997 from the DS2/IF, and no holes from the UF machines.

If you need hands-on help with this, sales is always listening... 😉

[confma812]

That is absolutely what I'm looking for. The key component (that I apologize for not including) was that I wanted to have the apps copied on DS2 but not used. The goal in the future is to manage all of my deployments via a single Deployment Server or a cluster of Deployment Servers that are also Search Heads. Thanks!

[lukejadamec]

Have you read "Example: How to propagate apps from Primary to Secondary Deployment Server" on this page?

http://wiki.splunk.com/Deploy:DeploymentServer

[confma812]

Then it's much easier than I thought, thanks!

[lukejadamec]

There are a number of settings involved, but yea, basically that's it. The client needs to know where the server is, and the server needs to know who the clients are and what to send.

[confma812]

That I have. So it's really as easy as pointing the second deployment client to the first? And then whatever I have set to forward to the forwarder will forward following it's propagation to the second deployment server?