Skip to content

Add support to run 2 server instances (HTTP/HTTPS) #1889

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

Merged
merged 10 commits into from
Jan 3, 2018
Merged

Add support to run 2 server instances (HTTP/HTTPS) #1889

merged 10 commits into from
Jan 3, 2018

Conversation

ggarnier
Copy link
Member

With this PR, it's possible to start 2 tsuru server instances simultaneously, one with HTTP and the other with HTTPS. The use case for this is when you want to migrate from HTTP to HTTPS, and you need to keep them both running for some time.

To enable HTTP server in port 8080 and HTTPS server in port 8443, for instance, set this in tsuru.conf:

listen: :8080
use-tls: true
tls:
  listen: :8443
  cert-file: test.crt
  key-file: test.key

To use only HTTPS, set use-tls: true and only one of listen, tls:listen keys.

RegisterHandler("/foo", "GET", AuthorizationRequiredHandler(authorizedTsuruHandler))
defer resetHandlers()

go RunServer(false)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Calling RunServer with false for the dryMode is quite problematic, this is the cause of all the race conditions in the tests and this happens because the test isn't closing the old server and calling shutdown on multiple initialized components. Calling shutdown.Do() before the test exits should be able to fix this. However, I'm not sure if some of our packages can safely handle being reinitialized after a shutdown.

api/server.go Outdated

if httpsSrv != nil {
if httpSrv != nil {
go startHttpServer(httpSrv, listen)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By starting a goroutine here we are ignoring possible errors during listening. Maybe we should have a channel for errors to capture then, something like:

errCh := make(chan error, 2)
if httpsSrv != nil {
  go func() { errCh <- startHttpsServer(httpsSrv, listen, ...) }()
}
if httpSrv != nil {
  go func() { errCh <- startHttpServer(httpSrv, listen) }()
}
return <-errCh

Also, I don't think we should call fatal in createServers since we're able to return errors. We should simply return the errors and let the caller call fatal for any returned error.

@ggarnier ggarnier merged commit 1e931bb into master Jan 3, 2018
@ggarnier ggarnier deleted the tls branch January 3, 2018 13:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants