Deploy apps and configurations
Deploy apps and configurations
1. Put the new or updated content into deployment directories on the deployment server.
2. Inform the clients that it's time to download new content.
Put the content into directories on the deployment server
You place the deployment apps into individual subdirectories in a special location on the deployment server. From there, the deployment server can push the content to its deployment clients. 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, with the same name as the app itself. The app name is specified in
Note: On the deployment clients, the downloaded apps reside in a different location, which defaults to
$SPLUNK_HOME/etc/apps. This location is configurable in deploymentclient.conf, but, for most purposes, you should not change it from the default.
This example creates a deployment directory in the default repository location on the deployment server, for an app named "fwd_to_splunk1":
mkdir –p $SPLUNK_HOME/etc/deployment-apps/fwd_to_splunk1/default
Place the content for each app into the app's subdirectory. To update the app with new or changed content, just add or overwrite the files in the directory.
Inform the clients of new content
When you first configure the deployment server, and whenever you update its configuration by editing
serverclass.conf, you'll need to restart or reload it for the changes to take effect. The clients will then pick up any new or changed content. Instead of restarting the server, you can use the CLI
reload deploy-server command.
This version of the command checks all server classes for change and notifies the relevant clients:
splunk reload deploy-server
This version of the command notifies and updates only the server class you specify:
splunk reload deploy-server -class <server class>
splunk reload deploy-server -class www
In this example, the command notifies and updates only the clients that are members of the "www" server class.
Confirm the deployment update
To confirm that all clients received the configuration correctly, run this command from the deployment server:
splunk list deploy-clients
This lists all the deployment clients that have contacted the deployment server within the last two minutes. It specifies the last time that they successfully synced.
App management issues
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 instead to tell the deployment client 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" in the
repositoryLocation 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's
repositoryLocation, 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 search app. By managing the search app through the deployment server, you are preventing users from saving any unique searches on their search heads. And since there's no way to tell the deployment server to stop managing an app, you're effectively stuck with that decision.