I have several App Services, and storage accounts set up in Azure. We have a Resource Group, which is a handy way to bundle together all the services and storage - for example, for tracking billing (other teams use the same subscription).
Now, I want to add a new Cloud Service, and have it included in the Resource Group. But then I see the Cloud Service listed at the same level as Resource Groups, which makes no sense.
Is it possible to include Cloud Services inside a Resource Groups, along with our App Services - and if not, what's the rationale?
Currently azure cloud services( web roles and worker roles) are not part of the Azure resource manager feature. Hence you cannot add a cloud service to a resource group. This is a requested feature in the azure feedback portal. You can go add your comments and cast your vote.
https://feedback.azure.com/forums/169386-cloud-services-web-and-worker-role/suggestions/7899432-add-cloud-services-as-an-available-resource-when-w
Related
We may assign Roles, Policies, ARM templates and Resource groups to users via Azure Blueprints during deployments at organization's scope or to one or more subscriptions. But can we do the vice-versa. I mean can a VNET or VM be assigned to interact with some other user via Azure Blueprints.
This is a deployment question raised by my management. We currently are searching for an answer.
Each Published Version of an Azure Blueprint can be assigned only to an existing management group or subscription.
For more information read here.
I have two web apps in different Resource Groups. I want to use a shared App Service Plan. Please guide how this can be done, When I try to use "Change Service Plan" I can not see another resource group service plan. Both Resource groups are in same region. When I try to create a App Service Plan I can not see option as a shared resource.
I am too late for the show, but still - it's possible to at least CREATE an App Service with App Service Plan from another resource group (not geographical region though).
You can pick up some details from here:
https://praveenkumarsreeram.com/2019/09/11/share-azure-app-service-plan-across-resource-groups/
It is not possible to move App Service to App Service plan in another resource group.
You can move an app to another App Service plan, as long as the source
plan and the target plan are in the same resource group and
geographical region.
Additional Info:
Azure deploys each new App Service plan into a deployment unit,
internally called a webspace. Each region can have many webspaces, but
your app can only move between plans that are created in the same
webspace. An App Service Environment is an isolated webspace, so apps
can be moved between plans in the same App Service Environment, but
not between plans in different App Service Environments.
You can’t specify the webspace you want when creating a plan, but it’s
possible to ensure that a plan is created in the same webspace as an
existing plan. In brief, all plans created with the same resource
group and region combination are deployed into the same webspace. For
example, if you created a plan in resource group A and region B, then
any plan you subsequently create in resource group A and region B is
deployed into the same webspace. Note that plans can’t move webspaces
after they’re created, so you can’t move a plan into “the same
webspace” as another plan by moving it to another resource group.
Ref: https://learn.microsoft.com/en-us/azure/app-service/app-service-plan-manage#move-an-app-to-another-app-service-plan
Noticed Virtual Network and Virtual Network(Classic) in Azure, Wondering what is the difference between them and when to choose what ?
Azure has two different deployment models for creating and working with resources: Resource Manager and classic.
How you create, configure, and manage your Azure resources is different between these two models. In classic mode, each resource provisioned in Azure is a single management unit. You manage all of the resources individually. The classic mode does not allow grouping of resources, which makes managing Azure resources difficult.
Azure resource management mode adds the concept of the resource group, which is a container for resources that share a common lifecycle. In ARM mode, you can deploy, manage, and monitor all the services for your solution as a group, rather than handling these services individually. Also, you can apply tags to resources to logically organize all the resources in your subscription.
When you interact with Classic mode resources from a command line such as Azure PowerShell, you are using Azure Service Management API calls (ASM). ASM is a traditional way of accessing Azure resources. In the Resource Manager mode, you are using Azure Resource Manager Rest API. When a user sends a request from any of the Azure tools, APIs, or SDKs, Resource Manager receives the request. It authenticates and authorizes the request. Resource Manager sends the request to the Azure service, which takes the requested action. See Azure Resource Manager overview.
The Virtual Network(Classic) is used for the classic models. Virtual Network in Azure is created for Resource Manager models. Currently, Microsoft recommends that you use Resource Manager for all new resources. Mostly, the Virtual Network(Classic) is used when you are creating a VNet for cloud services as far as I can tell. For Resource Manager resources, you just need to create Virtual Network in Azure portal.
There are three scenarios to be aware of:
Cloud Services does not support Resource Manager deployment model.
Virtual machines, storage accounts, and virtual networks support both Resource Manager and classic deployment models.
All other Azure services support Resource Manager
Here is a blog about Azure Classic vs Azure Resource Manager
So which one should I use?
Since both modes are viable options at this point, it is necessary to
pay careful attention to the features that each offer and your
specific requirements. ARM cannot simply be assumed to be the best fit
as it simply may not meet all of your or your customer’s needs.
I need to give a colleague access to a development azure portal so that he can learn how to create web bots. As he has no experience of azure, I dont want to through him in the deep end, so would rather use RBACs, but I cant quite see what roles would be best to apply. I had been thinking about creating a resource group and then scoping the 'contributor' role assignment to the group, but would like to try to find a more granular approach where the type of resources the user can create are restricted eg excluding VMs and SQL server?
When you deploy a bot, typically these resources are created in the Azure portal:
Resources
Web App
App Service
App Service plan
Application Insights
Storage account
If you wanted to get really granular, you could make your colleague these built-in roles as these are the typical services deployed with a bot:
Web Plan Contributor
Website Contributor
Storage Account Contributor
Application Insights Component Contributor
Another approach would be to go the Resource Group route and assign a policy to audit the creation of services so you can give your college more room to test
We are developing applications in .Net and deploying them to Azure app services. We currently have a multi-tier environment (QA/STG/PROD). In order to replicate the same environments we are using slots. However, the issue with slots is all developers who has access to QA slot are able to view/modify STG / PROD slot settings. We want to segregate this with authorization where-in users should only be able to publish apps on QA. Should we still use slots or we go with separate web apps?
As suggested in one of the comments you can use RBAC (Role Based Access Control) to control the user permissions on the web app/slots.
Azure RBAC has three basic roles that apply to all resource types:
Owner has full access to all resources including the right to delegate access to others.
Contributor can create and manage all types of Azure resources but can’t grant access to others.
Reader can view existing Azure resources.
So, you could add the developers as a READER to the webapp and as a CONTRIBUTOR to one of the slots. This will prevent the web app changes
Further, you can customize the RBAC to suit your requirements.
You can create a role with custom
Refer this article:
https://azure.microsoft.com/en-us/documentation/articles/role-based-access-control-custom-roles/
You can go with slots. Each slot creates a separate URL and you could control access to the slots by Authenticating using AD.
https://azure.microsoft.com/en-us/documentation/articles/app-service-mobile-how-to-configure-active-directory-authentication/