Continuous integration and continuous delivery (CI/CD) are considered by most to be the backbone of DevOps. Things start to get really interesting when you combine these practices with programmable infrastructure and a suite of services that allow you to automate the entire lifecycle of an application.

The goal with this guide is to give you a practical example of what that all looks like when you’re building, testing, and deploying applications with Azure DevOps Services. I’ll walk you through the end-to-end process of building a fully automated build and release pipeline for a Node and Express application. We’ll use Azure DevOps Services to create the CI/CD pipeline and Azure App Service for deploying to development/staging and production.

To follow along, you’ll need a GitHub account and Azure Subscription. The demo application is open source, so the Azure DevOps pipeline infrastructure we build will be covered under the free tier.

Create Your Azure DevOps Organization

The first step is to navigate to dev.azure.com and sign in to Azure DevOps. If you’ve never done this before, you’ll need to create a new organization.

You need to have at least one organization, which is used to store your projects, structure your repositories, set up your teams, and manage access to data. The guidance from Microsoft is to keep things simple and start with a single organization. For more advanced scenarios, take a look at plan your organization structure in Microsoft’s documentation.

After clicking on continue, you may end up with an organization name that was generated at random. You can change this as shown in Figure 2.

Simply navigate to Organization Settings > Overview and update the name.

Fork the Node & Express Demo App Repository

I wanted to demonstrate an application that was somewhat realistic but not overly complex for this walkthrough. The Node and Express app is a simple website for a fictitious company. This app uses Express and Handlebars to serve up a few common pages you’d see on any company website. Also included are some unit tests that ensure those routes are working and serving up the right content.

You can head over to my GitHub account to fork this repository.

Next, we can move on to deploying the infrastructure to support both development and production deployment slots using Azure App Service.

Deploy the App Service Infrastructure

We’re going to use an Azure Web App for Linux resource to power our Node and Express application. We’ll set things up so our CI/CD pipeline can build and deploy the app into a development/staging slot. Then we’ll set up up a manual approval into the production slot.

We’ll use an Azure Resource Manager (ARM) template to build the App Service infrastructure.

Navigate to the node-express-azure repository you forked in the previous step. You’ll see a “Deploy to Azure” button about halfway down the screen.

Clicking the “Deploy to Azure” button will redirect you to the Azure portal as shown in Figure 5.

Notice that you’ll need to set a globally unique hostname for your web application, along with a name for the new app service plan. I’d recommend deploying these resources into a new resource group. That way when you’re done with this walkthrough, you can clean up the Azure resources easily by deleting the resource group.

Click “Purchase” to launch the template to agree that you’ll have to pay for the App Service resources that this template deploys on your behalf.

After you launch the template you should see a successful deployment message, and you should have a new resource group similar to the one shown in Figure 6. Notice that there is an App Service Plan, a web app that represents the production deployment slot, and a slot for development called “dev”.

Quick side note about the ARM template: the Deploy to Azure button references the azuredeploy.json ARM template in my GitHub repository. If you want to update the template, update the version in your own repo, and don’t forget to change the target of the button in the source of your README.md file.

Create a Build Pipeline

We’re ready to move on and set up a build pipeline in Azure DevOps. Head back to dev.azure.com and create a new project inside your organization. Use the settings shown in Figure 7.

After clicking on the “Create project” button, you’ll see a summary page for the project. Navigate to Pipelines and click on Builds as shown in Figure 8.

Next, click the button to create a new build pipeline. You’ll be prompted to choose a repository. Select GitHub. You’ll see a screen like the one in Figure 9 where you’ll need to authorize the Azure DevOps service to connect to your GitHub account on your behalf. Click Authorize.

After your connection to GitHub has been authorized select the node-express-azure repo that you forked in the first step. You should end up seeing a “New pipeline” screen like the one shown in Figure 10.

The new pipeline wizard should recognize that we already have an azure-pipelines.yml in the repository. This file contains all of the settings that the build service should use to build and test our application, as well as generate the output artifacts that will be used to deploy the app later in our release pipeline.

After you click “Run” to kick off your first build, you should see a screen like the one shown in Figure 11.

Notice that a lot went on with the build. The service used an Ubuntu 16.04 build agent to grab the code from GitHub, installed our development dependencies, and then ran our unit tests to validate the application. Finally, the code was bundled into an output artifact and published so we can use it as an input artifact for our upcoming release pipeline.

Click on the release button at the top of this screen to create a new release pipeline.

Create a Release Pipeline

When you get into the release pipeline screen, you’ll need to select a template. For this scenario, we are going to choose “App Service deployment with slot”.

Click on the apply button to create the new deployment stage within the release pipeline. On the next screen, you’ll be able to configure this stage. Change the name to “development” as shown in Figure 13.

While on this screen, click on the link that says “2 tasks” inside your development stage. This will take you to a screen where you can configure the deployment task. Make sure you fill out all the fields as shown in Figure 14.

Next, highlight and remove the second deployment task for swapping the slots.

Finally, click Save.

Head back over to the “Pipeline” tab at the top left of the screen. Inspect the deployment triggers for the artifacts as shown in Figure 17.

Notice that continuous deployment is enabled by default. Going forward, each new build will trigger a deployment to our development slot in Azure App Service.

First, let’s trigger a manual release.

Create Your First Release to Development

Click the “Release” button on the top right of the release pipeline screen and create a new release. Use the settings as shown in Figure 18.

Click on the “Create” button to deploy the application to the development deployment slot. You should see a successful status in the properties of the release.

Navigate to the public URL of the “dev” deployment slot in your web browser. The hostname will have “-dev” appended to it. For example, my web app is named “node-express-demo” and the “dev” deployment slot URL is https://node-express-demo-dev.azurewebsites.net.

You should see the sample web application when you visit the “dev” slot URL. The production slot will show the default Azure App Service splash page since it is virtually untouched at this point. Let’s change that in the next step.

Create a Release Stage for Production

Head back over to the Azure DevOps portal and go to Pipelines > Releases. Click on the “Edit” button to modify the pipeline. Highlight the Development stage and click the dropdown to clone the stage.

Rename the stage to “Production”.

Next, click the pre-deployment conditions button for the Production stage. Enable pre-deployment approvals and add yourself as an approver.

We’re doing this because we don’t want automated deployments going straight into production. We’re not building a continuous deployment pipeline for production. We’re building continuous delivery pipeline.

Continuous delivery is a process that ensures our application is production ready. When we are doing a scheduled deployment we can do so with confidence since we know the application has been through a pipeline of tests before-hand.

Next, click on the “task” link on the Production stage. We need to modify this task so that it does not deploy our code into the development slot.

Simply uncheck “slot” and this will infer that the production slot of the web app should be used during the deployment. Click save when complete.

Validating the Pipeline

Navigate to your GitHub account and into the views folder of the demo application. Edit the index.handlebars file to update the app to version 2.0.0.

Committing the change in this repo should automatically trigger a build, perform our tests, and publish a deployment package. We can confirm this by reviewing the build status.

After the build, you should see a new release. The development stage should be green indicating that the deployment succeeded. The production stage should be blue and show that it’s pending approval.

Click approve to kick-off the production deployment.

Go back to your pipeline view and you should see the deployment to production succeeded.

Finally, head over to the web app URL for the production slot to confirm the correct version is running.

You should see version 2.0.0 on the homepage.

Set up a Build Badge for Your Project

Have you ever seen those build pass/fail badges when browsing projects on GitHub? They’re really cool because you can tell at a glance if the code is still working or if it’s old and busted.

Let’s set up a badge for this project.

Go back to your Builds section and click the status badge button.

Copy the markdown code for the status badge.

Now, go back to GitHub and modify the README.md file in your node-express-azure repo. Paste the markdown you copied from the status badge page.

Commit the change and view the README. You should see a build passing status icon.

If you’re still reading after all this time, respect! You now know who to build a CI/CD pipeline on Azure.

You can simply delete all the resources to clean things up. Delete the resource group you created for this project, delete the Node demo project in the Azure DevOps portal, and delete the GitHub repo that you forked from my account (unless you want to keep a copy).

Where to go from here

Isn’t this awesome stuff? There’s so much more. For now, check out these resources to dive deeper.

• Get started with Azure DevOps
• DevOps Resource Center
• Microsoft Professional Program for DevOps

Originally published at cloudskills.io.

Public and private cloud platforms have changed the IT landscape. With virtualization and cloud computing, it’s easier than ever to spin up a fully functional application environment with a single button click or API call. The world of server deployment and administration is much different than it was ten years ago, and it will never be the same.

This is great news because businesses can now move much faster than ever before. And the reality is, many of them must do so in order to keep up with their competitors.

The challenge is, you’ll want to start thinking like a software developer if you plan to stay in the trenches over the long term in the tech industry.

Here’s why. Most technologies are shifting to a new paradigm where software development practices are being applied to infrastructure. Speed, agility, consistency, and predictability are all characteristics of platforms that power modern day applications. The infrastructure engineers of the future will be expected to have deep automation expertise.

IT pros who want to thrive in the tech industry in the coming years should learn the core principles of infrastructure development. Those who do will hold in-demand skills in a world where almost everything is software defined.

Here are four areas to focus on to start building infrastructure development skills.

Infrastructure as Code

Imagine being able to click a button in a web console, and like magic, you have a fully built server environment, complete with Domain Controllers, SQL Servers, and a new SharePoint farm ready to serve users.

Sounds far-fetched, but this is something that you can do today using an Azure Resource Manager (ARM) template.

Here’s how it works. All the infrastructure required to power the servers is declared in a plain text file. Technically, it’s a JSON template, which means it’s really just a set of key/value pairs. Think of it as a list of resources with their required settings. For example, in the file, there are blocks of code that describe the virtual network, storage, servers, and along with all of their detailed settings.

All of the infrastructure for the deployment is referenced in the template. It’s human readable, and anyone with a basic understanding of the syntax can look at the template and understand it’s intent.

These templates can be deployed interactively in a web browser, or via an API call as part of an automated process.

With infrastructure written in code, you always know exactly how the environment is supposed to be configured. You literally have a blue-print of the entire environment that you can execute if you ever need to rebuild it.

Imagine the possibilities this opens up when you want to test something.

Your first step to becoming an infrastructure developer is to start learning the basics of infrastructure as code. If you’re working with Azure, start educating yourself about ARM templates. Try to build one that does something simple, like building a standalone server.

Configuration Management

Servers that are launched from an infrastructure template also need to be configured. They need software installed and configured, and there needs to be a mechanism to keep them in their desired state. That’s where configuration management comes into play.

For example, that ARM template that spins up the SharePoint environment is mostly focused on building the server infrastructure. It’s creating the virtual network, storage, VM’s, and so on. The servers actually boot with a plain operating system.

Once the servers are up and running, a configuration management solution is used to boot strap the applications. In this case, the technology happens to be PowerShell DSC.

Most configuration management solutions follow similar patterns. Like infrastructure templates, configuration management code tells each server what software should be installed, and how it should be configured.

As an infrastructure developer, you’ll need skills with a configuration management solution like PowerShell DSC. The good news is that once you’ve learned one, it’ll be easier to pick up another. For example, DSC implements many patterns used in other configuration management tools like Chef, Puppet, and Ansible, to name a few.

Infrastructure as code templates, along with startup scripts or configuration management scripts, can provide an end-to-end automated solution for an application and all of its dependencies.

Version Control

When developers build applications, they typically do so in teams. In order to make life easier for everyone, the code is typically stored in a central location, like a version control repository.

It’s a common practice for developers to make very small, incremental changes to the code base for an application. Those changes get committed into the code base in the version control repository. If there’s an issue, the change can be reverted easily, since it was a small change.

Each time code is committed to the repository, meaningful notes are included about the change. This gives everyone a clear picture of what changed from one version to the next. Teams can even compare the new version of the code with the previous one side-by-side to see what was done.

This is exactly what infrastructure developers need to do as well. All of your infrastructure templates and configuration management scripts should live in a version control repository. Git-based version control systems, like GitHub, are widely used.

As an infrastructure developer, you’ll want to learn how to use Git, which is a version control tool. You can use it to store your code in a repository on GitHub, which is simply a platform for hosting git-based version control repositories.

Continuous Integration and Delivery (CI/CD)

When a software developer commits a small code change to a version control repository, that change is often tested. For example, if it’s a C# application, an automated process can take the code and make sure it compiles without any errors. It can also run other tests to make sure the code was written correctly. This process is known as continuous integration (CI).

The idea with CI is that developers get fast feedback on whether or not their changes are working. If they get build errors or the tests fail, they know they need to address thing right away.

Once the code has passed through those basic checks, it might be useful to perform further analyses, like performance or user interface tests. This, of course, requires infrastructure to run the code.

As a next step in the process, the team could invoke an infrastructure as code template to build a clone of the production environment. Once the servers are up and running, the latest version of the code can be deployed and tested.

If everything checks out, the team knows they have a known-good version of the code that is production ready, which is the basis for Continuous Delivery (CD).

As an infrastructure developer, you’ll want to be able to work with software developers and understand their world. To do that, learn the basics of the CI/CD release pipeline workflow. It’s simply a chain of events that takes code committed in version control to being fully validated and considered ready for production use. Azure focused infrastructure developers will want to look into the Azure DevOps platform.

Where to go from here

There’s a lot to learn as an infrastructure developer. The good news is; most organizations are still in the very early stages of figuring out how to do this efficiently. There will be big opportunities for those who decide to take advantage of this shift in the industry. Here are some resources to help you get started:

• Get started with Azure DevOps
• Build Azure Resource Manager templates
• Best Practices For Using Azure Resource Manager Templates

Infrastructure as Code is the topic for my next podcast episode on CloudSkills.fm. Please subscribe if you’re interested in this topic and feel free to send me your questions. I’ll answer them on the show.

Originally published on LinkedIn and CloudSkills.io

If you’re thinking about investing your time to pick up new skills, you can’t go wrong with learning how to build, run, and manage containers.

That’s probably not a big surprise. Based on all the excitement, headlines, and success stories coming out of tech news every day, there’s no doubt we’ll see even more container adoption going forward. But, it’s still very early in the game. And that means there’s a massive opportunity for those who embrace this new approach to building modern applications.

My goal with this tutorial is to hopefully spark your interest in this topic or give you some new ideas to try out on your own. I’ll show you a quick and easy way to store and run your container images on Microsoft’s Azure platform.

We’ll take a look at how to build a container image locally, push that image to the Azure Container Registry, and then run and continuously deploy updates to that container using Azure Web App for Containers. It’s a great way to run a single container for a web application.

We’ll keep things simple, but practical. And, if you want to follow along, all you’ll need is Git and Docker Desktop installed locally, along with an Azure account.

Building the Azure Container Registry (ACR) Resource

Container images provide the foundation for applications running inside Docker containers. You can think of an image as an executable package that includes everything you need to run an application. Your container images include application code, the runtime environment, libraries, configuration files, and environment variables. Containers that you spin up to power an application are merely a running instance of a container image.

Container images live in public or private container registries, and servers running the Docker engine download those images to start and run containers. The default container registry for Docker containers is hub.docker.com, which offers over 100,000 container images from ISVs, open-source projects, and community contributors. You can use this service to store your images in public or private repositories.

Microsoft also offers the Azure Container Registry (ACR), which is a managed Docker registry service based on the open-source Docker Registry 2.0 platform.

Using ACR for container deployments allows you to store your custom container images privately in the Azure cloud. ACR natively integrates with multiple Azure services, and teams can use ACR tasks to automate deployments when building new images, or when code is committed to version control. ACR also provides a low-latency endpoint to pull images from when your Docker hosts are running in the Azure cloud.

For this tutorial, we’re going to provision a new ACR instance. We’ll build a custom Docker image and push it to ACR so we can use it later with Azure Web App for containers.

In the Azure portal, select Create a resource, select Containers in the Azure Marketplace, and choose Container Registry.

Figure 1. Creating an ACR Resource.

Enter a globally unique, DNS-compliant hostname for your registry under the azurecr.io namespace. Set the destination resource group and make sure you enable the option for admin user and click on Create.

Once provisioning is complete, navigate to your ACR resource in the portal and select Access Keys under the settings section. Here you will see your login server, admin username, and passwords.

Figure 2. Retrieving the ACR Credentials.

Finally, fire up a terminal and use the docker login command to authenticate to ACR and validate the credentials.

Figure 3. Logging into the ACR.

You should see a message that says “login succeeded” as shown in Figure 3.

Cloning the Sample Node & Express Application

Next, we’re ready to package up an application into a container image. For this example, we’ll use a bare-bones Node.js and Express application from my Github account. The app is really basic and simply returns a “hello world” message when you visit the web application.

Open a terminal or command prompt and switch to a directory where you want to store the source code locally. Use the following command to clone the repo:

git clone https://github.com/mikepfeiffer/node-docker-demo.git

After you’ve cloned the repo, switch into the application directory:

cd node-docker-demo/

Inside the local repo you’ll see the following set of files and folders:

├── Dockerfile
  ├── LICENSE
  ├── README.md
  ├── app.js
  ├── config.js
  ├── package-lock.json
  ├── package.json
  └── test
      └── index_test.js

The main thing to focus on here is the Dockerfile included with the application. This will give Docker all the instructions to build our container image. Open the Dockerfile in a text editor to review the commands. You’ll see something like the output in Figure 4.

Figure 4. Reviewing the Dockerfile.

The commands in the Dockerfile will be used to build the image locally before we push it to ACR. Let’s break it down line by line.

• Line 1: The FROM command defines the base container image. In this case, we’ll use the official Node.js image available in the Docker Hub. Notice we’re not explicitly referencing a container registry for this image. This means we’ll pull down the Node.js container image from the default container registry (Docker Hub). Also note that the image uses an alpine tag. This means we’ll use the Node.js container image based on Alpine Linux, which is a Linux distro designed for security and resource efficiency. It will allow us to keep the container image very small at less than 90 MB in size.
• Line 3: The WORKDIR command sets the working directory and is where we’ll store the application code. If the path indicated doesn’t exist it will get created during the build process.
• Line 5: The COPY command will be used during the build process to add the package.json and package-lock.json files to the working directory. Note that, instead of copying the entire application at this stage, we are only copying the package*.json files. This allows us to take advantage of cached Docker layers to improve our development workflow, which you can read about here.
• Line 6: Next, the RUN command is used to execute npm install which will ensure our application dependencies are included within the container image.
• Line 7: The COPY command is used to copy the application source files into the working directory.
• Line 9: Finally, CMD defines the default command to execute when the container starts. In this case, npm start will run the start script defined in the package.json file to get our node server up and running.

Now that we understand what will be included in our container image, we’re ready to run a build.

Building the Container Image

Head back over to the command-line. Make sure your context is set to the root of the application. You should be in the same directory as the Dockerfile. Use the docker build command to create your container image.

docker build -t <YOUR REGISTRY NAME>.azurecr.io/node-docker-demo:latest .

This command will tell Docker to build your image using the Dockerfile in the current directory. It will also tag your image with your ACR repository name, an image name, and version set to latest to indicate that this image is the current version of the application.

Since the registry name is included in the image tag, the Docker client will intuitively know where to send the image when we run a push in the next step.

Pushing the Image to ACR

Since we already logged in using docker login, all that’s left to do is push the image up to ACR using the following syntax.

docker push <YOUR REGISTRY NAME>.azurecr.io/node-docker-demo:latest

After the command completes successfully, you can head back to the Azure portal to verify that your image is now available in ACR.

Figure 5. Reviewing the image in ACR. Building the Web App Resource.

With the image available in ACR, we’re ready to build a Web App resource that can host the application. In the Azure portal, select Create a resource, select Web in the Azure Marketplace, and choose Web App.

Figure 6. Creating the Web App Resource.

Enter a globally unique, DNS-compliant hostname for your web app under the azurewebsites.net namespace. Set the destination resource group and choose Linux as the OS. Make sure the publish settings are configured to use a container as shown in Figure 6. You’ll be able to browse and find your custom container image in ACR. Click on Apply and Create.

Open a web browser and navigate to the URL for your new Azure Web App. You should see “Hello World!” on the home page.

Figure 7. Testing the Web App.

Now that we have the app up and running we can setup continuous deployment.

Enabling and Validating Continuous Deployment

Navigate to your Web App resource in the Azure portal. Select Container settings as shown in Figure 8.

Figure 8. Updating the Web App.

Switch Continuous Deployment to On and click on Save.

This will create an ACR webhook behind the scenes. Anytime we push an updated image to ACR it will trigger a deployment in Azure App Service. This means we can update and rebuild our image locally, push it back to ACR, and the website will be updated without us having to do anything else. You’ll see the webhook in the same resource group as your web app in the Azure portal.

Figure 9. Reviewing the Webhook.

Now that continuous deployment is enabled, we can test out. Fire up your code editor and open the app.js file in the root of the application that we cloned earlier. Modify line 7 to return a new message. For this example, I’ll update the code to return “Hello World v2!” when a user visits the page.

Figure 10. Updating the app.js file.

Once the code has been updated, rebuild the container image:

docker build -t <YOUR REGISTRY NAME>.azurecr.io/node-docker-demo:latest .

Then push the new container image to ACR:

docker push <YOUR REGISTRY NAME>.azurecr.io/node-docker-demo:latest

The push will trigger the webhook.

Figure 11. Reviewing the Webhook History.

Then we can visit our web app and see that it’s serving the new version of the application.

Figure 12. Validating the Deployment.

Isn’t that awesome? This is a really slick solution for those who want to streamline the deployment process for single container-based web apps.

Where to go from here

There’s so much more when it comes to running Docker containers on Azure. Check out some of these resources to help you get started.

• Azure for Containers
• Play with Docker (If you’re new to Docker)
• Build and store container images with Azure Container Registry
• Use a custom Docker image for Web App for Containers

Originally published at https://cloudskills.io/blog/azure-docker-containers

This is a tutorial for absolute beginners.

Whether you’re a developer or an operations engineer, it’s a good idea to start wrapping your brain around the fundamental concepts of serverless computing. The technology is still in its infancy, but I believe it will radically shift how many applications are built in the years to come.

In this guide, I’ll walk you through setting up a super basic serverless web application on Azure. Just a simple webform that sends and receives data to and from an Azure Function.

The HTML page for this serverless application will be hosted in an Azure Storage account. Users will visit the webpage and submit a message. The form will trigger an Azure Function that will send a message back to the user. There will be no virtual machines involved. Just code. Hence the term serverless ;)

Here’s the good news; you don’t need to be an experienced programmer to follow along with this tutorial. I’ll show you how to build the resources you’ll need in Azure, and I’ll give you some sample code to try out.

Sound good? Let’s go.

Before We Begin

We need to build a handful of Azure resources to support both the front-end and the back-end of the application. We’ll create an Azure Storage account, build an Azure Function, and then deploy and test a simple HTML web page.

Yes, we could automate all of this work, but that’s a topic for another post. My goal here is to help you grasp the concept of a serverless web app using a simple example with minimal steps.

However, we will use the Azure CLI as much as possible as we build the infrastructure. I’ll try to minimize the steps required in the portal since the UI tends to change frequently.

Don’t worry about installing the Azure CLI locally unless you want to. You can use shell.azure.com to run the CLI in a web browser, or you can run it inside VS Code.

Step 1. Building the Azure Storage Account

Fire up the Azure CLI. If you have more than one Azure subscription you should make sure your CLI session is set accordingly. You can get a list of your subscriptions and their id’s by running:

az account list --query [].[name,id]

If you have more than one subscription, use the output from the above command to scope your CLI session to the desired subscription id using the syntax below:

az account set --subscription <YOUR SUBSCRIPTION ID>

Next, create a resource group to store the resources for the application. If you’re not sure what the region names are you can use the “az account list-locations” command. I’m using westus2.

az group create --location <YOUR REGION> --name <YOUR GROUP NAME>

Now we are ready to create the Storage Account. Make sure you use a globally unique DNS-compliant name for the storage account using the — name flag. Also note that only GPv2 storage accounts allow you to serve static content like HTML, CSS, JavaScript, and images. Therefore, the — kind flag must be set to StorageV2 as shown below.

az storage account create \ 
    --location <YOUR REGION> \
    --name <YOUR STORAGE ACCOUNT NAME> \ 
    --resource-group <YOUR GROUP NAME> \ 
    --sku Standard_LRS \ 
    --kind StorageV2

Now that the storage account is created, we need to enable static website hosting. As I am writing this article, static website hosting for GPv2 storage accounts is generally available, but we still need to install the storage preview extension to enable it via the CLI. Run the following command to install the extension:

az extension add --name storage-preview

The final step is to enable static website hosting. Make sure to update the — name flag to reflect your storage account name:

az storage blob service-properties update \ 
    --account-name <YOUR STORAGE ACCOUNT NAME> \ 
    --static-website \ 
    --index-document index.html

If you run into problems creating the storage account or enabling static website hosting from the CLI, you can do this work through the Azure portal using the steps outlined in this guide in the Azure documentation.

Here’s what you should see in the portal after running the above CLI commands or manually enabling static website hosting:

Figure 1. Reviewing the static website properties.

Notice that the default document is set to index.html. That file doesn’t exist yet. We’ll deploy it later. Go ahead and record the primary endpoint URL for the static website as shown in Figure 1 because we’ll need this value in the next step.

Step 2. Building the Azure Function App

Now it’s time to create a function app. Think of a function app as a resource that hosts the execution of one or more serverless functions. The way the function app is configured will be unique for each application because it controls the underlying OS platform and runtime stack. The function app settings also control the billing model you’ll use for your serverless functions.

Take a look at the CLI command below. You can see we’ll be using the az functionapp create command to build the function app. The consumption plan location defines where our code will run and how we’re billed. Azure Functions consumption plan is billed based on per-second resource consumption and executions and includes a monthly free grant of 1 million requests. Also, pay close attention to the — name flag. Like Azure Storage, the name must be a DNS-compliant globally unique value as it will be used as the host portion of the URL for the function app. We’ll set the runtime node. Make sure you update all the values in the example below and then run the command to create the function app.

az functionapp create \ 
    --resource-group <YOUR GROUP NAME> \ 
    --consumption-plan-location <YOUR REGION> \ 
    --name <YOUR FUNCTION APP NAME> \ 
    --storage-account <YOUR STORAGE ACCOUNT NAME> \ 
    --runtime node

After the function app has been created we need to update the Cross-Origin Resource Sharing (CORS) configuration. CORS is a mechanism that tells a web browser connected to one origin (domain) that its OK to access resources on another server.

Here’s why this is important; we’re going to have a static HTML page in the Azure Storage account acting as the front-end of the serverless application. There will be JavaScript in that page that executes when users fill out and submit a form, and that client-side code will be connecting to a different endpoint (the function URL) to communicate with the back-end of the application. CORS allows us to define where that traffic is allowed to originate from (in this case, the static website in Azure Storage), and it will tell web browsers used by our clients that its not a security risk to do this.

So, what we need to do is run the az functionapp cors add command as shown below. We’ll need to target the previous resource group and function app resources we created, and also define the allowed origin which will be the primary endpoint URL from the Storage Account from Step 1.

az functionapp cors add \ 
    --resource-group <YOUR GROUP NAME> \ 
    --name <YOUR FUNCTION APP NAME> \ 
    --allowed-origins <YOUR STATIC WEBSITE URL>

Once the CORS configuration has been set you’ll be able to see the change in the platform features section of the function app in the Azure portal, as shown in Figure 2.

Figure 2. Reviewing the CORS configuration.

Again, if you run into any problems doing this from the CLI, you can manually create the Function App and add the static website primary endpoint URL to the CORS configuration.

Step 3. Creating an Azure Function

Now that we have a function app, we can create a new function. While the Azure CLI makes it easy to create the function app from the command-line, we need to use other tools to create our functions. One way we could do it is by using the Azure Core Tools, but I’m not going to get into that here. Instead, we’ll create the function inside the Azure portal.

Navigate to your function app and highlight Functions. Click the New function button to start the process as shown in Figure 3.

Figure 3. Locating the new function button.

Next, we can select a template for our function. Select the HTTP trigger template as shown in Figure 4.

Figure 4. Selecting the HTTP trigger template.

The last step is to name the function and set the authorization level. Change the name of the function to SayHello and set the authorization level to Anonymous.

Figure 5. Setting the function name and auth level.

After the function has been created you’ll see the default code for the HTTP trigger template as shown below in Figure 6.

Figure 6. Reviewing the Function App Settings.

This is the exported JavaScript function that will execute when triggered via HTTP. Let’s break it down a bit so we know what's going on when we call the function.

• Line 1: You can see the first argument sent to the function is a context object which, among other things, is used for communicating with the Azure Functions runtime. The second argument (req) is the request object that contains the details about what was sent to the function. We’ll be able to use the req object to access the data sent to this function from our web form.
• Line 4: Here we’re using some conditional logic to make sure the request contains a name key within the query string parameters or request body.
• Line 5: If a name was provided with the request, we use the context.res object to send a response. In this case, we send back a “hello” message to the caller.
• Line 11: If a name wasn’t provided, we’ll send back an HTTP 400 error with a message explaining what the problem is.

While you’re viewing this code in the Azure portal, you’ll see a link at the top of the screen that says Get function URL as shown in Figure 7.

Figure 7. Copying the function URL.

Copy the URL from this screen as we’ll need it for the next step.

Step 4. Configuring the HTML Front-end

Now we are ready to configure the HTML page for the serverless application like the one shown in Figure 8.

Figure 8. The UI for our serverless app.

This page uses Bootstrap 4 which is an easy to use open source toolkit for developing with HTML, CSS, and JavaScript. Let me point out some of the basics that are going on inside the HTML code for this form that is relevant to the functionality of our serverless application.

Check out the snippet from Figure 9:

Figure 9. The HTML form for the app.

Here’s what you need to know:

• Line 4: There’s an empty output div we can update based on the response from our Azure function. We’ll use this element to provide a success or failure message to the user.
• Line 7: The input field where the user submits their name. Notice that the id is set to name. We’ll grab the value from this input and send it along with the request to our Azure Function.
• Line 9: When the user clicks the submit button we’ll post the form to our Azure function.

Now that you understand what is going on with the HTML code, let me explain a couple of points about the client side javascript that will send the form data to our serverless function.

Take a look at the code in Figure 10:

Figure 10. The client-side JavaScript that calls our serverless function.

This is a vanilla JavaScript function that will be called when the user clicks the Submit button. Here are some important points about the code in Figure 10:

• Line 4: We grab the value of the input field in the HTML form.
• Line 5: The Fetch API will be used to facilitate the request/response process. You’ll obviously need to update this line with your own function URL.
• Line 12: The value for the name input will be sent as part of the body of the POST request.
• Line 15: fetch() returns a promise containing the response, and that gets passed to another client-side function called processResponse() which will update the UI.

Still awake? Good :)

All of this code is included in a single HTML file for the sake of convenience. Grab the Index.html page from GitHub. Don’t forget to replace “<YOUR FUNCTION URL GOES HERE>” with the URL of your function that you recorded in Step 3.

Step 5. Deploying the HTML Front-end

Let’s take the index.html file and upload it into our Azure Storage account. Since static website hosting is already enabled for the storage account, we simply need to upload the file/blob to the $web container.

This can be done easily in the portal, but here’s how you can do it via the Azure CLI:

az storage blob upload-batch \ 
    --source <YOUR SOURCE FOLDER> \ 
    --destination \$web \ 
    --account-name <YOUR STORAGE ACCOUNT NAME>

Notice that I had to escape the “$” character with “\” when executing the CLI in bash. Also, note the — source flag expects a directory since this command is designed to upload multiple files as a batch process. This makes sense as most sites will have multiple HTML, CSS, JavaScript, and image files that need to be uploaded.

Step 6. Testing the Serverless Web Application

Finally, its time to test our serverless application. Navigate to the static website primary endpoint URL to view your application. After filling out and submitting the form, you should see a response similar to the one in Figure 11.

Figure 11. The UI for our serverless app in action.

Isn’t that awesome?

You might be wondering how the success message was created on the page. That work is done as part of the response where we call the processResponse() function shown in Figure 12.

Figure 12. The processResponse() function.

What we’re doing with this function is checking the HTTP response code sent back from the Azure function. Regardless of the result, we use processResponse() to update the output element on the page. We’re taking advantage of Bootstrap alerts to add some flare.

Here’s what it would look like if there was a problem:

Figure 13. The UI for our serverless app when there is an error.

This is a good example of how we can give feedback to users based on the result of a function invoked over HTTP. Obviously, we could do client-side validation and more error handling on the back-end but I think you get the idea.

Where to go from here

We’ve only scratched the surface, but I hope this tutorial has given you a little more perspective. Going forward, I’d recommend these resources from Microsoft to learn more about serverless on Azure:

• Create Serverless Applications (Microsoft Learn)
• Azure Functions Documentation
• Create a Serverless API using Azure Functions
• Build a Serverless Web App in Azure
• Azure Serverless Community Library

Originally published at mikepfeiffer.io.