Welcome to today’s post.
In today’s post I will be showing how to deploy a .NET Core WebJob console application to Azure.
In a previous post I showed how to create a basic WebJob console application using .NET Core. In another post I showed how to extend the same WebJob application to support logging and database access.
After we have created the WebJob application within our local development environment and tested it locally, we can try deploying the application to the Azure environment. I will show how we deploy the WebJob in this post.
Deployment using the Publishing Wizard
The simplest way for us to deploy a locally developed WebJob to Azure is through the Visual Studio development environment. We can do this using the Visual Studio Publish wizard.
In the Publish Wizard screen, we select the target as Azure:
Next, we select the service as Azure WebJobs:
Next, select an existing App Service instance you wish to move the WebJob under:
At this stage we confirm the settings, most of which are defaulted, including the username, which is taken from our App Service.
We then publish the application:
The deployment should take a minute.
In the next sections, I will show how to verify the deployment of the WebJob in the Azure App Service and how to run a basic test the job in Azure.
Verifying the WebJob Deployment in the Azure Portal
Following deployment, the WebJob will be moved into a folder under your app service:
[App Service Name]\app_data\Jobs\Triggered\
Next, open the Azure portal, navigate to your App Service, then locate and select the WebJobs menu item:
You will then see the WebJob listed with the name, type, status, and schedule:
Next, we will conduct a quick test of our web job to ensure it is doing what we expect.
Manually Running the WebJob
First, we run the WebJob. We do this by selecting the WebJob, right-click the select Run as shown:
Once the WebJob is run, we should see the status showing:
In the next section, I will show how to add a message to the storage queue so that the Web Job triggers through the trigger function.
Adding a Message to the Storage Queue
The next task is to add a message to an Azure storage queue.
We do this as follows:
Select an existing Azure storage account.
Then from the side menu, find and select the Queues menu item:
The queues in your storage account will show:
Next, select one of the storage queues, you will then see a screen showing any messages in the queue:
Click on Add Message and add a test message to the queue:
After adding the message, it will be listed in the queue:
In the next section, I will show how to diagnose and troubleshoot errors that appear in the message queue,
Troubleshooting Web Job Failures
If you see the WebJob fails after a minute, then the value in the Status column will show with a failure message:
Should this be the case, there are two things we can check:
1.The connection string AzureWebJobsDashboard has not been set in Azure App Settings for your host App Service. The format of the dashboard connection string should be:
DefaultEndpointsProtocol=https;AccountName=NAME;AccountKey=KEY
Where AccountName is the name of the Azure storage account you are using for the queue and AccountKey is the key for the Azure storage account.
2. Any additional settings that the WebJob depends on. One common setting is a database connection string, which might be inaccessible or invalid.
Azure Dashboard Connection String Configuration
Adding the AzureWebJobsDashboard connection string can be done using the App Settings configuration and should be set to type Custom as shown:
Custom Azure SQL Database Connection Strings
The connection string in the Azure production environment by default will take the connection settings from the appsettings.production.json.
Remember that when we deploy the application to Azure App Services, the appsettings.json file will be copied over to the site\wwwroot folder if the settings file is newer. There will be an additional settings file, appsettings.production.json created in the same folder. In our WebJob application, we will need to tell it to look for the correct settings file based on our environment variable. The same variables created within the App Settings configuration will override corresponding settings keys defined in appsettings.production.json.
With this in mind, we ensure that our application Configuration checks the app settings applicable for its environment:
public void ConfigureServices(IServiceCollection services)
{
…
var environment = "";
var hostBuilder = new HostBuilder()
.UseContentRoot(Directory.GetCurrentDirectory())
.ConfigureAppConfiguration((hostingContext, config) =>
{
environment = hostingContext.HostingEnvironment.EnvironmentName;
});
var configBuilder = new ConfigurationBuilder()
.SetBasePath(Directory.GetCurrentDirectory())
.AddJsonFile("appsettings.json", optional: true, reloadOnChange: false);
if (environment.Length > 0)
configBuilder.AddJsonFile($"appsettings.{environment}.json",
optional: false, reloadOnChange: true);
configBuilder.AddEnvironmentVariables();
IConfiguration config = configBuilder.Build();
services.AddDbContext<ApplicationDbContext>(options =>
options.UseSqlServer(config.GetConnectionString("AppDbContext")));
…
}
This will ensure our web job in the context of the production environment, takes the connection settings from the correct app settings JSON file in production instead of the development settings, which may be referencing localhost! If the same settings are created in the App Settings configuration then we would not have this problem.
In the Kudo console, you can see the files within the site/wwwroot folder:
To view WebJob Details, select the Web Job, right-click the select Log. The web jobs for your App Service will then show:
Select a running WebJob and toggle the output. You will then see the output:
The logs from the WebJob will be visible in the logs. If successful you will see a Succeeded message. When a message is processed from the queue you will also see a Dequeue message.
To confirm that the database has been updated from the WebJob, open and run a Query from the Azure SQL Database and check the DateUpdated field:
From the above tasks, we have seen how straightforward it is to deploy a web job, created as a .NET Core console application that has database connectivity, to an Azure application service as a triggered job.
We have also seen how to test the triggered deployed Azure WebJob by posting a basic message to the queue and to check the data has been modified by the web job.
That is all for today’s post.
I hope you found this post useful and informative.
Andrew Halil is a blogger, author and software developer with expertise of many areas in the information technology industry including full-stack web and native cloud based development, test driven development and Devops.
