We have an Azure Container Instance which holds a container for RabbitMQ. The IP address of the container keeps changing, which makes the rabbitmq server unreachable. Is there a way to make this static? do we need to add a DNS on top of the IP address if this can be made static?
As pointed out by #evidalpe, you can't assign a static IP address to a container instance. However, you can easily assign a static/predictable DNS name using dnsNameLabel. I find this much more convenient than using the IP address.
Example:
customdnslabel.westeurope.azurecontainer.io
You can set the DNS name label when creating the container instance, and also update the label for an existing instance. You cannot edit it using the portal, but it is shown as "FQDN" afterwards.
Azure CLI Example - Works for create and update. Azure CLI can also be executed using the Cloud Shell.
az container create -g myresourcegroup -n mycontainerinstancename --dns-name-label customdnslabel --image rabbitmq
Bicep Template:
resource mycontainerinstance 'Microsoft.ContainerInstance/containerGroups#2021-03-01' = {
name: 'mycontainerinstancename'
location: location
properties: {
osType: 'Linux'
restartPolicy: 'Always'
ipAddress: {
dnsNameLabel: 'customdnslabel'
type: 'Public'
ports: [
// ...
]
}
containers: [
{
name: 'mycontainer'
properties: {
image: image
resources: {
requests: {
cpu: cpus
memoryInGB: memory
}
}
ports: [
// ...
]
}
}
]
This is a known issue and several solutions have been proposed so far:
Static IP address for Azure Container Intances
Attaching a static ip address to Azure Container Instance
Another solution is setting up an Azure function that periodically checks the Container Instance IP, and when it changes, the function updates the Server IP accordingly.
A container orchestration system like Kubernetes could help overcoming the issue as well.
Related
So I have deployed a container containing a microservice in Azure Kubernetes cluster in subnet A. And I have another microservice that is running on a VM but in another subnet B. I have to call rest APIs of the application running inside the container from a VM. How can I achieve it?
The right way to achieve that is by creating an internal load balancer.
From the docs:
To restrict access to your applications in Azure Kubernetes Service
(AKS), you can create and use an internal load balancer. An internal
load balancer makes a Kubernetes service accessible only to
applications running in the same virtual network as the Kubernetes
cluster.
Follow Specify a different subnet section:
To specify a subnet for your load balancer, add the
azure-load-balancer-internal-subnet annotation to your service. The
subnet specified must be in the same virtual network as your AKS
cluster. When deployed, the load balancer EXTERNAL-IP address is part
of the specified subnet.
Example:
apiVersion: v1
kind: Service
metadata:
name: internal-app
annotations:
service.beta.kubernetes.io/azure-load-balancer-internal: "true"
service.beta.kubernetes.io/azure-load-balancer-internal-subnet: "apps-subnet"
spec:
type: LoadBalancer
ports:
- port: 80
selector:
app: internal-app
Diagram:
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 am having an aks instance running. which I assigned an virtual network to it. So all the Node IPs in the network are good and I can reach them from within the network.
Now I wonder if it is possible to create a 2nd virtual network and tell kubernetes to use it to assign public ips ?
Or maybe is it possible to say that a specific service should always have the same node ip ?
No, this is not supported, you might be able to hack your way through, but certainly not out of the box.
But you can create an internal load balancer for your service in the network and its ip wouldnt change, you do this using a service with an annotation:
---
apiVersion: v1
kind: Service
metadata:
name: name
annotations:
service.beta.kubernetes.io/azure-load-balancer-internal: "true"
spec:
ports:
- port: xxx
selector:
app: name
type: LoadBalancer
We are using managed Kubernetes in Azure (AKS) and have run out of public IP addresses. We only need one, but AKS creates a new public IP every time we deploy a service and it does not delete it when the service is deleted. For example:
apiVersion: v1
kind: Service
metadata:
name: somename
spec:
ports:
- port: 443
targetPort: 443
selector:
app: somename
# Also tried this to reuse public IP in AKS MC resource group
# https://learn.microsoft.com/en-my/azure/aks/static-ip
# loadBalancerIP: x.x.x.x
type: LoadBalancer
Every time this is deployed (kubectl create -f svc.yml) a new public IP is created. When it is deleted (kubectl delete -f svc.yml) the IP remains. Trying to reuse one of the existing IPs with loadBalanceIP as in the comments above fails, "Public ip address ... is referenced by multiple ipconfigs in resource ...".
We have created a service request but it takes ages, so I'm hoping this will be faster. I don't dare to just delete the public IPs in the AKS managed resource as that may cause issues down the line.
Is there a way to safely release or reuse the public IPs? We are using Kubernetes version 1.7.12. We have deleted the deployment referenced by the service as well, it makes no difference.
It should delete the IPs after some time (like 5 minutes tops). So the issue you are having is a bug. You can check k8s events to find the error and look at it.
Also, its perfectly safe to delete Azure resources. k8s wont freak out if they are gone.
Tested with k8s 1.9.1
I am using Azure Container Registry to store my private docker image and Azure Container Instance to deploy it.
I get a public IP address which is OK for verification and simple preview, but not usable (or shareable with customer) since the IP address is dynamic.
Is there a way to set up fully qualified domain name that i can use instead of changing IP address on every container restart?
Browsing through the documentation does not reveal anything about that.
You can now set a dns-name-label as a property for your container group. Details are shared in this answer - hope this helps and thanks for being a user!
Azure Container Group IP Address disappeared
Is there a way to set up fully qualified domain name that i can use
instead of changing IP address on every container restart?
Unfortunately, for now, Azure does not support to set a static public IP address for instance, Azure Container Instance still in preview.
In the future, we will expand our networking capabilities to include
integration with virtual networks, load balancers, and other core
parts of the Azure networking infrastructure.
More information about Azure Container Instance network, please refer to this link.
As a workaround, we can deploy a VM and run docker on it, set static public IP address for this VM, then restart docker we will not lose this public IP address.
When using a docker-compose.yml file on ACI(Azure Container Instances), domainname property is used for FQDN.
services:
service-name:
image: ****
domainname: **FQDN**
Looks like you can do it via Azure CLI using the dns-name-label flag:
az container create --resource-group myResourceGroup --name mycontainer --image mcr.microsoft.com/azuredocs/aci-helloworld --dns-name-label aci-demo --ports 80
src here
This will result in the following FQDN: aci-demo.westeurope.azurecontainer.io (westeurope being your location)