Does Azure provide a static IP address to the web role or is it dynamically allocated each time I deploy or redeploy my application ?
Azure now supports reserving IP addresses: http://azure.microsoft.com/blog/2014/05/14/reserved-ip-addresses/
As long as you do not delete a deployment, but rather upgrade it, you will keep your "VIP" (Virtual IP address).
You also can deploy to a staging instance and "Swap VIP", which means moving your production VIP to your staging slot, and your staging VIP to your production slot. In effect, this moves your staging slot into production.
You cannot allocate an IP address permanently to a cloud service, however. They are permanent only within a deployment.
When you deploy your cloud service, the service is assigned an IP address. You can then update the deployment in several ways without losing your assigned IP address.
Take a look at this blog post which enumerates what you can do with in-place updates, while preserving your IP address.
Related
is it possible to determine each slot of an azure webapp to different ip adresses / vnets? e.g. dev-slot to the dev-vnet and prod-slot to the prod-vnet
the properties to determine outbound ip-adresses work "global" (for the whole webapp is not offering slot individual options.
Any idea how to do that (one ip / better vnet for each webapp slot) is very much appreciated!
Thank you very much!
As I know, it is not possible to determine each slot of an Azure web app to a different IP address.
Deployment slots are actually live apps with their own hostnames which is different from Azure web app hostnames. But the slots have the same IP address with Azure web app in Azure. You can use Ping utility to verify it, Ping timeout can say nothing only we can see the host from the web app or each slot in azure.
Here are the screenshots of two slots- staging and full in Azure web app service.
Actually, the IP address 13.90.143.69 is also the IP address of the Azure web app service. If you want dev-slot to the dev-vnet and prod-slot to the prod-vnet. I think it should be dev-slot linked to Azure web app service1 and prod-slot linked to Azure web service2. The service1 has a different IP address with service2.
Hope this makes sense.
I published my Cloud Service from visual studio with the advanced setting Incremental Update selected. My understanding was that this would allow my service to keep the previous assigned IP address. However, after my publish my service had a new IP Address assigned to it.
Does anyone know why or what other factors may be involved? I don't think this should matter and I don't know why I got this error. While the package uploaded fine the overall deployment ended with the following message.
The deployment has timed out while waiting on the role to reach the
ready status.
I don't know that this should be a factor in the assigned IP Address though.
Any time Azure deploys a Cloud Service and provisions a new VM it can and most often will assign a new VIP (Virtual IP Address) to the Cloud Service. If you want/need the VIP to stay the same always then you will need to setup a Reserved IP for use with your Cloud Service.
I have an Azure Cloud Service, mywebapp.cloudapp.net, that consists of two Azure VMs - mywebappvm1 and mywebappvm2. Both VMs are in the same Availability Set and have the same DNS name.
I also have a Regional Reserved IP address assigned to the Cloud Service so that I can give our clients a guaranteed IP address that our app uses.
Part of the app uses a private background process, currently only running on one of the VMs. I want to be able to make a connection to that process over TCP running on mywebappvm1 from mywebappvm2. I could use the public IP and an endpoint on mywebappvm1 but I don't want the background service to be publicly accessible.
I'm currently using the private IP address, but is that safe? Will the private IP of each VM change if it's rebooted? I can't see an easy way of fixing the private IP of each VM - that seems like something you can do with a VNET but I can't find any information on how to do it with a cloud service and an availability group as well.
Is there perhaps another way to run a web app on multiple load-balanced VMs within an availability set that would make this easier?
What you do is absolutely safe and actually a recommended best practice. You should not go out to public IP address in order to communicate between the Virtual Machines.
It is also a recommended best practice to organize your Virtual Machines into Virtual Network and sub-nets.
This excellent blog post describes how can you even use static IP addresses for the VMs, so you are always 100% sure that mywebappvm1 always get XXX.XXX.XXX.XXX IP Address andyour mywebappvm2 always get YYY.YYY.YYY.YYY IP Address.
Please note that if you do not use Static IP Address assigned to the VM, it is guaranteed that the IP Address of the VM may change.
The IP for a webRole VM instance will not change for the lifetime of the deployment regardless of reboot, update or swapping. The IP will be released only if you delete the deployment, detailed here
Background. I have a service that is crawling a partners website. Their website blocks "bot like" behaviour by IP Address. They don't control their servers themselves, so they want me to change IP address of my crawler often (e.g. every minute). The crawler is currently running as an Azure Cloud Service.
So my question is. How would you programmatically change the IP address of an Azure server?
I could use a Proxy... but the site is running on SSL, so I'm not sure this is an option.
I could use a VPN connection... but I'm not sure if it's possible to programmatically dial a VPN from within a Cloud Service/VM? I'm using C#/.NET.
Finally. I tried to do a VIP Swap, which actually gives me a new IP in seconds. But unfortunately this only works when swapping form Staging to Production. I get an error when trying to swap from Production to Staging, if there is no staging running. Why is this blocked?
You cannot programmatically change a deployment's IP address, aside from shutting down the deployment (which releases the IP address) and then re-starting it (and that you can do programmatically, or through PowerShell). Also note that if you have several Virtual Machines in the same deployment, each VM will share the same public IP address.
Note that with Virtual Machines (vs. web/worker role cloud services), if you have a single Virtual Machine, you can stop the VM, then restart it, and you'll get a new IP address (ok, actually, there's no guarantee you'll get a different IP address, so more accurately you'll be assigned an IP address) while retaining the state of your VM. Shutdown and startup are not an instantaneous operatios however, and it's not going to provide you a per-minute IP address (and your VM will end up being offline shutting down or starting up pretty much all the time), so it won't satisfy your requirement.
I want to move my web role to a smaller VM size for cost saving purposes.
I changed the vmsize attribute in WebRole in the ServiceDefinition.csdef accordingly. On publishing I received the following error:
Total requested resources are too large for the specified VM size
So I then reduced the size of the local storage resources in the ServiceDefinition.csdef. Then I got the error while publishing:
The size of local resources cannot be reduced. Affected local resource
is DataFiles in role Website.
From what I have read online, I will need to delete the deployment and republish it. But this will assign a new IP to my cloud service. I can't have this happen.
Is there another solution to my problem?
To add on to what sharptooth said....
In your specific case you should deploy to the staging slot and then perform a VIP swap. This will leave you with your original IP address, and will put your new hosted service (with the smaller VM size) in the production slot. You can then delete your staging slot (your old service with the larger VM size).
If you can't do a VIP swap then you can deploy your updated application to a new hosted service which will result in a new IP address. You can then update whatever is dependent on the IP address (firewalls, whitelists, etc) to the new hosted service's IP address, then once everything is working correctly you can update your cname/arecord to the new hosted service and then delete the old hosted service.
However, while you can't do it for your scenario, an in-place upgrade is a better upgrade option than VIP swap whenever possible. With the VIP swap you have the potential to momentarily lose connectivity to external resources that rely on your public IP address. The issue is that outbound traffic can fail if connecting to a resource which does IP address whitelisting, which for most services effectively means that they are down.
Normally, outbound traffic (ie. a call to SQL Azure) is SNATed from the DIP to the VIP. If the resource being called (ie. SQL Azure) does IP whitelisting then this is no problem because the traffic will be coming from the VIP which is a known good IP address. During the VIP swap there is a short period of time, typically just a few seconds but in some cases can be a couple minutes or more, where the SNAT is in flux and does not happen. This means that traffic from an Azure VM appears to be coming from the DIP which will cause the connection to be blocked because the DIP IP address is not in the whitelist.