(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.
Related
I have a Linux based Webapp and I am trying to deploy this static webapp deployment from dropbox and after I navigate to the Deployment Center, there is no option for Dropbox or OneDrive. What are the possible ways to find this?
If your app is Linux WebApp, it is currently not available. Because these deployment options are only available for Windows Web Apps, not for Linux Web Apps.
There are other current limitations on Linux platform:
App Service on Linux is not supported on Shared pricing tier.
2.You can't mix Windows and Linux apps in the same App Service plan.
Within the same resource group, you can't mix Windows and Linux apps in the same region.
The Azure portal shows only features that currently work for Linux apps. As features are enabled, they're activated on the portal.
When deployed to built-in images, your code and content are allocated a storage volume for web content, backed by Azure Storage. The disk latency of this volume is higher and more variable than the latency of the container filesystem. Apps that require heavy read-only access to content files may benefit from the custom container option, which places files in the container filesystem instead of on the content volume.
Please take a look at this doc for more info : Azure App Service
We are currently running several Azure App Services which are having trouble with PCI-DSS compliance, due to the fact that App Services have TLSv1.0 enabled, with no option to disable it. After reading around, it seems like App Service Environments will allow us to do just that. However, I can't seem to figure out how to migrate our existing app to the new service environment. Do we just have to create a new app from scratch?
I assume your existing apps have already been deployed into existing App Service Plan? If so, you cannot move, all you can do is to clone it into a new ASP which has been deployed into your ASE
Given the fact that an ASP’s location (within an ASE or in a shared public location) cannot be changed once it is created, you have to clone/duplicate the deployments when you scale your apps in this approach. It also implies that the order you create resources is ASE (optional), then ASP, and finally add App Service apps into an ASP.
Or you can see my ASP/ASE learning at my blog
Deploying apps to Windows Azure Websites feels incredibly more convenient compared to the initial WebRole option. Being able to push through Git, and get the app restarted in ~20s is a massive improvement over the 15min role redeploy.
Thus, I am considering using this option for what used to be hosted in WorkerRole as well. Indeed, it's possible to allocate a full VM to run WA website.
Are there any gotcha to be aware of when attempting this? Obviously, as the name suggests, WA websites are not intended for backoffice processing.
In an upcoming feature for Windows Azure Websites, the scenario you're referring to will be supported:
http://github.com/projectkudu/kudu/wiki/Web-jobs
The following will allow you to have 2 types of processes to run aside your website:
Triggered - Start your process on a scheduled (or manual) basis.
Continuous - Your process will always be on (if it goes, it brings it back up).
Regarding the differences between Azure Webrole and Azure Website, there's a different question:
What is the difference between an Azure Web Site and an Azure Web Role
Cloud Services gives you two different environments: staging and production. You can also use Continous deployment with Git, Tfs, Codeplex, Dropbox too. But if you don't need this two environments, you can go with websites.
Using a Virtual Machine, you'll be responsible for the operating system, runtime, data and also your app (obviously). Just be aware that you'll have to apply the service packs / security packs by yourself. If your app doesn't use 3rd party components I don't see a reason to use a VM for that.
I am new to Windows Azure and need help with deploying my Azure application, which is correctly deployed to Azure, to a local server.
My application consists of one Web Role, which contains a Silverlight client for a Silverlight application.
I installed and configured windows server appfabric on the server and the server is actually ready. But I don't know how can I deploy/publish the application.
To deploy to Azure, i created the .cspkg file using the publish option in the right click on Azure application. And then deployed the generated files to Azure using azure management portal. how can i do something like that for the local server?
Windows Azure provides an emulator environment that runs on your development machine. You may either run a Windows Azure app in that emulator, or publish to Windows Azure. There's no option to deploy a Windows Azure application to Windows Server.
While some of the services offered are similar (such as cache), Windows Server AppFabric is not equivalent to the services provided by Windows Azure, and there's no equivalent fabric controller that runs on Windows Server.
EDIT: Adding clarification per #Asmaa's comments.
Building a private cloud is not the same as creating a local version of Windows Azure. The Private Cloud you reference is essentially a set of Windows Servers running virtual machines managed by Hyper-V, and some type of local storage. You'd be fully responsible for replication, disaster recovery, durable storage (where storage survives even with a disk crash), scaling, etc.
Windows Azure provides the abovementioned features, but only within its data centers. As #Avkash mentioned, there is a Windows Azure Appliance, but it there are only a handful in existence and they're huge (as in made for a data center).
If the objective is to run your code either locally or in Windows Azure, this can be done, but not by pushing the Windows Azure package to your Windows Servers. You'd need to build separate solutions to run your code in the two environments. You can reuse your core code if it's packaged correctly, but the notion of the Role Environment, Diagnostics, and other Windows Azure features would need to be replaced with something else.
One last thing: if you want to build a hybrid app, where some of it is deployed locally and some to Windows Azure, then there are certainly ways to bridge the two. See this article for more info.
The bottom line is that you can not deploy Azure Application to Windows Server machines in your own data center and David added all the info needed on this context. However, I just want to add little more as you are new to Windows Azure. I can understand why you are trying to do something like this and because I have had similar conversation with other partners in past, I believe this information is useful.
The main why you couldn't do it because Windows Azure main components i.e. Compute, Storage, Networking and other value added services which are built upon main component are just not available in your machine however, there is a lot more to it.
Windows Azure Appliance is a product which can be deployed to any Data Center and currently used by Dell, eBay, Fujitsu and HP as described in this link. Windows Azure and Windows Azure Appliance are not exactly same, however, Windows Azure Appliance does have a similar model of Compute, package deployment, Storage, Management portal and functionality. So when available to general public this could be a choice for data centers to have something similar to Azure running in their premise however it is currently available to only very limited partners.
I have a webrole I'd like to host in IIS for the time being.
Does anyone know how involved this is, considering that I still want Azure Storage functions of the IIS site to still work?
Azure Storage (tables, blobs, queues) only run on the actual Windows Azure environment in the cloud. There is a simulated development environment that runs a facsimile on a local SQL Server database, but that is only meant for development purposes and cannot be used for running an actual site.
Theoretically, you could run your webapp locally and connect to Azure Storage over the internet (e.g. by using the REST api), but latency would almost certainly be too high for any interactive site.
So, if you want to be able to run your site on premise on your own IIS environment, you will need to remove all the specific Azure platform dependencies and build in non-Azure alternatives. For Azure Storage, you could either do a relational database (SQL Server, mySQL) or look at a nosql/document database.
If you want to move it to IIS then tijmedvdk's answer is correct.
If your goal is to run it in your data center then you should consider Azure Appliance http://www.microsoft.com/windowsazure/appliance/ this allows you to run Azure applications on premise, without making any changes.
This answers seems misleading. Windows Azure is a platform that provides several services and you can choose from the services that you want to use.
In essence a Windows Azure is just a Virtual Machine with
*Windows Server 2008 R2
*IIS 7.5
So can if you have an application that you are currently hosting in Azure and you want to host it in IIS I don't see much of a problem there.
If you are using Storage, the only problem might be that the Storage account settings were in the WebRole or Service configuration files, but you can change your app logic to take the appropiate settings from other config files.
I have created Windows Desktop applications that for several reasons use Azure Storage and i also think of that as a great advantage of cloud computing.