How does Splunk deploy apps?

In our last article we went over the structure of what in Splunk terms is called an app. I personally think that an configuration bundle would be a better name but he: potato potato 😉

Depending on the circumstances apps are deployed in a certain way.

Manual deployment

By manual deployment we mean that you are copying your apps manually on your Splunk server in the /opt/splunk/etc/apps directory. When you do this, make sure that user that is running Splunk (the splunk process/service) has sufficient rights to all the files within your app. Depending on the settings that your app contains a restart of the Splunk service might be needed. For configuration change a ‘debug refresh’ will be sufficient. (we will come back to this later).

This method is rarely used in a distributed production environment, but can come in handy in development scenarios.

Via the deployment server

As the manual method can be very cumbersome, Splunk came up with their own deployment solution which is called deployment server.

The way it works in a nutshell: right after installation preferably an app is put on a deployment client (a client that will receive configurations from the deployment server). Please create an app for this and don’t use the installation wizard to do so! You will thank me later 🙂 .

Then the deployment server check if it has apps for this client, based on the server class(es) it belongs to (the is are groupings of clients and apps). If it determines that it has a deployment package for that client, the client will be instructed to download all the apps and to restart Splunk if needed. In the case where the whole package or part of it on the client, the client will check if the checksum value of the package pushed by deployment server and the one in its /opt/splunk/etc/apps directory are the same. If they are, nothing will happen. If they are not, the client will download the package again from the deployment server.

This is perfect to use for non clustered components like stand alone search heads, universal and heavy forwarders.

Via the cluster master

When you have a indexer cluster, the way for you to deploy most of the configuration will be via the cluster master. The cluster master, being ‘the boss’ of your indexer cluster, will handle all the tasks for an app to be deployed across all the indexers. This way you are always sure that the apps within a cluster are consistent and up to date.

This method is for indexers that are part of a cluster only.

Via the deployer

When you have a search head cluster environment, you will use the deployer to deploy apps to all your search heads in the cluster. That is actually its one and only function.

This method is for search heads that are part of a search head cluster only.

App locations per deployment solution