Skip to content
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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

ser-io
Copy link
Member

@ser-io 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.

@ser-io ser-io requested a review from jemoreira as a code owner April 17, 2024 19:44
Comment on lines 17 to 16
ln -s /etc/cuttlefish-orchestration/nginx.conf /etc/nginx/nginx.conf
sudo nginx -s reload
Copy link
Member

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.

Copy link
Member Author

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 different location 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?

Copy link
Member

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.

Copy link
Member Author

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.

frontend/src/host_orchestrator/main.go Outdated Show resolved Hide resolved
- 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants