I'm currently using the standard blue/green deployment setup here:
I need to use the same public IP for both Load Balancers.
Currently it appears that a load balancer (LB) can only use a 'not used' frontend IP configuration. So, I could switch the load balancer off the public IP onto a temporary one then assign the public IP to the other LB. Not such a slick blue/green deployment though.
Is there a way to overcome this issue so I can switch the traffic manager over and the public IP remains the same?
You can try this:
https://learn.microsoft.com/en-us/rest/api/load-balancer/load-balancers/swap-public-ip-addresses
{
"frontendIPConfigurations": [
{
"id": "/subscriptions/subid/resourceGroups/rg1/providers/Microsoft.Network/loadBalancers/lb1/frontendIPConfigurations/lbfe1",
"properties": {
"publicIPAddress": {
"id": "/subscriptions/subid/resourceGroups/rg2/providers/Microsoft.Network/publicIPAddresses/pip2"
}
}
},
{
"id": "/subscriptions/subid/resourceGroups/rg2/providers/Microsoft.Network/loadBalancers/lb2/frontendIPConfigurations/lbfe2",
"properties": {
"publicIPAddress": {
"id": "/subscriptions/subid/resourceGroups/rg1/providers/Microsoft.Network/publicIPAddresses/pip1"
}
}
}
]
}
I would probably still prefer a blue/green solution that does not depend on something like this, but it can be a start.
Related
I have my web app running on Azure with scale out to have multiple instances.
I can get the list instances name using the Management API of Azure as below
https://management.azure.com/subscriptions/"SubscriptionID"/resourceGroups/"ResournceGroupName"/providers/Microsoft.Web/sites/"sitename"/instances?api-version=2018-02-01
This API provides me the below information
"value": [
{
"id": "/subscriptions/subscriptionid/resourceGroups/websitename/providers/Microsoft.Web/sites/websitename/instances/instancename",
"name": "68e9f48782245c3a112318 INSTANCE NAME ac97aa9f0b55a4b0eb7a0",
"type": "Microsoft.Web/sites/instances",
"location": "UK West",
"properties": {
"name": "68e9f48782245c3a112318 INSTANCE NAME ac97aa9f0b55a4b0eb7a0",
"siteInstanceName": "68e9f48782245c3a112318 INSTANCE NAME ac97aa9f0b55a4b0eb7a0"
}
I wanted to know the IP address of each instance. Can any one please help me how can i get that.
You can't know beforehand which IP address a given app instance will
use to make the outbound connection
So, unfortunately, you just can know the possible outbound IP addresses and not the exact IP address. The inbound IP address may also change when you perform some actions. But you can get a static inbound IP address if you configure an IP-based SSL binding. See Get static inbound IP.
You can retrieve the possible IP list of the scaled instances in Azure Portal. Find the possibilities of retrieving the IP of scaled instances here.
There are 100 external domains are pointing to my existing application. We're planning to migrate to Azure App service. In this case, we have to request all domain users to point to our new app service. It involved lot of coordination and takes time.
In future(may after 2 years), we've a plan to deploy solution to another app service or azure VM, then we've to repeat the same process of requesting external domain owner to point to new deployment environment.
Currently we're thinking below two solutions. Could you please suggest on those.
First, create a public static IP address, and request all external domains to point to this IP address.
Solution 1:
Attach this IP address to Azure VM which is very lower capacity and use this server as redirecting url where ever you deploy the solution, it may be Azure app service.
Solution 2:
Is it possible to attach public static IP address to Azure app service? I know app service is not an IaaS service to control on infrastructure. I went through some of article to set static IP address to app service. But that is different that what I required.
Please also suggest if you've any other better solution.
Regards,
Venkat
For solution1, It's easy to set the static public IP for an Azure VM. But it might lack redundancy. All of the services rely on the only one Azure VM.
I will suggest Solution2, Azure app services run in the same App service plan which shared the compute resources and VM instances are available to you for scale-out. You can flexibly adjust the app service plan according to your need. Generally, the Azure web app service IP addresses change when you perform one of the following actions:
Delete an app and recreate it in a different resource group. Delete
the last app in a resource group and region combination and recreate
it. Delete an existing SSL binding, such as during certificate renewal
(see Renew certificates).
The Azure web app service IP address does not change, this looks like "static" unless you do the above actions and change to a free tier. Sometimes, if you want a dedicated, static IP address for your app. You need to configure an IP-based SSL binding.
Ref: How to get a static IP address for your Windows App Service Web App
Nancy, thanks for your suggestion. It helps me to finalize solution.
Three solutions we identified for this scenario. We chose 3rd solution.
Use static IP for azure app service and wanted to migrate after a year or two you would have to inform every external domain owner to change their endpoint to a different environment.
https://learn.microsoft.com/en-us/azure/cloud-services/cloud-services-custom-domain-name-portal#understand-cname-and-a-records
A CNAME may be a better alternative since it maps to a specific domain and will resolve to the ip address of your app automatically so if your cloud services changes you will not have to take any action.
Create a public static IP address, request every external domain owners to point to this IP address. Next, create a Azure VM with low capacity (B1ms) and attach the public static IP address to this VM. Then use this VM as reverse proxy, currently it may point to existing Azure app service, in future, wherever new environment will be, I will redirect to that environment. In future, public static IP address can also attach to load balancer or any other azure VM.
I did it like this:
Create a Virtual Network
Create NAT Gateway
Create Public IP Create
SubNets for each App
Attach SubNets to VN
Use NAT In SubNets
Enable vnetRouteAllEnabled for each App
Bicep for the network part:
param location string = resourceGroup().location
var appOne = 'app-one'
var appTwo = 'app-two'
resource publicIp 'Microsoft.Network/publicIPAddresses#2021-05-01' = {
name: 'public-ip-name'
location: location
sku: {
name: 'Standard'
}
properties: {
publicIPAddressVersion: 'IPv4'
publicIPAllocationMethod: 'Static'
idleTimeoutInMinutes: 4
}
}
resource natgateway 'Microsoft.Network/natGateways#2021-05-01' = {
name: 'natgateway-name'
location: location
sku: {
name: 'Standard'
}
properties: {
idleTimeoutInMinutes: 4
publicIpAddresses: [
{
id: publicIp.id
}
]
}
}
resource virtualNetwork 'Microsoft.Network/virtualNetworks#2021-05-01' = {
name: 'virtualNetwork'
location: location
properties: {
addressSpace: {
addressPrefixes: [
'192.168.0.0/16'
]
}
subnets: [
{
name: 'subnet-for-${appOne}'
properties: {
addressPrefix: '192.168.0.0/24'
natGateway: {
id: natgateway.id
}
delegations: [
{
name: 'delegation'
properties: {
serviceName: 'Microsoft.Web/serverfarms'
}
}
]
}
}
{
name: 'subnet-for-${appTwo}'
properties: {
addressPrefix: '192.168.1.0/24'
natGateway: {
id: natgateway.id
}
delegations: [
{
name: 'delegation'
properties: {
serviceName: 'Microsoft.Web/serverfarms'
}
}
]
}
}
]
}
}
resource prodcutsToSubnet 'Microsoft.Web/sites/networkConfig#2022-03-01' = {
name: '${appOne}/virtualNetwork'
properties: {
subnetResourceId: virtualNetwork.properties.subnets[0].id
swiftSupported: true
}
}
resource webhooksToSubnet 'Microsoft.Web/sites/networkConfig#2022-03-01' = {
name: '${appTwo}/virtualNetwork'
properties: {
subnetResourceId: virtualNetwork.properties.subnets[1].id
swiftSupported: true
}
}
I have an Azure Load Balancer in front of a Azure VM Scale Set (VMSS). I also have a NAT pool configured on the Load Balancer like the following:
{
"name": "InstanceInputEndpointNatPool",
"properties": {
"backendPort": 10000,
"frontendIPConfiguration": {
"id": "[concat(resourceId('Microsoft.Network/loadBalancers', variables('loadBalancers_01_name')), '/frontendIPConfigurations/LoadBalancerIPConfig')]"
},
"frontendPortRangeStart": 10100,
"frontendPortRangeEnd": 10500,
"protocol": "Tcp"
}
}
Essentially, for each VM in the VMSS, the load balancer forwards a request received at DNSName:PORT(between 10100-10500) to one of the VMs:10000(same backend port).
Is it possible to retrieve the PORT assigned to this VM, programmatically in C#, for a program running on that VM? This would help me directly target that VM port.
You may refer the article and find the code on GitHub link.
The API seems to support public or private for ip address, but I can't figure out how to get that private ip address on a vnet.
"properties": {
"containers": [
],
"osType": "Linux",
"ipAddress": {
"type": "Public",
"ports": [
{
"protocol": "tcp",
"port": "[parameters('port')]"
}
]
I'm guessing it's either not documented or not possible yet. I was wondering about exposing multiple IPs, and even though the portal doesn't have it I was able to get it working from the template by just adding it there, so I'm wondering if there is a way to get the instance on a VNET for an internal IP address through the template?
Azure Container Instances currently don't have VNet integration, so it's not possible to get a private ip - we will have it by the time Azure Container Instances reaches GA. Thanks!
Looks like this feature is now in preview:
https://learn.microsoft.com/en-us/azure/container-instances/container-instances-vnet
I deployed a swarm ACS and a Load Balancer was auto deployed also.
I'm using an Application Gateway for SSL offloading and want to point it at my swarm agents.
However, since the swarm agents are configured as the backend pool for the Load Balancer, I can't also make the swarm agents a backend pool for the Application Gateway.
I don't need/want the Load Balancer, but I can't delete it since it has a backend pool associated with is.
This is the same story for GUI or CLI deployed ACS'.
I asked this same question over at Microsoft, but they eventually directed me here.
Thoughts?
Thanks for reading.
There are two solutions. The second solution is better since you can deploy a modern swarm mode cluster:
For ACS deployed swarm cluster, in the following order make the following modifications:
remove the loadBalancerBackendAddressPools relation ship in the VMSS object
remove the loadBalancer
remove the public ip associated with the loadBalancer.
Use ACS-Engine, https://github.com/Azure/acs-engine, to deploy a cluster without a load balancer using the model such as the following:
{
"apiVersion": "vlabs",
"properties": {
"orchestratorProfile": {
"orchestratorType": "SwarmMode"
},
"masterProfile": {
"count": 3,
"dnsPrefix": "",
"vmSize": "Standard_D2_v2"
},
"agentPoolProfiles": [
{
"name": "agentpublic",
"count": 3,
"vmSize": "Standard_D2_v2"
}
],
"linuxProfile": {
"adminUsername": "azureuser",
"ssh": {
"publicKeys": [
{
"keyData": ""
}
]
}
}
}
}