I am working on a task to deploy ElasticSearch as an azure cloud service with 3 Master + Data Nodes and Kibana 4 as an Azure Website. The ES (2.3.1) service is active and I get the green health status on Chrome sense on retreiving health of ES cluster.
I have used the Kibana 4 binaries in https://github.com/iremmats/kibana4-azure-website for creating a json application that can be deployed as Azure website. The json application that I have created along with configuration for server.js, kibana.yml runs successfully on local VS using node.exe and I am able to discover my ES instance indices on it. However, the moment I deploy this nodejs application to Azure Website and attempt to browse Kibana 4 on Azure website I get Kibana: Bad Gateway exception. Looking into the network timeline of azure website hit, it throws HTTP 502 error on attempting to connect with ElasticSearch cloud service instance.
Below is network timeline screen shot.The IP address mentioned is the IP address of ES cloud service.
Kibana Bad Gateway error and network timeline
It seems that the issue was caused by Azure virtual network configuration for your ElasticSearch cloud service.
I think you may try to do two ways below for the configuration.
Adding a new endpoint for the cloud services to allow the inbound access for port 9200 at the endpoint setting on Azure portal.
Following the article How to manage NSGs using the Azure portal to configure the access rules for subnets in your virtual network between the website and cloud services.
However, I think it's not necessary for integrating the independency Kibana instance with the ElasticSearch instances. In fact, Azure has supplied the Elasticsearch and Kibana integration environment in the Azure Marketplace that you can directly create without any additional configuration. Please try to access the url https://ms.portal.azure.com/#blade/Microsoft_Azure_Marketplace/GalleryFeaturedMenuItemBlade/selectedMenuItemId/home/searchQuery/Elasticsearch%20and%20Kibana/resetMenuId/ to see it, or search the words "Elasticsearch and Kibana" in the search bar of Azure Marketplace to find it.
Any concern, please feel free to let me know.
Related
Earlier we had Windows App Service Plan and App services within the plan have VNet-integration enabled to connect to on-premises services. It used to reach on-premises services from the app service by resolving the domain names.
Recently Microsoft announced that regional VNet-integration for Linux App Services feature is Generally Available. we tried to migrate all our windows app services to Linux. Fortunately, we did not face any issues with subnet-delegation. But after the migration, the Linux app services are not able to reach on-premises service. It says UnknownHostException from the java code and tried from Kudo console, there also it says domain name is not being resolved. and we noticed that logs are not being pushed to Application Insights.
The next day, we just tried with IP address instead of domain names, it worked. For Application Insights, we could not do anything. To just confirm for Application Insights, we disconnected the vnet-integration for app service, then the app is able to send logs to application insights.
So what would be the problem?
You cannot create a Linux Web App in an App Service plan already hosting non-Linux Web Apps. I suppose you have created new app service plan and app service for Linux to manage regional VNet Integration.
Your app cannot resolve addresses in Azure DNS Private Zones without
configuration changes
The feature is fully supported for both Windows and Linux web apps.
All of the behaviors act the same between Windows apps and Linux apps.
Also, from https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-name-resolution-for-vms-and-role-instances
In the scenario of name resolution from App Service Web Apps in one virtual network to VMs in a different virtual network, it requires customer-managed DNS servers forwarding queries between virtual networks for resolution by Azure (DNS proxy). See Name resolution using your own DNS server.
By default, app service use the Azure providing DNS server in the delegated VNet, it don't know your on-premise DNS records. You need to deploy a custom DNS server in your Azure virtual network and target network to forward the DNS query.
For Application Insights, you could check if you have a rule blocking the outbound call to application insights if you have set the app setting WEBSITE_VNET_ROUTE_ALL to 1. Refer to this.
If you integrate your app with your VNet, the default behavior remains
as it was. You would only be able to reach RFC1918 addresses
(10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and service endpoints.
Just like with Windows, the feature now supports outbound calls into
the VNet on non-RFC1918 addresses as well. To reach all addresses you
need to set the app setting WEBSITE_VNET_ROUTE_ALL to 1, your app will
then enable all of the outbound traffic from your app to be subject to
NSGs and UDRs.
Finally, all of a sudden it got resolved by itself. And when we asked Microsoft Support, its mentioned that they have done recent network update in their backbone network.
Since we did not know what was the issue, we did not migrate Win to Linux in our higher env, we rollback to Windows and there was no issue after that.
This has been previously working but stopped recently. I have a Wordpress container running in an AKS pod that connects to Azure Database for MySQL Server Basic Pricing Tier. Recently the container is unable to connect. I have tried to whitelist all IPs in the MySQL Connection Security to rule that out 0.0.0.0 - 255.255.255.255 but that did not seem to help.
When exec into the pod and install a MySQL client and try to connect to the MySQL Server I see an error:
ERROR 9009 (28000): Client connections to Basic tier servers through Virtual Network Service Endpoints are not supported. Virtual Network Service Endpoints are supported for General Purpose and Memory Optimized severs.
I don't understand why this was working in the past and stopped now. Is this error message correct and is it basically telling you either upgrade (which I don't think you can just do in the portal to scale up like you would do for SQL Server), or you will not be able to access the DB. To upgrade would I have to backup the DB, create a new server in the General Purpose Pricing Tier and restore, so no smooth Scale Up path?
I don't seem to have the VNet option in Azure Portal
EDIT:
I have since found this post on microsoft forum and what that is saying is that you have to upgrade to GP pricing tier. So going from £19.805/month to £104.789/month. Just wow.
EDIT:
The way to get it work with MySQL Basic Tier was to disable Service Endpoints in AKS VNet as suggested in the accepted answer. The problem was that the SQL Server was configured to use Service Endpoints. To get that going after removing the service endpoints I had to disable service endpoints in the SQL Server. Not too happy with that but I guess you can't have both, your Basic Tier MySQL Server and decent security. If you want both, you will have to pay :(
It was never working, unless you were not using Service Endpoints. If you switch those off - it should resume working.
I have an Azure Web App and an Azure SQL Server, both in the same subscription. Both of them are connected to the same VNet Subnet as shown in the below snapshots. The SQL Server is configured not to Allow Azure Resources and Services to access the server, as it should only permit access from either the connected subnet or a set of IP rules.
Unfortunately, the SQL Server is actively refusing any connection from the web app stating that the web app IP is not allowed to access the server.
The interesting thing is that I have the exact same configuration working on another subscription.
What could I be missing?
Snapshots:
1- Here you can see the web application connected to the "webapps" subnet
2- And here you can see the SQL Server connected to the same subnet
3- And that's the error I get
TLDR
The configuration is correct, but an app service restart may be required.
VNET Integration
The configuration of using a virtual network to connect a web app to a SQL database is correct: if the web app is connected to the same subnet/vnet which is allowed in the database's ACLs, and the Microsoft.Sql service endpoint is enabled on the subnet, the web app is able to communicate to the database. This is the whole reason for service endpoints: you do not need to configure with IP allowances on the database.
As to why the configuration still resulted in an error, it could be the order in which the resources were configured. We were experiencing the exact same setup and issue (which is what let me to this question)!
We connected our web app to the subnet/vnet but had not enabled the service endpoint on the subnet. We then added/allowed the subnet/vnet as an ACL in the database, during which we were prompted to enable the Microsoft.Sql service endpoint (we did). However, even after waiting ~20 minutes, we were still seeing the same connection issue.
However, once we restarted the app service, the issue went away and the web app could connect to the SQL database.
I suspect the issue is due to enabling the subnet's service endpoint after the app service was connected to the subnet. The app service must need a restart to refresh the app service's vnet config/routing.
Configuration NOT needed
Contrary to other answers, you do not need to configure firewall IP allowances nor enable access to Azure services and resources. In fact, there are downsides to both approaches:
Enabling access to Azure services and resources allows any Azure-based resource to connect to your database, which includes resources not owned by you. From doc:
This option configures the firewall to allow all connections from Azure, including connections from the subscriptions of other customers.
Unless you're using an App Service Environment (which is significantly more expensive than normal App Service plans), your web app's outbound IP addresses are neither static nor specific to your application. From doc:
Azure App Service is a multi-tenant service, except for App Service Environments. Apps that are not in an App Service environment (not in the Isolated tier) share network infrastructure with other apps. As a result, the inbound and outbound IP addresses of an app can be different, and can even change in certain situations.
The second point is further elaborated upon in this Github issue:
IPs are indeed shared with other App Service plans (including other customer's plans) that are deployed into the same shared webspace. The network resources are shared among the plans in a workspace even if the computing instances are dedicated (e.g. in Standard tier). This is inherent to the App Service multi-tenant model. The only way to have a dedicated webspace (i.e. outbound IPs) is to deploy an App Service plan into an App Service Environment (ASE) (i.e. Isolated tier). ASE is the only thing that offers true single-tenency in App Service.
So neither of the above options will truly harden your SQL database if you want to isolate communication from only your web app. If you have resources in the same subnet, using vnet integration is the correct way to solve the problem.
If resources cannot be in the same subnet, the solution is to use Private Endpoints.
Virtual networking in Azure is quite different from how it would work on premises.
I had similar problems in production environment and digging deep, the working solution (meeting security standards and create a secure connection to the database) was to create a private endpoint for SQL access in the virtual network. Then all the calls to the SQL were performed internally (it did not go on the internet), and the databases were denying all public calls.
In your case now, you deactivated the Allow Azure apps to access so when your app is trying to access the SQL the server checks the ip to find out if it is white listed or not. So fast solutions would be one of the following:
Enable Azure Web apps to access SQL
Find all outbound IPs of your web app and register them in you SQL firewall/ security settings.
If you talk about a proper production environment with security regulations I would suggest you go down the more tedious path of private endpoints.
You have to configure the outbound IPs from the app service in the sql fw.
You can find them under properties of your app service. Documentation.
The reason why is that the VNET integration doesn't give your app service an outbound IP in the VNET you configured it in, so the FW you configured doesn't work.
I have working web apps which access storage accounts and KVs. These storage accounts and KVs accept traffic from a particular subnet and the web apps have been configured to integrate with those subnets. I did face an issue where even after integration apps were not able to access these resources. What worked for me was, I changed the App service SKU from Standard to Premium and restarted the app. As you can see, it warns that "Outgoing IPs of your app might change". This is not guaranteed solution but it worked for me.. several times! Not sure about SQL server though. Private endpoint does seem like the way to go but you can give this a try.
I'm taking my first foray into Azure Service Fabric using a cluster hosted in Azure. I've successfully deployed my cluster via ARM template, which includes the cluster manager resource, VMs for hosting Service Fabric, a Load Balancer, an IP Address and several storage accounts. I've successfully configured the certificate for the management interface and I've successfully written and deployed an application to my cluster. However, when I try to connect to my API via Postman (or even via browser, e.g. Chrome) the connection invariably times out and does not get a response. I've double checked all of my settings for the Load Balancer and traffic should be getting through since I've configured my load balancing rules using the same port for the front and back ends to use the same port for my API in Service Fabric. Can anyone provide me with some tips for how to troubleshoot this situation and find out where exactly the connection problem lies ?
To clarify, I've examined the documentation here, here and here
Have you tried logging in to one of your service fabric nodes via remote desktop and calling your API directly from the VM? I have found that if I can confirm it's working directly on a node, the issue likely lies within the LB or potentially an NSG.
What am I trying to do
I have to azure apps deployed as App services. To make rest post easy let's call them "blog" and "landing_page". Both of them are hosted, so they URL are blog.azurewebsites.net and landing_page.azurewebsites.net.
I want to configure "something" in Azure with following rules:
if user access http://mydomain/ - content of landing_page.azurewebsites.net
if user access http://mydomain/blog - content of blog.azurewebsites.net
What I tried
After reading documentation, I have to reject Traffic Manager because it works on DNS level. From the other two I decided to use Application Gateway, because it should work on eny Endpoint (Any Azure internal IP address, public internet IP address, Azure VM, or Azure Cloud Service).
I configured my Application Gateway setting backend to: landing_page.azurewebsites.net. But in "Backend health" the app status is unhealthy. I tried also:
blog.azurewebsites.net - unhealthy
www.wp.pl (polish news portal) - is working
gazeta.pl (polish news portal) - is working
stapp.space (my blog) - this is same as piotrstapp.azurewebsites.net and status is unhealthy
Question :)
What did I wrong? Maybe should I use something else on Azure? Or am I missing something?
Make sure that custom probes is turned on and configured in the HTTP settings of the WAF for your site. If you don't the Application Gateway will try to go to the IP of the App Service Environment without passing a Host header, which won't work and will throw the probe into an unhealthy state resulting in a "502 Gateway Proxy" error.
There is a great article here
You may want to check out Azure's application gateway path-based rules function:
Create a path-based rule for an application gateway by using the Azure portal