0 Comments Posted in:

Service Fabric is one of several ways you can run containers in Azure that I explore in my most recent Pluralsight course. However, it can seem a little bit intimidating to get started with, so in this post I'll run you through the basic steps you'll need to get started with hosting containers on it, including all the information that I wish I had known when I tried this for the first time.

What is Service Fabric?

According to this promo video, Service Fabric is...

“Azure Service Fabric is an application platform that simplifies building and deploying microservice-based applications to provide organizations with scalable, agile and reliable applications, whether they are run in Azure, on-premises or in other clouds.”

So it's a platform designed for you to run microservice applications on, but those applications don't have to be containers, and they don't even have to run on Azure - Service Fabric works just fine on premises and even works on your local development machine. Your services can also run on Windows or Linux, making Service Fabric an incredibly versatile platform.

If you're wondering whether its a mature enough platform for hosting your own mission critical applications, its worth considering that Microsoft themselves have built many of their key cloud-based products on top of Service Platform, including Azure SQL Database, Azure Cosmos DB, Cortana, Microsoft Power BI, Skype for Business, and much more.

A lot of the articles and training material you'll find on Service Fabric focus very strongly on some of the powerful programming models it offers such as "stateful services" with "reliable collections" or the "reliable actor" model. And this initially led me to think that if you chose Service Fabric it meant you had to write your application using these models. But that's not the case. Although Service Fabric offers these as options, you can still use it to host applications using all the same techniques you are already familiar with, including containers.

Setting up a Development Environment

There are three steps to setting up your development environment for working with Service Fabric. First, using the Visual Studio 2017 installer, ensure you have the "Service Fabric Tools" option selected.

Service Fabric Tools

Once you've done this, there will be Service Fabric templates available when you create a new project, but you will see a warning telling you that you also need to install the Service Fabric SDK:

Service Fabric New Project Dialog

The dialog helpfully contains a link which will download the Web Platform Installer and launch it with the Service Fabric SDK ready selected:

Installing Service Fabric SDK

Once you've got this installed, you'll actually have the ability to run a local Service Fabric cluster on your own development machine. There is a new system tray icon that you can use to start or stop that container.

Service Fabric system tray icon

Two additional important things to remember.

First, you'll need to run Visual Studio in Administrator mode when you want to work with your local Service Fabric cluster, as it needs administrator privileges to make some configuration changes to the cluster.

Second, if you want to run containers, you will also need to ensure you have Docker for Windows installed.

Creating a cluster

To run a containerized Service Fabric application we need a Service Fabric cluster, and the good news is that we already have one on our development machine courtesy of installing the Service Fabric SDK. But in this post, I'm going to assume that you want to get your Service Fabric application running in Azure.

There are two ways to do that. First, is to take advantage of the brilliantly named "Party Clusters". This allows you to use a free shared cluster. Just sign in, pick whether you want a Windows or Linux cluster, and you'll get connection details including the certificate to deploy to it and access the dashboard.

Service Fabric Party Cluster

But you can also create your own cluster in the Azure Portal. First create a new resource and search for Service Fabric Cluster

Create Service Fabric cluster in Portal

Then you need to provide basic information such as a name for your cluster and credentials for the virtual machines

Cluster basic details

You also need to select an operating system. Make sure you choose one that supports containers if you're running Windows containers.

Operating System selection

Next you're specifying details of the nodes in the cluster. You can pick the Virtual Machine size (note that you might need to select a VM that supports virtualization if you want to use the Windows Hyper-V container mode). And you can pick the initial number of machines in your cluster. At this point you can also select the ports you want to open up for your application and it will automatically set up the load balancer configuration.

Cluster node settings

Then there's the security settings. And here we need to configure a certificate, that can be used to deploy to our cluster as well as to access the dashboard. The portal will offer to create a certificate for you in a Key Vault, as well as creating a Key Vault if you haven't got one. You can opt to use an existing certificate if you've got one you want to reuse.

Security settings

If you do create a Key Vault at this point, you'll need to set up the following Access Policies for this to work.

Configure Key Vault access policies

Once you've created the certificate, you should download it (the portal provides a link on the review page) and install it on your local development machine (it's easy to do: just double-click it once its downloaded and accept all the defaults - the password is blank).

Review Service Fabric Cluster settings

With that done, we're ready to create a containerized app to deploy to Service Fabric.

Creating containerized services

For the purposes of keeping this post simple, I'm going to assume that we've already created all the container images we want to deploy, and so its simply a case of telling Service Fabric where to find them. Of course, it's equally possible for your Visual Studio project to contain all the code for each service, and to build the container images itself before deploying them to Service Fabric.

The first step is simply to create a new Service Fabric project in Visual Studio, and we need to choose the "container" option for our first service. To add additional services, just right-click click on the Service Fabric project in Visual Studio and click "Add new Service Fabric Service" again selecting "container".

Adding a new Service Fabric Service

What you end up with when you do this is a single Service Fabric project in Visual Studio that contains a bunch of XML files. There is an "application manifest" which defines what all the services in your application are. And for each service you added there is a "service manifest".

These manifest files may need a bit of tweaking, but on the whole its fairly self explanatory what you need to do to change them.

To test this out, I created a very simple two service application consisting of a "front end" web application which makes a call through to a "back end" web API.

If you look at the ServiceManifest.xml for the front end web app you'll see that I've specified the ImageName which points to an image on Docker Hub (for simplicity - you can of course use private images hosted in Azure Container Registry), specified a couple of environment variables, and set up an Endpoint which determines the port on which we want to expose this service. Note that this isn't necessarily the same as the port the app in the container is listening on - it supports port mapping.

I've also got a very similar ServiceManifest.xml for the back-end web API

And then we need an ApplicationManifest.xml file to define our application. In here we specify what service make up the application. We can choose how many instances of each service we want (I just left it at the default which seems to put an instance on each node), and in PortBinding we connect the port the container is listening on to the port of the Endpoint we defined.

Notice also we can specify a ServiceDnsName that makes it super easy for our services to talk to one another. My web app container can simply call the backend service on "http://backend:8081".

Obviously there's a lot more depth that you can go into here, but that's the bare minimum needed to define a two container application. Next, we need to deploy it to our cluster.

Deploying and testing the application

One of the great things about Service Fabric is that you can run it locally, but deploying it to Azure is also very straightforward. When our Service Fabric project is created, there is a folder containing some "publish profiles", including a cloud.xml file.

What we need to do is update this to set the ConnectionEndpoint of the cluster we created (the default port to use for this is 19000), and fill in the thumbprint of the certificate we downloaded and installed. You can see my custom cloud.xml file here.

With this in place, its as simple as right-clicking the project and publishing within Visual Studio, just like you may be familiar with for publishing to other services like App Service.

Now if all goes well, our services will start up successfully and we can visit the web-page of our front-end application on port 8080 which was the port we opened up in the service manifest for our web app.

But Service Fabric also comes with a really helpful dashboard called the Service Fabric Explorer which is available by default on port 19080 of your cluster and is secured using the certificate we downloaded. When you load it you should see a nice visualization showing us details of the nodes in our cluster, the applications and services installed. Note that a Service Fabric cluster can be used for running multiple applications, so you can save money for your development and test environments by packing multiple applications onto a single cluster.

Service Fabric Dashboard

You can also navigate in this dashboard into the details of all the nodes and services, including drilling right down to see the container logs for an individual replica of one of our services:

Container Logs

If you want to deploy an updated version of your application, I found the simplest way was to update the service and application manifests, and update their version numbers in the XML before publishing again.

Demo code

If you'd like to try this out for yourself, then you can find all the code here on GitHub and you can also watch me work through this scenario in my Microsoft Azure Developer: Deploy and Manage Containers Pluralsight course.

Learning more about Service Fabric

Of course, there a huge amount to learn about Service Fabric, and this tutorial only touched on a few of the basics, so if you'd like to go deeper, here's a few resources I found helpful.

Want to learn more about how easy it is to get up and running with containers on Azure? Be sure to check out my Pluralsight courses Microsoft Azure Developer: Deploy and Manage Containers

0 Comments Posted in:

I'm really pleased to announce that my latest Pluralsight course has just been released: Microsoft Azure Developer: Deploying and Managing Containers. And the great thing is that you can watch it free even if you're not a Pluralsight subscriber! This is because it's being made available as part of the superb Microsoft Learn platform.

All you need to do to take advantage of this offer is to visit the Pluralsight Azure sign-up page, and you'll be able to watch my new course), and my Create Serverless Functions course, which is all about Azure Functions, and is also available free.

One of the reasons I am so excited about this course is that it covers several amazing technologies. In just over three hours I've crammed in as much as I can about the following topics:


I'm sure you don't need me to tell you what an exciting and revolutionary technology Docker is. In a short period of time it's transformed the way we think about building and deploying applications.

In the course I introduce the basics of running containers locally with Docker for Windows, and how to create your own images with Dockerfiles.

Azure Container Registry

Azure Container Registry is a great place to host your private Docker images in the cloud. It's also got some great features to support building your containers in the cloud.

In the course I show how to use the Azure CLI to create an Azure Container Registry, and push images to it.

Azure Container Instances

Azure Container Instances is the easiest way to get containers running in Azure. You don't need to pre-provision a server, and you pay only while your container runs.

In the course I show how to use the Azure CLI to create Azure Container Instances, execute commands against them. Of course, I also created a whole Pluralsight course about Azure Container Instances if you'd like to go deeper.

Azure Web App for Containers

Azure App Service is a really great feature-rich platform for running web applications on. It's ideal for running ASP.NET applications, and it's also the underlying platform for Azure Functions. But more recently it's expanded its capabilities to also be able to host containerized web apps. This opens the door to you using any web development framework you want. Linux support is already available, and Windows container support is currently in preview.

In the course, I show how you can use Web App for Containers to host a WordPress container, connecting to the Azure Database for MySql service, as well as how to set up continuous deployment with deployment slots to automatically upgrade to new versions of a web app as you update your container images hosted in ACR.

Azure Service Fabric and Service Fabric Mesh

Service Fabric is a very powerful and scalable microservice hosting platform, and it can do far more than just run containers. It's the platform that runs many of Microsoft's own flagship services, and it runs not only in Azure, but can be hosted on premises in your own data-center.

In fact, the sheer breadth of programming models it offers can make it seem quite intimidating at first, and there certainly is a fair bit to learn to get started with it. However, because it also runs locally on a development machine, you can easily try it out, without the complexity and cost of creating and configuring a cluster in the cloud.

But the great news is that a very exciting new service - Service Fabric Mesh, which runs on top of Service Fabric, offers a greatly simplified, container-focused, serverless microservices platform. You just define what services make up your application in YAML or JSON format, and then you can deploy your application to Azure without needing to pre-provision any infrastructure at all. It's still in preview and I did run into a number of issues with it, but as the platform matures, I think it could quickly become a very compelling option for hosting microservice containerized applications in Azure.

In the course I show how to create a Service Fabric cluster in Azure and deploy containers to it. Then I show how we can run a microservice application on Service Fabric Mesh in Azure, and easily scale one of the services.

Azure Kubernetes Service

Finally Azure Kubernetes Service takes Kubernetes - the leading open source container orchestrator, and makes it trivially easy to get up and running in the cloud. The pricing model means that you essentially get your master nodes for free, paying only for worker nodes.

It's super easy to set up and manage with the Azure CLI and the familiar kubectl tool, and once you've got your AKS cluster set up you can tap into the full power of Kubernetes, as well as benefit from integrating with many other Azure services, such as Azure File Shares or Disks for mounting volumes, Azure Container Instances to add elastic scale, Azure Monitor to get rich logging and diagnostics, and Azure Active Directory for security.

In the course I show how easy it is to create an AKS cluster and scale out the number of nodes. And we also see how to use kubectl apply to really quickly and easily deploy a microservice application and update it.


I've made all the PowerShell scripts and source code for running all the demos available here on GitHub so you can easily try out the same demo scenarios yourself as you watch the course.

0 Comments Posted in:

I've provided a few tutorials on this blog showing how easy Docker makes it to get a WordPress blog up and running. These show off two different ways of running containers in Azure - first just by using a regular Virtual Machine, and second with Azure Container Instances:

Web App for Containers

But Azure offers several other ways to host your containers, and for WordPress, a great choice would be to use Web App for Containers and Azure Database for MySQL for the database.

"Web App for Containers" is simply a way of hosting your web application on App Service as a container (Linux or Windows). The advantage of doing this is that App Service offers many features ideally suited to web applications such as configuring custom domains and SSL certificates, slot swapping, CI/CD functionality, auto-scaling, IP address whitelisting, AD authentication and much more.

And the reason for using "Azure Database for MySQL" rather than also using a container for the database is that we might want to scale up the web server to multiple instances, but we'd want each of the containers to be talking to the same database.

So let's see how we can use the Azure CLI to set up WordPress running on Web App for Containers, using Azure Database for MySQL as the back-end.

Create the App Service Plan

I'll be showing PowerShell commands, but since I'm using the cross-platform Azure CLI, these commands can also be run with minimal modification in a Bash shell.

When we create the app service plan, we will need to specify the --is-linux flag as we plan to use a Linux container image.

# create a resource group to hold everything in this demo
$resourceGroup = "wordpressappservice"
$location = "westeurope"
az group create -l $location -n $resourceGroup

# create an app service plan to host our web app
az appservice plan create -n $planName -g $resourceGroup `
                          -l $location --is-linux --sku S1

Create an Azure Database for MySQL

We then need to create a MySQL server with the az mysql server create command, and we will need to set the --ssl-enforcement flag to Disabled for this demo to work.

# we need a unique name for the servwer
$mysqlServerName = "mysql-xyz123"
$adminUser = "wpadmin"
$adminPassword = "J9!3EklqIl1-LS,am3f"

az mysql server create -g $resourceGroup -n $mysqlServerName `
            --admin-user $adminUser --admin-password "$adminPassword" `
            -l $location `
            --ssl-enforcement Disabled `
            --sku-name GP_Gen4_2 --version 5.7

n.b. if the az mysql server create command takes a long time to return, I've found I need to cancel it and try it again.

And we will also need to open up a firewall rule to allow our web app to talk to the MySQL server. The simplest approach is to use the special address to allow all internal Azure traffic, but a better solution is to get the outbound IP addresses of our Web App and explicitly create a rule for each one.

# open the firewall (use to allow all Azure traffic for now)
az mysql server firewall-rule create -g $resourceGroup `
    --server $mysqlServerName --name AllowAppService `
    --start-ip-address --end-ip-address

Create a Web App from a Container

Now let's create a new web app. We need to give it a unique name, and we'll use the official WordPress image from Docker Hub

az webapp create -n $appName -g $resourceGroup `
                 --plan $planName -i "wordpress"

Although this will start up our container, we're not actually ready yet as we need some environment variables to be correctly configured. Annoyingly, the az webapp create command doesn't allow us to do that at the time of creating the app (please add your support this GitHub issue which also highlights that you can't specify a private ACR image with this command either).

Configure the Environment Variables

Configuring environment variables for our container is done by setting the web apps "Application Settings", which will be surfaced as environment variables within the container. The WordPress container image is expecting three environment variables for the database host name, username and password

# get hold of the wordpress DB host name
$wordpressDbHost = (az mysql server show -g $resourceGroup -n $mysqlServerName `
                   --query "fullyQualifiedDomainName" -o tsv)

# configure web app settings (container environment variables)
az webapp config appsettings set `
    -n $appName -g $resourceGroup --settings `
    WORDPRESS_DB_HOST=$wordpressDbHost `
    WORDPRESS_DB_USER="[email protected]$mysqlServerName" `

Once we've set this, presumably the container gets restarted to make those environment variables available. In any case, I've found that once I've made these setting changes, after a couple of minutes, the WordPress site is up and running.

Test it out

We can find out the domain name of our WordPress site with the az webapp show command like this:

$site = az webapp show -n $appName -g $resourceGroup `
                       --query "defaultHostName" -o tsv
Start-Process https://$site

And you should see that now you have a fully working WordPress installation that you can set up and try out.

WordPress installation

The setup wizard only takes a minute, and you'll be editing new posts in no time:

Editing a Post

Scale out

Because we've used Azure Database for MySQL for our database rather than a containerized instance of MySQL, our web apps are entirely stateless. That means we can safely scale out to multiple instances of our web server, which is easily achieved with the az appservice plan update command. Notice that you scale out the App Service plan as a whole, rather than at the web app level.

az appservice plan update -n $planName -g $resourceGroup --number-of-workers 3

Clean up

Of course, when you're done with this instance of WordPress, you'll want to clean up the resources you created. Since we put everything (the App Service Plan, the Web App and the MySQL Server) in the same resource group, we can clean it all up with a single command like this:

az group delete --name $resourceGroup --yes --no-wait


Azure Web App for Containers is an ideal hosting platform for containerized web applications like WordPress. You benefit from many added value web hosting features that App Service has to offer, as well as the cost benefits of being able to host multiple containerized web apps on the same App Service plan.

Want to learn more about how easy it is to get up and running with containers on Azure? Be sure to check out my Pluralsight courses Microsoft Azure Developer: Deploy and Manage Containers