4.1 Introduction to Azure App Services

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *

Already have an account? Sign In »

19 hours 58 minutes
Video Transcription
Welcome back. Here we are in the first episode of Our Module four, with an introduction to Azure APP. Service is
the objectives include understanding what APP service plans are taking a look at Web APS and then some Web jobs.
So first, what our azure app service is as Europe Service's allow for building and hosting Web APS inside of Azure,
you can choose multiple programming languages as well as Windows or Lennox. The host your Web. EPPS, without worrying about provisioning or managing the underlying infrastructure
as your APP service, is designed to take advantage of many of actors. Other capabilities. Such a security load balancing auto scaling an automated management.
You can incorporate DEV ops like capabilities by performing continues deployment using tools like Azure Dev Ops get Hub and Dr Hub
much like the service compute options we covered back in a previous module you only pay for the compute resource is use inside of the service.
When you create an APP service plan you're creating, the compute resource is in the azure region. Selected during the setup in the apse that you deploy into the APP service plan will run on those compute resource is in the region.
And like I mentioned on the previous slide, you don't have to worry about maintaining those. Computer resource is inside the Azure at plan.
And as with all things in the cloud, there are different tiers in versions of the APP service plans all the way from free tow, isolated. Let's jump out to Azure is documentation and review these plans.
Here we are out in the documentation for the APP service plans and taking a look. Some of the pricing
Let's scroll down a little bit. Here we have our six tears that we're gonna be concerned with from free, shared, basic, standard, premium and isolated.
I just want to highlight some of the differences we have in between some of these
in the free and share plans. We are limited by the number of APS we can have, but from basic standard premium isolated, we have unlimited number of APS
and also the free and shared do not have an S l. A. And we're only able provisioned. One instance.
Another feature to consider is the deployment slots, which will cover in a later episode. Thes air only covered in the standard premium and isolated APP service plans.
Another thing to look at is auto scaling, which is only available inside a standard primi in isolated.
This is the ability to auto scale the number of instances we have in response to our resource usage.
Another thing to look at is are always on and custom domains in which tears they're available in. That's just a handful of the things that I wanted to point out. Definitely. Take a look at this chart on your own and just try to point out some major differences between some of the tears that you might think would be important for the exam.
Back to our slides. We also have something called a nap service environment, which is a feature of the azure APP service is. It provides a full, isolated and dedicated environment for running your applications. The APP service environment is meant for APS that might require high scalability isolation, secure network access and high memory utilization,
and the's also support Windows and Lennox Web, APS, doctor containers, mobile laps and functions.
AB service environments are meant to run and support a single application and articulate into a virtual network in your tenant.
This allows granular control over inbound and outbound network traffic as well as connecting to on premises. Resource is over a site to site VPN, or express route connection.
It's now we've talked about where Web perhaps are going to live. Let's talk about actually creating a Web at
when creating a Web app. You have a couple of decisions to make. First, we need to choose a globally unique Ural for the Web app name, and we'll have a domain suffix of azure websites dot net.
Next, we need to choose our runtime stack or our language. Our Web app is going to be built on
here. We have a couple of screenshots of a few choices that are available such as dot net, Java or python, but there's many more. We also get to choose the operating system that our Web app is going to run on. Choosing the operating system can affect how much logging is available, as well as other Web options will see later. And finally
we're gonna associate the Web app to an APP service plan
that we've created previously. Placing the Web app inside. The APP service plan will determine where the compute resource is the Web app rooms on
inside of our Web app. We do have a couple of configuration options. The first is application settings where we can define environmental variables and access the's in the application during runtime. We also have connection strings, which is similar to what dot Net developers might configure in a web dot convict file, like setting database connections or application credentials.
We also have general settings where we can configure the programming stack like version requirements as well as a platform settings
like keeping the app always on or setting cookie affinity and enabling secure FTP connections. We also have default documents where you can configure the default document. Our web page That is the root your l for the website, you know, something like index dot html, you know, so configure more than one, and the first matching file is going to be used.
Finally, we have path wrappings. This is for windows apse, where you can customize the II s handler, wrappings and virtual applications and directories, much like you'd find in a Windows server. I s deployment
was will have the ability to set custom domains. You can purchase domains directly through azure or bring your own and you'll want to make sure and check the APP service plans supports the configuration of custom domains, something we saw earlier when we were looking out at the Azure Documentation website.
We can also enable logging for our Web. EPPS. We have different options depending on the underlying operating system we choose for Windows. We have an option of enabling application logging to the file system, but this is temporary and turns off after 12 hours.
When choosing the second option for blood, we have to have a blob storage container available for writing locks, too, and this is more of a long term solution.
This is also on Lee, supported by dot NET applications. We also have the option of enabling Web server logging, detail their messages and failed to request tracings
for Web APS running on Lennox. We have fear options, and basically it's logging to the file system. We can set the dis space quota for the logs as well as the retention period. When logging to the file system is enabled, we can access a special year l to download a zip file of logs
Finally inside of our APP. Service is we have Web jobs, Web jobs allow for running a programmed or script like it is a Web app. Web jobs are only currently supported for AP Service is configured on Windows and not Lennox.
We have two different types of Web jobs. The first is continuous, or it starts immediately, and it's typically written in an endless loop inside the application.
The second is a triggered Webb job, where it only starts when it is mainly ran or on a schedule. And Web jobs currently support a good amount of file types, like batch files, executed Bols Power Shell scripts and Python scripts.
When creating a scheduled Webb job, it uses NC Tron tab expressions, which are similar to crown expressions. Thes expressions have an additional field at the beginning to mark the time in seconds. Here on the slide, we have the format of what this expression looks like. We have seconds, minutes, hours, days, month and day of the week
and down below have a couple examples here that 1st 1 is showing a schedule that will run every five minutes.
The second is showing one that will run every hour from 9 a.m. to 5 p.m. So you see the 9-17 representing the hour in the expression, and the last example we have here is one that will run at 9:30 a.m. every weekday, which is indicated by the one through five.
You can also use English terms for the month and day, such as January, February or Monday Tuesday Wednesday to configure the schedule
for the purposes of the exam. Just kind of understand what these look like and probably memorized how the expressions are laid out
that does it for some of the basics of our APP service's plans and configuring and creating Web APS inside of them.
Let's follow this up with the quick quiz question. Which tears of the APP service's plan support auto Scaling
Our tears includes standard premium and isolated. So basically meaning the free and basic tears do not support auto scaling. You can go back out to the azure documentation to see that
coming up. Next, we're gonna jump back out to the Azure portal, and we're gonna build an APP service plan and then create a Web job inside of it. See you in the next episode
Up Next