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/service-connector/known-limitations.md
+5-5Lines changed: 5 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,6 @@
1
1
---
2
2
title: Service Connector limitations
3
-
description: Learn about current limitations in Service Connector.
3
+
description: Learn about current limitations in Service Connector used to connect apps and Cloud services in Azure.
4
4
titleSuffix: Service Connector
5
5
ms.service: service-connector
6
6
ms.topic: troubleshooting
@@ -14,9 +14,9 @@ In this article, learn about Service Connector's existing limitations and how to
14
14
15
15
## Limitations to Infrastructure as Code (IaC)
16
16
17
-
Service Connector has been designed to bring the benefits of easy, secure, and consistent backing service connections to as many Azure services as possible. To do so, Service Connector has been developed as an extension resource provider.
17
+
Service Connector is designed to bring the benefits of easy, secure, and consistent backing service connections to as many Azure services as possible. To do so, Service Connector is developed as an extension resource provider.
18
18
19
-
Unfortunately, there are some limitations with IaC support as Service Connector modifies infrastructure on users' behalf. In this scenario, users would begin by using Azure Resource Manager (ARM), Bicep, Terraform, or other IaC templates to create resources. Afterwards, they would use Service Connector to set up resource connections. During this step, Service Connector modifies resource configurations on behalf of the user. If the user reruns their IaC template at a later time, modifications made by Service Connector would disappear as they were not reflected in the original IaC templates. An example of this behavior is Azure Container Apps deployed with ARM templates usually have Managed Identity (MI) disabled by default, Service Connector enables MI when setting up connections on users' behalf. If users trigger the same ARM templates without updating MI settings, the redeployed container apps will have MI disabled again.
19
+
IaC support comes with some limitations, as Service Connector modifies the infrastructure on the users' behalf. In this scenario, users begin by using Azure Resource Manager (ARM), Bicep, Terraform, or other IaC templates to create resources. Afterwards, they use Service Connector to set up resource connections. During this step, Service Connector modifies resource configurations on behalf of the user. If the user reruns their IaC template at a later time, modifications made by Service Connector disappear as they weren't reflected in the original IaC templates. As an example of this behavior, Azure Container Apps resources deployed with ARM templates usually have the managed identity authentication disabled by default. Service Connector enables the managed identity when setting up connections on the users' behalf. If users trigger the same ARM templates without updating the managed identity settings, the managed identity will be disabled once again in the redeployed Azure Container Apps resource.
20
20
21
21
If you run into any issues when using Service Connector, [file an issue with us](https://github.com/Azure/ServiceConnector/issues/new).
22
22
@@ -25,9 +25,9 @@ If you run into any issues when using Service Connector, [file an issue with us]
25
25
We suggest the following solutions:
26
26
27
27
- Reference [how to build connections with IaC tools](how-to-build-connections-with-iac-tools.md) to build your infrastructure or translate your existing infrastructure to IaC templates.
28
-
- If your CI/CD pipelines contain templates of source compute or backing services, suggested flow is: reapplying the templates, adding sanity check or smoke tests to make sure the application is up and running, then allowing live traffic to the application. The flow adds a verification step before allowing live traffic.
28
+
- If your CI/CD pipelines contain templates of source compute or backing services, we suggested reapplying the templates, adding a sanity check or smoke tests to make sure the application is up and running, then allowing live traffic to the application. The flow adds a verification step before allowing live traffic.
29
29
- When automating Azure Container App code deployments with Service Connector, we recommend the use of [multiple revision mode](../container-apps/revisions.md#revision-modes) to avoid routing traffic to a temporarily nonfunctional app before Service connector can reapply connections.
30
-
- The order in which automation operations are performed matters greatly. Ensure your connection endpoints are there before the connection itself is created. Ideally, create the backing service, then the compute service, and then the connection between the two. This way, Service Connector can configure both the compute service and the backing service appropriately.
30
+
- The order in which automation operations are performed matters. Ensure your connection endpoints are there before the connection itself is created. Ideally, create the backing service, then the compute service, and then the connection between the two. This way, Service Connector can configure both the compute service and the backing service appropriately.
0 commit comments