Closed RyanWalker277 closed 1 year ago
Service owners can clarify this. Let's wait on this for now.
@chinmoy12c @pankajjangid05 can you confirm this? Last time I deployed I saw same redis being used to stored and then fetch key-value
@chinmoy12c @pankajjangid05 can you confirm this? Last time I deployed I saw same redis being used to stored and then fetch key-value
Both transaction layer (SpringBoot services) as well as uci-api is using 6379 for redis cache.
@chinmoy12c @pankajjangid05 can you confirm this? Last time I deployed I saw same redis being used to stored and then fetch key-value
Both transaction layer (SpringBoot services) as well as uci-api is using 6379 for redis cache.
6379 is going to be common, as we are using internal docker compose network to connect services. hostname is the one which help identify if the cache is same or not.
A small update, initially I didn't notice that there is another redis instance named redis
in the compose. Just like uci-api-scheduler-db, it also dosen't seem to be used by any other service in the docker-compose. Can anyone confirm whether it is required or not?
If these secrets were true positive and are still valid, we highly recommend you to revoke them. Once a secret has been leaked into a git repository, you should consider it compromised, even if it was deleted immediately. Find here more information about risks.
🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.
Our GitHub checks need improvements? Share your feedbacks!
Fixes #44
It looks like the
uci-api-scheduler-db
container may not be needed because none of the services use it. However, thecache
container seems to be necessary for theuci-transport-socket
service to work properly. Please let me know, if I am mistaken.