Today I saw something really strange with my azure web site. My site was originally deployed using an ARM Template that configured various application settings.
After the initial deploy one of the settings was manually changed via the portal. Today that setting was reverted back to the original value used in the template.
Should that even be possible? I checked audit/activity logs to see if anyone changed it, and the audit logs are empty.
What is going on here, anyone have an idea?
That should not be happening. Azure will never automatically redeploy your ARM template.
Some possibilities that could have led to this:
Someone redeployed your ARM template, which would cause settings to be reset
Maybe when you made the setting change, it was never actually applied, e.g. if 'save' wasn't click, or some error happen.
I'd suggest applying you setting change again, and making sure that it is in fact applied. It should not get reverted by magic.
Related
I have deployed a javascript function app using VSTS Continuous Deployment and the function works but you can't see any of the code in the portal and the management screen looks seriously screwed up. By Function state it only has a grayed out garbage can instead of the grayed out enable/disalbe and the function key section is completely missing. The host keys section is empty even though I have host keys. This is frustrating because I can't set any function keys.
Similar to this one.
This probably means that your ARM template is incorrectly setting FUNCTIONS_EXTENSION_VERSION. Please make sure to set it to ~1. See this page for more info.
If your host keys fail to appear after you have deleted and redeployed your function app (I had this issue after upgrade from ~2 to ~3) then ensure all file shares and blob-containers (in used storage account) with the function app name are also deleted before trying redeploy. specifically the following containers:
azure-webjobs-hosts
azure-webjobs-secrets
Only by clearing these was I able to get a clean re-deploy - and host/app keys back again!
I am half expecting the answer to be delete everything and start over, but I figured I'd come here first after not figuring it out / finding an answer.
I created a Web App, and two deployment slots (staging / development). I created two DB's (DBName, DBName_Development). I forgot to tick off "Slot Setting" on the Development slot, and when I swapped it to Staging the configuration setting swapped as well. No problem, I figured, I will just put in the correct configuration setting and then tick off all the "Slot Setting" boxes so this doesn't occur again.
However, even after doing that, it appears my Staging site is still looking for the old DBName_Development database. Since it was changed it's not working. Not sure if I can even access the web.config for the staging site.
So, do I just trash everything and start over? Or am I missing some setting somewhere in the blades of Azure? I tried Restarting the Web App to no avail.
Thank you in advance for any suggestions/guidance/help.
You may start from Kudu console - it is the nice tooling for getting different things done with your web app.
So, if you suspect that some of your websites use something wrong or things mixed, you may go to the http://webappname1.scm.azurewebsites.net (note .scm.) and http://webappname2.scm.azurewebsites.net and compare the needed settings. If you will see that there is nothing wrong (or, vice versa, something is wrong), then you may proceed to the debug console and check the state of your web.config. And replace it if you will see that it will be needed.
Looking at the docs, it would appear that this would be super simple...perhaps it's something with my Azure Configuration. I'm simply setting up a demo project in Azure (which will be a Node app). I set up a Web App (have tried standard, basic, and free levels) and try to follow the instructions here which seem very straightforward.
https://azure.microsoft.com/en-us/documentation/articles/web-sites-publish-source-control/
But when I go to "All Settings" on my web app, there is no "Continuous deployment" option under the Publishing settings.
So I thought that perhaps I needed to set my deployment credentials. When I go to Deployment Credentials, it states that I need to create a deployment username and password. But even when I enter credentials that satisfy the requirements, the Save button is never enabled!
Any ideas on what is going on here would be greatly appreciated. I though perhaps it was some kind of regional limitation, but that seems unlikely as I've tried both West and SouthCentral regions. I'm convinced I'm doing something obviously dumb and just missing it.
Thanks!
I just encounter the same issue, no Continuous Deployment option and cannot save deployment credentials. I just switch back to classic portal and set it from there(click the app > go to dashboard > quick glance > Set up deployment from source control). After setting up and then I switch back to the new portal and the option appears. Really weird issue.
Not much to say...I basically deleted and totally cleaned up everything from Azure and started over and miraculously the 3rd or 4th time, the option just appeared.... Not very reassuring...no idea what altered the situation.
Same issue here, but just copy paste deployment hook (Settings/Deployment Source) and add it to the github repository webhooks and it worked.
I had a site running asp.net 5 beta4, and decided to upgrade to beta5. The site runs locally fine. I pushed the changes to master and it was picked up from bitbucket and deployed successfully.
When I try to hit the site in azure, I get a 500 Internal Server Error. I've tried a number of things, but can't seem to track down the root cause of the failure. I'm looking for suggestions as I'm hitting a wall. From what I've tried below it seems like some fundamental initialization is failing.
Here's what I've tried:
Enabling customerrors="off". I added a web.config to the wwwroot folder with system.web/customErrors mode="Off". I've verified that the web.config is populated correctly in the deployed wwwroot and had the appsettings containing the dnxversion etc merged correctly.
Customizing the custom error page, adding runtimeinfo. I have the following set in my Startup.cs:
app.UseErrorHandler("/Home/Error");. I also have set the error page to display the exception. This doesn't seem to be hit.
Attached to the remote process to debug. Visual studio eventually freezes, so haven't gotten anywhere with this.
Enabled application insights. This registers events when I debug locally, but doesn't capture anything from the azure instance.
Enabled application logs and request failure tracing. The detailed errors show a 500.0, without much detailed information.
Imgur
Imgur
I've also verified through the console that the runtime is set correctly to beta5.
Update:
I set the ASPNET_ENV to Development and it loaded with appsettings loaded via the azure portal. Setting ASPNET_ENV to something else isn't working. I also removed any custom code from startup.cs pertaining to the non-development environments, with no help. I'm still looking for a means of capturing the original error.
Assuming you are targeting DNX451 and not dnxcore50, there is a good chance Azure it still trying to run it against the beta4 runtime instead of beta5. If that's the case, you won't get a decent error message.
Try adding an environment variable in Azure "SCM_DNX_VERSION" and set it to 1.0.0-beta5. It looks like kudu was recently upgraded to support beta5 https://github.com/projectkudu/kudu/commit/55175a017779bf493ff8e6ce87b96dd1451f7d7b, so you might want to try to redeploy from bitbucket in the case that the Kudu team has already deployed this change.
For a little more detail, you can check out my previous answer (although it is very dated and references the old "K" names) here:
Deploying ASP.NET vNext beta 2 on Azure with Kudu
Every time you update to a new beta, you will have to update your SCM_DNX_VERSION environment variable.
I created a cloud service and tested it successfully locally. I added service configurations for stage and production. Here is a snippet of my staging-configuration:
and here my configuration-settings:
Then when I publish I set up the deployment as follows:
All this worked like 2 weeks ago. But now he deploys in VS and when I look into Azure Service Configure area it looks like this:
I played a little bit with the "Update development ..."-checkbox on the second screen but the result is the same.
So it ignores all the settings I made and just won't tranistion my configuration to the ine I named "CloudStage". My current Web PI tells me that I use Windows Azure SDK for .NET (VS 2013) 2.3. I don't get the point.
Edit
Some more things I observed:
No WADLogsTable and WADWindowsEventLogsTable is generated automatically in the staging storage.
I deactivated Remote Desktop because it was one of the changes I made to monitor the event log (which wasn't useful here)
I manually changed the connection strings in Azure Portal but it seems as if the worker is totally unaware of the storage (rebooted it with no success).
Edit
I recognized another thing. Here you can see a running deployment of my service:
See the warning-mark on the left? If I go to my Error list this is shown:
This warning is senseless since it tells me that I did everything the right way. My *.Local.csfg-files are pointing to the local storage. So?!?
This seems weird. Please check the in your ServiceConfiguration.CloudStage.cscfg to verify the expected values.
Have you tried updating any other property like Enabling Remote desktop? Does that get updated on your deployment? You should select the "Deployment Update" check box in the publish dialog. Now, when deploying to an existing Cloud Service, it should ask you if you want to replace it.
If you get the Object reference error every time you right click on project, there might be some issue with the Azure SDK set up.
I'm a little bit further now. What I did was:
Deleted all Services in Azure.
Deleted all Storage Accounts in Azure
Removed my Service-Project completely from solution (not the library containing the worker-logic).
Re-added storage-accounts in Azure.
Re-added services in Azure.
Re-added a project in the solution and added the worker-logic inside it.
Builded up all the publishing-stuff again.
Published it.
The first publish ended like the one described in my question. After I checked the "Update development..."-option in properties of my worker it finally took my transitions into the stage!
Now I recognized, that WADLogsTable was still empty. I hit the instance right in server-explorer and choosse "Update diagnostic settings...". There was an option "Transfer period" suddenly set to "None". This explained to me, why my table was empty and after I set it back to "1" my table is filling again!
Another funny thing beside: When I right-click my Cloud-project in the solution I get "Object reference not set to an instance...". When I just click it left and choose Build->Publish it works.
I just hope that I can help somebody with this. Lets see if it's stable now.
Edit: Yesterday it worked - today is still the same issue :-(.
When you get "Object reference not set to an instance.." for a CloudService project you usually have some kind of mismatch. It could be that a setting in the ServiceConfiguration is not defined in the ServiceDefinition. It could also be that there is a publish profile defined in the .ccproj file for the CloudService that doesn't exist. This might also be what is causing your problems with the different configurations.
So it turns out that the problem is completely on client-side. My Visual Studio (now with SDK 2.4) is doing something wrong. I set up a fresh installation with all the stuff needed :-( and there it works perfect. I'll try to determine if one of my extensions is causing the strange "Object reference not set..."-bug.
Repair-Installation of VS does not solve the problem btw.