Hello Team,
We need to set multi sites cluster with indexer clusters and search head clusters, and want to use deployment server. How can we use the deployment server in this?
I like this question. I was wondering if you could use one deployer and do site specific deployments.
splunk apply shcluster-bundle -target : -auth : --site1
Then deploy to site2 once you knew things looked good.
splunk apply shcluster-bundle -target : -auth : --site2
Nothing worse than pushing a bundle from one deployer to two sites and having an issue and now everything is impacted!! This would also be one less deployer to maintain.
I have this in deploymentclient.conf
in an app called foo_manual_master_deploymentclient
that goes to my cluster master so that I can manage Indexer apps from the DS, too:
# CLUSTER MASTER VERSION
# This file would have to be hand-copied to the $SPLUNK_HOME/etc/apps
# directory of the cluster master. Note that the cluster master itself
# will no longer be manageable by the deployment server, as the configs
# which are received go to the etc/master-apps directory, rather than the
# etc/apps directory.
[deployment-client]
# Set the phoneHome at the end of the PS engagement
# 10 minutes
#phoneHomeIntervalInSecs = 600 FIXME put this line back in before launch
phoneHomeIntervalInSecs = 60
# NOTE: Because of a bug in the way the client works when installing apps
# outside of $SPLUNK_HOME/etc/apps, these apps aren't listed as "installed"
# by the deployment client, meaning that taking an app away from the cluster
# master's serverclass won't remove it from the master-apps directory. This
# would have to be done by hand. Updates to existing apps will transfer
# from the deployment server just fine, however.
repositoryLocation = $SPLUNK_HOME/etc/master-apps
serverRepositoryLocationPolicy = rejectAlways
[target-broker:deploymentServer]
# Change the targetUri
targetUri = Your.Address.Goes.Here:8089
# These two options together make the cluster master a client of the
# deployment server, stashing the received apps directly in the master-apps
# directory. In this way, it becomes a proxy for the indexer config. This
# still requires positive action by the administrator to push the bundle
# from the cluster master, but it requires the least amount of interactive
# steps by the admin.
I was suggesting apps to be deployed on indexer cluster master/master-apps and search head cluster deployer/shcluster using deploy servers instead of copying manually and than push on cluster members.
Question is here how we manage forwarders by deployment server in muti sites
It doesn't matter where your forwarder is, Deployer server can push the apps on any forwarders until they are not behind firewall rules.
@saurabh009 yes you can set a new repositoryLocation
on Deployment Server side and repositoryLocation
on client side however you will still have to push apps from Deployer to SHC and form Cluster Master to Indexers.
also, iirc, you cant have the Deployment Server write to multiple unique locations, e.g. /etc/master-apps/
on CM and /etc/shcluster/apps
on Deployer
Why would you want to use Deployment Server for all? I will recommend against that approach
for each role, use the correct tool
to deploy apps to Search Head Cluster Members - use Deployer
to deploy apps to Indexer Cluster (Peers) - use Cluster Master
to deploy apps to forwarder - use Deployment Server
hope it helps
@lmjoin you will manage forwarders the same as in single site, considering you have connection between forwarders in site A to deployment server in site B.
are there any requirements / limitations that prevents you from doing so?
Thanks ,
You mean that 2 deployment servers one for sites1 and other for site2 . We use deployment server same as single site to push forwarders and shcluster cluster servers. No need to make anything change in deployment side for an files .
Thanks
Lalit
if there is connection, there is nothing you need to do
Do you want splunk deploy server to push apps on indexer cluster master and search head cluster master?
This can be achieved by specifying the repository directories.