registry逻辑解析：启动与配置加载

Docker社区中有丰富的文档介绍，registry如何使用，但对于registry内部的处理逻辑却鲜有人知。下面对于registry的代码进行了一些阅读，下文将讲述registry的一些关键逻辑。

首先，是启动过程。参照下图：

registry的启动，主要是由通用的 cmd启动 registry.go进行启动的，registry.go中会引用yaml的parser去加载confiy.yml文件（configuration.go）是配置文件schema，加载config的之后会对照schema并忽略不在schema中的配置节点。

之后，会去读系统ENV，在系统配置中读出通过docker-compose(或者命令行加入的环境变量)。会按照环境变量名称找到对应了configration，并且“覆盖”第一次读出的config配置。

**从这里可以看到docker run或者compose的配置，是会覆盖原有registry config配置的，请各位关注。

另外yaml读写有个规则，就是会将 String自动翻译成指定数据的类型。这里有的时候会让人很困惑，比如，之前鄙人就踩到一个坑，系统自动将我的一个ossbucketname：“040432”翻译成了一个八进制的数字。所以各位如何不需要使用数字，尽量不要用纯数字的表达符。

之后，被翻译成configration对象的配置，会传递到app.go的初始化过程中，对于各个component进行参数初始化。

（包括各个handler,notification endpoint,storage driver,proxy等）

app.go中包含了一个方法，叫做ServeHTTP，一看名字就是知道是做啥的了。

对于registry的所有的请求，都是有app.go去handler的，之后会传递到方法dispatcher中根据不同的请求的context进行请求分发。

dispatcher在分发前，会统一地调用authorize进行鉴权的操作，如鉴权不通过，则会通过统一错误码机制，返回统一的错误码。若通过，则会根据route.go中的配置，将指定的请求映射到对应的handler上边去。

每一个handler对应是使用的case在registry的文档上都可以看到，这里就不一一讲述了。下一章会对于，镜像上传下载场景中，所需要涉及到的handler中的逻辑进行分析。