[ECS] [Service Discovery]: Service Registry Variables stored in Task Container
- Dominant language
- Shell
- Stars
- 5.4k
- Forks
- 334
- PR merge metrics
- No merged PRs in 30d
Description
### Community Note
* Please vote on this issue by adding a 👍 [reaction](https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) to the original issue to help the community and maintainers prioritize this request
* Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
* If you are interested in working on this issue or have submitted a pull request, please leave a comment
**Tell us about your request**
What do you want us to build?
This is a request to store some service discovery information such as service endpoint/registry information on the container/task metadata which can be dynamically referenced by the application running on ECS.
**Which service(s) is this request for?**
This could be Fargate, ECS
**Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?**
What outcome are you trying to achieve, ultimately, and why is it hard/impossible to do right now? What is the impact of not having this problem solved? The more details you can provide, the better we'll be able to understand and solve the problem.
Tasks do not currently have a way outside of the CloudMap API to reference their service discovery information dynamically. Through storing this information on the container or the metadata endpoints this allows for easier access to service endpoints and allows for extensions of current troubleshooting tooling to better assist in situations where users experience issues with service discovery connectivity.
**Are you currently working around this issue?**
How are you currently solving this problem?
Currently, the only way around this is to hardcode environment variables in the container definition section of your task definition, or leverage the CloudMap API to programmatically pull service discovery configuration.
**Additional context**
Anything else we should know?
**Attachments**
If you think you might have additional information that you'd like to include via an attachment, please do - we'll take a look. (Remember to remove any personally-identifiable information.)
Contributor guide
Research direction
No repository files or tests are named. Start by reviewing the ECS task and container metadata endpoints alongside the Cloud Map API references mentioned in the issue. Done would require an agreed design and documented service-discovery information that applications and troubleshooting tools can access dynamically.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- aws
- Domain
- cloud
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100