[erlang-questions] Deploying multiple webapps

Chandru chandrashekhar.mullaparthi@REDACTED
Thu Dec 17 11:19:02 CET 2015


On 16 December 2015 at 20:25, Hugo Mills <hugo@REDACTED> wrote:

>    Thanks for the reply.
>
> On Wed, Dec 16, 2015 at 12:17:50AM +0000, Chandru wrote:
> > On 16 December 2015 at 00:10, Hugo Mills <hugo@REDACTED> wrote:
> >> - You can have a global cowboy handler (one module which is used in all
> > your backend erlang nodes) which provides internal routing for all your
> > services. At its most basic form, routing in cowboy is redirecting
> requests
> > based on URL to a module. So you just have to make sure this module is
> > common across all your erlang nodes, regardless of how you distribute
> your
> > services across nodes.
>
>    So I make sure that I have a 'common_routing' (or whatever) module
> in each service -- do those have their own router (for the internal
> routing within each service) in each one?
>

Your common routing can be put in a separate application. So your list of
applications in your .rel file would be something like
...
cowboy
common_routing
service_1
service_2
...


>
>    I guess that's something that Loïc's work with Cowboy and RabbitMQ
> would help with.
>
> > What am I missing here?
>
>    It's probably what I'm missing...
>
>    How do I handle deploying this? I really don't want to be building
> a different release for each configuration, so how do I enable/disable
> the different services in each separate deployment? How do I make sure
> that the unused services don't run when the release is run, and don't
> have routing entries in the top-level router? (Ideally, not shipping
> the unused code at all, but if I'm building a single release, I guess
> that's not going to be possible).
>

One way is to ship the same release with all your services bundled in, but
turn services on/off based on configuration. You specify in a common
sys.config which nodes should have which services. Ship all your services
in each node, and at startup they check if they should be running on the
local node. If not, they just stay disabled. Similarly, the common_routing
application can check configuration to see which handlers should be
activated in each node.

If you don't want certain services to start at all if they are not supposed
to run on a given node, you can develop an application whose sole job is to
start other applications. It can examine the configuration and start which
ever applications are relevant to the given node. Your release file will
then have a specification such as

...
{cowboy, "cowboy_version"}
{common_routing, "common_routing_version"},
{app_loader, "app_loader_version"},
{service_1, "service_1_version", load}
{service_2, "service_2_version", load}
...

This means beam will only load the modules at startup. Your app_loader
application on startup can examine its config and start whichever services
need to be started. If you do not use the '-embedded' option to al when
starting up your node, you can even introduce new applications into the
node without restarting it. I used this in production quite successfully in
my previous role. It cut the time to introduce new services into production
drastically.

cheers,
Chandru


> > >
> > > > On 15 December 2015 at 23:41, Hugo Mills <hugo@REDACTED> wrote:
> > > >
> > > > >    I've got a collection of small services, with minimal coupling
> > > > > between the back ends of those services (orchestration is done
> mostly
> > > > > client-side). I'd like to put an HTTPS interface in front of each
> one
> > > > > -- say, with cowboy.
> > > > >
> > > > >    What I'd also like to be able to do, at least in principle, is
> > > > > deploy some arbitrary subset of those services on each machine in
> my
> > > > > (comedically-named) server farm. I'd like to be able to do this
> with
> > > > > one TLS configuration, and preferably under a single port.
> > > > >
> > > > > i.e., access my services through
> > > > >
> > > > > https://server.me/service1/...
> > > > > https://server.me/service2/...
> > > > > https://server.me/service3/...
> > > > >
> > > > >    Now, in python-land, which is largely where I come from, I'd
> set up
> > > > > Apache with mod-wsgi, and deploy each WSGI app to a specific URL
> > > > > within the same URL namespace. I'm not quite sure how to do that
> > > > > easily with erlang+cowboy, because there seems to be no easy way of
> > > > > treating a webapp as a unit within a larger server configuration. I
> > > > > keep coming to one of two approaches:
> > > > >
> > > > > 1) Write each service completely independently (as HTTP), run it
> on a
> > > > >    distinct port, and splice together the URL namespaces through a
> > > > >    reverse proxy on a "normal" web server like Apache.
> > > > >
> > > > > 2) Find some way to automatically write a top-level router for
> cowboy,
> > > > >    for each set of services that I want to deploy to a machine.
> > > > >
> > > > >    I don't much like option 1, but I like option 2 even less. I
> guess
> > > > > I could write some kind of "top-level" app that, given a bunch of
> > > > > webapp modules (via a configuration file of some kind), gets a
> router
> > > > > for each module and transforms those routers into a single router
> > > > > config. Does such a thing already exist?
> > > > >
> > > > >    It all just feels a bit awkward, and I feel like I'm missing
> > > > > something. What do other people do to put together this kind of
> setup?
> > > > >
> > > > >    Hugo.
> > > > >
> > >
>
> --
> Hugo Mills             | Beware geeks bearing GIFs
> hugo@REDACTED carfax.org.uk |
> http://carfax.org.uk/  |
> PGP: E2AB1DE4          |
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20151217/067a44b4/attachment.htm>


More information about the erlang-questions mailing list