Note that currently, to hook up the rule to the VM, you would need to do the following:
network lb create ...
network lb inbound-nat-rule create ...
network nic ip-config inbound-nat-rule add ...
It's very unintuitive.
@tjprescott When you are saying
network nic ip-config inbound-nat-rule add ...
I've tried with this kind of command:
az network nic ip-config inbound-nat-rule add --inbound-nat-rule RULE_NAME --lb-name LB_NAME --ip-config-name ipConfigNode --resource-group GROUP_NAME --nic-name NIC_NAME
I'm getting this kind of error:
Resource /subscriptions/S/resourceGroups/G/providers/Microsoft.Network/loadBalancers/LB/inboundNatRules/R referenced by resource /subscriptions/S/resourceGroups/G/providers/Microsoft.Network/networkInterfaces/NIC was not found. Please make sure that the referenced resource exists, and that both resources are in the same region.
They are in the same region... Also, when asking details about my inbound-rule, I'm getting backendIpConfiguration: null.
I have to set the backend configuration through the Azure portal... What am I missing!? :)
Az Cli version: 2.0.12+dev
Got it!
I've changed the --inbound-nat-rule NAME by --inbound-nat-rule ID
But, it is not quite clear in the docs provided here: https://docs.microsoft.com/en-us/cli/azure/network/nic/ip-config/inbound-nat-rule#add
It says, _The name or ID of an existing inbound NAT rule._
2 cents here for getting the command signature closer to people's mental model
az network lb inbound-nat-rule create command, suggest expose --vm or --backend-ip-configuration argument, so executing one command will set up all. Currently, having to run az network nic ip-config inbound-nat-rule add to get the backend ip configuration plugged in is rather hard for people to figure out. I guess --vm would be used more often, --backend-ip-configuration will only be useful when the VM has more nics or more than one ip-config per nic, which would be rare under the scale-out contextaz network lb add-vm, which should eliminate more boiler-plate scripts including adding VMs to the BE pool. So yes, I agree with the initiatives mentioned early
Note that currently, to hook up the rule to the VM, you would need to do the following:
network lb create ...
network lb inbound-nat-rule create ...
network nic ip-config inbound-nat-rule add ...
It's very unintuitive.
Once the knack stuff is done (pray it is soon!) I would like to continue this project.
@christiankuhtz, please check out this item and input here any other suggestions you have.
I shall work on it this week.
@yugangw-msft thank you. reading ;-)
This would be a really nice feature if added. Spent a couple hours figuring this out today as it's not intuitive to have the TARGET available in portal but not in the CLI.
Wrote this shell script to handle this in our automation.
resrouce_group="yourResourceGroupName"
loadbalancer_name="YourLBname"
natrule_name="yourNATruleName"
nic_name="yourNICname"
ipconfig_name="this part was trickier since I didn't know where to find this. I ended up using this.
ipconfig_name=$(echo $nic_name | sed -e 's/VNIC/IIP/g')
az network lb inbound-nat-rule create -g $resrouce_group --lb-name $loadbalancer_name -n $natrule_name --protocol Tcp --frontend-port 80 --backend-port 8080
az network nic ip-config inbound-nat-rule add -g $resrouce_group --nic-name $nic_name --inbound-nat-rule $natrule_name --lb-name $loadbalancer_name --ip-config-name $ipconfig_name
Due to the perceived amount of engineering effort needed to simplify these scenarios balanced against the lack of customer asks in this area, we have decided to not pursue these changes.
Does the load balancer and the virtual machine have to be in the same resource group?
Most helpful comment
2 cents here for getting the command signature closer to people's mental model
az network lb inbound-nat-rule createcommand, suggest expose--vmor--backend-ip-configurationargument, so executing one command will set up all. Currently, having to runaz network nic ip-config inbound-nat-rule addto get the backend ip configuration plugged in is rather hard for people to figure out. I guess--vmwould be used more often,--backend-ip-configurationwill only be useful when the VM has more nics or more than one ip-config per nic, which would be rare under the scale-out contextaz network lb add-vm, which should eliminate more boiler-plate scripts including adding VMs to the BE pool.So yes, I agree with the initiatives mentioned early