I’m facing a small roadblock right now in our DSC implementation. Say we have 3 servers all managed using DSC, and they are in a NLB, so they are identical and have the same mof. We’re also using a Pullserver to distribute the mof.
So, we now have a new version of a web application to deploy, and in the deploy script(that DSC will use) we first take out the server from the NLB, install the new version, then reinsert the server in the NLB. Then the second node could start the same process.
Now, that’s all theoretical because with a pull server, we have no control of which server pull the new mof and when. They could actually pull the new mof all at the same time.
Is there a way to sequence such a thing, or have we met a case where we’d have to develop a push server instead?(I can hear the cringing sounds already from management on that)
Azure is not an option.(because I think the console in Azure might allow that, but it’s 300% impossible for us to use Azure)
Nope, pull server doesn’t work that way. At least not the low-functionality “sample” pull server Microsoft provides. If you were using something like Tug (open source pull alternative), you could code up whatever you wanted, since you write the back-end functionality there.
And no, Azure DSC doesn’t do this either.
Not sure why push is cringe-worthy, though. Most large organizations are using push as their primary means.
But you could also code up some custom resources to fake this, I suspect. “Is it my turn to update? If so, remove me from NLB, etc, if not, bomb the config run.” It’d take some work. Me, I’d lose the MS-provided pull server and invest in Tug instead. You could easily code in maintenance windows and stuff. Yes, it’ll be some work, but it’ll be less work in the long run and more maintainable.
Thanks for the reply. I wanted to make sure I wasn’t missing something somewhere.
I’ve downloaded Tug some times ago but haven’t had time to give it a serious look yet. This might be the time to do so and evaluate the work required.
Push is cringe worthy only because it would requires starting something from scratch, and we do not have a dev team for that kind of project. The push-server model itself would be alot more flexible, it’s only building something from scratch that is problematic(it scares management, and that’s a problem I cannot solve)
I also looked at Ansible and Puppet for their great tooling that you can install on-premise, and they would do the job perfectly, but I already have my plate full bringing the organization up to DSC, so I’m waiting before suggesting another layer.
Thanks for the precision about Azure DSC. I received the answer “you can do that in Azure automation” so many times that I thought this was in it too
There’s also an open source push server project. I don’t have the URL handy, but it’s fairly far along. Nothing new under the sun ;).
“On-premise” isn’t a thing :). You probably meant “on-premises.” Happens all the time. “Premise” is not the singular of “premises.” Sorry, I’m a writer, I can’t help it.
And yeah, the basic stance even in MS now, from what I can tell, is “if you want tooling and stuff, Puppet and Chef and those things are probably the solution if you can’t use The Cloud.” I’ve been deeply disappointed in how MS, outside the actual DSC team and Azure Stack, has kind of utterly failed to pick up on DSC. I think the company’s missing a huge opportunity, and the System Center family’s basic approach of “we’re not really developing this further and we’re only focused on supporting existing deployments” is a little shortsighted, for me. It seems like SCCM and DSC should be best buddies, but no.
Anyway, look into Tug. Eugene’s done a crapload of work on it, and there’s a PowerShell example provider which should be relatively easy for you to build on.
Azure Automation does have a feature that could help with this. It is on my list to document it as a tutorial. For now it is a bit buried in the cmdlet documentation.
