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
Related
I have a .Net core app developed using Visual Studio 2019 and deployed on Azure app service. I have function app as well in the same solution. I have to do couple of things and then redeploy to Azure app service.
Add one .cshtml file
Modify one .cshtml file
My question is, how to deploy the CSHTML file only to the Azure app service? Without affecting the existing functionality of application.
As per my understanding, if web app is deployed in Azure app service then the whole thing (solution) has to be deployed even though there are/is very small code modifications.
Please let me know.Thanks.
Even if you have Web App and Function App in the same solution, they should be separated units of deployment. That said, your deployment pipeline should be separately triggered for Web App and Function App.
From the technical point of view(or architecture) there's no concept of "solution". Solution(.sln) is a Visual Studio specific being and even though it's supported e.g. in VS Code, I'd never treat it as deployment unit. Especially in your scenario, when in fact two separate services are responsible for handling your code.
Even if you deploy Function App as a part of the same App Service Plan as your Web App, it's still a separate Azure service. In such a scenario they only share compute.
Yes its possible if you have access to kudu deployment center you can perform manual add/update information , please visit below URL:-
https://[yourAppName].scm.azurewebsites.net
You can also navigate to this site using the azure portal , once you open the app service blade you will find the kudu deployment center option in the bottom left of the menu.
It will provide an online file explorer of your application hosted on the app service and from there you can migrate to relevant folder and perform add/update.
I have an app service running on Azure with an associated SQL server DB.
I would like to create a test environment for the project.
I looked at a few Azure Dev/Test tutorials but they are for setting up VMs and I couldn't see anything indicating it can be used for a app service.
Is my only option to duplicate the appservice, db, ssl certs, custom domains and effectively double my azure bill?
Bruno gave good advice, but here's a few more things to consider.
If you use deployment slots, you are sharing your Web App CPU and memory between all slots. If something goes horribly wrong with a test build that's deployed to a slot on your production machine, your production environment can end up resource starved. I personally don't recommend using slots for testing for this reason. Slots are more for smoke testing/warming up a build that you're about to swap into your production slot.
If you want to save money yet still have the benefit of separate environments, consider looking into ARM templates. ARM templates let you script the provisioning of Azure resources. You can create ARM templates based on your production environment, including scripting the App Settings section of your Web App to hold test configuration settings. You can then deploy your ARM template that spins up a test environment right from a Visual Studio project. If you put all of your test resources into the same resource group, tearing down your test environment is a few mouse clicks to delete the test resource group.
For the App Service, you have something called Slots. This allows you to have multiple environments on the same App Service. You can also have multiple Web Apps under the same App Service Plan as well instead of using Slots, so in this case, you only pay for 1 backend. App Service has a Free Tier, but with limitations such as not supporting custom domains.
Set up staging environments in Azure App Service
For SQL Databases you have to pay for each DB or use Elastic Pools (1 backend for multiple DBs) but that's only worth when you're using at least 100DTUs DBs. The minimum database you can have is the Basic one, but that's $6/month.
(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.
I am currently looking into using ARM to deploy new environments of our Azure Components. We have a lot of web apis that are deployed to Cloud Services, since we need access to the underlying OS to get CPU usage for App Dynamics metrics. When reading through ARM, it seems as if they are deprecating Cloud Services, but I have some confusion about what is replacing it. I see that you can create Web Apps using this and use Publish from Visual Studio to deploy the app it, but I see no options for Cloud Services. So what is the preferred method to do this? Creating a VM and deploying using Web Deploy? What about VM scaling. Any help would be greatly appreciated.
My company is in the process of moving a legacy app to Azure using Cloud Services and we were concerned about the future of Cloud Services. Since we are somewhat early into the project and would like to use the ARM model we thought it would be easier to make a move now if we knew the future. After a few conversations with project leads at Microsoft on this topic we were only told that we should continue working with Cloud Services as they would continue to be supported.
It's quite clear that the move to ARM was not well thought out in terms of direction and consequences of existing services that many people are already using. Reading between the lines I would say that there is no plan to convert Cloud Services from the ASM to ARM model.
If application insights (https://azure.microsoft.com/en-us/services/application-insights/) are sufficient for your monitoring needs, then you can use web apps. These can be deployed via ARM, and can automatically deploy from a git repo or web deploy package. See this example:
https://github.com/Azure/azure-quickstart-templates/tree/master/201-web-app-github-deploy
The issue here that you may be trying to do operations which are restricted by the web app sandbox.
Failing that, you can use an ARM template to set up a VM and then invoke a custom site extension which will run powershell code to do further provisioning. This powershell code can fetch any package that you may want to install. See this ARM template for example: https://github.com/Azure/azure-quickstart-templates/tree/9ad72f1f5f0008c14311be79eee036b871712394/201-list-storage-keys-windows-vm
Once the VM is created you would be able to modify it and scale as needed.
I am writing an application that will be deployed both to the cloud and to on-premise data-centres (for those clients who, essentially, don't yet trust the cloud with their data.
If i choose to go MS Azure I can use the new cloud project types with their Web and Worker roles. But how can I get the worker roles running for the on-premise variant?
Do I have to write my own host (say as a windows service)? This is not ideal as it requires additional code and deployment.
Is there an Azure compatible approach, say in the Windows Azure Pack or the App Fabric stuff (is App Fabric still current?) that doesn't require the full setup of the private cloud ?
This doesn't exist in Azure Pack.
There is no need to try and have a Worker Role on premise. All you need to do is to have a Virtual Machine that you install a Windows Service on.
It's easy to create a Windows Service using Topshelf.
Deployment of a Windows Service with Topshelf is actually much easier than deployments for Worker Roles because you just run the .exe you create with the install and then with the start arguments.
Because of this you actually need less code than for a Worker Role since you don't need a second wrapper project.
While I haven't used Windows Azure Pack before it does seem capable of providing this functionality in house, however the requirements and setup procedures are intense and it is certainly geared towards enterprise.
A better option is for you to create a console app that triggers the OnStart() and Run() functions for your WorkerRole based on your OS Task Scheduler.
Not too much work in my opinion and you get to keep your WorkerRoles as is but just add the console app for any on premise solutions.