What's the best way to split up custom apps for deployment?

[Lowell]

Anyone have and recommendations or best practices to follow when deploying splunk apps in medium to large deployments?

I have a bunch of all-in-one apps that contains inputs, savedsearches, indexes, props (index-time and search-time settings), and custom views. As we're looking to split out our splunk deployment across multiple systems (Forwarders/indexer/search head), it seems like a good idea to split out the configurations so only the relevant parts are deployed to each component.

I'm looking for advice on how to split-up, name, and manage separate apps.

[araitz]

Selfishly, I would recommend you look at the unix app and TA (technology add-on). We do a few things in most of our apps that you can see examples of there:

• In your source control, create a TA package that contains the knowledge layer only - this will be deployed on forwarders and indexers
• In the case of unix, we create a thin UI layer for configuration on search heads in case they are deployed there and also provides collision detection since in general apps and their TA's cannot coexist on the same machine
• Create an app package that contains the relevant UI bits and conf files (e.g. view XML, web.conf if you are using custom controllers, or any custom modules/templates you are using)
• Use a build process to create the final TA .spl
• Use a build process to have the knowledge layer synced over from the TA package to the app package to create the final app .spl
• That way, you don't need to duplicate code such as inputs, props, etc in separate branches
• There may be files that need to be ommitted from this build process, such as app.conf
• There may be a need to merge config files, again through a build process - for example, props.conf may have index time settings in the TA that need to be merged with search time settings in the app

I'm sure there is stuff I missed or that you have questions on. Please feel free to add comments and I will update the answer.

[araitz]

We tend to just use myapp and TA-myapp. In general, the TA will have all the bits necessary to deploy on a heavy forwarder - if deployed on a light forwarder or on an indexer where the data is coming in cooked, they will have no impact.

With regard to our very simple python build system, we have talked about open sourcing it, but there is not really clarity around what we will do with it at this time.

[Lowell]

Any thoughts on naming conventions for the apps? MyApp-TA, MyApp-UI, MyApp-IDX? How do you handle the difference between deploying to a heavy forwarder and a universal forwarder? (Do you deploy the all the props setting to the universal forwarder and to the indexer?)

[Lowell]

Thanks for your feedback. We do use version control for the apps, but we deploy all the apps from a single deployment server, and there are never customized on individual systems. The idea of using a build process to automatically split up apps into different chunks is interesting, but probably more work than what I can justify...