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 Web Job console application using .NET Core and how to extend the same application to support logging and database access.
The first steps we take to deploy our Web Job to Azure is to use the Publish wizard.
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.
After deployment, the Web Job will be moved into a folder under your app service:
[App Service Name]\app_data\Jobs\Triggered\
After deployment open the Azure portal, navigate to your App Service, then locate and select the WebJobs menu item:
You will then see the Web Job 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.
First, we run the Web Job. We do this by selecting the Web Job, right-click the select Run as shown:
Once the Web Job is run, we should see the status showing:
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:
If you see the Web Job fails after a minute, then the Status will show:
Should this be the case, there are two things we can check:
- 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 Web Job 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 Web Job 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 Web Job Details, select the Web Job, right-click the select Log. The web jobs for your App Service will then show:
Select a running Web Job and toggle the output. You will then see the output:
The logs from the Web Job 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 Web Job, 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 web job 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.
