Splunk® Enterprise

Updating Splunk Enterprise Instances

Download manual as PDF

Download topic as PDF

Create deployment apps

A deployment app consists of any arbitrary content that you want to download to a set of deployment clients. The content can include:

  • A Splunk Enterprise app (such as those on Splunkbase)
  • A set of Splunk Enterprise configurations
  • Other content, such as scripts, images, and supporting files

You add a deployment app by creating a directory for it on the deployment server. Once you create the directory, you can use the forwarder management interface to map the app to deployment clients.

You can add to or change the content of an app at any time -- when you initially create the directory, or later, when you're ready to deploy or redeploy the app to deployment clients.

Create the app directories

You create separate directories for each deployment app in a special location on the deployment server. The default location is $SPLUNK_HOME/etc/deployment-apps, but this is configurable through the repositoryLocation attribute in serverclass.conf. Underneath this location, each app must have its own subdirectory. The name of the subdirectory serves as the app name in the forwarder management interface.

Note: After an app is downloaded, it resides under $SPLUNK_HOME/etc/apps on the deployment clients.

You can add apps at any time. After creating any new app directories, you must run the CLI reload deploy-server command to make the deployment server aware of them:

 splunk reload deploy-server

By creating an app directory, you have effectively created the app itself, even if the directory does not yet contain any content. The app now appears in the forwarder management interface and you can use it to define server classes, as described in "About server classes".

Important: When specifying app names (that is, when creating the app directories), you should be aware of the rules of configuration file precedence, as described in the topic "Configuration file precedence" in the Admin manual. In particular, note that app directory precedence is determined by ASCII sort order. For example, if you set an attribute/value pair whatever=1 in the configuration file x.conf in an app directory named "A", the setting in app A overrides the setting whatever=0 in x.conf in an app named "B", and so on.

Populate the apps

You can put content into an app directory at any time prior to deploying the app to its clients. You can later update and redeploy the app. To update the app, just add to or overwrite the files in the directory. For information on updating and deploying apps to clients, see "Deploy apps to clients".

View apps with forwarder management

Once you create an app directory, the deployment server adds it to its list of apps under the Apps tab of the forwarder management interface. For example:

Forwarder management apps.png

App management issues

Before deciding whether to use the deployment server to manage an app, there are some issues to consider.

The decision to manage an app with deployment server is irreversible

Important: Once you start using the deployment server to manage an app, you cannot later stop using the deployment server to manage the app. It is important to understand the implications of this.

If you remove an app from the deployment server's repositoryLocation (defined in serverclass.conf), the deployment client will delete its copy of the app. There is no way to tell the deployment client instead to start managing the app on its own.

For example, say you are using the deployment server to manage updates to "appA". To do this, you have created a directory called "appA" on the deployment server and you have placed the app's contents there. From now on, whenever the deployment clients poll the server to check for updates, they compare their checksum for appA with the server's checksum for appA. If the checksums differ, the clients download the latest version of the app from the server. However, if appA has been deleted from the server's app repository, the client behavior is to delete their own instances of the app.

Therefore, by deleting an app from the deployment server, you are not telling the clients to stop using the deployment server to manage the app and to start managing it on their own. Instead, you're actually telling them to delete the app. Once the deployment server manages an app, it always manages that app.

Warning: Because of this behavior, you should be extremely cautious before deciding to use the deployment server to manage the Splunk Enterprise search app. Managing the search app through the deployment server prevents users from saving any unique searches on their search heads. And because there's no way to tell the deployment server to stop managing an app, you're stuck with that decision.

Apps with lookup tables

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 apps. When the deployment server distributes an updated app configuration, it overwrites the existing app. At that point, you'll lose those lookup tables.

Configure deployment clients
Create server classes

This documentation applies to the following versions of Splunk® Enterprise: 6.0, 6.0.1, 6.0.2, 6.0.3, 6.0.4, 6.0.5, 6.0.6, 6.0.7, 6.0.8, 6.0.9, 6.0.10, 6.0.11, 6.0.12, 6.0.13, 6.0.14, 6.0.15, 6.1, 6.1.1, 6.1.2, 6.1.3, 6.1.4, 6.1.5, 6.1.6, 6.1.7, 6.1.8, 6.1.9, 6.1.10, 6.1.11, 6.1.12, 6.1.13, 6.1.14, 6.2.0, 6.2.1, 6.2.2, 6.2.3, 6.2.4, 6.2.5, 6.2.6, 6.2.7, 6.2.8, 6.2.9, 6.2.10, 6.2.11, 6.2.12, 6.2.13, 6.2.14, 6.2.15, 6.3.0, 6.3.1, 6.3.2, 6.3.3, 6.3.4, 6.3.5, 6.3.6, 6.3.7, 6.3.8, 6.3.9, 6.3.10, 6.3.11, 6.3.12, 6.3.13, 6.3.14, 6.4.0, 6.4.1, 6.4.2, 6.4.3, 6.4.4, 6.4.5, 6.4.6, 6.4.7, 6.4.8, 6.4.9, 6.4.10, 6.4.11, 6.5.0, 6.5.1, 6.5.1612 (Splunk Cloud only), 6.5.2, 6.5.3, 6.5.4, 6.5.5, 6.5.6, 6.5.7, 6.5.8, 6.5.9, 6.5.10, 6.6.0, 6.6.1, 6.6.2, 6.6.3, 6.6.4, 6.6.5, 6.6.6, 6.6.7, 6.6.8, 6.6.9, 6.6.10, 6.6.11, 6.6.12, 7.0.0, 7.0.1, 7.0.2, 7.0.3, 7.0.4, 7.0.5, 7.0.6, 7.0.7, 7.0.8, 7.0.9, 7.0.10, 7.1.0, 7.1.1, 7.1.2, 7.1.3, 7.1.4, 7.1.5, 7.1.6, 7.1.7, 7.2.0, 7.2.1, 7.2.2, 7.2.3, 7.2.4, 7.2.5, 7.2.6, 7.3.0


"Once the deployment server manages an app, it always manages that app." But once a deployment app is deleted from $SPLUNK_HOME/etc/deployment-apps (and deleted from the clients), it's no longer managed, right? If it's added locally to a client, the deployment server won't intervene to delete it, will it? If it does, this means there's a deployment server config file that keeps a list of deployed apps, so an admin should be able to edit the config file and restart the deployment server, no?

May 31, 2019

Yes, that would make logical sense. Also, if the deployment server removes the app from the client you can re-add it to the client manually as long is it isn't mapped in a serverclass and it should remain.

October 27, 2017

I like this line : Once the deployment server manages an app, it always manages that app, I have a question around that- if we delete the deployment client config to poll deployment server, then can we manage app individually in all client itself? Stop Deployment Server -> Comment config on client.

June 8, 2016

Was this documentation topic helpful?

Enter your email address, and someone from the documentation team will respond to you:

Please provide your comments here. Ask a question or make a suggestion.

You must be logged into splunk.com in order to post comments. Log in now.

Please try to keep this discussion focused on the content covered in this documentation topic. If you have a more general question about Splunk functionality or are experiencing a difficulty with Splunk, consider posting a question to Splunkbase Answers.

0 out of 1000 Characters