-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Zero-downtime deployment of Chisel #36
Comments
Awesome :) It's not possible to move existing connections into a new process. Each connection has significant state which couldn't be carried forward by a different process. chisel clients perform automatic reconnects on any disconnection so a deploy strategy of replacing the chisel server's binary and performing a restart would cause chisel clients to reconnect almost instantly. However, this short chisel-to-chisel disconnection would also disconnect any user connections (e.g. SSH connections). I have thought of hiding any short chisel-to-chisel disconnections from the user, by buffering user data though this would result in complex edge cases, like, where a user program might think it has successfully transmitted data when it hasn't, and then this data is lost. Also, even if implemented, this would not work through a chisel upgrade. Happy to hear of any other ideas |
@jpillora I assume running multiple chisel servers behind a TCP load balancer wouldn't work either, would it? If hot-swapping chisel binary without bringing existing connections down is not an option, would you consider a feature that watches auth-file for changes? Just noticed that there is a feature request for this at #30 |
Yeah that sounds reasonable
…On Wed, 13 Dec 2017 at 8:22 am Vaidas Jablonskis ***@***.***> wrote:
@jpillora <https://github.com/jpillora> I assume running multiple chisel
servers behind a TCP load balancer wouldn't work either, would it?
If hot-swapping chisel binary without bringing existing connections down
is not an option, would you consider a feature that watches auth-file for
changes?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#36 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAmr8_zPUF-b8H-pLLqFaqqvFaXFB6mUks5s_u6CgaJpZM4ODZN->
.
|
@jpillora Can CRIU work here with the tcp-connection-established flag? https://criu.org/Main_Page |
i dont think auth file changes is the ask. What is needed is a way to maintain network state between two or more processes. Going back many years, Cisco have done this with things like ASA firewalls and these were connected by fast ethernet. There is a way to do this, i just need to Google more. Or can someone point me in the right direction for the design pattern? Or are there any other open source projects that have implement the sane feature? |
Would it be possible to use something like a Redis cluster to store/maintain state and share that across multiple Chisel instances? If so, building an generic option point state data to a url would be ideal - this way you can point it to various sources - Redis, MongoDB, etc. |
First off, let me begin by saying that Chisel is a brilliant little project for accomplishing a lot of useful tasks. I personally use Chisel to tunnel SSH traffic to containers and VMs.
However, this got me thinking- how do you propose to achieve zero-downtime maintenance and deployment of the chisel server? If there are existing tunnels already created and active, would it be possible to switch the connections over to the new chisel server instance?
The text was updated successfully, but these errors were encountered: