We have a single cloud service (within same resource group) in Azure that contains two VMs and would like each of the VMs to host some external facing websites on port 80.
Take for example:
VM1 = www.domain1.com:80, www.domain2.com:80
VM2 = www.domain3.com:80, www.domain4.com:80
It seems with Azure all resources within a Cloud Service share the same VIP, DNS Name and Endpoints settings and in particular the VIP is pointing to the cloud service and not any VM. Since all the settings are shared we cannot create a DNS record pointing directly to the individual VMs.
Is this a limitation of Azure or setup issue?
We've tried giving each VM it's own Instance IP address but only 1 can be assigned as we receive an error message on the 2nd VM:
Failed to update IP address in the virtual machine 'XXXX'. Error: The operation '08faed40bf2fad76a67fac50be475a33' failed: 'The server encountered an internal error. Please retry the request.'
I did notice that the Virtual IP address assignment = Dynamic - But not sure if that's related to the above error?
Related
I followed the documentation guide here to configure an Azure DNS zone for a virtual network.
I then created a virtual machine on that virtual network and provisioned a virtual network gateway to allow my Azure web apps to communicate with the virtual machine using VNet integration. My web apps are then able to resolve against the virtual machines private IP as expected.
I then created an 'A' type record set within the DNS zone resolving a service name against the private IP of the virtual machine just like here.
However, when I then attempt to access the DNS configured service name that should resolve against the private IP address of the virtual machine, I get the following error:
curl: (6) Could not resolve host: xxxx.local
Am I missing something obvious here?
I can not reproduce this error following your steps:
Create an Azure VNet with a DNS private zone like private.test.com.
Create a VM and a VPN gateway on that VNet.
Enable VNet integration with my Azure web app service.
My web apps are able to resolve against the virtual machines private IP as expected. This could verify the Azure private DNS zone should work. Then I also create an A record for a custom name against the VM private IP address. Both scenarios work.
You could check if an A record is something like below picture in the private DNS zone.
Then you could verify if curl with http:// or without that, or without the specific port 9200, the error is still the same.
I suggest using SET WEBSITE_DNS_ command. This command will output the current DNS server that is being used by the web app. If the error Environment variable WEBSITE_DNS_ not defined is received, no custom DNS servers are configured for the web app. See more details about networking Related Commands for Azure App Services.
We have time triggered Azure Function deployed on portal to perform some iterative task at specific time. Our azure function uses the database deployed on Azure VM via connection string provided at AppSettings. The function throws following error on running:
MySql.Data: Authentication to host 'xxx' for user 'xxx using method 'mysql_native_password' failed with message:
Client with IP address 'x.x.x.x' is not allowed to connect to this MySQL server. MySql.Data: Client with IP address 'x.x.x.x' is not allowed to connect to this MySQL server*
When we white-list the IP mentioned in error message, the function runs successfully. But since the azure function has no determined work-station or PC of same IP that handles the execution, whenever the function runs from new IP, it throws the error back. Therefore, we require a mechanism by which we can white-list all IPs of PCs that will be running our function app OR some better mechanism to authenticate and allow azure function to access our database hosted on Azure VM.
What we tried?
We white-listed the Virtual IP address of the function app. But it doesn't work every time.
We tried to white-list the IP ranges obtained from Microsoft Datacenter of the region in which our function app is deployed. But this method also didn't work.
Azure application can't access database on Azure VM?
Thus, is there any way by which azure function can access our database deployed on Virtual machine securely?
I have opened up the issue on github but no reply yet from there.
Finally, after thorough researching, found the solution.
One need to white-list all Outbound IPs of Function App in Virtual Machine where DB is deployed. The outbound IP address can be found from resources.azure.com. On searching your resource (in my case Function app's name), there will be a long json output from where you have to pick possibleOutboundIpAddresses parameter as shown in the image. Whitelist all Ips and then your azure function app can access your database deployed on virtual machine.
Also, I searched whether these IPs tend to change on regular basis or not. While I didn't find any official word from it, but from various internet sources I came to know that even if the IPs gets planned to be changed ever, everyone will get enough notifications before that to prevent any problems.
You need to set up a Virtual Network (VNet) where both your App Service Plan hosting the Azure Function and the VM participate.
Then from Azure Functions, view All Properties > Networking and you should see the virtual network to connect.
This method doesn't require you to whitelist IP addresses for your VM and secures your VM by allowing only internal network traffice.
Note that your Azure Function must be set up on an App Service Plan, rather than on a Consumption plan.
I have successfully used this recipe in the past to migrate a virtual network including attached VMs: https://learn.microsoft.com/en-us/azure/virtual-machines/virtual-machines-linux-cli-migration-classic-resource-manager
But today, and also when I tried last week, no matter the number of reboots, I get this error (Azure CLI):
> azure network vnet prepare-migration "<RG-NAME>"
info: Executing command network vnet prepare-migration
error: BadRequest : Migration is not allowed for HostedService
<CLOUD-SERVICE> because it has VM <VM-NAME> in State :
RoleStateUnknown. Migration is allowed only when the VM is in one of the
following states - Running, Stopped, Stopped Deallocated.
The VM is in fact running smoothly, and so says the Azure portal.
So any ideas how to get out of this mess?
Have you edited the NSG or local firewall of the VM? Please do not restrict the outbound traffic from the VM. It may break the VM Agent.
Also, please check if the VM Agent is running properly. If the VM Agent is not reachable, this issue may occur.
==============================================================================
Only issue is that I don't seem to be able to moved the Reserve IP to my new load balancer.
If we migrate the cloud service with a preserved public IP address, this public IP address will be migrated to ARM and be assigned to a load balancer automatically. (The load balancer is auto-created.) Then, you are able to re-assign this static public IP address to your load balancer.
Here is the screenshot of my lab:
Before the migration
After the migration
I can re-associate the IP with new load balancer after I delete the auto-created one.
I have 2 different virtual networks set up in azure. The first of these virtual networks contains virtual machines in which I am able to set the internal virtual network IP as 10.101.1.4, 10.101.1.5, 10.101.1.6 on the virtual machines by using the preview portal to set the IP address
In my other virtual network I have a VPN connection and from the virtual network I add a Cloud service which we have informed the other side of the VPN will be available on 10.103.1.4 but for some reason this has now changed to 10.103.1.5
Is there any means of ensuring that the cloud service will always be deployed to the 10.103.1.4 IP address within the virtual network?
an compute instance or an azureVM get an IP-Adresse via DHCP and the lease time is 100+ years. to set a specific IP-Adresse to an azureVM/compute instance you can define a "static ip reservation" in your own VNET to this instance. e.g. via powershell, the new portal or via your cloud service configuration schema.
check out this link: https://azure.microsoft.com/en-us/blog/reserved-ip-addresses/
regards
patrick
I had a need to add additional public IP addresses to an Azure VM and found a working solution here:
Azure VM: More than one Public IP
Essentially this creates a reserved IP in Azure and then adds the reserved IP to a cloud service. Once it's bound to a cloud service it can be mapped to a VM endpoint.
This all works great but there is one bit I don't understand - The IP address of the reserved IP and the resultant VM endpoint don't match. I have to set up DNS to point to the IP address of the endpoint to make this work. Is there something I am not doing right, or is this just the way reserved VMs work?
It looks like this unanswered question is the same issue:
azure reserved IP for VM is diffrent than the given
Thanks!
The "Azure Cloud Service" is a container that provides internet connectivity to "Azure VMs". Thus, you assign the Internet facing Public IP to the Cloud Service. This article is relatively good at explaining the relationship: Azure Cloud Services
From above link:
Here’s a definition of an Azure IaaS cloud service that will make it easy for you to understand what it is in the context of Azure Infrastructure Services:
A cloud service is a network container where you can place virtual machines.
All virtual machines in that container can communicate with each other directly through Azure (and therefore don’t have to go out to the Internet to communicate with each other).
This container is also assigned a DNS name that is reachable from the Internet.
A rudimentary DNS server is created and can provide name resolution for all virtual machines within the same cloud service container (note that name resolution provided by the DNS server is only available to the virtual machines that are located within the cloud service).
One or more Virtual IP Addresses (VIPs) are assigned to the container and these IP addresses can be used to allow inbound connections from the Internet to the virtual machines.
Certain services (like FTP) may require your vm have a public IP: Azure VM Public IP
(IaaS v1) An Azure cloud service comes with a permanent DNS name - something.cloudapp.net - and has a single VIP allocated whenever there are VMs deployed in it OR whenever a reserved IP address is associated with it. Traffic is either load balanced or NATted (port forwarded) to the VM from the Azure Load Balancer sitting on the VIP. You can also associate a public instance-level IP address (PIP) with a VM, which gives it an additional IP address. The VIP always has a DNS name (something.cloudapp.net) while the PIP has one only if you specifically add it, I did a post which goes into these differences.
(IaaS v2) VMs are not deployed into cloud services and only have a public IP address if one is specifically added - either by configuring a PIP on the NIC of the VM (and optionally giving it a cloudapp.azure.com DNS name) or by configuring a load balancer and either load balancing or NATting traffic to it. This load balancer is configured with a public IP address and can optionally have a cloudapp.azure.com DNS name associated with it. (Ignoring internal load balancers in this discussion.)