This approach ensures consistent, reliable releases across multiple environments while supporting best practices like infrastructure as code, security scanning, and observability. It can help your organization deliver cloud-ready .NET software efficiently and safely.

In this article, you'll learn how to implement cloud-native CI/CD pipelines for enterprise .NET applications using Azure DevOps, Docker, and Kubernetes.

Table of Contents

• Prerequisites

• Overview

• Principles of Cloud-Native .NET Development

• Understanding Azure DevOps CI/CD Pipelines

• Creating an Azure DevOps Pipeline for a .NET Application

• Containerizing .NET Applications

• Building and Publishing Docker Images in Azure DevOps

• Deploying to Azure Kubernetes Service (AKS)

• Managing Environments with Deployment Stages

• Infrastructure as Code with Azure DevOps

• Implementing Security in CI/CD Pipelines

• Observability and Monitoring

• Best Practices for Enterprise CI/CD Pipelines

• Conclusion

Prerequisites

Before moving into cloud-native development with Azure DevOps CI/CD pipelines, it’s helpful to have a basic understanding of the following concepts:

• Familiarity with building applications using ASP.NET Core or .NET (for example, controllers, APIs, project structure).

• Understanding how to clone repositories, create branches, and push code changes.

• Ability to run commands such as dotnet build, docker build, and kubectl.

• Understanding what Continuous Integration and Continuous Deployment mean and why they're important.

• Basic idea of how containerization works and how Docker packages applications.

• Familiarity with Microsoft Azure or similar cloud providers.

To work through the examples, you should also have the following tools:

• .NET SDK (version 6 or later recommended)

• Docker installed locally

• Azure DevOps account

• Azure CLI (optional but useful)

• A code editor like VS Code or Visual Studio

Overview

Modern enterprise applications must be built to scale, adapt, and deploy quickly. Traditional monolithic deployment strategies (where applications are manually built, tested, and deployed) are no longer sufficient for teams delivering software in fast-paced environments. Organizations now expect rapid feature delivery, automated testing, and resilient infrastructure.

Cloud-native development addresses these challenges by embracing automation, microservices architectures, containerization, and continuous delivery. For .NET teams building enterprise applications, combining cloud-native principles with Azure DevOps CI/CD pipelines provides a powerful way to automate software delivery and improve reliability.

Azure DevOps enables teams to create fully automated pipelines that build, test, and deploy applications across environments. When integrated with .NET applications and cloud platforms such as Azure Kubernetes Service (AKS) or Azure App Service, CI/CD pipelines become the backbone of cloud-native development workflows.

By the end of this guide, you will understand how to implement a cloud-native delivery pipeline for .NET applications using Azure DevOps.

Principles of Cloud-Native .NET Development

Cloud-native applications are designed specifically to run in dynamic cloud environments. Rather than treating the cloud as simply another hosting location, cloud-native systems take advantage of elasticity, automation, and distributed architecture.

Key principles include:

Microservices Architecture

Modern .NET applications are often split into smaller independent services. Each microservice can be deployed, scaled, and updated independently. This reduces system coupling and allows teams to deploy features faster.

Stateless services

Cloud-native services typically avoid storing session data locally. Instead, state is stored in distributed databases, caches, or storage services. This allows applications to scale horizontally across multiple instances.

Containerization

Containers package applications along with their dependencies, ensuring consistent execution across environments. Technologies like Docker allow .NET services to run identically in development, testing, and production.

Infrastructure as Code

Cloud infrastructure is defined declaratively using templates such as Bicep, ARM, or Terraform. This ensures environments are reproducible, version-controlled, and automated.

Observability and Resilience

Cloud-native applications must be observable through logs, metrics, and traces. They also require resilience patterns such as retries, circuit breakers, and health checks.

Azure DevOps pipelines help enforce these principles by automating builds, deployments, and operational processes.

Understanding Azure DevOps CI/CD Pipelines

Azure DevOps pipelines automate the process of building, testing, and deploying applications.

A typical pipeline consists of two stages:

• Continuous Integration (CI)

• Continuous Deployment (CD)

Continuous Integration (CI)

Continuous Integration ensures that every code change is automatically built and tested.

When developers push code to the repository, the pipeline:

• Restores dependencies

• Compiles the application

• Runs automated tests

• Produces build artifacts

This process helps teams detect issues early and maintain code quality.

Continuous Deployment (CD)

Continuous Deployment takes the build artifacts and deploys them to different environments, such as:

• Development

• Staging

• Production

Deployment can include infrastructure provisioning, container image publishing, and application rollout.

Creating an Azure DevOps Pipeline for a .NET Application

Azure DevOps uses YAML pipelines to define automation workflows.

Let’s start with a simple pipeline configuration for building a .NET application.

trigger:
- main

pool:
  vmImage: 'ubuntu-latest'

variables:
  buildConfiguration: 'Release'

steps:
- task: UseDotNet@2
  inputs:
    packageType: 'sdk'
    version: '8.0.x'

- script: dotnet restore
  displayName: Restore dependencies

- script: dotnet build --configuration $(buildConfiguration)
  displayName: Build project

- script: dotnet test --configuration $(buildConfiguration)
  displayName: Run unit tests

- script: dotnet publish -c \((buildConfiguration) -o \)(Build.ArtifactStagingDirectory)
  displayName: Publish application

- task: PublishBuildArtifacts@1

 inputs:
    pathToPublish: $(Build.ArtifactStagingDirectory)
    artifactName: drop

This pipeline performs the following tasks:

1. Installs the .NET SDK

2. Restores NuGet dependencies

3. Builds the application

4. Runs tests

5. Publishes build artifacts

Once the artifacts are generated, they can be deployed automatically.

Containerizing .NET Applications

Cloud-native systems commonly use containers to ensure consistency across environments.

Docker allows you to package your .NET application and its dependencies into a container image.

Here is an example Dockerfile for an ASP.NET Core application:

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src

COPY . .
RUN dotnet restore
RUN dotnet publish -c Release -o /app

FROM mcr.microsoft.com/dotnet/aspnet:8.0
WORKDIR /app
COPY --from=build /app .

ENTRYPOINT ["dotnet", "MyApp.dll"]

This Dockerfile uses a multi-stage build to keep the final container image lightweight.

The application is compiled in the build stage and then copied into a smaller runtime image.

Building and Publishing Docker Images in Azure DevOps

After containerizing your application, the pipeline can automatically build and push the container image.

- task: Docker@2
  displayName: Build and push Docker image
  inputs:
    command: buildAndPush
    repository: myregistry.azurecr.io/myapp
    dockerfile: Dockerfile
    containerRegistry: MyAzureContainerRegistry
    tags: |
      $(Build.BuildId)
      latest

This step performs two important actions:

1. Builds the Docker image

2. Pushes it to Azure Container Registry (ACR)

Once stored in ACR, the image can be deployed to various environments.

Deploying to Azure Kubernetes Service (AKS)

Kubernetes is a popular orchestration platform for cloud-native applications.

Azure Kubernetes Service (AKS) simplifies Kubernetes deployment and management.

To deploy the application, you can use a Kubernetes deployment manifest.

Example deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: dotnet-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: dotnet-app
template:
    metadata:
      labels:
        app: dotnet-app
spec:
      containers:
      - name: dotnet-app
        image: myregistry.azurecr.io/myapp:latest
        ports:
        - containerPort: 80

This configuration defines:

• A deployment with three replicas

• The container image to run

• The exposed port

Now we add a pipeline step to deploy it.

- task: KubernetesManifest@0
  inputs:
    action: deploy
    kubernetesServiceConnection: myKubernetesConnection
    namespace: default
    manifests: deployment.yaml

This step updates the Kubernetes cluster with the latest version of the application.

Managing Environments with Deployment Stages

Enterprise pipelines often include multiple environments.

For example:

• Development

• QA

• Production.

Azure DevOps allows pipelines to define deployment stages.

Example:

stages:
- stage: Build
 jobs:
  - job: BuildApp
  steps:
      - script: dotnet build

  - stage: DeployDev
  dependsOn: Build
  jobs:
  - deployment: DeployDev
    environment: dev
    strategy:
     runOnce:
       deploy:
        steps:
          - script: echo Deploying to Dev
- stage: DeployProd
  dependsOn: DeployDev
  jobs:
  - deployment: DeployProd
    environment: production

Stages allow teams to:

• Approve deployments

• Run environment-specific tests

• Control promotion between environments

Infrastructure as Code with Azure DevOps

Cloud-native environments require automated infrastructure provisioning.

Tools such as Terraform, Bicep, or ARM templates allow infrastructure to be defined as code.

Example Terraform pipeline step:

- script: |
    terraform init
    terraform plan
    terraform apply -auto-approve
  displayName: Provision infrastructure

This ensures infrastructure environments remain consistent and reproducible.

Implementing Security in CI/CD Pipelines

Security in CI/CD pipelines should be automated and enforced at every stage of the delivery lifecycle. Instead of treating security as a separate step, modern pipelines integrate security checks directly into build and deployment workflows.

Below are practical implementations of key security practices.

1. Secure Secrets with Azure Key Vault

Never hardcode secrets such as API keys, connection strings, or credentials in your codebase.

In Azure DevOps, you can link secrets from Azure Key Vault using variable groups.

Pipeline Example

variables:
- group: KeyVault-Secrets

Usage in Code

var connectionString = Environment.GetEnvironmentVariable("DB_CONNECTION");

This ensures:

• Secrets are stored securely

• No sensitive data is exposed in source control

• Secrets can be rotated without code changes

2. Dependency Vulnerability Scanning

Automatically scan for vulnerable packages during the build process.

Pipeline Step:

- script: dotnet list package --vulnerable
  displayName: Check for vulnerable dependencies

Example Output (What You’ll See)

This allows teams to:

• Detect vulnerabilities early

• Prevent insecure builds from progressing

3. Static Code Analysis

Use tools like SonarCloud or built-in analyzers to catch security issues.

Example Pipeline Step:

- task: SonarCloudAnalyze@1

This can detect:

• SQL injection risks

• Hardcoded credentials

• Unsafe API usage

4. Enforcing Secure Build Policies

You can enforce rules such as:

• Blocking builds with vulnerabilities

• Requiring pull request approvals

Example – Fail Pipeline on Vulnerabilities:

- script: |
    dotnet list package --vulnerable | grep "High" && exit 1 || echo "No        high vulnerabilities"
  displayName: Fail on high vulnerabilities

5. Container Security Scanning

Scan Docker images before deployment.

- task: Docker@2
  displayName: Scan Docker Image
  inputs:
    command: build

You can integrate tools like Trivy or Microsoft Defender for Containers.

Observability and Monitoring

Cloud-native applications require strong observability.

Observability ensures that you can understand how your application behaves in production. In cloud-native systems, it is essential for debugging, performance optimization, and reliability.

A complete observability strategy includes:

• Logs

• Metrics

• Traces

1. Adding Application Insights to a .NET App

Azure Application Insights provides built-in telemetry for .NET applications.

Setup in ASP.NET Core:

builder.Services.AddApplicationInsightsTelemetry();

Example: Custom Logging

private readonly ILogger<HomeController> _logger;

public HomeController(ILogger<HomeController> logger)
{
    _logger = logger;
}

public IActionResult Index()
{
    _logger.LogInformation("Home page accessed");
    return View();
}

In Azure Portal, this appears as:

• Request logs

• Response times

• Dependency tracking

2. Tracking Custom Metrics

You can track business-specific metrics.

var telemetryClient = new TelemetryClient();

telemetryClient.TrackMetric("OrdersProcessed", 1);

Example use cases:

• Number of API calls

• Orders processed

• Failed transactions

3. Distributed Tracing Example

Tracing helps track requests across services.

using System.Diagnostics;

var activity = new Activity("ProcessOrder");
activity.Start();

// Business logic here

activity.Stop();

This allows you to:

• Trace request flow across microservices

• Identify bottlenecks

4. Observability in CI/CD Pipelines

You can also monitor pipeline execution itself.

Example: Logging in Pipeline

- script: echo "Deploying version $(Build.BuildId)"
  displayName: Log deployment version

Example: Tracking Deployment Time

- script: date
  displayName: Start Time

- script: echo "Deploying..."

- script: date
  displayName: End Time

5. Monitoring Kubernetes Deployments

If using AKS, monitor pods and services.

kubectl get pods
kubectl logs <pod-name>

This helps identify:

• Crashes

• Restart loops

• Performance issues

• What Observability Looks Like in Practice

In a real system, observability enables you to answer questions like

• Why is this request slow?

• Which service failed?

• What changed in the last deployment?

For example:

A spike in latency can be traced to a slow database query. Increased errors can be linked to a recent deployment. And high CPU usage can be caused by inefficient code.

Best Practices for Enterprise CI/CD Pipelines

Designing CI/CD pipelines for enterprise .NET applications requires more than automation—it requires consistency, reliability, and control. Below are key best practices with real examples to show how they are implemented in practice.

1. Keep Pipelines Declarative (YAML-Based)

Defining pipelines in YAML ensures they are version-controlled and reproducible.

Example:

trigger:
- main

pool:
  vmImage: 'ubuntu-latest'

steps:
- script: dotnet build

This approach allows you to:

• Track pipeline changes in Git

• Review pipeline updates via pull requests

• Reuse templates across projects

2. Implement Automated Testing at Multiple Levels

A robust pipeline includes unit, integration, and end-to-end tests.

Example:

- script: dotnet test --filter Category=Unit
  displayName: Run Unit Tests

- script: dotnet test --filter Category=Integration
  displayName: Run Integration Tests

This ensures that bugs are caught early, critical workflows are validated, and releases are more stable.

3. Use Immutable Build Artifacts

Build once and deploy the same artifact across all environments.

Example:

- script: dotnet publish -c Release -o $(Build.ArtifactStagingDirectory)

- task: PublishBuildArtifacts@1
  inputs:
    pathToPublish: $(Build.ArtifactStagingDirectory)
    artifactName: drop

Deployment Uses Same Artifact

- task: DownloadBuildArtifacts@0
  inputs:
    artifactName: drop

This prevents environment inconsistencies and “Works on my machine” issues.

4. Enable Safe Deployment Strategies (Blue-Green / Canary)

Avoid deploying directly to all users at once.

Example: Canary Deployment Concept

- script: echo "Deploying to 10% of users"

In Kubernetes:

spec:
  replicas: 10

Then gradually increase replicas of the new version.

This allows:

• Gradual rollout

• Early detection of failures

• Quick rollback if needed

5. Enforce Pull Request Validation

Ensure code is tested before merging into main branches.

Example:

pr:
- main
steps:
- script: dotnet build
- script: dotnet test

This ensures that only validated code is merged, and that code quality remains high.

6. Use Environment Approvals for Production

Prevent accidental deployments to production.

Example:

- stage: DeployProd
  jobs:
- deployment: Deploy
    environment: production

Azure DevOps allows manual approvals and role-based access control.

This ensures that you have controlled releases and results in reduced risk.

7. Version Your Builds and Artifacts

Every build should be uniquely identifiable.

Example:

- script: echo "Version: $(Build.BuildId)"

For Docker:

tags: |
  $(Build.BuildId)
  latest

This allows for easy rollbacks and traceability.

8. Add Logging and Diagnostics in Pipelines

Pipelines should produce meaningful logs.

Example:

- script: echo "Starting deployment..."
- script: dotnet build
- script: echo "Build completed"

This helps you debug failed pipelines and understand execution flow.

9. Automate Infrastructure Provisioning

Don't manually create infrastructure. Instead, use a tool like Terraform.

Example (Terraform):

- script: |
    terraform init
    terraform apply -auto-approve

This ensures consistent environments and repeatable deployments.

10. Monitor Pipeline and Deployment Performance

Track metrics such as build time and deployment frequency.

Example:

- script: echo "Build completed at $(date)"

You can track:

• Build duration

• Deployment success rate

• Failure trends

Conclusion

Cloud-native development has transformed how enterprise .NET applications are built and delivered. By adopting containerization, automated pipelines, and infrastructure as code, teams can deliver reliable software faster and with greater confidence.

Azure DevOps CI/CD pipelines play a central role in this process. They automate everything from building and testing applications to packaging containers and deploying them across cloud environments. When combined with technologies such as Docker, Kubernetes, and Azure monitoring services, they enable .NET teams to build scalable, resilient, and continuously deployable systems.

For teams beginning their cloud-native journey, the best starting point is to automate the build and test process using CI pipelines. From there, gradually introduce containerization, deployment automation, and infrastructure as code. As pipelines mature, organizations can incorporate advanced practices such as multi-environment deployments, automated security scanning, and progressive rollout strategies.

Ultimately, cloud-native CI/CD pipelines turn software delivery into a repeatable and reliable process. For enterprise .NET applications, this shift allows development teams to focus less on manual operations and more on delivering value through faster innovation and continuous improvement.

I hope you're doing well. Whether you're a seasoned coder, a curious learner, or just someone browsing through, welcome to my little corner of the internet.

In this tutorial, we’ll dive into how you can deploy a web service on Microsoft Azure app service. It’s a topic I’ve been excited to explore, and I hope you’ll find it insightful and helpful. So grab a coffee, sit back, and let’s get started.

Prerequisites

• Basic understanding of RESTful web services

• Programming knowledge

• Docker basics

• Docker Hub account

• Command Line Interface (CLI) skills

What we’ll cover:

• Key Terminologies

• How to Install Docker and Docker Compose

• How to Create a Simple Get Client Info Web Service

• How to Build the App’s Docker Image

• How to Run the App in the Container

• How to Create an Azure Resource Group on Azure Portal.

• How to Deploy to Azure App Service

• Conclusion

Before we actually get started, I’d like to go over some key terminologies that I'll be using throughout this tutorial. Understanding these terms will make it easier to follow along and get the most out of what we're discussing. Let’s dive in!

Key Terminologies

1. Docker

Docker is an open-source platform that simplifies application development, shipping, and deployment by using containers. With Docker, there are three key things you can do:

• build once and run anywhere

• keep environment consistent, and

• easily scale your application with container orchestration tools like Kubernetes.

2. Docker Hub

Docker Hub is a cloud-based repository where developers can store, share, and manage Docker images. You can think of it as the GitHub for Docker images 😉.

3. Docker Image

A Docker image is a lightweight, standalone, and executable package that includes everything needed to run a piece of software. You can also think of it as a blueprint for creating and running a container.

Once built, an image is immutable, meaning it cannot change after creation. Instead, you create a new version when updates are needed. This means that you’ll need to rebuild if you update the code that’s being run in the container.

4. Container

A container is a running instance of a Docker image. It provides an isolated environment where an application runs with all its dependencies, without interfering with the host system or other containers.

Wait, what?! 😕 Well, simply put, a container is like a tiny virtual machine that runs the built Docker image. But unlike traditional VMs, it has no init process (PID 1), meaning it always runs on a host system rather than being fully independent. By now, you should be getting the idea: no image, no container. A container depends on an image to exist. You have to cook before you serve, right? 🍽️

5. Azure Resource Group

An Azure resource group refers to a store or folder containing all related resources for an application you want to deploy to production using MS Azure Cloud. For example, if I want to deploy an eCommerce web app with MS Azure, I could create a resource group called EcommWebAppRG. I’d use this to create all the resources I needed for the web app to go live and be accessible – like VMs, DBs, caches, and other services.

Alrighty, now that all the terms are out of the way, lets get started with the tutorial so you can learn how to deploy a web service on Azure App Service.

Since we are deploying an app, let’s start by creating simple REST API app. I’ll be using Golang for the API development, but you can use any programming language/framework of your choice. If you’d like to follow along with the app for this tutorial, I’ve provided the source code here.

How to Install Docker and Docker Compose

To install Docker and Docker compose on your PC, for Mac and Windows you’ll need to download Docker desktop for your Operating System here.

For Linux, you can run the following command:

sudo apt update # update apt registry
sudo apt install docker.io # for docker engine
sudo apt install docker-compose-plugin

After downloading the Docker desktop for your application, open your terminal and enter the following command to verify that Docker and Docker Compose have been successfully installed on your machine:

docker-compose -v # this should show the version of docker compose cli you have on your PC

My Docker Compose version is:

Docker Compose version v2.31.0-desktop.2

docker -v

You should see something similar if Docker has successfully been installed on your machine:

Docker version 27.4.0, build bde2b89

How to Create a Simple Get Client Info Web Service

Alright, I’ll use this handy tool called sparky_generate to generate the app code template. sparky_generate is a command line tool used to generate boilerplate code for backend development using various backend languages and frameworks.

Use this command to install and setup the tool on your Mac or Linux machine. If you are on Windows, you can use WSL.

wget https://raw.githubusercontent.com/Ayobami6/sparky_generate/refs/heads/main/install.sh

chmod 711 install.sh
./install.sh # run the install command like so

sparky # run the sparky command like so

You should see something similar to the below. Select whatever framework you want to use for your backend service.

I will select Go, because I’m using Go for this tutorial. You should have your project template ready once you’ve selected your framework. I won’t go through how to code the web service since it’s out of scope for this tutorial. The goal here is to deploy on Azure using Azure App Service.

How to Build the App’s Docker Image

To build the Docker image for our app, we first need to create a Docker file that will include all the steps needed to build the image.

touch Dockerfile

We will be using a multistage Docker build to reduce the size of our Docker image. We need something as light as possible.

The multistage Docker build helps reduce size because we use different stages for different concerns. This helps ensure that only what’s needed runs the application in the final stage. For example, we might need certain artifacts to build the application, but we don’t need them to run the application. This is why we have the builder and runner stages in the Docker file below.

Our first stage (build) is concerned with building and bundling the application. The second stage (runner) is just used to run the executable we built in the first stage. So basically all files, modules, and so on used in the build process will be discarded in the runner since they’ve already served their purposes.

# using the first stage as build
FROM golang:1.23-alpine AS build # using alpine base image to reduce size

# install git on the machine
RUN apk add --no-cache git

# setting the current work directory on the vm to be /app
WORKDIR /app

# Copying all go dependency files to the working directory
COPY go.mod go.sum ./

# Install go dependencies
RUN go mod download

# copy all remaining files to the working directory
COPY . .
# build the execuatable

# build the go program
RUN go build -o api cmd/main.go

# stage 2 AKA the runner
FROM alpine:3.18

RUN  apk add --no-cache ca-certificates

# copy the go executable to the working directory
COPY --from=build /app/api .

# expose the service running port
EXPOSE 6080

This Dockerfile outlines all the steps for building a Docker image for our app. Lets go through all these steps line by line. Because we are using a multistage build here, our stages are build and runner.

• The first stage build starts from the first FROM golang:1.23-alpine AS build. It initializes a stage with all the steps in the stage. It states that the base image to be used for all the steps in this stage should use a pre-existing golang:1.23 image using an Alpine Linux distro to run all the steps in the stage.

• Next, we have RUN, which is used to run the command apk add git, followed by setting the working directory to the /app folder.

• Then we have the COPY command that copies all the Go dependencies that will run the Go program.

• Following that is RUN go mod download which is used to install all the dependencies.

• We then have the command COPY . . to copy all the files to the working directory /app of the image

• Then the last step in the build stage, RUN go build -o api cmd/main.go, builds the app code main.go to an executable API. The second stage “runner“ uses an alpine:3.18 base image, and also uses the RUN directive to add ca-certificates to the Alpine base image. The COPY is used here to copy just the built executable file from the builder image to the runner image.

• We then expose port 6080 so our built container can accept an HTTP connection from port 6080.

Now, let’s write our docker-compose.yml file to define and run our containerized service::

services:

  client_info_app:
    build: 
      context: .
      dockerfile: Dockerfile
    container_name: info_app

    ports:
      - "6080:6080"

    command: "./api"

Understanding the YAML Structure

YAML follows a key-value structure similar to a dictionary or hashmap. In our file, the top-level key is services, which acts as the parent key. Within services, we define individual service configurations.

In this case, we have a single service named client_info_app, which contains the necessary properties for Docker to build and run it.

• build: This specifies how to build the Docker image for the service. The context: . tells Docker to look for the Dockerfile in the same directory as the docker-compose.yml file.

• container_name: This assigns a custom name (info_app) to the running container, making it easier to reference.

• ports: Defines the port mappings between the host and the container. The - before "6080:6080" indicates that multiple mappings could be listed. Here, port 6080 on the host is mapped to port 6080 inside the container.

• command: Specifies the command to execute inside the container once it starts. In this case, it runs ./api.

This structure allows us to define and configure multiple services within the services key if needed, but for now, we are only defining client_info_app.

How to Run the App in the Container

You can use this command to start the container:

docker-compose up client_info_app

The above command will first build the image if it doesn’t exist. Then it runs it, because remember: no image, no container.

If all looks good, you should have something similar to this, depending on your application framework:

You should also verify that your Docker image has been built as well. To do that, run the following:

docker images

Voilà! You now have your Docker image built and ready for deployment on Azure App Service.

Let’s go on to the Azure Portal to deploy the app.

Note: if you don’t have an active Azure Subscription, that’s fine – you can still follow along. If you want to get a trial account, you can get one here.

How to Create an Azure Resource Group on Azure Portal.

As a reminder, an Azure resource group refers to a store or folder containing all related resources for an application you want to deploy to production using MS Azure Cloud. Now let’s go about creating one.

When you login to the Azure portal, you should see some like this, the dashboard:

Search for Resource group using the search bar:

Click on Create to create a new resource group:

Give your resource group a name and select a region for it. Here I will use the default East US 2, but you can use any you want. Then click on Review + create.

You should see something like the above after creating the resource group.

How to Deploy to Azure App Service

Ok now that we’ve created the resource group, let’s go ahead and create the Azure App Service. To do this, navigate back to the dashboard and click on Create a resource.

You can search for Web App if you don’t see it in the list there. Then click on the Create Web App option:

Here, select the resource group you created earlier, give the app a name, then select Container for the Publish option.

Before you click on Create, go back to your dev workspace (VS Code or whatever IDE you are using) to push your Docker image to Docker Hub so you can add it there before proceeding to the next steps.

But why do you need to push to Docker Hub? Well, first of all, for accessibility – so we can easily share it with others or have other services access it (which is what we need here).

Remember how I compared Docker Hub with Github earlier? Docker Hub helps you host your Docker image on the internet and make it available for others or for various services on the internet to access if you make it public. Otherwise it’s limited to only authorized services.

To push the Docker image to Docker Hub, you first need to tag the Docker image with your Docker Hub username. Go to Docker Docker Hub to register and get your username if you don’t have one.

Run the following:

docker tag client_info_webservice-client_info_app:latest ayobami6/client_info_webservice-client_info_app:latest
# this adds the latest tag to your docker image

This shows that you successfully tagged your image with the latest tag.

Before you actually push the image to Docker Hub, go ahead and login to it with the Docker CLI.

docker login # this will prompt for browser authetication, for the prompt and login your account with your usernam and password

Push the image to Docker Hub like this:

docker push ayobami6/client_info_webservice-client_info_app:latest

You should see something like the below once you enter the push command on Docker Hub.

Alright, now that you have the Docker image on Docker Hub, you can go ahead and deploy it using Microsoft Azure App Service.

Click on the container on the top menu bar to configure the container settings.

Here, select Other container registries.

Select public, because your pushed image is public (meaning it’s publicly accessible over the internet).

Add your Docker image and tag. You can get this when you run the command docker images.

λ MACs-MacBook-Pro ~ → docker images
REPOSITORY                                        TAG         IMAGE ID       CREATED         SIZE
ayobami6/client_info_webservice-client_info_app   latest      a14f2a5b3bd4   2 weeks ago     30.8MB
postgres                                          13-alpine   236985828131   4 weeks ago     383MB
glint_pm_frontend-nextjs                          latest      424233ceaa4b   4 weeks ago     1.72GB
flask_app-flask_app                               latest      ff6ecfc4ba5a   5 weeks ago     203MB
nginx                                             latest      124b44bfc9cc   7 weeks ago     279MB
encoredotdev/postgres                             15          58b55b0e1fc7   10 months ago   878MB
λ MACs-MacBook-Pro ~ →

Copy the repository name and tag – in my case I have ayobami6/client_info_webservice-client_info_app and tag latest → ayobami6/client_info_webservice-client_info_app:latest.

Then add your startup command. If you are not using Go for the development like I am, your startup command will be different – so just use the command you added to your Docker compose command key, like so command: "./api". Copy just the value (mine is ./api) don’t add the double quotes, and add it to the startup command.

This start up command is the command that will start the application from the container and get the container running.

Click on review and create to create the service.

Once the deployment is complete you’ll be redirected here:

Congratulations! You’ve successfully deployed your web service to Azure App Service. You can visit your app using the default domain from the overview. Mine is here.

Conclusion

Deploying a RESTful web service on Microsoft Azure App Service is a powerful way to leverage cloud technology for scalable and efficient application hosting.

Understanding key terms like Docker, Docker Hub, and Azure Resource Groups will help you streamline the deployment process.

This guide walked you through creating a simple web service, building a Docker image, and deploying it on Azure. By following these steps, you can confidently deploy your applications, ensuring they are accessible and performant.

Thank you for following along, and I hope this tutorial has been insightful and helpful in your cloud deployment journey. If you found it useful, feel free to share it with others who might benefit from it. Happy coding and deploying!

Stay tuned for more insightful content, and let's continue learning and growing together. Cheers to building smarter, more efficient solutions with Azure.