Re: Continuous Deployment of Boost.Beast-based server

From: Martijn Otto (boost_at_[hidden])
Date: 2020-04-21 12:24:39

The easiest way is to simply replace the old process with the new,
improved version after stopping the listener for the old process.

The io_context is kept alive by handlers registered. Initially, this is
probably only the acceptor listening for incoming connections. Then, as
connections are established, handlers are registered for those too.
When you want to replace the process, you cancel the acceptor, so only
the existing connections keep the io_context alive.

At this point, the listener is closed and the port is free to use by
the new process. When all connections in the old process terminate, the
process then stops (because no more handlers are registered).

There is a small timeframe during which requests might fail, because
the old process stops listening and the new process is not yet
accepting connections. Depending on your platform, there are ways
around this (e.g. SO_REUSEPORT on linux).

On Tue, 2020-04-21 at 13:59 +0200, Dominique Devienne via Boost-users
wrote:
> Imagine I have a WebSocket server, implemented using Boost.Asio and
> Boost.Beast.
> 
> It's deployed and serving clients in production or test environments,
> but I
> fixed a bug, checked in a fix, passed CI, and would like to redeploy,
> but
> w/o downtime for existing clients.  New clients should use the same
> address, but be served by the newly deployed fixed server.  While
> on-ongoing WebSocket connections keep on using the old server.
> 
> Is that possible? In-process? Or one must use some kind of "front-end
> server" redirecting
> new traffic (i.e. new WebSocket session and/or HTTP requests)  to
> separate
> processes?
> (nginx? little GoLang exe? In C++ Boost.Asio based? else?)
> 
> If not possible in-process, then how to know when older server is no
> longer
> in use, to gracefully stop it?  Asio servers typically run forever,
> i.e.
> never run out of work, even when they temporarily have nothing to do,
> by
> design.
> 
> The goal is to do this on "premise" (i.e. not in the cloud), on a
> single
> machine (no containers), and cross-platform (Windows and Linux).
> 
> Thanks, --DD
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> https://lists.boost.org/mailman/listinfo.cgi/boost-users