We used this for a while at Braintree. It works great for Unicorn-style restarts, but it doesn't ensure that the server shuts down gracefully.
So while you'll have uninterrupted connectivity, if you don't ensure that your server shuts down gracefully, you'll still drop the requests that the old process is servicing when the restart is triggered. We wrote a library called manners for managing the graceful shutdown of a single server: https://github.com/braintree/manners. When used in conjunction with manners, GoAgain provides zero-downtime restarts without any dropped requests.
(Manners is still under development, so make sure you understand it before using it.)
We had an interesting experience with Go. We ended up deciding the language was not a great fit for our needs right now, in part because the community is still pretty immature. (You can read about our experiences here: https://braintreepayments.com/braintrust/gotchas-irritants-a...).
Still -- as more and more libraries like this get released and stabilized, Go will become an increasingly interesting option for developers.
Go is only ever going to be as useful as the community works towards making it useful. We are trying our best to implement all the boilerplate code and solve all of Go's short comings.
Go is a very young programming language and unfortunately there are alot of cases where we have to implement pkg foo, bar, baz, because pkg quux depends on them. There are going to be many places where things break at this stage in Go's life, however that shouldnt discourage using Go for real world projects, because many of yesterday's bug end up being debugged and patched today. Go is a great investment for your company, and I hope you and your team reconsider using go for your projects after go 1.1 comes out.
http://tip.golang.org/doc/go1.1
If you guys need help, feel free to join us in #go-nuts on freenode's irc server. IMHO, The best feature of go is, arguably, the helpful evangelist-like gopher community hanging out in IRC. We wouldnt mind helping you guys with your issues, but you have to help us help you.
Those are clearly not Facebook scale servers but for majority of people: you don't need this or any other such solution.
Here's what I do for deployment. I have a fabric script that:
- copies the new executable to the server
- kills currently running executable
- starts the new executable
The worst that can happen is that a few connections will get dropped and that's perfectly fine 99.9% of websites. You don't control internet so the users will get broken connections all the time for reasons you can't eliminate. They shrug and hit reload button.
Complicating things to avoid few seconds of downtime was not worth it for me and rationally, probably not worth it for most.
If you deployed Go in production, I'd love reading about that since I'm having a closer look at it now (coming from Ruby). Is there a more widely used option currently?
Looking at the source, and having looked at how nginx does it, this looks like a pretty straightforward implementation with no real frills. I imagine anyone doing this in production with Go already has just rolled their own solution not much unlike this (doing this for some pet projects of mine has been on my TODO for a few weeks, never got around to it though).
Unless you are a committer to Ruby now, or plan to invest in learning more powerful languages, Go probably isn't a good choice. I run a pure Go shop and we generally look for people with hardcore C (not C++ or C#) or systems/kernel backgrounds or at least one open source Go library under their belt.
If you're just looking for another language to get away from the cesspit that is Ruby, try Python.
I built something similar which additionally provides graceful termination of established connections as well as systemd socket activation to (optionally) provide lazy startup of servers: https://github.com/daaku/go.grace
The documentation is very light so I had a look through the source code. Is the purpose of this to remotely restart a go app (that presumably has been updated and deployed) via TCP whilst keeping the TCP connection alive, or is there more to it?
There appear to be some philosophical differences that mean this won't occur.
Specifically the "let it fail" aspect of OTP, which begets supervisor hierarchies and the consequent lack of exception handling required.
This has been brought up before and dismissed (not the unix way perhaps? I forget), and supervisors have been implemented in go by others from Erlang backgrounds. It's just not quite the same as being built in.
The way goroutines are not linked to their parents or children is related to this. It's a conscious design decision, but I am still adjusting my style to it.
[+] [-] lbarrow|13 years ago|reply
So while you'll have uninterrupted connectivity, if you don't ensure that your server shuts down gracefully, you'll still drop the requests that the old process is servicing when the restart is triggered. We wrote a library called manners for managing the graceful shutdown of a single server: https://github.com/braintree/manners. When used in conjunction with manners, GoAgain provides zero-downtime restarts without any dropped requests.
(Manners is still under development, so make sure you understand it before using it.)
We had an interesting experience with Go. We ended up deciding the language was not a great fit for our needs right now, in part because the community is still pretty immature. (You can read about our experiences here: https://braintreepayments.com/braintrust/gotchas-irritants-a...).
Still -- as more and more libraries like this get released and stabilized, Go will become an increasingly interesting option for developers.
[+] [-] mortdeus|13 years ago|reply
Go is a very young programming language and unfortunately there are alot of cases where we have to implement pkg foo, bar, baz, because pkg quux depends on them. There are going to be many places where things break at this stage in Go's life, however that shouldnt discourage using Go for real world projects, because many of yesterday's bug end up being debugged and patched today. Go is a great investment for your company, and I hope you and your team reconsider using go for your projects after go 1.1 comes out. http://tip.golang.org/doc/go1.1
If you guys need help, feel free to join us in #go-nuts on freenode's irc server. IMHO, The best feature of go is, arguably, the helpful evangelist-like gopher community hanging out in IRC. We wouldnt mind helping you guys with your issues, but you have to help us help you.
[+] [-] kkowalczyk|13 years ago|reply
Those are clearly not Facebook scale servers but for majority of people: you don't need this or any other such solution.
Here's what I do for deployment. I have a fabric script that:
- copies the new executable to the server - kills currently running executable - starts the new executable
The worst that can happen is that a few connections will get dropped and that's perfectly fine 99.9% of websites. You don't control internet so the users will get broken connections all the time for reasons you can't eliminate. They shrug and hit reload button.
Complicating things to avoid few seconds of downtime was not worth it for me and rationally, probably not worth it for most.
[+] [-] codexon|13 years ago|reply
[+] [-] thibaut_barrere|13 years ago|reply
[+] [-] jlgreco|13 years ago|reply
[+] [-] dsl|13 years ago|reply
If you're just looking for another language to get away from the cesspit that is Ruby, try Python.
[+] [-] daakus|13 years ago|reply
[+] [-] justinhj|13 years ago|reply
[+] [-] voidlogic|13 years ago|reply
[+] [-] davidw|13 years ago|reply
[+] [-] bwooce|13 years ago|reply
Specifically the "let it fail" aspect of OTP, which begets supervisor hierarchies and the consequent lack of exception handling required.
This has been brought up before and dismissed (not the unix way perhaps? I forget), and supervisors have been implemented in go by others from Erlang backgrounds. It's just not quite the same as being built in.
The way goroutines are not linked to their parents or children is related to this. It's a conscious design decision, but I am still adjusting my style to it.
[+] [-] mortdeus|13 years ago|reply
[+] [-] the_mitsuhiko|13 years ago|reply