As a follow up to my question about Deployment Status, I'd like to ask if there is a fast way to find:
Current Subscription Id
The current deployment slot the role is in (Staging/Production)
I am currently using the Management API, which is a bit slow, but I don't want to cache it for long because I can't be sure the cache will invalidate upon the slot swap.
From a running instance, you might be able to tell if you are in staging/production from the host URL for a web role. If you see your deployment ID there, it is staging. However, this can get tricky if you are using CNAMEs or you are running a worker role. For subscription ID, there is not much you can do as that is a pre-cursor to everything. You can't even use the Mgmt API if you don't know your SubID (there is no way that I am aware of to get the subscription ID other than portal).
Seems like the management API is your best bet (and only bet in some cases).
Related
This question may sound a little odd, but here it goes: A customer of ours would like to get access to certain metrics of his environment of our product which we host on Azure for the customer. It's a pretty complicated deployment, but in the end it consists of an Application Gateway, some virtual machines and a dedicated Azure SQL database.
The customer now would want to get select metrics from this deployment forward to their own DataDog subscription, e.g. VM CPU metrics, database statistics and those things. DataDog obviously supports all this information (which is good), but as a default would slurp in information from all resources within our subscription (which is not OK).
Is there a way to fine-granularly define which data is forwarded to DataDog, e.g. the resources and also which type of metrics to forward for each resource? What are my options here? Is it enough to create a service principal with a limited reading right, or can I configure this somewhere else? I am unfortunately not familiar with DataDog.
The main thing which must be prevented is that the customer due to the metrics forwarding could get access to other metrics in our subscription - we need to control the exact scope of the metrics.
The pretty straightforward solution to this issue is to create a service principal via command line, and then to assign the monitoring role to this service principal only exactly for the resources you need. This even works down to a level of specific databases for example.
Kicker: This is not possible to do in such a granularity from the UI, but the az command line accepts assigning the monitoring reader permission on a deep resource ID level, even if the UI for this is not there. By finding the resource ID from the UI, and then using the resource ID from the command line, it's possible to achieve exactly this behaviour.
I'm wondering what implications ,if any, backing up a production API Management Service has on production traffic. The reason for me asking is that I recently tested running the backup cmdlet
Backup-AzApiManagement ..
and during the process ( which took anywhere between 15-25 minutes), within the Azure Portal on the main APIMS page for the service I was backing up, it stated "Updating service..."
I just want to be sure I understand if there are any potential downtime that need to be accounted for during the backup. Perhaps I need to run the backup during non-peak hours if so. I would hate to run the backup operation during peak hours, just unaware of potential downtime just to kick myself later when I find out that the service is expected to be down intermittently during the backup operation.
Any insight is appreciated. Thank you in advance for the help.
There will be no downtime if you are within the same region, however if its different region If you use the same Use the same API Management instance name there will be a downtime.
There will be no downtime. The API's is still working even when doing backup. However the developer portal is locked for editing. (I have tested running queries against API's when doing backup)
The only downside is that the APIM also throws an event in the Resource health log. Which means that if you have alerts configured for you APIM there will be an alert every time you are running a backup! I am digging for a solution for this, thats why I ended up here.
We have Azure environment with 3 different subscription and around 5 project resources are deployed in this environment.
Each project team has rights to create resources under specific Resource Group (RG) within Azure.
Now from Azure Admin perspective, i would like to know Who, When
This is basic requirements for any organization to track their cost, resource information. When i looked in Azure, this information is not available directly at resource level.
Few posts are mentioning to use Tagging for this or use logs (2 years back, really?)? Is it? I am surprised.
Can i use Application Insight for this? or only available for App Service kind of services?
Please help me to get this information in efficient way
Your only option is to implement some sort of logging (like poll Azure Subscription events) and save it somewhere. You can use Azure Monitor to achieve that rather easily. But by itself Azure doesnt offer anything like that out of the box.
you can use tagging, but with obvious challenges. logs only go 3 months back.
We are looking at using Azure Jobs for out multi-tenant platform, but want to figure the best way to do security for it, without using a certificate that has access to our whole Azure account.
We have a Resource Group called "Scheduler" and for each tenant we create a Job Collection with the Tentants Id "Tenant{tenant.Id}".
Currently we do this using SchedulerManagementClient and passing in CertificateCloudCredentials. We could use the Token to do this, but I believe it still has the same problem - in that the credentials have access to the full azure account, which we don't want.
Ideally we would like to lock down creation to the resource group "Scheduler" and create a certificate/token for this.
Is there a way to do that? Is there a better way to do what we are doing anyway?
Ok I figured this out, as is always the way it seems when you finally post something on StackOverflow. Everything was complicated by the fact I was using the old management libraries (Microsoft.WindowsAzure.Management) and not the new libraries (Microsoft.Azure.Management).
Basically I needed to create an application, and then assign that application roles just like you do users. This also helped:
https://azure.microsoft.com/en-gb/documentation/articles/resource-group-create-service-principal-portal/
I thought one of the advantages of Azure was that I could turn services on and off depending on when I want them to be available.
However I cant see how to pause my App Service Plan.
Is it possible?
I want to use the S1 tier so that I can play with what it offers. However I want to be able to pause the cost accumulation when I am not using it.
I see from the app service pricing help that an app will still be billed for even though it is in the stopped state.
Yet the link also clearly states that I only pay for what I use. So how does that work?
If you put your hosting plan onto the free tier, you will stop being charged for it. However if you have things like deployment slots and certificates these will be deleted.
The ability to turn services on and off, is more to do with being able to scale services, so if you need 50 servers for an hour you can easily do that.
What you can do to make your solution temporary is to create a deployment script, using Powershell or Resource manager Templates then you can deploy your solution for exactly as long as you need it and then delete it again when you don't. In this sense you can turn your services on and off at a whim.
Azure provides building blocks for you to create the solution you need, it is up to you to figure out how to best use those building blocks to create the solution you seek.
Edited to answer extended question.
If you want to use the S1 pricing plan, and not have it charge when you are not using it, the only way of achieving that is by using automation. Fortunately, this is reasonably trivial to achieve.
If you look at this template it is pretty much all configured to deploy a website from Github to Azure on demand. If you edit that to configure it to your needs you can have a new Azure website online with 2 minutes of running the script.
Then you would have another script that deleted it once you had finished.
Doing it this way you would loose no functionality, and probably learn quite a bit about what is possible with Azure along the way.
App Service Plan
An app service plan is the hardware that a web app runs on. In the free and shared tier your web apps share an instance with other web apps. In the other tiers you have a dedicated virtual machine. It is this virtual machine that you pay for. In that case it is irrelevant whether or not you have web apps running on your app service or not, you still have a virtual machine running and you will be charged for that.
To change the App Service Plan via PowerShell, you can run the following command
Set-AzureRmAppServicePlan -ResourceGroupName $rg -Name $AppServicePlan -Tier Free
I was able to accomplish this using the dashboard by selecting the App Service Plan, clicking Scale up (App Service Plan), and then from there if you click Dev/Test you can select the Free tier.
As others have mentioned, you need to script this. Fortunately, I created a repository with one-click deployment to your Azure resources.
https://github.com/jraps20/jrap-AzureVerticalScaling
The steps are intended to be as simple and generic as possible:
Execute the one-click deployment from the repo readme
Select the subscription, resource group etc.
Deploy resource to Azure
Set up your schedule to scale up and scale down as-needed
The scripting relies on runbooks and variables to maintain the previous state of each App Service Plan and App Services within those plans. Some App Services cannot be scaled due to specific settings being used (AlwaysOn, Use32BitWOrkerProcess, ClientCertEnabled, etc.). In those cases, the previous values are stored as variables prior to down scaling and then the original values are reapplied when the services are scaled up.
For more clarity, I have written a blog post that goes into detail. The post is pertaining to Sitecore, but applies to any App Service setup- Drastically Reduce Azure PaaS Hosting Costs in Non-Prod Environments With Scheduled Vertical Scaling. It also includes a brief video tutorial to show its use case.
Myself and others have been using this repository/approach for well over a year and it works great. I mostly use it for POC's to reduce costs when I'm not actively working on something. However, its main intention was for targeting non-prod environments to save costs during non-work hours.
Azure App Service Plan is just an logical concept of a set of features and capacity that you can share across multiple apps. I don`t think you can "pause" a plan, instead you can pause your service. and depends on billing model of each service, you might or might not get charged.
Pausing = Delete or lower tier.
Scripting is the key.
Design Diagram
Use scripts to create (also consider shared resources)
Delete using scripts
Use scripts to recreate.
eg: If we use resource group properly per environment then
Export-AzureRmResourceGroup will create a template for us (everything in the resource group will be pulled out as script). So we can delete it and recreate it anytime.
To pause a VM and stop billing you need to shut is down and deallocate it. Just shutting down still has the capacity reserved as if its running.
Storage can't be shutdown - it can be moved to lower cost tiers.