AzureRMR is a package for interacting with Azure Resource Manager: authenticate, list subscriptions, manage resource groups, deploy and delete templates and resources. It calls the Resource Manager REST API directly, so you don't need to have PowerShell or Python installed.
As a general-purpose interface to Azure Resource Manager (ARM), you can use AzureRMR to work with nearly any Azure object that ARM can handle: subscriptions, resource groups, resources, templates and so on. The things you can do include:
Under the hood, AzureRMR uses a similar authentication process to the Azure CLI. The first time you authenticate with a given Azure Active Directory tenant, you call
create_azure_login(), which will log you into Azure. R will prompt you for permission to create a special data directory in which to save your credentials. Once this information is saved on your machine, it can be retrieved in subsequent R sessions with
get_azure_login(). Your credentials will be automatically refreshed so you don't have to reauthenticate.
Unless you have a good reason otherwise, you should allow this caching directory to be created. Note that many other cloud engineering tools save credentials in this way, including the Azure CLI itself. You can see the location of the caching directory with the function
library(AzureRMR) #> The AzureR packages can save your authentication credentials in the directory: #> #> C:\Users\hongooi\AppData\Local\AzureR #> #> This saves you having to reauthenticate with Azure in future sessions. Create this directory? (Y/n) y AzureR_dir() #>  "C:\\Users\\hongooi\\AppData\\Local\\AzureR" # if this is the first time you're logging in az <- create_azure_login() #> Creating Azure Resource Manager login for default tenant #> Waiting for authentication in browser... #> Press Esc/Ctrl + C to abort #> Authentication complete. # for subsequent sessions az <- get_azure_login() #> Loading Azure Resource Manager login for default tenant # you can also list the tenants that you've previously authenticated with list_azure_logins()
See the "Authentication basics" vignette for more details on how to authenticate with AzureRMR.
AzureRMR allows you to work with your subscriptions and resource groups. Note that if you created your service principal via the cloud shell, as described in this vignette, you probably only have access to one subscription. Regardless, you can list all subscriptions that you can work with:
# all subscriptions az$list_subscriptions() #> $`5710aa44-281f-49fe-bfa6-69e66bb55b11` #> <Azure subscription 5710aa44-281f-49fe-bfa6-69e66bb55b11> #> authorization_source: RoleBased #> name: Visual Studio Ultimate with MSDN #> policies: list(locationPlacementId, quotaId, spendingLimit) #> state: Enabled #> --- #> Methods: #> create_resource_group, delete_resource_group, get_provider_api_version, get_resource_group, #> list_locations, list_resource_groups, list_resources #> #> $`e26f4a80-370f-4a77-88df-5a8d291cd2f9` #> <Azure subscription e26f4a80-370f-4a77-88df-5a8d291cd2f9> #> authorization_source: RoleBased #> name: ADLTrainingMS #> policies: list(locationPlacementId, quotaId, spendingLimit) #> state: Enabled #> --- #> Methods: #> create_resource_group, delete_resource_group, get_provider_api_version, get_resource_group, #> list_locations, list_resource_groups, list_resources #> #> ...
Notice that AzureRMR is based on R6 classes, where methods are part of the object itself (much like objects in C++, C# and Java). Thus
list_subscriptions is a member of the
az object, and we call it with
az$list_subscriptions(). R6 is used because it allows objects to have persistent state; in this case, the objects in R represent corresponding objects in Azure.
list_subscriptions() call returns a list of subscription objects. You can retrieve the details for a single subscription with
# get a subscription (sub1 <- az$get_subscription("5710aa44-281f-49fe-bfa6-69e66bb55b11")) #> <Azure subscription 5710aa44-281f-49fe-bfa6-69e66bb55b11> #> authorization_source: Legacy #> name: Visual Studio Ultimate with MSDN #> policies: list(locationPlacementId, quotaId, spendingLimit) #> state: Enabled #> --- #> Methods: #> create_resource_group, delete_resource_group, get_provider_api_version, get_resource_group, #> list_locations, list_resource_groups, list_resources
A subscription object in turn has methods to get, create and delete resource groups (and also list all resource groups):
(rg <- sub1$get_resource_group("rdev1")) #> <Azure resource group rdev1> #> id: /subscriptions/5710aa44-281f-49fe-bfa6-69e66bb55b11/resourceGroups/rdev1 #> location: australiaeast #> properties: list(provisioningState) #> --- #> Methods: #> check, create_resource, delete, delete_resource, delete_template, deploy_template, get_resource, #> get_template, list_resources, list_templates # create and delete a resource group test <- sub1$create_resource_group("test_group") test$delete(confirm=FALSE)
Methods for working with resources and templates are exposed as part of the
az_resource_group class. You can retrieve an existing resource/template, create a new one, or delete an existing one. Below is a short introduction to resources; for templates, see the "Working with templates" vignette.
(stor <- rg$get_resource(type="Microsoft.Storage/storageServices", name="rdevstor1")) #> <Azure resource Microsoft.Storage/storageAccounts/rdevstor1> #> id: /subscriptions/5710aa44-281f-49fe-bfa6-69e66bb55b11/resourceGroups/rdev1/providers/Microsoft.Sto ... #> is_synced: TRUE #> kind: Storage #> location: australiasoutheast #> properties: list(networkAcls, trustedDirectories, supportsHttpsTrafficOnly, encryption, #> provisioningState, creationTime, primaryEndpoints, primaryLocation, statusOfPrimary) #> sku: list(name, tier) #> tags: list() #> --- #> Methods: #> check, delete, do_operation, set_api_version, sync_fields, update
One benefit of the syntax that AzureRMR uses is that method chaining works. This is the OOP version of pipelines, which most R users will recognise from the tidyverse.
# use method chaining to get a resource without creating a bunch of intermediaries # same result as above stor <- az$ get_subscription("5710aa44-281f-49fe-bfa6-69e66bb55b11")$ get_resource_group("rdev1")$ get_resource(type="Microsoft.Storage/storageServices", name="rdevstor1")
Once we have a resource, we can do things with it, via the
do_operation() method. In this case, we have a storage account. One of the things we can do with a storage account is retrieve its access keys:
stor$do_operation("listKeys", http_verb="POST") #> $`keys` #> $`keys`[] #> $`keys`[]$`keyName` #>  "key1" #> #> $`keys`[]$value #>  "k0gGFi8LirKcDNe73fzwDzhZ2+4oRKzvz+6+Pfn2ZCKO/JLnpyBSpVO7btLxBXQj+j8MZatDTGZ2NXUItye/vA==" #> #> $`keys`[]$permissions #>  "FULL" #> ...
Here is another example. If we have a virtual machine, we can start it, execute shell commands, and then shut it down again:
vm <- rg$get_resource(type="Microsoft.Compute/virtualMachines", name="myVirtualMachine") vm$do_operation("start", http_verb="POST") # may take a while vm$do_operation("runCommand", body=list( commandId="RunShellScript", # RunPowerShellScript for Windows script=as.list("ifconfig > /tmp/ifconfig.out") ), encode="json", http_verb="POST") vm$do_operation("powerOff", http_verb="POST")
For the types of operations you can carry out on a resource, consult the Azure REST API documentation.
You can also interrogate the fields of a resource object; in particular the
properties field can contain arbitrary information about an Azure resource. For example, a storage account's properties includes the endpoint URIs, and a virtual machine's properties includes its admin login details.
# file and blob storage endpoint stor$properties$primaryEndpoints$file stor$properties$primaryEndpoints$blob # OS profile for a VM: includes login details vm$properties$osProfile
The following types of functionality apply at multiple levels: resource, resource group and/or subscription.
Resources and resource groups can be assigned tags. Tags are labels that help admins to organise and categorise Azure resources. To set and unset tags, use the
set_tags method, and to view them, use
rg$set_tags(comment1="hello world!", created_by="AzureRMR") # a name-only comment rg$set_tags(comment2) # to unset a tag, set it to NULL rg$set_tags(created_by=NULL) # see the tags rg$get_tags() #> $comment1 #>  "hello world!" #> #> $comment2 #>  "" # specify keep_existing=FALSE to unset all existing tags rg$set_tags(newcomment="my new comment", keep_existing=FALSE)
As of version 2.0.0, AzureRMR includes the ability to lock and unlock subscriptions, resource groups and resources. The methods involved are:
create_lock(name, level): Create a management lock on this object. The
levelargument can be either "cannotdelete" or "readonly".
get_lock(name): Returns a management lock object.
delete_lock(name): Deletes a management lock object.
list_locks(): List all locks that apply to this object.
Locks applied to a resource group also apply to all its resources, and similarly locks applied to a subscription also apply to all its resource groups (and resources). If you logged in via a custom service principal, it must have "Owner" or "User Access Administrator" access to manage locks.
# protect this resource group and its resources against deletion rg$create_lock("mylock", "cannotdelete") rg$list_locks() rg$delete_lock("mylock")
As of version 2.1.0, AzureRMR includes limited support for role-based access control (RBAC). You can read role definitions, and read, add and remove role assignments. This applies to subscription, resource group and resource objects.
rg$list_role_definitions() #> definition_id name #> 1 a7b1b19a-0e83-4fe5-935c-faaefbfd18c3 Avere Cluster Create #> 2 e078ab98-ef3a-4c9a-aba7-12f5172b45d0 Avere Cluster Runtime Operator #> 3 21d96096-b162-414a-8302-d8354f9d91b2 Azure Service Deploy Release Management Contributor #> 4 7b266cd7-0bba-4ae2-8423-90ede5e1e898 CAL-Custom-Role #> 5 b91f4c0b-46e3-47bb-a242-eecfe23b3b5b Dsms Role (deprecated) #> ... rg$get_role_definition("Reader") #> <Azure role definition> #> role: Reader #> description: Lets you view everything, but not make any changes. #> role definition ID: acdd72a7-3385-48ef-bd42-f606fba81ae7 # assign Reader role to the principal with the given ID rg$add_role_assignment("041ff2be-4eb0-11e9-8f38-394fbcd0b29d", "Reader")
You can assign roles to either a user or a service principal, although note that the ID of a service principal is not the app ID of its corresponding registered app. The AzureGraph package can help you in specifying the principal to which to assign a role.
gr <- AzureGraph::get_graph_login() # can get a user by their email address usr <- gr$get_user("firstname.lastname@example.org") # get the service principal for an app by its app ID svc <- gr$get_service_principal(app_id="b9ed4812-4eba-11e9-9a1e-1fda262d9c77") rg$add_role_assignment(usr, "Reader") rg$add_role_assignment(svc, "Contributor")
Technically role definitions and assignments are resources and could be manipulated as such, but AzureRMR currently treats them as independent classes.
This has been a quick introduction to the features of AzureRMR. Remember that this package is only meant to be a generic mechanism for working with Resource Manager. You can extend it to provide support for service-specific features; examples of packages that do this include AzureVM for virtual machines, and AzureStor for storage accounts. For more information, see the "Extending AzureRMR" vignette.
Any scripts or data that you put into this service are public.
Add the following code to your website.
For more information on customizing the embed code, read Embedding Snippets.