Christos Polydorou

In a Kubernetes cluster, the resources we deploy are assigned IPs from the cluster's network that makes them unreachable from other networks. The most common way to expose an app to the world outside the cluster is to create a service. The service will load balance the traffic across pods and will also bridge the gap between the two worlds (cluster and outside network) using a concept much like NAT. This, however, does now allow us control over how the app is published, from which pods, etc. This is where ingress controllers come into play. An ingress controller is a way to publish apps having full control on how each and every component is being accessed. Compared to traditional application deployment, we could say that the role and functionality of the ingress controller are much like those of application delivery controllers such as Citrix ADC and F5 BigIP.  The below diagram shows the basic functionality of an ingress controller: In this example, we have three namespaces config

Citrix ADC (formerly NetSceler) is, without doubt, one of the top enterprise Application Delivery Controllers on the market and the preferred solution for many organizations. It is offered in many different form factors, from physical to virtual appliances and even containers. Citrix ADC is also available on Azure, which makes it ideal not only for experimenting and getting to know it better but also for using it to publish applications and services. I've created a bicep template to serve as a starting point so that you can easily create an instance and get to know the resources required. The main template creates a subscription-level deployment that separates the resources into different resource groups. The resources to be deployed include: virtual network network security group network card public IP virtual machine Going through the bicep files, we have a main template file ( main.bicep ) that uses two separate modules to deploy the vNet ( vnet.bicep ) and the ADC ( adc.bic

Microsoft's Windows Subsystem for Linux is starting to gain a lot of my respect lately, not only because I can run my docker container engine on it, but due to the fact that the most popular Linux distributions are also available as images to be imported.  As you can imagine, having a Linux environment as an app within Windows can be very helpful. Especially when the drives of the system are also available from within the distribution! One of the most common problems I run into and I've managed to solve using WSL is running bash scripts for Azure CLI. In the majority of the cases, I use VS Code and the remote container extension to deploy resources using Azure CLI, but there are times I want to test different versions of it, including beta releases. The solution? Separate instances of Ubuntu on WSL! Below are the steps to import Ubuntu and then install Azure CLI. First, we need to add a new Ubuntu instance to WSL. The Ubuntu cloud images are published on the Ubuntu website  and

Azure's Resource Configuration Changes feature has been in public preview for a few days now and I thought we should give it a try and see what it has to offer! Resource Configuration Changes aims to provide more information on changes applied to Azure resources through Resource Graph Explorer.  If you search for "Resource Graph" in the Azure Portal search, one of the results will be Resource Graph Explorer: The look and feel of the Resource Graph Explorer is pretty similar to Log Analytics workspaces: On the left, we have the tables we can query and in the middle is the well-known query window, where we type and execute our queries. To get information about the changes that have been applied to Azure resources, we'll be querying the  resourcechanges namespace: We can see the available properties to query against by starting with a simple where  clause. Let's get all the changes in a specific subscription: As you can imagine, this query will return a very large d