Oliver Nicholas created MESOS-2856:
--------------------------------------
Summary: fully functional webui requires all masters+slaves to be
routable by browser
Key: MESOS-2856
URL: https://issues.apache.org/jira/browse/MESOS-2856
Project: Mesos
Issue Type: Bug
Reporter: Oliver Nicholas
Assignee: Oliver Nicholas
The core issue is that the Mesos web UI doesn't play well behind a proxy. This
is closely related to MESOS-1822, but I propose a different mechanism to
resolve it.
The mesos webui expects that it can both:
# redirect your browser to the {{--hostname}} registered for another master if
the master you're currently hitting isn't the leader (this is MESOS-1822)
# redirect you directly to the {{--hostname}} of any slave (eg/ to look at
sandbox logs)
But I don't want that to be possible really - fundamentally, mesos-master's
webui is not appropriate for direct exposure to the Internet; in many
enterprise cases it's not appropriate for wide exposure on a VPN either. It
has no access controls. And those machines shouldn't really have public IPs or
DNS entries anyway.
The way I want to resolve this for my enterprise is to have a _single_ hostname
(as in URL component, not literally unix host), with public DNS that can handle
the entire webui experience (aside: the vhost this hits has a authentication
middleware to handle the access control part). In my case, the vhost is load
balanced randomly across the mesos master quorum machines, and some slightly
complex nginx rules allow it to effectively proxy any request to the actual
leader master regardless of where the request goes. This works nicely.
However, the mesos webui also attempts to route directly to slave machines
with JSONP requests (eg/ as i mentioned above, to load the sandbox stdout for a
task). My slave machines don't even have public IPs.
Given this existing code for generating the parameters for URLs to slaves:
{code:javascript}
var pid = $scope.slaves[$routeParams.slave_id].pid;
var hostname = $scope.slaves[$routeParams.slave_id].hostname;
var id = pid.substring(0, pid.indexOf('@'));
var host = hostname + ":" + pid.substring(pid.lastIndexOf(':') + 1);
{code}
I'd like to implement a {{--enable-webui-proxy-urls}} option on the master that
would change behavior in the webui from generating a slave URL as:
{code:javascript}
var url = '//' + host + '/files/browse.json?jsonp=JSON_CALLBACK';
{code}
to instead generate the URL as:
{code:javascript}
var url = '/proxy?host=' + encodeURIComponent(host) + '&orig='
encodeURIComponent('/files/browse.json?jsonp=JSON_CALLBACK');
{code}
and then nginx can take care of rewriting/reissuing the request and proxying
the results back to the browser.
All of this could be obviated and probably made more elegant by implementing
MESOS-2130/MESOS-2131 but..this seems like a simple change to make. Any
thoughts?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
