• +000 0000 000
  • [email protected]
    • Contact Us

    Category Archives: Securing an app service

    1. Home / 
    2. Archive by category "Securing an app service"
    Sep 4, 2024
    Deploying AKS 2 – Creating and Configuring Containers
    1. Next, we have the Authentication tab; here, you will note we can modify the setting for the Authentication method type to either Service principal or System-assigned managed identity. This will be used by AKS for managing the infrastructure related to the service. For this exercise, we will leave this at its default setting. Then, you have the Role-based access control (RBAC) option. By default, this is set to Enabled; this is the best option to manage the service as it allows fine-grained access control over the resource; leave this as Enabled. You will also have the choice to enable AKS-managed Azure Active Directory. Checking this will enable you to manage permissions for users on the service based on their group membership within Azure AD. Note that once this function has been enabled, it can’t be disabled again, so leave this unchecked for this exercise. Finally, you have the option of the Encryption type value you want. For this exercise, leave it as the default setting. Click Next: Networking >. The process is illustrated in the following screenshot:

    Figure 11.47 – Creating a Kubernetes cluster: Authentication tab

    1. For the Networking section, we will leave most of the settings as their default configuration. Note that for Network configurations we have two options here, one for Kubenet and another for Azure CNI. kubenet is a new VNet for the cluster whereby Pods are allocated an IP address and containers have network address translation (NAT) connections over the shared Pod IP. Azure Container Networking Interface (Azure CNI) enables Pods to be directly connected to a VNet. In association, this allows containers to have an IP mapped to them directly, removing the need for NAT connection. Next, we have the DNS name prefix field, which will form the first part of your FQDN for the service. You will then notice Traffic routing options available to us for the service—we will discuss this more in one of the next exercises, as well as the Security options available to us. Select Calico under Network policy. Click Next: Integrations >. The process is illustrated in the following screenshot:

    Figure 11.48 – Creating a Kubernetes cluster: Networking tab

    1. On the Integrations tab, you will note the option to select a container registry. We will select the registry that we previously deployed. You will also note you have the option to deploy a new registry directly from this creation dialog. Next, we have the option to deploy container monitoring into the solution on creation. We will leave the default setting here, but monitoring will not be covered under the scope of this chapter. Finally, you have the option of applying Azure Policy directly to the solution; this is recommended where you want to enhance and standardize your deployments. This solution enables you to deliver consistently and control your deployments on AKS more effectively. Click Review + create, then click Create. The process is illustrated in the following screenshot:

    Figure 11.49 – Creating a Kubernetes cluster: deployment

    You have just successfully deployed your first Kubernetes cluster; you now know how to deploy and manage containers at scale and in a standardized way. Next, we will look at how we configure storage for Kubernetes and make persistent storage available to our solution.

    More Details
    Mar 10, 2024
    Configuring network connections for AKS – Creating and Configuring Containers

    Configuring network connections for AKS

    We have covered AKS cluster deployment in one of the previous exercises. In this section, we will elaborate on some networking configurations to give you a better understanding of the options available to you.

    Network configuration

    The first component in your network configuration is the different types of networks that are available for you to deploy.

    kubenet

    This is the most basicnetworking service for AKS. With kubenet, an IP address is allocated from an Azure VNet to the nodes for a Pod. The Pods receive an IP address from an internal network that is deployed in a logically different address space from the VNet. Connections to these Pods are then performed through NAT connections that allow Pods to communicate to resources on the Azure VNet. This approach reduces the number of IP addresses required for your solution but disables the ability to directly connect to your containers.

    Azure CNI

    This is a moreadvanced implementation networking service for AKS. Azure CNI enables Pods to be directly connected to an Azure VNet, and therefore every Pod is allocated an IP address on the VNet. Without careful planning, you may exhaust your IP allocation on the subnet you are connecting to.

    Regardless of the solution you choose, external traffic is still conducted over a NAT connection to nodes within AKS from a public IP interface.

    Traffic routing

    Traffic routing comprisesthe load balancing and application routing configurations available to your AKS cluster.

    Load balancer

    The AKS cluster can be deployed using both a standard SKU and a basic SKU. A standard SKU enforces traffic securely, restrictstraffic by default, andrequires explicit allow rules to enable traffic flow. The default option Standardis and is the recommended choice unless there is a specific reason for Basic, such as your organization only allowing private IP access. Basic can only be deployed using the Azure command-line interface (CLI), PowerShell, or an ARM template.

    Enabling HTTP application routing

    Please note before enabling this feature that it is currently not designed or ready for production environments and is something I would advise being cautious about enabling until Microsoft’s documentation reflects that this is ready for production use.

    The solution deploys two components, one being an External-DNS controller component, which creates DNS host A records for the cluster DNS zone, and the second resource being an ingress controller component, which is responsible for routing ingress traffic to application endpoints.

    More Details
    Jul 4, 2023
    Creating an App Service plan – Creating and Configuring App Services

    Creating an App Service plan

    In this exercise, you will be creating an App Service plan for Azure. This will act as the server configuration for hosting your Azure web applications and function applications. Follow these steps to do so:

    1. Sign in to the Azure portal at https://portal.azure.com.
    2. Open the resource group you will be using for this exercise, click Overview via the left menu, and clickCreate.
    3. Type app service plan in the search bar and click App Service Plan:

    Figure 12.2 – App Service Plan

    1. On the next screen, click Create:

    Figure 12.3 – App Service Plan – Create

    1. Enter the name of your Resource Group, then enter a name for your App Service plan. Here, we have used myappserviceplan. Next, choose an Operating System. For this demo, we will deploy a Windows App Service plan. Finally, select your Region and SKU and size; we will select Standard S1. Click Review + create, then Create:

    Figure 12.4 – Create App Service Plan

    With that, you have configured your first App Service plan and are ready to host your first application on the service. In the next section, you will learn how to create an App Service in your newly deployed App Service plan.

    Creating an app service

    In this exercise, you will deploy your first web application in Azure using the Azure Web Apps service. Follow these steps:

    1. Sign in to the Azure portal at https://portal.azure.com.
    2. Open the resource group you will be using for this exercise, click Overview via the left menu, and clickCreate.
    3. From the left menu bar, clickWeb, then click Create under Web App:

    Figure 12.5 – Web App

    1. Enter the name of your Resource Group, then enter a name for your web app. Here, we have used myfirstwebapp221221. Next, choose the type of deployment you would like. We will select Code. Note that you could also select a Docker Container. Then, select a Runtime stack – this will support the code you are deploying. Now, choose an Operating System. For this demo, we will deploy a Windows web app; we did this for the App Service plan we deployed previously. Select your Region, this will also be the same as what you selected for your App Service plan:

    Figure 12.6 – Create Web App – Basics

    Finally, select a Windows Plan – this is the App Service plan you created previously. Note that when you select this, it automatically configures your SKU and size, which will match what you chose for your App Service plan. Also, note that you have the option to create your App Service plan directly in the Deployment menu. Click Next : Deployment >:

    Figure 12.7 – Create Web App – Basics 2

    1. Here, you have the option to do a Continuous deployment. We won’t be configuring this in this exercise. Click Next : Monitoring >:

    Figure 12.8 – Create Web App – Deployment

    1. On the Monitoring tab, you will have the option to deploy Application Insights for your application. Note that you can either create a new Application Insights deployment through this blade or create it as part of the deployment. For this exercise, we will select No for Enable Application Insights. Click Review + create, then Create:

    Figure 12.9 – Create Web App – Monitoring

    1. Navigate to your application, click on Overview via the left-hand menu, and note your URL for your application. This blue text is clickable; you can either click on this or copy it into your browser to navigate to your application to confirm that it’s working:

    Figure 12.10 – Web App – Overview

    You will be presented with a screen similar to the following for your application. Congratulations – you have successfully deployed your application using the Azure portal!

    Figure 12.11 – Web App – running in your browser

    Now that you know how to deploy a web application using the Azure portal, let’s learn how to do the same using PowerShell. This time, we will create a Linux service plan.

    More Details
    Jan 15, 2023
    Securing an app service 4 – Creating and Configuring App Services
    1. The next configuration for inbound traffic isApp assigned address. Clicking this option will take you to the TLS/SSL settings blade. This is used to determine your Custom Domain, which we will configure in the next section. This is another method of enhancing security as the domain can be configured to something that is trusted by your organization or users. It will confirm that you are using certificate delivery to enhance the security of your application:

    Figure 12.35 – Network settings – Inbound Traffic 2

    1. The last inbound configuration option is Private endpoints. Selecting this allows you to completely remove all public access to your application. Your application will be assigned an NIC with a private IP from the associated VNet and subnet you connect it to. To enable public access for this configuration, you would need some form of network address translation (NAT) configuration to reach your application. This can be achieved by deploying an Application Gateway or using Azure Front Door, or by using your firewall service to translate traffic from one of its public IP addresses to your application over the private endpoint. This is a great way to secure traffic to your application, but as you can see, it can quickly cause complications. This setting will force you to consider how other components of your application communicate with each other and the outside world.
    2. For outbound communication, you can perform VNet integration, which will associate your application with a designated subnet. Note that to assign a web app to a subnet, it will need to assume delegated access for the subnet. This means that it can manage the DHCP deployment for the subnet and will be responsible for IP assignment on the subnet. Furthermore, it restricts what can access the subnet and limits you to which subnet can be used for what service as only a single service can have delegated administration. Note that this is for outbound communication only and will not protect inbound communication. The subnet should also be allowed to communicate with the relevant services within Azure. Click VNet integration:

    Figure 12.36 – Network settings – Outbound Traffic 1

    1. Click + Add VNet:

    Figure 12.37 – VNet Configuration

    1. You can also select an appropriate Virtual Network, which will give you the option to either create a new subnet or use an existing one. Use whichever best suits this demo and click OK:

    Figure 12.38 – Add VNet Integration

    Note that your application is now connected to the VNet and subnet you selected. Note the address details as well. Traffic from your application can now be controlled for outbound traffic using user-defined routes (UDRs) on the network:

    Figure 12.39 – VNet Configuration

    1. The last configuration item for outbound traffic isHybrid connections. This feature is a service that enables endpoint connectivity for your application and provides
      a connection solution where you don’t have direct access paths to your on-premises environments or other environments from Azure. It enables a mechanism for TCP communication that’s mapped to a port number for that corresponding system or service. Each hybrid connection is associated with a single host and port that enhances security as it’s easier to manage and correlate the traffic:

    Figure 12.40 – Network settings – Outbound Traffic 2

    The final security configuration item to be aware of is the CORS option under API context on the left menu pane. CORS should be disabled unless it’s required as it exposes more vulnerabilities to your application, especially when it’s not managed correctly:

    Figure 12.41 – Network settings – CORS

    Now that you have reviewed the different security settings, you should feel more familiar with the controls that are available and when to use them. It’s especially important to understand the configurations that are relative to traffic flow. In the next section, you will learn how to configure custom domain names.

    More Details
    Jan 11, 2023
    Securing an app service 2 – Creating and Configuring App Services
    1. You will see a screen with additional configuration settings. The first item to configure is the application registration. This can be used to assign permissions and will configure a service principal account in Azure AD called an app registration. For this exercise, select Create new app registration and assign a name. Next, select the option for supported account types for your application. Depending on how and where your application is used, this will dictate the configuration that best suits your security requirements. For instance, if you are looking to deliver an internal application such as something that lists the mobile numbers of employees within your organization so that you can contact someone urgently (where sharing this information is disallowed publicly), then you would want to restrict public access (that is, anyone external to your organization).

    Using your identity provider will help you determine if they have an account with your organization or not. In such cases, you can select Current tenant – Single tenant. Any Azure AD direction – Multi-tenant will allow you to accept user logins from any other Azure AD directory. The next option, Any Azure AD directory & personal Microsoft accounts, opens access to public accounts too, where personal accounts can be used. Finally, Personal Microsoft accounts only removes access from other Azure accounts and limit this to personal Microsoft accounts. This is typically used for gaming services, whereyou want to allow friends to connect but you also want to restrict business accounts from accessing the service. As you can see, the most secure option is Current tenant – Single tenant. You can also configure Restrict access, where you can force authentication to be conducted before access is granted to your application. Unauthenticated access allows users to log in anonymously. Choose Require authentication since this is the most secure option. Finally, you can choose what kind of error handling you would like to deliver upon detection, such as delivering an HTTP 401 Unauthorized error message. Select HTTP 302 Found redirect. Then, click Next : Permissions >:

    Figure 12.27 – Identity provider configuration

    1. The next blade relates to the Permissions options you would like to grant. The default option is User.Read, which allows the application to read the user’s profile. These permissions can be modified as needed to deliver the required information to your application. These permissions will be prompted by the user when they access the application and are being authenticated. They will need to consent to this permission request if they wish to access the application. Click Add:

    Figure 12.28 – Identity provider – Permissions

    1. Click Identity from the left menu pane for the application. You will be presented with two tabs – System assigned and User assigned. Here, you can choose which deployment configuration you would like to use. System assigned allows you to create a managed identity whose life cycle is controlled and managed by Azure. A managed identity allows you to grant RBAC permissions to the application as if it were a user, which gives them better control over resources and prevents user management issues such as abuse of privileges or mistakes being made. Enabling this setting increases the security of your application and prevents credentials from being injected directly into code, which would allow account and system compromise to occur. User assigned is managed manually but can be configured more granularly for control over the specific RBAC permissions you would like to grant to the application. On the System assigned tab, click On under the Status option, then click Save:

    Figure 12.29 – System assigned

    1. After clicking Save, you will see a new configuration option, where you can configure the Azure RBAC permissions for your application:

    Figure 12.30 – Adding a role assignment

    More Details
    Nov 4, 2022
    Configuring custom domain names – Creating and Configuring App Services

    Configuring custom domain names

    Custom domains allow you to connect to your web application using the public DNS name that you have chosen for your application. To do this, you need to own the respective domain and prove that you have authority over it. Your custom domain could be, for example, www.yourapp.com. There are several providers for purchasing a domain, though this is outside the scope of this book. For suggestions on getting started, you could buy directly from Microsoft, which also leverages GoDaddy. To configure a custom domain, follow these steps:

    1. Navigate to the App Service plan you worked on in the previous exercises.
    2. From the left menu blade, theSettings, click Custom domains. From the blade that appears, click + Add custom domain.
    3. Enter a Custom domain name of your choice, such as www.yourapp.com (this must be for a domain that you own). Click Validate:

    Figure 12.42 – Add custom domain

    1. You will be presented with a screen that gives you a Custom Domain Verification ID:

    Figure 12.43 – CName configuration

    Copy this ID and create a new CName and TXT record for your domain, as follows. These values will be used to determine that you have authority over the domain you have specified:

    Top Tip

    You can also map custom domains using A records or a wildcard (*) CNAME record. Go to https://docs.microsoft.com/en-us/azure/ app-service/app-service-web-tutorial-custom-domain?tabs=a%2Cazurecli#dns-record-types for more details.

    1. Once completed, click the Validate button again.
    2. The following screenshot shows an example of the TXT and CName records that you may have created with your domain host (all the providers have slightly different configurations):

    Figure 12.44 – TXT and CName records

    1. You will get two successful messages after clicking the Validate button. Now, click Add custom domain:

    Figure 12.45 – Add custom domain

    1. With that, your custom domain has been added. However, you now have an entry on your screen that shows that this endpoint is not secure. You will need to add a certificate to make it secure. Click TLS/SSL settings from the left menu:

    Figure 12.46 – Insecure custom domain

    1. Click the Private Key Certificates (.pfx) tab. Then, click + Create App Service Managed Certificate:

    Figure 12.47 – Private Key Certificate

    1. Once Azure has analyzed the eligibility of the hostname, click Create. Azure allows one certificate per web app to be generated by the platform for your custom domain. This can save you a lot of money as, typically, you will need to procure a certificate from a third-party vendor. Your certificate will be valid for 6 months once it’s been created.
    2. DNS propagation can take up to 48 hours to occur, though sometimes, this can happen within minutes, depending on whether your DNS was used and the Time to Live (TTL) setting has been configured. You should now be able to browse your web app using the custom domain you configured. Note that you can connect using HTTPS and get a valid certificate check:

    Figure 12.48 – Browsing to your custom domain

    You now know how to configure a custom domain for your web app within Azure, as well as how to generate a valid certificate using the platform for a certified secure HTTPS connection. Typically, this can be done for production-based applications that are exposed to the internet and it is a common administrative duty for those that work in organizations that utilize many web applications. In the next section, you will learn how to configure backups for your applications.

    More Details
    Jul 14, 2022
    Configuring networking settings – Creating and Configuring App Services

    Configuring networking settings

    You learned how to perform VNet integration in the Securing an app service section. In this section, you will learn how to configure behind a private endpoint:

    1. Navigate to the App Service plan you worked on in the previous exercises.
    2. From the left menu blade, underSettings, click Scale up (App Service plan). On the blade that appears, ensure that you have chosen the Premium V2, Premium V3, or Elastic Premium SKU to continue with this exercise. Click Apply.
    3. From the left menu blade, underSettings, click Networking. From the blade that appears, click Private endpoints in the Inbound Traffic section:

    Figure 12.53 – Private endpoints

    1. Click Add:

    Figure 12.54 – Private Endpoint connections – Add

    1. Enter a Name, ensure that you have the right Subscription selected, and select the correct Virtual network your private endpoint will be connecting to. Then, select a Subnet you would like to connect to. Finally, select Yes for Integrate with private DNS zone. Thisfeature allows Azure to create a Fully Qualified Domain Name (FQDN) for your private endpoint that can be reached by your resources. If you select No, then you will need to ensure that your DNS zone is maintained by another DNS service, such as Active Directory (on-premises version), and configured on your VNet for DNS lookup queries to forward to your DNS server(s):

    Figure 12.55 – Add Private Endpoint

    1. On the Private Endpoint connections screen, which you will see after deploying your resource, click on the new endpoint you have created. Click the name of your Private endpoint (where the text is highlighted in blue) to open the Private endpoint blade:

    Figure 12.56 – Backup overview

    1. From the left menu blade, under theSettings context, click Networking. From the blade that appears, scroll down to Customer Visible FQDNs and note the FQDN names associated with your service. Note that these are now associated with a private IP that belongs to the subnet you selected previously:

    Figure 12.57 – Customer Visible FQDNs

    1. Scrolling down further, you will see Custom DNS records. Note that the FQDN variable that’s been assigned is very much the same as the website FQDN you have for azurewebsites.net, except it also contains privatelink as a prefix. So, you now have an FQDN of [app name].privatelink.azurewebsites. net. This is also associated with the private IP we saw previously. Note that if you performed an NSLookup on the preceding FQDNs, you will get a public IP address for your service:

    Figure 12.58 – Custom DNS records

    1. Attempting to access your site now will deliver a 403-Forbidden error since public access is now revoked:

    Figure 12.59 – Error 403 – Forbidden

    Top Tip

    If you have applied DNS to the VNet you are associating with and have configured a private DNS zone, you will need to ensure that your DNS servers have been configured to forward lookup to Azure for the private endpoint namespace related to your service.

    With that, you have just configured a private endpoint and should feel confident in how to deploy one. You are also aware of some of the DNS complexities you should look out for to ensure you can resolve the host correctly by your resources.

    More Details
    Mar 4, 2022
    Downloading and extracting files for labs – Practice Labs – Deploying and Managing Azure Compute Resources

    Downloading and extracting files for labs

    Follow these steps to download and extract the required files:

    1. Navigate to the following URL and download the archive folder (.zip): https://github.com/MicrosoftLearning/AZ-104-MicrosoftAzureAdministrator/archive/master.zip.
    2. Depending on the browser you are using, you will likely be presented with different versions of the following dialog. Click Save File and OK at the bottom of the screen:

    Figure 13.1 – Downloading files (ZIP)

    1. Right-click the ZIP file you downloaded and click Extract All…(on Windows systems):

    Figure 13.2 – Extract All… (ZIP)

    1. Navigate to your downloaded folder and follow instructions from labs when needing files that will be in that folder.

    You have now downloaded all the files you need for performing the labs later in the chapter.

    Managing virtual machines lab

    This lab willguide you through creating standalone Virtual Machines (VMs) and VMs as a scale set, as well as exploring storage for these different deployments and how both solutions can be scaled. Furthermore, you will explore how VM custom script extension can be assigned and use to automatically configuring your VMs.

    Estimated time: 50 minutes.

    Lab method: PowerShell, ARM templates, and the Azure portal.

    Lab scenario: In this lab, you play the role of an administrator evaluating different methods for deploying VMs for scale and resiliency. You are also exploring how VMs manage storage to support your scale. You need to determine whether standalone VMs or VMs deployed as a scale set are best suited to your deployments and understand the differences between them to ascertain when to use the different deployment types. As part of your exploration task, you want to see whether there is any mechanism that can assist you in reducing the administrative effort involved in deploying your VMs or automatically completing configuration tasks. You have heard that a custom script extension can assist with this, and you want to see how this will guide you to achieve your expected result.

    Visit the following link (Lab URL) to the official Microsoft Learning GitHub labs, where you will be guided through each task step by step to achieve the following objectives.

    Lab objectives:

    1. Task one: Deploy two VMs in two different zones for resiliency.

    II. Task two: Use VM extensions to configure your VMs.

    III. Task three: Configure and attach data disks to your VMs.

    IV. Task four: Register the required resource providers for your subscription.

    V. Task five: Deploy your VM scale sets.

    VI. Task six: Use VM extensions to configure your scale set.

    VII. Task seven: Configure autoscale for your scale set and attach data disks.

    Lab URL: https://microsoftlearning.github.io/AZ-104-MicrosoftAzureAdministrator/Instructions/Labs/LAB_08-Manage_ Virtual_Machines.html.

    Lab architecture diagram: The following diagram illustrates the different steps and deployment components involved in the exercise. The tasks are numbered 1 to 7 to correlate with the steps in the exercise:

    Figure 13.3 – Managing VMs – architecture diagrams

    You have now experienced working with VMs both as individual resources and scale sets and should feel confident in working with these in your environments. It’s best practice to delete your resources from the lab to prevent unnecessary spending.

    More Details
    Jan 11, 2022
    Deploying an Azure Container Instances lab – Practice Labs – Deploying and Managing Azure Compute Resources

    Deploying an Azure Container Instances lab

    This lab willguide you through creating a container group using Azure Container Instances using a Docker image and testing connectivity to your deployed containers.

    Estimated time: 20 minutes.

    Lab method: PowerShell and the Azure portal.

    Lab scenario: In this lab, you play the role of an administrator who is looking to reduce their container management activities. Your organization, Contoso, has several virtualized workloads, and you want to explore whether these can be run from Azure Container Instances using Docker images.

    Visit the following URL to the official Microsoft Learning GitHub labs, where you will be guided through each task step by step to achieve the following objectives.

    Lab objectives:

    I.  Task one: Use Azure Container Instances to host your container.

    II. Task two: Confirm connectivity to your container and functionality.

    Lab URL: https://microsoftlearning.github.io/AZ-104-MicrosoftAzureAdministrator/Instructions/Labs/LAB_09b-Implement_Azure_Container_Instances.html.

    Lab architecture diagram:

    The following diagram illustrates the different steps involved in the exercise:

    Figure 13.4 – Deploying an Azure container instance – architecture diagram

    After running through this lab, you should now feel confident to deploy container instances to Azure. The next lab will take you through using Azure Kubernetes Service for the orchestration of your container instance deployments.

    Deploying an Azure Kubernetes Service lab

    This labwill guide you through setting up an Azure Kubernetes Service instance and deploying an NGINX pod for your multi-tier applications. You will implement node scaling as part of the exercise and learn to leverage Kubernetes as an orchestration service in Azure.

    Estimated time: 40 minutes.

    Lab method: PowerShell and the Azure portal.

    Lab scenario: In this lab, you play the role of an administrator who is looking to reduce container management activities and implement container orchestration services. Your organization, Contoso, has several multi-tier applications that are not suitable for Azure Container Instances. You want to explore running these through Kubernetes, and since Azure has Azure Kubernetes Service (AKS), you want to leverage this to minimize administrative effort and complexity in deploying your solution.

    Visit the following URL to the official Microsoft Learning GitHub labs, where you will be guided through each task step by step to achieve the following objectives.

    Lab objectives:

    1. Task one: Register the required resource providers for your subscription.

    II. Task two: Deploy AKS.

    III. Task three: Deploy your AKS pods.

    IV. Task four: Configure scaling for your AKS cluster.

    Lab URL: https://microsoftlearning.github.io/AZ-104-MicrosoftAzureAdministrator/Instructions/Labs/LAB_09c-Implement_Azure_Kubernetes_Service.html.

    Lab architecture diagram:

    The following diagram illustrates the different steps involved in the exercise:

    Figure 13.5 – Deploying an Azure container instance – architecture diagram

    After working through these previous labs, you should feel confident working with containers on Azure. You are also familiar with some aspects of the Kubernetes service, which can be used for the orchestration of your container instances. You’ve also experienced managing scale using these tools and will be prepared for performing this aspect of your role going forward. The next lab will explore working with Web App service on Azure.

    More Details
    Oct 4, 2021
    Deploying Web App service lab – Practice Labs – Deploying and Managing Azure Compute Resources

    Deploying Web App service lab

    In this lab, you will be guided through the deployment of an Azure container instance with using a Docker image as the source. Finally, you will test connectivity to your containers to prove a successful deployment.

    Estimated time: 30 minutes.

    Lab method: PowerShell and the Azure portal.

    Lab scenario: In this lab, you play the role of an administrator who is looking to utilize Azure App Services for hosting your company’s web applications. Your organization, Contoso, has several websites running in on-premises data centers on servers using a PHP runtime stack. Furthermore, you are looking to start using DevOps practices within your organization and want to use app deployment slots to improve your deployment strategy.

    Visit the following URL to the official Microsoft Learning GitHub labs, where you will be guided through each task step by step to achieve the following objectives.

    Lab objectives:

    I.  Task one: Deploy your Web App and Service plan.

    1. Task two: Create a staging deployment slot for your web app.

    III. Task three: Configure deployment settings for the local Git.

    IV. Task four: Deploy your staging code.

    V. Task five: Swap the staging and production deployment slots.

    VI. Task six: Configure autoscaling and test your web app.

    Lab URL: https://microsoftlearning.github.io/AZ-104-MicrosoftAzureAdministrator/Instructions/Labs/LAB_09a-Implement_Web_Apps.html.

    Lab architecture diagram: The following diagram illustrates the different steps involved in the exercise:

    Figure 13.6 – Deploying an Azure web app – architecture diagram

    You have now experienced working with Azure web apps on the Azure portal as well as configuring autoscale rules. You should now feel confident in using this service within your daily role. It is best practice to remove unused resources to ensure that there are no unexpected costs.

    Summary

    In this chapter, we looked at several compute infrastructure type deployments. We explored the deployments of app services, Azure Container Instances, Azure Kubernetes Service, and VM deployments. We also looked at how to scale and manage these systems through a practical demonstration. You should now feel confident in managing Azure compute resources and working with these on Azure.

    In the next part of the book, we’ll cover the deployment and configuration of network-related services and components. We will explore the management of Azure virtual networks and securing services. We will then explore the load balancing services available to us, and finally, how to monitor and troubleshoot network-related issues.

    More Details