We are actually deploying container to Azure using Azure CLI and the create command as specify the sample documentation below :
https://learn.microsoft.com/en-us/azure/container-instances/container-instances-vnet
In this dosucmentation it is clearly specify from the sample command below that when the container and the Vnet/Subnet gets created, azure create for you a Network Profile Id ( that is need for yaml deplyoement)
az container create --name appcontainer --resource-group myResourceGroup --image mcr.microsoft.com/azuredocs/aci-helloworld --vnet aci-vnet --vnet-address-prefix 10.0.0.0/16 --subnet aci-subnet --subnet-address-prefix 10.0.0.0/24
After the container gets created successfully you are supposed to get Network profile name or ID, which you can obtain using "az network profile list"
Which in fact does not return anything
UPDATE :
I update m Azure CLI to 2.30 in powershell but the result is the same the output of the command return nohing even if container and vnet gets succesfully created
Output result
Thanks for your help
regards
I have tested in my environment.
I deployed a container to a new virtual network using the below command:
az container create --name appcontainer --resource-group myResourceGroup --image mcr.microsoft.com/azuredocs/aci-helloworld --vnet aci-vnet --vnet-address-prefix 10.0.0.0/16 --subnet aci-subnet --subnet-address-prefix 10.0.0.0/24
The container got successfully created.
To get the Network Profile ID, I used the below command:
az network profile list --resource-group myResourceGroup --query [0].id --output tsv
In this way, we can fetch the Network Profile ID
If network profile is not getting created using CLI, try using ARM template
The same happened to me. I solve it using Azure CLI version 2.27.2. Any newer version leaves me with the same problem.
There seems to be a problem with the latest versions of the Azure CLI
Related
I'm trying to create a postgresql database on azure with azure-cli. I set my default location with az configure --defaults location=WestEurope, then I created a resourcegroup, a vnet and a subnet. Now I want to create a flexible server for postgresql with
az postgres flexible-server create --name $SERVERNAME --vnet $VNET --subnet $DBSUBNET
--admin-user $DB_USER --admin-password $DB_PASSWORD --sku-name Standard_B1ms --tier Burstable --storage-size 1024 --tags "Billing=test" --version 13 --database-name $DB_NAME
but I get this error and the server is not created: The location of Vnet should be same as the location of the server.
My Vnet is obviously located in WestEurope, given my default location set before, and I can't understand how the location of any resource I create could be different from my default location. I even tried to add --location WestEurope to the command, but it produced the same result.
I tried to set the default location as West Europe through AZ CLI in Azure Cloud Shell:
az configure --defaults location=westeurope
To create the PostgreSQL Server and database in the specified default location:
az postgres flexible-server create --resource-group HariTestRG \
--name demoserver1205 --admin-user <username> --admin-password <your-password> \
--sku-name Standard_B1ms --tier Burstable --storage-size 1024 \
--tags "Billing=test" --version 13 \
--vnet myVnet --subnet mySubnet --database-name demopsqldb01 \
Result:
Private DNS Zone is created at the global level automatically by Azure while creating the Postgres SQL Server and the Virtual Network.
Note:
After executing the default location command, you need to execute the remaining CLI commands without any error.
If you got the error in between the execution of any other commands, then execute the default location config command again.
Without interactive activity, cloud shell time out after 20 minutes and it runs on a temporary host provided on a per-session basis.
Updated Answer:
Here I created the VNet and Subnet in the resource group. Created the PostgreSQL Server and database with the existing VNet and Subnet through AZ CLI (using the above CLI Cmdlets - worked successfully):
Result:
I am using Azure CLI version 2.34.1. I ran following commands to create a resource group and then a virtual machine. Note that I used options to delete relevant resources when the VM is deleted.
az group create --name myTestRG --location eastus
az vm create --resource-group myTestRG --name myTestWindows11VM --image MicrosoftWindowsDesktop:windows-11:win11-21h2-pro:22000.493.220201 --admin-username someusername --os-disk-delete-option delete --nic-delete-option delete
Later I deleted the VM using following command.
az vm delete --name MyTestWin11VM --resource-group myTestRG -y
However, when I browse to the portal, the resource group still showing following resources that are relevant to the VM.
What I may be doing wrong? Is there anyway to delete all resources associated to VM when I delete the virtual machine itself?
UPDATE ITS A BUG:
The way Azure works is to group resources in Resource Groups - its a mandatory field in all creation of services. Azure does this because many resources have dependencies, such as a VM with a NIC, VNet & NSG.
You can use this to your advantage and simply delete the Resource Group:
az group delete --name myTestRG
Azure will work out the dependency order, eg NSG, VNet, NIC, VM. You can read up on how it does the ordering: https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/delete-resource-group?tabs=azure-cli
What happens if I have multiple VMs in a Resource Group and I only want to delete one?
There's 3 new options --os-disk-delete-option, --data-disk-delete-option, --nic-delete-option to support deleting VMs and dependencies:
az vm create \
--resource-group myResourceGroup \
--name myVM \
--image UbuntuLTS \
--public-ip-sku Standard \
--nic-delete-option delete \
--os-disk-delete-option delete \
--admin-username azureuser \
--generate-ssh-keys
Otherwise script the whole thing using Azure Resource Manager Templates (ARM Templates), or the new tool to generate ARM Templates called Bicep. It's worth continuing with raw CLI commands and delete dependencies in order. IF you get good with the CLI you end up with a library of commands that you can use with ARM templates.
I am trying to find a way to delete an Instance in azure and all its associated resources. But I don't see any straightforward approach to accomplish it. I am using az vm delete -g resourcegroup -n myinstancename--yes command which currently only deletes instances. In my scenario, I can't use powershell.
For testing ,I created a VM with 1 NIC, 1 Public IP and 2 Data disks.
Then, I used the below az CLI script :
$osDisk = (az vm show --resource-group ansumantest --name ansumantest --query "storageProfile.osDisk.name" --output tsv)
$datadisks = (az vm show --resource-group ansumantest --name ansumantest --query "storageProfile.dataDisks[].name" --output tsv)
$nics= (az vm show --resource-group ansumantest --name ansumantest --query "networkProfile.networkInterfaces[].id" --output tsv)
foreach ($nic in $nics){
$publicIps=az network nic show --id $nic --query "ipConfigurations[].publicIpAddress.id" --output tsv
}
az vm delete --resource-group ansumantest --name ansumantest --yes
if ($osDisk) {
az disk show --resource-group ansumantest --name $osDisk --yes
}
foreach ($datadisk in $Datadisks){
az disk delete --resource-group ansumantest --name $datadisk --yes
}
foreach ($nic in $nics){
az network nic delete --id $nic
}
foreach ($publicIp in $publicIps){
az network public-ip delete --id $publicIp
}
Outputs:
OR
You can directly delete all the resources while the running the VM delete Command as well but there are some Prerequisites for this method i.e. While creating the VM using CLI you have to configure couple of features like below :
As per Microsoft Document in az vm create section:
[--os-disk-delete-option {Delete, Detach}]
Specify the behavior of
the managed disk when the VM gets deleted i.e whether the managed
disk is deleted or detached.
accepted values: Delete, Detach
[--data-disk-delete-option]
Specify whether data disk should be deleted or detached upon VM deletion.
[--nic-delete-option]
Specify what happens to the network interface when the VM is
deleted. Use a singular value to apply on all resources, or use = to
configure the delete behavior for individual resources. Possible
options are Delete and Detach.
If the above 3 are configured to delete while creating the VM then , when you run the az vm delete it defaults to delete these resources when the VM is to be deleted.
Reference:
Github Support
I am using the below commands for creating the webapp using Azure CLI but getting the below exception-
Unable to retrieve details of the existing app 'newapp2'. Please check that the app is a part of the current subscription
Command -
az webapp create --name newapp2000 --resource-group staging-grp --plan newappplan2000 --runtime "DOTNETCORE|3.1"
subscription- payasgo
Looking forward for assistance.
A very effective way to check if your commands work or not is going to portal, login with your account, check if your web app exist in your subscription or not.
If you don't want to use portal, you could also use CLI commands. You should check if the session you are using linked to your subscription or not:
az account show --output table
If not, use this command to switch to a different subscription:
az account set --subscription "My Demos"
You could also specify the subscription in the command while creating your web app:
az webapp create --resource-group StorageGroups --subscription "My Demos" \
--name newapp2000 --location eastus --plan newappplan2000 --runtime "DOTNETCORE|3.1"
I've created a service principal with push and pull access to/from my private Azure Container Registry. Pushing to ACR works perfectly fine with the following command:
az login --service-principal -u "someSpID" -p "someSpSecret" --tenant "someTenantID"
az acr login --name "someRegistry"
docker push "someRegistry.azurecr.io/my-image:0.0.1"
And I am also able to pull the image directly with the following command:
docker pull "someRegistry.azurecr.io/my-image:0.0.1"
I want to deploy a container instance into a private subnet and I've configured the network security to allow access for my said subnet.
However, when I attempt to deploy a container instance with the following command into my private subnet, where I specified the same service principal which I had previously logged in with, I get an error response.
az container create \
--name myContainerGroup \
--resource-group myResourceGroup \
--image "someRegistry.azurecr.io/my-image:0.0.1" \
--os-type Linux \
--protocol TCP \
--registry-login-server someRegistry.azurecr.io \
--registry-password someSpSecret \
--registry-username someSpID \
--vnet someVNET \
--subnet someSubnet \
--location someLocation \
--ip-address Private
Error:
urllib3.connectionpool : Starting new HTTPS connection (1): management.azure.com:443
urllib3.connectionpool : https://management.azure.com:443 "PUT /subscriptions/mySubscription/resourceGroups/myResourceGroup/providers/Microsoft.ContainerInstance/containerGroups/myContainerGroup?api-version=2018-10-01 HTTP/1.1" 400
msrest.http_logger : Response status: 400
The image 'someRegistry.azurecr.io/my-image:0.0.1' in container group 'myContainerGroup' is not accessible. Please check the image and registry credential.
The same error ensues when I try and deploy the container instance through Azure Portal.
When I tried deploying a public image into the same subnet, it succeeds fine so it isn't a deployment permission issue, neither does it seem to be wrong service principal credentials as the docker pull "someRegistry.azurecr.io/my-image:0.0.1" works just fine. I can't quite wrap my head around this inconsistent behavior. Ideas anyone?
For your issue, here is a possible reason to explain the error you got. Let's look at the limitation describe here:
Only an Azure Kubernetes Service cluster or Azure virtual machine can
be used as a host to access a container registry in a virtual network.
Other Azure services including Azure Container Instances aren't
currently supported.
This limitation shows the firewall of the Azure Container Registry does not support the Azure Container Instance currently. It only supports that pull/push the image in the Azure VM or AKS cluster.
So the solution for you is that change the rules to allow all network and then try again. Or use the AKS cluster, but it will also cost more.