This article is contributed. See the original author and article here.
Hi everyone, welcome to the post-Ignite edition of the Azure CLI blog. Today I will share with you a list of the latest features we released in the Azure CLI supporting various announcements for Microsoft Ignite. However Microsoft Ignite is not just about the major announcements. We also released several updates to Azure CLI commands based on customer asks surfacing improvements to our core platform services during the Ignite timeframe. Here are some of the announcements and updates.
Azure Arc-enabled Kubernetes is now generally available. This allows organizations to connect, manage and govern any Kubernetes cluster across datacenters, multicloud and edge from Azure. You can reap the benefits of Azure Arc-enabled Kubernetes by connecting an existing Kubernetes cluster to Azure Arc using the Azure CLI via the az connectedk8s connect command. (Learn more at Connect an existing Kubernetes cluster to Azure Arc)
Azure Resource Mover, which provides portability between Azure regions and is unique to the Azure platform, is now generally available. Azure Resource Mover allows new customers to create applications in existing regions and migrate them upon new region launch or move into regions with availability zones (AZs) if not planned for their region. This service can now be accessed from the Azure CLI via az resource-mover. We would love to hear your feedback about managing this new service via the Azure CLI.
Mongo v4.0 server support in Azure Cosmos DB API for Mongo DB is now generally available. This makes it easier for developers using MongoDB v4.0 to migrate to Azure Cosmos DB. Support for Mongo v4.0 can now be leveraged from the Azure CLI via the az cosmosdb mongodb commands.
Azure Managed Instance for Apache Cassandra is a new service that automates deployment, scaling, and management operations for open-source Apache Cassandra datacenters. It is an ideal service if you want to create hybrid deployments that can extend the capacity in your existing on-premises or cloud datacenters. Customers can now create a managed instance cluster as well as connect to the cluster via az managed-cassandra (Learn more at Use CLI to create Azure Managed Instance for Apache Cassandra cluster)
Azure Cosmos DB Continuous Backup and Point-in-Time is now available in preview. This provides ongoing backups and enables customers to recover and restore data from any point within the past 30 days. To provision an API for MongoDB or SQL API account with continuous backup, an extra argument –backup-policy-type Continuous should be passed along with az cosmosdb create. You can also use commands with restorable- prefix to enumerate restorable resources; like az cosmosdb mongodb restorable-database list. (Learn more at Use Azure CLI to configure continuous backup and point in time restore ).
Azure Virtual Machine Scale Sets flexible orchestration mode is now available in preview. Customers may now change VM sizes without redeploying their scale set, resulting in greater operational agility. Customers will also be able to mix Spot Virtual Machines and pay-as-you-go VMs within the same scale set to optimize costs. Customers can now create VM Scale Sets in this mode via the Azure CLI using az vmss create –orchestration-mode Flexible.
Security updates to Storage
Preventing authorization with shared keys is now in preview. Every secure request to an Azure Storage account must be authorized. By default, requests can be authorized with either Azure Active Directory (Azure AD) credentials, or by using the account access key for Shared Key authorization. Of these two types of authorization, Azure AD provides superior security and ease of use over Shared Key, and is recommended by Microsoft. So we are more secure by default and require Azure AD to authorize requests, disallowing requests to the storage account that are authorized with Shared Key. For accounts that still need to use shared keys, you will need to explicitly enable this at the account level using az storage account create/update with the new –allow-shared-key-access flag. (Learn more at Prevent authorization with Shared Key (preview) )
Encryption scopes (preview) enable you to manage encryption at the level of an individual blob or container. An encryption scope isolates blob data in a secure enclave within a storage account. You can use encryption scopes to create secure boundaries between data that resides in the same storage account but belongs to different customers. You can create an encryption scope using Microsoft managed keys or customer managed keys (in a key vault or managed HSM) based on –key-source in the az storage account encryption-scope create command. (Learn more at Create and manage encryption scopes (preview) ). In addition, you can rewrite a blob with a specified encryption scope using az storage blob rewrite with –encryption-scope. This will change the encryption used to protect a blob’s content (Learn more at Encryption scopes for Blob storage (preview) )
Customers who require higher levels of assurance that their data is secure can enable 256-bit AES encryption at the Azure Storage infrastructure level. When infrastructure encryption is enabled, data in a storage account is encrypted twice — once at the service level and once at the infrastructure level — with two different encryption algorithms and two different keys. Double encryption of Azure Storage data protects against a scenario where one of the encryption algorithms or keys may be compromised. In this scenario, the additional layer of encryption continues to protect your data. To set this up, create a general-purpose v2 storage account by calling the az storage account create command with –kind StorageV2 and include the –require-infrastructure-encryption option which enables infrastructure encryption and double encrypts your data.
IP address related updates to Networking
Azure Public IP SKU upgrade is now generally available. This allows customers to upgrade and retain the same IPs without management overhead or notices to their end customers and now supports the ability to upgrade from Basic to Standard SKU using the Azure CLI az network public-ip update with –sku Standard. Optionally first updating the Basic SKU IP using az network public-ip update with –allocation-method Static. (Learn more at Upgrade public IP addresses ).
Standard SKU IPs can be zone-redundant (advertised from all 3 zones). This can be configured using az network public-ip create with –zone 1 2 3. (Learn more at Public IP addresses in Azure ) You can also indicate if a Standard SKU IP address is “anycast” from multiple regions (Global) using –tier Global. Note that a “Global Tier” IP is only utilized for the cross-region Load Balancer.
Finally, speaking of IP addresses, Azure ExpressRoute supports IPv6 addresses for peering using az network express-route peering create with –ip-version ipv6
Azure CLI core updates
We recently blogged about our AI-powered az next commands, and are eager to know what you think (Learn more at https://techcommunity.microsoft.com/t5/azure-tools/az-next-ai-powered-interactive-assistant/ba-p/2118582)
We also need your valuable feedback on our Azure CLI Beta which is setup for customers to try out the breaking changes that our shift to the Microsoft Authentication Library (MSAL) from the Azure Active Directory Authentication Library (ADAL) will require. (Learn more at Azure CLI Beta release notes )
Looking forward to all of your feedback on these updates and anything else you would like to see. Thanks a lot for your continued support!
Brought to you by Dr. Ware, Microsoft Office 365 Silver Partner, Charleston SC.