Make service discovery endpoint transparent to the application
As of today the Copilot service discovery documentation states that for a public facing front-end service to talk to a backend api service, the FE application needs to append a specific domain string ({env name}.{app name}.local) when calling the api backend. We inform the application about this string via a variable (COPILOT_SERVICE_DISCOVERY_ENDPOINT).
This, however, requires the application to be aware of being deployed with copilot (in fact we suggest the application to be modified with, for example, the following command: endpoint := fmt.Sprintf("http://api.%s/some-request", os.Getenv("COPILOT_SERVICE_DISCOVERY_ENDPOINT")).
There may be situations where users may be reluctant to change the application (and/or making it "infrastructure aware"). Most container solutions (e.g. docker-compose, swarm, kubernetes, etc) allows customers to resolve services by their name (e.g. front-end and api) by treating the domain name they use internally transparently to the user.
This could be solved by populating and injecting the LOCALDOMAIN variable with the same string (the domain in that variable will be appended by default to the endpoint being called (e.g. if you call api the OS will search for api.{env name}.{app name}.local)
The above (AFAIK) won't work with Alpine based-images so another workaround that the user has is to echo the content of the COPILOT_SERVICE_DISCOVERY_ENDPOINT into the resolv.conf of the container. This has the advantage of keeping the application infrastructure agnostic (e.g. their code can continue to call api) but it requires a small tweak in the startup of the image.
Injecting LOCALDOMAIN seems that it could be useful (at least for those that do not use Alpine) and low hanging fruit.
Hi @mreferre !
The request makes sense to me, today copilot injects environment variables with the prefix COPILOT_ to make our "namespace" explicit.
But we should be able to tell from the manifest if the client has already specified a LOCALDOMAIN env variable or not and if not to inject the variable.
There may be situations where users may be reluctant to change the application
We can also allow the configuration of the service discovery namespace now that environment manifests are supported. So that copilot's default can be overriden before environment creation.
type: Environment
service_discovery:
endpoint: 'custom.name.local'
Thanks. Maybe make it intentional/explicit and allow customers to opt-in into injecting LOCALDOMAIN? As a new parameter in the manifest. Albeit it's a bit of a moot point because the whole idea would be to make it completely transparent and "it just works" (well anyway better adding a parameter to the Copilot manifest than changing the code).
I don't see the environment custom service endpoint being useful in this case unless you are calling a hard-coded private URL in the code (which I would argue is way way less frequent than calling the service name without the domain).