A Simple Network Connection Test Tool for Azure Spring Cloud
Applications running inside Azure Spring Cloud may need to make outbound calls to targets outside the Azure Spring Cloud. Sometimes the application may encounter network connection issue for different reasons. If we can run DNS resolve and TCP ping test from inside the Azure Spring Cloud to the outside target, it should be helpful for us to quickly narrow down network connection related issues. This blog shows how to build a very simple App for DNS resolve and TCP ping tests. After we deploy this App inside the existing Azure Spring Cloud service. We can run quick test to verify the availability of network connection to a specific target. Note: Azure Spring Apps published a newConnect Featurethat allows you access the shell environment inside your application instances to do advanced troubleshooting. For more details, please refer to:Investigate Azure Spring Apps Networking Issue with the new Connect feature Step 1: Create a simple Spring Web application with DNS resolve and TCP ping feature Step 2: Deploy it to your Azure Spring Cloud Step 3: Run DNS/Tcpping tests inside your Azure Spring Cloud instance Step 1: Create a simple Spring Web application with DNS resolve and TCP ping feature My test tool source code and compiled jar file can be found in: https://github.com/renhanli/AzureSpringCloud_connectiontest/tree/main/src/main/java/com/network/connectiontest https://github.com/renhanli/AzureSpringCloud_connectiontest/blob/main/target/connectiontest-0.0.1-SNAPSHOT.jar You can use the following steps to build your own test application: 1. Go to Spring initializr to create a Spring Web template. Select Generate when all the dependencies are set. 2. Download and unpack the package, then create a network test controller for a simple web application by adding the file \src\main\java\com\network\connectiontest\NetworkTestController.java with the following contents: package com.network.connectiontest; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RequestParam; import org.springframework.web.bind.annotation.RestController; import java.net.Socket; import java.io.PrintWriter; import java.io.StringWriter; import java.net.InetAddress; import java.net.InetSocketAddress; import java.util.List; import org.xbill.DNS.ResolverConfig; @RestController public class NetworkTestController { @GetMapping("/") public String index() { return "Run DNS resovle and Tcpping tests!"; } @GetMapping("/dns") public String dns(@RequestParam String hostname) { String result = "Resolve name for "+ hostname + ". </br>"; try { List<InetSocketAddress> dnsServers = ResolverConfig.getCurrentConfig().servers(); for (InetSocketAddress nameServer : dnsServers) { result += "Using system selected DNS server:"+ "</br>"; result += nameServer.getAddress() + "</br>"; } InetAddress addr = InetAddress.getByName(hostname); result += addr + "</br>"; } catch (Exception e) { result += "DNS resolve Failed! </br>"; StringWriter writer = new StringWriter(); PrintWriter printWriter = new PrintWriter( writer ); e.printStackTrace( printWriter ); printWriter.flush(); result += writer.toString().replaceAll("(\r\n|\n)", "<br />"); } return result; } @GetMapping("/tcpping") public String tcpping(@RequestParam String target, @RequestParam int port) { String result = "Tcpping "+ target + ":"+ port + ".</br>"; Socket socket = null; try { socket = new Socket(target, port); socket.setSoTimeout(2*1000); result += "Successfully Connected. </br>"; socket.close(); result += "Disconnected. </br>"; } catch(Exception e) { result += "Connection Failed! </br>"; StringWriter writer = new StringWriter(); PrintWriter printWriter = new PrintWriter( writer ); e.printStackTrace( printWriter ); printWriter.flush(); result += writer.toString().replaceAll("(\r\n|\n)", "<br />"); } return result; } } 3. Build the project using Maven mvn clean package 4.Run local test java -jar target\connectiontest-0.0.1-SNAPSHOT.jar After you bring up the application in your local machine, you should be able to access http://localhost:8080 We can run DNS resolve test by providing the hostname http://localhost:8080/dns?hostname=google.com We can run tcpping test by providing the target IP/domain and port number http://localhost:8080/tcpping?target=google.com&port=443 http://localhost:8080/tcpping?target=142.250.76.174&port=443 Step 2: Deploy it to your Azure Spring Cloud Assume you already have your Azure Spring Cloud service created. If you do not have any Azure Spring Cloud instance created, please create one according to https://docs.microsoft.com/en-us/azure/spring-cloud/quickstart?tabs=Azure-CLI&pivots=programming-language-java#provision-an-instance-of-azure-spring-cloud Use Azure CLI to create the network test App and deploy the .jar file to it. 1. Install the Azure CLI version 2.0.67 or higher and the Azure Spring Cloud extension with the command: az extension add --name spring-cloud 2. Login your account az login az account set --subscription <Name or ID of a subscription> 3. Create the test app with endpoint enabled az spring-cloud app create -n networktest -s <spring cloud instance name> -g <resource group name> --assign-endpoint true 4. Deploy the jar file to the app az spring-cloud app deploy -n networktest -s <spring cloud instance name> -g <resource group name> --artifact-path <jar file path>/connectiontest-0.0.1-SNAPSHOT.jar Step 3: Run DNS/Tcpping tests inside your Azure Spring Cloud instance Go to the networktest app we just created, use the URL provided in Overview Portal to run the test For succeed dns resolve test, we can see the following output. For failed dns resolve, we can see detailed error message and call stacks. For succeed tcpping, we can see the following output. For failed tcpping, we can see detailed error message and call stacks. To help you get started, we havemonthly FREE grantson all tiers – 50 vCPU Hours and 100 memory GB Hours per tier. These are the number of FREE hours per month BEFORE any usage is billed.Navigating Common VNET Injection Challenges with Azure Spring Apps
This article outlines the typical challenges that customers may come across while operating an Azure Spring Apps service instance using the Standard and Enterprise plans within a virtual network environment. Deploying Azure Spring Apps within a customized Virtual Network introduces a multitude of components into the system. This article will guide you to set network components such as Network Security Groups (NSG), route tables, and custom DNS servers correctly to make sure service is functioning as expected. In the following sections, we've compiled a list of common issues our customers encounter and offer recommendations for effectively resolving them. VNET Prerequisites not met Issues Custom Policy issues Custom DNS Server Resolution Issues Outbound connection issues Route Table Issues User Defined Route Issues VNET Prerequisites not met Issues Symptoms: Failed to create Azure Spring Apps service. Error Messages: "InvalidVNetPermission" error messages reporting ""Invalid Subnet xxx. This may be a customer error if 'Grant service permission to virtual network' step is missing before create Azure Spring Apps in vnets." Common Causes of the issue: Azure Spring Apps platform need to execute some management operations (e,g, create route tables, add rules into existing route tables) in the customer provided VNET. Without the above permissions, the platform operations will be blocked. How to fix: Grant the Owner permission on your virtual network to "Azure Spring Cloud Resource Provider" (id: e8de9221-a19c-4c81-b814-fd37c6caf9d2). Or you can grant User Access Administrator and Network Contributor roles to it if you can't grant Owner permission. az role assignment create \ --role "Owner" \ --scope ${VIRTUAL_NETWORK_RESOURCE_ID} \ --assignee e8de9221-a19c-4c81-b814-fd37c6caf9d2 If you associated your own route tables to the given subnets, also need to make sure to grant Owner or User Access Administrator & Network Contributor permission to "Azure Spring Cloud Resource Provider" on your route tables. az role assignment create \ --role "Owner" \ --scope ${APP_ROUTE_TABLE_RESOURCE_ID} \ --assignee e8de9221-a19c-4c81-b814-fd37c6caf9d2 Reference docs: Virtual network requirements Grant service permission to the virtual network Custom Policy issues Symptoms: Failed to create Azure Spring Apps service. Failed to start/stop Azure Spring Apps service. Failed to delete Azure Spring Apps service. Error Messages: Resource request failed due to RequestDisallowedByPolicy. Id: /providers/Microsoft.Management/managementGroups/<group-name>/providers/Microsoft.Authorization/policyAssignments/<policy-name> Common Causes of the issue: One of the most common policies we saw that blocks the platform operation is "Deny Public IP Address creation". The Azure Spring Apps platform need to create a public IP in the load balancer to communicate with those targets mentioned in Customer responsibilities running Azure Spring Apps in a virtual network for management and operational purposes. How to fix: Find the policy id provided in the error message, then check if the policy can be deleted or modified to avoid the issue. For Deny Public IP Address policy, if your company policy does not allow that, you can also choose to use Customize Azure Spring Apps egress with a user-defined route. Custom DNS Server Resolution Issues Symptom： Failed to create Azure Spring Apps service. Failed to start Azure Spring Apps service. App cannot register to Eureka server. App cannot resolve or resolve wrong IP address of a target URL. Error Messages: Could not resolve private dns zone. java.net.UnknownHostException If the DNS server resolved wrong IP address of a host, we may also see connection failure in the log. java.net.SocketTimeoutException Common Causes of the issue: Custom DNS server is not correctly configured to forward DNS requests to upstream public DNS server. In the Troubleshooting Azure Spring Apps in virtual network Doc, it mentioned if your virtual network is configured with custom DNS settings, be sure to add Azure DNS IP 168.63.129.16 as the upstream DNS server in the custom DNS server. But sometimes it got misunderstood as adding both custom DNS server IP and 168.63.129.16 into the VNET DNS servers setting. This will introduce unpredictable behavior in name resolving. Some companies' policy does not allow forwarding DNS requests to Azure DNS server. Customers have the flexibility to direct their DNS requests to any upstream DNS server of their choice, provided that the chosen server is capable of resolving the public targets outlined in the Customer responsibilities running Azure Spring Apps in a virtual network. In this scenario, you will also need to add an additional DNS A record for *.svc.private.azuremicroservices.io (Service Runtime cluster ingress domain) -> the IP of yourapplication (Find the IP for your application). While the Azure Spring Apps platform does configure this record, it is specifically recognizable by Azure DNS servers. If an alternative DNS server is in use, this record needs to be manually added into your own DNS server. Since our Spring boot Configure server and Eureka server are hosting in Service Runtime cluster, if your DNS server setting cannot resolve *.svc.private.azuremicroservices.io domain, your app may fail to load config and register itself to the Eureka server. Upon modifying your DNS configuration file or adjusting the VNET DNS server settings, it's important to note that these changes will not be instantly propagated across all the cluster nodes that host your application. To effectively implement the modifications, it is necessary to stop then start the Azure Spring Apps instance. This action enforces a reboot of the underlying cluster nodes. It's a by design behavior, since any cluster node virtual machine will only load the DNS settings from VNET for one time when it got created, restarted or being manually restart the network daemon. The network connection to the custom DNS server or Azure DNS server is blocked by NSG rule or firewall. How to investigate: Use Diagnose and Solve problems -> DNS Resolution detector Use App Connect console to test the DNS resolve result. We can connect to the App container, and directly run nslookup command to test the host's name resolve result. Please refer to Investigate Azure Spring Apps Networking Issue with the new Connect feature - Microsoft Community Hub. If the wrong DNS server setting blocked Azure Spring Apps service creation, since there is no resource being created yet, the above 2 troubleshooting method won't be available. You will need to create a jump-box (windows or Linux VM) in the same VNET subnet as your Azure Spring App, then use nslookup or dig command to verify the DNS settings. Make sure all the targets mentioned in Customer responsibilities running Azure Spring Apps in a virtual network can be resolved. nslookup mcr.microsoft.com Outbound connection issues Symptom: Failed to create Azure Spring Apps service. Failed to start Azure Spring Apps service. App Deployment failed to start. App Deployment cannot mount Azure File Share. App Deployment cannot send metrics/logs to Azure Monitor, Application Insights. Error Messages: "code": "InvalidVNetConfiguration", "message": "Invalid VNet configuration: Required traffic is not whitelisted, refer to https://docs.microsoft.com/en-us/azure/spring-cloud/vnet-customer-responsibilities Common Causes of the issue: If the traffic targeting *.azmk8s.io being blocked, the Azure Spring Apps service will lost connection to the underneath Kubernetes Cluster to send management requests. It will cause the service failed to create and start. If the traffic targeting mcr.microsoft.com, *.data.mcr.microsoft.com, packages.microsoft.com being blocked, the platform won't be able to pull images and packages to deploy the cluster node. It will cause the service failed to create and start. If the traffic targeting *.core.windows.net:443 and *.core.windows.net:445 being blocked, the platform won't be able to use SMB to mount the remote storage file share. It will cause the app deployment failed to start. If the traffic targeting login.microsoftonline.com being blocked, the platform authentication feature like MSI will be blocked. It will impact service start and app MSI usage. If the traffic targeting global.prod.microsoftmetrics.com and *.livediagnostics.monitor.azure.com being blocked, the platform won't to able to send data to Azure metrics, so you will lose App Metric data. How to investigate: Examine the logs of your NSG and firewall to verify whether any traffic directed towards the targets outlined in the Customer responsibilities running Azure Spring Apps in a virtual network is encountering blocks or restrictions. Review your route table settings to ensure that they are configured to effectively route traffic towards the public network (either directly or via firewall, gateway or other appliances) for the specific targets detailed in the Customer responsibilities running Azure Spring Apps in a virtual network. Use Diagnose and Solve problems -> Required Outbound Traffic Use App Connect console to test the outbound connection blocking issue. We can connect to the App container, and directly run "nc -zv <ip> <port>"command to test the outbound connection blocking issue. nc -zv <ip> <port> Please refer to Investigate Azure Spring Apps Networking Issue with the new Connect feature - Microsoft Community Hub If the outbound connection issue blocked Azure Spring Apps service creation, since there is no resource being created yet, the above 2 troubleshooting method won't be available. You will need to create a jump-box (windows or Linux VM) in the same VNET subnet as your Azure Spring App, then use "nc" or "tcpping" command to verify the connection. Make sure all the targets mentioned in Customer responsibilities running Azure Spring Apps in a virtual network are not blocked by your NSG or firewall rules. How to fix: Use the above method to check which outbound traffics being blocked. Fix the setting in route table, NSG and firewall in both service runtime and app subnets. Route Table Issues Symptom: Failed to create Azure Spring Apps service. Failed to start Azure Spring Apps service. Failed to delete Azure Spring Apps service. Error Messages: Invalid VNet configuration: Invalid RouteTable xxx. This may be a customer error if providing wrong route table information Invalid VNet configuration: Please make sure to grant Azure Spring Apps service permission to the scope /subscriptions/xxx/resourceGroups/xxx/providers/Microsoft.Network/routeTables/xxx. Refer to https://aka.ms/asc/vnet-permission-help for more details Common Causes of the issue: You did not grant Owner or User Access Administrator & Network Contributor permission to "Azure Spring Cloud Resource Provider" on your route tables. The platform needs to write new route table rules into the given route table. Without qualified permission, the operation will fail. You provided wrong route table information, so the platform cannot find it. How to fix: Unless you have distinct prerequisites necessitating the routing of outbound traffic through a designated gateway or firewall, there is no need to establish your own route tables within the subnets allocated to Azure Spring Apps. The platform itself will autonomously generate a new route table within the subnets and configure appropriate route rules for the underlying nodes. If you need routing outbound traffic to your own gateway or firewall: You have the option to employ your personal route table. Prior to initiating the creation of Azure Spring Apps, please make sure to associate your custom route tables with the two specified subnets. If your custom subnets contain route tables, Azure Spring Apps acknowledges the existing route tables during instance operations and adds/updates and/or rules accordingly for operations. You can also use the route tables created by the platform. Just add your new routing rules into it. We can see rules named like this: aks-nodepoolxx-xxxx-vmssxxxxx_xxxx. These are the rules added by Azure Spring Apps and they must not be updated or removed. You can add your own rules to routing other outbound traffic. For example, using 0.0.0.0/0 to route all the other traffic to your gateway or firewall. If you created your own routing rule to route internet outbound traffic, make sure the traffic can reach all the targets mentioned in Customer responsibilities running Azure Spring Apps in a virtual network. User Defined Route Issues Symptom Failed to create Azure Spring Apps service. Failed to start Azure Spring Apps service. Failed to use Public Endpoint feature. Failed to use log stream or connect to App console from public network. Error Messages: Invalid VNet configuration: Route tables need to be bound on subnets when you select outbound type as UserDefinedRouting.. Invalid VNet configuration: Both route table need default route(0.0.0.0/0). When connecting to Console from public network, it's reporting: A network error was encountered when connecting to "xxx.private.azuremicroservices.io". Please open the browser devtools or try with "az spring app connect" to check the detailed error message. Azure CLI log stream command may report: requests.exceptions.ConnectionError: HTTPSConnectionPool(host='xxx.private.azuremicroservices.io', port=443): Max retries exceeded with url: /api/logstream/apps/authserver/instances/xxxxx Common Causes of the issue: When you choose to use User Defined Route, the platform won’t create any public IP address on the load balancer anymore. So, it's customer's responsibility to make sure that both subnets can still make calls to all the public targets mentioned in Customer responsibilities running Azure Spring Apps in a virtual network. This is the reason why we require both route tables need default route (0.0.0.0/0) and route the traffic to your firewall. This firewall is responsible for managing Source Network Address Translation (SNAT) and Destination Network Address Translation (DNAT) processes, converting local IP addresses to corresponding public IP addresses. This configuration enables the platform to successfully establish outbound connections to targets located in the public network. By design, in UDR type of Azure Spring Apps, we cannot use the following features: - Enable Public Endpoint - Use public network to access the log stream - Use public network to access the console The same limitations also apply to the Azure Spring Apps usingBring Your Own Route Tablefeature when customer route egress traffics to a firewall. Because theyintroduce asymmetric routing into the cluster, this is where the problem occurs. Packets arrive on the firewall's public IP address but return to the firewall via the private IP address. So, the firewall must block such traffic. We can refer to this doc to get more details:Integrate Azure Firewall with Azure Standard Load Balancer How to fix: When creating Azure Spring Apps using UDR outbound type, please carefully read this Control egress traffic for an Azure Spring Apps instance doc. It is recommended to diligently adhere to each step outlined in this document while establishing your individual route tables and configuring the associated firewall settings. This approach ensures the proper and effective control of outbound traffic for your Azure Spring Apps instance. Hope the troubleshooting guide is helpful to you! To help you get started, we havemonthly FREE grantson all tiers – 50 vCPU Hours and 100 memory GB Hours per tier. Additional Resources Learn using anMS Learn moduleorself-paced workshopon GitHub Deployyour first Spring app to Azure! Deploythe demo Fitness Store Spring Boot app to Azure Deploythe demo Animal Rescue Spring Boot app to Azure Learnmoreabout implementing solutions on Azure Spring Apps Deploy Spring Boot apps by leveraging enterprise best practices –Azure Spring Apps Reference Architecture Migrate yourSpring Boot,Spring Cloud, andTomcatapplications to Azure Spring Apps Wire Spring applications tointeract with Azure services For feedback and questions, please raise your issues on our GitHub. To learn more about Spring Cloud Azure, we invite you to visit the following links: Reach out to us onStackOverfloworGitHub. Reference Documentation Conceptual Documentation Code Samples Spring Version MappingTroubleshooting guide for Application Configuration Service on Azure Spring Apps
Application Configuration Service overview Application Configuration Service for VMware Tanzu(ACS) is one of the commercial VMware Tanzu components. It enables the management of Kubernetes-native ConfigMap resources that are populated from properties defined in one or more Git repositories. Application Configuration Service is offered in two versions: Gen1 and Gen2. The Gen1 version mainly serves existing customers for backward compatibility purposes and is supported only until April 30, 2024. New service instances should use Gen2. The Gen2 version usesfluxas the backend to communicate with Git repositories and provides better performance compared to Gen1. You can check the generation information via Azure Portal The below article will introduce thetroubleshooting guide for both generations. Case 1: Application fails to start due to configuration not available 1. Make sure your Application Configuration Service setting is correct. There are several checkpoints in theApplication Configuration Service settings. The Git URI and label are correct. E.g. we have met several cases that use `master` branch but the default branch in GitHub has been changed to `main`. The credentials are correct. If you are using a private Git repo, it is recommended to use `SSH` auth for security considerations. `HTTP basic` auth also works but be cautioned that the token usually has an expiration date. Please remember to update the token before it expires. Please check Authentication section in our docs. To verify the above things, you may take a look atApplication Configuration Service's logs through Azure Log analysis. The log will hint reason if it is not able to access to your Git repository. // Both works for Application Configuration Service Gen1 and Gen2 AppPlatformSystemLogs | where LogType == "ApplicationConfigurationService" | project TimeGenerated , ServiceName , Log , _ResourceId | limit 100 If you are using Application Configuration Service Gen2, it is also worth a while to take a look at `Flux` logs. // Only available in Application Configuration Service Gen2 AppPlatformSystemLogs | where LogType == "Flux" | project TimeGenerated , ServiceName , Log , _ResourceId | limit 100 2. Make sure the app is bonded to ACS. To explicitly useApplication Configuration Service feature in an app, you have to bind the app through Azure Portal or Azure command line. It is unbound by default. # Azure Command line to bind app az spring application-configuration-service bind --app <app-name> 3.Make sure the deployment is configured with the corrected pattern. A pattern is a combination of{application}/{profile}. Toexplicitly tell Azure Spring Apps which pattern your deployment wants to use, you can do that through Azure Portal or Azure command line. // Bind config file pattern to your deployment az spring app deploy \ --name <app-name> \ --artifact-path <path-to-your-JAR-file> \ --config-file-pattern <config-file-pattern> 4. Restart the app You have to restart the application after the bind operation. Note that restart is not mandatory if you do an app deploy instead. Case 2: Configuration not refreshed in application The refresh strategiesprovides some code examples about the end to end workflow torefresh your Java Spring Boot application configuration after you update the configuration file in the Git repository. The refresh frequency is 60 seconds inAzure Spring Apps but please allow another 60 seconds to reflect the change to the configmap. If you still hit any issue, you can also follow the below troubleshooting guide. 1. Make sure theApplication Configuration Service setting still uses the correct credentials. Credentials may be expired and not been updated inApplication Configuration Service settings. You can verify it through the same step in Case 1 vialogs inAzure Log analysis. 2. Restart the app Another possible reason that the refresh doesn't work in your app is that the Spring context is not refreshed. It could be a code issue in the app. You may restart the app to check the result. Hope the troubleshooting guide is helpful to you! To help you get started, we havemonthly FREE grantson all tiers – 50 vCPU Hours and 100 memory GB Hours per tier. Additional Resources Learn using anMS Learn moduleorself-paced workshopon GitHub Deployyour first Spring app to Azure! Deploythe demo Fitness Store Spring Boot app to Azure Deploythe demo Animal Rescue Spring Boot app to Azure Learnmoreabout implementing solutions on Azure Spring Apps Deploy Spring Boot apps by leveraging enterprise best practices –Azure Spring Apps Reference Architecture Migrate yourSpring Boot,Spring Cloud, andTomcatapplications to Azure Spring Apps Wire Spring applications tointeract with Azure services For feedback and questions, please raise your issues on our GitHub. To learn more about Spring Cloud Azure, we invite you to visit the following links: Reach out to us onStackOverfloworGitHub. Reference Documentation Conceptual Documentation Code Samples Spring Version MappingMaximizing Value: Streamlined Cloud Solutions with Prime Cost Savings for Spring Apps – upto 47% off
Cost is not just a number — it is key to making big decisions, especially when moving to the cloud. Knowing how important this is, we offer solutions that make your cloud experience better and save you a lot of money, up to a huge 47% discount. This is not just about being affordable; it is about getting great value every step of the way.Build Right and Fast: Landing Zone Accelerator for Spring Apps - Now Generally Available!
Are you looking for deploying spring applications at enterprise scale with industry-proven practices? Leverage Azure Spring Apps landing zone accelerator, now generally available that helps you build a secure scalable compliant development, test or production environments within 15-30 minutes. Landing zone accelerator provides a packaged architecture guidance with design recommendations and considerations on key critical design areas, reference architecture and reference implementation.
Azure Spring Apps feature updates in Q1 2023
The following updates are now available in both basic/standard and enterprise plan: Source code assessment for migration: Assess your existing on-premise Spring applications for their readiness to migrate to Azure Spring Apps with Cloud Suitability Analyzer. The tool will provide you information on what types of changes will be needed for migration, and how much effort will be involved. Learn more. The following updates are now available in the enterprise plan More Options For build pools and allow queue build jobs: Build service now supports big size build agent pool and allows at most one pool-sized build task to build and twice the pool-sized build tasks to queue. Learn more. 99.95% SLA support: Higher SLA for mission-critical workloads. High vCPU and Memory app support: Support to deploy large CPU and memory applications to support CPU-intensive or memory-intensive workloads. Learn more. SCG APM & certificate verification support: Allow to configure APM and TLS certificate verification between Spring Cloud Gateway and applications. Learn more. Tanzu Components on demand: allow to enable or disable Tanzu components after service provisioning, you can learn how to do that per Tanzu component doc. Learn more. To help you get started, we havemonthly FREE grantson all tiers – 50 vCPU Hours and 100 memory GB Hours per tier. Additional Resources Learn using anMS Learn moduleorself-paced workshopon GitHub Deployyour first Spring app to Azure! Deploythe demo Fitness Store Spring Boot app to Azure Deploythe demo Animal Rescue Spring Boot app to Azure Learnmoreabout implementing solutions on Azure Spring Apps Deploy Spring Boot apps by leveraging enterprise best practices –Azure Spring Apps Reference Architecture Migrate yourSpring Boot,Spring Cloud,andTomcatapplications to Azure Spring Apps Wire Spring applications tointeract with Azure services For feedback and questions, pleasee-mailus.Unleash Spring apps in a flex environment with Azure Spring Apps Consumption and Dedicated plans
Today, we are thrilled to announce the public preview of the Standard Dedicated plan! The Standard Dedicated plan provides a fully managed, dedicated environment for running Spring applications on Azure. This plan offers you customizable compute options (including memory-optimized), single tenancy, and high availability to help you achieve price predictability, cost savings, and performance for running Spring applications at scale.Your ultimate guide to Azure app innovation at Microsoft Build 2023
This has been an incredible year for app innovation, with new solutions, new plans, and new capabilities from Azure to help you rapidly build, deploy, and secure apps at scale. It is a lot to keep up with, we know! This is why we’re excited to bring you this curated list of Azure app innovation sessions, labs, and demos at Microsoft Build 2023!
Configuring Custom DNS for Azure Spring App in a Private Network
Azure Spring App is a cloud-based platform for building and deploying enterprise-grade Java applications. By default, Azure Spring App uses Azure DNS for name resolution. However, in some cases, you may want to use custom DNS servers for name resolution. This article explains how to configure custom DNS for Azure Spring App in a private network. Suggestions for Using CustomDNS. Set up less than 3 custom DNS servers. This is becauseAzure Kubernetes Service (AKS) uses theCoreDNSproject for cluster DNS management and resolution. It only takes the first three custom DNS server settings. If you specify more than three custom DNS servers, AKS will only use the first three. Make sure that all custom DNS servers have some records that all of them could resolve your private URLs. With multiple DNS servers, the resolver library queries them in the order that's listed. (The strategy used is to try a name server first. If the query times out, try the next name server, and continue until the list of name servers is exhausted. Then, the query continues to try to connect to the name servers until the maximum number of retries are made.) If two custom DNS servers are specified, and the third DNS server is specified as Azure DNS (168.63.129.16), the node will send requests to the first custom DNS server if it's running and reachable. In this setup, the node can resolve the custom domain. However, some of the DNS requests from the pod might be directed to Azure DNS. This is because CoreDNS can select the upstream server at random. In this scenario, the custom domain can’t be resolved. Therefore, the DNS request fails. We recommend that you don't combine Azure DNS with custom DNS servers in the virtual network settings. If you want to use the custom DNS servers, add only the custom DNS servers in the virtual network settings. Then, configure Azure DNS in the forwarder settings of your custom DNS servers. Setting up DNS Forwarding on a Custom DNS Server As discussed earlier, we need to set up Azure DNS in the DNS forwarding on your custom DNS server, you can add the IP address(168.63.129.16) of the Azure DNS server to the DNS forwarder settings. This will allow your custom DNS server to forward DNS requests to the Azure DNS server for resolution. Keep in mind that the specific steps for configuring DNS forwarding on your Windows or Linux DNS server may vary depending on the distribution and version of Linux you're using. Windows Server Open the DNS Manager on the custom DNS server. Right-click on the server name and select "Properties". Click on the "Forwarders" tab. Click "Edit" and enter the IP address of the DNS server you want to forward requests to. Click "OK" to save your changes. Reference link:https://www.readandexecute.com/how-to/server-2016/dns/configure-dns-forwarders-windows-server-2016/. Linux Open the DNS configuration file on the custom DNS server. The location of the file may vary depending on your Linux distribution. Add the following line to the configuration file, replacing "IP_ADDRESS" with the IP address of the DNS server you want to forward requests to: forwarders { IP_ADDRESS; }; Save the configuration file. Restart the DNS service to apply the changes. Reference link:How To Configure Bind as a Caching or Forwarding DNS Server on Ubuntu 16.04 | DigitalOcean. How to Verify if your Custom DNS can Resolve Private URLs? I would suggest using the 'Console' feature of the Azure Spring Apps portal to connect to your app instance for troubleshooting, as described in this link: Connect to an app instance for troubleshooting. Once connected, you can run the 'nslookup' command to check the resolution result of your private URLs. How to Verify if DNS Forwarding to Azure DNS is Set Up Correctly? In Azure Spring Apps, you can use the DNS health check feature to verify if your app can resolve internal DNS names. You can access this feature through the 'Diagnose and solve problems' blade in the Azure portal. The DNS health check feature checks if your app can resolve the '*.svc.private.azuremicroservices.io' domain name. If you're seeing an error message that says 'cannot resolve private DNS zone', it may indicate that DNS forwarding is not properly configured. This error can occur when your custom DNS server is unable to forward DNS requests to the Azure DNS server for resolution.
