Feature Request: Support service discovery via app name

[ezYakaEagle442]

Is your feature request related to a problem? Please describe.

The doc https://learn.microsoft.com/en-us/azure/container-apps/connect-apps?source=recommendations&tabs=bash describes that the only way connect microservices without Dapr is to get the App FQDN which breaks Apps migration when migrating an existing App to ACA.

see at https://github.com/ezYakaEagle442/aca-java-petclinic-mic-srv#understanding-the-spring-petclinic-application

Specifically required when deploying the Petclinic App to ACA ${} ${VETS_SVC_URL} ${} , ${VISITS_SVC_URL} , ${CUSTOMERS_SVC_URL} Environment variables have been configured in :

• spring-petclinic-api-gateway/src/main/resources/application.yml

original code :

spring:
  cloud:
    gateway:
      discovery:
        # make sure a DiscoveryClient implementation (such as Netflix Eureka) is on the classpath and enabled
        locator: # https://cloud.spring.io/spring-cloud-gateway/reference/html/#the-discoveryclient-route-definition-locator
          enabled: true #  to configure Spring Cloud Gateway to use the Spring Cloud Service Registry to discover the available microservices.    
      routes:
        - id: vets-service
          uri: http://vets-service
          predicates:
            - Path=/api/vet/**
          filters:
            - StripPrefix=2
        - id: visits-service
          uri: http://visits-service
          predicates:
            - Path=/api/visit/**
          filters:
            - StripPrefix=2
        - id: customers-service
          uri: http://customers-service
          predicates:
            - Path=/api/customer/**
          filters:
            - StripPrefix=2

code update required to deploy Petclinic to ACA :

spring:      
  cloud:
    gateway:
      routes:
        - id: vets-service
          uri: https://${VETS_SVC_URL}
          predicates:
            - Path=/api/vet/**
          filters:
            - StripPrefix=2
        - id: visits-service
          uri: https://${VISITS_SVC_URL}
          predicates:
            - Path=/api/visit/**
          filters:
            - StripPrefix=2
        - id: customers-service
          uri: https://${CUSTOMERS_SVC_URL}
          predicates:
            - Path=/api/customer/**
          filters:
            - StripPrefix=2

• spring-petclinic-api-gateway/src/main/java/org/springframework/samples/petclinic/api/application/CustomersServiceClient.java

original code :

public Mono<OwnerDetails> getOwner(final int ownerId) {
    return webClientBuilder.build().get()
        .uri("http://customers-service/owners/{ownerId}", ownerId)
        .retrieve()
        .bodyToMono(OwnerDetails.class);
}

code update required to deploy Petclinic to ACA :

public Mono<OwnerDetails> getOwner(final int ownerId) {
    return webClientBuilder.build().get()
        .uri("https://${CUSTOMERS_SVC_URL}/owners/{ownerId}", ownerId)
        .retrieve()
        .bodyToMono(OwnerDetails.class);
    }

• spring-petclinic-api-gateway/src/main/java/org/springframework/samples/petclinic/api/application/VisitsServiceClient.java

original code :

private String hostname = "http://visits-service/";

code update required to deploy Petclinic to ACA :

private String hostname = "https://${VISITS_SVC_URL}/";

Those back-end URL have been set in the App through Bicep

    template: {
      containers: [
        { 
          command: [
            'java', '-javaagent:${applicationInsightsAgentJarFilePath}', 'org.springframework.boot.loader.JarLauncher', '--server.port=8080', '-Xms512m -Xmx1024m', '--spring.cloud.azure.keyvault.secret.enabled=false', '--spring.cloud.azure.keyvault.secret.property-source-enabled=false'
          ]
          env: [
            {
              // https://docs.microsoft.com/en-us/azure/azure-monitor/app/java-in-process-agent#set-the-application-insights-connection-string
              name: 'APPLICATIONINSIGHTS_CONNECTION_STRING'
              secretRef: 'appinscon'
            }
            {
              name: 'SPRING_CLOUD_AZURE_TENANT_ID'
              secretRef: 'springcloudazuretenantid'
            }   
            {
              name: 'SPRING_CLOUD_AZURE_KEY_VAULT_ENDPOINT'
              secretRef: 'springcloudazurekvendpoint'
            }           
            {
              name: 'CFG_SRV_URL'
              value: ConfigServerContainerApp.properties.configuration.ingress.fqdn
            }
            {
              name: 'CUSTOMERS_SVC_URL'
              value: CustomersServiceContainerApp.properties.configuration.ingress.fqdn
            }    
            {
              name: 'VETS_SVC_URL'
              value: VetsServiceContainerApp.properties.configuration.ingress.fqdn
            } 
            {
              name: 'VISITS_SVC_URL'
              value: VisitsServiceContainerApp.properties.configuration.ingress.fqdn
            }                                          
          ]

Describe the solution you'd like.
To support App portability, ACA should expose the interna service through this URL pattern : http://${ACA_APP_NAME}

Describe alternatives you've considered.
The only option was to replace the URL http://mybackend by the https://${ACA endpoint}

Additional context.
this breaks the portability of any spring boot Apps, any other App using K8S internal service pattern when configuring URL through http://mybackend-service

@kendallroden @dariagrigoriu @torosent

[kendallroden]

We are investigating the implementation and have plans to enable shortly. Thanks for the issue we have marked as roadmap

[benc-uk]

Would be great to see some improvements here. For many coming from Kubernetes, it seems super strange needing to put an ingress in front of each container app, even for internal "pod to pod" calls. For most Kubernetes people, ingress means - exposing traffic outside the cluster

I totally get that the deployment model for ACA is very different from true Kubernetes, perhaps it's just overloading on the term "ingress"

[ezYakaEagle442]

see also ezYakaEagle442/aca-java-petclinic-mic-srv#1, it looks worse than what I thought : even using the FQDN as workaround, the UI is broken.

[ezYakaEagle442]

finally fixed the routing using internal service with:

String internalK8Ssvc2svcRoute = "http://" + System.getenv("CUSTOMERS_SVC_APP_NAME") + ".internal." + System.getenv("CONTAINER_APP_ENV_DNS_SUFFIX");

[mburumaxwell]

My 2 cents on this having migrated mostly from AKS to ACA in the last 30 days.

The problem with building the URL using the name of the Container App is the {APP_NAME}.internal.{ENV_DNS_SUFFIX} domain is only mapped when the ingress is internal. Should you change the target application to external you will need to rebuild your code to change how the URL is built by removing the .internal. part, otherwise it will always return a 404.

Using the name of the app (analogous to the name of the service in AKS) would be okay but complicate TLS setup and also makes the assumption that all the apps are in the same Kubernetes namespace?

I would much rather prefer (maybe it is just wish), that Azure made the internal domain name always functional so long as the ingress is enabled (internal or external) while the one without the .internal section be functional only when the ingress is external.

[ahmelsayed]

the .internal. domain should always work, i.e: for both internal and external apps. Only the external domain is conditional on the app being external.

example:

# 1. Create an external proxy app 
$ az containerapp create \
  --name squid-proxy \
  --resource-group $RESOURCE_GROUP \
  --environment $CONTAINERAPPS_ENVIRONMENT  \
  --image docker.io/ubuntu/squid:5.2-22.04_beta \
  --transport tcp \
  --target-port 3128 \
  --exposed-port 3128 \
  --ingress external \
  --query properties.configuration.ingress.fqdn

> squid-proxy.bluesand-424eb2fe.westeu.azurecontainerapps.io

# 2. Create an external nginx app
$ az containerapp create \
  --name nginx\
  --resource-group $RESOURCE_GROUP \
  --environment $CONTAINERAPPS_ENVIRONMENT  \
  --image nginx \
  --target-port 80 \
  --ingress external \
  --query properties.configuration.ingress.fqdn

> nginx.bluesand-424eb2fe.westeu.azurecontainerapps.io

# through the proxy, both external and internal endpoints should be accessible
# external
$ curl -I --proxy squid-proxy.bluesand-424eb2fe.westeu.azurecontainerapps.io:3128 \
    https://nginx.bluesand-424eb2fe.westeu.azurecontainerapps.io 

> HTTP/1.1 200 Connection established

> HTTP/2 200 
> server: nginx/1.23.2
> date: Thu, 10 Nov 2022 17:29:27 GMT
> content-type: text/html
> content-length: 615
> last-modified: Wed, 19 Oct 2022 07:56:21 GMT
> etag: "634fada5-267"
> accept-ranges: bytes

# internal
$ curl -I --proxy squid-proxy.bluesand-424eb2fe.westeu.azurecontainerapps.io:3128 \
    https://nginx.internal.bluesand-424eb2fe.westeu.azurecontainerapps.io 

> HTTP/1.1 200 Connection established

> HTTP/2 200 
> server: nginx/1.23.2
> date: Thu, 10 Nov 2022 17:29:43 GMT
> content-type: text/html
> content-length: 615
> last-modified: Wed, 19 Oct 2022 07:56:21 GMT
> etag: "634fada5-267"
> accept-ranges: bytes

Using the name of the app (analogous to the name of the service in AKS) would be okay but complicate TLS setup and also makes the assumption that all the apps are in the same Kubernetes namespace?

I would much rather prefer (maybe it is just wish), that Azure made the internal domain name always functional so long as the ingress is enabled (internal or external) while the one without the .internal section be functional only when the ingress is external.

This is coming soon. Though you're right about the TLS issue. It'll be http:// only to start.

[SophCarp]

Roadmap issue: #605

[calleo]

This was very helpful. Perhaps this could be added to the docs: https://learn.microsoft.com/en-us/azure/container-apps/connect-apps?

I had no idea I had to use ".internal" to reach an internal service which is not externally exposed.

[ahmelsayed]

This should work now as expected. You can call http apps over http://{appName} or http://{revisionName}.

[marinasundstrom]

I have been working on the developer experience in my own app. I use Steeltoe with Consul locally.

The convention https://<app-name> will work great for both development, and production!

[marinasundstrom]

I was expecting this to work, but it does not: https://<app-name>, or is it just for HTTP?

Yes, they are internal. So is it about the .internal. Kind of ruins it for me with the conventions.

Where is the documentation?

Update: http is important. http://<app-name>