In azure web apps, there's a tab called "Deployment option" that allows a push from a github branch to azure web apps.
Currently I'm developing a website in Umbraco and is trying to get this option to work properly.
I have been able to successfully connect connect web app and sync the build from that branch from github.
However, after the deploy, the connection is wrong so I have deduced that it's potentially a connection string problem.
Therefore, is there a way to perform web.config transforms while using this deployment option?
Generally, you should not attempt to transform your web.config with connection strings during deployment, as doing this leaves you with physical files containing secrets (dangerous practice).
Instead, you need to set your connection strings using the Azure Portal (or ARM API). Just keep a 'dummy' entry in your web.config to mark that you have this key, and then override the value with the real connection string in the portal.
See doc for related info.
Related
Can I host a web application created on .net core 2.1 with sql server as database to azure web app service using CI tools / MS WebDeploy?
The following points I want to take care:
The application is using file system for temp storage and file storage
Deployment should be managed by some CI tools such as jenkins
After deployment, the app settings file should be modified with some keys/server details
Log files(stored on app root) should be accessible by application administrator
Is there a way to create a virtual directory same as in IIS and upload the files using FTP or similar protocols..?
All your doubts about deploying .net core 2.1 web app are achievable.
Suppose our projects are all completed and uploaded to github.
Questions and explanations about your concerns：
About the connection configuration using the database, you can directly configure it in web.config. If you are using azure sql server, find the connection string, set up the firewall, and pass the SSMS test, you can test the connection in the code. It can also be added in the Configuration -> Application settings -> Connection strings in the portal. After the addition, the priority is higher than the configuration in web.config, which will override the configuration and not modify the web.config file.
Regarding the use of file storage, you can use azure storage services or not. Looking specifically at the business, for example, very small pictures, documents and other files can be stored in the current program running directory, which is consistent with the original development at the code level. When publishing, you need to include the MyFiles file in the publishing process, or wait for the publishing to be completed and add folders manually in kudu, or the program can judge. It is recommended to use the program to judge that the subsequent program upgrade will not lose data.
The confidential information in the app settings file can actually be configured in web.config or appsetting.json. Make sure that the offline project is running properly when you are debugging locally, and then you can publish it. The rest is configured in the portal as in the first explanation.
The Log Files file storage can fully achieve the effect you want. It should be enough to set the owner permissions of this app services. For details, please refer to the official documentation.
Virtual directories and virtual applications, I have a better answer in another post here, you can refer to it.
Steps：
First of all, we can create a web app in portal and select .net core 2.1. Create appservices, and click Deployment Center when finished.
Follow the prompts step by step, and wait until the Action in github is completed, and the release is successful.
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.
We're using VSTS for building various Azure Web Apps and deploying them to different environments. During the release process we are performing transformations on Web.config files, using variables stored in VSTS for things like connection strings per environment.
We want to do a similar thing with Azure Functions but we've had issues. We've found that performing transforms to the appsettings.json file doesn't work. New key/value pairs added aren't working in Azure and changes to existing ones aren't being loaded in Azure.
I've looked through countless documents and have only found documentation stating that app settings for Azure Functions must be stored using the Azure Portal, or set using a PowerShell script during the release process. However, these solutions then expose connection strings and other secrets to anyone who has access to the Azure Portal, which is not what we want.
How can I provide app settings to Azure Functions, such as the AzureWebJobsStorage and AzureWebJobsDashboard values, without exposing them on the Azure Portal?
However, these solutions then expose connection strings and other secrets to anyone who has access to the Azure Portal, which is not what we want.
That is not a correct assumption. Only users that are contributors or admins on that Function App can see the app settings. And those same users can see all the deployed files, so if you have secrets in deployed files, they are equally visible.
The benefit of using App Setting over having your secrets in files are:
The App Settings secrets and encrypted at rest
You're less likely to accidentally leak a secret by downloading deployed files without realizing they have secrets.
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.
Is there a way with Kudu (or some other means) to retrieve the MySql connection information when I push with Git?
I know I can access it through the portal, but I want to write a build script that generates some files based on the Azure Web Site I'm going to push to. I also am aware of the App Settings, but I don't want duplication there.
I'm deploying a custom built WordPress instance where I want to build the wp-config.php file dynamically and not have it checked in to my repository.
Yes, your connection string is available as an environment setting.
To experiment with custom scripts use kuduexec (http://blog.amitapple.com/post/45675601255/azurewebsiteterminal)