Merge pull request #268530 from Ratulac-Azure/Ratulac-fix-old-image-syntax

Fix old image syntax

Author: prmerger-automator[bot]

articles/spring-apps/basic-standard/how-to-appdynamics-java-agent-monitor.md

@@ -44,7 +44,7 @@ For the whole workflow, you need to:
 * Activate the AppDynamics Java in-process agent in Azure Spring Apps to generate application metrics data.
 * Connect the AppDynamics Agent to the AppDynamics Controller to collect and visualize the data in the controller.
 
-![Diagram showing a Spring Boot application in 'Azure Spring Apps' box with a two-directional arrow connecting it to an 'AppDynamics Agent' box, which also has an arrow pointing to an 'AppDynamics Controller' box](media/how-to-appdynamics-java-agent-monitor/appdynamics-activation.jpg)
+:::image type="content" source="media/how-to-appdynamics-java-agent-monitor/appdynamics-activation.jpg" alt-text="Diagram showing a Spring Boot application in 'Azure Spring Apps' box with a two-directional arrow connecting it to an 'AppDynamics Agent' box, which also has an arrow pointing to an 'AppDynamics Controller' box" lightbox="media/how-to-appdynamics-java-agent-monitor/appdynamics-activation.jpg":::
 
 ### Activate an application with the AppDynamics Agent using the Azure CLI
 

articles/spring-apps/basic-standard/quickstart-logs-metrics-tracing.md

@@ -161,15 +161,15 @@ To get the logs using Azure Toolkit for IntelliJ:
 
 1. Select **Streaming Logs** from the drop-down list.
 
-   ![Select streaming logs](media/quickstart-logs-metrics-tracing/streaming-logs.png)
+   :::image type="content" source="media/quickstart-logs-metrics-tracing/streaming-logs.png" alt-text="Select streaming logs" lightbox="media/quickstart-logs-metrics-tracing/streaming-logs.png":::
 
 1. Select **Instance**.
 
-   ![Select instance](media/quickstart-logs-metrics-tracing/select-instance.png)
+   :::image type="content" source="media/quickstart-logs-metrics-tracing/select-instance.png" alt-text="Select instance" lightbox="media/quickstart-logs-metrics-tracing/select-instance.png":::
 
 1. The streaming log is visible in the output window.
 
-   ![Streaming log output](media/quickstart-logs-metrics-tracing/streaming-log-output.png)
+   :::image type="content" source="media/quickstart-logs-metrics-tracing/streaming-log-output.png" alt-text="Streaming log output" lightbox="media/quickstart-logs-metrics-tracing/streaming-log-output.png":::
 
  To learn more about the query language that's used in Log Analytics, see [Azure Monitor log queries](/azure/data-explorer/kusto/query/). To query all your Log Analytics logs from a centralized client, check out [Azure Data Explorer](/azure/data-explorer/query-monitor-data).
 

articles/spring-apps/enterprise/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/concepts-blue-green-deployment-strategies/alternating-deployments-1.png)
+:::image type="content" source="media/concepts-blue-green-deployment-strategies/alternating-deployments-1.png" alt-text="Two deployments: deployment1 receives production traffic" lightbox="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/concepts-blue-green-deployment-strategies/alternating-deployments-2.png)
+:::image type="content" source="media/concepts-blue-green-deployment-strategies/alternating-deployments-2.png" alt-text="V4 is now deployed on deployment2 and undergoes testing" lightbox="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/concepts-blue-green-deployment-strategies/alternating-deployments-3.png)
+:::image type="content" source="media/concepts-blue-green-deployment-strategies/alternating-deployments-3.png" alt-text="V4 on deployment2 now receives production traffic" lightbox="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/concepts-blue-green-deployment-strategies/alternating-deployments-4.png)
+:::image type="content" source="media/concepts-blue-green-deployment-strategies/alternating-deployments-4.png" alt-text="V5 deployed on deployment1" lightbox="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/concepts-blue-green-deployment-strategies/alternating-deployments-5.png)
+:::image type="content" source="media/concepts-blue-green-deployment-strategies/alternating-deployments-5.png" alt-text="V5 tested on deployment1" lightbox="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/concepts-blue-green-deployment-strategies/alternating-deployments-6.png)
+:::image type="content" source="media/concepts-blue-green-deployment-strategies/alternating-deployments-6.png" alt-text="V5 receives traffic on deployment1" lightbox="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/concepts-blue-green-deployment-strategies/alternating-deployments-race-condition.png)
+:::image type="content" source="media/concepts-blue-green-deployment-strategies/alternating-deployments-race-condition.png" alt-text="The approval race condition" lightbox="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/concepts-blue-green-deployment-strategies/named-deployment-1.png)
+:::image type="content" source="media/concepts-blue-green-deployment-strategies/named-deployment-1.png" alt-text="Deploying new version on a named deployment" lightbox="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/concepts-blue-green-deployment-strategies/named-deployment-2.png)
+:::image type="content" source="media/concepts-blue-green-deployment-strategies/named-deployment-2.png" alt-text="New version receives production traffic named deployment" lightbox="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/concepts-blue-green-deployment-strategies/named-deployment-3.png)
+:::image type="content" source="media/concepts-blue-green-deployment-strategies/named-deployment-3.png" alt-text="After a fallback period, deleting the previous deployment" lightbox="media/concepts-blue-green-deployment-strategies/named-deployment-3.png":::
 
 ### Tradeoffs of the named deployments approach
 

articles/spring-apps/enterprise/github-actions-key-vault.md

@@ -56,11 +56,11 @@ The credential you created above can get only general information about the Key
 
 Go to the **Key Vault** dashboard in Azure portal, select the **Access control** menu, then open the **Role assignments** tab. Select **Apps** for **Type** and `This resource` for **scope**.  You should see the credential you created in previous step:
 
-![Set access policy](media/github-actions-key-vault/key-vault1.png)
+:::image type="content" source="media/github-actions-key-vault/key-vault1.png" alt-text="Set access policy" lightbox="media/github-actions-key-vault/key-vault1.png":::
 
 Copy the credential name, for example, `azure-cli-2020-01-19-04-39-02`. Open the **Access policies** menu, then select the **Add Access Policy** link.  Select `Secret Management` for **Template**, then select **Principal**. Paste the credential name in **Principal**/**Select** input box:
 
-![Select](media/github-actions-key-vault/key-vault2.png)
+:::image type="content" source="media/github-actions-key-vault/key-vault2.png" alt-text="Select" lightbox="media/github-actions-key-vault/key-vault2.png":::
 
 Select the **Add** button in the **Add access policy** dialog, then select **Save**.
 
@@ -90,7 +90,7 @@ Again, results:
 
 Copy the entire JSON string.  Go back to **Key Vault** dashboard. Open the **Secrets** menu, then select the **Generate/Import** button. Input the secret name, such as `AZURE-CREDENTIALS-FOR-SPRING`. Paste the JSON credential string to the **Value** input box. You may notice the value input box is a one-line text field, rather than a multi-line text area.  You can paste the complete JSON string there.
 
-![Full scope credential](media/github-actions-key-vault/key-vault3.png)
+:::image type="content" source="media/github-actions-key-vault/key-vault3.png" alt-text="Full scope credential" lightbox="media/github-actions-key-vault/key-vault3.png":::
 
 ## Combine credentials in GitHub Actions
 

articles/spring-apps/enterprise/troubleshoot.md

@@ -272,7 +272,7 @@ Creating an Azure Spring Apps Enterprise plan instance fails with error code "11
 
 When you visit the SaaS offer [Azure Spring Apps Enterprise](https://aka.ms/ascmpoffer) in the Azure Marketplace, it may say "No plans are available for market '\<Location>'" as in the following image.
 
-![No plans available error image](./media/troubleshoot/no-enterprise-plans-available.png)
+:::image type="content" source="./media/troubleshoot/no-enterprise-plans-available.png" alt-text="No plans available error image" lightbox="./media/troubleshoot/no-enterprise-plans-available.png":::
 
 The Azure Spring Apps Enterprise plan needs customers to pay for a license to Tanzu components through an Azure Marketplace offer. To purchase in the Azure Marketplace, the billing account's country or region for your Azure subscription should be in the SaaS offer's supported geographic locations.