You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/app-service/environment/using-an-ase.md
+35-7Lines changed: 35 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,18 +5,18 @@ author: ccompy
5
5
6
6
ms.assetid: a22450c4-9b8b-41d4-9568-c4646f4cf66b
7
7
ms.topic: article
8
-
ms.date: 01/01/2020
8
+
ms.date: 3/26/2020
9
9
ms.author: ccompy
10
10
ms.custom: seodec18
11
11
---
12
12
# Use an App Service Environment
13
13
14
14
An App Service Environment (ASE) is a deployment of Azure App Service into a subnet in a customer's Azure Virtual Network instance. An ASE consists of:
15
15
16
-
-**Front ends**: Where HTTP or HTTPS terminates in an App Service Environment.
17
-
-**Workers**: The resources that host your apps.
18
-
-**Database**: Holds information that defines the environment.
19
-
-**Storage**: Used to host the customer-published apps.
16
+
-**Front ends**: Where HTTP or HTTPS terminates in an App Service Environment
17
+
-**Workers**: The resources that host your apps
18
+
-**Database**: Holds information that defines the environment
19
+
-**Storage**: Used to host the customer-published apps
20
20
21
21
You can deploy an ASE with an external or internal virtual IP (VIP) for app access. A deployment with an external VIP is commonly called an *External ASE*. A deployment with an internal VIP is called an *ILB ASE* because it uses an internal load balancer (ILB). To learn more about the ILB ASE, see [Create and use an ILB ASE][MakeILBASE].
22
22
@@ -115,6 +115,22 @@ For information about how to create an ILB ASE, see [Create and use an ILB ASE][
115
115
116
116
The SCM URL is used to access the Kudu console or for publishing your app by using Web Deploy. For information on the Kudu console, see [Kudu console for Azure App Service][Kudu]. The Kudu console gives you a web UI for debugging, uploading files, editing files, and much more.
117
117
118
+
### DNS configuration
119
+
120
+
When you use an External ASE, apps made in your ASE are registered with Azure DNS. With an ILB ASE, you must manage your own DNS.
121
+
122
+
To configure DNS with your ILB ASE:
123
+
124
+
create a zone for <ASE name>.appserviceenvironment.net
125
+
create an A record in that zone that points * to the ILB IP address
126
+
create an A record in that zone that points @ to the ILB IP address
127
+
create a zone in <ASE name>.appserviceenvironment.net named scm
128
+
create an A record in the scm zone that points * to the ILB IP address
129
+
130
+
The DNS settings for your ASE default domain suffix do not restrict your apps to only being accessible by those names. You can set a custom domain name without any validation on your apps in an ILB ASE. If you then want to create a zone named *contoso.net*, you could do so and point it to the ILB IP address. The custom domain name works for app requests but doesn't for the scm site. The scm site is only available at *<appname>.scm.<asename>.appserviceenvironment.net*.
131
+
132
+
The zone named *.<asename>.appserviceenvironment.net* is globally unique. Before May 2019, customers were able to specify the domain suffix of the ILB ASE. If you wanted to use *.contoso.com* for the domain suffix, you were able do so and that would include the scm site. There were challenges with that model including; managing the default SSL certificate, lack of single sign-on with the scm site, and the requirement to use a wildcard certificate. The ILB ASE default certificate upgrade process was also disruptive and caused application restarts. To solve these problems, the ILB ASE behavior was changed to use a domain suffix based on the name of the ASE and with a Microsoft owned suffix. The change to the ILB ASE behavior only affects ILB ASEs made after May 2019. Pre-existing ILB ASEs must still manage the default certificate of the ASE and their DNS configuration.
133
+
118
134
## Publishing
119
135
120
136
In an ASE, as with the multitenant App Service, you can publish by these methods:
@@ -127,7 +143,7 @@ In an ASE, as with the multitenant App Service, you can publish by these methods
127
143
128
144
With an External ASE, these publishing options all work the same way. For more information, see [Deployment in Azure App Service][AppDeploy].
129
145
130
-
Publishing is significantly different with an ILB ASE, for which the publishing endpoints are all available only through the ILB. The ILB is on a private IP in the ASE subnet in the virtual network. If you don't have network access to the ILB, you can't publish any apps on that ASE. As noted in [Create and use an ILB ASE][MakeILBASE], you must configure DNS for the apps in the system. That requirement includes the SCM endpoint. If the endpoints aren't defined properly, you can't publish. Your IDEs must also have network access to the ILB to publish directly to it.
146
+
With an ILB ASE, the publishing endpoints are only available through the ILB. The ILB is on a private IP in the ASE subnet in the virtual network. If you don't have network access to the ILB, you can't publish any apps on that ASE. As noted in [Create and use an ILB ASE][MakeILBASE], you must configure DNS for the apps in the system. That requirement includes the SCM endpoint. If the endpoints aren't defined properly, you can't publish. Your IDEs must also have network access to the ILB to publish directly to it.
131
147
132
148
Without additional changes, internet-based CI systems like GitHub and Azure DevOps don't work with an ILB ASE because the publishing endpoint isn't internet accessible. You can enable publishing to an ILB ASE from Azure DevOps by installing a self-hosted release agent in the virtual network that contains the ILB ASE. Alternatively, you can also use a CI system that uses a pull model, such as Dropbox.
133
149
@@ -164,7 +180,18 @@ To enable logging on your ASE:
164
180
165
181
![ASE diagnostic log settings][4]
166
182
167
-
If you integrate with Log Analytics, you can see the logs by selecting **Logs** from the ASE portal and creating a query against **AppServiceEnvironmentPlatformLogs**.
183
+
If you integrate with Log Analytics, you can see the logs by selecting **Logs** from the ASE portal and creating a query against **AppServiceEnvironmentPlatformLogs**. Logs are only emitted when your ASE has an event that will trigger it. If your ASE does not have such an event, there will not be any logs. To quickly see an example of logs in your Log Analytics workspace, perform a scale operation with one of the App Service plans in your ASE. You can then run a query against **AppServiceEnvironmentPlatformLogs** to see those logs.
184
+
185
+
**Creating an alert**
186
+
187
+
To create an alert against your logs, follow the instructions in [Create, view, and manage log alerts using Azure Monitor][logalerts]. In brief:
188
+
189
+
* Open the Alerts page in your ASE portal
190
+
* Select **New alert rule**
191
+
* Select your Resource to be your Log Analytics workspace
192
+
* Set your condition with a custom log search to use a query like, "AppServiceEnvironmentPlatformLogs | where ResultDescription contains "has begun scaling" or whatever you want. Set the threshold as appropriate.
193
+
* Add or create an action group as desired. The action group is where you define the response to the alert such as sending an email or an SMS message
0 commit comments