we want to deploy a webrole on the Azure cloud service (PaaS)
we have multiple Virtual Applications that have exactly the same codebase (dlls) but different web.configs
this leads to multiple time the same dll's in the package to upload; resulting in a very large package file
is there any way to share the bin folder for these 'same' Virtual Applications to minimize the size of the package?
greetings,
Tim
Create a cloud application with one web role containing the codebase and additional web roles containing only the Web.config for the multiple virtual applications.
On ServiceDefinition.csdef, define the virtual applications for the roles as required.
Set a startup task to copy the contents from the complete web role to each of the additional virtual applications. This will be executed at role initialization time, with administrator privileges.
This way your deployment package won't need to include multiple copies of the same artifacts, and the virtual applications will be set up when the role instance is initialized.
Is it possible for you to load your configuration settings based on the host header or incoming request?
In the past we had configuration settings stored in Azure Blob Storage that were loaded (and then cached) based upon the host header. This allows you to load what is identically the same site except for the specific settings for that client.
In essence this is a multi-tenant application.
Related
I want to understand how does this Web / Worker role under cloud service work. As per my understanding, we have to define the required Web / Worker role instance count in CSDEF file, and Azure will create VMs (Instances) under the cloud service automatically. How about the application is updated and new code is deployed? Will the existing instances destroyed and new instances will be created or only the changed code will be updated in IIS? How does it work in the backend?
Note: Basically I have four instances in a web role and I want to create around 20 local user accounts in the VMs to manage it by different teams. I want to ensure the accounts do not get deleted whenever deployment is done.
Basically I have four instances in a web role and I want to create
around 20 local user accounts in the VMs to manage it by different
teams. I want to ensure the accounts do not get deleted whenever
deployment is done.
Simple answer: Don't Do This!
Azure Cloud Services are essentially Stateless Virtual Machines. What that means is that anything you do in the VM (like installing software etc.) after a VM is created for you can be removed. Though this doesn't apply when you simply deploy the new version of the code but there are times when Microsoft takes down faulty VMs and stand up new VMs for you automatically from the last package file you used to create/update the deployment. In this scenario, any changes you have made will be lost.
Cloud services should be considered stateless. The disks won't necessarily be destroyed on every deployment, but you must plan for it. Any configuration or operations you wish to perform prior to the role starting up must be defined as a startup task in the CSDEF file.
(Note that I'm using the new "blade" Azure Portal exclusively and use the new terminology, so avoid words like "Azure Website" as they do not apply here).
In the Portal I created two Azure App Services, "foo-production" and "foo-staging" - both exist in the same Subscription and Resource Group, and share the same App Service Plan. These App Services represent the production and staging deployments of a straightforward ASP.NET web application, which runs as a normal website.
The App Service Plan is "Basic: 1 Small".
My understanding is that when you use Azure App Services with a Basic or higher App Service Plan, that the Plan represents a VM which I'm able to host as many IIS websites as I want on - these IIS websites are represented in Azure as Azure App Services.
Given this, one would assume when I access the filesystem of the VM in Kudu ( https://yourwebsite.scm.azurewebsites.net/DebugConsole ) that I would be able to see each website's files under some common root directory.
However when I access the Kudu console for the foo-production website, I see that its files are in D:\home\site\wwwroot and files for foo-staging are not to be found.
If I'm understanding this correctly, it means that Azure actually created a whole new VM just for each website and that websites cannot share a filesystem - and that I cannot have a more advanced Azure-managed IIS configuration - I'd have to create my own self-managed Windows Server VM.
I can understand the motivation behind a separate VM for each website, it just seems wasteful - Windows Server requires at least a gigabyte of memory for each VM, yet my website is largely just static files (but I can't use a Shared App Service Plan because I need some of the more advanced functionality). That can't be economical for Microsoft then.
How can I have multiple Azure App Services in an Azure-managed environment share the same VM? Or am I thinking about it incorrectly?
To avoid an X/Y problem: I'll state that my primary concern is the persistence of files. The web-application I'm deploying stores uploaded files to a subdirectory of the webroot and those files should be there permanently. There is ambiguous information out there: some people suggest websites (and all their files) are actively destroyed and recycled and that Azure Storage Blobs should be used. I would like to use Azure File Shares, unfortunately I get ACCESS_DENIED errors when using WNetAddConnection2 and some users report that Azure File Shares cannot be used from within Azure App Services - though I cannot find anything authoritative from Microsoft about this.
If they are in the same App Service Plan, they are running in the same VM. Try typing hostname in Kudu Console for each and you'll see the same machine name.
But note that they each run in a different sandbox, which prevents them from seeing each other's files. Folders like d:\home are virtualized, and are actually pointing to network shares. So you can't use that to make conclusions as to the machines are the same.
As I answered here, all app services within a plan run in the same set of VMs, sharing all compute resources.
You assumed each app service within a plan shares files with all other app services. This is incorrect: Each app service will have its own set of files, in d:\home for each app service. If you need to share files, you'll need to use something external to App Services, like Azure File Service (an SMB share). Azure File Service is separate from the space created for you on a per-app-service basis.
An Azure "App Service" is analogous to a "Container" (Docker terminology). Although it's based on a VM, it's much lighter weight than a VM itself. For example, you cannot RDP into it.
An Azure "VM" is a full-fledged virtual machine. The OS can be Windows or any of several different flavors of Linux.
You can get more information here:
Azure App Service, Cloud Services, Virtual Machines, and Service Fabric comparison
Here is an excellent article that compares Web Sites (one example of an App Service), Cloud Services, and VMs:
http://www.c-sharpcorner.com/UploadFile/42ddd2/azure-websites-vs-cloud-service-vs-virtual-machines/
Azure Websites
Azure Websites has very little responsibility to complete, and
relatively less control. It is the best choice for most web apps.
Deployment and management are integrated directly into the platform we
get.
Azure Cloud Services
If you want more, web server like environment you might want to go
with Azure Cloud Services. You can remote into your cloud services and
configure startup tasks. Cloud Services provide you more Ease of
Management and Agility than Azure Websites
Azure Virtual Machines
Provides you rich set of features; however, correctly configuring,
securing and maintaining VMs require much more time and more IT
expertise compared to Azure Cloud Services and Azure Websites.
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 have a Worker Role that need complex environment settings (install a couple of softwares, setup some directories and etc) so I want to deploy it to VM ( instead of Cloud Service that specialize in more simple environment without pre configure settings).
The problem that I can only publish to Cloud Service (from VS 2013), am I missing something ?
I tried to find some article and relevant materiel about deploy a Worker Role to a VM and the only things I found is related to the Cloud Service.
How can I do it ?
(or provide me a general guidelines)
Simply put, you can't deploy a Worker Role as is into an Azure Virtual Machine (IaaS) without doing code changes.
Things you could do:
Isolate your business logic into a separate DLL and then create a separate Windows Service project which consumes this DLL. Then you could deploy that Windows Service into a VM. Do note that your business logic DLL should not have references to any libraries which will only run in Cloud Services kind of environment (e.g. Diagnostics, ServiceRuntime etc.)
Do take a look at Startup Tasks for Cloud Services. They do provide a mechanism to perform additional tasks like installing software when your Cloud Service is deployed.
In the "on premise" world, when creating an application like a Windows Service I'd classically use an App.config file to store a variety of configuration information about the application, from database connection strings to WCF endpoint information.
In the Azure Worker Role world, I am now presented with .cscfg files which are said to contain information "for the role".
I don't understand whether these files are there to supplement the configuration of the application, or replace App.config files entirely. How do these two files work to configure Azure Worker roles?
Very Basic Explanation:
Conceptually they're the same. In a traditional application, you use app.config file to define various settings related to the application (in appSettings section). Similarly, you use cscfg file to define various settings related to your cloud application (in ConfigurationSettings section). Like app.config file, you get to define other things (e.g. number of instances of your cloud application) in the cscfg file.
If you want, you can still define some of the settings in app.config file but one thing to keep in mind is that app.config file gets "packaged" and deployed and in order to change the settings, you would have to repackage your application and deploy it. However you could change the settings in a cscfg file on the fly using either the portal or Service Management API without having to repackage and redeploy the application. For example consider the scenario where you're defining the database connection string in settings file. If you specify that in app.config, in order to change it you would need to make change in app.config file --> Build the application --> publish the application. Where as in case of a cscfg file, you would just change this value in the portal.
For Web/Worker Roles the traditional configuration files (app/web.config) will keep working like they do on an on-premises deployment. But it's important to know that this file is included in the Service Package, meaning it's part of the deployment.
This means you can't change the settings you have in your app/web.config without redeploying your application. The ServiceConfiguration.cscfg on the other hand is something which is defined at Cloud Service deployment slot level, next to the actual Service Package. This means you can change this configuration file without having to redeploy your application. These settings can also be accessed from your application by calling RoleEnvironment.GetConfigurationSettingValue (similar to ConfigurationManager.AppSettings).
If you consider building an application that works both on-premises and in Windows Azure, consider using the Microsoft.WindowsAzure.ConfigurationManager package. Which automatically chooses the cscfg or app/web.config based on where your application runs.
Tip: By subscribing to the RoleEnvironment.Changing/Changed event you can intercept changes to this configuration file. You can handle this to update the web.config in code for example (explained here).