Azure Service Fabric : Deploying your first container…


In the past I’ve already done several posts about containers. This by using various orchestrators & workflow management tools. Today’s post will be about deploying a Linux container with Service Fabric… The main goals is to provide you with the look & feel of the initial steps. In a future posts, I’ll delve into the more advanced stuff (like data persistence & inter-container connectivity).


For this small “proof-of-concept”, we’ll be deploying a WordPress container to a Service Fabric cluster. Be aware that the way we’ll be doing this deployment isn’t a production ready architecture. Why? The way we’ll be deploying does not incorporate any state (data persistence). So once we upgrade that container, we’ll have data loss…



For this post I’ll be assuming you have already setup your Service Fabric development environment & cluster. So be sure to have these things setup before you embark on your journey!


Creating our project

Let’s kick it off by launching Visual Studio. We’ll be using this one to create the packages, as this will be a huge help instead of creating it by hand. Go to “File”, “New” & “Project…”

Now browse to the “Service Fabric Application”  template ;

Next up, select “Container” as service template. Once selected, you can enter an image & service name.

Afterwards just press “Ok” to get it started.

Wait a bit and your project is set up!


Adjusting the vanilla template

Once the project is created, open up the “ApplicationManifest.xml” and the “ServiceManifest.xml” ;

Here we’re going to add the “PortBinding” to the “ApplicationManifest.xml” file.

And we’ll also add these details to the “Endpoint” in the “ServiceManifest.xml”.

Once you made your changes, “Build” your solution…

Your build will succeed…

Though take a look at the “Error List”, you’ll receive some information/warning messages on the xml schema.


Avoiding XML Schema messages/warnings

If you want to avoid the messages as seen in the previous chapter. Then generate an “.xsd” (schema) file for each of the xml files. Do this by selecting the xml file, and going to the XML menu. Here you can generate a schema by doing “Create Schema”.

Which will generate the .xsd file for that .xml file…

Save those files…

And now go back to the XML menu, and select “Schemas…”. Here you can select the schemas you want to use.

Now repeat your previous build actions, and your messages part will stay clean. 😉


Deploying the container

Now let’s do the fun stuff! Deploying the container… Right click on the package and do “Publish…”

Select your Connection Endpoint ;

And it will be validated (if ready) by showing the nice green checked icon. Now press “Publish”.

Now wait for it to get published…

And you’ll see the dashboard in your Service Fabric Dashboard change from “0 applications” to “1 application”


And you’ll see the container being added one by one to the nodes.

Once the “Status” of each container is set to “Ready”, you’ll know that the deployment is ready. Another status will probably indicate that the container is being pulled down to the host.

As our container was ready, let’s browse to our endpoint… And “Eureka!”, our container has been published.



As an appendix, underneath the changes to the files as outputted after the creation of the project.



<?xml version="1.0" encoding="utf-8"?>
<ApplicationManifest ApplicationTypeName="WordpressType" ApplicationTypeVersion="1.0.0" xmlns="" xmlns:xsd="" xmlns:xsi="">
    <Parameter Name="WordpressService_InstanceCount" DefaultValue="-1" />
  <!-- Import the ServiceManifest from the ServicePackage. The ServiceManifestName and ServiceManifestVersion should match the Name and Version attributes of the ServiceManifest element defined in the ServiceManifest.xml file. -->
    <ServiceManifestRef ServiceManifestName="WordpressServicePkg" ServiceManifestVersion="1.0.0" />
    <ConfigOverrides />
      <ContainerHostPolicies CodePackageRef="Code">
        <PortBinding ContainerPort="80" EndpointRef="WordpressServiceTypeEndpoint"/>
    <!-- The section below creates instances of service types, when an instance of this application type is created. You can also create one or more instances of service type using the ServiceFabric PowerShell module. The attribute ServiceTypeName below must match the name defined in the imported ServiceManifest.xml file. -->
    <Service Name="WordpressService" ServicePackageActivationMode="ExclusiveProcess">
      <StatelessService ServiceTypeName="WordpressServiceType" InstanceCount="[WordpressService_InstanceCount]">
        <SingletonPartition />


<?xml version="1.0" encoding="utf-8"?>
<ServiceManifest Name="WordpressServicePkg" Version="1.0.0" xmlns="" xmlns:xsd="" xmlns:xsi="">
    <!-- This is the name of your ServiceType. The UseImplicitHost attribute indicates this is a guest service. -->
    <StatelessServiceType ServiceTypeName="WordpressServiceType" UseImplicitHost="true" />

  <!-- Code package is your service executable. -->
  <CodePackage Name="Code" Version="1.0.0">
      <!-- Follow this link for more information about deploying Windows containers to Service Fabric: -->
    <!-- Pass environment variables to your container: -->
      <EnvironmentVariable Name="VariableName" Value="VariableValue"/>

  <!-- Config package is the contents of the Config directoy under PackageRoot that contains an independently-updateable and versioned set of custom configuration settings for your service. -->
  <ConfigPackage Name="Config" Version="1.0.0" />

      <!-- This endpoint is used by the communication listener to obtain the port on which to listen. Please note that if your service is partitioned, this port is shared with replicas of different partitions that are placed in your code. -->
      <Endpoint Name="WordpressServiceTypeEndpoint" UriScheme="http" Port="80" Protocol="http"/>

The full project can be found at the following location :


Closing Thoughts

I would say that the road with the least resistance is probably by using Visual Studio with Service Fabric deployments. This is a bit in contrast with other orchestrators which use (in my perception) more easy templating structures. That being said, it is possible to use the “docker compose“-format with Service Fabric.

That being said, the system feels very robust and stable. On each action you notice that the system is very cautious about every action you do. It shows that operational stability is a primary focus of the system.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.