Tag: Azure App Service

Its Day 53 of my 100 Days of Cloud journey, and today I’m going to deploy a Web App using Azure App Service using both manual and automated deployment methods.

In the previous post, we looked at the fundamentals of Azure App Service:

• It can use multiple programming languages to run your Web Apps or Services.
• Benefits of using App Service over on-premise hosting.
• The various App Service plans available.
• Manual or Automated deployment options using familiar tools.
• Integrate directly with multiple providers for authentication.

Manual Deployment

So with all the theory out of the way, lets dive in and deploy a Web App. We’ll start with the manual deployment method. Login to the Azure portal and open the Cloud Shell from the menu bar.

After the shell opens be sure to select the Bash environment:

Next up, we need to create a htmlapp directory to store the files and code for our Web App:

Next, we’ll run this command in order to clone a sample Web App from the Azure Samples respository on GitHub, There are over two thousand code samples available in multiple languages, and you can browse the site here to find what you’re looking for.

git clone https://github.com/Azure-Samples/html-docs-hello-world.git

Now, change to the directory that contains the sample code and run the following command:

az webapp up --location <MyLocation> --name <MyAppName> --html

Replace <myLocation> with the Azure region that you want to deploy the Web App to, and <myAppName> with a name for your WebApp. So in my case, I’ll be running this command:

az webapp up --location northeurope --name MyDay53WebApp --html

Running this command does a number of things:

• Creates a resource group
• Creates an App Service Plan
• Creates the Web App
• Configures default logging for the app

We can see all of this info in the output from the command. We need to make a note of the Resource Group as we’ll need this later for both re-deployment and removal.

So now if we browse to the URL provided in the output:

We can see that the sample website is available. So now lets change the heading – from our bash shell we’ll run code index.html to open the editor.

We can see in Line 10 the title that we saw when we browsed to the site, and on line 19 the header at the top of the page. Lets change this to something different:

We use ctrl-s to save and ctrl-q to quit the editor. Now, we;ll run the same command we ran earlier to redeploy the Web App:

az webapp up --location northeurope --name MyDay53WebApp --html

As we can see from the command output, it detects that the WebApp name specified already exists so will deploy the new content to this app.

And now when we refresh the page, we see that both the header and the title have changed as expected:

Automated Deployment using GitHub

So now lets take a look at one of ways to automate deployment and update of our Web App – we’ll demonstrate this using GitHub.

The first thing we need to do it locate our sample Web App respository in GitHub. Once we locate this, we’ll click on the “Fork” button:

What this does is takes a copy of the repository into our own GitHub account, so now I can see it here:

Now we can use this repository in a CI/CD Deployment model where changes to the App are pushed into production every time we make changes to the code.

So back into the Azure Portal we go, and we need to locate our existing Web App, and click on “Deployment Center”. We can see there is warning that we are in the Production Slot – this is because we are using the Free Tier for this deployment – we’ll look at deployment slots in the next post. So we start by clicking on “Source*” to select the code source, and we select “GitHub”

Now, we need to Authorise Github as the provider:

And now we click “Authorize App Service”

Once we’re loged into Github, we can select the Repository and Branch that we wish to use in our deployment. One thing that I changed here was the Build Provider – where we see “Building with GitHub Actions”, I changed this to “App Service Build Service”

Once all of the options are selected, click on “Save” and a page will appear confirming the settings selected:

So this is now effectively live, if we click on “Logs”, we can see that this created an update to our deployment. And because we are now using the base respository files, we can browse to the site and see we are back to the default title and heading on the site:

So now, we can edit the index.html file directly on GitHub to make changes:

So we’ll do a commit of the changes in GitHub. And if we check our logs again, we can see another deployment has happened:

And if we refresh the website, we can see our changes automatically got published!

Conclusion

So thats an overview of deploying to Azure App Service using manual and automated deployment methods. In the next post, we’ll look at more advanced options like auto-scaling and deployment slots.

Hope you enjoyed this post, until next time!

Its Day 52 of my 100 Days of Cloud journey, and today I’m taking a look at Azure App Service.

After all my promises on Day 49 around doing further blogs on services such as AKS, Azure Monitor, Azure Security Center or Azure File Sync, I’m sure you weren’t expecting me to head off into another direction. The truth is dear reader that I have a rather embarrassing admission to make – I failed to follow my own advice….lets set the scene.

We go back in time to Day 17 where I spoke about the then upcoming Microsoft Ignite Cloud Skills Challenge, which enabled you to obtain a free exam voucher for completing an MS Learn Module. The exam voucher needs to be used by March 15th, and from the list of exams that were on the eligibility list, below were the ones that were of interest to me:

• AZ-204: Developing Solutions for Microsoft Azure
• AZ-800: Administering Windows Server Hybrid Core Infrastructure
• AZ-801: Configuring Windows Server Hybrid Advanced Services
• SC-200: Microsoft Security Operations Analyst
• SC-400: Microsoft Information Protection Administrator

But of course Michael jumped ahead and booked the betas for AZ-800 and AZ-801 (as described in Day 47 and Day 51). So those 2 get scratched off the list and I get left with a choice of 3. And my own advice from Day 17 is ringing in my head:

Its not worth doing it if the only reason is for a free voucher and you don’t really know what to use it for, and then just take an exam for the sake of it because you have the voucher.

So what do I do? I could let the exam expire, or I could pick one of the 3 remaining and give it a go. And as this 100 Days journey is learning experience, I decide to go for the one that I will freely admit I know the least about, and thats AZ-204. Loading up the Microsoft Learn modules from the official exam page, the first thing I see is Azure App Service! A-ha! This looks familiar, and it should as the content was covered briefly on AZ-104.

Overview of Azure App Service

Azure App Service is a Platform as a Service (PaaS) offering that is used to host web applications, REST APIs and mobile back end services.

Because this is a PaaS offering, the underlying infrastructure is fully managed and patched by Azure. You can choose to run App Service on either Windows or Linux platforms depending on your application requirements. Because of this, you can use any programming language to run your Web Applications or Service, and these can the be hosted on App Service. This list includes but is not limited to:

• .NET
• Java
• Node.js
• Ruby
• PHP
• Python

Benefits of App Service

Because Azure App Service is a PaaS offering, it means that you are only responsible for managing the application/service and the data. Everything else is managed by Azure.

As well as the range of programming languages that are supported, you can also run scripts or executables as background services.

You can also scale in/out (adds/removes additional VMs as required) or scale up/down (adds/removes CPU or memory resources as required).

Lets compare this to hosting on your own on-premise servers. You are responsible for the following:

• Procurement of Physical Servers, Storage, Networking equipment
• Power and Cooling
• Networking setup and security
• Virtualization, Operating System (Installation, Patching, System Upgrades)
• Middleware Components
• Configuration of Web Services such as Apache, IIS or Nginx

App Service Plans

As with all Azure Services, there are different pricing tiers that define the compute resources that are allocated to your App Service. There are 4 different tiers to choose from:

• Shared compute: Both Free and Shared share the resource pools of your apps with the apps of other customers. These tiers allocate CPU quotas to each app that runs on the shared resources, and the resources can’t scale out.
• Dedicated compute: The Basic, Standard, Premium, PremiumV2, and PremiumV3 tiers run apps on dedicated Azure VMs. Only apps in the same App Service plan share the same compute resources. The higher the tier, the more VM instances are available to you for scale-out.
• Isolated: This tier runs dedicated Azure VMs on dedicated Azure Virtual Networks. It provides network isolation on top of compute isolation, and maximum scale-out capabilities. You should run in Isolated if your app is resource intensive or needs to scale independently of other apps.
• Consumption: This tier is only available to Azure Function apps. It scales the functions dynamically depending on workload.

Deployment Options for App Service

You have multiple options for deployment of your App Service. Automated deployment options are:

• Azure DevOps
• GitHub
• Bitbucket

All of these options allow you to build your code, test and generate releases, and push the code changes to Azure. You also can maintain version control with these options.

Manual deployment options are:

• Git – Web Apps have a Git URL that you can use a remote repository to deploy your Web App.
• Azure CLI – you can package Web Apps and deploy them using CLI.
• ZIP Deploy – Use curl or similar http to send a zip of your deployment files to App Service.
• FTP/S – you can push your code directly to App Service over FTP or FTPS.

Authentication

Azure App Service allows you to integrate directly with multiple providers such as Azure AD, Facebook, Google or Twitter. This feature is built directly into the platform and doesn’t require any coding, language or security expertise to implement.

Conclusion

So thats an overview of the foundations of Azure App Service. In the next post, we’ll go through a demo of deploying a Web App using both manual and automated methods, and look at more advanced options like configuring diagnostic settings, auto-scaling and deployment slots.

Hope you enjoyed this intro to Azure App Service, until next time!