Azure Tips and Tricks

TIP

🔥 Make sure you star the repo (opens new window) to keep up to date with new tips and tricks.

📺 Watch the video : Build multi-service applications on Kubernetes with Azure Dev Spaces: Part 2 (opens new window).

💡 Learn more : Azure Kubernetes Service (opens new window).

# Important: Azure Dev Spaces is retired as of May 15, 2021. Customers should use Bridge to Kubernetes (opens new window).

# Part 2 - Develop multi-service applications on Kubernetes with Azure Dev Spaces

# Develop multi-service applications on Kubernetes with Azure Dev Spaces

This is part 2 of a 3-part series of articles about Azure Dev Spaces (opens new window). In part 1 - Get started with .NET Core on Kubernetes with Azure Dev Spaces, we set up a Kubernetes (opens new window) cluster in Azure and enabled Azure Dev Spaces for it, so that we could easily run and debug an application on it.

In this article, we are going use Kubernetes and Azure Dev Spaces to build a multi-service application, with multiple containers that can communicate with each other.

# Prerequisites

If you want to follow along, you'll need the following:

# Run an API in a separate container

In part 1, we ran the webfrontend application. Now, we are also going to run a new service, called mywebapi and have webfrontend call that service.

The mywebapi is part of the Azure Dev Spaces sample application. Let's set it up:

  1. If you do not have it on your local machine anymore, go to the Azure Dev Spaces sample application (opens new window) and clone or download it

  2. On your local machine, navigate to the samples/dotnetcore/getting-started/mywebapi directory

  3. Open the mywebapi folder with VS Code. This will open an ASP.NET Core Web API application

    (The mywebapi project in VS Code)

We will now run the application with Azure Dev Spaces:

  1. In VS Code, go to View > Command Palette and type or select the command Azure Dev Spaces: Prepare configuration files for Azure Dev Spaces. This will add debug capabilities to the project by using Azure Dev Spaces

  2. You'll be asked if you want to configure a publicly accessible endpoint for the service. Click No, as we only want the webfrontend application to talk to the service

    (Configure a public endpoint for the service)

  3. Press F5 to run the application

  4. The address that the service runs on will show up in the logs and in the bottom of VS Code, in the orange bar. Open a browser and navigate to the service and put /api/values at the end of the address (if it isn't yet)

The service runs on a localhost address, but it actually runs in a container in the dev space in Azure. It is a localhost address and not an Azure address, because the service is only accessible to services in the dev space in Azure. Azure Dev Spaces makes it look like the service runs locally, by temporarily creating an SSH tunnel to the container. This makes it easy for us to test the service. Cool, right?

(The API appears to run locally, but runs in Azure)

# Call the API from another container

The API is running, and we'll leave it as is for now, with the debugger attached in VS Code. Now, we will change the webfrontend project, so that it calls the mywebapi.

  1. Open the webfrontend project in VS Code (it is located in samples/dotnetcore/getting-started/webfrontend)
  2. In the HomeController.cs file, change the About action into the following:
public async Task<IActionResult> About()
{
    var client = _httpClientFactory.CreateClient();

    // Call *mywebapi*, and display its response in the page
    var request = new System.Net.Http.HttpRequestMessage();
    request.RequestUri = new Uri("http://mywebapi/api/values/1");
    if (this.Request.Headers.ContainsKey("azds-route-as"))
    {
        // Propagate the dev space routing header
        request.Headers.Add("azds-route-as", this.Request.Headers["azds-route-as"] as IEnumerable<string>);
    }
    var response = await client.SendAsync(request);
    ViewData["Message"] = await response.Content.ReadAsStringAsync();

    return View();
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

The code calls the api and uses the address http://mywebapi for that. This address is only known within the Kubernetes cluster and is not accessible outside it, because we haven't exposed the mywebapi as a publicly accessibly service. Click here (opens new window) for more information on using IHttpClientFactory.

The code also forwards the azds-route-as header from the incoming request to the outgoing request. We'll see how this helps teams with collaborative development in part 3 of this series.

Let's debug the service to see if it works:

  1. The mywebapi project is still running with a debugger attached. If it isn't, go to the VS Code of mywebapi and press F5
  2. In the VS Code of mywebapi, set a breakpoint inside the Get(int id) method
  3. In the VS Code of mywebfrontend, set a breakpoint in the About method in the HomeController, on the line var response = await client.SendAsync(request); and press F5
  4. Open the webfrontend app in a browser and click on the About menu-item
  5. The breakpoint in the webfrontend project should now be hit. Step over it (press F10)
  6. Now, the breakpoint in the mywebapi will be hit. Let the code continue (press F5)
  7. This returns us to the code of webfrontend, where the result variable will be populated. Let the code continue (press F5)
  8. Take a look at the webfrontend app in the browser. It should now display something like Hello from mywebapi

(The result of calling the API)

# Conclusion

Azure Dev Spaces (opens new window) makes it really easy to create multi-service applications that run in multiple containers in Kubernetes. As we've seen, it bridges the gap between the local machine and Azure by making it easy for us to call the api on localhost. And even though all the containers actually run in Azure, changing things and debugging is very fast and easy, which makes this a great developer experience. Go and check it out!

←
Tip 230 - Part 3 - Use Azure Dev Spaces to collaborate with a team on Kubernetes →