Recently I had a problem with a service in Windows Azure, I've deploy the app to staging with a connection string to test DB, before I swap to production, i've change the connection string to production DB, that was on saturday, but today at my production environment the connections strings were to test DB.
Is there an schedule to recycle the instances in windows Azure?
If there is, Where did azure took the package to create the new instance?
Thanks in advance.
Azure can recycle your cloud service (Web and Worker) roles at any time and you don't have any control on that. When you deploy your service, it is stored in Azure storage and instances are created from that. Once deployed, you can't change the Web.config file because if redeployed, the new instance will use the original settings stored in your deployment package. It is best practice to store connection strings in the service configuration file instead of the Web.config file since you can change it at runtime.
Check this SO Q/A for the how to: Set the application ConnectionString in the Service Configuration instead of web.config in Azure
Related
The config value is stored in the Web.config. When I build the web project, the Web.config gets copied to the build folder as {ProjectName}.dll.config. Running the web app locally works fine, the config value gets read without problem using ConfigurationManager.AppSettings["{key}"];.
When I build the cloud service however, the {ProjectName}.dll.config does not get copied to the cspkg file that I upload and run on Azure. I would expect it to be in approot/bin. However there is a Web.config in approot.
Running on Azure the app fails when trying to read from the app settings using ConfigurationManager.AppSettings["{key}"];.
I am aware of CloudConfigurationManager but I would like to avoid having to maintain the configuration in both, Web.config and the cloud cscfg.
The service configuration file specifies the number of role instances to deploy for each role in the service, the values of any configuration settings, and the thumbprints for any certificates associated with a role.
In Solution Explorer, select Properties>Development>Service Configuration and set the value as Cloud.
Then, set the web role's Service Configuration as Cloud.
In setting tab, Add Setting about connection string and what you want to store.
The following code illustrates an example of how to access a connection string. Replace the placeholder with the appropriate value.
// Setup the connection to Azure Storage
var storageAccount = CloudStorageAccount.Parse(RoleEnvironment.GetConfigurationSettingValue("<ConnectionStringName>"));
For more details about how to configure Azure Cloud service roles with Visual Studio, you could refer to this article.
I have a CI/CD pipeline where on VSTS with following considerations:
Web App is an ASP.NET Core project and is hosted on Azure with an "staging" slot
Staging will be connected to a non-production/ synced database for testing
Connection string in Staging will be pointing to Staging DB
Connection string in Production will be pointing to Production DB
While doing hot swap, the connection string should remain same of the staging as it will become the new production.
The problem I'm facing is while doing the hot swap the connection string wil be picked from the Application Settings from Production Web App which will be pointig to Production DB.
The connection string can be changed in Application Settings on Azure Web App on Azure portal but it requires a Restart - which will negate the value of hot swap!
Any hints on how to replace the connection string while doing hot swap.
PS: We have the connection strings mentioned in Azure Portal's Web App > Application Settings
Thanks in advance!
Edit 1:
Here's a depiction of my consideration:
Please note that if you are using the same app service plan one environment can interfere in the other one. Having this in mind, and assuming you are using release manager, you could:
1 - Create two separated environments in a release, one for staging and one for production
2 - Create a variable with the same name as your connection string name in your web.config, one scoped for staging environment and the other for production.
3 - Add a Deploy Azure App Service task to each environment.
Then you could use the File transformation and substitution options and mark to make the transformation. It will use the name of your variable and replace it in your config file. Take a look at XML Transformation and JSON transformation https://learn.microsoft.com/en-us/vsts/build-release/tasks/transforms-variable-substitution?view=vsts.
And you can add the Application and configuration settings.
I asked yesterday where to store the connection string for a CosmosDBTrigger. It worked great until I had to push it up to Azure. Now the function isn't working at all. It works locally just fine though. There is no difference between codebases so the only thing I can think of is the connection string isn't be pulled from local.settings.json when on Azure. I mean, it wouldn't surprise me if that was the case since the file has the word local in it.
I tried putting the contents in the host.json, but that didn't work either.
How do you specify the connection string when your Function is running on Azure?
local.settings.json is not used in Azure. Instead, settings are taken from App Service Settings.
For your yesterday's example, go to Function App's Application settings tab and add a value with key DbConnString there.
If you are using func CLI, you can publish settings from local.settings.json file to Azure Application settings by running
func azure functionapp public <App> --publish-local-settings
You need to put it in the Application Settings for the function app. These can be setup using the Azure Portal or deployed as part of the ARM template I believe.
Azure Application Settings
I've got few Cloud Services that have both Production and Staging slots. Since I hadn't deploy the environment and I'm not aware of what exactly stands behind them - can I delete the Staging slots to lower the cost because they are billed the same as Production slots? And if I download the config files, would I be able eventually to import them back in Azure?
You can directly deploy to the production slot of a Azure Cloud Service. If you have more than one role instance (you are running multiple role instances to get the stated SLA right?), Azure will automatically upgrade each role instance independently of one another.
While this saves you a little bit of money by not deploying to the staging slot, we found the staging slot deployment to work with our continuous integration strategy better.
Reference : How to Manage Cloud Services
Can I delete the Staging slots to lower the cost because they are
billed the same as Production slots?
You should be able to delete staging slot without impacting the production slot. However if you have some users that are connecting to the staging slot, they will no longer be able to connect to the application once you delete the deployment from staging slot.
And if I download the config files, would I be able eventually to
import them back in Azure?
Merely download the config file is not going to help as you would also need the package file. What you should do instead is invoke Get Deployment Service Management API REST operation. What it will do is copy both the config file and package file in a storage account of your choice.
I have a webapp deployed to an Azure Web App. In the webapp I am using MembershipReboot, with Entity Framework. The Sql Server database is also in Azure.
It is deployed via BitBucket integration and continuous deployment, in a staging slot.
As part of the build process, a web.config transfrom, changes the connection string value to "dummy".
I set this the connection string, named MembershipReboot, in the Azure portal.
When I browse to the application, I get this error:
Format of the initialization string does not conform to specification starting at index 0.
If I change the connection string in the web.config, to be the Sql Azure connection string the app loads fine. If I set it back to "dummy" then I get the above error.
This indicates to me that the connection string set in the Azure portal isn't being picked up by the application.
I created this Azure enviromnent using the ARM template deploy, mixed with some Azure powershell commands. I've tried creating the environment by hand too, with the same issue.
Any ideas on what to look at next?
edit: Just to say, the correct connection string is viewable within Kudu.
Managed to fix this.
It was due to StructureMap being invoked, and creating a database context (via global.asax), before the environment was providing the correct connection string.
In our case, the app was mixing Owin startup and global.asax Application_Start, we had to move the global.asax startup into the Owin startup, and not allow the database context to be created during that startup. I suspect we could have just done the latter.