3 ms·

I'm not a YC company but will share one man's opinion about Azure. We started using it because we have one piece of software in our stack that only runs on Wind

I'm not a YC company but will share one man's opinion about Azure. We started using it because we have one piece of software in our stack that only runs on Windows, so we have a Windows VM and a couple Linux VM's running everything else. We're early in the life of the company so we're pretty much just using it for basics, but as a platform it's been fine. My dev ops guy seems to have few complaints on a day to day basis. The one area we've consistently had real issues is with static IP persistence and VM location. At times, between our portal and an RDP session I've seen up to 3 different IP's for the same VM. Our VM's invariably lose their static IP's during reboots, which is a real nightmare because some of our vendors require IP white listing. We also can't seem to confirm that our servers are geographically where they're supposed to be. If we try to geolocate a server in US-West, we variously see it in other parts of the country, or even the world.

learnHowItWorks 10y ago
There's actually some very well thought out features related to what he's having a problem with. Don't just go with the "one endpoint per vm" that the default comes with in the older portal. Create a virtual network. Specify a custom DNS server or two for that subnet. Set static IP's on the NIC object in the new portal. Create a public IP address and bind it to that resource. There are lots of options for fixing this problem. I'm really not trying to be all "read the eff manual" or anything. It really has changed a lot. Look at how some of the Azure Resource Manager templates fix this problem. They are all on github. The can show you what's possible even if you don't go with the declarative model for your environment.
partiallypro 10y ago
I'm reasonably seasoned in Azure, though far, far from an expert. But it sounds like you need to set up a Reserved IP in Azure, that should solve your problem. You'll need PowerShell to do this. (tut: https://azure.microsoft.com/en-us/blog/reserved-ip-addresses/ https://azure.microsoft.com/en-us/blog/reserved-ip-addresses...) I think you can do this from the Azure CP now, I am not 100% sure. Your IP should not flush on reboot though, that should theoretically only occur if you're doing cold boots/shutdowns; but that's a no-no in any cloud environment unless you have a reserved IP; which is why you are encouraged to use cnames instead for domain management, etc. As far as the region problem, this can happen if you're using something like a scale set or load balancers. That could throw off a trace route. Also making sure your storage account, etc are all in the same region is fairly important.

learnHowItWorks 10y ago

There's actually some very well thought out features related to what he's having a problem with. Don't just go with the "one endpoint per vm" that the default comes with in the older portal. Create a virtual network. Specify a custom DNS server or two for that subnet. Set static IP's on the NIC object in the new portal. Create a public IP address and bind it to that resource. There are lots of options for fixing this problem. I'm really not trying to be all "read the eff manual" or anything. It really has changed a lot. Look at how some of the Azure Resource Manager templates fix this problem. They are all on github. The can show you what's possible even if you don't go with the declarative model for your environment.

partiallypro 10y ago

I'm reasonably seasoned in Azure, though far, far from an expert. But it sounds like you need to set up a Reserved IP in Azure, that should solve your problem. You'll need PowerShell to do this. (tut: https://azure.microsoft.com/en-us/blog/reserved-ip-addresses/ https://azure.microsoft.com/en-us/blog/reserved-ip-addresses...) I think you can do this from the Azure CP now, I am not 100% sure. Your IP should not flush on reboot though, that should theoretically only occur if you're doing cold boots/shutdowns; but that's a no-no in any cloud environment unless you have a reserved IP; which is why you are encouraged to use cnames instead for domain management, etc. As far as the region problem, this can happen if you're using something like a scale set or load balancers. That could throw off a trace route. Also making sure your storage account, etc are all in the same region is fairly important.