Christos Polydorou

In this article, I'm going to walk you through submitting Azure Deployments using Bicep files from Azure DevOps. Unfortunately, up until now, there is no official task for this need, so we are going to use Azure CLI instead. We'll start with creating a new pipeline, so open your project in Azure DevOps, switch to the Pipelines view, and hit the new pipeline button. We're going to use the classic edition for this demo, so go for the Use the classic editor option at the bottom. The first step of a build pipeline is to select the source that contains your code. For this, I've created a Git repository in the same project that contains a bicep file and looks like this: By default, the source repository is going to be set to Azure DevOps, which is fine for our case: Moving on to the next step, we're presented with some template options for the pipeline. We'll start with an empty pipeline that we'll build ourselves so click the Empty Job option. The next screen i

For the last couple of weeks, I've been working on a project that is focused on Azure App Services and how certain applications can be hosted on them. Part of the project was to examine the performance of the storage space that each plan offers and whether it can accommodate the needs of each application. If you deploy an App Service that is using code instead of containers, you'll have to upload the files to the App Service's storage yourself. This can be achieved in many ways, including DevOps pipelines, development tools such as Visual Studio and FTP. In my case, I was handed a testing version of the website code that was based on PHP and a large number of files used by the site, including CSS and JS and a lot of image files that I had to upload to the AppService. In order to provide the required information regarding the endpoints to connect to and with what credentials, Azure provides a file called "Publish Profile". There are three profiles included in the p

Following my last post about monitoring your domains and hosts for RBL listing, we are going to continue with the PowerShell module to manage the solution and a script to query the status of hosts and domains. Since the solution is accessible via HTTP, it couldn't be simpler to manage using PowerShell. But first, let's take a look at the files in the module. The module is comprised of three files, the module manifest (.psd1), the script file (.psm1), and a configuration file (.json). The manifest contains the module parameters and configuration, the script file the code of the functions, and the configuration file a couple of settings such as the URL of the function app and the key to use. We'll talk about key management later in this article. The module contains the following functions: List related Get-AzureRBLList Add-AzureRBLList Remove-AzureRBLList Host related Get-AzureRBLHost Add-AzureRBLHost Remove-AzureRBLHost Check-AzureRBLHost Domain related Get-AzureR

In the previous post of the series ( here ), we went through the design of a solution to help monitor host and domain listing in RBLs. In this article, we'll go through the process of deploying and configuring the required resources on Azure. To deploy the solution to your Azure subscription, you have to perform two tasks: Deploy the Azure resources, that is the Storage Account and a Function App Deploy the Azure Function App application code To deploy the Azure resources, you have to submit an ARM deployment task using the ARM template file saved in the repository ( here ). There are two ways to create a deployment using this file: Deploy to Azure button   The main repository page contains a button that opens the Azure portal and prompts for parameters for the deployment: Leaving the default values will result in a deployment in the same location as the resource group and randomized resource names. ARM File Deployment The other way to deploy an ARM file is to use the Azure Powers

The thing that prompted the publishing of this series of posts is a recent case of a customer with a large mail platform. The Mail Transfer Agents handling the internet mail flow for such a platform are usually susceptible to being flagged as malicious on RBLs, causing issues with mail flow. The solution described in these posts helps monitor the status on the RBLs and trigger alerts in service management systems, using modern cloud application development techniques. But wait, what is an RBL? A Real Time Block list is a service that keeps track of the domain and/or the IP address of the hosts reported to be sending SPAM or malicius messages. RBLs are actual DNS zones where IP addresses or domain names are represented by A records. Let's take a list, say rbl.example.net, for example. To check if the host with IP 100.101.102.103 is listed we have to query the DNS for the host 103.102.101.100.rbl.example.net. If there is no such host known (the responce is NXDOMAIN) the host

Developing using containers offers the ability to use different environments and software without having to install them on your development workstation, while at the same time you conserve a lot of system resources avoiding the use of virtual machines. Visual Studio Code has been receiving a lot of functionality towards that end with a great deal of extensions and part of that is targeting Azure template developement.  We can use VS Code to develop our code and then use a container with all the Azure tools to deploy. This post describes this very process, from docker installation to VS Code configuration and finally template deployment.  First we need to install all the necessary components on our system. This includes Docker Desktop, Visual Studio Code and a patch for the linux kernel of Windows Subsystem for Linux (WSL 2). You can find Docker Desktop on the official Docker page here  and VS Code on its page over here . The Docker installation wizard will add any required Windows fea