Azure appservice
Download as PPTX, PDF0 likes317 views
This document serves as a comprehensive guide on Azure Web Apps, a platform-as-a-service (PaaS) that streamlines app development and maintenance. It details various deployment methods, including .NET applications and Git, as well as the use of deployment slots for robust workflows. Additionally, it covers diagnostics, logging, scaling strategies, and the functionality of Azure Traffic Manager for traffic management across different endpoints.
Azure appservice
- 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
- 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.
- 28. THANK YOU