Deployment Architecture

What can we not do without a deployment server?

aanataliya
Explorer

I am new to Splunk. Our organization is using Splunk Cloud and I have been asked to configure 200+ EC2 instances to forward log. I am configuring Universal forwarder on client systems to directly forward log to Splunk Cloud. I am not planning to have deployment server.

I would like to know, will I face any issue in future without deployment server? What are the things which cannot be done without DS? In future, if I plan to use DS, what possible changes do I have to make?

Thanks.

0 Karma
1 Solution

FrankVl
Ultra Champion

I don't think there really is something you cannot do without a DS, apart of course from taking benefit from the centralized management of configuration that it offers. So without a DS, each time you want to change some config on the UF (e.g. inputs / outputs) you need to touch each UF, or use some other automation tooling to do that for you.

If you later want to introduce a DS, key action to do is make the UFs a deployment client of that DS.

Depending on how you deployed the manual UF configs, you can or cannot take control over that from the DS. For example: DS cannot take control over config defined in system/local on the UF. So if you want to keep options open for the future, avoid making any changes in system/local on the UF, but bundle configuration files into apps, that you put in etc/apps on the UF. That way, you can later on have the DS take over control of those apps and manage them centrally.

View solution in original post

dpetracca_splun
Splunk Employee
Splunk Employee

Good simple example of using a deployment server here: https://docs.splunk.com/Documentation/MSApp/1.4.3/MSInfra/Createthesendtoindexerapp

This will give you better idea of why/when you would want to use a DS

0 Karma

FrankVl
Ultra Champion

I don't think there really is something you cannot do without a DS, apart of course from taking benefit from the centralized management of configuration that it offers. So without a DS, each time you want to change some config on the UF (e.g. inputs / outputs) you need to touch each UF, or use some other automation tooling to do that for you.

If you later want to introduce a DS, key action to do is make the UFs a deployment client of that DS.

Depending on how you deployed the manual UF configs, you can or cannot take control over that from the DS. For example: DS cannot take control over config defined in system/local on the UF. So if you want to keep options open for the future, avoid making any changes in system/local on the UF, but bundle configuration files into apps, that you put in etc/apps on the UF. That way, you can later on have the DS take over control of those apps and manage them centrally.

Get Updates on the Splunk Community!

Introducing the Splunk Community Dashboard Challenge!

Welcome to Splunk Community Dashboard Challenge! This is your chance to showcase your skills in creating ...

Built-in Service Level Objectives Management to Bridge the Gap Between Service & ...

Wednesday, May 29, 2024  |  11AM PST / 2PM ESTRegister now and join us to learn more about how you can ...

Get Your Exclusive Splunk Certified Cybersecurity Defense Engineer Certification at ...

We’re excited to announce a new Splunk certification exam being released at .conf24! If you’re headed to Vegas ...