add screenshots, fix links

Author: cebundy

articles/container-apps/TOC.yml

@@ -101,7 +101,7 @@
     - name: Ingress
       items:
       - name: Configure ingress
-        href: ingress.md
+        href: ingress-how-to.md
       - name: Configure IP restrictions
         href: ip-restrictions.md
       - name: Add client certificates
@@ -110,6 +110,7 @@
         href: traffic-splitting.md
       - name: Session affinity
         href: sticky-sessions.md
+        displayName: Sticky sessions
     - name: Custom domains and certificates
       items:
       - name: Set up container app custom domain

articles/container-apps/client-certificate-authorization.md

@@ -30,7 +30,7 @@ Anthony mentioned that the customer will be able to obtain a client certificate
 
 ## Configure client certificate authorization
 
-The client certificate mode property available as you enable [ingress](./ingress.md) on your container app.  The property can be set to one of the following values:
+The client certificate mode property available as you enable [ingress](./ingress-how-to.md) on your container app.  The property can be set to one of the following values:
 
 - `require`: The client certificate is required for all requests to the container app.
 - `accept`: The client certificate is optional. If the client certificate isn't provided, the request is still accepted.
@@ -83,4 +83,4 @@ To configure client certificate authorization in the Azure portal, follow these
 ## Next Steps
 
 > [!div class="nextstepaction"]
-> [Configure ingress](ingress.md)
+> [Configure ingress](ingress-how-to.md)

articles/container-apps/communicate-between-microservices.md

@@ -12,7 +12,7 @@ zone_pivot_groups: container-apps-image-build-type
 
 # Tutorial: Communication between microservices in Azure Container Apps
 
-Azure Container Apps exposes each container app through a domain name if [ingress](ingress.md) is enabled. Ingress endpoints for container apps within an external environment can be either publicly accessible or only available to other container apps in the same [environment](environment.md).
+Azure Container Apps exposes each container app through a domain name if [ingress](ingress-how-to.md) is enabled. Ingress endpoints for container apps within an external environment can be either publicly accessible or only available to other container apps in the same [environment](environment.md).
 
 Once you know the fully qualified domain name for a given container app, you can make direct calls to the service from other container apps within the shared environment.
 

articles/container-apps/connect-apps.md

@@ -12,12 +12,17 @@ ms.custom: ignite-fall-2021, event-tier1-build-2022
 
 # Connect applications in Azure Container Apps
 
-Azure Container Apps exposes each container app through a domain name if [ingress](ingress.md) is enabled. Ingress endpoints can be exposed either publicly to the world or internally and only available to other container apps in the same [environment](environment.md).
+Azure Container Apps exposes each container app through a domain name if [ingress](ingress-concept.md) is enabled. Ingress endpoints can be exposed either publicly to the world and to other container apps in the same environment, or ingress can be limited to only other container apps in the same [environment](environment.md).
 
-Once you know a container app's domain name, then you can call the location within your application code to connect multiple container apps together.
+You can call other container apps in the same environment from your application code using one of the following methods: 
+
+- default fully qualified domain name (FQDN)
+- a custom domain name
+- the container app name
+- a Dapr URL
 
 > [!NOTE]
-> When you call another container in the same environment using the FQDN, the network traffic never leaves the environment.
+> When you call another container in the same environment using the FQDN or app name, the network traffic never leaves the environment.
 
 A sample solution showing how you can call between containers using both the FQDN Location or Dapr can be found on [Azure Samples](https://github.com/Azure-Samples/container-apps-connect-multiple-apps)
 
@@ -37,7 +42,7 @@ The following diagram shows how these values are used to compose a container app
 
 ## Dapr location
 
-Developing microservices often requires you to implement patterns common to distributed architecture. Dapr allows you to secure microservices with mutual TLS, trigger retries when errors occur, and take advantage of distributed tracing when Azure Application Insights is enabled.
+Developing microservices often requires you to implement patterns common to distributed architecture. Dapr allows you to secure microservices with mutual TLS (client certificates), trigger retries when errors occur, and take advantage of distributed tracing when Azure Application Insights is enabled.
 
 A microservice that uses Dapr is available through the following URL pattern:
 

articles/container-apps/index.yml

@@ -53,8 +53,8 @@ landingContent:
             url: manage-secrets.md
           - text: Manage revisions
             url: revisions-manage.md
-          - text: Set up HTTP ingress
-            url: ingress.md
+          - text: Set up ingress
+            url: ingress-how-to.md
           - text: Connect multiple apps
             url: connect-apps.md
           - text: Use a custom VNET 

articles/container-apps/ingress-overview.md

@@ -11,11 +11,11 @@ ms.author: cshoe
 
 # Ingress in Azure Container Apps
 
-Azure Container Apps allows you to expose your container app to the public web, your virtual network (VNET), and other container apps within your environment by enabling ingress. Ingress settings are enforced through a set of rules that control the routing of external and internal traffic to your container app.  When you enable ingress, you don't need to create an Azure Load Balancer, public IP address, or any other Azure resources to enable incoming HTTPS requests or TCP traffic.
+Azure Container Apps allows you to expose your container app to the public web, your virtual network (VNET), and other container apps within your environment by enabling ingress. Ingress settings are enforced through a set of rules that control the routing of external and internal traffic to your container app.  When you enable ingress, you don't need to create an Azure Load Balancer, public IP address, or any other Azure resources to enable incoming HTTP requests or TCP traffic.
 
 Ingress supports:
 
-- [Public and private ingress](#public-and-private-ingress)
+- [External and internal ingress](#external-and-internal-ingress)
 - [HTTP and TCP ingress types](#protocol-types)
 - [Domain names](#domain-names)
 - [IP restrictions](#ip-restrictions)
@@ -26,16 +26,14 @@ Ingress supports:
 > [!NOTE]
 > Add diagram here,  Talked with Anthony about this.  He thought that we should consult Ahmed.  I think that we should have a diagram that shows the ingress options and how they work together.
 
-For configuration details, see [Configure ingress](ingress.md).
+For configuration details, see [Configure ingress](ingress-how-to.md).
 
-## Public and private ingress
+## External and internal ingress
 
 When you enable ingress, you can choose between two types of ingress:
 
-- Public: Allows external access from the public internet and from apps within the same environment.
-- Private: Allows only internal access from with your container app's environment.
-
-Ingress external to your environment uses a [fully qualified domain name](#domain-names) (FQDN) to route traffic to your container app.  In addition to the FQDN, container apps can access another app in the same environment by using its name.  The name of the container app is defined in `name` property in the container app's resource.  
+- External: Accepts traffic from both the public internet and your container app's internal environment.
+- Internal: Allows only internal access from within your container app's environment.
 
 Each container app within an environment can be configured with different ingress settings. For example, in a scenario with multiple microservice apps, to increase security you may have a single container app that receives public requests and passes the requests to a background service.  In this scenario, you would configure the public-facing container app with external ingress and the internal-facing container app with internal ingress.
 
@@ -80,11 +78,11 @@ With TCP ingress enabled, your container app:
 
 ## Domain names
 
-Each app in a Container Apps environment is automatically assigned a fully qualified domain name (FQDN) based on the environment's DNS suffix. To customize an environment's DNS suffix, see [Custom environment DNS Suffix](environment-custom-dns-suffix.md).
-
-You can configure a custom DNS domain for your Container Apps environment.  For more information, see [Custom domain names and certificates](./custom-domains-certificates.md).
+You can access your app in the following ways:
 
-VNET-scope ingress requires more DNS configuration. For more information, see [DNS configuration for VNET-scope ingress](./networking.md#dns).
+- The default fully qualified domain name (FQDN).  Each app in a Container Apps environment is automatically assigned an FQDN based on the environment's DNS suffix. To customize an environment's DNS suffix, see [Custom environment DNS Suffix](environment-custom-dns-suffix.md).
+- A custom domain name:  You can configure a custom DNS domain for your Container Apps environment.  For more information, see [Custom domain names and certificates](./custom-domains-certificates.md).
+- The app name: You can use the app name for communication between apps in the same environment.
 
 ## IP restrictions
 
@@ -105,9 +103,9 @@ Containers Apps allows you to split incoming traffic between active revisions.
 
 ## Session affinity
 
-Session affinity, also known as sticky sessions, is a feature that allows you to route all HTTP requests from a client to the same replica. This feature is useful for stateful applications that require a consistent connection to the same replica.  For more information, see [Session affinity](session-affinity.md).
+Session affinity, also known as sticky sessions, is a feature that allows you to route all HTTP requests from a client to the same replica. This feature is useful for stateful applications that require a consistent connection to the same replica.  For more information, see [Session affinity](sticky-sessions.md).
 
 ## Next steps
 
 > [!div class="nextstepaction"]
-> [Configure ingress](ingress.md)
+> [Configure ingress](ingress-how-to.md)

articles/container-apps/media/ingress/screenshot-create-deploy-new-revision.png

@@ -26,7 +26,7 @@ As you create a custom VNET, keep in mind the following situations:
 
 - If you want your container app to restrict all outside access, create an [internal Container Apps environment](vnet-custom-internal.md).
 
-- When you provide your own VNET, you need to provide a subnet that is dedicated to the Container App Environment you'll deploy. This subnet can't be used by other services.
+- When you provide your own VNET, you need to provide a subnet that is dedicated to the Container App environment you deploy. This subnet can't be used by other services.
 
 - Network addresses are assigned from a subnet range you define as the environment is created.
 
@@ -50,7 +50,7 @@ https://techcommunity.microsoft.com/t5/apps-on-azure-blog/azure-container-apps-v
 
 ## HTTP edge proxy behavior
 
-Azure Container Apps uses [Envoy proxy](https://www.envoyproxy.io/) as an edge HTTP proxy. TLS is terminated on the edge and requests are routed based on their traffic split rules and routes traffic to the correct application.
+Azure Container Apps uses [Envoy proxy](https://www.envoyproxy.io/) as an edge HTTP proxy. TLS is terminated on the edge and requests are routed based on their traffic splitting rules and routes traffic to the correct application.
 
 HTTP applications scale based on the number of HTTP requests and connections. Envoy routes internal traffic inside clusters. Downstream connections support HTTP1.1 and HTTP2 and Envoy automatically detects and upgrades the connection should the client connection be upgraded. Upstream connection is defined by setting the `transport` property on the [ingress](azure-resource-manager-api-spec.md#propertiesconfiguration) object.
 
@@ -60,7 +60,9 @@ Under the [ingress](azure-resource-manager-api-spec.md#propertiesconfiguration)
 
 - **Accessibility level**: You can set your container app as externally or internally accessible in the environment. An environment variable `CONTAINER_APP_ENV_DNS_SUFFIX` is used to automatically resolve the FQDN suffix for your environment.
 
-- **Traffic split rules**: You can define traffic split rules between different revisions of your application.
+- **Traffic split rules**: You can define traffic splitting rules between different revisions of your application.  For more information, see [Traffic splitting](traffic-splitting.md).
+
+For more information about ingress configuration, see [Ingress in Azure Container Apps](ingress-overview.md).
 
 ### Scenarios
 
@@ -70,7 +72,7 @@ For more information about scenarios, see [Ingress in Azure Container Apps](ingr
 
 For every app in Azure Container Apps, there are two URLs.
 
-The first URL is generated by Container Apps and is used to access your app. See the *Application Url* in the *Overview* window of your container app in the Azure portal for the fully qualified domain name (FQDN) of your container app.
+Container Apps generates the first URL, which is used to access your app. See the *Application Url* in the *Overview* window of your container app in the Azure portal for the fully qualified domain name (FQDN) of your container app.
 
 The second URL grants access to the log streaming service and the console. If necessary, you may need to add `https://azurecontainerapps.dev/` to the allowlist of your firewall or proxy.
 
@@ -119,7 +121,7 @@ There's no forced tunneling in Container Apps routes.
 
 ## DNS
 
--	**Custom DNS**: If your VNET uses a custom DNS server instead of the default Azure-provided DNS server, configure your DNS server to forward unresolved DNS queries to `168.63.129.16`. [Azure recursive resolvers](../virtual-network/virtual-networks-name-resolution-for-vms-and-role-instances.md#name-resolution-that-uses-your-own-dns-server) uses this IP address to resolve requests. If you don't use the Azure recursive resolvers, the Container Apps environment won't function.
+-	**Custom DNS**: If your VNET uses a custom DNS server instead of the default Azure-provided DNS server, configure your DNS server to forward unresolved DNS queries to `168.63.129.16`. [Azure recursive resolvers](../virtual-network/virtual-networks-name-resolution-for-vms-and-role-instances.md#name-resolution-that-uses-your-own-dns-server) uses this IP address to resolve requests. If you don't use the Azure recursive resolvers, the Container Apps environment can't function.
 
 -	**VNET-scope ingress**: If you plan to use VNET-scope [ingress](ingress-overview.md) in an internal Container Apps environment, configure your domains in one of the following ways: