jpl-btlunsfo
commented
1 month ago @galenatjpl per slack, you wanted to discuss this more?
Looking at the current implementation, I feel like the not-really idempotent application of changes is something that is being overlooked. That methodology is what causes the heartburn of testing changes and updating the source config, because the current setup can't purge things from the config- since it just mindlessly injects strings into a file to begin with. The proper way would (in my opinon) involve the proxy refetching the whole configuration from a single source of truth that is actually composable and modifiable.
That the config is stored on EFS doesn't really even buy us anything, and again causes more issues when we're trying to develop changes.
The process I would expect (and hope to implement) would be: 1) ECS httpd container starts up a) httpd container (modified) entrypoint script queries a specific SSM parameter path (based on venue, etc) b) the entrypoint script takes those input snippetss, and based on simple ordinal naming (say 01-ui-proxy, 04-sps-proxy, etc for each) templates its configuration file as part of the startup
2) some application adds a new config snippet to that SSM path area a) lambda catches the change, and triggers a rolling restart of any/all containers (i'm not sure if there are multiple instances of this httpd ECS container) b) container restarts, fetches and templates config file again
1a hinges on being able to query all parameters under a certain path; if we can't do this then i'd say we should keep a list in one parameter that references the paths of the other parameters, etc
2a hinges on the lambda being able to "watch" a SSM parameter change. If we can't do that, then i'd say we should stash the config snipet in some S3 bucket or the like, where it can.
as it is currently, the process seems to be 1) make the lambda create the config file on EFS a) and if it exists just shove the lambda input on top of it b) restart the container?
mike-gangl
galenatjpl
NOTE: @jpl-btlunsfo before starting on this, we should discuss more..
Investigate how VENUE HTTPD configurations are managed, and improve this process.
Look into whether EFS is still necessary. Mike has recently said that he successfully was able to add a path to the HTTPD configuration via the lambda. As this seems to work, Brad should probably continue along the lines of this approach, and reach out to Mike if he needs an example of how this was done. See writeup: https://github.com/unity-sds/unity-proxy/. See also: https://jpl.slack.com/archives/C028NP76HPA/p1716321080117919
Configurations can be in Github? SSM-change can perhaps trigger a ECS restart? Fetching on start from SSM might be a better approach.