Using Ensure-AppSetting on a config file from a ProGet deployment causes drift to be detected

Hi,

Sorry to keep asking so many questions...

New scenario: I have an application packaged in ProGet and being deployed to a server. The ProGet package includes a web.config file in. This has various 'static' settings - assembly references etc - along with some settings that will be specific to the environment - connection strings etc.

I have created a server role with a configuration with steps to:

Create a directory
Deploy the ProGet package
Apply the environment-specific settings in the web.config

Pretty much the same thing as the tutorial here:
http://inedo.com/support/tutorials/otter/deploying-aspnet-and-windows-service-applications-with-otter

My problem is - or appears to be - that after the remediation job has run, and the Ensure-AppSetting statements have been applied, the web.config doesn't match what is in the ProGet package, so it's considered to be in drift status.

Is there something I can do so that when Otter is checking for drift in a config file, it will apply Ensure-AppSettings statements to the ProGet source file before it compares it to what is on the server? Or is there some other way around this?

Thanks again!

Andrew

Product: BuildMaster
Version: 5.8.1

I think the best solution for this in terms of Otter is to add exclude masking for the Ensure-Package operation so that it ignores certain files, e.g. you could specify **.config to ignore any differences in files that end with .config. This could also be extended to ignore logs directories or other non-package items.

I've had one of our devs create an issue for this here: https://github.com/Inedo/inedox-inedocore/issues/4

Thanks Tod!

The workaround of excluding the web.config file doesn't quite meet the requirement here, as we then won't be able to detect drift in the non-variable parts of the web.config.

For example, say our web.config looks like:

<web.config>
	<appSettings>
		<add key="ConnectionString" value="ConnString" />
	</appSettings>
	<runtime>
		<assembly name="system.web.mvc" version="4.0.0.0" />
	</runtime>
</web.config>

(This isn't strictly accurate, just an example).

The connection string varies from environment to environment, so is ideally controlled by a variable within Otter. However, the assembly version might change as a result of something done by the development team - or we might add new assembly references etc (or any of a number of other types of change in the web.config).

I do however appreciate the technical challenges with this approach - in fact I'm not sure where you'd begin to implement it, as I assume you'd have to do something like:

Extract the ProGet package into a temp directory
Run any operations that might modify any of the files in the ProGet package in the temp directory
Compare the existing files to the temp directory

Which seems like it could be a messy process!

Would be interested to hear your thoughts on this - I'm always open to being told that I'm doing things wrong, so if there is a better way, that would be great!

Thanks,

Andrew

Thanks for the detailed write-up on the situation; we have certainly not forgotten about this. It's definitely a problem that we want to solve, so i'm hoping you can help :)

To generalize it, the situation is that we are building something using two conflicting sets of instructions.

Ensure a solid green circle
Ensure a white "H" within the green circle

Step 2 undoes part of Step 1, which causes a "drift" problem.

Other configuration management tools (Puppet, DSC) have tried to solve this by building a complex object model of configuration, and then checking the "processed" model against actual configuration. Of course that doesn't actually work in real world scenarios, which I why we (and other CM tools) didn't follow the graph model.

In any case, the only way "proper" solve this is to have a single step ("Ensure a solid green circle with a white "H" in the middle", or "Ensure this package with these app settings"), but now you're constrained by the limitations of what that step template ("only this font", or "only in web.config")... and will run into the exact problem as soon as the single-step solution doesn't fit your requirements.

So this means, we need to find more "improper" means to solve it in a general manner. Tod's suggestion was one way of doing it... but as you notice, it's not good enough.

What about externalizing those configruations into a different file?
What about using Romp to install the package, which has the built-in variables?
Some sort of way to say "ignore drift" in this step?

This is where we're very open to input.

Hey Alex,

Thanks for the follow up!

I did continue working on this, and got to a point where I'm happy with how it is working. I was in contact with Karl about it too via email, and sent him some details, but for reference for others who find it useful..

We went with the solution of putting the config into separate files, using the 'configSource' option as needed to specify references to external files.

Further to that, we created an extension for Otter to allow us to manage the settings in those files - similar to how the 'EnsureAppSetting' thing works, but allowing an XPath expression to be used to identify the precise element in the config file to check. That meant we could use it for e.g. files that hold connection strings.

(I do intend to publish that extension to the Den at some point - haven't so far gotten around to it though).

Let me know if you would like any more detail on what we're doing!

Thanks,

Andrew