Deployment Architecture

Deployment Architecture

confma812
Explorer

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!

0 Karma
1 Solution

martin_mueller
SplunkTrust
SplunkTrust

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.

View solution in original post

martin_mueller
SplunkTrust
SplunkTrust

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
SplunkTrust
SplunkTrust

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... 😉

0 Karma

confma812
Explorer

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!

0 Karma

lukejadamec
Super Champion

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

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

confma812
Explorer

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

0 Karma

lukejadamec
Super Champion

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.

0 Karma

confma812
Explorer

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?

0 Karma
Get Updates on the Splunk Community!

.conf24 | Registration Open!

Hello, hello! I come bearing good news: Registration for .conf24 is now open!   conf is Splunk’s rad annual ...

Splunk is officially part of Cisco

Revolutionizing how our customers build resilience across their entire digital footprint.   Splunk ...

Splunk APM & RUM | Planned Maintenance March 26 - March 28, 2024

There will be planned maintenance for Splunk APM and RUM between March 26, 2024 and March 28, 2024 as ...