一段分析调用机制的旅程。
引言
深更半夜一位道上的朋友突然微信问我，Rancher Server内Cattle之外的服务如何调用Rancher API。 调用API本身没问题，但是Rancher API是需要授权访问的， 也就是说Rancher Server内其他服务如何授权访问API，这个机制是什么样的？ Rancher Server内有很多服务，如catalog、go-machine-service、websocket-proxy等等， 本文就以go-machine-service为例说明其授权机制。
以go-machine-service为例
首先我们要了解go-machine-service在做什么事，官方文档里很清楚的描述到， 它实现了physicalhost相关事件的handler，主要包括：
- physicalhost.create - Calls machine create ….
- physicalhost.activate - Runs docker run rancher/agent …
- physicalhost.delete|purge - Calls machine delete …
而若实现这些handler，需要和rancher events打交道，
我们认为rancher events也是rancher api的一部分，
所以访问rancher events也需要和API服务一样的鉴权信息。
go-machine-service在启动之时，很明确的读取了CATTLE相关变量：
而且rancher还给go-machine-service专门创建了相应的API Key，查看DB可以得知：
进入rancher-server容器内部，查看go-machine-service进程的环境变量，
可以看到API Key的授权信息就在其中：
那么go-machine-service的环境变量是如何设置的呢？查看Cattle源码，找到MachineLancher，
它是启动go-machine-service服务的具体实现，我们可以看到设置环境变量这一步：
总结
Cattle本身就是一个框架，Rancher Server内的其他服务都是通过Cattle的Proxy机制来转发请求的， 授权机制则是由Cattle统一提供出来，其他服务自身无需单独实现授权机制。 如果我们想对Rancher Server扩展，再增加一些其他服务，利用本文所描述的机制，就会非常方便。