Merge pull request #264253 from KarlErickson/karler-fixes

miscellaneous fixes

Author: ttorble

articles/spring-apps/concept-understand-app-and-deployment.md

@@ -20,7 +20,7 @@ ms.custom: devx-track-java, devx-track-extended-java, event-tier1-build-2022
 
 *App* and *Deployment* are the two key concepts in the resource model of Azure Spring Apps. In Azure Spring Apps, an *App* is an abstraction of one business app. One version of code or binary deployed as the *App* runs in a *Deployment*. Apps run in an *Azure Spring Apps service instance*, or simply *service instance*, as shown next.
 
-:::image type="content" source="./media/spring-cloud-app-and-deployment/app-deployment-rev.png" alt-text="Diagram showing the relationship between the apps and deployments." border="false":::
+:::image type="content" source="media/concept-understand-app-and-deployment/app-deployment-rev.png" alt-text="Diagram showing the relationship between the apps and deployments." border="false":::
 
 You can have multiple service instances within a single Azure subscription, but the Azure Spring Apps Service is easiest to use when all of the Apps that make up a business app reside within a single service instance. One reason is that the Apps are likely to communicate with each other. They can easily do that by using Eureka service registry in the service instance.
 

articles/spring-apps/concepts-blue-green-deployment-strategies.md

@@ -30,27 +30,27 @@ Suppose your application has two deployments: `deployment1` and `deployment2`. C
 
 This makes `deployment2` the staging deployment. Thus, when the Continuous Delivery (CD) pipeline is ready to run, it deploys the next version of the app, version `v4`, onto the staging deployment `deployment2`.
 
-![Two deployments: deployment1 receives production traffic](media/spring-cloud-blue-green-patterns/alternating-deployments-1.png)
+![Two deployments: deployment1 receives production traffic](media/concepts-blue-green-deployment-strategies/alternating-deployments-1.png)
 
 After `v4` has started up on `deployment2`, you can run automated and manual tests against it through a private test endpoint to ensure `v4` meets all expectations.
 
-![V4 is now deployed on deployment2 and undergoes testing](media/spring-cloud-blue-green-patterns/alternating-deployments-2.png)
+![V4 is now deployed on deployment2 and undergoes testing](media/concepts-blue-green-deployment-strategies/alternating-deployments-2.png)
 
 When you have confidence in `v4`, you can set `deployment2` as the production deployment so that it receives all production traffic. `v3` will remain running on `deployment1` in case you discover a critical issue that requires rolling back.
 
-![V4 on deployment2 now receives production traffic](media/spring-cloud-blue-green-patterns/alternating-deployments-3.png)
+![V4 on deployment2 now receives production traffic](media/concepts-blue-green-deployment-strategies/alternating-deployments-3.png)
 
 Now, `deployment1` is the staging deployment. So the next run of the deployment pipeline deploys onto `deployment1`.
 
-![V5 deployed on deployment1](media/spring-cloud-blue-green-patterns/alternating-deployments-4.png)
+![V5 deployed on deployment1](media/concepts-blue-green-deployment-strategies/alternating-deployments-4.png)
 
 You can now test `V5` on `deployment1`'s private test endpoint.
 
-![V5 tested on deployment1](media/spring-cloud-blue-green-patterns/alternating-deployments-5.png)
+![V5 tested on deployment1](media/concepts-blue-green-deployment-strategies/alternating-deployments-5.png)
 
 Finally, after `v5` meets all your expectations, you set `deployment1` as the production deployment once again, so that `v5` receives all production traffic.
 
-![V5 receives traffic on deployment1](media/spring-cloud-blue-green-patterns/alternating-deployments-6.png)
+![V5 receives traffic on deployment1](media/concepts-blue-green-deployment-strategies/alternating-deployments-6.png)
 
 ### Tradeoffs of the alternating deployments approach
 
@@ -64,7 +64,7 @@ The staging deployment always remains running, and thus consuming resources of t
 
 Suppose in the above application, the release pipeline requires manual approval before each new version of the application can receive production traffic. This creates the risk that while one version (`v6`) awaits manual approval on the staging deployment, the deployment pipeline will run again and overwrite it with a newer version (`v7`). Then, when the approval for `v6` is granted, the pipeline that deployed `v6` will set the staging deployment as production. But now it will be the unapproved `v7`, not the approved `v6`, that is deployed on that deployment and receives traffic.
 
-![The approval race condition](media/spring-cloud-blue-green-patterns/alternating-deployments-race-condition.png)
+![The approval race condition](media/concepts-blue-green-deployment-strategies/alternating-deployments-race-condition.png)
 
 You may be able to prevent the race condition by ensuring that the deployment flow for one version can't begin until the deployment flow for all previous versions is complete or aborted. Another way to prevent the approval race condition is to use the Named Deployments approach described below.
 
@@ -74,15 +74,15 @@ In the named deployments approach, a new deployment is created for each new vers
 
 In the illustration below, version `v5` is running on the deployment `deployment-v5`. The deployment name now contains the version because the deployment was created specifically for this version. There's no other deployment at the outset. Now, to deploy version `v6`, the deployment pipeline creates a new deployment `deployment-v6` and deploys app version `v6` there.
 
-![Deploying new version on a named deployment](media/spring-cloud-blue-green-patterns/named-deployment-1.png)
+![Deploying new version on a named deployment](media/concepts-blue-green-deployment-strategies/named-deployment-1.png)
 
 There's no risk of another version being deployed in parallel. First, Azure Spring Apps doesn't allow the creation of a third deployment while two deployments already exist. Second, even if it was possible to have more than two deployments, each deployment is identified by the version of the application it contains. Thus, the pipeline orchestrating the deployment of `v6` would only attempt to set `deployment-v6` as the production deployment.
 
-![New version receives production traffic named deployment](media/spring-cloud-blue-green-patterns/named-deployment-2.png)
+![New version receives production traffic named deployment](media/concepts-blue-green-deployment-strategies/named-deployment-2.png)
 
 After the deployment created for the new version receives production traffic, you'll need to remove the deployment containing the previous version to make room for future deployments. You may wish to postpone by some number of minutes or hours so you can roll back to the previous version if you discover a critical issue in the new version.
 
-![After a fallback period, deleting the previous deployment](media/spring-cloud-blue-green-patterns/named-deployment-3.png)
+![After a fallback period, deleting the previous deployment](media/concepts-blue-green-deployment-strategies/named-deployment-3.png)
 
 ### Tradeoffs of the named deployments approach
 

articles/spring-apps/how-to-cicd.md

@@ -119,7 +119,7 @@ To deploy using a pipeline, follow these steps:
 
    Your pipeline settings should match the following image.
 
-   :::image type="content" source="media/spring-cloud-how-to-cicd/pipeline-task-setting.jpg" alt-text="Screenshot of pipeline settings." lightbox="media/spring-cloud-how-to-cicd/pipeline-task-setting.jpg":::
+   :::image type="content" source="media/how-to-cicd/pipeline-task-setting.jpg" alt-text="Screenshot of pipeline settings." lightbox="media/how-to-cicd/pipeline-task-setting.jpg":::
 
    You can also build and deploy your projects using following pipeline template. This example first defines a Maven task to build the application, followed by a second task that deploys the JAR file using the Azure Spring Apps task for Azure Pipelines.
 
@@ -189,7 +189,7 @@ The following steps show you how to enable a blue-green deployment from the **Re
 1. Add a new pipeline, and select **Empty job** to create a job.
 1. Under **Stages** select the line **1 job, 0 task**
 
-   :::image type="content" source="media/spring-cloud-how-to-cicd/create-new-job.jpg" alt-text="Screenshot of where to select to add a task to a job." lightbox="media/spring-cloud-how-to-cicd/create-new-job.jpg":::
+   :::image type="content" source="media/how-to-cicd/create-new-job.jpg" alt-text="Screenshot of where to select to add a task to a job." lightbox="media/how-to-cicd/create-new-job.jpg":::
 
    1. Select the **+** to add a task to the job.
    1. Search for the **Azure Spring Apps** template, then select **Add** to add the task to the job.
@@ -205,7 +205,7 @@ The following steps show you how to enable a blue-green deployment from the **Re
 1. Navigate to the **Azure Spring Apps Deploy** task in **Stage 1**, then select the ellipsis next to **Package or folder**.
 1. Select *spring-boot-complete-0.0.1-SNAPSHOT.jar* in the dialog, then select **OK**.
 
-   :::image type="content" source="media/spring-cloud-how-to-cicd/change-artifact-path.jpg" alt-text="Screenshot of the 'Select a file or folder' dialog box." lightbox="media/spring-cloud-how-to-cicd/change-artifact-path.jpg":::
+   :::image type="content" source="media/how-to-cicd/change-artifact-path.jpg" alt-text="Screenshot of the 'Select a file or folder' dialog box." lightbox="media/how-to-cicd/change-artifact-path.jpg":::
 
 1. Select the **+** to add another **Azure Spring Apps** task to the job.
 1. Change the action to **Set Production Deployment**.

articles/spring-apps/how-to-configure-enterprise-spring-cloud-gateway.md

@@ -390,7 +390,7 @@ The following list shows the options available for Autoscale demand management:
 
 On the Azure portal, choose how you want to scale. The following screenshot shows the **Custom autoscale** option and mode settings:
 
-:::image type="content" source="media/spring-cloud-autoscale/custom-autoscale.png" alt-text="Screenshot of the Azure portal that shows the Autoscale setting page with the Custom autoscale option highlighted." lightbox="media/spring-cloud-autoscale/custom-autoscale.png":::
+:::image type="content" source="media/how-to-configure-enterprise-spring-cloud-gateway/custom-autoscale.png" alt-text="Screenshot of the Azure portal that shows the Autoscale setting page with the Custom autoscale option highlighted." lightbox="media/how-to-configure-enterprise-spring-cloud-gateway/custom-autoscale.png":::
 
 #### [Azure CLI](#tab/Azure-CLI)
 

articles/spring-apps/how-to-enable-ingress-to-app-tls.md

@@ -23,7 +23,7 @@ This article describes secure communications in Azure Spring Apps. The article a
 
 The following picture shows the overall secure communication support in Azure Spring Apps.
 
-:::image type="content" source="media/enable-end-to-end-tls/secured-tls.png" alt-text="Screenshot of secured TLS flow in Azure Spring Apps." border="false":::
+:::image type="content" source="media/how-to-enable-ingress-to-app-tls/secured-tls.png" alt-text="Screenshot of secured TLS flow in Azure Spring Apps." border="false" lightbox="media/how-to-enable-ingress-to-app-tls/secured-tls.png":::
 
 ## Secure communication model within Azure Spring Apps
 
@@ -78,7 +78,7 @@ To enable ingress-to-app TLS in the [Azure portal](https://portal.azure.com/), f
 3. Select **Ingress-to-app TLS**.
 4. Switch **Ingress-to-app TLS** to *Yes*.
 
-:::image type="content" source="media/enable-end-to-end-tls/enable-i2a-tls.png" alt-text="Screenshot of the Azure portal that shows the Ingress-to-app TLS page and control." lightbox="media/enable-end-to-end-tls/enable-i2a-tls.png":::
+:::image type="content" source="media/how-to-enable-ingress-to-app-tls/enable-i2a-tls.png" alt-text="Screenshot of the Azure portal that shows the Ingress-to-app TLS page and control." lightbox="media/how-to-enable-ingress-to-app-tls/enable-i2a-tls.png":::
 
 ### Verify ingress-to-app TLS status
 

articles/spring-apps/how-to-integrate-azure-load-balancers.md

@@ -50,9 +50,9 @@ Add endpoints in traffic manager:
 1. Input fully qualified domain name (FQDN) of each Azure Spring Apps public endpoint.
 1. Select **OK**.
 
-   :::image type="content" source="media/spring-cloud-load-balancers/traffic-manager-1.png" alt-text="Screenshot of the Azure portal that shows the Add endpoint page with an eastus FQDN with Priority 1." lightbox="media/spring-cloud-load-balancers/traffic-manager-1.png":::
+   :::image type="content" source="media/how-to-integrate-azure-load-balancers/traffic-manager-1.png" alt-text="Screenshot of the Azure portal that shows the Add endpoint page with an eastus FQDN with Priority 1." lightbox="media/how-to-integrate-azure-load-balancers/traffic-manager-1.png":::
 
-   :::image type="content" source="media/spring-cloud-load-balancers/traffic-manager-2.png" alt-text="Screenshot of the Azure portal that shows the Add endpoint page with a westus FQDN with Priority 2." lightbox="media/spring-cloud-load-balancers/traffic-manager-2.png":::
+   :::image type="content" source="media/how-to-integrate-azure-load-balancers/traffic-manager-2.png" alt-text="Screenshot of the Azure portal that shows the Add endpoint page with a westus FQDN with Priority 2." lightbox="media/how-to-integrate-azure-load-balancers/traffic-manager-2.png":::
 
 ### Configure Custom Domain
 
@@ -69,22 +69,22 @@ To integrate with Azure Spring Apps service, complete the following configuratio
 1. Specify **Target type** as *IP address* or *FQDN*.
 1. Enter your Azure Spring Apps public endpoints.
 
-   :::image type="content" source="media/spring-cloud-load-balancers/app-gateway-1.png" alt-text="Screenshot of the Azure portal that shows the Add backend pool page with the Backend targets values highlighted." lightbox="media/spring-cloud-load-balancers/app-gateway-1.png":::
+   :::image type="content" source="media/how-to-integrate-azure-load-balancers/app-gateway-1.png" alt-text="Screenshot of the Azure portal that shows the Add backend pool page with the Backend targets values highlighted." lightbox="media/how-to-integrate-azure-load-balancers/app-gateway-1.png":::
 
 ### Add Custom Probe
 
 1. Select **Health Probes** then **Add** to open custom **Probe** dialog.
 1. The key point is to select **No** for **Pick host name from backend HTTP settings** option and explicitly specify the host name. For more information, see [Application Gateway configuration for host name preservation](/azure/architecture/best-practices/host-name-preservation#application-gateway).
 
-   :::image type="content" source="media/spring-cloud-load-balancers/app-gateway-2.png" alt-text="Screenshot of the Azure portal that shows the probe page." lightbox="media/spring-cloud-load-balancers/app-gateway-2.png":::
+   :::image type="content" source="media/how-to-integrate-azure-load-balancers/app-gateway-2.png" alt-text="Screenshot of the Azure portal that shows the probe page." lightbox="media/how-to-integrate-azure-load-balancers/app-gateway-2.png":::
 
 ### Configure Backend Setting
 
 1. Select **Backend settings** then **Add** to add a backend setting.
 1. **Override with new host name:** select **No**.
 1. **Use custom probe**: select **Yes** and pick the custom probe created above.
 
-   :::image type="content" source="media/spring-cloud-load-balancers/app-gateway-3.png" alt-text="Screenshot of the Azure portal that shows the Add Backend setting page." lightbox="media/spring-cloud-load-balancers/app-gateway-3.png":::
+    :::image type="content" source="media/how-to-integrate-azure-load-balancers/app-gateway-3.png" alt-text="Screenshot of the Azure portal that shows the Add Backend setting page." lightbox="media/how-to-integrate-azure-load-balancers/app-gateway-3.png":::
 
 ## Integrate Azure Spring Apps with Azure Front Door
 
@@ -93,13 +93,13 @@ To integrate with Azure Spring Apps service and configure an origin group, use t
 1. **Add origin group**.
 1. Specify the backend endpoints by adding origins for the different Azure Spring Apps instances.
 
-   :::image type="content" source="media/spring-cloud-load-balancers/front-door-1.png" alt-text="Screenshot of the Azure portal that shows the Add an origin group page with the Add an origin button highlighted." lightbox="media/spring-cloud-load-balancers/front-door-1.png":::
+    :::image type="content" source="media/how-to-integrate-azure-load-balancers/front-door-1.png" alt-text="Screenshot of the Azure portal that shows the Add an origin group page with the Add an origin button highlighted." lightbox="media/how-to-integrate-azure-load-balancers/front-door-1.png":::
 
 1. Specify **origin type** as *Azure Spring Apps*.
 1. Select your Azure Spring Apps instance for the **host name**.
 1. Keep the **origin host header** empty, so that the incoming host header will be used towards the backend. For more information, see [Azure Front Door configuration for host name preservation](/azure/architecture/best-practices/host-name-preservation#azure-front-door).
 
-   :::image type="content" source="media/spring-cloud-load-balancers/front-door-2.png" alt-text="Screenshot of the Azure portal that shows the Add an origin page." lightbox="media/spring-cloud-load-balancers/front-door-2.png":::
+    :::image type="content" source="media/how-to-integrate-azure-load-balancers/front-door-2.png" alt-text="Screenshot of the Azure portal that shows the Add an origin page." lightbox="media/how-to-integrate-azure-load-balancers/front-door-2.png":::
 
 ## Next steps