New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Run host orchestrator service behind nginx. #508
base: main
Are you sure you want to change the base?
Conversation
ser-io
commented
Apr 17, 2024
- Start using a reverse proxy in the host as new services running along with the host orchestrator service will be added, i.e a new service for logs retrieval.
ln -s /etc/cuttlefish-orchestration/nginx.conf /etc/nginx/nginx.conf | ||
sudo nginx -s reload |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you put this configuration file in /etc/nginx/conf.d/host_orchestrator.conf
instead? That avoids having to override the entire nginx config and plays well with other services that could be installed in the host.
That would also allow you to enable and disable that configuration on host_orchestrator service start/stop, simply by changing the file extension and reloading nginx.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I evaluated this approach, however preferred to have full control of the configuration in one single file for the following reasons:
- different nginx packages can potentially install different defaults we won't be having control over, using our own config we make sure of having a similar behavior everywhere. (found this searching around this topic which adds more color https://serverfault.com/a/882180)
- we are going to use nginx as reverse proxy only where we are going to have one
server
and differentlocation
entries for which I consider easier to maintain and less prone to error to control this setup on a centralized place rather than being enabled/disabled for the downstream services themselves.
let me know what do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
different nginx packages can potentially install different defaults we won't be having control over
This would still be problem if the other package is installed after cuttlefish-orchestration
, as that package would still override our config.
I'm thinking other users of the orchestration package could decide to install something like a /health endpoint or some other service in the host for which they want to use nginx but we're taking over nginx config completely.
one server and different location entries
I don't know what this means, I'm not familiar enough with nginx configuration. Based on my previous argument, I would still prefer the conf.d approach.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree, added our own specific config under /etc/nginx/conf.d
.
- Start using a reverse proxy in the host as new services running along with the host orchestrator service will be added, i.e a new service for logs retrieval.