Christos Polydorou

In my previous article , we went through the process of uploading our own image to Docker Hub. Even though it's perfectly fine to use Docker Hub, some organizations prefer using their own registries, either due to additional functionality that they might offer or due to policies and regulations. Since Azure offers a container registry resource that would fit most use cases, I thought we could try to upload some images and at least use it for test and dev purposes!  First things first, the tools we're going to need. To upload an image to an ACR we need: 1. An Azure Container Registry 2. Docker Desktop 3. Azure CLI Starting from the top of the list, we need the ACR resource to which we're going to upload the images. Clone my Github bicep repository and switch to the  ContainerRegistry-ImageUpload-001/110-Bicep/110-AzureContainerRegistry/ folder. Update the parameters in the deploy script and submit the deployment. The output should be similar to the below: If everything goe

Modern applications are usually developed with cloud-native principles in mind, there are however some that may have particular requirements in terms of storage. When developing for containers, the need for a ReadWriteMany storage may arise, which may turn into a problem when cloud services fail to match the requirements, especially the ones related to performance. One of the solutions to this problem is the Rook - Ceph combination. Ceph is an open-source software-defined storage platform that implements object storage on a single distributed computer cluster and provides interfaces for object-, block- and file-level storage. Rook, on the other hand, helps perform all the administrative tasks such as deployment, configuration, provisioning, scaling, and more. A multi-zone AKS cluster is the perfect home for Rook and Ceph. The cluster is spread across three data centers and so is the data handled by Ceph. This increases the SLAs of the services running on the cluster and at the same tim

One of the very first steps in the containerization process of a service or application is constructing the image that is going to be used for every component. A component may require a plain image that is just an Apache server, but in the majority of the cases, you'll have to add packages or apply configurations to the images already provided in Docker Hub. This will result in creating your own images that you may eventually share on Docker Hub.     In this post, we're going to follow the process of creating our own image and then publishing it. First, we need to decide the image on top of which we're going to build our own. To make this call, you need to know what services and applications are going to be running on your container. Take WordPress for example. You can start with the official image, one of the very popular Bitnami images, or with just a PHP-FPM image. In this example, we're going to build on top of the PHP Apache image and save all of our files in a dir

I've been using Azure to test virtual machines and applications for quite a few years now and I've realized that although I mostly use two or three solution templates - like an Active Directory environment for example - in the majority of the cases I need more server or client machines. This is the main reason I decided to adjust my deployments and include loops so that I can control the number of machines using parameters and variables. In this post, I'll describe how I've used loops and hopefully how you can benefit from them. I'm a big fan of organizing resources in modules, so all of the examples will be based on a deployment of virtual networks and virtual machines from a main bicep file using the respective modules, one for each resource type. Multiple Resources/Modules Since we're talking about modules, what could be better than having the ability to deploy the same module multiple times! The first thing we need is a variable that will hold the custom fie

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