Invoking Dapr Services in Azure Container Apps using gRPC

When Dapr is enabled, we can utilize Dapr service invocation API that acts similar to a reverse proxy with built-in service discovery, while leveraging built-in distributed tracing, transient error handling, and retry of transient failures, this will be an added value compared to calling services directly using GrpcClient without Dapr. Looking at the diagram below, the two scenarios I’ll cover will be using Dapr Sidecar of each service to call each other over gRPC, the gRPC client API will be exposed “externally” over HTTP so I can test using a traditional REST client.

The source code for this tutorial is available on GitHub.

Scenario 2: Invoke gRPC services via Dapr Sidecar using GrpcClient (Dapr enabled)

In this scenario, we’ll see that we can enable Dapr on both applications and it will allow us to keep using our own proto services defined in the previous post (expense.proto) without any change to the gRPC service. This means that we can use service invocation to call our existing gRPC services without having to include any Dapr client SDKs or include custom gRPC services.

Update gRPC Client API

Step 1: Update ‘GrpcClient’ Address Configuration

In order for the gRPC client API to invoke the gRPC service, we need to update the typed gRPC client configuration and use the injected “DAPR_GRPC_PORT” environment variable Dapr is enabled on the client API, the value of this environment variable is the gRPC port that the Dapr sidecar is listening on. Our gRPC client API should use this variable to connect to the Dapr sidecar instead of hardcoding the port value, to do this change, open “Program.cs” and add the highlighted lines below:

builder.Services.AddGrpcClient<ExpenseSvc.ExpenseSvcClient>(o =>
{
    var islocalhost = builder.Configuration.GetValue("grpc:localhost", false);

    var serverAddress = "";

    if (islocalhost)
    {
        var port = "7029";
        var scheme = "https";
        var daprGRPCPort = Environment.GetEnvironmentVariable("DAPR_GRPC_PORT");

        if (!string.IsNullOrEmpty(daprGRPCPort))
        {
            scheme = "http";
            port = daprGRPCPort;
        }

        serverAddress = string.Format(builder.Configuration.GetValue<string>("grpc:server"), scheme, port);
    }
    else
    {
        serverAddress = builder.Configuration.GetValue<string>("grpc:server");
    }

    o.Address = new Uri(serverAddress);
});

Notice that when Dapr is enabled, the value of the Environment Variable “DAPR_GRPC_PORT” will not be empty and it will contain a port number, so we are going to use this port number and stop calling the gRPC server address directly, we are offloading the gRPC server service discovery to the gRPC Client Dapr Sidecar as I’ll show you in the next step.

Step 2: Inject Metadata headers upon invoking gRPC methods

Now I need to configure service discovery of the gRPC server by providing the Dapr Server App-Id when the gRPC client invokes a method on the server, to do this, we need to inject a “Metadata” header similar to the code below, so add the method below to your “Program.cs” file:

Metadata? BuildMetadataHeader()
{
    //The gRPC port that the Dapr sidecar is listening on
    var daprGRPCPort = Environment.GetEnvironmentVariable("DAPR_GRPC_PORT");

    Metadata? metadata = null;

    if (!string.IsNullOrEmpty(daprGRPCPort))
    {
        metadata = new Metadata();
        var serverDaprAppId = "expenses-grpc-server";
        metadata.Add("dapr-app-id", serverDaprAppId);
        app?.Logger.LogInformation("Calling gRPC server app id '{server}' using dapr sidecar on gRPC port: {daprGRPCPort}", serverDaprAppId, daprGRPCPort);
    }

    return metadata;
}

Notice how we are adding an entry to the “Metadata” dictionary with a key named “dapr-app-id” and a value of “expenses-grpc-server” which is the name of the gRPC service Dapr App Id, which we are going to set in the following steps.

Next, we need to call the method BuildMetadataHeader() upon calling each gRPC method, I will show below how to do it when calling the method “GetExpenseByIdAsync” and the other methods will follow the same pattern, check the highlighted line below:

app.MapGet("/api/expenses/{id}", async (ExpenseSvc.ExpenseSvcClient grpcClient, int id) =>
{
    GetExpenseByIdResponse? response;
    var request = new GetExpenseByIdRequest { Id = id };
    app?.Logger.LogInformation("Calling grpc server (GetExpenseByIdRequest) for id: {id}", id);
    
    response = await grpcClient.GetExpenseByIdAsync(request, BuildMetadataHeader());

    return Results.Ok(response.Expense);

}).WithName("GetExpenseById");

With this change on gRPC client, we are ready to test the gRPC service and client locally using Dapr CLI.

Enable Dapr and test the gRPC server and client locally

Now I’ll run the gRPC server while Dapr is enabled, to do so, navigate to the root folder of the project “Expenses.Grpc.Server” and run the command below. If you don’t have Dapr CLI installed locally on your machine you can check my previous post for more details:

dapr run --app-id expenses-grpc-server --app-protocol grpc --app-port 7029 --app-ssl -- dotnet run

When using dapr run  command we are running a dapr process as a sidecar next to the gRPC Server, the properties we have configured as the following:

• app-id: The unique identifier of the application. Used for service discovery, the value of this parameter is: “expenses-grpc-server” and it should match what we used in the “BuildMetadataHeader()” method.
• app-port: This parameter tells Dapr which port your application is listening on, you can get the app port from “launchSettings.json” file in the gRPC service project, I’m using the https port here.
• app-protocol: This is a gRPC service, setting this to “grpc”.
• app-ssl: Sets the URI scheme of the app to https and attempts an SSL connection.

Next, I will run the gRPC client API while Dapr is enabled, to do so, navigate to the root folder of the project “Expenses.Grpc.Api” and run the command below:

dapr run --app-id expenses-grpc-api --app-protocol http --app-port 5252 --dapr-http-port 3501 -- dotnet run

The properties we have configured for the gRPC client as the following:

• app-id: Using the value “expenses-grpc-api”.
• app-protocol: gRPC client API is a standard Web API, so the protocol is HTTP.
• dapr-http-port: The HTTP port for Dapr to listen on, setting it to 3501.

To test locally, using any Rest client, send HTTP GET request to the endpoint http://localhost:3501/v1.0/invoke/expenses-grpc-api/method/api/expenses/2 notice how I’m calling the Dapr Sidecar “Invoke” API of the gRPC client API with app-id “expenses-grpc-api” on port 3501, internally the gRPC client API will invoke the gRPC Server Sidecar over gRPC protocol and call the method “GetExpenseById” in the gRPC service.

Enable Dapr on the gRPC Server and Client then deploy updated to Azure Container Apps

Now we need to ship the changes done on the gRPC client API to Azure Container Apps and enable Dapr on the gRPC service and client too.

Step 1: Enable Dapr on the gRPC Server Azure Container App

We didn’t do any code changes on the server, so there is no need to build and push a new image, nor to deploy a new revision of the Azure Container App, all we need to do is to enable Dapr on the gRPC server Azure Container App, to do so, run the below CLI command:

az containerapp dapr enable `
--name $BACKEND_SVC_NAME  `
--resource-group $RESOURCE_GROUP `
--dal `
--dapr-app-id $BACKEND_SVC_NAME  `
--dapr-app-port 80 `
--dapr-app-protocol grpc `
--dapr-log-level info

Notice how I’m setting the property “dapr-app-protocol” to “grpc”, this will tell Dapr Sidecar that this service is using gRPC protocol.

Step 2: Update gRPC client API and create a new Azure Container App Revision

To reflect changes done on the gRPC client API, we need to create and push a new image to the container registry used, once this is done, we need to create a new revision using the command below:

az containerapp update `
--name $BACKEND_API_NAME  `
--resource-group $RESOURCE_GROUP `
--revision-suffix v20221102-1 `
--set-env-vars  "grpc__server={0}://localhost:{1}" "grpc__localhost=true"

Notice that I’m setting the environment variables with new values so that when the gRPC client API constructs the gRPC server address, it will use the assigned “Dapr Grpc Port” as described in the previous steps.

Step 3: Enable Dapr on the gRPC Client API Azure Container App

Similar to what I’ve done on the gRPC Server, we need to enable Dapr on the gRPC client API too, to do so, run the command below:

az containerapp dapr enable `
--name  $BACKEND_API_NAME  `
--resource-group $RESOURCE_GROUP `
--dal `
--dapr-app-id $BACKEND_API_NAME  `
--dapr-app-port 80 `
--dapr-app-protocol grpc `
--dapr-log-level info

We are setting the “dapr-app-protocol” to “grpc” for communication between the service and its Sidecar but remember from the previous post that Azure Container App hosting the gRPC Client API is using “transport” of type “http” that’s why we can invoke it using standard HTTP request as we will see in the next step.

With this in place, we can do our final testing via PostMan or any other REST client, take note of your gRPC client API Container App FQDN and invoke the POST operation to create a new expense, PostMan result should look like the below:

Note on distributed tracing of Dapr Services:

If you configured Application Insights when creating the Azure Container Apps Environment by setting the parameter “–dapr-instrumentation-key” to App Insights instrumentation key; you will be able to see the distributed tracing between the gRPC client API and the gRPC server on App Insights Application Map, this won’t be available if you are using the first approach (Scenario 1 in the previous post). The application map should be similar to the image below:

Scenario 3: Invoke gRPC services via Dapr Sidecar using DaprClient SDK (Dapr enabled)

Dapr offers a .NET SDK which enables us to invoke the gRPC services using a different approach other than the standard “GrpcClient” used in the previous 2 scenarios. If we are going to use this approach and utilize the methods available on Dapr .NET SDK such as method “InvokeMethodGrpcAsync” we need to build the gRPC service in a different way by implementing Dapr appcallback service, yet there is no change on proto files.

Create a new gRPC service inheriting from ‘AppCallback.AppCallbackBase’

Step 1: Create a new gRPC service

The first thing to do is to install the NuGet package “Dapr.AspNetCore” on project “Expenses.Grpc.Server”, then add a new file named “ExpenseServiceAppCallBack.cs” under the folder “Services”, this new service will do the exact behavior done by the previous ExpensesService, I will paste the content of the file here and go over the important parts of it:

using Dapr.AppCallback.Autogen.Grpc.v1;
using Dapr.Client.Autogen.Grpc.v1;
using Google.Protobuf.WellKnownTypes;
using Grpc.Core;

namespace Expenses.Grpc.Server.Services
{
    public class ExpenseServiceAppCallBack : AppCallback.AppCallbackBase
    {

        private readonly ILogger<ExpenseServiceAppCallBack> _logger;
        private readonly IExpensesRepo _expensesRepo;
        
        public ExpenseServiceAppCallBack(IExpensesRepo expensesRepo, ILogger<ExpenseServiceAppCallBack> logger)
        {
            _expensesRepo = expensesRepo;
            _logger = logger;
        }

        public override Task<InvokeResponse> OnInvoke(InvokeRequest request, ServerCallContext context)
        {
            var response = new InvokeResponse();

            switch (request.Method)
            {
                case "GetExpenses":

                    var getExpensesRequestInput = request.Data.Unpack<GetExpensesRequest>();
                    var getExpensesResponseOutput = new GetExpensesResponse();

                    _logger.LogInformation("Getting expenses for owner: {owner}", getExpensesRequestInput.Owner);

                    var filteredResults = _expensesRepo.GetExpensesByOwner(getExpensesRequestInput.Owner);
                    getExpensesResponseOutput.Expenses.AddRange(filteredResults);

                    response.Data = Any.Pack(getExpensesResponseOutput);
                    break;

                case "GetExpenseById":
                   
                    var getExpenseByIdRequestInput = request.Data.Unpack<GetExpenseByIdRequest>();
                    var getExpenseByIdResponseOutput = new GetExpenseByIdResponse();

                    _logger.LogInformation("Getting expense by id: {id}", getExpenseByIdRequestInput.Id);

                    var expense = _expensesRepo.GetExpenseById(getExpenseByIdRequestInput.Id);
                    getExpenseByIdResponseOutput.Expense = expense;

                    response.Data = Any.Pack(getExpenseByIdResponseOutput);
                    break;

                case "AddExpense":

                    var addExpenseRequestInput = request.Data.Unpack<AddExpenseRequest>();
                    var addExpenseResponseOutput = new AddExpenseResponse();

                    _logger.LogInformation("Adding expense for provider {provider} for owner: {owner}", addExpenseRequestInput.Provider, addExpenseRequestInput.Owner);

                    var expenseModel = new ExpenseModel()
                    {
                        Owner = addExpenseRequestInput.Owner,
                        Amount = addExpenseRequestInput.Amount,
                        Category = addExpenseRequestInput.Category,
                        Provider = addExpenseRequestInput.Provider,
                        Workflowstatus = addExpenseRequestInput.Workflowstatus,
                        Description = addExpenseRequestInput.Description
                    };

                    _expensesRepo.AddExpense(expenseModel);
                    addExpenseResponseOutput.Expense = expenseModel;

                    response.Data = Any.Pack(addExpenseResponseOutput);
                    break;
               
                default:
                    break;
            }

            return Task.FromResult(response);
        }
    }
}

What I’ve done here is the following:

• The service inherits from the abstract class “AppCallback.AppCallbackBase”, this is needed as it will be called by the Dapr runtime to invoke gRPC method.
• I’m overriding the method “OnInvoke” which is called when service invocation is happening, this method accepts an input parameter of type “InvokeRequest” which contains the following properties:
  • A string property named “Method” holds the name of the method which is invoked by the caller. In our case, we are supporting three methods “GetExpenses”, “GetExpenseById”, and “AddExpense”. Those method names should be identical to the names defined in the “expense.proto” file definition.
  • A “Data” property of type “Google.Protobuf.WellKnownTypes.Any”, this property holds a serialized protocol buffer message. I’m calling “Unpack” and specifying the expected input type request to serialize the data into a strongly typed object.
• Using the injected “IExpenseRepo” I’m calling the right operation to manipulate the In-memory Expenses list.
• Lastly, I’m generating a response output based on the invoked method and returning the response after “packing” the specified message into an “Any” message and assigning it to the “Data” property of an “InvokeResponse” object.

Step 2: Add “ExpenseServiceAppCallBack” gRPC service to the routes pipeline

Now we need to add the “ExpenseServiceAppCallBack” gRPC service to the routing pipeline so clients can invoke the operation “InvokeMethodGrpcAsync”, to do so, open the file “Program.cs” and paste the code below:

app.MapGrpcService<ExpenseServiceAppCallBack>();

Update gRPC Client API to use DaprClient SDK

Step 1: Install DaprClient SDK into gRPC Client API

Now we need to install the NuGet package “Dapr.AspNetCore” on project “Expenses.Grpc.Api”, after it gets installed, we need to register the DaprClient into service collection, so open Program.cs file and add builder.Services.AddDaprClient();

Step 2: Use DaprClient for methods invocations

Next, I’m injecting the “DaprClient” into each defined route endpoint, and I’m calling the method “InvokeMethodGrpcAsync”, so for example the updated code of the endpoint “/api/expenses/{id}” will look like the below:

app.MapGet("/api/expenses/{id}", async (ExpenseSvc.ExpenseSvcClient grpcClient, Dapr.Client.DaprClient daprClient, int id) =>
{
    GetExpenseByIdResponse? response;

    var request = new GetExpenseByIdRequest { Id = id };

    if (builder.Configuration.GetValue("grpc:daprClientSDK", false))
    {
        app?.Logger.LogInformation("DaprClientSDK::Calling grpc server (GetExpenseByIdRequest) for id: {id}", id);
        response = await daprClient.InvokeMethodGrpcAsync<GetExpenseByIdRequest, GetExpenseByIdResponse>("expenses-grpc-server", "GetExpenseById", request);
    }
    else
    {
        app?.Logger.LogInformation("Calling grpc server (GetExpenseByIdRequest) for id: {id}", id);
        response = await grpcClient.GetExpenseByIdAsync(request, BuildMetadataHeader());
    }

    return Results.Ok(response.Expense);

}).WithName("GetExpenseById");

Notice in the highlighted line above how I’m specifying the gRPC server Dapr “App-Id”, and invoking the method named “GetExpenseById” hosted in this server.
Note: We can completely remove the reference to the “GrpcClient” if we are going to use the “DaprClient” but I kept the code as is and introduced an Environment Variable named “grpc:daprClientSDK” and set it to “true” when using “DaprClient”. With this approach; the code on gRPC client API will remain working whether you decided to use “GrpcClient” or “DaprClient”.

Step 3: Test the gRPC client using DaprClient SDK locally

Now I’ll run both the gRPC server and gRPC Client API while Dapr is enabled locally to do so, run both commands below, and don’t forget to change the directory to the root folder of each project:

Run gRPC Server:

dapr run --app-id expenses-grpc-server --app-protocol grpc --app-port 7029 --app-ssl -- dotnet run

Run gRPC Client API:

dapr run --app-id expenses-grpc-api --app-protocol http --app-port 5252 --dapr-http-port 3501 -- dotnet run

To test locally, using any Rest client, send HTTP GET request to the endpoint http://localhost:3501/v1.0/invoke/expenses-grpc-api/method/api/expenses/2 notice how logs generated from the gRPC server are using the new “ExpenseServiceAppCallBack” gRPC service, logs should look similar to the below image:

Deploy changes to Azure Container Apps

Lastly, we need to push changes done on the gRPC server and gRPC Client API to Azure Container Apps and create 2 new revisions, to do so, create 2 new images for both applications and push them to your container registry, then update Azure Container Apps by running the two CLI commands:

Update gRPC Server Azure Container App

az containerapp update `
--name $BACKEND_SVC_NAME  `
--resource-group $RESOURCE_GROUP `
--revision-suffix v20221103-1

Update gRPC Client Api Azure Container App, notice how I’m setting the environment variable “grpc:daprClientSDK” to “true” to instruct the client API to use DaprClient SDK, not the GrpcClient.

az containerapp update `
--name $BACKEND_API_NAME  `
--resource-group $RESOURCE_GROUP `
--revision-suffix v20221103-1 `
--set-env-vars "grpc__daprClientSDK=true"

With this in place, you can do your final testing using any Rest Client, if you open Application Insights and checked the Request details, you will notice that there are extra properties injected when using DaprClient SDK for service-to-service invocation over gRPC, check the image below

The source code for this tutorial is available on GitHub.

Conclusion

In these two posts, I’ve covered the various scenarios in which we can invoke service using synchronous communication using GrpcClient or DaprSlient SDK and host the services on Azure Container Apps.

Follow me on Twitter @tjoudeh

References:

• How-To: Configure Dapr to use gRPC
• Service invocation overview
• Featured Image Credit

The post Invoking Dapr Services in Azure Container Apps using gRPC – Part 2 appeared first on Bit of Technology.

In this post, I will cover how 2 services deployed to Azure Container Apps communicate synchronously over gRPC without using Dapr and then we will Daperize the 2 services and utilize the service-to-service invocation features coming with Dapr.

The scenarios I’ll cover are the following:

• Scenario 1: Invoke gRPC services deployed to Container Apps using GrpcClient.
• Scenario 2: Invoke gRPC services deployed to Container Apps via Dapr Sidecar using GrpcClient (Part 2)
• Scenario 3: Invoke gRPC services deployed to Container Apps via Dapr Sidecar using DaprClient SDK (Part 2)

gRPC Communication In Azure Container Apps

Basically what I’m going to build today is a simple gRPC enabled service/server that exposes 3 endpoints to manage personal expenses, this gRPC service will be deployed into Azure Container Apps and will be invoked/called from a simple minimal .Net Web API which will act as gRPC client and will be deployed to Azure Container Apps too.

The source code for this tutorial is available on GitHub.

The scenarios depend on each other, so if you are interested in scenario 3 for example please consider looking into the scenarios in order.

Scenario 1: Invoke gRPC services using GrpcClient (Dapr disabled)

In this scenario, I will create the gRPC service and the gRPC client which invokes the service, use PostMan interactive UI to call the gRPC services, and then deploy both gRPC service and client to Azure Container Apps. The scenario should reflect the architecture diagram below:

Create the gRPC Service

Step 1: Create the gRPC Service project

Using VS Code or Visual Studio 2022, I will create a new project named “Expenses.Grpc.Server” of the type “ASP.NET Core gRPC Service”. If you are using VS Code you can create the project by running dotnet new grpc -o Expenses.Grpc.Server This will create a new gRPC enabled project with a default “greet.proto” file which we are going to update in the next step.

Step 2: Create a new Proto file

Now, I will add a new Proto file named “expense.proto” under the folder “Protos” which will contain all RPC methods needed to generate the gRPC server stubs, request inputs, and response outputs for the methods, add the file and paste the content below:

syntax = "proto3";

option csharp_namespace = "Expenses.Grpc.Server";

message ExpenseModel{
    int32 id =1;
    string provider =2;
    double amount =3; 
    string category = 4;
    string owner = 5;
    int32 workflowstatus = 6;
    optional string description = 7;
}

message GetExpensesRequest {
    string owner = 1;
}

message GetExpensesResponse {
    repeated ExpenseModel expenses = 1;
}

message GetExpenseByIdRequest {
    int32 id = 1;
}

message GetExpenseByIdResponse {
    ExpenseModel expense = 1;
}

message AddExpenseRequest {
    string provider =1;
    double amount =2; 
    string category = 3;
    string owner = 4;
    int32 workflowstatus = 5;
    optional string description = 6;
}

message AddExpenseResponse {
    ExpenseModel expense = 1;
}

service ExpenseSvc {
    rpc GetExpenses(GetExpensesRequest) returns (GetExpensesResponse) {}
    rpc GetExpenseById(GetExpenseByIdRequest) returns (GetExpenseByIdResponse) {}
    rpc AddExpense(AddExpenseRequest) returns (AddExpenseResponse) {}
}

What I’ve done here is straightforward, this Proto file exposes 3 RPC methods as the following

• GetExpenses: Returns list of “ExpenseModel” based on the expense owner input string.
• GetExpenseById: Returns a single “ExpenseModel” based on the provided expense id.
• AddExpense: Add a new expense to the repository based on the provided “ExpenseRequest”, and returns the saved “ExpenseModel” to the caller.

Step 3: Generate gRPC service stubs based on the Proto file

In order to generate the server stubs, I need to invoke the protocol buffer compiler to generate the code for the target language (.NET in my case) .NET uses the Grpc.Tools NuGet package with MSBuild to provide automatic code generation of server stubs, so when we build the project or call “dotnet build”, the compiler will automatically generate server stubs based on the Proto file definition.

To enable this, we need to add this new Proto file to the gRPC service project, so open the project file “Expenses.Grpc.Server.csproj” and paste the below code:

<ItemGroup>
    <Protobuf Include="Protos\expense.proto" GrpcServices="Server" />
</ItemGroup>

You can remove any default Proto files coming with the default template. Notice how I set the “GrpcServices” property to the value of a “Server” as we are generating server stubs now.

Once added, build the project, and it should generate the code of server stubs for you.

Step 4: Create a repository to store data In-Memory

To keep things simple, I will use a static list to store expenses and manipulate them, we will use the same repository in the next post in scenario 3 once we create the gRPC service implementation in a different way. To create the repository add a new interface named “IExpensesRepo.cs” under a new folder named “Services” and paste the code below:

namespace Expenses.Grpc.Server.Services
{
    public interface IExpensesRepo
    {
        List<ExpenseModel> GetExpensesByOwner(string owner);
        ExpenseModel? GetExpenseById(int id);
        ExpenseModel AddExpense(ExpenseModel expense);
    }
}

Then add a new file named “ExpensesRepo.cs” which implements the interface “IExpensesRepo.cs” and paste the code below:

namespace Expenses.Grpc.Server.Services
{
    public class ExpensesRepo : IExpensesRepo
    {
        private static List<ExpenseModel> _expensesList = new List<ExpenseModel>();

        private void GenerateRandomExpenses()
        {
            if (_expensesList.Count > 0)
            {
                return;
            }

            _expensesList.Add(new ExpenseModel
            {
                Id = 1,
                Provider = "Golds Gym",
                Amount = 290,
                Category = "Fitness Activity",
                Owner = "tjoudeh@mail.com",
                Workflowstatus = 1,
                Description = ""
            });

            _expensesList.Add(new ExpenseModel
            {
                Id = 2,
                Provider = "Adidas",
                Amount = 100,
                Category = "Athletic Shoes",
                Owner = "tjoudeh@mail.com",
                Workflowstatus = 1,
                Description = ""
            });

            _expensesList.Add(new ExpenseModel
            {
                Id = 3,
                Provider = "FreeMind",
                Amount = 25,
                Category = "Yoga Class",
                Owner = "xyz@yahoo.com",
                Workflowstatus = 2,
                Description = ""
            });
        }

        public ExpensesRepo()
        {
            GenerateRandomExpenses();
        }

        public ExpenseModel AddExpense(ExpenseModel expense)
        {
            expense.Id = _expensesList.Max(e => e.Id) + 1;
            _expensesList.Add(expense);
            return expense;
        }

        public ExpenseModel? GetExpenseById(int id)
        {
            return _expensesList.SingleOrDefault(e => e.Id == id);
        }

        public List<ExpenseModel> GetExpensesByOwner(string owner)
        {
            var expensesList = _expensesList.Where(t => t.Owner.Equals(owner, StringComparison.OrdinalIgnoreCase)).OrderByDescending(o => o.Id).ToList();

            return expensesList;
        }
    }
}

What I’ve done here is simple, it is a service that exposes three methods responsible to list expenses by expense owner, getting a single expense by Id, and adding a new expense and storing it in the static list.

Step 5: Implement the Service based on generated gRPC service stubs

Now I will add the actual implementation of the Expenses Service by inheriting it from the auto-generated stubs. To do so add a new file named “ExpenseService.cs” under the folder named “Services” and paste the code below:

using Grpc.Core;

namespace Expenses.Grpc.Server.Services
{
    public class ExpenseService : ExpenseSvc.ExpenseSvcBase
    {

        private readonly ILogger<ExpenseService> _logger;
        private readonly IExpensesRepo _expensesRepo;

        public ExpenseService(IExpensesRepo expensesRepo, ILogger<ExpenseService> logger)
        {
            _logger = logger;
            _expensesRepo = expensesRepo;
            _logger.LogInformation("Invoking Constructor");

        }

        public override Task<GetExpensesResponse> GetExpenses(GetExpensesRequest request, ServerCallContext context)
        {

            _logger.LogInformation("Getting expenses for owner: {owner}", request.Owner);

            var response = new GetExpensesResponse();

            var filteredResults =  _expensesRepo.GetExpensesByOwner(request.Owner);

            response.Expenses.AddRange(filteredResults);

            return Task.FromResult(response);
        }

        public override Task<AddExpenseResponse> AddExpense(AddExpenseRequest request, ServerCallContext context)
        {

            _logger.LogInformation("Adding expense for provider {provider} for owner: {owner}", request.Provider, request.Owner);

            var response = new AddExpenseResponse();

            var expenseModel = new ExpenseModel()
            {
                Owner = request.Owner,
                Amount = request.Amount,
                Category = request.Category,
                Provider = request.Provider,
                Workflowstatus = request.Workflowstatus,
                Description = request.Description
            };

            _expensesRepo.AddExpense(expenseModel);

            response.Expense = expenseModel;

            return Task.FromResult(response);
        }

        public override Task<GetExpenseByIdResponse> GetExpenseById(GetExpenseByIdRequest request, ServerCallContext context)
        {
            _logger.LogInformation("Getting expense by id: {id}", request.Id);

            var response = new GetExpenseByIdResponse();

            var expense = _expensesRepo.GetExpenseById(request.Id);

            response.Expense = expense;

            return Task.FromResult(response);

        }

    }

}

What I’ve done here is the following:

• The service “ExpenseService” is inherited from the abstract class “ExpenseSvc.ExpenseSvcBase”, this abstract class is auto-generated by the protocol buffer compiler based on the “expense.proto” file definition. The class exists in the following location on my machine “~\Expenses.Grpc.Server\obj\Debug\net6.0\Protos\ExpenseGrpc.cs”
• I’m overriding the three methods that are generated by the protocol buffer compiler and exist in the class “ExpenseSvc.ExpenseSvcBase” Those are methods defined in the “expense.proto” file. Each method accepts a “Request” input parameter that defines what the request accepts, and a “ServerCallContext” parameter that contains authentication context, headers, etc… Each method returns a “Response” based on the “expense.proto” definition. All those Request inputs and Response outputs classes are auto-generated by the gRPC tooling for .NET.
• For example, if we take a look at the method “GetExpenses”, we’ll notice that it accepts an input request of type “GetExpensesRequest” which encapsulates the “Owner” string property which I will be passing to the method “GetExpensesByOwner” from the repository “ExpensesRepo” to return a list of expenses associated with this owner. The response type of this method is a list of expenses that we are adding to the “Expenses” property part of the “GetExpensesResponse”.

Step 6: Add “Expenses” gRPC service to the routes pipeline and Register “IExpensesRepo” repository

Now we need to add the “ExpensesService” gRPC service to the routing pipeline so clients can access the three methods, and we need the repository “IExpensesRepo” as a singleton service so it is injected into the “ExpensesService” service constructor, to do so, open the file “Program.cs” and paste the code below:

using Expenses.Grpc.Server.Services;

var builder = WebApplication.CreateBuilder(args);

// Additional configuration is required to successfully run gRPC on macOS.
// For instructions on how to configure Kestrel and gRPC clients on macOS, visit https://go.microsoft.com/fwlink/?linkid=2099682

// Add services to the container.

builder.Services.AddSingleton<IExpensesRepo, ExpensesRepo>();

builder.Services.AddGrpc();

var app = builder.Build();

// Configure the HTTP request pipeline.
app.MapGrpcService<ExpenseService>();

app.MapGet("/", () => "Communication with gRPC endpoints must be made through a gRPC client. To learn how to create a client, visit: https://go.microsoft.com/fwlink/?linkid=2086909");
app.Run();

Step 7: (Optional) Enable gRPC service reflection

In order to call a gRPC service, any gRPC-enabled client tooling should have access to the Protobuf contract of the service (.proto) file before being able to invoke the gRPC service, to simplify this, we can enable gRPC reflection on the server, so tools such as PostMan (I’m going to use it for testing next step) will use reflection to automatically discover service contracts. Once gRPC reflection is enabled on the gRPC server; it adds a new gRPC service to the app that clients can call to discover services.

To do so, add a reference for the NuGet package “Grpc.AspNetCore.Server.Reflection” and then open the file “Program.cs” and add the highlighted lines below:

var builder = WebApplication.CreateBuilder(args);

// code omitted for brevity

builder.Services.AddGrpcReflection();

var app = builder.Build();

// code omitted for brevity

app.MapGrpcReflectionService();
app.MapGet("/", () => "Communication with gRPC endpoints must be made through a gRPC client. To learn how to create a client, visit: https://go.microsoft.com/fwlink/?linkid=2086909");
app.Run();

What I’ve done here is the following:

• “AddGrpcReflection” to register services that enable reflection.
• “MapGrpcReflectionService” to add a reflection service endpoint.

With those changes in place, client apps that support gRPC reflection can call the reflection service to discover services hosted by the server. It is worth noting that when reflection is enabled, it only enables service discovery and doesn’t bypass server-side security.

Step 8: Test gRPC service using PostMan

To start testing the gRPC service locally, run the project “Expenses.Grpc.Server” using dotnet run or from Visual Studio using Kestrel. Take note of the https port as shown I’m the image below:

Open PostMan and follow the steps below:

1. Select the “New” button and choose “gRPC Request”.
2. Enter the gRPC server’s hostname and port in the server URL. In my case, it is “localhost:7029”. Don’t include the http or https scheme in the URL. I’m using the port with https, so I select the padlock next to the server URL to enable TLS in Postman.
3. Navigate to the “Service definition” section, then select server reflection or import the “expense.proto” file. In my case, our gRPC service has reflection enabled so I will use the “server reflection” approach. When complete, the dropdown list next to the server URL textbox has a list of gRPC methods available.
4. Navigate to the “Settings” section, and turn off “Enable server certificate verification”, this is only needed when running gRPC server locally.
5. To call a gRPC method, in my case I will test the method “AddExpense” so select from the dropdown, copy the message content from below and paste it in the message body textbox, then select “Invoke” to send the gRPC call to the server.

{
    "provider": "Golds Gym 6",
    "amount": 350,
    "category": "Fitness Activity",
    "owner": "tjoudeh@mail.com",
    "workflowstatus": 2,
    "description": "Gym Subscription"
}

If all is configured successfully, you should receive back the created expense with an “Id” property assigned to it, it should look like the below image:

Create the gRPC Client App

Step 1: Create the gRPC Client project

Now I will add a new Minimal Web Api which will act as a gRPC client for the gRPC service and will define three REST API endpoints to access the gRPC methods, using VS Code or Visual Studio 2022, create a new project named “Expenses.Grpc.API” of the type “ASP.NET Core Web Api”, do not forget to uncheck “Use Controllers” and “Configure for HTTPS”. If you are using VS Code you can create the project by running dotnet new webapi -minimal -o Expense.Grpc.Api --no-https This will create a new minimal Web API.

Step 2: Add needed NuGet packages and Proto file reference

I will install the 2 NuGet packages needed for the gRPC client to invoke the gRPC service, to do so, Install package “Grpc.AspNetCore” and package “Grpc.Net.ClientFactory“. The package “Grpc.Net.ClientFactory” is optional to use, but I recommend using it as it will provide a central location for configuring gRPC client instances and it will manage the lifetime of the underlying “HttpClientMessageHandler”

Next, I’ll add a link reference to the “expense.proto” protobuf file so the gRPC client application will be able to automatically generate gRPC client code to invoke the gRPC service, thanks for the built-in .NET integration between MSBuild and the Grpc.Tools NuGet package

Open the file “Expenses.Grpc.Api.csproj” and add the code below:

<ItemGroup>
	<Protobuf Include="..\Expenses.Grpc.Server\Protos\expense.proto" GrpcServices="Client">
		<Link>Protos\expense.proto</Link>
	</Protobuf>
</ItemGroup>

Notice that I set the “GrpcServices” property value to “Client”, this will tell the gRPC client when building it to generate concrete client types based on the “expense.proto” file definition. The generated gRPC client code will contain “client” methods that translate to the gRPC service I’ve built in the previous steps.

Step 3: Add environment variables

To simplify the testing of gRPC client locally and when deploying it to Azure Container Apps, I added the below environment variables which we are going to update when deploying to Azure Container Apps, so open file “appsettings.json” and add the configuration below:

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning"
    }
  },
  "AllowedHosts": "*",
  "grpc": {
    "server": "{0}://localhost:{1}",
    "localhost": true,
    "daprClientSDK": false
  }
}

Step 4: Define API endpoints and invoke gRPC

Because I’m using minimal API, all services configuration and API endpoints will be on the same file “Program.cs”, so I will list the entire code of the file and explain what I’ve done thoroughly, open the file “Program.cs” and paste the code below:

using Expenses.Grpc.Server;
using Grpc.Core;

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.

builder.Services.AddGrpcClient<ExpenseSvc.ExpenseSvcClient>(o =>
{
    var islocalhost = builder.Configuration.GetValue("grpc:localhost", false);

    var serverAddress = "";

    if (islocalhost)
    {
        var port = "7029";
        var scheme = "https";

        serverAddress = string.Format(builder.Configuration.GetValue<string>("grpc:server"), scheme, port);
    }
    else
    {
        serverAddress = builder.Configuration.GetValue<string>("grpc:server");
    }

    o.Address = new Uri(serverAddress);
});

var app = builder.Build();

// Configure the HTTP request pipeline.

app.MapGet("/api/expenses", async (ExpenseSvc.ExpenseSvcClient grpcClient, string owner) =>
{
    GetExpensesResponse? response;
    
    var request = new GetExpensesRequest { Owner = owner };

    app?.Logger.LogInformation("Calling grpc server (GetExpenses) for owner: {owner}", owner);

    response = await grpcClient.GetExpensesAsync(request);
    
    return Results.Ok(response.Expenses);

});

app.MapGet("/api/expenses/{id}", async (ExpenseSvc.ExpenseSvcClient grpcClient, int id) =>
{
    GetExpenseByIdResponse? response;

    var request = new GetExpenseByIdRequest { Id = id };

    app?.Logger.LogInformation("Calling grpc server (GetExpenseByIdRequest) for id: {id}", id);
    
    response = await grpcClient.GetExpenseByIdAsync(request);

    return Results.Ok(response.Expense);

}).WithName("GetExpenseById");

app.MapPost("/api/expenses", async (ExpenseSvc.ExpenseSvcClient grpcClient, Dapr.Client.DaprClient daprClient,ExpenseModel expenseModel) =>
{
    AddExpenseResponse? response;

    var request = new AddExpenseRequest
    {
        Provider = expenseModel.Provider,
        Amount = expenseModel.Amount,
        Category = expenseModel.Category,
        Owner = expenseModel.Owner,
        Workflowstatus = expenseModel.Workflowstatus,
        Description = expenseModel.Description
    };

    app?.Logger.LogInformation("Calling grpc server (AddExpenseRequest) for provider: {provider}", expenseModel.Provider);
    response = await grpcClient.AddExpenseAsync(request);

    return Results.CreatedAtRoute("GetExpenseById", new { id = response.Expense.Id }, response.Expense);
});

app.Run();

internal class ExpenseModel
{
    public string Provider { get; set; } = string.Empty;
    public double Amount { get; set; } = 0.0;
    public string Category { get; set; } = string.Empty;
    public string Owner  { get; set; } = string.Empty;
    public int Workflowstatus  { get; set; } 
    public string Description { get; set; } = string.Empty;
}

What I’ve done here is the following:

• In-line builder.Services.AddGrpcClient<ExpenseSvc.ExpenseSvcClient> I’ve registered a gRPC client, the generic “AddGrpcClient” extension method is used within an instance of WebApplicationBuilder at the app’s entry point, specifying the gRPC typed client class and service address. The client class is auto-generated based on the “expense.proto” definition. The gRPC client type is registered as transient with dependency injection (DI). The client can now be injected and consumed directly in types created by DI.
• The gRPC service address when running locally will be the same address I’ve used when running the gRPC service on localhost, the address value in my case will be “https://localhost:7029”.
• I’ve defined a DTO class named “ExpenseModel” which will be used when sending JSON payload in the POST request body to create a new expense. We could use the “ExpenseModel” class generated by gRPC server but it is always better to use a DTO when exposing API endpoints.
• I’ve defined 2 GET endpoints to get expenses based on the Expense Owner or by Expense Id, and a POST endpoint to allow creating a new expense.
• Taking on of the endpoints for example: GET “/api/expenses/{id}” and analyzing it in detail:
  • I’ve injected an instance named “grpcClient” of the “ExpenseSvc.ExpenseSvcClient”. This client contains auto-generated methods based on the “expense.proto” definition.
  • I’m taking the “Id” from the route and using it to create an instance of “GetExpenseByIdRequest”.
  • Then I’m calling the method “GetExpenseByIdAsync” asynchronously as the following response = await grpcClient.GetExpenseByIdAsync(request); and assign the response to an object of type “GetExpenseByIdResponse”
  • Lastly, I’m returning 200 OK with the returned ExpenseModel to the caller.
• The other endpoints are following the same pattern described in the previous point.

Step 5: Test the gRPC client and the gRPC server locally

With those changes in place, I can run both the gRPC server and the client and test locally to do so, run the gRPC server first by calling dotnet run and then the gRPC client using the same command. I’ll be using PostMan to send a regular HTTP request to the client API to one of the endpoints, for example, I will send a POST request to the endpoint “/api/expenses”, the request will look like the below:

POST /api/expenses/ HTTP/1.1
Host: localhost:5252
Content-Type: application/json
Content-Length: 170

{
    "provider": "Hyve8",
    "amount": 350,
    "category": "Gym Subscription",
    "owner": "tjoudeh@mail.com",
    "workflowstatus": 1,
    "description": ""
}

Once you send the request, the endpoint should return 201 created and you should see logs reported on the gRPC server to indicate that the request from gRPC client reached the gRPC server and a new expense has been created, logs should be similar to the below image:

Deploy the gRPC server and the gRPC client to Azure Container Apps

We are ready now to deploy both applications to Azure Container Apps and do an end-to-end test.

Step 1: Add Dockerfile to the gRPC server and client

In order to deploy both applications into a container we need to add Docker files for both apps, so ensure you are on the root of the project “Expenses.Grpc.Server” and add a file named “Docekrfile” and paste the code below:

#See https://aka.ms/containerfastmode to understand how Visual Studio uses this Dockerfile to build your images for faster debugging.

FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443

FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
WORKDIR /src
COPY ["Expenses.Grpc.Server/Expenses.Grpc.Server.csproj", "Expenses.Grpc.Server/"]
RUN dotnet restore "Expenses.Grpc.Server/Expenses.Grpc.Server.csproj"
COPY . .
WORKDIR "/src/Expenses.Grpc.Server"
RUN dotnet build "Expenses.Grpc.Server.csproj" -c Release -o /app/build

FROM build AS publish
RUN dotnet publish "Expenses.Grpc.Server.csproj" -c Release -o /app/publish /p:UseAppHost=false

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "Expenses.Grpc.Server.dll"]

Do the same for the project “Expenses.Grpc.Api” and add a file named “Docekrfile” and paste the code below:

#See https://aka.ms/containerfastmode to understand how Visual Studio uses this Dockerfile to build your images for faster debugging.

FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS base
WORKDIR /app
EXPOSE 80

FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
WORKDIR /src
COPY ["Expenses.Grpc.Api/Expenses.Grpc.Api.csproj", "Expenses.Grpc.Api/"]
RUN dotnet restore "Expenses.Grpc.Api/Expenses.Grpc.Api.csproj"
COPY . .
WORKDIR "/src/Expenses.Grpc.Api"
RUN dotnet build "Expenses.Grpc.Api.csproj" -c Release -o /app/build

FROM build AS publish
RUN dotnet publish "Expenses.Grpc.Api.csproj" -c Release -o /app/publish /p:UseAppHost=false

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "Expenses.Grpc.Api.dll"]

You can use the tooling coming with Visual Studio or VS Code (Docker Extension should be installed) to generate the Docker files for you.

Step 2: Build and Push Container Images to a Container Registry

Now we need to build and push both images to a Container Registry, In my case, I’m using ACR, you can follow this post to see the commands needed to build and push images to ACR. You can use Docker Hub as well.

Step 3: Create Azure Container Apps Environment

To deploy an Azure Container App, we need to have a Container Apps Environment to host it, you can follow this post to see how to create an environment.

Step 4: Deploy gRPC server to Azure Container Apps

Now I’ll deploy the gRPC server to Azure Container App, I’ll be using CLI for creating the Azure Container App, use the right variable names in terms of environment, ACR name, etc.. to match your deployment:

$RESOURCE_GROUP="aca-grpc-rg"
$LOCATION="westus"
$ENVIRONMENT="aca-grpc-env"
$BACKEND_SVC_NAME="expenses-grpc-server"
$BACKEND_API_NAME="expenses-grpc-api"
$ACR_NAME="taskstrackeracr"

az containerapp create `
  --name $BACKEND_SVC_NAME  `
  --resource-group $RESOURCE_GROUP `
  --environment $ENVIRONMENT `
  --image "$ACR_NAME.azurecr.io/$BACKEND_SVC_NAME" `
  --registry-server "$ACR_NAME.azurecr.io" `
  --target-port 80 `
  --ingress 'external' `
  --transport http2 `
  --min-replicas 1 `
  --max-replicas 1 `
  --cpu 0.25 --memory 0.5Gi `
  --revision-suffix v20221031-1 `
  --query configuration.ingress.fqdn

Notice that I’m setting the “Transport” value here to “http2” as this is needed when the deployed container is exposing gRPC methods. I can set the “Ingress” property to “Internal” to allow only the container apps deployed within the same environment to call the gRPC server (similar to our case) but I kept it “external” as I want to test the gRPC server from PostMan as the next step.

Step 5: Test the gRPC server after deploying to Azure Container App

Similar to what I’ve done previously when testing gRPC server locally, I will take the FQDN of the gRPC server and follow the exact steps done in step 8 earlier, if all is working correctly, you should be able to invoke the gRPC service using service reflection successfully, for example, to create create an expense, PostMan results will look like the below:

Notice that we can “Enable server certificate verification” when testing against a gRPC service deployed to Azure Container Apps as the certificate used by Container Apps is a trusted certificate and the PostMan client won’t complain about it.

Step 6: Deploy gRPC client to Azure Container Apps

Now I’ll deploy the gRPC client API to Azure Container App, I’ll be using CLI for creating the Azure Container App:

az containerapp create `
  --name $BACKEND_API_NAME  `
  --resource-group $RESOURCE_GROUP `
  --environment $ENVIRONMENT `
  --image "$ACR_NAME.azurecr.io/$BACKEND_API_NAME" `
  --registry-server "$ACR_NAME.azurecr.io" `
  --target-port 80 `
  --transport http `
  --ingress 'external' `
  --min-replicas 1 `
  --max-replicas 1 `
  --cpu 0.25 --memory 0.5Gi `
  --env-vars "grpc__server=https://expenses-grpc-server.gentleplant-b85581e3.westus.azurecontainerapps.io" "grpc__localhost=false" `
  --query configuration.ingress.fqdn

Notice that I’m keeping the transport to HTTP here as this is a normal Web API that will invoke the gRPC server. As well I’m setting the environment variables to the address of the gRPC service.

With this in place, we can do our final testing via PostMan or any other REST client, take note of your gRPC client API Container App FQDN and invoke the POST operation to create a new expense, PostMan result should look like the below:

In the next post, I’ll be covering how to invoke gRPC services via Dapr Sidecar using GrpcClient and DaprClient (Dapr Client SDK).

The source code for this tutorial is available on GitHub.

Follow me on Twitter @tjoudeh

References:

• Test gRPC services with Postman or gRPCurl in ASP.NET Core
• Building a gRPC Client in .NET
• Feature Image Credit

The post gRPC Communication In Azure Container Apps – Part 1 appeared first on Bit of Technology.

• Tutorial for building Microservice Applications with Azure Container Apps and Dapr – Part 1
• Deploy backend API Microservice to Azure Container Apps – Part 2
• Communication between Microservices in Azure Container Apps – Part 3
• Dapr Integration with Azure Container Apps – Part 4
• Azure Container Apps State Store With Dapr State Management API – Part 5
• Azure Container Apps Async Communication with Dapr Pub/Sub API – Part 6
• Azure Container Apps with Dapr Bindings Building Block – Part 7
• Azure Container Apps Monitoring and Observability with Application Insights – Part 8
• Continuous Deployment for Azure Container Apps using GitHub Actions – Part 9
• Use Bicep to Deploy Dapr Microservices Apps to Azure Container Apps – Part 10
• Azure Container Apps Auto Scaling with KEDA – Part 11
• Azure Container Apps Volume Mounts using Azure Files – (This Post)
• Integrate Health probes in Azure Container Apps – Part 13

Azure Container Apps Volume Mounts using Azure Files

In the previous post, we saw how we could store and persists files on external service such as Azure Blob Storage. Still, there are some cases in which persisting files on the container itself are a must to deploy the service successfully, for example, in the last post titled “Deploy Meilisearch into Azure Container Apps” I showed how to deploy a Meliesearch instance on Container Apps requires persistence of different files such as (Lightning Memory-Mapped Database files, configurations, etc…) on the container storage as a volume mounted to a file share from Azure Files is a requirement for the service to function correctly.

The source code for this tutorial is available on GitHub. You can check the demo application too.

Storage options for Azure Container Apps

There are 3 different types of storage Container Apps that can utilize any of them or all of them based on the use case, the official documentation covers this thoroughly. In this post, I will be focusing on configuring Container Apps Volume Mounts using Azure Files as permanent storage for writing files to Azure Files share and making them accessible to other containers.

The use case that we will cover today is the following; once the user creates a new task, the Backend API service will capture the raw JSON of the task, create a JSON file, then store it locally on the service’s storage volume-mounted to an Azure Files share, then we’ll configure the Frontend Web Container App service to use the same volume mount and file share so the files written by the Backend API will be available for the Frontend Web App for download/view from the UI. We will see that creating new revisions or restarting the containers will not have any impact on the persistence of the files, they will be always preserved and accessible by the container apps.

Updating the Backend API Project

Step 1: Save files locally on container storage

We will introduce now few changes on the Backend API code base to write files on the container’s local storage, to do so open the file named “TasksStoreManager.cs” in the project “TasksTracker.TasksManager.Backend.Api” and add the below method:

private async Task WriteFileAsync(TaskModel taskModel)
 {
     var options = new JsonSerializerOptions()
     {
         WriteIndented = true
     };
     
     var jsonString = System.Text.Json.JsonSerializer.Serialize(taskModel, options);

     var directory = Path.Combine(Directory.GetCurrentDirectory(), "attachments");

     if (!Directory.Exists(directory))
     {
         Directory.CreateDirectory(directory);
     }

     var filePath = Path.ChangeExtension(Path.Combine(directory, taskModel.TaskId.ToString()), ".json");

     _logger.LogInformation("Trying to write file for task with id '{0}' on path {1}", taskModel.TaskId.ToString(),filePath);

     await File.WriteAllTextAsync(filePath, jsonString);
 }

What we have done here is simple, we are just taking the task JSON content and writing it to a file locally when we call the method Directory.GetCurrentDirectory() while running on Container Apps, it will return the Work directory of your service which is /app so this means that we are going to store the files locally on the container storage on this directory /app/attachments. 

We need to call the method “WriteFileAsync”, so update the method named “CreateNewTask” and invoke “WriteFileAsync” as the highlighted line below:

public async Task<Guid> CreateNewTask(string taskName, string createdBy, string assignedTo, DateTime dueDate)
 {
     //code removed for brevity 
    
     await _daprClient.SaveStateAsync<TaskModel>(STORE_NAME, taskModel.TaskId.ToString(), taskModel);

     _logger.LogInformation("Write task file as json with name: '{0}' to permanent file storage", taskModel.TaskName);

     await WriteFileAsync(taskModel);

     await PublishTaskSavedEvent(taskModel);
	 
     //code removed for brevity 

 }

Updating the Frontend Web App Project

Step 1: Download files from the container storage

Next, we will update the Frontend Web App to read/download the saved JSON task file, we will add a new button on the edit page that is responsible to read the stored file, to do this open the page named “Tasks/Edit.cshtml.cs” in the project named “TasksTracker.WebPortal.Frontend.Ui” and add the below method:

public IActionResult OnGetDownloadFile(string fileNameWithoutExtension)
 {

     byte[] bytes;
     var fileName = Path.ChangeExtension(fileNameWithoutExtension, ".json");

     var directory = Path.Combine(Directory.GetCurrentDirectory(), "attachments");

     var filePath = Path.Combine(directory, fileName);

     try
     {
         //Read the File data into Byte Array.
         bytes = System.IO.File.ReadAllBytes(filePath);

         //Send the File to Download.
         return File(bytes, "application/octet-stream", fileName);
     }
     catch (FileNotFoundException)
     {
         var result = new NotFoundObjectResult(new { message = "File Not Found" });
         return result;
     }

 }

As you can see above, we are reading the Tasks JSON files from the same storage location directory /app/attachments, remember that those are 2 different services and each one has its own local storage, but once we configure both services local storage to a volume mounted to the same Azure Files share, both services will be able to see the same files under this directory. More about this in the next steps.

Now, we just need to add a link on the Edit screen to download the raw JSON for each task, to do this, open the file named “Tasks/Edit.cshtml” and add the highlighted line below:

<div class="col-md-4">
    <form method="post">
		
	@* code removed for brevity *@
		
        <div class="form-group">
            <input type="submit" value="Save" class="btn btn-primary" />
            <a class="btn btn-primary" download href="@Url.Page("Edit", "DownloadFile", new { fileNameWithoutExtension = Model.TaskUpdate!.TaskId })">Download Raw</a>
        </div>

    </form>
</div>

Create the Azure File Share

If you are following up with the tutorial, we can use the same Azure Storage account used earlier to create Azure File share (skip step 1 below), if not you can create a new storage account as the step 1 below

Step 1: Create a new Store account

From a PowerShell console run the command below:

$RESOURCE_GROUP="tasks-tracker-rg"
$STORAGE_ACCOUNT="taskstracker"
$LOCATION="eastus"

az storage account create `
  --resource-group $RESOURCE_GROUP `
  --name $STORAGE_ACCOUNT_NAME `
  --location "$LOCATION" `
  --kind StorageV2 `
  --sku Standard_LRS `
  --enable-large-file-share `
  --query provisioningState

Step 2: Create Azure Storage File Share

Now we will create the File Share which will be used to mount containers’ local storage/volumes to it, to do use PowerShell and run the command below:

$STORAGE_ACCOUNT="taskstracker"
$SHARE_NAME = "permanent-file-share"
$RESOURCE_GROUP="tasks-tracker-rg"

az storage share-rm create `
  --resource-group $RESOURCE_GROUP `
  --storage-account $STORAGE_ACCOUNT  `
  --name $SHARE_NAME `
  --quota 1024 `
  --enabled-protocols SMB `
  --output table

Step 3: Link the Storage File Share to Container Apps Environment

The below step will define the storage mount link from our Container Apps environment to the Azure Storage account:

## Get storage account key
$STORAGE_ACCOUNT_KEY=$(az storage account keys list -n $STORAGE_ACCOUNT --query "[0].value" -o tsv)

##Create the storage link in the environment.
$STORAGE_MOUNT_NAME = "permanent-storage-mount"
az containerapp env storage set `
  --name $ENVIRONMENT `
  --access-mode ReadWrite `
  --azure-file-account-name $STORAGE_ACCOUNT `
  --azure-file-account-key $STORAGE_ACCOUNT_KEY `
  --azure-file-share-name $SHARE_NAME `
  --storage-name $STORAGE_MOUNT_NAME `
  --resource-group $RESOURCE_GROUP `
  --output table

Basically, this above command creates a link between the Container App environment and the file share created in step 2 when using the az storage share-rm command.

Step 4: Update the Backend API service to use the storage mount

Now we are ready to configure the Backend API service to use this storage mount, to do so w need to do 2 things:

• Define a storage volume
• Define a volume mount

To achieve this, the az container app has no direct API to update the storage configuration, so what we are going to do, is download the YAML file of the service, do the modification manually by hand on the YAML file, then update the container app using the updated YAML. If you are using ARM/Bicep templates you can do this directly from there.

But first, we need to push our code changes to ACR, to do this run the PowerShell command below:

$BACKEND_API_NAME="tasksmanager-backend-api"
$ACR_NAME="taskstrackeracr"

az acr build --registry $ACR_NAME --image "tasksmanager/$BACKEND_API_NAME" --file 'TasksTracker.TasksManager.Backend.Api/Dockerfile' .

Next, we will download the Backend API YAML file, so we can run the manual edits, the command below will download a file named “app-backend-api.yaml” to the directory you are in:

az containerapp show `
  --name $BACKEND_API_NAME `
  --resource-group $RESOURCE_GROUP `
  --output yaml > app-backend-api.yaml

Once the file “app-backend-api.yaml” is downloaded, go ahead and open with VS Code or an editor which supports editing yaml files, we need to do 3 things on the file:

1. Define a “volumes” array on the template level with a single entry/item named “azure-file-volume” for the storage linked to the container app environment “permanent-storage-mount”, this volume entry should be of storage type “AzureFile”
2. Define “volumeMounts” array for the container with an entry/item with a volume name “azure-file-volume” and with a mount path of value “/app/attachments”. This path should match the path our backend API writes JSON files to and our frontend web app reads JSON files from. You can define many volume mounts if needed to support other storage use cases
3. Update the “revesionSuffix” to a unique value, so the container app will not complain that revesionSuffix is already used.

Your modified application YAML should look similar to the below image, don’t forget to save the file

Next, we need to update the container app and create a new revision using the updated YAML file, to do so, run the command below:

az containerapp update `
  --name $BACKEND_API_NAME `
  --resource-group $RESOURCE_GROUP `
  --yaml app-backend-api.yaml `
  --output table

Step 5: Update the Frontend Web App service to use the storage mount

Now we’ve to do the same steps we have done before for the backend API to make the Container App Frontend WebApp storage volume mounted to AzureFile share and can read the JSON files written by the Backend API

Push code changes to ACR as below:

az acr build --registry $ACR_NAME --image "tasksmanager/$FRONTEND_WEBAPP_NAME" --file 'TasksTracker.WebPortal.Frontend.Ui/Dockerfile' .

Download the YAML file of the Frontend Web App

az containerapp show `
  --name $FRONTEND_WEBAPP_NAME `
  --resource-group $RESOURCE_GROUP `
  --output yaml > app-frontend-ui.yaml

Manually update the YAML entries to create “volumes” and “volumeMounts”, the files will be identical to what used in the Backend API

Lastly, update the Frontend Web App container by creating a new revision as the command below:

##Update container app using yaml file
az containerapp update `
  --name $FRONTEND_WEBAPP_NAME `
  --resource-group $RESOURCE_GROUP `
  --yaml  app-frontend-ui.yaml `
  --output table

With both changes in place, we can give it a try and save a new task from the UI, it should create a JSON file in the backend, and when you edit the file, you should see a download button that allows you to download the Raw JOSN file from the shared Azure File.

You can access both containers by using “exec” and navigating to the directory “/app/attachments”, you should be able to see the files stored in this local location which s mounted to Azure Files.

##Access Backend API container
az containerapp exec --name $BACKEND_API_NAME --resource-group $RESOURCE_GROUP
ls /app/attachments

##Access Frontend WebApp container
az containerapp exec --name $FRONTEND_WEBAPP_NAME --resource-group $RESOURCE_GROUP
ls /app/attachments

And you can verify that files are stored in the shared Azure Files Storage from Azure Portal or Azure Storage Explorer.

Update the Bicep template to reflect changes in solution components

To keep things consistent, we need to update the Bicep template to match the changes we’ve done using the “az containerapp”, the changes are on GitHub so i will just put links to the impacted files with a brief description of what changed

• Update on file “storageAccount.bicep“: Adding the new file service and the file share
• Update on file “acaEnvironment.bicep“: Creating environment storages which created the link between Azure File Share and container Apps environment
• Update on file “containerApp.bicep“: Creating the “volumeMounts” array and the “volumes” for all containers
• Update on file “main.bicep” by updating the values for some parameters and passing the storage mount name for the container apps module.

Conclusion

As we saw in this post, we can mount a file share from Azure Files as a volume inside a container, and once this setup we can achieve the below:

• Files written under the mount location are persisted to the file share.
• Files in the share are available via the mount location.
• Multiple containers can mount the same file share, including ones that are in another replica, revision, or container app.
• All containers that mount the share can access files written by any other container or method.
• More than one Azure Files volume can be mounted in a single container.

The source code for this tutorial is available on GitHub. You can check the demo application too.

Follow me on Twitter @tjoudeh

References:

• Azure Container Apps: working with storage
• Featured Image Credit

The post Azure Container Apps Volume Mounts using Azure Files – Part 12 appeared first on Bit of Technology.

Overview of Meilisearch

Meilisearch is a RESTful search API that offers a fast and instant search experience (search as you type), it is designed for a vast majority of needs of small-to-medium businesses with little configuration needed during installation yet with high customization.
Meilisearch is an open-source project built using Rust with more than 29K stars on GitHub and support for various SDKs including dotnet.

Meilisearch on Azure Container Apps

Meilisearch can be deployed on Azure on different options, Meilisearch container image can be deployed on Azure App Services as per the documentation, on this post I will go over the steps needed to prepare the Bicep template needed to deploy a Meilisearch container image into Azure Container Apps and use storage mounts in Azure Container Apps to permanently host Meilisearch database into Azure Files.

The source code used for this post exists on GitHub.

Deploying Meilisearch on Azure Container Apps

In this post, I will go over the Bicep template needed to deploy Meilisearch into Azure Container Apps and any important notes needed for deployment.

You can click on the button below to deploy a Meilisearch instance into Azure Container Apps. This is the final result of the Bicep templates we are going to build:



If you are new to Bicep, you can check my previous post on how to deploy Container Apps using Bicep.

Step 1: Define Azure Storage Resource

Azure storage is needed to create a file share service under it, the file share service will allow us to mount a file share from Azure Files as a volume inside the Meilisearch container. This means that Meilisearch DB and its configuration files are written into the container volume location are persisted in the file share, this is durable storage so if the container is restarted, crashed or a new revision is deployed; the files on the share will not be impacted and the new provisioned container will find the files on the configured volume.

To create a file share service under Azure storage, create a directory named “deploy/modules”, add a new file named “storage.bicep” and use the code below:

@description('The name of your application')
param applicationName string

@description('The Azure region where all resources in this example should be created')
param location string = resourceGroup().location

@description('A list of tags to apply to the resources')
param resourceTags object

@description('The name of the container to create. Defaults to applicationName value.')
param containerName string = applicationName

@description('The name of the Azure file share.')
param shareName string

@description('The name of storage account')
param storageAccountName string

resource storageAccount 'Microsoft.Storage/storageAccounts@2021-09-01' = {
  name: storageAccountName
  location: location
  tags: resourceTags
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
}

resource blobServices 'Microsoft.Storage/storageAccounts/blobServices@2021-09-01' = {
  name: 'default'
  parent: storageAccount
}

resource storageContainer 'Microsoft.Storage/storageAccounts/blobServices/containers@2021-09-01' = {
  name: containerName
  parent: blobServices
}

resource fileServices 'Microsoft.Storage/storageAccounts/fileServices@2021-09-01' = {
  name: 'default'
  parent: storageAccount
}

resource permanentFileShare 'Microsoft.Storage/storageAccounts/fileServices/shares@2022-05-01' = {
  name: shareName
  parent: fileServices
  properties: {
    accessTier: 'TransactionOptimized'
    enabledProtocols: 'SMB'
    shareQuota: 1024
  }
}

var storageKeyValue = storageAccount.listKeys().keys[0].value

output storageAccountName string = storageAccount.name
output id string = storageAccount.id
output apiVersion string = storageAccount.apiVersion
output storageKey string = storageKeyValue

Looking at the code above, notice that we’ve created a file share with the access tier “TransactionOptimized”, you can use “Premium” as it is backed by SSD drives and provides low latency. The size of the file share is set to 1024 gigabytes (1TB).

Step 2: Define Azure Log Analytics Workspace Resource

Add a new file named “logAnalyticsWorkspace.bicep” under the folder “modules”, and use the code below, the log analytics workspace is needed by the Container Apps Environment,

@description('The name of your Log Analytics Workspace')
param logAnalyticsWorkspaceName string

@description('The Azure region where all resources in this example should be created')
param location string = resourceGroup().location

@description('A list of tags to apply to the resources')
param resourceTags object

resource logAnalyticsWorkspace'Microsoft.OperationalInsights/workspaces@2021-12-01-preview' = {
  name: logAnalyticsWorkspaceName
  tags: resourceTags
  location: location
  properties: any({
    retentionInDays: 30
    features: {
      searchVersion: 1
    }
    sku: {
      name: 'PerGB2018'
    }
  })
}

var sharedKey = listKeys(logAnalyticsWorkspace.id, logAnalyticsWorkspace.apiVersion).primarySharedKey

output workspaceResourceId string = logAnalyticsWorkspace.id
output logAnalyticsWorkspaceCustomerId string = logAnalyticsWorkspace.properties.customerId
output logAnalyticsWorkspacePrimarySharedKey string = sharedKey

Step 3: Define an Azure Container Apps Environment Resource

Add a new file named “acaEnvironment.bicep” under the folder “modules” and use the code below:

@description('The name of Azure Container Apps Environment')
param acaEnvironmentName string

@description('The Azure region where all resources in this example should be created')
param location string = resourceGroup().location

@description('A list of tags to apply to the resources')
param resourceTags object

param logAnalyticsWorkspaceCustomerId string

@secure()
param logAnalyticsWorkspacePrimarySharedKey string 

resource environment 'Microsoft.App/managedEnvironments@2022-03-01' = {
  name: acaEnvironmentName
  location: location
  tags: resourceTags
  properties: {
    appLogsConfiguration: {
      destination: 'log-analytics'
      logAnalyticsConfiguration: {
        customerId: logAnalyticsWorkspaceCustomerId
        sharedKey: logAnalyticsWorkspacePrimarySharedKey
      }
    }
  }
}

output acaEnvironmentId string = environment.id

Step 4: Define an Azure Container Apps Environment Storages Resource

Add a new file named “acaEnvironmentStorages.bicep” under the folder “modules” and use the content below:

@description('The name of Azure Container Apps Environment')
param acaEnvironmentName string

@description('The name of your storage account')
param storageAccountResName string

@description('The storage account key')
@secure()
param storageAccountResourceKey string 

@description('The ACA env storage name mount')
param storageNameMount string

@description('The name of the Azure file share. Defaults to applicationName value.')
param shareName string

resource environment 'Microsoft.App/managedEnvironments@2022-03-01' existing = {
  name: acaEnvironmentName
}

//Environment Storages
resource permanentStorageMount 'Microsoft.App/managedEnvironments/storages@2022-03-01' = {
  name: storageNameMount
  parent: environment
  properties: {
    azureFile: {
      accountName: storageAccountResName
      accountKey: storageAccountResourceKey
      shareName: shareName
      accessMode: 'ReadWrite'
    }
  }
}

This is a key step to configure a storage definition of type AzureFile in the Container Apps Environment, within this file we have enabled the environment to use the Azure File share service for any Container App under this environment, we are setting the access mode to “ReadWrite” as we need to write and read files from the file share.

Step 5: Define an Azure Container Apps Resource

Add a new file named “containerApp.bicep” under the folder “modules” and use the content below:

param containerAppName string
param location string 
param environmentId string 
param containerImage string
param targetPort int
param containerRegistry string
param containerRegistryUsername string
param isPrivateRegistry bool
param registryPassName string
param minReplicas int = 0
param maxReplicas int = 1
@secure()
param secListObj object
param envList array = []
param revisionMode string = 'Single'
param storageNameMount string
param volumeName string
param mountPath string
param resourceTags object
param resourceAllocationCPU string
param resourceAllocationMemory string

resource containerApp 'Microsoft.App/containerApps@2022-06-01-preview' = {
  name: containerAppName
  location: location
  tags: resourceTags
  properties: {
    managedEnvironmentId: environmentId
    configuration: {
      activeRevisionsMode: revisionMode
      secrets: secListObj.secArray
      registries: isPrivateRegistry ? [
        {
          server: containerRegistry
          username: containerRegistryUsername
          passwordSecretRef: registryPassName
        }
      ] : null
      ingress: {
        external: true
        targetPort: targetPort
        transport: 'auto'
        traffic: [
          {
            latestRevision: true
            weight: 100
          }
        ]
      } 
      dapr: null
    }
    template: {
      containers: [
        {
          image: containerImage
          name: containerAppName
          env: envList
          volumeMounts: [
            { 
               mountPath:mountPath
               volumeName:volumeName
            }
          ]
          resources:{
            cpu: json(resourceAllocationCPU)
            memory: resourceAllocationMemory
           }
        }
      ]
      volumes: [
        {
           name: volumeName
           storageName: storageNameMount
           storageType: 'AzureFile'
        }
      ]
      scale: {
        minReplicas: minReplicas
        maxReplicas: maxReplicas
      }
    }
  }
}

output fqdn string =  containerApp.properties.configuration.ingress.fqdn

This module is responsible to deploy the actual Meilisearch container image to Container App, what we have done here is the following:

• Configuring the ingress of the container app to be external ingress (accepts HTTP requests from the public internet).
• Parameterizing the target port of the ingress controller, we will set the value in the next steps.
• Parameterizing the Meilisearch container image which will be deployed on this container app, the parameter will hold the Meilisearch image from docker hub.
• Parameterizing the compute resources CPU and memory of the container app.
• Parameterizing the secrets and environment variables arrays.
• Define one single storage volume of type AzureFile for the container app and parameterize the volume name and storage name mount.
• Define one single volume mount in the container app and parameterize the mount path and volume name.
• Lastly, outputting the FQDN of the provisioned container app as it will be the URL to access Meilisearch API.

Step 6: Define the Main module for the final deployment

Lastly, we need to define the Main Bicep module which will link the modules together, this will be the file that is referenced from AZ CLI command when creating the entire resources, to do so under the folder “deploy”, add a new file named “main.bicep” and use the code below:

targetScope = 'subscription'

//Azure Regions which Azure Container Apps available at can be found on this link:
//https://azure.microsoft.com/en-us/explore/global-infrastructure/products-by-region/?products=container-apps&regions=all
@description('The Azure region code for deployment resource group and resources such as westus, eastus, northeurope, etc...')
param location string = 'westus'

@description('The name of your search service. This value should be unique')
param applicationName string = 'meilisearch'

@description('The Container App CPU cores and Memory')
@allowed([
  {
    cpu: '0.25'
    memory: '0.5Gi'
  }
  {
    cpu: '0.5'
    memory: '1.0Gi'
  }
  {
    cpu: '0.75'
    memory: '1.5Gi'
  }
  {
    cpu: '1.0'
    memory: '2.0Gi'
  }
  {
    cpu: '1.25'
    memory: '2.50Gi'
  }
  {
    cpu: '1.5'
    memory: '3.0Gi'
  }
  {
    cpu: '1.75'
    memory: '3.5Gi'
  }
  {
    cpu: '2.0'
    memory: '4.0Gi'
  }
])
param containerResources object = {
  cpu: '1.0'
  memory: '2.0Gi'
}

@maxLength(4)
@description('The environment of deployment such as dev, test, stg, prod, etc...')
param deploymentEnvironment string = 'dev'

@secure()
@description('The Master API Key used to connect to Meilisearch instance')
@minLength(32)
param meilisearchMasterKey string = newGuid()


var resourceGroupName = '${applicationName}-${deploymentEnvironment}-rg'
var logAnalyticsWorkspaceResName = '${applicationName}-${deploymentEnvironment}-logs'
var environmentName = '${applicationName}-${deploymentEnvironment}-env'
var storageAccountName  = '${take(applicationName,14)}${deploymentEnvironment}strg'

var shareName = 'meilisearch-fileshare'
var storageNameMount = 'permanent-storage-mount'

var meilisearchImageName = 'getmeili/meilisearch:v0.29'
var meilisearchAppPort = 7700
var dbMountPath = '/data/meili'
var volumeName = 'azure-file-volume'

var defaultTags = {
  environment: deploymentEnvironment
  application: applicationName
}

resource rg 'Microsoft.Resources/resourceGroups@2021-04-01' = {
  name: resourceGroupName
  location: location
  tags: defaultTags
}

module storageModule 'modules/storage.bicep' = {
  scope: resourceGroup(rg.name)
  name: '${deployment().name}--storage'
  params: {
    storageAccountName: storageAccountName
    location: rg.location
    applicationName: applicationName
    containerName: applicationName
    shareName: shareName
    resourceTags: defaultTags
  }
}

module logAnalyticsWorkspace 'modules/logAnalyticsWorkspace.bicep' = {
  scope: resourceGroup(rg.name)
  name: '${deployment().name}--logAnalyticsWorkspace'
  params: {
    logAnalyticsWorkspaceName: logAnalyticsWorkspaceResName
    location: rg.location
    resourceTags: defaultTags
  }
}

module environment 'modules/acaEnvironment.bicep' = {
  scope: resourceGroup(rg.name)
  name: '${deployment().name}--acaenvironment'
  params: {
    acaEnvironmentName: environmentName
    location: rg.location
    logAnalyticsWorkspaceCustomerId: logAnalyticsWorkspace.outputs.logAnalyticsWorkspaceCustomerId
    logAnalyticsWorkspacePrimarySharedKey: logAnalyticsWorkspace.outputs.logAnalyticsWorkspacePrimarySharedKey
    resourceTags: defaultTags
  }
}

module environmentStorages 'modules/acaEnvironmentStorages.bicep' = {
  scope: resourceGroup(rg.name)
  name: '${deployment().name}--acaenvironmentstorages'
  dependsOn:[
    environment
  ]
  params: {
    acaEnvironmentName: environmentName
    storageAccountResName: storageModule.outputs.storageAccountName
    storageAccountResourceKey: storageModule.outputs.storageKey
    storageNameMount: storageNameMount
    shareName: shareName
  }
}

module containerApp 'modules/containerApp.bicep' = {
  scope: resourceGroup(rg.name)
  name: '${deployment().name}--${applicationName}'
  dependsOn: [
    environment
  ]
  params: {
    containerAppName: applicationName
    location: rg.location
    environmentId: environment.outputs.acaEnvironmentId
    containerImage: meilisearchImageName
    targetPort: meilisearchAppPort
    minReplicas: 1
    maxReplicas: 1
    revisionMode: 'Single'
    storageNameMount: storageNameMount
    mountPath: dbMountPath
    volumeName: volumeName
    resourceTags: defaultTags
    resourceAllocationCPU: containerResources.cpu
    resourceAllocationMemory: containerResources.memory
    secListObj: {
      secArray: [
        {
          name: 'meili-master-key-value'
          value: meilisearchMasterKey
        }
      ]
    }
    envList: [
      {
        name: 'MEILI_MASTER_KEY'
        secretRef: 'meili-master-key-value'
      }
      {
        name: 'MEILI_DB_PATH'
        value: dbMountPath
      }
    ]
  }
}

output containerAppUrl string = containerApp.outputs.fqdn

What we have done is the following:

• Defined a set of parameters so the end user can control the deployment of Meilisearch instance, parameters defined as the following:
  • Location: The Azure region code (“westus”, “northeurope”, “australiacentral”, etc…). This should be a region where Azure container Apps and Azure Storage is available, you can check where Azure Container Apps are available on this link.
  • Application Name: the name of the Meilisearch search service, this name will be part of the FQDN and will be used to set resource group name, storage, container app environment, and log analytics workspace.
  • Container Resources: Container App CPU and Memory. Read here to understand more about those CPU/Memory combinations. The limits are soft limits and you can request to increase the quota by submitting a support request.
  • Deployment Environment: Used to identify deployment resources (“dev”, “stg”, “prod”, etc…) and tag them with the selected environment, this has nothing to do with the capacity or performance of the resources provisioned. This will be useful if you are deploying multiple  Meilisearch instances under the same subscription for dev/test scenarios.
  • Meilisearch Master Key: This is the Master API Key used with the Meilisearch instance, minimum length is 32 characters. The recommendation is to generate a strong key, if not provided deployment template will generate a guide as the Master API key.
• Defined a set of variables to be passed to the child modules to provision needed resources, variables defined are:
  • Share Name: the name of the file share which will be created under Azure storage files share, this name will be passed to the Container Apps environment too to configure the storage definition of type AzureFile in the Container Apps environment.
  • Storage Name Mount: The name of the storage mount associated with the Meilisearch container.
  • Meilisearch Image Name: The Meilisearch docker image name “getmeili/meilisearch:v0.29” hosted in docker hub using tag ‘v0.29’ this is the latest tag at the time of writing this post.
  • Meilisearch App Port: This is the port that Container App listens to for incoming requests, Meilisearch uses port 7700, when ingress is enabled on Container App; the ingress endpoint is exposed on port 443.
  • DB Mount Path: The path “/data/meili” is used, this path represents the volume inside the Container App mounted to Azure File Share. You can change the path if needed but the path needs to be the same in an environment variable named “MEILI_DB_PATH“
  • Volume Name: Logical name used to define the volume used in the Container App.
• Notice how we are storing the “Meilisearch Master Key” securely in the Container Apps secrets, and using a “secretRef” in the environment variables to reference the secret. The name of the environment variable which stores the Master API Key must be “MEILI_MASTER_KEY“
• Lastly, we are returning the provisioned Container App FQDN as a deployment output.

Step 7: Deploy Meilisearch Resources using Azure CLI

Now we are ready to deploy the resources using Azure CLI, to do so, open a PowerShell console and use the script below, don’t forget to set actual values for the placeholders.

az deployment sub create `
  --template-file ./main.bicep `
  --location WestUS `
  --parameters '{ \"meilisearchMasterKey\": {\"value\":\"YOUR_MASTER_KEY\"}, \"applicationName\": {\"value\":\"YOUR_APP_NAME\"}, \"deploymentEnvironment\": {\"value\":\"dev\"}, \"location\": {\"value\":\"westus\"} }'

Note: You can use the “Deploy to Azure Button” highlighted above to deploy the resources.

If all is completed successfully you should see the resource group and the below 4 resources created under the subscription selected as the image below. To get the Container App FQDN, you can navigate to the Container App or you can get it from the deployment output tab.

Step 8: Test Deployed Meilisearch Instance

To test the deployed Meilisearch Instance, I’ve created a console application that uses the dotnet Meilisearch SDK and it creates an index named “movies” and indexes 40K documents using a JSON file (file is included in source code) or you can download it from this link.

The console application contains the below code:

using System.Text.Json;

namespace Meilisearch.Console
{
    public class Movie
    {
        public int Id { get; set; }
        public string Title { get; set; }
        public string Poster { get; set; }
        public string Overview { get; set; }
        public IEnumerable<string> Genres { get; set; }
    }

    internal class Program
    {
        static async Task Main(string[] args)
        {

            MeilisearchClient client = new MeilisearchClient("https://<fqdn>.<location>.azurecontainerapps.io", "<MASTER API KEY>");
            var options = new JsonSerializerOptions
            {
                PropertyNameCaseInsensitive = true
            };

            string jsonString = await File.ReadAllTextAsync(@"movies.json");
            var movies = JsonSerializer.Deserialize<IEnumerable<Movie>>(jsonString, options);

            var index = client.Index("movies");

            var newSettings = new Settings
            {
                FilterableAttributes = new string[] { "genres" },
                SortableAttributes = new string[] { "title" },
            };

            await index.UpdateSettingsAsync(newSettings);

            await index.AddDocumentsAsync<Movie>(movies,"id");
        }
    }
}

What the console application does is the following:

• Instantiating MeilisearchClient by passing the URL of the Container App and the Master API Key.
• Reading the JSON content from the file.
• Updating the settings and attributes of an index named “movies”.
• Lastly, add the documents (movies) into the index named “movies”.

Meilisearch provides a PostMan collection that contains all the endpoints to configure your deployed Meilisearch instance and perform a search as well, Meilisearch PostMan collection can be downloaded from this link.

To verify that documents added successfully to the “movies” index, you can issue the below HTTP Get request and you see a list of movies returned.

GET /indexes/movies/documents
Host: <FQDN>.<Location>.azurecontainerapps.io
Authorization: Bearer <MASTER API KEY>

Follow me on Twitter @tjoudeh

References:

• Meilisearch on Azure

The post Deploy Meilisearch into Azure Container Apps appeared first on Bit of Technology.

This post is inspired by the amazing article Monitoring Azure Container Apps With Azure Managed Grafana written by Paul Yu.

In his post, Paul walks us through provisioning Azure Managed Grafana instance and Container Apps using Terraform AzAPI provider and how we can add Container Apps dashboards into the Managed Grafana instance.

In this post, I’ll walk you through how to monitor in Grafana a simple Microservices App which consists of 2 Azure Container Apps, Azure Service Bus, and Azure Storage. And I will put the system under some load so we can see how Container Apps are scaling based on KEDA scaling rules and how these metrics are reflecting beautifully in Managed Grafana dashboards.

The source code is available on GitHub. A detailed Tutorial of Container Apps Can be accessed here.

The simple Microservices App components are shown below:

An overview of Azure Managed Grafana

Grafana is an open and composable observability and data visualization platform that permits you to visualize metrics, logs, and traces from multiple sources. Grafana is also available as Azure Managed Grafana, a managed service that is optimized for the Azure environment that enables us to run Grafana natively within the Azure cloud platform.

As we will see in this post Azure Managed Grafana will allow us to bring together all our telemetry data in one place. It can access a wide variety of data sources, including our data stores in Azure as it has built-in support for Azure Monitor and Azure Data Explorer.

Setting up Azure Managed Grafana

We will start now by creating an Azure Managed Grafana workspace using the Azure CLI.

Step 1: Create a new resource group

We need to create a resource group that will contain our resources, open the PowerShell terminal, use the command below:

$RESOURCE_GROUP="grafana-poc-rg"
$LOCATION="eastus"

az group create `
  --name $RESOURCE_GROUP `
  --location $LOCATION

Step 2: Create an Azure Managed Grafana workspace

Run the command below to create an Azure Managed Grafana instance with a system-assigned managed identity, this is the default authenticate method for Azure Managed Grafana instances:

$GRAFANA_NAME = "grafana-aca-poc"

az grafana create `
--name $GRAFANA_NAME `
--resource-group $RESOURCE_GROUP

When running the command above, you must log in to Azure CLI with a user that has an Owner Role assigned on the subscription, this is needed because when a Grafana instance is created, Azure Managed Grafana grants it the Monitoring Reader role for all Azure Monitor data and Log Analytics resources within the subscription.
With this in place, any resource provisioned in the subscription will inherit from the subscription a Monitoring Reader role (Can read all monitoring data).

Once the deployment is complete, you’ll see a note in the output of the command line stating that the instance was successfully created, Take note of the endpoint URL listed in the CLI output. Based on the resource naming and location we’ve picked it will be similar to the following URL: https://grafana-aca-poc-<randomstring>.eus.grafana.azure.com/

Now we are ready to login into Managed Grafana instance and start defining our dashboard, we will do this after we deploy our simple microservices app.

Deploy microservices application resources

In the below steps, we will deploy the application components listed below, if you need through details on how those components are setup, you can visit the corresponding links:

• Azure Service Bus namespace, a topic, and subscription as a service broker
• Azure Storage Account to store processed messages.
• Azure Container Apps Environment
• 2 Dapr components (State Management API) and (Pub/Sub API)
• Azure Container Apps to host Backend Processor/API with internal ingress
• Azure Container Apps to host Frontend API with external ingress

Step 1: Deploy Azure Service Bus and Azure Storage Account

Use the commands below to deploy the Service Bus and Storage account:

$NamespaceName="shipmentsservices"
$TopicName="shipmentstopic"
$TopicSubscription="shipments-processor-subscription"

##Create Service Bus namespace
az servicebus namespace create `
--resource-group $RESOURCE_GROUP `
--name $NamespaceName `
--location $LOCATION

##Create a topic under namespace
az servicebus topic create `
--resource-group $RESOURCE_GROUP `
--namespace-name $NamespaceName `
--name $TopicName

##Create a topic subscription
az servicebus topic subscription create `
  --resource-group $RESOURCE_GROUP `
  --namespace-name $NamespaceName `
  --topic-name $TopicName `
  --name $TopicSubscription

##Create Storage Account
$STORAGE_ACCOUNT_NAME = "shipmentstore"
az storage account create `
--name $STORAGE_ACCOUNT_NAME `
--resource-group $RESOURCE_GROUP `
--location $LOCATION `
--sku Standard_LRS `
--kind StorageV2

Step 2: Deploy Azure Container App Environment

Now we will create the ACA environment and associate 2 dapr components pubsub-servicebus and shipmentsstatestore, the content of the dapr component file pubsub-svcbus.yaml and statestore-tablestorage.yaml can be found on the links.

Creating ACA environment will create by default a Log Analytics Workspace which will contain all the metrics, telemetry, and logs produced by any container apps deployed within this environment, and by default Managed Gragana Instance has a Monitoring Reader role so container apps metrics will be visible on Grafana dashboards.

$ENVIRONMENT="orders-services-aca-env"
az containerapp env create `
--name $ENVIRONMENT `
--resource-group $RESOURCE_GROUP `
--location $LOCATION

## Set Dapr Components
az containerapp env dapr-component set `
--name $ENVIRONMENT --resource-group $RESOURCE_GROUP `
--dapr-component-name pubsub-servicebus `
--yaml '.\components\pubsub-svcbus.yaml'

az containerapp env dapr-component set `
--name $ENVIRONMENT --resource-group $RESOURCE_GROUP `
--dapr-component-name shipmentsstatestore `
--yaml '.\components\statestore-tablestorage.yaml'

Step 3: Deploy Azure Container App Backend Processor

We will deploy now the backend API which is responsible to process messages published into Service Bus and will store the processed messages in Table Storage. This API will be configured to use KEDA Service Bus scaler to autoscale for up to 10 instances if the length of messages in the Service Bus Topic exceeds 10 messages. As well this service will expose an internal endpoint to allow the frontend API to invoke it over HTTP using dapr service to service invocation. To read more about KEDA autoscaling you can visit my previous post.

I’m building and pushing the docker images to Azure Container Registry, you can use the same approach or you can use another registry such as Docker Hub. The source code of the backend processor can be found here.

To deploy the Backend processor, use the commands below:

$BACKEND_SVC_NAME="shipments-backend-processor"
$ACR_NAME="taskstrackeracr"
## Create Backend App
az containerapp create `
 --name $BACKEND_SVC_NAME  `
 --resource-group $RESOURCE_GROUP `
 --environment $ENVIRONMENT `
 --registry-server "$ACR_NAME.azurecr.io" `
 --image "$ACR_NAME.azurecr.io/$BACKEND_SVC_NAME" `
 --cpu 0.50 --memory 1.0Gi `
 --target-port 80 `
 --ingress 'internal' `
 --secrets "svcbus-connstring=<Conn string>" `
 --enable-dapr `
 --dapr-app-id $BACKEND_SVC_NAME `
 --dapr-app-port 80 `
 --min-replicas 1 `
 --max-replicas 10 `
 --scale-rule-name "queue-length-autoscaling" `
 --scale-rule-type "azure-servicebus" `
 --scale-rule-metadata "topicName=shipmentstopic" `
		       "subscriptionName=shipments-processor-subscription" `
		       "namespace=shipmentsservices" `
		       "messageCount=10" `
		       "connectionFromEnv=svcbus-connstring" `
 --scale-rule-auth "connection=svcbus-connstring"

Step 4: Deploy Azure Container App Frontend API

This API is very simple, it exposes a single external API endpoint which we are going to load test using K6, this endpoint reads data from Azure Table Storage by invoking an internal endpoint in the Backend Processor. HTTP autoscaling rule will be configured to trigger if the container app replica receives 10 concurrent requests per second or more. It can scale up to 10 instances maximum as per the configuration.

I’m building and pushing the docker images to Azure Container Registry, you can use the same approach or you can use another registry. The source code of the backend processor can be found here.

To deploy the Frontend API, use the commands below:

$FRONTEND_WEBAPP_NAME="shipments-frontend-api"
## Create Frontend App
az containerapp create `
--name $FRONTEND_WEBAPP_NAME  `
--resource-group $RESOURCE_GROUP `
--environment $ENVIRONMENT `
--registry-server "$ACR_NAME.azurecr.io" `
--image "$ACR_NAME.azurecr.io/$FRONTEND_WEBAPP_NAME" `
--cpu 0.25 --memory 0.5Gi `
--target-port 80 `
--ingress 'external' `
--enable-dapr `
--dapr-app-id  $FRONTEND_WEBAPP_NAME `
--dapr-app-port 80 `
--min-replicas 1 `
--max-replicas 10 `
--scale-rule-name "http-requests-rule" `
--scale-rule-http-concurrency 10 `
--scale-rule-type "http"

Generate Load to scale up the Container Apps

In order to see some realistic dashboard data on Grafana, we need to simulate some load on the microservices app, to do so we need to publish a large number of messages to Service Bus, and we need to simulate high traffic coming from the internet on the Frontend API, to achieve this we need do the following:

Step 1: Publish a large number of messages to Service Bus Topic

I’ve created a sample console application that asks the user how many messages to publish on the topic and it will send every 25 messages in a batch, use can provide for example 10000 messages and the console application will publish them in seconds, this will make the Topic fill up quickly so KEDA Service Bus scaler which is monitoring the Topic will trigger the auto-scaling for Backend Processor and start spinning up more replicas to cope up with this sudden number of messages in the topic. The source code of this console application can be found on the link.

Step 2: Generate HTTP traffic load to scale up Container App Frontend API

I will be using an open source tool named K6 to simulate virtual user traffic to the Frontend API, the traffic which we will generate should trigger the HTTP auto-scaling Frontend API and start spinning up more replicas to handle the sudden number of concurrent HTTP requests.

Using the tool is very simple, you need to create a JavaScript file and then invoke this file from K6 CLI. To install the K6 CLI follow the instructions document on this link. On Windows, they have .msi package too which makes installation very simple.

The content of the JavaScript file will contain the following:

import http from 'k6/http';
import {sleep} from 'k6';

const baseUrl = 'https://shipments-frontend-api.happysea-573aaf45.eastus.azurecontainerapps.io';

  export let options = {
        vus: 100,
        duration: '180s'
  };

export default function () {
    var idfrom = getRandomInt(1,10000);
    http.get(`${baseUrl}/api/shipments?idfrom=${idfrom}`);
    sleep(1);
  }

function getRandomInt(min, max) {
    min = Math.ceil(min);
    max = Math.floor(max);
    return Math.floor(Math.random() * (max - min) + min); // The maximum is exclusive and the minimum is inclusive
  }

This script will use 100 virtual users for the duration of 3 minutes and will keep sending GET requests to the public endpoint /api/shipments?idfrom=<RandomId>

To invoke the script, open the command line and use the command below:

k6 run script.js

By now we’ve generated a load of data on every component within our simple microservices app, let’s start configuring Grafana Dashboard and exploring the metrics.

Configure Managed Grafana Dashboards

Step 1: Login to Managed Grafana Instance

Now we’ll use the Managed Grafa endpoint URL to login to Grafana, to get the endpoint URL you can use the command below:

az grafana show `
--name $GRAFANA_NAME `
--query properties.endpoint

Open the URL in the browser and login with a corporate account as Managed Grafana doesn’t support login with personal Microsoft accounts at the time of writing this post.

After you login successfully we need to Import a couple of Grafana dashboards. Grafana has more than 40 Azure Dashboards built by the community and some of them by Microsoft. You can explore Azure dashboards by clicking on this link.

In our case we are interested in 4 Dashboards as the below:

• Single Azure Container App view: https://grafana.com/grafana/dashboards/16592-azure-container-apps-container-app-view/
• Azure Container Apps Aggregate view: https://grafana.com/grafana/dashboards/16591-azure-container-apps-aggregate-view/
• Azure Storage account: https://grafana.com/grafana/dashboards/14469-azure-insights-storage-accounts/
• Azure Service Bus: https://grafana.com/grafana/dashboards/10533-azure-service-bus/

Importing the dashboards is a simple process, after you click on the Import menu item, you will be redirected to the below page

Provide the URL of the dashboard or the ID of the dashboard and click on the Load button. Once the metadata of the dashboard is loaded, you need to set the Datasource to Azure Monitor as in the image below, and then click on Import:

You need to do the same steps for the remaining 3 dashboards (Azure Service Bus, Azure Storage, and Container Apps aggregated view)

After you import the 4 dashboards, you can navigate to the Dashboards menu item, select Browse and you should see the 4 dashboards imported successfully as in the image below:

You can now select any of the dashboards and start seeing the beautiful visualization of metrics in one place, let’s check a snapshot of each dashboard when the system was under load:

Azure Service Bus Dashboard

Pay attention to the panel with the title Service Bus – Messages in Queue / Topic it represents the spike of messages when the console application was publishing a load of messages. There are many other useful panels you can explore.

Azure Storage Dashboard

Very useful panels to show for example the size of incoming data while the Backend Processor was writing processed messages to Table Storage, and the size of outgoing data when the same processor was serving read requests from the table storage.

Backend Processor Azure Container App Dashboard

Check the panel titled Replica Count and notice how 10 replicas are provisioned at the same time the Service Bus was receiving a load of messages, there are many other useful panels cush as Memory and Networks, etc.. which are not shown on this snapshot.

Frontend API Azure Container App Dashboard

Take a look at the panel titled Max Request Count which gives an indication of the number of inbound HTTP requests and how container apps started to scale up when there is a sudden increase in the HTTP requests count.

Azure Container Apps Aggregated View

Simple dashboard which will be useful if you have various Container Apps or Container Apps Environments, this dashboard will act as an entry point to access Container Apps.

Summary

As we saw in this post, Managed Grafana lets you bring together all your telemetry data into one place, you can customize dashboards the way you prefer and you can depend on community dashboards to help you get started. To know more about customization visit Grafana documentation.

Follow me on Twitter @tjoudeh

References:

• Featured Image Credit
• Create an Azure Managed Grafana instance using the Azure CLI
• Set up Azure Managed Grafana authentication and permissions
• Introducing Azure Managed Grafana for improving your Dynamics

The post Monitor Microservices App using Azure Managed Grafana appeared first on Bit of Technology.

• Tutorial for building Microservice Applications with Azure Container Apps and Dapr – Part 1
• Deploy backend API Microservice to Azure Container Apps – Part 2
• Communication between Microservices in Azure Container Apps – Part 3
• Dapr Integration with Azure Container Apps – Part 4
• Azure Container Apps State Store With Dapr State Management API – Part 5
• Azure Container Apps Async Communication with Dapr Pub/Sub API – Part 6
• Azure Container Apps with Dapr Bindings Building Block – Part 7
• Azure Container Apps Monitoring and Observability with Application Insights – Part 8
• Continuous Deployment for Azure Container Apps using GitHub Actions – Part 9
• Use Bicep to Deploy Dapr Microservices Apps to Azure Container Apps – Part 10
• Azure Container Apps Auto Scaling with KEDA – (This Post)
• Azure Container Apps Volume Mounts using Azure Files – Part 12
• Integrate Health probes in Azure Container Apps – Part 13

Azure Container Apps Auto Scaling with KEDA

In this post, we will explore how we can configure Auto Scaling rules in Container Apps. In my opinion, the Auto Scaling feature is one of the key features of any Serverless hosting platform, you want your application to respond dynamically based on the increased demand on workloads to maintain your system availability and performance.
Container Apps support Horizontal Scaling (Scaling Out) by adding more replicas (new instances of the Container App) and splitting the workload across multiple replicas to process the work in parallel. When the demand decrease, Container Apps will (Scale In) by removing the unutilized replicas according to your configured scaling rule. With this approach, you pay only for the replicas provisioned during the increased demand period, and you can as well configure the scaling rule to scale to Zero replicas, which means that no charges are incurred when your Container App scales to zero.

Azure Container Apps supports different scaling triggers as the below:

• HTTP traffic: Scaling based on the number of concurrent HTTP requests to your revision.
• CPU or Memory usage: Scaling based on the amount of CPU utilized or memory consumed by a replica.
• Azure Storage Queues: Scaling based on the number of messages in Azure Storage Queue.
• Event-driven using KEDA: Scaling based on events triggers, such as the number of messages in Azure Service Bus Topic or the number of blobs in Azure Blob Storage container.

As I covered in the initial posts, Azure Container Apps utilize different open source technologies, KEDA is one of them to enable event-driven autoscaling, which means that KEDA is installed by default when you provision your Container App, we should not worry about installing it. All we need to focus on is enabling and configuring our Container App scaling rules.

In this post, I will be focusing on event-driven autoscaling using KEDA.

The source code for this tutorial is available on GitHub. You can check the demo application too.

An overview of KEDA

KEDA stands for Kubernetes Event-Driven Autoscaler. It is an open-source project initially started by Microsoft and Red Hat to allow any Kubernetes workload to benefit from the event-driven architecture model. Prior to KEDA, horizontally scaling Kubernetes deployment was achieved through the Horizontal Pod Autoscaler (HPA). The HPA relies on resource metrics such as Memory and CPU to determine when additional replicas should be deployed. Within any enterprise application, there will be other external metrics we want to scale out our application based on, think of Kafka topic log, length of an Azure Service Bus Queue, or metrics obtained from a Prometheus query. KEDA offers more than 50 scalers to pick from based on your business need. KEDA exists to fill this gap and provides a framework for scaling based on events in conjunction with HPA scaling based on CPU and Memory.

Configure Scaling Rule in Backend Background Processer Project

We need to configure our Backend Background Processer named “tasksmanager-backend-processor” service to scale out and increase the number of replicas based on the number of messages in the Topic named “tasksavedtopic”. If our service is under a huge workload and our single replica is not able to cope with the number of messages on the topic, we need the Container App to spin up more replicas to parallelize the processing of messages on this topic.

So our requirements for scaling the backend processor are as follows:

• For every 10 messages on the Azure Service Bus Topic, scale-out by one replica.
• When there are no messages on the topic, scale-in to a Zero replica.
• The maximum number of replicas should not exceed 5.

To achieve this, we will start looking into KEDA Azure Service Bus scaler, This specification describes the azure-servicebus  trigger for Azure Service Bus Queue or Topic, let’s take a look at the below yaml file which contains a template for the KEDA specification:

triggers:
- type: azure-servicebus
  metadata:
    # Required: queueName OR topicName and subscriptionName
    queueName: functions-sbqueue
    # or
    topicName: functions-sbtopic
    subscriptionName: sbtopic-sub1
    # Optional, required when pod identity is used
    namespace: service-bus-namespace
    # Optional, can use TriggerAuthentication as well
    connectionFromEnv: SERVICEBUS_CONNECTIONSTRING_ENV_NAME # This must be a connection string for a queue itself, and not a namespace level (e.g. RootAccessPolicy) connection string [#215](https://github.com/kedacore/keda/issues/215)
    # Optional
    messageCount: "5" # Optional. Count of messages to trigger scaling on. Default: 5 messages
    cloud: Private # Optional. Default: AzurePublicCloud
    endpointSuffix: servicebus.airgap.example # Required when cloud=Private

Let’s review the parameters:

• The property type  is set to “azure-servicebus”, each KEDA scaler specification file has a unique type.
• One of the properties queueName  or topicName should be provided, in our case, it will be “topicName” and we will use the value “tasksavedtopic”.
• The property subscriptionName  will be set to use “tasksmanager-backend-processor” This represents the subscription associated with the topic. Not needed if we are using queues.
• The property connectionFromEnv  will be set to reference a secret stored in our Container App, we will not use the Azure Service Bus shared access policy (connection string) directly, the shared access policy will be stored in the Container App secrets, and the secret will be referenced here. Please note that the Service Bus Shared Access Policy needs to be of type Manage. It is required for KEDA to be able to get metrics from Service Bus and read the length of messages in the queue or topic.
• The property messageCount  is used to decide when scaling out should be triggered, in our case, it will be set to 10.
• The property cloud represents the name of the cloud environment that the service bus belongs to.

Note about authentication: KEDA scaler for Azure Service Bus supports different authentication mechanisms such as Pod Managed Identity, Azure AD Workload Identity, and shared access policy (connection string). When using KEDA with Azure Container Apps, at the time of writing this post, the only supported authentication mechanism is Connection Strings.

Azure Container Apps has its own proprietary schema to map KEDA Scaler template to its own when defining a custom scale rule, you can define this scaling rule via Container Apps ARM templates, yaml manifest, Azure CLI, or from Azure Portal. In this post, I will cover how to do it from the Azure Portal and Azure CLI.

Step 1: Create a new secret in Container App

Let’s now create a secret named “svcbus-connstring” in our Container App named “tasksmanager-backend-processor”, this secret will contain the value of Azure Service Bus shared access policy (connection string) with “Manage” policy. To do so, run the below commands in Azure CLI to get the connection string, and then add this secret using the second command:

##List Service Bus Access Policy RootManageSharedAccessKey
$RESOURCE_GROUP = "tasks-tracker-rg"
$NamespaceName = "tasksTracker"
az servicebus namespace authorization-rule keys list `
  --resource-group $RESOURCE_GROUP ` 
  --namespace-name $NamespaceName `
  --name RootManageSharedAccessKey `
  --query primaryConnectionString `
  --output tsv

##Create a new secret named 'svcbus-connstring' in backend processer container app
az containerapp secret set `
 --name $BACKEND_SVC_NAME `
 --resource-group $RESOURCE_GROUP `
 --secrets "svcbus-connstring=<Connection String from Service Bus>"

Step 2: Create a Custom Scaling Rule from Azure CLI

Now we are ready to add a new custom scaling rule to match the business requirements, to do so we need to run the below Azure CLI command:

Note: I had to update az containerapp  extension in order to create a scaling rule from CLI, to update it you can run the following command az extension update --name containerapp

az containerapp update `
  --name $BACKEND_SVC_NAME `
  --resource-group $RESOURCE_GROUP `
  --min-replicas 0 `
  --max-replicas 5 `
  --scale-rule-name "queue-length" `
  --scale-rule-type "azure-servicebus" `
  --scale-rule-auth "connection=svcbus-connstring" `  
  --scale-rule-metadata "topicName=tasksavedtopic" `
                          "subscriptionName=tasksmanager-backend-processor" `
                          "namespace=tasksTracker" `
                          "messageCount=10" `
                          "connectionFromEnv=svcbus-connstring"

What we have done is the following:

• Setting the minimum number of replicas to Zero, means that this Container App could be scaled-in to Zero replicas if there are no new messages on the topic.
• Setting the maximum number of replicas to 5, means that this Container App will not exceed more than 5 replicas regardless of the number of messages on the topic.
• Setting a friendly name for the scale rule “queue-length” which will be visible in Azure Portal.
• Setting the scare rule type to “azure-servicebus”, this is important to tell KEDA which type of scalers our Container App is configuring.
• Setting the authentication mechanism to type “connection” and indicating which secret reference will be used, in our case “svcbus-connstring”
• Setting the “metadata” dictionary of the scale rule, those matching the metadata properties in KEDA template we discussed earlier.

Once you run this command the custom scale rule will be created, we can navigate to the Azure Portal and see the details.

Step 3: Create a Custom Scaling Rule from the Azure Portal

Select your Container App named “tasksmanager-backend-processor” and navigate to the tab named “Scale”, select your minimum and maximum replica count, and then click on “Add Scale Rule”, set the values as below, and click on Save. This will create a new revision for the Container App with the scale rule applied.

Step 4: Run an end-to-end test and generate a load of messages

Now we are ready to test out our Azure Service Bus Scaling Rule, to generate a load of messages we can do this from Service Bus Explorer under our Azure Service Bus namespace, so navigate to Azure Service Bus, select your topic/subscription, and then select “Service Bus Explorer”.

The message structure our backend processor expects is as JSON below, so copy this message and click on Send messages button, paste the message content, set the content type to “application/json”, check the “Repeat Send” check box, select 500 messages and put an interval of 5 ms between them, click “Send” when you are ready.

{
    "data": {
        "isCompleted": false,
        "isOverDue": false,
        "taskAssignedTo": "temp@mail.com",
        "taskCreatedBy": "Readiness Prob",
        "taskCreatedOn": "2022-08-18T12:45:22.0984036Z",
        "taskDueDate": "2022-08-19T12:45:22.0983978Z",
        "taskId": "6a051aeb-f567-40dd-a434-39927f2b93c5",
        "taskName": "Health Readiness Task"
    }
}

Step 5: Verify that multiple replicas are created

If all is setup correctly, 5 replicas will be created based on the number of messages we generated into the topic, there are various ways to verify this:

• You can verify this by looking into the “Live Metrics” within Application Insights, you will see instantly that there are 5 “tasksmanager-backend-processor” provisioned to work in parallel and consume the messages:

• You can verify this from Container Apps “Console” tab you will see those replicas in the drop-down list:

• You can use the below Azure CLI command to list the names of replicas:

##Query Number & names of Replicas
  az containerapp replica list `
    --name $BACKEND_SVC_NAME `
    --resource-group $RESOURCE_GROUP `
    --query [].name

Note about KEDA Scale In:

Container Apps implements the KEDA ScaledObject with the following default settings:

• pollingInterval: 30 seconds. This is the interval to check each trigger on. By default, KEDA will check each trigger source on every ScaledObject every 30 seconds.
• cooldownPeriod: 300 seconds. The period to wait after the last trigger is reported active before scaling in the resource back to 0. By default, it’s 5 minutes (300 seconds).

Currently, there is no way to override this value, yet there is an open issue on the Container Apps repo and the PG is tracking it, 5 minutes might be a long period to wait for instances to be scaled in after they finish processing messages.

That’s it for now, hopefully, you find KEDA framework easy to work with to scale your Container Apps.

The source code for this tutorial is available on GitHub. You can check the demo application too.

Follow me on Twitter @tjoudeh

References:

• Scaling Container Apps
• Set scaling rules in Azure Container Apps
• Scaling Deployments, StatefulSets & Custom Resources
• Featured Image Credit

The post Azure Container Apps Auto Scaling with KEDA – Part 11 appeared first on Bit of Technology.

• Tutorial for building Microservice Applications with Azure Container Apps and Dapr – Part 1
• Deploy backend API Microservice to Azure Container Apps – Part 2
• Communication between Microservices in Azure Container Apps – Part 3
• Dapr Integration with Azure Container Apps – Part 4
• Azure Container Apps State Store With Dapr State Management API – Part 5
• Azure Container Apps Async Communication with Dapr Pub/Sub API – Part 6
• Azure Container Apps with Dapr Bindings Building Block – Part 7
• Azure Container Apps Monitoring and Observability with Application Insights – Part 8
• Continuous Deployment for Azure Container Apps using GitHub Actions – Part 9
• Use Bicep to Deploy Dapr Microservices Apps to Azure Container Apps – (This Post)
• Azure Container Apps Auto Scaling with KEDA – Part 11
• Azure Container Apps Volume Mounts using Azure Files – Part 12
• Integrate Health probes in Azure Container Apps – Part 13

Use Bicep to Deploy Dapr Microservices Apps to Azure Container Apps

In the previous post we’ve used GitHub Actions to continuously build and deploy the 3 Azure Container Apps after any code commits to a specific branch, on this post we will be working on defining the proper process to automate the infrastructure provisioning by creating the scripts/templates to provision the resources, this process is known as IaC (Infrastructure as Code).

Once we have this in place, IaC deployments will benefit us in key ways such as:

1. Increase confidence in the deployments, ensure consistency, reduce human error in resource provisioning, and ensure consistent deployments.
2. Avoid configuration drifts, IaC is an idempotent operation, which means it provides the same result each time it’s run.
3. Provision of new environments, during the lifecycle of the application you might need to run penetration testing or load testing for a short period of time in a totally isolated environment, with IaC in place it will be a matter of executing the scripts to recreate an identical environment to the production one.
4. When you provision resources from the Azure Portal many processes are abstracted, in our case think of when creating an Azure Container Apps Environment from the portal, behind the sense it will create a log analytics workspace and associate with the environment. With IaC it can help provide a better understanding of how Azure works and how to troubleshoot issues that might arise.

ARM Templates in Azure

ARM templates are files that define the infrastructure and configuration for your deployment, the template uses declarative syntax, which lets you state what you intend to deploy without having to write the sequence of programming commands to create it.

Within Azure there are 2 ways to create IaC, we can use the JSON ARM templates or Bicep (domain-specific language). From my personal experience, I’ve used JSON ARM templates in real-world scenarios which tend to be complex to manage and maintain especially when the project grows and the number of components and dependencies increases.

For Bicep, this is my first time to use it, so far I found it easier to work with and you can be more productive compared to ARM templates, it is worth mentioning that Bicep code will be compiled into ARM templates eventually, this process called “Transpilation”.

If you want to learn more about Bicep, I highly recommend checking Microsft learn website Fundamentals of Bicep and the post Getting started with Azure Bicep by Tobias Zimmergren

The source code for this tutorial is available on GitHub. You can check the demo application too.

Creating the Infrastructure as Code using Bicep

Lets’ get started by defining the Bicep modules needed to create the Infstatrcure code, what we want to achieve by the end of this post is to have a new resource group containing all the resources and configuration (connection strings, secrets, env variables, dapr components, etc..) we used to build our solution, we should have a new resource group which contains the below resources.

Step 1: Add the needed extension to VS Code Or Visual Studio

If you are using VS Code, you need to install an extension named “Bicep“, and if you are using Visual Studio, PG team announced the release of Bicep extension for Visual Studio version 17.3 and higher, you can get it from here. Both extensions will simplify building Bicep files as they will offer IntelliSense, Validation, listing all available resource types, etc..

Step 2: Define an Azure Log Analytics Workspace

Add a new folder named “deploy” on the root project directory then add a new file named “logAnalyticsWorkspace.bicep”, use the content below:

param logAnalyticsWorkspaceName string
param location string = resourceGroup().location

resource logAnalyticsWorkspace'Microsoft.OperationalInsights/workspaces@2021-06-01' = {
  name: logAnalyticsWorkspaceName
  location: location
  properties: any({
    retentionInDays: 30
    features: {
      searchVersion: 1
    }
    sku: {
      name: 'PerGB2018'
    }
  })
}

output workspaceResourceId string = logAnalyticsWorkspace.id
output logAnalyticsWorkspaceCustomerId string = logAnalyticsWorkspace.properties.customerId
//Do not use outputs to return secrets, we will use a different way
//var sharedKey = listKeys(logAnalyticsWorkspace.id, logAnalyticsWorkspace.apiVersion).primarySharedKey
//output logAnalyticsWorkspacePrimarySharedKey string = sharedKey

This module takes 2 input parameters “logAnalyticsWorkspaceName” and “location”, the location defaults to the container resource group location. Bicep has a function named resourceGroup() which you can get the location from, yet you can override this default value if you provided the location when calling this module.

The output of this module is 2 parameters, first one is “workspaceResourceId” and the second one is “logAnalyticsWorkspaceCustomerId” both outputs are needed as input for the Azure Container Apps Environment and Application Insights resource which we will provision next.

Important note: You can see that I left a commented code on how to return the secret/shared key using outputs, this was the initial way I followed but it turned out it is not secure as those outputs will be available on the deployment level (when viewing the Resource Group Deployment section) in Azure Portal in plain text, so anyone has access to the resource group will see those keys and secrets.
I will be using a different approach to return the secrets from modules. Keep reading to see how. You can read more about the 2 possible approaches on the official documentation.
In my personal opinion, I wished there is a “@Secure” param we can put on the output parameters to keep things modular. There is a GitHub issue opened and hopefully, PG will add it.

Step 3: Define an Azure Application Insights resource

Add a new file named “appInsights.bicep” under the folder “deploy” and use the content below:

param location string = resourceGroup().location
param workspaceResourceId string 
param appInsightsName string

resource appInsights 'Microsoft.Insights/components@2020-02-02' = {
  name: appInsightsName
  location: location
  kind: 'web'
  properties: {
    Application_Type: 'web'
    WorkspaceResourceId:workspaceResourceId
  }
}

//Do not use output params to pass keys for other resources
//output appInsightsInstrumentationKey string = appInsights.properties.InstrumentationKey

This module accepts 3 parameters, the “location”, and “workspaceResourceId “, and “appInsightsName”, we are associating the log analytics workspace with this Application Insights resource by setting the property “WorkspaceResourceId”

Step 4: Define an Azure Container Apps Environment resource

Add a new file named “acaEnvironment.bicep” under the folder “deploy” and use the content below:

param acaEnvironmentName string
param location string = resourceGroup().location
@secure()
param instrumentationKey string
param logAnalyticsWorkspaceCustomerId string
@secure()
param logAnalyticsWorkspacePrimarySharedKey string 

resource environment 'Microsoft.App/managedEnvironments@2022-03-01' = {
  name: acaEnvironmentName
  location: location
  properties: {
    daprAIInstrumentationKey:instrumentationKey
    appLogsConfiguration: {
      destination: 'log-analytics'
      logAnalyticsConfiguration: {
        customerId: logAnalyticsWorkspaceCustomerId
        sharedKey: logAnalyticsWorkspacePrimarySharedKey
      }
    }
  }
}

output acaEnvironmentId string = environment.id

This module accepts 5 input parameters, mainly those to associate the log analytics workspace with the Environment and set the Application Insights Key for dapr distributed calls tracing and telemetry. This module outputs the Container App Environment Id as an output parameter which will be used when defining the 3 Azure Container Apps. More about the “@secure” attribute below.

Step 5: Define Azure CosmosDB resources

We will start defining the supporting resources needed for our solution, we will start defining the module needed to provision Azure Cosmos Account, Database, and Container, to do so, add a new file named “cosmosdb.bicep” and use the content below:

@description('Cosmos DB account name, max length 44 characters, lowercase')
param accountName string 

@description('Location for the Cosmos DB account.')
param location string = resourceGroup().location

@description('The primary replica region for the Cosmos DB account.')
param primaryRegion string

@description('The default consistency level of the Cosmos DB account.')
@allowed([
  'Eventual'
  'ConsistentPrefix'
  'Session'
  'BoundedStaleness'
  'Strong'
])
param defaultConsistencyLevel string = 'Session'

@description('The name for the database')
param databaseName string = 'tasksmanagerdb'

@description('The name for the container')
param containerName string = 'taskscollection'

var accountName_var = toLower(accountName)
var consistencyPolicy = {
  Eventual: {
    defaultConsistencyLevel: 'Eventual'
  }
  ConsistentPrefix: {
    defaultConsistencyLevel: 'ConsistentPrefix'
  }
  Session: {
    defaultConsistencyLevel: 'Session'
  }
  BoundedStaleness: {
    defaultConsistencyLevel: 'BoundedStaleness'
    maxStalenessPrefix: 100000
    maxIntervalInSeconds: 300
  }
  Strong: {
    defaultConsistencyLevel: 'Strong'
  }
}
var locations = [
  {
    locationName: primaryRegion
    failoverPriority: 0
    isZoneRedundant: false
  }
]

resource databaseAccount 'Microsoft.DocumentDB/databaseAccounts@2021-01-15' = {
  name: accountName_var
  kind: 'GlobalDocumentDB'
  location: location
  properties: {
    consistencyPolicy: consistencyPolicy[defaultConsistencyLevel]
    locations: locations
    databaseAccountOfferType: 'Standard'
  }
}

resource accountName_databaseName 'Microsoft.DocumentDB/databaseAccounts/sqlDatabases@2021-01-15' = {
  parent: databaseAccount
  name: databaseName
  properties: {
    resource: {
      id: databaseName
    }
  }
}

resource accountName_databaseName_containerName 'Microsoft.DocumentDB/databaseAccounts/sqlDatabases/containers@2021-01-15' = {
  parent: accountName_databaseName
  name: containerName
  properties: {
    resource: {
      id: containerName
      partitionKey: {
        paths: [
          '/partitionKey'
        ]
        kind: 'Hash'
      }
    }
    options: {
      autoscaleSettings: {
        maxThroughput: 4000
      }
    }
  }
}

output documentEndpoint string = databaseAccount.properties.documentEndpoint
// Do not use output param for returning cosmos db master key
//var primaryMasterKeyValue = listKeys(accountName_resource.id, accountName_resource.apiVersion).primaryMasterKey
//output primaryMasterKey string = primaryMasterKeyValue

On this file, we are creating Azure Cosmos Account, Database, and a Collection, I’m defaulting the names of Database and Collection to use the same names we’ve previously used in the tutorial, but we are going to send a different Cosmos Account. For full details on Cosmos DB Bicep module parameters, you can check it here.

Step 6: Define Azure Service Bus resource

Add a new file named “serviceBus.bicep” under the folder “deploy” and use the content below:

@description('The location where we will deploy our resources to. Default is the location of the resource group')
param location string = resourceGroup().location

@description('The name of the service bus namespace')
param serviceBusName string

var topicName = 'tasksavedtopic'

resource serviceBus 'Microsoft.ServiceBus/namespaces@2021-11-01' = {
  name: serviceBusName
  location: location
  sku: {
    name: 'Standard'
  }
}

resource topic 'Microsoft.ServiceBus/namespaces/topics@2021-11-01' = {
  name: topicName
  parent: serviceBus
}

//var listKeysEndpoint = '${serviceBus.id}/AuthorizationRules/RootManageSharedAccessKey'
//var sharedAccessKey = '${listKeys(listKeysEndpoint, serviceBus.apiVersion).primaryKey}'
//var connectionStringValue = 'Endpoint=sb://${serviceBus.name}.servicebus.windows.net/;SharedAccessKeyName=RootManageSharedAccessKey;SharedAccessKey=${sharedAccessKey}'
//output connectionString string = connectionStringValue

This module will be needed to provision the Azure Service Bus and a Topic named “tasksavedtopic” by default. The connection string of the service bus will be returned in a different way, not like the commented code.

Step 7: Define Azure Storage Account resource

Add a new file named “storageAccount.bicep” under the folder “deploy” and use the content below:

param storageAccountName string
param location string = resourceGroup().location

var externalTasksQueueName = 'external-tasks-queue'

resource storageAccount 'Microsoft.Storage/storageAccounts@2021-09-01' = {
  name: storageAccountName
  location: location
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
}

resource storageQueues 'Microsoft.Storage/storageAccounts/queueServices@2021-09-01' = {
  name: 'default'
  parent: storageAccount
}

resource external_queue 'Microsoft.Storage/storageAccounts/queueServices/queues@2021-09-01' = {
  name: externalTasksQueueName
  parent: storageQueues
}

//var storageAccountKeyValue = storageAccount.listKeys().keys[0].value
//output storageAccountKey string = storageAccountKeyValue

This module will be needed to provision an Azure Storage Account and a queue named “external-tasks-queue”.

Step 8: Define Azure Container Apps module

Now we will create a reusable Bicep module which will be used to define the 3 Azure Container Apps in our solution, so add a new file named “containerApp.bicep” and use the content below:

param containerAppName string
param location string = resourceGroup().location
param environmentId string 
param containerImage string
param targetPort int
param isExternalIngress bool
param containerRegistry string
param containerRegistryUsername string
param isPrivateRegistry bool
param enableIngress bool 
param registryPassName string
param minReplicas int = 0
param maxReplicas int = 1
@secure()
param secListObj object
param envList array = []
param revisionMode string = 'Single'
param useProbes bool = false

resource containerApp 'Microsoft.App/containerApps@2022-03-01' = {
  name: containerAppName
  location: location
  properties: {
    managedEnvironmentId: environmentId
    configuration: {
      activeRevisionsMode: revisionMode
      secrets: secListObj.secArray
      registries: isPrivateRegistry ? [
        {
          server: containerRegistry
          username: containerRegistryUsername
          passwordSecretRef: registryPassName
        }
      ] : null
      ingress: enableIngress ? {
        external: isExternalIngress
        targetPort: targetPort
        transport: 'auto'
        traffic: [
          {
            latestRevision: true
            weight: 100
          }
        ]
      } : null
      dapr: {
        enabled: true
        appPort: targetPort
        appId: containerAppName
        appProtocol: 'http'
      }
    }
    template: {
      containers: [
        {
          image: containerImage
          name: containerAppName
          env: envList
          probes: useProbes? [
            {
              type: 'Readiness'
               httpGet: {
                 port: 80
                 path: '/api/health/readiness'
                  scheme: 'HTTP'
               }
              periodSeconds: 240
               timeoutSeconds: 5
               initialDelaySeconds: 5
                successThreshold: 1
                failureThreshold: 3
            }
          ] : null
        }
      ]
      scale: {
        minReplicas: minReplicas
        maxReplicas: maxReplicas
      }
    }
  }
}

output fqdn string = enableIngress ? containerApp.properties.configuration.ingress.fqdn : 'Ingress not enabled'

The Azure Container Apps module is reusable and almost accepts input parameters for all Azure Container Apps properties, we will be using it to provision the 3 container apps. The output parameter of this module is the fully qualified domain name (FQDN) of the container app if the “enableIngress” property is set to true.

Notice how conditional boolean parameters such as “useProbes”, or “enableIngress” control how the template will be provisioned differently based on those values.

The property “envList” is an array that accepts a dictionary of environment variables, we will see how we are sending those values next.

The property “secListObj” is an object with a “@secure” attribute his attribute can be applied on string and object parameters that might contain secret values, when it is used Azure won’t make the parameter values available in the deployment logs nor on the terminal if you are using Azure CLI.

Step 9: Define the Main module for the solution

Lastly, we need to define the Main Bicep module which will link all other modules together, this will be the file that is referenced from AZ CLI command or GitHub action when creating the entire resources, to do so add a new file named “main.bicep”, I will not list the file content here as it is more than 500 lines but I will go over it step by step, you can always get the file from GitHub repo. The file “main.bicep” can be accessed from the previous link.

What we have added to the file is the following:

• We have defined many parameters to make the deployment flexible, yet we default most of them, this means that there is no need to provide values for the defaulted ones. The only mandatory parameters are “containerRegistryPassword ” and “sendGridApiKey“.
• We used the attribute “@secure” on the properties “containerRegistryPassword” and “sendGridApiKey” as those are secrets and should not be logged or visible when typing them in Azure CLI.
• We are calling the modules defined earlier “cosmosdb.bicep”, “serviceBus.bicep”, “storageAccount.bicep”, “logAnalyticsWorkspace.bicep”, and then “appInsights.bicep” by bundling them in 1 single module named “primaryResources.bicep”.
• We want to get the secrets, keys, and connection strings from the resources without using the output parameter, so we are going to use the existing keyword to obtain a strongly typed reference to the pre-created resource. Then use the listKeys() function to obtain the key or connection string.
  For example, let’s take a look at how we are getting a reference for the Application Insights Resource by providing its name as an input, then using the resource named “appInsightsResource” to get the InstrumentationKey by calling “appInsightsResource.properties.InstrumentationKey“.
• Looking at how we are creating the Azure Container App “Backend API App” using the module “containerApp.bicep” we notice the following:
  • We are setting the array “dependsOn” to help the Bicep interpreter to understand the dependencies between components, this is not needed if we are not using the “existing” keyword.
  • We are passing various mandatory parameters for Azure Container Apps, we are getting the value of “environmentId” from the output parameter defined in ACA Environment.
  • We are passing the needed information to access the ACR to pull the right image for each ACA. We will pass the registry password from Azure CLI.
  • We are passing the property “secListObj” by adding secrets to a dictionary named “secArray”, we did this because @secure attribute is only applicable on strings and objects, so this is a workaround to do this by creating an object which wraps an array. Thanks Alex for the hint.
• Looking at one of the Dapr components, for example, “stateStoreDaprComponent” you will notice the following:
  • Setting the component name while prefixing it with ACA environment name “${environmentName}/statestore” (Parent/Child) relation in Bicep.
  • Setting “secrets”, “metadata” and “scopes” dictionaries of this component in a consistent way among all other Dapr components.

Step 10: Calling the main.bicep file from Azure CLI and deploy the Infrastructure

Now we are ready to start the actual deployment by calling az deployment group create to do so, open the PowerShell console and use the content below, don’t forget to replace the “containerRegistryPassword” and SendGrid API key with your values. You need to create an empty resource group before. I’m using a resource group named “tasks-bicep-rg”:

az group create `
    --name "tasks-bicep-rg" `
    --location "eastus"  

az deployment group create `
   --resource-group "tasks-bicep-rg" `
   --template-file ./deploy/main.bicep `
   --parameters '{ \"containerRegistryPassword\": {\"value\":\"XXXX\"}, \"sendGridApiKey\": {\"value\":\"SG.XXXXX\"} }'

Azure CLI will take the Bicep module, and start creating the deployment in the resource group “tasks-bicep-rg”

Step 11: Verify the final results

If the deployment succeeded; you should see all the resources created under the resource group, as well you can navigate to the “Deployments” tab to verify the ARM templates deployed, it should look like the below image:

That’s it for now, Bicep is a quite powerful DSL language to manage your Infrastructure, I highly recommend checking the reference below to get more familiar with Bicep and IaC.

References:

• Fundamentals of Bicep
• How to deploy Azure Container Apps with Bicep by Thorsten Hans

The source code for this tutorial is available on GitHub. You can check the demo application too.

Follow me on Twitter @tjoudeh

The post Use Bicep to Deploy Dapr Microservices Apps to Azure Container Apps – Part 10 appeared first on Bit of Technology.

• Tutorial for building Microservice Applications with Azure Container Apps and Dapr – Part 1
• Deploy backend API Microservice to Azure Container Apps – Part 2
• Communication between Microservices in Azure Container Apps – Part 3
• Dapr Integration with Azure Container Apps – Part 4
• Azure Container Apps State Store With Dapr State Management API – Part 5
• Azure Container Apps Async Communication with Dapr Pub/Sub API – Part 6
• Azure Container Apps with Dapr Bindings Building Block – Part 7
• Azure Container Apps Monitoring and Observability with Application Insights – Part 8
• Continuous Deployment for Azure Container Apps using GitHub Actions – (This Post)
• Use Bicep to Deploy Dapr Microservices Apps to Azure Container Apps – Part 10
• Azure Container Apps Auto Scaling with KEDA – Part 11
• Azure Container Apps Volume Mounts using Azure Files – Part 12
• Integrate Health probes in Azure Container Apps – Part 13

Continuous Deployment for Azure Container Apps using GitHub Action

In the previous posts, you noticed that with every change in the source code on any of the 3 services, we have to build the applications locally, create a new image and push it to ACR by calling CLI command manually, and then we use another CLI command az containerapp update to create a new Revision of the subject Container App and publish it.

This will be a tedious process and might create issues if multiple developers are working on the same repository and they keep updating the remote resources manually from their machines.

To enhance this process we will rely on GitHub Actions to automate the build and deploy process for the 3 services, the process will be as the following:

1. A code change is done on one of the projects, and a commit is pushed to a certain branch of our GitHub repository.
2. GitHub action is triggered which updates the container image in the container registry. We will have a dedicated GitHub action for each project.
3. Once the container is updated in the registry, Azure Container Apps creates a new revision based on the updated container image.

The source code for this tutorial is available on GitHub. You can check the demo application too.

Configure GitHub actions to connect to Azure

We need to allow our GitHub repository (GitHub actions) to connect to the Azure subscription and the resource group which hosts our  3 services, there are multiple ways to do this but we are going to use the Azure login action with a service principal secret approach.

To do so from the Azure CLI, run the command below, you need to replace the values of Subscription ID and Resource Group to match your deployment.

$SERVICE_PRINCIPAL_NAME="TasksTrackerSP"
$SUBSCRIPTION_ID="<use your subscription id value>"
$RESOURCE_GROUP="tasks-tracker-rg"

az ad sp create-for-rbac `
  --name "$SERVICE_PRINCIPAL_NAME" `
  --role "contributor" `
  --scopes "/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$RESOURCE_GROUP" `
  --sdk-auth

After running this command, the output will be similar to the JSON below, you need to copy this JSON as we are using it in the next step.

{
  "clientId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx",
  "clientSecret": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
  "subscriptionId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx",
  "tenantId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx",
  "activeDirectoryEndpointUrl": "https://login.microsoftonline.com",
  "resourceManagerEndpointUrl": "https://management.azure.com/",
  "activeDirectoryGraphResourceId": "https://graph.windows.net/",
  "sqlManagementEndpointUrl": "https://management.core.windows.net:8443/",
  "galleryEndpointUrl": "https://gallery.azure.com/",
  "managementEndpointUrl": "https://management.core.windows.net/"
}

Add Action Secrets to GitHub Repository

Step 1: Create credentials for Azure

Now we need to create a couple of secrets that will be used by the GitHub actions, to do so, from the GitHub portal, navigate to your repository select “Settings”,  select “Secrets”, then “Actions”. Click on “New Secret Repository”.

As the image below, name your secret “TASKSMANAGER_AZURE_CREDENTIALS” and paste the JSON from the previous step, you need to include the properties “clientId”, “clientSecret”, “subscriptionId”, and “tenantId”, other properties in JOSN can be eliminated.

{ 
  "clientId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx", 
  "clientSecret": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx", 
  "subscriptionId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx", 
  "tenantId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx"
}

Step 2: Create credentials for Azure Container Registry

We need to create 2 more GitHub action secrets to store the ACR username and password to allow us to build, push, and pull images inside the GitHub action.

To get the username and password for ACR, run the below command in Azure CLI, you can get them from Azure Portal too.

az acr credential show -n $ACR_NAME

As the step above, we will create new secrets named “TASKSMANAGER_REGISTRY_USERNAME” and “TASKSMANAGER_REGISTRY_PASSWORD” and you put the right values accordingly and save them. You should have 3 actions secrets as in the image below:

Create GitHub Action for Backend Web API service

We will start now defining the first GitHub action for the project named “TasksTracker.TasksManager.Backend.Api”, we will have a dedicated GitHub action for each service, so if a change happened to one of the services, there is no need to trigger action and do a re-deploy the service for the unchanged ones.

Next, create a new folder named “.github/workflows” on the root project directory and add a new file named “build-deploy-backend-api.yaml”, use the content below:

name: tasksmanager-backend-api deployment

# When this action will be executed
on:
  # Automatically trigger it when detected changes in repo
  push:
    branches: 
      [ dev ]
    paths:
    - 'TasksTracker.TasksManager.Backend.Api/**'
    - '.github/workflows/build-deploy-backend-api.yaml'

  # Allow mannually trigger 
  workflow_dispatch:      

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout to the branch
        uses: actions/checkout@v2

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v1

      - name: Log in to container registry
        uses: docker/login-action@v1
        with:
          registry: taskstrackeracr.azurecr.io
          username: ${{ secrets.TASKSMANAGER_REGISTRY_USERNAME }}
          password: ${{ secrets.TASKSMANAGER_REGISTRY_PASSWORD }}

      - name: Build and push container image to registry
        uses: docker/build-push-action@v2
        with:
          push: true
          tags: taskstrackeracr.azurecr.io/tasksmanager-backend-api:${{ github.sha }} , taskstrackeracr.azurecr.io/tasksmanager-backend-api:latest
          file: TasksTracker.TasksManager.Backend.Api/Dockerfile
          context: ./.


  deploy:
    runs-on: ubuntu-latest
    needs: build
    
    steps:
      - name: Azure Login
        uses: azure/login@v1
        with:
          creds: ${{ secrets.TASKSMANAGER_AZURE_CREDENTIALS }}


      - name: Deploy to containerapp
        uses: azure/CLI@v1
        with:
          inlineScript: |
            az config set extension.use_dynamic_install=yes_without_prompt
            az containerapp registry set -n tasksmanager-backend-api -g tasks-tracker-rg --server taskstrackeracr.azurecr.io --username  ${{ secrets.TASKSMANAGER_REGISTRY_USERNAME }} --password ${{ secrets.TASKSMANAGER_REGISTRY_PASSWORD }}
            az containerapp update -n tasksmanager-backend-api -g tasks-tracker-rg --image taskstrackeracr.azurecr.io/tasksmanager-backend-api:${{ github.sha }}

Let’s review what we added to this yaml file:

• Line 1: Setting the name “tasksmanager-backend-api deployment”  for the GitHub action.
• Lines 4-8 Configure the action to be triggered when a change happens on the branch ‘dev’, if you are using a different branch name you can update this value.
• Lines 9 -10: Specify that any change on the files under the path “TasksTracker.TasksManager.Backend.Api” will trigger this action, this is very important to control that changes on this subject service will trigger this action, we want to avoid for example changes that happen on the UI project to trigger this action.
• Line 11: Specify that any change on the yaml file “build-deploy-backend-api.yaml” for this action will trigger the action.
• Line 14: Enabled manual trigger for the action (this might be needed to trigger the action without any change on code).
• Lines 16 -19: Specify that the latest Ubuntu agent will be used to run the action.
• Lines 20 – 40: Specify what we actually want to happen within our GitHub action (what jobs), we are going to add to our build process
  • Lines 21-22: Check out our repository so our GitHub action can access it.
  • Lines 24-25: Using the Builder, this action uses BuildKit under the hood through a simple Buildx action.
  • Lines 27-32: Login to Azure Container Registry using the Username and Password created in GitHub actions secrets.
  • Lines 34-40: Action to build Docker image and push to ACR, notice that we are creating 2 tags when pushing, one with tag “latest” and the other one will contain the “Commit SHA that triggered the workflow”.
• Lines 48-51 Login to Azure subscription using the credentials stored in GitHub action secrets.
• Lines 54- 60: Use Azure CLI to do the actual deployment/update for the Azure Container App and deploy a new revision.

Note: you need to do the same and create another 2 new GitHub actions for the project “TasksTracker.Processor.Backend.Svc” and project “TasksTracker.WebPortal.Frontend.Ui“, the GitHub action files are in the links.

With this in place, you can commit your work and notice that the GitHub action is triggered, if all is configured correctly you should see the results in the GitHub Actions workflows tab as well the Azure App Service should be updated with a new revision.

Note: Azure Container Apps has support from the Azure Portal or via Azure CLI commands “az containerapp github-action” to set up this continuous deployment, I preferred to do it manually from scratch to understand what is happening under the hood, as well with the built-in approach you need to create a GitHub PAT to allow Azure to access GitHub and setup the GitHub action workflows, another secret that you want to maintain

In the next post, we will be implementing using Bicep templates to create the entire environment, and resources from scratch, this will be useful if you want to provision a new test or staging environment for example. Stay tuned!

The source code for this tutorial is available on GitHub. You can check the demo application too.

Follow me on Twitter @tjoudeh

The post Continuous Deployment for Azure Container Apps using GitHub Actions – Part 9 appeared first on Bit of Technology.

• Tutorial for building Microservice Applications with Azure Container Apps and Dapr – Part 1
• Deploy backend API Microservice to Azure Container Apps – Part 2
• Communication between Microservices in Azure Container Apps – Part 3
• Dapr Integration with Azure Container Apps – Part 4
• Azure Container Apps State Store With Dapr State Management API – Part 5
• Azure Container Apps Async Communication with Dapr Pub/Sub API – Part 6
• Azure Container Apps with Dapr Bindings Building Block – Part 7
• Azure Container Apps Monitoring and Observability with Application Insights – (This Post)
• Continuous Deployment for Azure Container Apps using GitHub Actions – Part 9
• Use Bicep to Deploy Dapr Microservices Apps to Azure Container Apps – Part 10
• Azure Container Apps Auto Scaling with KEDA – Part 11
• Azure Container Apps Volume Mounts using Azure Files – Part 12
• Integrate Health probes in Azure Container Apps – Part 13

Azure Container Apps Monitoring and Observability with Application Insights

When building a microservices application that consists of many distributed services that communicate with each other across different processes and use different infrastructure services (different message brokers, different databases, different 3rd party components, etc…) then having a mechanism to observe and trace from end to end is inevitable.

The good news that Azure Container Apps provides various built-in Monitoring and Observability features that help in understanding how are the various services are operating and performing. Those features will help to monitor and diagnose the state of your distributed services to improve performance and respond to critical problems.

The Azure Container Apps official documentation page talks thoroughly about observability features, so I will not cover them here.
From my personal experience while building this tutorial and during the development and test phases, the 2 features I relied on most were the Log streaming and Azure Monitor Log Analytics.

The official documentation page didn’t talk about how to configure Azure Container Apps and Azure Container Apps Environment with Application Insights, as well Azure Container Apps do not support Auto-Instrumentation for Application Insights, so in this post, I will be focusing on how we can integrate Application Insights into our microservices application.

The source code for this tutorial is available on GitHub. You can check the demo application too.

Application Insights overview

Application Insights is an offering from Azure Monitor that will help us to monitor all Azure Container Apps under the same Container App Environment and collect telemetry about the services within the solution, as well as understand the usage of the services and users’ engagement via integrated analytics tools.
What I mean by Telemetry here is the data collected to observe our application, it can be broken into three categories :

1. Distributed Tracing: provides insights into the traffic between services involved in distributed transactions, think of when the Frontend Web App talks with the Backend Api App to insert or retrieve data. An application map of how calls are flowing between services is very important for any distributed application.
2. Metrics: provide insights into the performance of a service and its resource utilization, think of the CPU and Memory utilization of the Backend Background processor, and how we can understand when we need to increase the number of replicas.
3. Logging: provides insights into how code is executing and if errors have occurred.

So let’s get started and add Application Insights to our solution.

Provision a Workspace-based Application Insights Instance

We need to create one single Application Insights instance to be used for all the services telemetry within our application, to create the instance using Azure CLI script below:

## install the application-insights extension for the CLI
  az extension add -n application-insights
  
  ## Workspace crreated when creating Azure Container Apps Env
  $workspace = "/subscriptions/<SubscriptionId>/resourcegroups/<RsourceGroup>/providers/microsoft.operationalinsights/workspaces/<WorkSpaceName>"
  
  ##Create Application Insights instance
  $ai = $(az monitor app-insights component create -g $RESOURCE_GROUP -l $Location --app $taskstracker-ai --workspace $workspace)  | ConvertFrom-Json
  
  ## Get APPINSIGHTS INSTRUMENTATIONKEY
  $APPINSIGHTS_INSTRUMENTATIONKEY=$($ai.InstrumentationKey)

We are creating here a Workspace-based Application Insights resource as the “Classic” one will be out of support in 2024. So we are going to use the same Workspace we created when we provisioned the Azure Container App Environment in this previous post.

Next, we need to update the Azure Container App Environment we have created in this previous post, if you remember we used the CLI command az containerapp env create  (link for command properties) as the below script to create the Environment:

az containerapp env create `
  --name $ENVIRONMENT `
  --resource-group $RESOURCE_GROUP `
  --location $LOCATION

You can see that we didn’t provide the property --dapr-instrumentation-key when creating it, and unfortunately we can’t update this from the Azure CLI, there is an open issue on GitHub asking to add support for updating the Azure Container Apps Environment via the CLI.
So my recommendation is to set the property “dapr-instrumentation-key” when creating the ACA Environment as it is the property responsible for setting the instrumentation key of the Application Insights instance used by Dapr to export Service to Service communication telemetry, without it you will not be able to see the relation between microservices.

In our case we need to do the update, in order to do this we are going to use Bicep/ARM template, I’m going to cover in the future post in full detail how we are going to use Bicep to provision every component in the solution including the external components such as Azure Storage, Cosmos DB, Service bus, etc… it will be a detailed post to show you how Bicep will simplify the creation of Infrastructure as a Code (IaC) and will enable you to create and redeploy the entire solution with all configuration we have done manually by executing one command or running 1 single action from GitHub actions.

For this post, I will keep the description minimal so follow along with me to create a simple Bicep file used to update the Azure Container Apps Environment, to do so, from VS code add a new folder named “deploy” on the same root folder of our solution “TasksTracker.ContainerApps/deploy” and then add a new file named “updateacaEnvironment.bicep”.
You need to install a VS code extension named Bicep, so go ahead and install it as we are going to use it heavily in the next post.
Now open the file named “updateacaEnvironment.bicep” and paste the code below

param location string = resourceGroup().location
param environmentName string = 'tasks-tracker-containerapps-env'
param appInsightsName string = 'taskstracker-ai'
param logAnalyticsWorkspaceName string ='workspace-taskstrackerrgRItW'

resource appInsights 'Microsoft.Insights/components@2020-02-02' existing = {
    name: appInsightsName
}

resource logAnalyticsWorkspace 'Microsoft.OperationalInsights/workspaces@2021-06-01' existing = {
  name: logAnalyticsWorkspaceName
}

resource environment 'Microsoft.App/managedEnvironments@2022-03-01' = {
  name: environmentName
  location: location
  properties: {
    daprAIInstrumentationKey:appInsights.properties.InstrumentationKey
    appLogsConfiguration: {
      destination: 'log-analytics'
      logAnalyticsConfiguration: {
        customerId: logAnalyticsWorkspace.properties.customerId
        sharedKey: listKeys(logAnalyticsWorkspace.id, logAnalyticsWorkspace.apiVersion).primarySharedKey
      }
    }
  }
}

What we’ve done here is simple, we are getting a reference for the existing Application Insights and Log Analytics Workspace instances, then, we are updating the existing Azure Container Apps Environment, see how we are setting the property “daprAIInstrumentationKey” on the highlighted line above, and providing the Application Insights Instrumentation Key.

To execute this file, use the PowerShell terminal and run the command below:

## Ensure you are on directory "~/asksTracker.ContainerApps"
az deployment group create `
  --resource-group $RESOURCE_GROUP `
  --template-file ./deploy/updateacaEnvironment.bicep

Installing Application Insights SDK into the 3 Microservices apps

Now we need to add Application Insights SDK to the 3 services we have, this is an identical operation, so I will describe how we can do it on the Backend API and you do the same on the remaining services.

Step 1: Install the Application Insights SDK using NuGet

To add the SDK, open the file “TasksTracker.TasksManager.Backend.Api.csproj” and add the below NuGet reference

<ItemGroup>
    <!--Other packages are removed for brevity-->
    <PackageReference Include="Microsoft.ApplicationInsights.AspNetCore" Version="2.21.0" />
  </ItemGroup>

Step 2: Set RoleName property for all the services

Next and on each project, we will add a new file named “AppInsightsTelemetryInitializer.cs” on the root directory of the project, so add a file named “AppInsightsTelemetryInitializer.cs” under project “TasksTracker.TasksManager.Backend.Api.Svc” and paste the below:

namespace TasksTracker.TasksManager.Backend.Api
{
    public class AppInsightsTelemetryInitializer : ITelemetryInitializer
    {
        public void Initialize(ITelemetry telemetry)
        {
            if (string.IsNullOrEmpty(telemetry.Context.Cloud.RoleName))
            {
                //set custom role name here
                telemetry.Context.Cloud.RoleName = "tasksmanager-backend-api";
            }
        }
    }
}

The only difference between each file on the 3 projects is the RoleName property value, this property will be used by Application Insights to identify the components on the application map, as well for example it will be useful for us if we need to filter on all the warning logs generated from the Backend API project, so we will use the value “tasksmanager-backend-api” when we filter.
You can check the RoleName value used in the project “TasksTracker.WebPortal.Frontend.Ui” and project “TasksTracker.Processor.Backend.Svc“.

Next, we need to register this “AppInsightsTelemetryInitializer” class, to do this, open the file “Program.cs” and add the code highlighted below (lines 5-9), don’t forget that you need to do the same for the remaining 2 projects.

//Code removed for brevity 

builder.Services.AddControllers();

builder.Services.AddApplicationInsightsTelemetry();

builder.Services.Configure<TelemetryConfiguration>((o) => {
    o.TelemetryInitializers.Add(new AppInsightsTelemetryInitializer());
});

var app = builder.Build();

//Code removed for brevity

Step 3: Set the Application Insights instrumentation key in appsettings.json file

Now we need to set the Application Insights Instrumentation Key so the projects are able to send telemetry data to the AI instance, to do this open file “appsettings.json” and paste the code below, we are going to set this via secrets and environment variables once we redeploy the Container Apps and create new revisions.

{
  "ApplicationInsights": {
    "InstrumentationKey": ""
  } 
}

With this step we have completed the changes on the projects, let’s now deploy the changes and create new revisions.

Deploy the 3 services to Azure Container Apps and create new Revisions

Step 1: Add Application Insights Insrumnation key as a secret

Let’s create a secret named “appinsights-key” on each Container App which contains the value of the AI instrumentation key, remember that we can obtain this value from Azure Portal by going to AI instance we created or we can get it from Azure CLI as we did above. To create the secret use PowerShell console and paste the code below:

az containerapp secret set `
--name $BACKEND_API_NAME `
--resource-group $RESOURCE_GROUP `
--secrets "appinsights-key=<AI Key Here>"

az containerapp secret set `
--name $FRONTEND_WEBAPP_NAME `
--resource-group $RESOURCE_GROUP `
--secrets "appinsights-key=<AI Key Here>"

az containerapp secret set `
--name $BACKEND_SVC_NAME `
--resource-group $RESOURCE_GROUP `
--secrets "appinsights-key=<AI Key Here>"

Step 2: Build new images and push them to ACR

As we have done previously we need to build and push the 3 apps images to ACR so they are ready to be deployed to Azure Container Apps, to do so, continue using the same PowerShell console and paste the code below (Make sure you are on directory “TasksTracker.ContainerApps”):

## Build Backend API on ACR and Push to ACR
az acr build --registry $ACR_NAME --image "tasksmanager/$BACKEND_API_NAME" --file 'TasksTracker.TasksManager.Backend.Api/Dockerfile' . 

## Build Backend Service on ACR and Push to ACR
az acr build --registry $ACR_NAME --image "tasksmanager/$BACKEND_SVC_NAME" --file 'TasksTracker.Processor.Backend.Svc/Dockerfile' .

## Build Frontend Web App on ACR and Push to ACR
az acr build --registry $ACR_NAME --image "tasksmanager/$FRONTEND_WEBAPP_NAME" --file 'TasksTracker.WebPortal.Frontend.Ui/Dockerfile' .

Step 3: Deploy new revisions of the 3 services to Azure Container Apps and set a new environment variable

As we’ve done multiple times, we need to update the Azure Container App hosting the 3 services with a new revision so our code changes are available for end users, to do so run the below PowerShell script, n and notice how we used the property --set-env-vars to set new environment variable named “ApplicationInsights__InstrumentationKey” and its value is a secret reference coming from the secret “appinsights-key” we added in step 1.

az containerapp update `
--name $BACKEND_API_NAME  `
--resource-group $RESOURCE_GROUP `
--image taiseerjoudeh/tasksmanager-backend-api-repo:latest `
--revision-suffix v20220908-1 `
--cpu 0.25 --memory 0.5Gi `
--set-env-vars "ApplicationInsights__InstrumentationKey=secretref:appinsights-key" `
--min-replicas 1 `
--max-replicas 2

az containerapp update `
--name $FRONTEND_WEBAPP_NAME  `
--resource-group $RESOURCE_GROUP `
--revision-suffix v20220908-1 `
--cpu 0.25 --memory 0.5Gi `
--set-env-vars "ApplicationInsights__InstrumentationKey=secretref:appinsights-key" `
--min-replicas 1 `
--max-replicas 1

az containerapp update `
--name $BACKEND_SVC_NAME `
--resource-group $RESOURCE_GROUP `
--revision-suffix v20220908-1 `
--cpu 0.25 --memory 0.5Gi `
--set-env-vars "ApplicationInsights__InstrumentationKey=secretref:appinsights-key" `
--min-replicas 1 `
--max-replicas 5

With those changes in place, you should start seeing telemetry coming to the Application Insights instance provisioned, let’s review Application Insights key dashboards and panels in Azure Portal.

Distributed Tracing via Application Map

Application Map will help us to spot any performance bottlenecks or failure hotspots across all our services of our distributed microservices application. Each node on the map represents an application component (service) or its dependencies and has a health KPI and alerts status.

Looking at the image above, you will see for example how the Backend Api with could RoleName “tasksmanager-backend-api” is depending on the Cosmos DB instance, showing the number of calls and average time to service these calls. The application map is interactive so you can select a service/ component and drill down into details. For example, when I drill down into the Dapr State node to understand how many times my backend API invoked the Dapr Sidecar state service to Save/Delete state, you will see results similar to the below image:

Mintor production application using Live Metrics

This is one of my favorite monitoring panels, it provides you with near real-time (1-second latency) status of your entire distributed application, we can see performance and failures count, we can watch exceptions and traces as they happened, and we can see live servers (replicas in our case) and the CPU and Memory utilization and the number of requests they are handling.
These live metrics provide very powerful diagnostics for our production microservice application. Check the image below and see the server names and some requests coming to the system.

Logs search using Transaction Search

Transaction search in Application Insights will help us to find and explore individual telemetry items, such as exceptions, web requests, or dependencies. As well as any log traces and events that we’ve added to the application.
For example, if I want to see all the event types of type “Request” for the cloud RoleName “tasksmanager-backend-api” in the past 24 hours, I can use the transaction search dashboard to do this, see how the filters are set and the results are displayed nicely, you can drill down on each result to have more details and what telemetry was captured before and after. A very useful feature when troubleshooting exceptions and reading logs.

Failures and Performance Panels

The failure panel allows us to view the frequency of failures across different operations to help us to focus our efforts on those with the highest impact.

The Performance panel displays performance details for the different operations in our system. By identifying those operations with the longest duration, we can diagnose potential problems or best target our ongoing development to improve the overall performance of the system

In the next post, we will be implementing continuous integration and deployment so we automate the process of building images, pushing them to ACR, and then creating new revisions.

The source code for this tutorial is available on GitHub. You can check the demo application too.

Follow me on Twitter @tjoudeh

References:

• The Dapr observability building block
• Opentelemtry Overview
• Application Map: Triage distributed applications
• Find and diagnose performance issues with Azure Application Insights
• Featured image credit by Bethany Drouin

The post Azure Container Apps Monitoring and Observability with Application Insights – Part 8 appeared first on Bit of Technology.

• Tutorial for building Microservice Applications with Azure Container Apps and Dapr – Part 1
• Deploy backend API Microservice to Azure Container Apps – Part 2
• Communication between Microservices in Azure Container Apps – Part 3
• Dapr Integration with Azure Container Apps – Part 4
• Azure Container Apps State Store With Dapr State Management API – Part 5
• Azure Container Apps Async Communication with Dapr Pub/Sub API – Part 6
• Azure Container Apps with Dapr Bindings Building Block – (This Post)
• Azure Container Apps Monitoring and Observability with Application Insights – Part 8
• Continuous Deployment for Azure Container Apps using GitHub Actions – Part 9
• Use Bicep to Deploy Dapr Microservices Apps to Azure Container Apps – Part 10
• Azure Container Apps Auto Scaling with KEDA – Part 11
• Azure Container Apps Volume Mounts using Azure Files – Part 12
• Integrate Health probes in Azure Container Apps – Part 13

Azure Container Apps with Dapr Bindings Building Block

In this post, we are going to extend the backend background processor service named “ACA-Processer Backend” which we created in the previous post, we will rely on Dapr Input and Output Bindings to achieve 3 scenarios as the following:

• Trigger a process on the “ACA-Processer Backend” based on a configurable interval schedule, this implements a background worker to wake up (at a regular interval) and check if tasks created are overdue and mark them as overdue, then store the updated state on Azure Cosmos DB.
• Trigger a process on the “ACA-Processer Backend” based on a message sent to a specific Azure Storage Queue, this is a fictitious scenario but we will assume that this Azure Storage Queue is an external system to which external clients can submit tasks to this queue and our “ACA-Processer Backend” will be configured to trigger a certain process when a new message is received.
• From the service “ACA-Processer Backend” we will invoke an external resource that is storing the content of the incoming task from the external queue as a JSON blob file on Azure Storage Blobs.

Let’s take a look at the high-level architecture diagram below to understand the flow of input and output bindings in Dapr:

The source code for this tutorial is available on GitHub. You can check the demo application too.

Let’s assume that there is an external system (outside of our Tasks Tracker microservice application) that needs to integrate with our Tasks Tracker application, this external system can publish a message on Azure Storage Queue which contains information about a task that needs to be stored and maintained in our Tasks Tracker application, so our system needs to react when a message is added to the Azure Storage Queue.
To achieve this in a simple way and without writing a lot of plumbing code to access the Azure Storage Queue, our system will expose an event handler (aka Input Binding) that receives and processes the message coming to the storage queue. Once the processing of the message completes and we store the task into Cosmos DB, our system will trigger an event (aka Output binding) that invokes a fictitious external service that stores the content of the message into an Azure Blob Storage container.

Note: When I started looking at Dapr Bindings Building Block, I noticed a lot of similarities with the Pub/Sub Building Block we covered in the previous post. But remember that Pub/Sub Building Block is meant to be used for Async communication between services within your solution, the Binding Building Block has a wider scope and it mainly focuses on connectivity and interoperability across different systems, disparate applications, and services outside the boundaries of your own application. For a full list of supported bindings visit this link.

Overview of Dapr Bindings Building Block

Let’s take a look at the detailed Dapr Binding Building Block architecture diagram that we are going to implement in this post to fulfill the use case we discussed earlier:

Looking at the diagram we notice the following:

• In order to receive events and data from the external resource (Azure Storage Queue) our “ACA-Processor Backend” service need to register a public endpoint that will become an event handler.
• This binding configuration between the external resource and our service will be configured by using the “Input Binding Confgiration yaml” file, the Dapr sidecar of the background service will read the configuration and subscribe to the endpoint defined for the external resource, in our case, it will be a specific Azure Storage Queue.
• When a message is published to the storage queue; the input binding component running in the Dapr sidecar picks it up and triggers the event.
• The Dapr sidecar invokes the endpoint (event handler defined in the “ACA-Processer Backend” Service) configured for the binding. In our case, it will be an endpoint that can be reached by invoking a POST operation http://localhost:3502/ExternalTasksProcessor/Process and the request body content will be the JSON payload of the published message to the Azure Storage Queue.
• When the event is handled in our “ACA-Processer Backend” and the business logic is completed, this endpoint needs to return an HTTP response with a 200 ok status to acknowledge that processing is complete. If the event handling is not completed or there is an error, this endpoint should return HTTP 400 or 500 status code.
• In order to enable our service “ACA-Processor Backend” to trigger an event that invokes an external resource, we need to use the “Output Binding Configuration Yaml” file to configure the relation between our service and the external resource (Azure Blob Storage) and how to connect to it.
• Once the Dapr sidecar reads the binding configuration file, our service can trigger an event that invokes the output binding API on the Dapr sidecar, in our case, the event will be creating a new blob file containing the content of the message we read from the Azure Storage Queue.
• With this in place, our service “ACA-Processor Backend” is ready to invoke the external resource by sending a POST operation to the endpoint http://localhost:3502/v1.0/bindings/ExternalTasksBlobstore and the JSON payload will contain the below content, or we can use the Dapr client SDK to invoke this output biding to invoke the external service and store the file in Azure Blob Storage
  

  {
    "data": "{
  	        "taskName": "Health Readiness Task",
  	        "taskAssignedTo": "tayseer_joudeh@hotmail.com",
  	        "taskCreatedBy": "tjoudeh@bitoftech.net",
  	        "taskDueDate": "2022-08-19T12:45:22.0983978Z"
   }",
    "operation": "create"
  }

Let’s now update our Backend Background Processer project and define the input and output bindings configuration files and event handlers.

To proceed with this tutorial we need to provision this fictisios external service (Azure Storage Account) to start responding to messages published to a queue and use the same storage account to store blob files as an external event. To do so, you can run the below PowerShell script to create Azure Storage Account and get the master key.

$STORAGE_ACCOUNT_NAME = "<replace with unique storage name>"
  
az storage account create `
--name $STORAGE_ACCOUNT_NAME `
--resource-group $RESOURCE_GROUP `
--location $LOCATION `
--sku Standard_LRS `
--kind StorageV2
  
# list azure storage keys
az storage account keys list -g $RESOURCE_GROUP -n $STORAGE_ACCOUNT_NAME

Updating the Backend Background Processer Project

Step 1: Create an event handler (API endpoint) to respond to messages published to Azure Storage Queue

Let’s add an endpoint that will be responsible to handle the event when a message is published to Azure Storage Queue,  this endpoint will start receiving the message published from the external service, to do so, add a new controller named “ExternalTasksProcessorController.cs” under “Controllers” folder and use the code below:

namespace TasksTracker.Processor.Backend.Svc.Controllers
{
    [Route("ExternalTasksProcessor")]
    [ApiController]
    public class ExternalTasksProcessorController : ControllerBase
    {
        private readonly ILogger<ExternalTasksProcessorController> _logger;
        private readonly DaprClient _daprClient;

        public ExternalTasksProcessorController(ILogger<ExternalTasksProcessorController> logger,
                                                DaprClient daprClient)
        {
            _logger = logger;
            _daprClient = daprClient;
        }

        [HttpPost("process")]
        public async Task<IActionResult> ProcesseTaskAndStore([FromBody] TaskModel taskModel)
        {
            try
            {
                _logger.LogInformation("Started processing external task message from storage queue. Task Name: '{0}'", taskModel.TaskName);

                taskModel.TaskId = Guid.NewGuid();
                taskModel.TaskCreatedOn = DateTime.UtcNow;

                //Dapr SideCar Invocation (save task to a state store)
                await _daprClient.InvokeMethodAsync(HttpMethod.Post, "tasksmanager-backend-api", $"api/tasks", taskModel);

                _logger.LogInformation("Saved external task to the state store successfuly. Task name: '{0}', Task Id: '{1}'", taskModel.TaskName, taskModel.TaskId);

		      //ToDo: code to invoke external binding and store queue message content into blob file in auzre storage

                return Ok();
            }
            catch (Exception)
            {
                throw;
            }
        }
    }
}

What we have added here is simple, we just defined an action method named “ProcesseTaskAndStore” which can be accessed by sending HTTP POST operation on the endpoint “ExternalTasksProcessor/Process” and this action method accepts the TaskModel in the request body as JSON payload, this is what will be received from the external service (Azure Storage Queue). Within this action method, we are going to store the received task into Cosmos DB using Dapr state store API covered in this post, and then we return 200 OK to acknowledge that message received is processed successfully and should be removed from the external service queue.

Step 2: Create Dapr Input Binding Component file

Now we need to create the component configuration file which will describe the configuration and how our backend background processor will start handling events coming from the external service (Azure Storage Queues). To do so, add a new file named “dapr-bindings-in-storagequeue.yaml” under folder “components” and paste the below:

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: externaltasksmanager
spec:
  type: bindings.azure.storagequeues
  version: v1
  metadata:
  - name: storageAccount
    value: "taskstracker"
  - name: storageAccessKey
    value: "" 
  - name: queue
    value: "external-tasks-queue"
  - name: decodeBase64
    value: "true"
  - name: route
    value: /externaltasksprocessor/process

The full specifications of yaml file with Azure Storage Queues can be found on this link, but let’s go over the configuration we have added here:

• The type of binding is “bindings.azure.storagequeues”.
• The name of this input binding is “externaltasksmanager”.
• We are setting the “storageAccount” name, “storageAccessKey” value, and the “queue” name. Those properties will describe how the event handler we added can connect to the external service. You can create any queue you prefer on the Azure Storage Account we created to simulate an external system.
• We are setting the “route” property to the value “/externaltasksprocessor/process ” which is the address of the endpoint we have just added so POST requests are sent to this endpoint.
• We are setting the property “decodeBase64” to “true” as the message queued in the Azure Storage Queue is Base64 encoded.

Step 3: Create Dapr Output Binding Component file

Now we need to create the component configuration file which will describe the configuration and how our backend background processor will be able to invoke the external service (Azure Blob Storage) and be able to create a JSON file that contains the content of the message received from Azure Storage Queues. To do so, add a new file named “dapr-bindings-out-blobstorage.yaml” under folder “components” and paste the below:

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: externaltasksblobstore
spec:
  type: bindings.azure.blobstorage
  version: v1
  metadata:
  - name: storageAccount
    value: "taskstracker"
  - name: storageAccessKey
    value: "" 
  - name: container
    value: "externaltaskscontainer"
  - name: decodeBase64
    value: false

The full specifications of yaml file with Azure blob storage can be found on this link, but let’s go over the configuration we have added here:

• The type of binding is “bindings.azure.blobstorage”.
• The name of this output binding is “externaltasksblobstore”. We will use this name when we use the Dapr SDK to trigger the output binding.
• We are setting the “storageAccount” name, “storageAccessKey” value, and the “container” name. Those properties will describe how our backend background service will be able to connect to the external service and create a blob file. We will assume that there is a container already created on the external service and named “externaltaskscontainer” All our JSON blob files created will be under this container.
• We are setting the property “decodeBase64”  to “false” as we don’t want to encode file content to base64 images, we need to store the file content as is.

Step 4: Use Dapr client SDK to invoke the output binding

Now we need to invoke the output binding by using the .NET SDK, to do so, open the file named “ExternalTasksProcessorController.cs” and update the action method code as the below

[HttpPost("process")]
        public async Task<IActionResult> ProcesseTaskAndStore([FromBody] TaskModel taskModel)
        {
            try
            {
                _logger.LogInformation("Started processing external task message from storage queue. Task Name: '{0}'", taskModel.TaskName);

                taskModel.TaskId = Guid.NewGuid();
                taskModel.TaskCreatedOn = DateTime.UtcNow;

                //Dapr SideCar Invocation (save task to a state store)
                await _daprClient.InvokeMethodAsync(HttpMethod.Post, "tasksmanager-backend-api", $"api/tasks", taskModel);

                _logger.LogInformation("Saved external task to the state store successfuly. Task name: '{0}', Task Id: '{1}'", taskModel.TaskName, taskModel.TaskId);

		//code to invoke external binding and store queue message content into blob file in auzre storage
		     IReadOnlyDictionary<string,string> metaData = new Dictionary<string, string>()
                    {
                        { "blobName", $"{taskModel.TaskId}.json" },
                    };

                await _daprClient.InvokeBindingAsync("externaltasksblobstore", "create", taskModel, metaData);

                _logger.LogInformation("Invoked output binding '{0}' for external task. Task name: '{1}', Task Id: '{2}'", OUTPUT_BINDING_NAME, taskModel.TaskName, taskModel.TaskId);

                return Ok();
            }
            catch (Exception)
            {
                throw;
            }
        }

Looking at lines 17-24, you will see that we calling the method “InvokeBindingAsync” and we are passing the binding name “externaltasksblobstore” defined in the configuration file, as well the second parameter “create” is the action we need to do against the external blob storage. You can for example delete or get a content of a certain file. For a full list of supported actions on Azure Blob Storage, visit this link.

Notice how are setting the file name we are storing at the external service, we need the file names to be created using the same Task Identifier, all we need to do is to pass the key “blobName” with the file name values into the “metaData” dictionarity.

Step 5: Test Dapr bindings locally

Now we are ready to give it an end-to-end test on our dev machines, to do so, run the 3 applications together using Debug and Run button from VS Code. You can read how we configured the 3 apps to run together in this post.

Open Azure Storage Explorer, if you don’t have it you can install it from here. Login to your Azure Subscription and navigate to the storage account already created, create a queue, and use the same name you already used in the Dapr Input configuration file.

The content of the message that Azure Storage Queue excepts should be as below, so try to queue a new message using the tool as the image below

{
  "taskName": "Task from External System",
  "taskAssignedTo": "tayseer_joudeh@hotmail.com",
  "taskCreatedBy": "tjoudeh@bitoftech.net",
  "taskDueDate": "2022-08-19T12:45:22.0983978Z"
}

If all is configured successfully you should be able to see a JSON file created as a blob in the Azure Storage Container named “externaltaskscontainer” based on your configuration.

Step 6: Create Input and Output Binding Component files matching Azure Container Apps Specs

Go ahead and add a new file named “containerapps-bindings-in-storagequeue.yaml” under the folder “aca-components” and paste the code below:

componentType: bindings.azure.storagequeues
version: v1
metadata:
- name: storageAccount
  value: "taskstracker"
- name: storageAccessKey
  secretRef: storagekey
- name: queue
  value: "external-tasks-queue"
- name: decodeBase64
  value: "true"
- name: route
  value: /externaltasksprocessor/process        
secrets:
- name: storagekey
  value: "<value>"
scopes:
- tasksmanager-backend-processor

The properties of this file is matching the ones used in Dapr component-specific file, it is a component of type “bindings.azure.storagequeues”.
The only difference is that we are using “secretRef” when setting the “storageAccessKey” and we will be setting the actual value from the Azure Portal after we add those Dapr Input binding component to Azure Container Apps Env.

Let’s add a new file named “containerapps-bindings-out-blobstorage.yaml” under the folder “aca-components” and paste the code below:

componentType: bindings.azure.blobstorage
version: v1
metadata:
- name: storageAccount
  value: "taskstracker"
- name: storageAccessKey
  secretRef: storagekey
- name: container
  value: "externaltaskscontainer"
- name: decodeBase64
  value: "false"
- name: publicAccessLevel
  value: "none"    
secrets:
- name: storagekey
  value: "<value>"
scopes:
- tasksmanager-backend-processor

The properties of this file is matching the ones used in Dapr component-specific file, it is a component of type “bindings.azure.blobstorage”.
The only difference is that we are using “secretRef” when setting the “storageAccessKey” and we will be setting the actual value from the Azure Portal after we add those Dapr Output binding component to Azure Container Apps Env.

With those changes in place, we are ready to rebuild the backend background processor container image, update Azure Container Apps Env, and redeploy a new revision, but I want to add one small piece and introduce a special type of input binding which is Cron Jobs. So let’s do this before.

Overview of Cron Input Binding

Cron binding is a special type of input binding, it doesn’t subscribe for events coming from an external system, the corn biding can be used to trigger application code in our service periodically based on a configurable interval, so for example, if we want to trigger certain code to scan all the tasks in the system every 4 hours and mark the tasks which are overdue, the corn binding is suitable to do this.

Step 1: Add Cron binding configuration

The first step to configuring Cron binding is to add a component file that describes where is the code that needs to be triggered and on which intervals it should be triggered, to do so add a new file named “dapr-scheduled-cron.yaml” under folder “components” and use the code below:

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: ScheduledTasksManager
  namespace: default
spec:
  type: bindings.cron
  version: v1
  metadata:
  - name: schedule
    value: "@every 10m"
scopes:
- tasksmanager-backend-processor

What we have done here is the following:

• Added new input binding of type “bindings.cron”
• Provided the name “ScheduledTasksManager” for this binding, this means that an HTTP POST endpoint on the URL “/ScheduledTasksManager” should be added as it will be invoked when the job is triggered based on the Cron intervals.
• Setting the interval for this Cron job to be triggered every 10 minutes, for full details and available options on how to set this value, visit the Cron binding documentation.

Step 2: Add Cron binding configuration matching Azure Container Apps Specs

Now we will add a new file named “containerapps-scheduled-cron.yaml” under folder “aca-components”. this file will be used when updating the Azure Container App Env and enable this binding, and use the code below:

componentType: bindings.cron
version: v1
metadata:
- name: schedule
  value: "@every 6h"
# Application scopes  
scopes:
- tasksmanager-backend-processor

Note that the name of the binding is not part of the file metadata, we are going to set the name of the binding to the value “ScheduledTasksManager” when we update the Azure Container Apps Env.

Step 3: Add the endpoint which will be invoked by Cron binding

As we saw in the previous steps, the Cron job configuration is very simple, we now need to add an endpoint which accepts POST request when the Cron job is triggered, to do so add a new file named “ScheduledTasksManagerController.cs” under the project “TasksTracker.Processor.Backend.Svc” and use the code below:

namespace TasksTracker.Processor.Backend.Svc.Controllers
{
    [Route("ScheduledTasksManager")]
    [ApiController]
    public class ScheduledTasksManagerController : ControllerBase
    {
        private static string STORE_NAME = "periodicjobstatestore";
        private static string WATERMARK_KEY = "PeriodicSvcWatermark";
        private readonly ILogger<ScheduledTasksManagerController> _logger;
        private readonly DaprClient _daprClient;

        public ScheduledTasksManagerController(ILogger<ScheduledTasksManagerController> logger,
                                                DaprClient daprClient)
        {
            _logger = logger;
            _daprClient = daprClient;
        }

        [HttpPost]
        public async Task CheckOverDueTasksJob()
        {
            var currentWatermark = DateTime.UtcNow;

            _logger.LogInformation($"ScheduledTasksManager::Timer Services triggered at: {currentWatermark}");

            var overdueTasksList = new List<TaskModel>();

            var waterMark = await _daprClient.GetStateAsync<DateTime>(STORE_NAME, WATERMARK_KEY);
            _logger.LogInformation($"ScheduledTasksManager::reading watermark from state store, watermark value: {waterMark}");

            var tasksList = await _daprClient.InvokeMethodAsync<List<TaskModel>>(HttpMethod.Get, "tasksmanager-backend-api", $"api/overduetasks?waterMark={waterMark}");
            _logger.LogInformation($"ScheduledTasksManager::completed query state store for tasks, retrieved tasks count: {tasksList.Count()}");

            foreach (var taskModel in tasksList)
            {
                if (currentWatermark.Date> taskModel.TaskDueDate.Date)
                {
                    overdueTasksList.Add(taskModel);
                }
            }

            if (overdueTasksList.Count> 0)
            {
                _logger.LogInformation($"ScheduledTasksManager::marking {overdueTasksList.Count()} as overdue tasks");
                await _daprClient.InvokeMethodAsync(HttpMethod.Post, "tasksmanager-backend-api", $"api/overduetasks/markoverdue", overdueTasksList);
            }

            _logger.LogInformation($"ScheduledTasksManager::storing watermark to state store, watermark value: {currentWatermark}");
            await _daprClient.SaveStateAsync(STORE_NAME, WATERMARK_KEY, currentWatermark);
        }
    }
}

Let’s highlight what we have added to this controller:

• A new action method named “CheckOverDueTasksJob” contains the business logic which will be triggered by the Cron job configuration on a certain interval
• I’m using a watermark value that holds the last run of this job, the value of the watermark (timestamp of the last run) is stored in a persistent store (in my case it is stored as a blob file) using Dapr State management API on Azure Blob Storage, you can use output binding for this as well. This is the beauty o Dapr Building Blocks; it is flexible and you can choose different ways to achieve the same thing. We will add the State management Dapr component file in the next step.
• I have added 2 methods named “GetTasksByTime” and “MarkOverdueTasks” to the interface “ITasksManager” in project “TasksTracker.TasksManager.Backend.Api”. Those methods are called via the Dapr Service Invocation Building Block. You can see the complete code of method “GetTasksByTime” and method “MarkOverdueTasks” by visiting the links.

Step 4: Add Azure Blob Storage State Store Components to store and retrieve Watermark

Add a new file named “dapr-statestore-blobstorage-periodic.yaml” under the folder “components” and paste the code below:

apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: periodicjobstatestore
spec:
  type: state.azure.blobstorage
  version: v1
  metadata:
  - name: accountName
    value: "taskstracker"
  - name: accountKey
    value: ""
  - name: containerName
    value: "periodicjobcontainer"

Next, we need to add a component file that matches Azure Container Apps Specs, so add a new file named “containerapps-statestore-blobstorage-periodic.yaml” under the folder “aca-components” and paste the code below:

componentType: state.azure.blobstorage
version: v1
metadata:
- name: accountName
  value: "taskstracker"
- name: accountKey
  secretRef: storagekey
- name: containerName
  value: "periodicjobcontainer"
secrets:
- name: storagekey
  value: ""
scopes:
- tasksmanager-backend-processor

What we have done here should be familiar to you now, we have added a state store component file of type “state.azure.blobstorage”. This component file will describe to our service how it will store blob files on the storage account named “taskstracker” under container “periodicjobcontainer”. We will be setting the actual “storageKey” from the Azure Portal after we update Azure Container Apps Env.

Deploy the Backend Background Processer and the Backend API Projects to Azure Container Apps

Step 1: Build the Backend Background Processer and the Backend API App images and push them to ACR

As we have done previously we need to build and deploy both app images to ACR so they are ready to be deployed to Azure Container Apps, to do so, continue using the same PowerShell console and paste the code below (Make sure you are on directory “TasksTracker.ContainerApps”):

az acr build --registry $ACR_NAME --image "tasksmanager/$BACKEND_API_NAME" --file 'TasksTracker.TasksManager.Backend.Api/Dockerfile' . 

az acr build --registry $ACR_NAME --image "tasksmanager/$BACKEND_SVC_NAME" --file 'TasksTracker.Processor.Backend.Svc/Dockerfile' .

Step 2: Add 4 Dapr Components to Azure Container Apps Environment

We need to run the command below commands to add the 4 component files we have defined in this post, to do so use the same PowerShell console and paste the code below:

##Input binding component for Azure Storage Queue
az containerapp env dapr-component set `
  --name $ENVIRONMENT --resource-group $RESOURCE_GROUP `
  --dapr-component-name externaltasksmanager `
  --yaml '.\aca-components\containerapps-bindings-in-storagequeue.yaml'

##Output binding component for Azure Blob Storage
az containerapp env dapr-component set `
 --name $ENVIRONMENT --resource-group $RESOURCE_GROUP `
  --dapr-component-name externaltasksblobstore `
 --yaml '.\aca-components\containerapps-bindings-out-blobstorage.yaml'
 
##Cron binding component
az containerapp env dapr-component set `
  --name $ENVIRONMENT --resource-group $RESOURCE_GROUP `
  --dapr-component-name scheduledtasksmanager `
  --yaml '.\aca-components\containerapps-scheduled-cron.yaml'

##State Store component for Azure Blob Storage
az containerapp env dapr-component set `
 --name $ENVIRONMENT --resource-group $RESOURCE_GROUP `
  --dapr-component-name periodicjobstatestore `
 --yaml '.\aca-components\containerapps-statestore-blobstorage-periodic.yaml'

Once the components are added to Azure Container Apps Env. Don’t forget to update the “secretRef” where it is needed from the Azure Portal. It will be similar to what we have done previously in this post

Step 3: Deploy new revisions of the Backend API and Backend Background Processer to Azure Container Apps

As we’ve done multiple times, we need to update the Azure Container App hosting the Backend API & Backend Background Processer with a new revision so our code changes are available for end users, to do so run the below PowerShell script:

## Update Backend API App container app and create a new revision 
az containerapp update ` 
--name $BACKEND_API_NAME ` 
--resource-group $RESOURCE_GROUP ` 
--revision-suffix v20220829-1 ` 
--cpu 0.25 --memory 0.5Gi ` 
--min-replicas 1 ` 
--max-replicas 2

## Update Backend Background Processer container app and create a new revision 
az containerapp update `
--name $BACKEND_SVC_NAME `
--resource-group $RESOURCE_GROUP `
  --revision-suffix v20220829-1 `
  --cpu 0.25 --memory 0.5Gi `
  --min-replicas 1 `
  --max-replicas 5

With those changes in place and deployed, from the Azure Portal, you can open the log streams of the container app hosting the “ACA-Processor-Backend” and check the logs generated after queuing a message into Azure Storage Queue as an external system, you should receive logs similar to the below

That’s it for now, this post turned out to be a bit lengthy stay tuned and happy coding!

The source code for this tutorial is available on GitHub. You can check the demo application too.

Follow me on Twitter @tjoudeh

References:

• The Dapr bindings building block

The post Azure Container Apps with Dapr Bindings Building Block – Part 7 appeared first on Bit of Technology.