Azure Container Services has the option now to run in containers.
To register the billing you have to give your API key + Billing URL.
Even though I configured everything correctly and the service works locally, my calls are not registered as quoata's.
PS: Dont try to run the container without an internet connection, it will block the calls then ;)
Willem,
Here's what I think is going on: The problem is the linux container host picks an IP address range for the container that includes the IP addresses of your local DNS servers. This makes it impossible for the container to resolve names as requests for that range just end up on the local container network and won't go to the DNS servers.
The problem is described in this entry along with several solutions. The best solution seems to be at the very bottom which is also described in the docker documentation. The short version of this is to update the routing table on the host with the reserved IP range so that docker won’t pick it for the container.
Hope this helps,
Henrik
Related
My basic problem is to run multiple containers that make HTTP requests to a test server. I need the source IP registered by the test server to be different for the request made by each container. I am using azure AKS.
So far I follow the documentation from:
https://learn.microsoft.com/en-us/azure/aks/limit-egress-traffic#restrict-egress-traffic-using-azure-firewall
The above works fine. I need to run another container with a different IP address. For that I created a new Ip address to the firewall, a new Kubernetes service, and a new NAT rules connecting them. That didn't work: the source Ip registered by the test server is the same firewall IP.
The Documentation also states that:
"If needed, you can generalize the steps above to forward the traffic to your preferred egress solution, following the Outbound Type userDefinedRoute documentation."
For that, I create a cluster with vm-set-type of VirtualMachineScaleSets and load-balancer-sku of Standard. Try the above steps and it didn't work. Also, I created a new route on the Route table connecting the internet to the new public IP.. nothing
I am lack of ideas. I don't know if I mess something up. Anyway.. Any idea is welcome. Thanks in advance.
I'm running an azure function which gets data from an API and stores it in a blob. Everything worked fine and stopped working out of nowhere. We then got in contact with our provider and they told us they made some changes in their API. After we made the necessary changes in our code,started getting an IP denied error from their part. I then searched and found the possible outbound IP addresses for the Azure Function. They whitelisted the whole list and still
They aren't getting any requests from those IP's,
We are not able to access that data for the same reason our IP is denied.
We've been running the code in a local machine and it works completely fine, but this is just a temporary fix and we want to keep everything in the cloud.
I've been stuck with this for about 3 weeks. I've looked into different solutions and I found about Azure Logic Apps and Azure Service Fabric.
Is there something missing in my Azure Function that isn't allowing me to make requests to the API? Am I using the wrong outbound IP? Also, if I use any of the other two services, will I encounter with the same problem? I did some research on them and I think they both also use multiple outbound IP addresses, so I'm worried I'll get the same problem.
Using NAT gateway you can specify a static IP address for outbound traffic, your function app need to be attached on a subnet which is not available for consumption plan.
Here is where you should be getting the Azure IP address ranges from. Azure Functions originate from the App Service Plan ranges. Note that this is updated weekly, things change, but not too often. Your provider will need to open all the relevant ranges and keep up to date with any changes. If your solution is not mission critical with a high SLA, then having your service provider open the relevant ranges and deal with failures, updating the ranges on an ad-hoc basis should be fine.
Secondly, if you have a good relationship with the provider, ask them to check the firewall, they will be able to give you an indication of the IP's getting blocked by checking the firewall logs. This will help you find the right range.
The only guaranteed way to solve this in a mission critical solution is to run your Azure Functions from an dedicated app service plan with a dedicated IP address. This is an expensive option but will be the most robust.
Additional helpful information here on how App Services works with IPs can be found here.
If a docker enabled VM is restarted, e.g. due to Azure patching the VM or for whatever reason, the node can get a new IP address (VirtualBox can cause this, and Azure too)
Which in turn results in the cert no longer being valid and Docker fails to start on that machine.
If I use Docker Swarm, the result is that the restarted node will be stuck in status Pending indefinitely.
If I then do a docker-machine regenerate-certs mymachine then it starts working again.
How should I reason around this?
I guess there is no way around having nodes being restarted, so how do you deal with this?
Regarding Azure you can ensure your VM keeps its public IP address after restart by using "Reserved IP" addresses. Please note using reserved IPs on Azure (as with other cloud providers) may incur additional charges. https://azure.microsoft.com/en-us/documentation/articles/virtual-networks-reserved-public-ip/
Another way to handle this is using discovery. Swarm offers a discovery mechanism which support etcd, consul and zookeeper. Find more details here:
https://docs.docker.com/swarm/discovery/
I got a website (Web App) running on Azure (example.azurewebsites.net) and I want to use NEST (http://nest.azurewebsites.net) in my Asp.Net MVC solution. Locally it works fine, but when publishing it to Azure, I can't get a connection to elasticsearch. Because I did not found any useful tutorial, I mixed three together.
First I created a virtual network like described here in Step 1: http://www.kerrb.com/ecAzureVms101/day4-creating-point-to-site-vpn-to-azure-virtual-machines
I called it VirtualNetwork and got a Gateway-IP-Adress. It shows me that 1 Client is connected.
Then I created a virtual machine like described here: http://code972.com/blog/2014/07/74-the-definitive-guide-for-elasticsearch-on-windows-azure
I already had the virtual network, so I skipped the first step here. The cloud service got the name example-elastic-search (example-elastic-search.cloudapp.net) I called the virtual machine elasticsearchvm. I connected via putty, configured elasticsearch like described and I it works fine.
The last step with Azure was to connect the Web App with the virtual network. I did it like this: http://blogs.technet.com/b/canitpro/archive/2015/04/07/step-by-step-connect-an-azure-web-app-to-an-existing-virtual-network.aspx
Finally I changed my code to use the elasticsearchvm.
new ElasticClient(new ConnectionSettings(new Uri("http://example-elastic-search.cloudapp.net")))
Instead of example-elastic-search.cloudapp.net I also tried the name of the virtual machine (elasticsearchvm), the internal and public IPs of the VM, the IP of the cloud service and the IP of the gateway. All of these with http, https, the port and without the port (9200). Nothing worked.
Any ideas, what I have missed? If more informations are needed, feel free to ask :)
I realise that this is not directly answering your question, but I think this is useful to mention for those finding this question in future. The easiest way to get up and running with Elasticsearch on Azure is to use Elastic's ARM template; I wrote a blog post about some of the features available within the template.
The template can be deployed from within the portal UI or using the Azure CLI; the former is good for getting started and playing around, and the latter is useful to integrate the template into your automation environment of choice. You can of course clone/fork the repository and make changes to the template to suit your requirements.
When adding Elasticsearch to an existing web application, the deployed cluster can be attached to an existing virtual network in the same location; you just need to specify
the name of the network
the name of the subnet
the name of the resource group containing the network
An available IP address to use for the internal load balancer
You'll need enough available IP addresses on the network for the cluster you're deploying.
I configured two AD controllers and a WINS server in Azure each with static IP's and then turned them off for the weekend. Now that I turn the machines back on, all of the NIC's are setup to obtain an IP automatically.
When I go back into the NIC and reconfigure it for a static IP, I get an error message that the IP address I entered for the network adapter is already assigned to another adopter which is no longer present in the computer. Then it asks me if I want to remove the static IP configuration for the absent adapter.
What is happening here? Is there something I am configuring incorrectly that forces my configured static NIC's to change? Do I want to answer yes and reconfigure the card yet again, or is there a better way to go about this.
Thanks.
I'm going to answer my own question just in case someone is doing a network search looking for an answer and winds up here.
The issue centers on, for me at least, the differences between what is required for setting up bare metal AD environments as opposed to AD environments in Azure. In bare metal we are used to configuring inside of the NIC. In Azure, you work in two places. You create your AD's with DNS and then you use the Azure powershell to configure the AD controller's static IP and then you go back to your virtual network and register the DNS servers that were created.
There are some things happening behind the scenes in Azure that make this work. So, just create your AD's with DNS. Get the IP that was assigned by DHCP and register it with the Azure powershell and then list the name of the AD and it's IP in the virtual network and you are done.
Hope this helps.