Deployment Architecture

When will a deployment server cause a remote app to be deleted?

Builder

We discovered that when we stop deploying a particular app to a group of servers, that app is eventually deleted (not just disabled) from the deployment clients. This we like :-).

Based on this, we had this idea of creating an app that exists on the deployment client after installation, but as soon as the deployment client gets real deployments from the server (which does not know about this temporary app on the deployment client) it would be deleted. In theory. But in practice that doesn't work. That sort of makes sense because there are other apps in $SPLUNK_HOME/etc/apps that don't go away either (search, learned, etc).

So I'm curious about what makes the deployment client decide that an app should actually be removed from $SPLUNK_HOME/etc/apps? Clearly some interaction with the deployment server makes it do that. Is it because the deleted app is one that's "known" on the deployment server and it is clearly not deployed to the target client so it removes it? The key being that it's a known app on the deployment server? Or is it something else?

Essentially the goal here is to create a temporary app that has only a valid deploymentclient.conf in it. It's valid in that it points to a host that will always have a deployment server, however, it could point this deployment client somewhere else via another another deployed app. This temporary app would really just boot-strap the client to start talking with a deployment server. Yes, I'm aware this is a little weird in that there are circumstances where the client could get orphaned if the communications get messed up. The problem for us is that creating a deploymentclient.conf in $SPLUNK_HOME/etc/system/local means we can't really remove it easily. (We don't have access to tools that would let us easily modify this dir for hundreds of hosts and it's easier to remotely control via deployments).

Thanks

Tags (1)
0 Karma
1 Solution

Contributor

We do exactly what you are proposing. Our install script moves a deployment-client app into place after installation is completed. The on start it knows and polls the deployment server for its apps . The deployment-client app contains the deploymentclient.conf.

This document helped me understand the deployment server app relationship.

http://www.splunk.com/base/Documentation/latest/Deploy/Updateconfigurations#App_management_issues

View solution in original post

0 Karma

Path Finder

Hi. I know this thread is several months old, but the topic is very current to me, as I'm wrestling with the same design choices now. And, a thought occurred to me that may allow the initial asker of this question to achieve the desired results. (And, if my idea is flawed, then at least I will learn something :-)...

My idea is this: On each of the clients, you create a "one-time" app that has the deploymentclient.conf, which allows the client to make the initial contact with the Deployment Server. However, the key idea is this: The Deployment Server does know about this app - this app is always on the Deployment Server, and it is always EMPTY. Thus, the first time the deployment client phones home, that "one-time" app is deleted because it doesn't match the deployment server's version of this app. Of course, the deployment server must give the client a new app which provides a new version of deploymentclient.conf, that now is managed by the deployment server.

Would this give the asker what is desired? If not, where have I fallen down?

Thx!
mfeeny1

0 Karma

Contributor

We do exactly what you are proposing. Our install script moves a deployment-client app into place after installation is completed. The on start it knows and polls the deployment server for its apps . The deployment-client app contains the deploymentclient.conf.

This document helped me understand the deployment server app relationship.

http://www.splunk.com/base/Documentation/latest/Deploy/Updateconfigurations#App_management_issues

View solution in original post

0 Karma

Contributor

Technically you don't. I do just in case we have to adjust our environment with out having to manually touch all the clients.
You are absolutely correct, you could set the deployment server locally at time of install and be done with it .

0 Karma

Builder

So then at least with the universal forwarder configuration, why would you even need a package to hold the deploymentclient.conf (assuming it's really going to be the "permanent" DS)? The advantage I thought I had with a package was that I could easily change the DS. But if I don't need to change it at all, I could just let the UF create the deploymentclient.conf in system/local (the windows one does that anyway) and be done with it, right?

0 Karma

Builder

Interesting. So bottom line what you seem to be saying is that the deploymentclient.conf that I seed our installer with should be the permanent one and that I should not need to be looking to find a way to swap the temporary app that carries it out with another one. Given the other options I have.

0 Karma

Contributor

In the case of a large environment you could keep the DS at HQ but then have endpoints for apps based on GeoZone. Check out the "endpoint" property here:
http://www.splunk.com/base/Documentation/latest/admin/Serverclassconf

Builder

We used to have a production and another non-production deployment server (DS). We've consolidated it now, but I can imagine a scenario where as we grow Splunk usage throughout the enterprise, we need more, maybe by geographic location. I want the flexibility. I also don't want to have to build unique versions of the "bootstrap" app for the deployment client. I like the idea of having any new install go to one DS initially and that DS could send it new configuration which sends it to its 'final' DS. I want something that can be used and then thrown away in favor of what's sent by the DS.

0 Karma

Contributor

Also, You could define different deploymentclinent apps and use server classes within the serverclass.conf.
Then explicitly define, with a whitelist, which client would get which deploymentclient app based on precedence.
This link explains the conf file precedence :
http://www.splunk.com/base/Documentation/latest/Admin/Wheretofindtheconfigurationfiles

0 Karma

Contributor

Are you trying to have more than one deployment server with different apps ? I'm not sure I understand your need to change deployment servers .However, if this is for fail over then I suggest you create a unique DNS entry for your deploymentserver instance Ie splunk-deploy.local etc. This way if , all you would need to do is edit DNS to point to the IP of the new server.

0 Karma

Builder

Hmm. That's not quite what I was hoping for. I had hoped that when the deployment client got connected to the deployment server it would have some way of saying "I don't think you should have that app" or "I don't know what that app is" and cause it to be deleted. This docs page would seem to imply that the only way for me to do this is to add it the app then delete the app from the deployment server everytime this goes to a new deployment client.

0 Karma