Deploy Multiple Configurations Simultaneously

DSC
1

Hello,

We’re using DSC Push deployment as a part of our CD pipeline similar to what’s described here.
We have multiple components that we deploy on the same server.

Today we can only deploy one component at a time because each deploy runs a Start-DscConfiguration command with a different configuration.
I’ve read about partial configurations, and the recent article regarding DscLcm module, but non of them doesn’t help us with our problem.

What would be the best way to deploy multiple configurations deployment simultaneously?

Thanks,
David.

2

This is a great scenario for Composite Resources. Feedback from customers has largely been that this design is a preferred over Partial Configurations because it encourages collaboration around a single route to production.
https://docs.microsoft.com/en-us/powershell/dsc/authoringresourcecomposite

3

Thank you very much Michael!, I’ll review your suggestion and share my conclusions :slight_smile:

4

Hello Michael,

After I’ve reviewed the MS doc you’ve shared, and this great article:
http://duffney.io/UsingDscCompositeResources
And this channel9 episode:
https://channel9.msdn.com/Series/Advanced-PowerShell-Desired-State-Configuration-DSC-and-Custom-Resources/06

As far as I understand Composite Resources still evolves a Start-DSCConfiguration to apply the multiple configurations.

Can you please try to help me out to understand how can I implement the use of it as a part of my release pipeline?

Thanks,
David

5

Hi David,

Composite Configurations allows you to compose blocks of configurations together (xFile + xRegistry + WindowsFeature …), without the need to create one configuration per component.

From your post I understand that you have different Components, each generating a MOF, that you need to apply to a server… This is the way Partial configurations works, which may not be the best approach.

I’d recommend having a look at my answer to this post here: https://powershell.org/forums/topic/howto-optional-configuration/#post-96234

In short, you could generate one MOF per Server, and use Composite Resources to avoid duplicating code in big Monolithic configurations. I imagine your current ‘components’ configurations should be transformed in Composite Resources, and you then need a system to ‘link components to roles, and roles to nodes’: That’s part of the DSC Configuration Data Problem, but there’s a way to compose role.

There’s a full example of a pipeline using this model here:
With example of Composite Resources in this folder, which works with the Configuration Data in that folder.

Have a look at the workshop for more details and links on this release pipeline.

6

Hello Gael,

Thank you for your information, I’m still trying to process the entire information you’ve provided.

I’ll keep you posted,
Thanks!

7

Hello Gael,

I’ve tried to get into details of the Datum project and the documentation you’ve provided.

But then I’ve came across VSTS deployment groups as mentioned here:
https://blogs.perficient.com/2017/08/28/deployment-groups-in-visual-studio-team-services/

Can you think of a reason why I shouldn’t go for this instead?

Thanks,
David.

8

This is a larger question than it looks, but you should experiment, bearing in mind you’ll most likely change it as you learn.

Technically, you can use the VSTS agent as your DSC Pull agent instead of the LCM (some have done this with Octopus Deploy for instance, search a DevOpsGuys article by Dave Wyatt iirc), and code whatever logic you need in there. So you can make it more flexible, that’s cool…

Should you do it now?
If it’s the quickest for you to improve your current situation, maybe. Get a minimum viable product out, and learn from it. Understand that it will have to evolve (or it might become tech debt).

Would I do it?
Probably not. Where would you define those groups? How could you re-provision them from code? How can you make them visible, easy to change, enforced? Would those group definition live with the rest of the information? How would you apply the components one by one? Still as independent MOFs?

There’s many challenges to be solved that the LCM and pull model have already (defining intent, eventual convergence, policy-driven, immutable artefacts…), and best practices around Config Data management made easier using Datum…

So it’s one of those: “it depends”… Context is everything.

9

Hi,

Thank you for the quick response, I appreciate it.
I think the questions you’ve mentioned will help me to get a better understanding now.

Once I’ll get into conclusion I’ll share it with you guys.

Thanks,
David.