Taking a glance at running an Azure Webapp on a custom location powered by Azure Arc

Introduction

Earlier this week I published the following repository ; https://github.com/beluxappdev/demo-arc-appservice. Which basically contains all the needed steps (via Azure CLI) to create an environment that showcases how Azure AppService and Azure Arc work together. For today’s blog post, I would like to take you on the journey from a “consumer” of this App Service Environment (running on any Kubernetes distribution, managed via Arc) to deploy a Webapp onto it. Where we can then see how the it is currently looking in the preview!

 

Let us make it real! The platform…

Azure : What do I put in front of my (web) application?

Introduction

In almost every design session, the following question pops up…

“What do I put in front of my web application to secure it?”

Today we will take a look at the different options at hand. Or better said … What is the difference between the following services?

Azure CDN vs Azure Front Door versus Azure Application Gateway (WAF) vs Azure Traffic Manager

 

TL;DR

If you do not want to go through the entire post, here is a brief summary of the different options ;

My gut feeling tells me this will already help out like a lot! 😉

 

Web Application Firewall (WAF) : Azure Front Door vs Azure Application Gateway

Both Azure Front Door and Azure Application Gateway state that they can be configured to act as a Web Application Firewall. They key difference here is that the Azure Application Gateway can do a “detection only”-mode and that it supports CRS 2.2.9, 3.0, and 3.1. This means that there are out-of-the-box rules that provide a baseline security against most of the top-10 vulnerabilities that Open Web Application Security Project (OWASP) identifies. With Azure Front Door, you need to configure the rules yourself to your liking.

In terms of networking, there also is a very important difference between both. An Azure Application Gateway can be deployed (injected) in(to) an Azure VNET (Virtual Network). By doing so, the traffic between this gateway and your internal backend will flow through a private network. With Azure Front Door, your backend is always based on a public endpoint. Though you can harden / lock down the connectivity between Azure Front Door and your application by restricting the ingress of the traffic.

 

Geographic Redundancy : Azure Front Door vs Azure Traffic Manager

If you want to publish your webapp across regions, then you can leverage Azure Front Door or Azure Traffic Manager to do so. The most important thing to know is that Azure Traffic Manager is DNS based and serves as a redirection mechanism. Azure Front Door will serve as an entrypoint (think reverse proxy). So when using Traffic Manager, you will typically look at another reverse proxy / WAF (like Azure Application Gateway) to cover the need for the secure entrypoint for your application. Next to that, the Azure Traffic Manager is more feature rich in terms of the routing mechanisms, though Azure Front Door (just like Azure Application Gateway) have the advantage of working at layer 7 (Reference : OSI Model), thus also do header/path based routing.

 

Caching Content : Azure CDN vs Azure FrontDoor

The first thing to realize is what the intent was of both solutions?

• Azure CDN is a Content Delivery Network and was designed to delivery content. Think in terms of media files (“video”) for instance.
• Azure Front Door was built as a scalable entry point for applications (like Office 365)

Both will do caching (check the links above), though they differ in the sweet spots. Azure Front Door will cache files up to 8MB (as a side trait), where you should think that this is mainly done to optimize the delivery of your “web app”. Azure CDN its core function is caching… It was built to ensure that your files would be distributed world wide and delivered from a local pop.

The funky thing here, is that (if you ignore the Verizon and Akamai flavors of Azure CDN) both Azure CDN and Azure Front Door share the same POPs! Though the caching mechanics of both work differently.

 

DDOS

All services will have DDOS protection (“Basic”), as this is native to any Azure service! It is a key component of the Microsoft backbone actually. Though you can augment the services that reside in your VNET with the “Standard” protection. That being said, do know that the Azure Application Gateway does not scale as dynamic as the other services mentioned here (Azure Front Door and Azure Traffic Manager). So this could become a bottleneck for your design.

 

Closing Thoughts

With more than 100 services in Azure, you are bound to have services that overlap in terms of capabilities. I do hope this post provides you with some guidance towards a the external facing endpoints of your application! The above things are the recurring patterns I see in discussions with the organizations I talk to when deploying web applications on Azure.

Putting Azure FrontDoor in front of your webapp

Introduction

Today we’ll be going through the process of putting Azure FrontDoor in front (pun intended!) of a web app.

 

Step One) Adding the custom domain

The first step  is to add a new custom domain to your Frontend hosts ;

Now if you go through this, you’ll see that AFD expects you to link the custom domain to the azurefd.net domain in order to proceed.

Using Azure DevOps to deploy your static webpage (SPA) to Azure Storage

Introduction

To, without shame, grab the introduction of the “Static website hosting in Azure Storage” page ;

 

Azure Storage now offers static website hosting, enabling you to deploy cost-effective and scalable modern web applications on Azure. On a static website, webpages contain static content and JavaScript or other client-side code. By contrast, dynamic websites depend on server-side code, and can be hosted using Azure Web Apps.

As deployments shift toward elastic, cost-effective models, the ability to deliver web content without the need for server management is critical. The introduction of static website hosting in Azure Storage makes this possible, enabling rich backend capabilities with serverless architectures leveraging Azure Functions and other PaaS services.

 

Which, to me, sounds great! As one of my projects (VMchooser) is actually a static site (VueJS based Single Page App) that could just as well run on Azure Storage (thus reducing my cost footprint). So today we’re going to test that one out, and afterwards integrate it into our existing CI/CD pipeline (powered by Azure DevOps).

 

Trying out the Azure Front Door Service

Introduction

With the statement “Scalable and secure entry point for fast delivery of your global applications”, Azure Front Door (Service) saw the lights of dawn! The features it promises to bring to the table?

• SSL offload and application acceleration at the edge close to end users
• Global HTTP load balancing with instant failover
• Actionable insights about your users and back ends

• Application firewall and DDoS protection
• Central control plane for traffic orchestration

My first thought was… Does this fill the gap where I’m currently leveraging CloudFlare for my personal deployments? So today’s post will be to see what the process of creating the service looks like in real life!

 

Let’s take it for a spin!

After browsing through the marketplace, we select the “Azure Front Door” and press the button to create one. Here I must say that the configuration flow here is a pleasant surprise. First we enter the “basics”…

Generating a docs website powered by Git & Markdown

Introduction

Did you know I’m a huge fan of the Microsoft / Azure docs? Did you also know that the docs websites are powered by GitHub repositories? Let that one sink in… So you can leverage the same way you collaborate on code, work on publishing documentation?!? How awesome is that!

After a bit of looking around, it appears DocFX is actually powered to do this. I don’t know if this is the tool used behind the docs website. Though there seem to be a lot of similarities. Anyhow, today’s post will be a quick walkthrough on how to setup DocFX with VSTS to publish your GitHub driven repo to an Azure Web App.

 

So what will we be needing?

Ingredients

• GitHub repository
• VSTS Account
• Azure App Service
• A tool to do the conversion : DocFX
• Chocolatey to install DocFX

 

Initialize the repository

Be sure to install DocFX on your dev station to initialize the repository. This is done by running “docfx init -q” inside of your repository.

 

Afterwards do your typical Git magic to sync your local version with GitHub (or equivalent). Now you’ll have a dummy skeleton ready for usage, and you can now structure it to your liking! My effort is going into making docs for VMchooser.

Drupal on Azure – Leveraging the Linux App Service for a Managed Platform Experience

Introduction

WordPress is probably the most popular CMS around. Though when I look at my home country, then I see a lot of Drupal deployments too. This might be due to the fact that the creation is of Belgian origin? Though for the region I live in, Drupal is amongst the most popular CMS systems.

That being said, Drupal is a very resource hungry system. When you enable the WebProfiler (part of the Devel module), then you can see that typical page will execute between 90 and 200 database queries. This puts a lot of stress on the underlying database system, but also on the local file system.

Due to this we see a lot of articles on how to improve the performance of Drupal. Most commonly seen is the implementation of ;

• Varnish on the front end side, as a web application accelerator / caching HTTP reverse proxy
• Redis or Memcache, as a way to cache data (in memory instead of hammering the database)

For today’s post, we’ll briefly discuss the various options and afterwards delve into a more advanced scenario where we leverage the Azure Linux App Service’s multi container capability.

 

What options do I have for running Drupal on Azure?

In essence there are various ways to run Drupal on Azure ;

Azure Active Directory : Group integration for daemon / server applications (aka Service Principals)

Introduction

Today’s blog post will be how you can leverage the authentication scenario of a Daemon, Service User or Server Application when our application/API is using Azure Active Directory for its authentication flows.

“An example of a daemon application is a batch job, or an operating system service running in the background. This type of application requests an access token by using its application identity and presenting its Application ID, credential (password or certificate), and application ID URI to Azure AD. After successful authentication, the daemon receives an access token from Azure AD, which is then used to call the web API.”

In essence, a “daemon application” will do a “clients credentials grant” whilst using an Azure Active Directory Service Principal. The “application id” of the service principal will serve as the “client_id” and a generated “secret” will service as the “client_secret”.

In addition to this, we want our application to grant permissions (authorization & identification) based on the group memberships of Azure Active Directory. Where this is pretty straightforward for our basic user objects. This requires a bit of attention when wanting to achieve the same for our service principal.

Combining Azure Traffic Manager, CloudFlare & Azure App Service for Geographic Scale!

Introduction

For today’s post, let’s take a look at an architecture example where you want to provide a geographic deployment of your webapp by using a cloudbased WAF (like Cloudflare, or Akamai, …).

 

High Level Setup

So what will we be setting up & testing today?

The user will receive a url that is powered by “Azure Traffic Manager”. That will have three endpoints ; one in Europe, one in the US and one in Asia. These endpoints will be powered Cloudflare and back by an Azure Webapp.  You’re question will probably be ; “Why use that sequence?” Because the Traffic Manager is DNS based and will do a “basic” HTTP check. If you would setup the Traffic Manager behind Cloudflare/Akamai/…, then you would see the source IPs of that service. Thus you would be unable to route the clients to the nearest location.

 

Azure App Service : Deploying a java webapp (geoserver) to Azure

Introduction

For today’s post, we’ll be deploying a java web-app to Azure. Here we’ll be leveraging our well-known “App Service” as the underlying PaaS component to host our web-app.

 

Sample Workload : Geoserver

For today’s example, we’ll be using “geoserver” as the grounds for our little proof-of-concept. In addition, we’ll even trow in the Azure PostgreSQL Database for the back-end store.