I have a web app that I need to deploy on different websites.
Conditions:
The application code is identical across all websites;
The application is database driven;
Different websites have to connect to different databases;
Connection strings for databases are defined in web.config.
How can I make different websites use the same deployment of the application with different web.config to pull data from different databases?
Here is what my control panel looks like now:
These websites are all applications that I publish separately out of Visual Studio.
The end goal is this:
I found this article: http://www.wadewegner.com/2011/02/running-multiple-websites-in-a-windows-azure-web-role/
It talks briefly about this in “Run the Same Project in Two Sites in the Web Role”
But it seems like this is supposed to be for a local setup and does not discuss how I can get this on the remote Azure instance.
This seems pretty straight forward. Not sure what exactly your issue is.
You can easily map (Deploy from source control) multiple Azure Web Sites to same source code repository. Then, if you are using VSO (Visual Studio Online), the linking will create a new CI build definition for each site. Then you only have to edit the Build Configuration to include the appropriate configuration settings for each environment.
If you are using other source control, you can still customize how the continuous deployment works. All the settings are configurable via a special .dpeloyment file. You can read more about these configurable settings here. Most important part:
SCM_BUILD_ARGS=-p:Configuration=Debug;PublishProfile=MyChainedTransform
You can change build configuration to match that of the target site.
Now, how to make this independently of the source control. Nice Kudu Gurus have thought about that, too. You can tweak these settings via Application Setting for the web site itself (check section Using App Settings instead of .deployment file:
Instead, you can use App Settings to set the same values that are supported
in the .deployment file. The steps are:
Go to the Configure tab for you site in the Azure portal
Add an App Setting called Project, and set its value to something like
WebProject/WebProject.csproj
Then in your other web site you can set Project to point to a different .csproj file.
So you add a new entry with key SCM_BUILD_ARGS and value -p:Configuration=<your_desired_configuration> in the Site Application Settings and you should be ready to go.
Disclaimer: have not check the solutions, but there is no reason why either should not work.
Related
With an Azure App Service, there is the possibility to overwrite setting values for Application Settings and Connection strings.
In the web.config, we have a custom HttpModule (in particular it is HttpAuthModule) which can have its own key/value settings. I suppose the same could occur for any config section such as logging frameworks etc.
How can we overwrite these keys (that live outside of appSetting section) in Azure App Services? We want a different value for different environments (different app services).
I think I understand your requirements, you want to just rewrite the config file host in the azure without updating the config file.
You could get it with the portal, there is a tool called "App Service Editor" in preview that lets you edit any of the files you've deployed. Config and app settings are exposed via the portal as well and can be modified without dropping to the app service editor tool.
I was able to do this through our deployment process (Azure Devops) and the Tokenize in Archive task (free on the marketplace).
Add variables of the same name, but different environment scopes in the variable section, and then have the first task for deployment in each environment run the tokenize task to replace where appropriate in the config file (not limited to the appSettings section).
Have you looked at using Azure Resource Manager (ARM) templates for your deployemnts?
Can get a jump start by hitting the Export Template blade in the portal on your app service, though this isn't ideal as it will hardcode some of the specifics (subscription, resource group, etc..) ALso here is some of the quickstart templates
Essentially the deploy.json will be the "template" and will have a separate environment parameters.json file containing those settings specific to your application.
In my Azure Web Site I have in my AppSettings section in Web.Config some references to files on my disk. When deployed to Azure those references doesn't count any more. I know that you can overwrite AppSettings in Web.Config in the Azure environtment. But what is the file structure there?
A couple of examples from my web.config that I have to solve:
<add key="DataMapPath" value="d:\inetpub\MyWebApp\App_Data\map.xml"/>
<add key="CuteWebUI.AjaxUploader.TempDirectory" value="C:\Temp\WebApp\Attachments\UploaderTemp"/>
The first file tells our code to look for the map.xml-file in the App_Data-directory.
The last one tells our upload-controll where to upload files. I maybe should have used Azure Blob Storage here instead but that would need some major refactoring of our code.
Is there som best practices on this topic?
Our WebApp is running in production today, but I want to try out MS Azure. But I doesn't want to do to many code changes to make it work in Azure.
I have also read you can spin up an Virtual Machine (Windows Server) but that is overkill for my needs right now. We may go that way in the end, but for this testing-purpose it should be made simple.
Any suggestions on how this could be solved? Someone done this before? I guess someone has. Indeed.
If I do have read and write access to the file system for my Web Site I maybe could use this:
Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "TheFolder");
This would be appropriate for both on-premise and Azure deployment. But then I have to do some changes in our code.
You have multiple options:
Option 1: Use the App Settings of your web app to set custom settings for your website.
Option 2: Create multiple versions of your web.config (Visual Studio supports this) and deploy different versions to Azure and your local machine
Option 3: Make your path's relative to the paths of Azure Web App's environment variables
There's a HOME environment variable in your Azure Web App that resolves to the equivalent of inetpub for your site. Your app data folder is located at %HOME%\site\wwwroot\AppData.
There's also a TEMP environment both on Azure Web Apps and on your local machine. You can make your second setting relative to the TEMP environment variable value.
Actually you won't have this kind of "control" using azure web sites. To keep your app as it is, use Azure Virtual Machines.
So my application is composed of a handful of separate .NET components that all run in Azure. To give you an idea of what's involved:
A main ASP.NET MVC5/Web API 2 REST service that runs as an Azure website (I think they renamed these to web apps?).
A SQL database that the main REST service uses.
Another internal Web API REST service that the main REST service talks to that runs as an Azure website.
An Azure storage table that the the internal Web API REST service uses.
3 scheduled jobs (just .NET exe's) that do work in the background and also talk to the main SQL database.
All that's running great in Azure right now. My problem is automating the deployment and configuration.
Right now it's all manual. I right-click and publish both web apps from Visual Studio. I build and FTP up the web jobs. The database and Azure storage already exist so I don't have to re-set them up.
But say something bad happens - a datacenter goes down or something. I'd like to be able spin up a new version of my app (with all those components) that is ready to go with minimal effort.
I'm pretty new to the world of Azure so I'm not sure where to start. What are my options?
You are looking to automating deployments in Azure. I recommend to use ElasticBox to solve it.
To achieve the automation you will need to create a box for every different service or component you need to deploy (a box is the abstraction unit that uses to define the installation and configuration of the deployment of a service or application in any cloud).
It's possible also to create boxes based on VM Instances, VM Roles, or Worker Roles and also automate the deploy of Microsoft SQL Servers. Let's say near every option offered by Azure.
Then with those boxes completed (that can be customized and reuse your legacy code from your previous manual installation), you can deploy the multiple vms with near no manual intervention, just one click or a command with some parameters.
A box includes the variables necessary for your deployment (you can set default values for those variables) and your legacy scripts (In this case probably PowerShell, but they could be bash, python, perl, java, or any other language)
When you deploy your boxes:
Creates a Cloud Service or VM in the location that you choose and with the Azure configuration that you preconfigured. It takes care of provision the vm in your Azure provider, or near any other cloud provider in the market.
Installs, configure files with your specified variables and execute your SQL or Web services that you have defined.
Other ways to interact with the service:
Jenkins' Plugin could be used to build a CI environment connecting your code updated or a Pull Request with automated deployments in Azure or any other public cloud.
Command line tool that enables to do VM deployments of your boxes and also you can manage your deployed vm instances with it.
Azure Resource Manager (ARM) is intended to solve exactly the issues you described.
The basic idea is that you use a JSON template to describe all your services. You can then give that template to ARM and it will create the services as defined in the template. If you want to make a change, instead of doing it imperatively (via powershell or manually in the portal) just update your template, pass it to ARM and it will make whatever changes are necessary to make the services match your template.
Some resources:
ARM talk at MS Ignite 2015
ARM template language reference
Quickstart templates on GitHub
Azure Resource Explorer - view ARM templates of existing resources
Resource Group Deployment Projects in Visual Studio
I think your looking for something to help you handel deploys to your windows Azure servers. If that is the case I recommend looking into Jenkins CI. There are many resources available online you can look into in terms of having Jenkins and Azure work together.
I'm trying to figure out how to have more than one solution for a website, where each solution maps to a subdomain on my Azure site?
For example, I have a site called www.example.com, which a solution for that. I'd like to have another solution which deploys to www.sub1.example.com. And yet another for www.sub2.example.com.
I'd like to keep one site, to reduce the cost - is this achievable?
Edit: This question is along the same lines, however the answer isn't really specific and didn't seem to actually solve the question: How to use subdomain in Windows Azure?
If my thinking is right, you are wanting to host (potentially) completely separate (solutions/projects) websites through one hosting package with azure.
We have a system where we use the deployment slots. These are currently in preview with Azure, and easiest managed via the new portal (also in preview), not the main portal.
Go to Azure,
Click into your website instance,
On the website instance dashboard, under the graph, there is a "quick glance" menu - The bottom item is deployment slots. (You may need to be on the standard compute mode for the Deployment Slots ability.)
Deployment slots are supposed to be used for staging/alternative versions of the main site, and can be assigned a custom sub-domain.
Within visual studio, projects can be uploaded to these environments using the standard azure publish method.
Hopefully this can be of some help...
Background
We are using a reporting tool which is .NET based.
The reporting tool uses a settings file which is a pain to update between environments (doesn't do transformations, etc.)
The reporting tool allows us to write .NET plugins to be run at certain times so I can modify the settings file on the fly
We have access to IIS and can add settings / connection strings at that level
Goal
I'd like to:
Simplify deployment by moving all connection strings & settings to the IIS server-level settings.
even our developers have IIS available locally so this won't be a problem for them.
Use the .NET plugin that I'm writing to connect to the server the app resides on and pull the connection strings and settings files.
Question
How can I access server-level IIS connection settings programatically from within a .NET class?
Notes / Things to Consider
This application does not use a web.config.
EDIT: While apparently the app doesn't use a web.config, one does exist when the app is deployed, so theoretically I could access it via the .NET plugin.
These are actually technically 5 different web sites. I'll be implementing the plugin the same way for each web site
The IIS servers are only used for this purpose, so I'd like the settings & configuration elements to be global across all of the web applications.
you can use Memory Cache, MemoryCache class has been changed to make it usable by .NET Framework applications that are not ASP.NET applications.