Push mode with ResourceRepositoryShare - problem with custom resources

I’m trying to create a workflow using TFS Build / Release Management that pushes a configuration to target nodes prior to deploying an application.

In phase 1 of all this the target nodes are configured to be in push mode and configured with ResourceRepositoryShare so that custom resources can be imported from a file share. Everything works absolutely fine when the configuration is run from a development machine where the custom resources are already installed - my blog post here has all the details.

I’m now working on phase 2 where I want TFS to deploy and run DSC scripts on newly created target nodes where I’m expecting the custom resources to be installed from the ResourceRepositoryShare file share. However, there seems to be a chicken and egg thing because when the scripts are deployed and run on these target nodes they fail with “Could not find the module…” errors. It seems like the scripts are ‘compiled’ before they are run and thus fail, and don’t realise that they will be pulling the custom resources from the ResourceRepositoryShare location.

I seem to be going round in circles - am I missing something obvious? Cheers!

So, when the LCM receives a MOF, it does a sort of pre-scan to validate the MOF, detect duplicate resource keys, and make sure it has all the modules it needs. Missing any module will trigger an attempt to pull that module, if the LCM has previously been configured with a pull server location. That’s done via a meta-configuration MOF, of course.

So in your case, I’m guessing you’d be looking at two push operations. One to push a meta-config to the LCM, giving it a pull server location. Then, pushing the “main” configuration MOF, knowing that the LCM will be able to pull its modules from the pull server.

Many thanks for your reply Don. Apologies - I should have been a bit clearer. For the time being at least I’m working with Microsoft’s way of running DSC scripts on target nodes via the new web-based release management tooling in TFS 2015 Update 2 and VSTS. This sees the DSC script first copied to a temp folder on the target node and then run using the PowerShell on Target Machines task. Because this task is attempting to run the script on a node that doesn’t have the custom resources already in place processing stops with what I guess you might call ‘compilation’ errors.

My expectation was that somehow the script ‘compilation’ process would be - or could be - bypassed. I’m getting round this at the moment by copying the custom resources from a UNC using the task’s Initialization Script parameter but it would be nice to get push working with ResourceRepositoryShare if possible.

No, no bypass. I’m not sure how valid a model that really is, given how the LCM works, really. But anyway, you’d need to somehow pre stage the modules in order to run the script and produce a MOF. The LCM can’t help grab those from a pull server, either, at that stage.

Thanks for clarifying that Don. I have resorted to pre-staging the modules by simply copying them over and that does seem to work okay if a little inelegant. I’ll probably use this technique as a ‘phase 1’ and then start to develop something more robust and elegant for phase 2. Cheers!

I’ve been toying with “elegant” ideas myself.

One I thought of was to deploy an initial configuration script that sets up the LCM, and uses the native File resource to download the modules (file copy, which is all that’s needed) from someplace. So it’d produce two MOFs - the meta-config for the LCM, and then the “main” config for the file copy.

From there, getting your “actual desired configuration” to the node can be a little easier. I’ve got a prototype that actually deploys the “desired” configuration script in that same initial pass but doesn’t try to run it. A custom resource runs after the module file copy is complete, and actually runs that “latent” configuration to produce a MOF. Sort of a self-modifying sequence.

That sounds very interesting! I’m coming at this from a desire to create a workflow that encourages developers to write the DSC that will configure the servers their applications will sit on at the same time as writing the application code. Furthermore, I see the DSC residing in the same Visual Studio project as the application. I’ve got something that works because the script that copies the custom resources over as a precursor step also lives in the VS project alongside the DSC script but it’s another thing to remember to update when a new custom resource is used and another factor that could cause the deployment to a test environment to fail.

Are you likely to make your prototype available at some point?

Agreed. I think it’s a good pipeline. I do think, however, that the ultimately better goal is to set up a pull server in the test environment, and just inject a MOF - not a configuration script - into the build nodes to switch the LCM into pull mode. THEN push a configuration into the build node and compile the MOF. Or something along those lines. I do a great whiteboard with this.

Thanks - that definitely sounds like an option I’ll want to explore as I evolve this. In that scenario in Azure IaaS I’d probably hope do the first step as part of the VM creation process via the DSC extension for ARM templates.