Azure DataProtection not finding Key in Key Ring

[johnden12]

I am trying to configure and test the use of Orchard Core in a Service Fabric Environnement. I have enabled Azure DataProtection and AzureShells to ensure that no configuration is dependant on information within the Service Fabric cluster as this will get deleted in the event of a cluster restart.

In order to simulate this, I stop the service, delete the app_data folder and restart it. The AzureShells seems to work ok, however it appears unable to locate the Dataprotecton key from the blo container even though the DataProtectionKeys.xml file is present and contains the key that is reported as unfound.

Is there a something that I am missing

[deanmarcussen]

Generally the data protection module would have created the key that isn't being found, so it seems odd, that it creates it, but then doesn't find it.

How did the xml file get into blob storage? i.e. was it created by the module, or did you copy it in from the existing App_Data folder?

I'm assuming you have enabled the module through the admin?

[johnden12]

@deanmarcussen Once I have started the Service Fabric cluster and deployed the OrchardCore application, I enabled the module via the admin interface. It was the module that automatically generated the file, and since it was the module that created the file, I am assuming that the azure blob configuration is correct for the dataprotection elements?

Once the module is enabled the site reloads, I am assuming to take into account the changes with the new key. I can log out and log back in again and everything works fine. It only stops working when I remove the local App_Data file, in order to simulate the cluster starting a new instance of the Orchard Core service.

[deanmarcussen]

I am assuming that the azure blob configuration is correct for the dataprotection elements?

Yes, sounds like blob is connecting ok.

It only stops working when I remove the local App_Data file

This bit I don't understand. By the time you're using blob, the App_Data\Sites\Default\Data-Protection-Keys folder, is useless, and the folder and contents can be removed.

It shouldn't get recreated.

You also said you were deleting the entire App_Data folder at some point.

Doing that should put you back into running Setup.

You'll need to have at least the folder present to avoid that.

I feel like I'm missing something of your process.

[johnden12]

You also said you were deleting the entire App_Data folder at some point. This might the issue.

All applications on a service fabric cluster (default & recommended configuration) are deleted if the cluster stops. This is due to the fact that the virtual machines participating in the cluster use local SSD for performance reasons.

This is what I am trying to simulate in order to ensure that I can recover the content and information from OrchardCore when the service fabric cluster restarts. I need to be able to configure all required startup information for the CMS outside of the cluster.

It was my understanding that this was the role of the Azure Shell & Azure Dataprotection elements. Allowing to provide information for a scale-out farm through some sort of reliable storage which can be configured through the appsettings.json or other means of configuration to provide the required information.

It seems however that there is still some sort of dependency on the App_Data folder, which I have not yet been able to identify.

[deanmarcussen]

it seems however that there is still some sort of dependency on the App_Data folder, which I have not yet been able to identify.

Let's clear that up then.

Shells, and DataProtection allow you to move those pieces of data outside the App_Data.

That's it, other things still use it. Notably lucene. And/Or Media depending on whether you use blob storage.

In terms of cluster restarts.

Make sure you always have an empty App_Data folder. Otherwise Orchard Core will try and run Setup again.

Or use the ORCHARD_APPDATA environment variable to mount it externally.

But I would just put the empty folder in.

It's likely the error message you were seeing maybe related to a cookie for the antiforgery token. So clear your cookies should remove that issue.

[johnden12]

Or use the ORCHARD_APPDATA environment variable to mount it externally.

That was my original configuration, I setup the ORCHARD_APPDATA to use à mounted azure fileshare, however every time the cluster restarted orchard core didn't seem to find the App_Data information and presented the setup screen. Hence I started looking at other options.

I will try it out with both the mounted fileshare & Azure Shells and Dataprotection, to see if this works.

[sebastienros]

Needs a doc to explain how to configure OC to use Azure services to get rid of the app data folder. Lucene remains in the app_data so it's necessary, but tenants, content types, data protection keys should go somewhere else.