Ees 5814 add premium storage accounts #5558
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR:
Config changes
Our Public API storage account is now set up as a Premium,
FileStorage
storage account, meaning that it is tailored towards providing file shares with extremely low latency.Currently all environments are the same, each provisioning a file share of 100GBs (the minimum amount allowed in a Premium storage account.
All other existing storage accounts (e.g. the 3 used by the Data Processor) remain
StandardV2
.In order to roll out these changes, existing Public API storage accounts firstly needed to be backed up, and then deleted completely, as these settings cannot be applied retrospectively.
Other changes in this PR
File share naming convention
As we had to rebuild any existing Public API storage accounts in Resource Groups prior to deploying this, it seemed like a good opportunity to update our file share naming convention, from
fs
toshare
which is the recommended one.Data Processor deploy process
I removed the Data Processor from Dev during the roll-out of this PR. As part of that, I noticed that the deploy of the Data Processor would fail if there wasn't already a deployment in the staging slot (i.e. it would fail the first time you tried to deploy the infrastructure, or after removing the function app for whatever reason).
To fix this, I've now set it to allow 404s from an endpoint check while waiting for the function app to come back to life after appsetting updates, which only occurs the first time the deployment takes place.
YAML template for checking existence of a function app
I broke this piece of logic out into a template as I though we'd need it multiple times. Turns out we didn't but it's neater being extracted out so I have left this change in!