I have multiple service configurations defined : local, testing, and production.
under properties of the web role, configurations tab, I set the service configuration to one of the options.
However, this does not affect the values that I get using CloudConfigurationManager.GetSetting(key)
Even when set to local, I get the value for the production configuration.
I assume that setting the active conflagration is done elsewhere, or that it does not apply when running local?
I could not find the answer in the pages below:
http://msdn.microsoft.com/en-us/library/windowsazure/ee405486.aspx
Azure role configuration management
Related
I would like to start using the deployment slots in my Azure App Services for a staging to production task. The problem that I am running into is I can't seem to find a way to do transformations on the web.config outside of the appsetting and connectionstrings. I seem to be missing something, but I need to be able to adjust other configurations, from logging levels, to other integrated config sections.
We currently have been using direct deployments from our build server with msdeploy and Parameters.xml file to do much of this work, however that won't work with deployment slots.
When you create the additional deployment slot, you can clone all settings from the existing instance, or dont copy anything. As per documentation:
"You can clone configuration from any existing slot. Settings that can
be cloned include app settings, connection strings, language framework
versions, web sockets, HTTP version, and platform bitness."
In the new deployment slot, under Settings > Configuration, you can specify any settings here to be specific to the new deployment slot by selecting "Deployment slot setting".
I'm using the Microsoft app service to deploy my web application,
and it have staging.domain.com and www.domain.com,
but now they are both link to the same redis,
How to I let them link to different redis, when I swap them?
I think it can solved by the app setting.
Is there any best solution or suggestion?
As shown here in the documentation, you can set different settings on different deployment slots in Web Apps, and set them "sticky". That will make them stay in the deployment slot. If you don't mark them sticky, they will swap with the app.
To configure an app setting or connection string to stick to a slot (not swapped), access the Application Settings blade for a specific slot, then select the Slot Setting box for the configuration elements that should stick the slot. Note that marking a configuration element as slot specific has the effect of establishing that element as not swappable across all the deployment slots associated with the app.
I have an existing App Service created in Azure, which has a connection string linking to the database, 'Easy Tables' configured, and a whole bunch of custom API methods and table definitions done via the 'App Service Editor'.
I'm at a stage in development where I need to use deployment slots, in order to have separate environments for development, test, and eventually live.
On creating a deployment slot, I have the option of 'Configuration Source' - where I can clone an existing application.
I select my existing app when I choose this option, however my Easy Tables or API configurations are not carried over with it, and it appears I need to set them up again?
Considering that I already do have everything set up in the App Service, how can I transfer the Easy Tables and API methods over to the new deployment slot without recreating each file one by one.
The end goal that I am trying to achieve is an exact duplication of my current web app - pointing to a separate database, having it's own collection of API calls and easy tables - all using the existing app as a starting point, with a URL different to the existing app.
however my Easy Tables or API configurations are not carried over with it, and it appears I need to set them up again?
Answer in short yes. According the Set up staging environments in Azure App Service, we could know the if we choose WebApp as Configuration Source, it copies the configuration info such connectionstring setting, appsetting etc. not the content of the WebApp.
There is no content after deployment slot creation. You can deploy to the slot from a different repository branch, or an altogether different repository. You can also change the slot's configuration. Use the publish profile or deployment credentials associated with the deployment slot for content updates. For example, you can publish to this slot with git.
Does anyone know what the difference is between these two? I've looked and can't seem to find a page that has a clear description of how they are different. The way Microsoft explains the two of them is very vague.
Definition documentation
The file contains the definitions for the roles that are available to
a cloud service, specifies the service endpoints, and establishes
configuration settings for the service.
Configuration documentation
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
The very first line in the link you included for service definition file (*.csdef) is very important - The service definition file defines the service model for an application.
As you know Cloud Services are Stateless PaaS Services, and simply put the service definition file tells Azure Fabric Controller how your VM should be created and configured for you. For instance, InputEndpoints defines the ports that must be opened in the firewall to allow incoming traffic. Another example is vmsize element which tells the Fabric controller to create a VM of particular size (Small, Medium etc.) for hosting your role.
Service Configuration file (*.cscfg) can be thought of as web.config or app.config equivalent for your roles (Web and Worker). This is where you define the application settings.
One key difference between the two files is that csdef file is included in the package that gets deployed so if you have to make any changes to csdef file (e.g. VM size) you would need to redeploy your code. cscfg file is deployed along the package and you can make changes to the settings on the fly without having to redeploy your code. So if you have a setting and you want to change the value of that setting, you can simply do so on the portal (or some other means) without having to redeploy your code. Please note that the configuration setting elements name is also stored in csdef file so you can't add or remove a setting from the cscfg file. You have to add/remove it from both cscfg and csdef file.
I wish to put up some workers roles (cloud services) to the staging section/configuration.
Can i publish them to there, but not get them to auto-start?
once they are up. I can manually stop the production one, manually start the staging one and test.
I don't want both running that the same time.
Is this possible?
Yes, it is certainly possible.
If you're deploying your services through PowerShell using New-Deployment Cmdlet, you can specify for the role to not start automatically by specifying -DoNotStart switch parameter.
If you're deploying your services through Visual Studio, I don't think this option is available.
If you're deploying your services through Create Deployment REST API directly, you can specify for the role to not start by setting value of <StartDeployment> element to false.
If you're deploying you services through Windows Azure Portal, you can specify for the role to not start by un checking the checkbox labeled Start deployment as shown in screenshot below.