I think we can start from the instance troubleshooting solution first, then we can consider to let management console redirect the request to the certain instance.
Willem Jiang Twitter: willemjiang Weibo: 姜宁willem On Tue, Mar 5, 2019 at 11:54 AM wjm wjm <[email protected]> wrote: > > @[email protected] <[email protected]> agree to you. > but > 1.graphical user interface is not a problem, network is a problem > browser maybe can not connect to the instance directly > 2.we must provide these features by governance console, the problem is if > we will provide it by instance also? > when provide by governance console, it's more powerful than by instance > because instance can only have self information, but governance can show > related instance's information. > > yhs0092 <[email protected]> 于2019年3月5日周二 上午11:23写道： > > > Here is just my personal consideration. It's indeed a complex problem when > > get involved in security issues. > > > > > > Once we decide this function is only provided directly by the service > > instances, users can only log into the micro-service clusters to get access > > to these informations. In such case we can assume that the security should > > be guaranteed by users themselves. > > There are still several problems: > > 1. Usually there are all Linux OS servers in a cluster, with no graphical > > user interface. It may be hard to find a browser to read the informations. > > 2. If the instances enable Mutual TLS authentication, it may be difficult > > to get access to the informations directly. Or we can provide an isolated > > port for this feature, but it makes us further away from our security goal. > > > > > > If we provide a separate console service, maybe we can solve these > > problem. The console can be split into web page and backend service. The > > backend service can be deployed into the service cluster. It can be treated > > as a common micro-service, which means the security options of it can keep > > the same as other services. The web pages, if they are static page with > > html+js, can be deployed in the edge service. If users are concerned about > > the security issues, they can add authorization by themselves. > > I think this solution is flexible, but complex for many users. > > > > > > On conclusion, I guess if this feature is provided by service instances > > directly, it is less complex for us to implement it. While it may be not so > > practical in production environment. If this feature is provided by another > > console service, it's more complex, but there are more chances to apply it > > into a production environment. > > > > > > Yours sincerely > > > > > > Yao Haishi > > [email protected] > > > > > > On 3/5/2019 10:37，wjm wjm<[email protected]> wrote： > > this feature should be for both development and production environment, so > > must conside security problem. > > currently i'm not sure what's the best way to control it. > > > > yhs0092 <[email protected]> 于2019年3月5日周二 上午10:28写道： > > > > That's a great idea! > > What is the positioning of this feature? If it's designed for development > > environment trouble-shooting, I guess it's okay the web pages are provided > > by the micro-service instances directly. But if this feature is expected to > > work in production environment, which may contains massive micro-service > > instances, maybe it's better that service instances provide RESTful > > interfaces, and users get access to these informations via the console > > service. > > > > > > Yours sincerely > > > > > > Yao Haishi > > [email protected] > > > > > > On 3/5/2019 09:52，wjm wjm<[email protected]> wrote： > > @zhang_lei > > > > ServiceComb can run with spring boot, but will not depend on spring boot. > > > > > > wjm wjm <[email protected]> 于2019年3月5日周二 上午9:49写道： > > > > href of gif: > > > > https://issues.apache.org/jira/secure/attachment/12961084/swaggerAndDocument.gif > > and more question: > > how to define the security of the new feature > > should open a new port for the feature? > > > > > > wjm wjm <[email protected]> 于2019年3月5日周二 上午9:20写道： > > > > currently it's difficult to collect internal status of a microservice > > instance when some problem happened. > > eg: > > routing depend on cached instances, discovery tree, strategy of > > governances, and so on > > when we resolving routing related problem, we can only guess the status > > of all related modules. > > > > > > so we should provide a way to inspect the internal status of a > > microservice instance at runtime, maybe include: > > discovery tree > > isolation > > eventbus > > view schemas as swagger or html/pdf...... > > ...... > > maybe like the gif: > > > > > > > > > > my question: > > provide these informations include related html/js/css by instance > > directly, or only by governance console > > if provide by both instance and governance console, that will cause > > duplicate development > > > > if provide by instance > > what's the name of the module? "inspector"? > > swagger to html depend on "asciidoctor", which depend on jruby, it's very > > heavy. > > in my demo, resource of swagger and asciidoctor all load from cdn, but for > > some customer's environment, maybe can not connect to internet. > > any other idea? > >
