April 11, 2014 at 12:38 pm #14496
Anyone who has used a DSC pull server(s) knows that you have to associate machines with a GUID in order for the pull process to work. And although generating and configuring GUIDs is a relatively trivial task, the best method for maintaining the proper associations between these GUIDs and their host(s) pairing may be not so trivial. Also, when talking about GUID management it is almost impossible not to discuss configuration management, since all configurations are assigned a node GUID in a pull server setup.
In my short time playing around with DSC I've come to the conclusion that you probably don't want to create a GUID for each endpoint you manage, rather you would proabably want to reduce the number of configurations you support by creating a GUID to represent a particular server function or role. By taking advantage of (and getting a little creative with) composite configurations, you can develop a single composite configuration that contains generic settings that are applicable to all servers and then develop others for specific server role/functions that can be layered on top of the generic one (e.g. Web Servers, SQL Servers, etc.). You can then create configurations that inherit these composite ones, assigning each of these a GUID.
I'd be curious to understand how others manage the GUID associations in their environments. Do you maintain them in a flat file stored on the network somewhere? Do you upload them to a database? Do you use custom Active Directory attributes?
I'd also be curious to understand how others manage their conigurations. Do you create a generic composite config for all servers, role specific composite configurations and then unique configurations that import these composite ones? If so, what is the process you use and how is it working for you and your customer demands?
Thanks in advance for sharing your thoughts.
April 13, 2014 at 1:22 pm #14506
I think we're probably a little early on for real practices to have emerged. I think, in the long view, we need to view DSC as a platform technology – not as tooling. We do need tooling around it. I can imagine Microsoft, for example, making this a part of SCCM: it keeps track of resources that you target to collections, and handles building composite resources from them, setting the LCM GUID, and so on.
So what you're asking about is, what kind of DIY tooling are folks using? Right now, probably little to none.
I'm not sure AD is the right answer for everyone; a key part of DSC is that it doesn't depend on AD. Now, in an environment where every node is in AD – sure, you could use an attribute there to track the machine's DSC GUID. That'd work.
I certainly don't think a spreadsheet is the way to go, but a SQL Server database would be a good solution. You could easily build a script that queried the database, built the necessary LCM MOFs, and pushed those to computers to configure them for pull.
I think the idea of generic configuration-resources, that get pulled into composite resources that also contain node- or role-specific stuff, will probably emerge as the "way to go." That said, we still need some tooling to help us view the resultant configuration, help detect conflicts, and so on. But right now I'm only aware elf a couple of organizations who are using DSC in production, and a couple more that are actively starting to build for it – we just don't have a lot of experience to draw on, yet.
But I think we're going to have to see folks trying all of these, and finding what works and what doesn't, to see what actually works.
I also think that, right now, DSC is good for limited deployments in an organization, so that you can start to get a feel for it, and not make a heavy initial investment in something that we know is going to be enhanced going forward. Start slow, with basic servers (like infrastructure servers), and get a feel for it. Find out what works and what doesn't.
April 14, 2014 at 11:59 am #14535
Yes – I'm trying to guage what others are doing out there and how they're meeting the challenges of their specific DSC deployments. But as you stated, perhaps not many are supporting this in any large production capacity right now and so my questions may largely go unanswered.
As the product matures and others begin to adopt DSC, I presume that more people will have experience by which to draw from and then the real information sharing can begin. Until then, I'll continue to play and search the web/forums for ideas/feedback.
If there are any organizations out there currently using DSC in a production capacity to manage their servers, I'd be interested in learning more about those deployments.
April 14, 2014 at 12:05 pm #14536
StackExchange is. Steve Murawski's their point guy – he helped me write The DSC Book.
You must be logged in to reply to this topic.