Azure Deployment Basics and Advanced Techniques

Azure deployment can seem overwhelming, but breaking it down into basics and advanced techniques can make it more manageable.

You can deploy Azure resources using the Azure portal, Azure CLI, or Azure PowerShell.

The Azure portal is a user-friendly interface that allows you to deploy resources with just a few clicks.

Azure CLI and Azure PowerShell provide more flexibility and automation capabilities for large-scale deployments.

To deploy resources using the Azure portal, you'll need to create a resource group, select a deployment template, and configure the necessary settings.

Azure provides a variety of deployment templates, including ARM templates and Bicep templates, which can be used to automate deployments.

ARM templates are a popular choice for deploying Azure resources, as they allow for a high degree of customization and flexibility.

Bicep templates are a newer, more modern alternative to ARM templates, offering improved syntax and better support for Azure services.

Azure offers a free tier for its services, allowing you to deploy and test your applications without incurring costs.

To deploy an application on Azure, you'll need to create a resource group, which is a logical container for your resources. This helps you organize and manage your resources more efficiently.

Azure supports various deployment models, including Azure Resource Manager (ARM) and classic deployment. ARM is the recommended deployment method, as it provides a more structured and automated way of deploying resources.

Azure Deployment Environments share certain architectural components with Microsoft Dev Box.

Dev centers and projects are common to both services, helping to organize resources in an enterprise.

You might see Dev Box resources and components when configuring Deployment Environments.

These resources are likely to be ignored if you're not configuring any Dev Box features.

Dev Box provides developers with a cloud-based development workstation, configured with the tools they need for their work.

During deployment, your app can behave unpredictably because the files aren't all updated at the same time. This can be a problem for customer-facing apps.

Locked files can cause deployment to fail, and running your app directly from the ZIP package can help avoid this issue.

Stopping your app or enabling offline mode during deployment can also prevent problems with locked files. For more information, see Deal with locked files during deployment.

There are a few ways to avoid issues during deployment:

You can use FTP/S to directly transfer files to Azure Functions, although this deployment method isn't recommended.

To use FTP/S, you should disable FTP if you're not planning on using it, as it's not recommended.

If you do choose to use FTP, you should enforce FTPS to ensure secure file transfers.

To learn how to enforce FTPS, see the Azure portal for instructions.

The URL and credentials you need to deploy to your function app using FTPS can be found in the FTPS deployment settings.

You can deploy images hosted on Docker Hub, but hosting them on a private Azure Container Registry instance is a better option for security.

To start, you'll need to create an Azure Resource Group.

Create an Azure Container Registry instance to host your images securely.

First, find the username and password for the admin to authenticate into Azure Container Registry and pull the Docker image.

Azure Container Registry loginServer and the image name of your Quarkus application are essential details to keep in mind.

You can deploy to Azure Container Instances, which creates a container on Azure infrastructure.

Keep in mind that Azure Container Instances does not provide scalability, as a container instance is unique and does not scale.

Using deployment slots is a great way to deploy a new production build without downtime. You can deploy your app to a staging environment, validate your changes, and do smoke tests before swapping it with your production slot.

Azure Deployment Environments are perfect for common scenarios such as testing and validation, as well as canary releases and blue-green deployments.

A Standard App Service Plan tier or better is required to use deployment slots, which will automatically warm up the necessary worker instances to match your production scale during the swap operation.

This approach eliminates downtime and ensures a seamless transition to the new production build.

To automate Azure deployment, you can use other automation providers like CircleCI or Travis CI. These tools require the Azure CLI to update deployment slots with new image tags, which can be done by generating a Service Principal using the command `az ad sp create-for-rbac`.

You can then use the Azure CLI in your automation script to sign in with `az login --service-principal` and update the deployment slot with `az webapp config container set`.

For a build pipeline, you need to choose a deployment source and select a build pipeline that reads your source code and executes necessary steps to get the application in a runnable state. This can be done on a build server like Azure Pipelines or executed locally.

Here are some common automation frameworks:

A build pipeline is a series of steps that take your source code and turn it into a runnable application. It's like a production line where your code is compiled, tested, and packaged into a deployable format.

You can choose from various build servers like Azure Pipelines, or even run it locally on your machine. The specific steps executed by the build pipeline depend on your language stack, so you'll need to choose the right tools for the job.

If you're using GitHub as your deployment source, you might see a few options to select for build providers. These providers help automate build, test, and deployment tasks for Azure App Service. The options include GitHub Actions, App Service Build Service, and Azure Pipelines.

Here are some key features of each build provider:

The specific build provider you choose will depend on your deployment source and needs. For example, if you're using GitHub, GitHub Actions might be a good choice.

The user-assigned identity option is a powerful tool for automating authentication with GitHub Actions. It creates a federated credential between a user-assigned managed identity in Azure and your selected repository and branch in GitHub.

This federated credential allows for OpenID Connect authentication between the two platforms. Specifically, App Service does three operations: creates a federated credential, creates secrets AZURE_CLIENT_ID, AZURE_TENANT_ID, and AZURE_SUBSCRIPTION_ID, and assigns the identity to your app.

The user-assigned managed identity is created in Azure, and if your Azure account has the required permissions, App Service will create it for you. However, if your Azure account doesn't have the required permissions, you'll need to select an existing identity with the required role.

The required role for the user-assigned managed identity is either Owner, Contributor, or Websites Contributor. The least privileged role that the identity needs is Websites Contributor.

You can create a project in Azure Deployment Environments to host transient activities like workshops, hands-on labs, training, or hackathons. This project acts as a container for these activities.

Each user can create identical and isolated environments for training within a project. This ensures that everyone has a consistent experience.

You can easily delete a project and all related resources when the training is over. This makes cleanup a breeze.

Here are the benefits of using Azure Deployment Environments for hands-on training and labs:

To get started with automation and tools, you'll want to install the CLI.

The Azure CLI is a command-line tool that helps you manage Azure resources, so it's a great place to begin.

Visit the Azure CLI installation page for instructions specific to your operating system, whether you're on Windows, macOS, or Linux.

Ensure you are authenticated after installation to access Azure resources.

Zip deploy is the default and recommended deployment technology for function apps on certain plans.

It's a convenient option that allows you to deploy your app with just a few clicks, using tools like Visual Studio Code, Visual Studio, or the Azure CLI.

The result is a ready-to-run .zip package that your function app runs on, stored on the file system or Azure Files.

Zip deploy yields faster loading times for your applications, making it a great choice for many developers.

To use zip deploy, you can set your app to run from package by setting the WEBSITE_RUN_FROM_PACKAGE application setting value to 1.

This is the default for VS Code, Visual Studio, and the Azure CLI, making it a seamless experience for many users.

App content from a zip deploy is stored on the file system, which may be backed by Azure Files from the storage account specified when the function app was created.

In Linux Consumption, the app content is instead persisted on a blob in the storage account specified by the AzureWebJobsStorage app setting.

External Package URL is an option if you want to manually control how deployments are performed.

You take responsibility for uploading a ready-to-run .zip package containing your built app content to blob storage and referencing this external URL as an application setting on your function app.

To use it, add WEBSITE_RUN_FROM_PACKAGE to your application settings, with the value being a blob URL pointing to the location of the specific package you want your app to run.

You can add settings either in the portal or by using the Azure CLI.

Azure Blob Storage is recommended because managed identity is the preferred option for overall security, and SAS tokens expire and must be manually maintained.

Whenever you deploy the package file, you must manually sync triggers, including the initial deployment.

You must also restart your function app to sync triggers when you change the contents of the package file and not the URL itself.

This method is the only supported deployment method for apps running on the Linux Consumption plan when you don't want a remote build to occur.

You can store your app content in any blob storage account, but Azure Blob Storage is recommended.

To configure the deployment source for your Azure App Service app, you'll need to head to the management page for your app in the Azure portal. In the left pane, select Deployment Center, then Settings.

To get started, select one of the CI/CD options in the Source box, such as GitHub, Bitbucket, Local Git, Azure Repos, or Other repositories. GitHub Actions is the default build provider, but you can change it by selecting Change provider > App Service Build Service > OK.

If you're deploying from GitHub for the first time, you'll need to authorize your Azure account with GitHub. This involves selecting Authorize and following the authorization prompts. If you want to deploy from a different user's repository, select Change Account.

For Azure Pipelines, you can configure it directly from Azure Pipelines, but not from App Service. The Azure Pipelines option just points you in the right direction. To use Azure Pipelines, select the Azure DevOps Organization, Project, Repository, and Branch you want to deploy continuously.

To manually configure continuous deployment from a cloud Git or Mercurial repository, you can select External Git in the Source dropdown list. This includes repositories like GitLab.

When configuring the source for your App Service app, you need to specify the location of your application code. This is typically a repository hosted by version control software like GitHub, BitBucket, or Azure Repos.

To do this, go to the management page for your App Service app in the Azure portal and select Deployment Center. Then, select Settings and choose one of the CI/CD options in the Source box, such as GitHub, BitBucket, or Local Git.

For GitHub, you'll need to authorize your Azure account and select the Organization, Repository, and Branch you want to deploy from. If you're deploying from a different user's repository, you can select Change Account.

If your Azure account doesn't have the required permissions to create a user-assigned managed identity for GitHub Actions, you'll need to work with your Azure administrator to create an identity with the required role on your app.

Here are the steps to configure the source for different build providers:

For Windows apps, you can manually configure continuous deployment from a cloud Git or Mercurial repository that the portal doesn't directly support, like GitLab, by selecting External Git in the Source dropdown list.

To disable continuous deployment in Azure App Service, you'll need to head to the management page for your app in the Azure portal.

In the left pane, select Deployment Center, then click on Settings and choose Disconnect. This will stop the automatic deployment of your app.

The GitHub Actions workflow file is preserved in your repository by default, but it continues to trigger deployment to your app. To delete the file from your repository, select Delete workflow file.

Here's a step-by-step guide to disabling continuous deployment:

To edit your functions in the Azure portal, you must have created them in the portal itself.

You can directly edit the files in your function app using the portal-based editor, essentially deploying every time you save your changes.

Using any other deployment method makes your function read-only and prevents continued portal editing.

To return to a state where you can edit your files in the Azure portal, you can manually turn the edit mode back to Read/Write.

Microsoft Dev Box and Azure Deployment Environments share certain architectural components. Dev centers and projects are common to both services, helping to organize resources in an enterprise.

You might see Dev Box resources and components when configuring Deployment Environments. This is because the two services are complementary and share some underlying infrastructure.

Dev Box provides developers with a cloud-based development workstation, called a dev box, which is configured with the tools they need for their work. This is a key feature of Dev Box, but it's not directly related to configuring Deployment Environments.

If you're not configuring any Dev Box features, you can safely ignore informational messages regarding Dev Box features. This will help you stay focused on configuring your Deployment Environments.

Local Cache is a high-performance, read-only content store that can be used with Azure App Service to improve availability. It's perfect for apps that need fast access to content.

Local Cache isn't recommended for content management sites like WordPress, so keep that in mind when deciding whether to use it. Always use local cache in conjunction with deployment slots to prevent downtime.

To use local cache with deployment slots, navigate to your Web App in the Azure portal, select Diagnose and solve problems, and then choose the Best Practices homepage tile. From there, you can view the current state of your app's availability and performance.

Here are the steps to access App Service Diagnostics: