About deployment server
This documentation does not apply to the most recent version of Splunk. Click here for the latest version.
About deployment server
|Important: The deployment sever handles configuration and content updates to existing Splunk installations. You cannot use it for initial or upgrade installations of Splunk components. To learn how to install and deploy Splunk, see "Step-by-step installation procedures" for full Splunk and "Universal forwarder deployment overview" for the Splunk universal forwarder.|
The deployment server is Splunk's tool for pushing out configurations and content updates to distributed Splunk instances. A key use case for the deployment server is to manage configuration for groups of forwarders. For example, if you have several sets of forwarders, each set residing on a different machine type, you can use the deployment server to push out different content according to machine type. Similarly, in a distributed search environment, you can use a deployment server to push out content to sets of indexers. If you want an overview of the different ways you can design a Splunk deployment in your organization, check out the deployment information in the Community Wiki.
The first several topics in this section explain how to configure a deployment server and its clients. Topics then follow that show how to employ this technology for specific use cases.
The big picture (in words and diagram)
A deployment server is a Splunk instance that acts as a centralized configuration manager, collectively managing any number of Splunk instances, called "deployment clients". Any Splunk instance -- even one indexing data locally -- can act as a deployment server.
A deployment client is a Splunk instance remotely configured by a deployment server. A Splunk instance can be both a deployment server and client at the same time. Each Splunk deployment client belongs to one or more server classes.
A server class is a set of deployment clients, grouped by some set of configuration characteristics, so that they can be managed as a unit. You can group clients by application, OS, type of data, or any other feature of your Splunk deployment. To update the configuration for a set of clients, the deployment server pushes out configuration files to all or some members of a server class. Besides configuration settings, you can use the deployment server to push out any sort of content. Server classes are configured on the deployment server.
This diagram provides a conceptual overview of the relationship between a deployment server and its set of deployment clients and server classes:
In this example, each deployment client is a Splunk forwarder that belongs to two server classes, one for its OS and the other for its geographical location. The deployment server maintains the list of server classes and uses those server classes to determine what content to push to each client. For an example of how to implement this type of arrangement to govern the flow of content to clients, see "Deploy several forwarders".
A deployment app is a set of deployment content (including configuration files) deployed as a unit to clients of a server class. A deployment app might consist of just a single configuration file, or it can consist of many files. Depending on filtering criteria, an app might get deployed to all clients in a server class or to a subset of clients. Over time, an app can be updated with new content and then redeployed to its designated clients. The deployment app can be an existing Splunk app, or one developed solely to group some content for deployment purposes.
Note: The term "app" has a somewhat different meaning in the context of the deployment server from its meaning in the general Splunk context. For more information on Splunk apps, see "What are apps and add-ons?".
A multi-tenant environment means that you have more than one deployment server running on the same Splunk instance, and each deployment server is serving content to its own set of deployment clients. For information about multi-tenant environments, see "Deploy in multi-tenant environments".
Here's a recap of the key definitions:
|deployment server||A Splunk instance that acts as a centralized configuration manager. It pushes configuration updates to other Splunk instances.|
|deployment client||A remotely configured Splunk instance. It receives updates from the deployment server.|
|server class||A deployment configuration category shared by a group of deployment clients. A deployment client can belong to multiple server classes.|
|deployment app||A unit of content deployed to one or more members of a server class or classes.|
|multi-tenant environment||A deployment environment involving multiple deployment servers.|
Communication between deployment server and clients
The deployment client periodically polls the deployment server, identifying itself. The deployment server then reviews the information in its configuration to find out if there is something new or updated to push out to that particular client. If there is new content to deploy to a given deployment client, the deployment server tells the client exactly what it should retrieve. The deployment client then retrieves the new content and treats it according to the instructions specified for the server class it belongs to--maybe it should restart, run a script, or just wait until someone tells it to do something else.
Lookup tables and deployment server
In some cases, your indexers or search heads might be running apps that save information in lookup tables. Be careful about using the deployment server to manage such instances. When the deployment server pushes out an updated app configuration, it overwrites the existing app. At that point, you'll lose those lookup tables.