User Tools

Site Tools


knowledge:deployingawebapponazure

Deploying a Web App on Azure

Web applications can be deployed on Azure using the service App Services.

App Services are embedded into App Service Plans. An App Service Plan is the item in Azure which generates costs. For the reason for each new App Service it shall be considered to place it in an existing App Service Plan.

This article describes the deployment of a Web application using a Docker image. The image must be available from a public available registry. This can be hub.docker.com, however, it also can be a dedicated registry in Azure. The latter approach will be used here.

It is also possible to directly deploy a Node application or a WAR container. This is currently out of scope.

This approach works only for applications exposing an endpoint using the http protocol.

Preparation of the application

The application shall be packaged in a Docker image. The Docker image shall expose a port the application within the image is listening on.

Create a container registry in Azure

If no container registry exists so far, create one. If there is already one. From a cost view it would be beneficial to have only one registry company-wide.

  • Select Container Registries and then Create

Under the tab Basics:

  • Select a subscription (here: AzureSimple Krohne Messtechnik GmbH) and a resource group (here: AZ-RG-Development)
  • Choose a Registry Name
  • Select a Location (here: West Europe)
  • Do not enable Availability zones
  • Select Standard as SKU

Under the tab Networking you have, when using the SKU Standard, no options.

Also under the tab Encryption you have, when using the SKU Standard, no options.

Under the tab Tags it might be useful to enter a tag with the cost center if applicable.

Finally, create the registry.

Once the registry is created, under Settings, Access keys the server name to use for push, pull and in the tags can be found. Here, it is currently necessary to enable the Admin user. Note the credentials given here for push and pull operations. (A more fine-grained authentication shall be found.)

Creating the App Service in Azure

Use the resource App Services and select Create Web App.

Under the tab Basics:

  • Select a subscription (here: AzureSimple Krohne Messtechnik GmbH) and a resource group (here: AZ-RG-Development)

On the same tab under Instance Details

  • Choose a Name for the app. This name will be used in the generic URL of the app.
  • At Publish select Docker Container
  • At Operating System select Linux
  • At Region select West Europe

Select and create an App Service Plan. If available, usually select an existing App Service Plan. If you need to create a new App Service Plan it usually should be a production tier plan.

On the tab Docker

  • Select the option Single Container (unless you now what you are doing)
  • Select the Image Source Azure Container Registry

On the same tab under Azure container registry options

  • Choose the earlier created or already available registry
  • Select an image available on that registry
  • Select a tag for that image. Select a symbolic and no specific tag, something like latest. This is required for easier continuous deployment.
  • Do not set a startup command

On the tab Monitoring you have currently no options.

On the tab Tags you should again set the cost center.

Preparing continuous deployment

Once the App Service has been created, some setting must be tuned.

At Deployment, Deployment Center enable Continuous Deployment and save the Webhook URL.

Configuring the application

All configuration parameters shall either be set already hard-coded in the image or handed over using environment variables into the container. Make sure not to set secret credentials already in the image.

Configuration parameters handed over into the container using environment variables must be set under Settings, Configuration as Application settings.

At Settings, Custom domains a dedicated domain for the application can be configured.

At Monitoring, App Service logs the output of the container logs (docker logs -f …) can be activated. Select File System at Application Logging.

Network configuration

Network requests from the application (for instance to a database) are originated from addresses listed at Settings, Networking (preview), Outbound addresses (there are a lot of addresses!). Add this addresses to the network configuration of database or other dependencies.

There is a better way! See here.

CI/CD integration

To integrate building and publishing of the Docker image and loading it in the App Service in Gitlab it is required to tag the image using the selected Azure registry.

Building and publishing

  script:
      - VERSION=...
      - echo -n "$VERSION" > generated-version.txt
      - docker build --tag $AZURE_IMAGE_NAME:latest
                     --tag $AZURE_IMAGE_NAME:$VERSION
                     .
      - docker login -u $AZURE_REGISTRY_USER -p $AZURE_REGISTRY_PASSWORD $AZURE_REGISTRY
      - docker push $AZURE_IMAGE_NAME:latest
      - docker push $AZURE_IMAGE_NAME:$VERSION

While AZURE_REGISTRY and AZURE_IMAGE can be set in the CI script and maintained in the repository the credentials AZURE_REGISTRY_USER and AZURE_REGISTRY_PASSWORD must strictly not be entered in the repository but injected as CI variables from Gitlab. Here the admin user credentials of the registry must be used.

Triggering the deployment

  script:
      - curl $WEBHOOK_URL -u '$'${WEBHOOK_USER}':'${WEBHOOK_PASSWORD} -X POST -H "" -d ""

Unfortunately the Webhook URL from the App Service contains a dollar-sign at the beginning of the username in the URL. I haven't managed it to pass this correctly from the CI variables into the script. The dollar-sign was always interpreted as a variable dereferencing. So, the complete Webhook URL has been splitted into three parts: the URL without credentials (in the variable WEBHOOK_URL), the username without the leading dollar-sign (in the variable WEBHOOK_USER) and the password (in the variable WEBHOOK_PASSWORD). These three variable must be set as CI variables.

Make sure the trigger the deployment only for a dedicated production deployment branch or for tags using a ONLY statement in the CI script.

Virtual Networking in the Context of App Services

To connect a web app to a database the straight way via the official IP address or name of the database is not the way to be chosen. It can also be done using virtual networks and private endpoints but unfortunately it is not really intuitive.

This way you don't need to enter all the many outbound addresses of the web app into the connection security of the database.

Virtual network

  • Create a Virtual Network, choose for instance 192.168.1.0/24 as address range.
  • Within that virtual network, create two subnets, one for the database and one for the web app. I assigned 192.168.1.0/28 to the database subnet and 192.168.1.16/28 to the web app subnet.

Private Endpoint

  • Create a private endpoint for the database within the above create virtual networks within the subnet for the database.
  • Assign the private endpoint to the database.
  • In the DNS configuration of the private endpoint you can look up the IP address and DNS name assigned to the database. Take a note.

Connection security of database

  • Configure the connection security of the database to allow access from the above created virtual network, subnet of the web app.

Configuration of the web app

  • In Networking (preview) under Outbound Traffic use VNet Integration to assign the above created virtual network, subnet of the web app
  • In Configuration, Application Settings (or whereever the database connection string for the database client of the application is) set the DNS name of the private endpoint of the database. It is crucial to use the DNS name and not the IP address, otherwise SSL certificate validation won't work.
knowledge/deployingawebapponazure.txt · Last modified: 2021/11/29 11:41 by wn

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki