Re: [DISCUSS] PIP-1 Pulsar proxy component

[Dave Fisher <da...@comcast.net>]

> On Jun 30, 2017, at 4:39 PM, Matteo Merli <ma...@gmail.com> wrote:
> 
> On Fri, Jun 30, 2017 at 12:41 PM, Dave Fisher <da...@comcast.net> wrote:
> 
>> So I am clear the problem is having an SSL endpoint that authenticates the
>> client and allows the messages to flow through to the correct broker.
>> 
> 
> 
> The main problem this proposal is trying to solve is how to expose Pulsar,
> which is a stateful service [1], through a stateless frontend.

One thought is make the proxy into a WebSocket frontend but then pass through to the broker using the TCP protocol.

WebSocket would fit a pattern that everyone is used to scaling. It could be setup through Tomcat with connections through a VIP.

Think about it.

> The reason to have a stateless frontend, is that it's much easier to give
> access to this service from outside the current cluster/datacenter. If you
> have a stateless service, you can easily use multiple strategies (VIP, DNS,
> ....) to expose multiple instances that are composing the service and you
> don't need to connect to specific nodes. Any node, as routed by the
> VIP/DNS/.. mechanism will work.
> 
> One example of this is when deploying in a cloud environment, especially
> with some container orchestration mechanism like kubernetes. If you want to
> connect and publish messages from outside the Kubernetes cluster (or from
> outside the cloud region alltogether), having the stateless service,
> exposed to a cloud specific load balancer, makes it a lot easier to deploy
> and to control the access from the outside world.

Yes and this could work with WebSocket.

> 
> For the SSL part, right now in Pulsar you might want to use TLS/SSL for few
> reasons:
> 1. Transport encryption
> 2. Broker authentication (validate the broker we're talking to is
> legitimate)
> 3. Client authentication (extract the client principal to be used for
> authorization)
> 
> All these 3 should continue to work even when a proxy is introduced. In
> particular, for the client authentication, the proxy is responsible of
> validating the authentication and then carry the client principal over to
> the broker.
> 
> 
>>> Can I assume that if the broker disconnects that the requirement is for
> the client to reconnect and then at that point get the new broker?
> 
> Correct, that's the behavior of the client library and it will not change.
> Whenever the connection breaks, the client library internally tries to
> re-do the topic lookup (because now it might have moved to a different
> broker) and reconnect, with exponential backoff, until it succeeds.
> 
> 
> [1]  brokers don't keep state on disk, but still a topic is only assign to
> a single broker at a give point in time.
> 

Great.

Regards,
Dave

> 
> --
> Matteo Merli
> <ma...@gmail.com>

Re: [DISCUSS] PIP-1 Pulsar proxy component

[Matteo Merli <ma...@gmail.com>]

On Fri, Jun 30, 2017 at 5:09 PM, Dave Fisher <da...@comcast.net> wrote:

> One thought is make the proxy into a WebSocket frontend but then pass
> through to the broker using the TCP protocol.
>
> WebSocket would fit a pattern that everyone is used to scaling. It could
> be setup through Tomcat with connections through a VIP.
>

The problem is still related to the stateful nature of the brokers (a topic
is only served at a particular point in time), so the VIP cannot just route
to any random broker.
So, even if we change the client to always connect through the WebSocket
service, it would still need some way to indicate which broker it needs to
connect to.

Side note: Pulsar already provides a WebSocket service, and that is used to
expose an "easier" interface that you can use from whatever language. The
problem is that it's not meant to be super-performant (the exchanges
between client and server happen in JSON and the payloads are serialized in
base64..


Matteo


--
Matteo Merli
<ma...@gmail.com>

Re: [DISCUSS] PIP-1 Pulsar proxy component

[Matteo Merli <ma...@gmail.com>]

I have updated the Wiki page with a section about TLS :
https://github.com/apache/incubator-pulsar/wiki/PIP-1#tls-encryption-and-authentication

Also, I just posted a PR with the implementation:

https://github.com/apache/incubator-pulsar/pull/548



--
Matteo Merli
<ma...@gmail.com>

On Fri, Jun 30, 2017 at 5:09 PM, Dave Fisher <da...@comcast.net> wrote:

>
> > On Jun 30, 2017, at 4:39 PM, Matteo Merli <ma...@gmail.com>
> wrote:
> >
> > On Fri, Jun 30, 2017 at 12:41 PM, Dave Fisher <da...@comcast.net>
> wrote:
> >
> >> So I am clear the problem is having an SSL endpoint that authenticates
> the
> >> client and allows the messages to flow through to the correct broker.
> >>
> >
> >
> > The main problem this proposal is trying to solve is how to expose
> Pulsar,
> > which is a stateful service [1], through a stateless frontend.
>
> One thought is make the proxy into a WebSocket frontend but then pass
> through to the broker using the TCP protocol.
>
> WebSocket would fit a pattern that everyone is used to scaling. It could
> be setup through Tomcat with connections through a VIP.
>
> Think about it.
>
> > The reason to have a stateless frontend, is that it's much easier to give
> > access to this service from outside the current cluster/datacenter. If
> you
> > have a stateless service, you can easily use multiple strategies (VIP,
> DNS,
> > ....) to expose multiple instances that are composing the service and you
> > don't need to connect to specific nodes. Any node, as routed by the
> > VIP/DNS/.. mechanism will work.
> >
> > One example of this is when deploying in a cloud environment, especially
> > with some container orchestration mechanism like kubernetes. If you want
> to
> > connect and publish messages from outside the Kubernetes cluster (or from
> > outside the cloud region alltogether), having the stateless service,
> > exposed to a cloud specific load balancer, makes it a lot easier to
> deploy
> > and to control the access from the outside world.
>
> Yes and this could work with WebSocket.
>
> >
> > For the SSL part, right now in Pulsar you might want to use TLS/SSL for
> few
> > reasons:
> > 1. Transport encryption
> > 2. Broker authentication (validate the broker we're talking to is
> > legitimate)
> > 3. Client authentication (extract the client principal to be used for
> > authorization)
> >
> > All these 3 should continue to work even when a proxy is introduced. In
> > particular, for the client authentication, the proxy is responsible of
> > validating the authentication and then carry the client principal over to
> > the broker.
> >
> >
> >>> Can I assume that if the broker disconnects that the requirement is for
> > the client to reconnect and then at that point get the new broker?
> >
> > Correct, that's the behavior of the client library and it will not
> change.
> > Whenever the connection breaks, the client library internally tries to
> > re-do the topic lookup (because now it might have moved to a different
> > broker) and reconnect, with exponential backoff, until it succeeds.
> >
> >
> > [1]  brokers don't keep state on disk, but still a topic is only assign
> to
> > a single broker at a give point in time.
> >
>
> Great.
>
> Regards,
> Dave
>
> >
> > --
> > Matteo Merli
> > <ma...@gmail.com>
>
>