Introduction Deployment Deployment Slots Configuration Diagnostics Logs Web jobs Scaling Traffic Manager Challenges

1. AZURE WEBAPP

2. TRAINING CONTENT
Introduction
Deployment
Deployment Slots
Configuration
Diagnostics Logs
Web jobs
Scaling
Traffic Manager
Challenges

3. INTRODUCTION

4. WEB APP
• It is Platform as a service (PAAS) offered by azure. It is part of
appservice.
• It provides ability to developers to have an optimized full life cycle
experience from app design to app maintenance. It provides
following feature:
 Continuous deployment.
 Test in production.
 Running asynchronous tasks.
 Scaling the app.
 Maintaining the app.

5. DEPLOYMENT
There are various ways of deployment of web application using cloud
app service:
 By using publish mechanism from .net application.
 Using GIT command
 Using FTP
 Using Power shell script.

6. DEPLOYMENT USING .NET
PLATFORM
We can deploy website using .net application with following steps:
 Create web-app using portal.azure.com.
 Get publish profile page from management portal.
 Open application in .net.
 Right click on web application and use publish option.
 Import publish profile using import option.
 Click publish. It will deploy website on azure.

7. DEPLOYMENT USING GIT
We can deploy website using GIT with following steps:
 Create web-app using portal.azure.com.
 Configure Deployment option:
 Select choose source as GITHUB.
 Configure Authorization for GIT.
 Select Project and branch for GIT Repository.
 Push code from GIT console to configured Repository and branch

8. DEPLOYMENT USING GIT

9. DEPLOYMENT USING GIT

10. DEPLOYMENT SLOTS
Deployment slots provides more robust deployment workflows than deploying
websites directly to production. We can deploy websites on multiple endpoints to
perform different operations. For ex. We can deploy website on staging platform
before deploying it on production. It is useful in following scenarios:
 Staged deployment: In staged deployment we can deploy to non-production
slot that is acting as staging environment. In this environment we can test
whether website is working or not. If everything is working we can swap the
production slot with staging slot.
Incremental Deployment: If websites needs post deployment incremental
steps. We can deploy to non-production slot, make those changes and then
swap with production slot.
Rolling Back Deployment: If after swapping a non-production slot into
production, you need to rollback the deployment, you can swap the production
slot again with the slot contains the previous production deployment.

11. DEPLOYMENT SLOTS
Important points:
 All deployment slots for a given site share the same virtual machine instance that is hosting the
production slot.
Since the same VM is used for all slots ,We can’t scale a non-production slot independently of
the production slot. We can only adjust the scale settings of the production slot.
With each deployment slot we can create up to four additional deployment slots that we can
swap with production slot.
When we swap, the site content and certain slot configurations are exchanged with no
downtime.
When we swap deployment slots, some of the configuration settings got moved to destination
slot. E.g. General settings, Connection string, Handler Mappings, Application and sit diagnostic
settings, Monitoring settings.
Some of the configuration items not get moved to destination slot. E.g. Publishing endpoints,
SSL settings, Domain names, Scale settings.

12. DIAGNOSTICS AND MONITORING
Types of logs
 Event Log : It is similar as windows event log. It is useful to track exceptions which
are missed by application.
Web server Logs: It is a textual having information about all HTTP request.
Detailed Error Message Logs: HTML files generated by the webserver for failed
requests.
Application Diagnostic logs: These text based trace logs are created by web
application code in a manner specific to the platform the application is built in.
For asp.net application, these are crated by invoking the logging methods in
system.diagnostic.trace class.

13. DIAGNOSTICS AND MONITORING
Location of logs:
Event Log : Logfileseventlog.xml
Web Server Logs: Logfileshttpraw*.log
Detailed Error message Logs : LogfilesDetailedErrorsErrorpage.htm
Application Diagnostic Logs: LogfilesApplication*.txt

14. DIAGNOSTICS AND MONITORING
The various ways to view logs in Azure:
Retrieve diagnostic data using visual studio
Retrieve diagnostic data using site control manager
Retrieve diagnostic data using FTP
Retrieve diagnostic data using Powershell script.

15. REMOTE DEBUGGING
We can deploy website using GIT with following steps:
 Create web-app using portal.azure.com.

16. WEBJOBS
Web job enables to run .net console application within the context of
azure websites. It enables to perform background processing. It can
be scheduled to run on demand, continuously, or on a predefined
schedule with recurrence.
Additionally operations defined within webjobs can be triggered to run
either when webjob runs or when new file is created in blob storage
or message sent to Azure queue.

17. SCALING
Scaling is the process of allocating resources to match the
performance requirements. It is used to match capacity as per
demand.
There are various ways of scaling. Some of them are as follows:
 By adjusting the number of VM instances serving requests.
 By adjusting the instance size.
 By deploying websites to multiple regions.

18. SCALING
Adjusting number of instances:
We can scale out (increase) the number of instances to support load in
business hours and scale in (decrease) the number of instances during
less busy hours to save cost. We can do scale in or scale out
automatically or manually. There are two ways for auto scaling websites:
 Autoscaling by scheduling.
Autoscaling by metric.

19. SCALING
Autoscaling by scheduling:
 Autoscaling can be enabled by using scale out or scale in options provided in appservice.
 We have to create rule in which we can define condition for scaling and we can schedule it for dialy,
monthy or weekly.

20. SCALING

21. SCALING
Autoscaling based on metric:
We can automatically adjust the number of instances provided to your
web hosting plan based on one or more configured rules, where each rule
has a condition, metric and an action to take in response to threshold
being exceeded. Some of the performance metric are as follows:
 Cpu percentage : Percent of cpu utilization.
 Memory percentage : Percent of memory utilization.
 Disk Queue length: Count of pending disk operations.
 Http Queue length : Count of pending HTTP operations.
 Data in : Amount of traffic ingress in kilobytes.
 Data out : Amount of traffic egress in kilobytes.

22. SCALING
Create rule for autoscaling based on metric:
Rule can be configured by defining various parameters. One of the example for rule is as
follows:
 Metric : cpu percentage
 Threshold : Greater than 80 percent
 Over past : 20 minutes
 Scale Up By: 1 instance
 Cool down : 20 minutes.
After implementing this rule the instance will be increased when cpu utilization in greater than
80 percent. However, the cpu utilization remains at 80 percent for next five minutes even with
the additional instance helping to reduce cpu load. Autoscale will not trigger again for another
15 minutes because it is within cool down period

23. SCALING

24. SCALING USING TRAFFIC
MANAGER
 Traffic manager provides ability to control the distribution of user traffic for service
endpoints in different datacenters.
 Traffic manager can also be used with external and non-azure endpoints.
 Traffic manager use the domain name system (DNS) to direct client requests to most
appropriate endpoint based on traffic routing method and health of endpoints.
 To implement traffic manager CNAME is used to point domain name to traffic manager
domain name.
 When a client, such as browser, first tries to browse to www.testurl.com, it does domain
lookup and ultimately leads to traffic manager. Traffic manager evaluates endpoint based
on rules and route request to appropriate endpoint.
 For a period of time the ip address which is resolved by traffic manager is cached. So that
there is no need of evaluation of endpoint by traffic manager for subsequent request. This
period of time is known as TTL (Time to live)

25. SCALING USING TRAFFIC
MANAGER
Traffic manager Load balancing methods:
 Failover: When a DNS query comes from a client, Traffic manager picks the first endpoint
from the ordered list of endpoints that is determines is healthy based on periodic
monitoring of the endpoints.
 Round Robin : Traffic manager treats each active endpoint in the list of endpoints equally
and tries to evenly distribute traffic among the endpoints in round-robin manner.
 Performance : Traffic manager picks the closet endpoint from the configured list of
endpoints that should have the lowest latency for the client.

26. SCALING USING TRAFFIC
MANAGER

27. SCALING USING TRAFFIC
MANAGER

28. THANK YOU