以core data服务为例:
- ./core-data使用本地找到的默认配置文件启动服务
- ./core-data——profile=docker使用本地找到的docker配置文件启动服务
填充配置
在使用注册为EdgeX Foundry微服务提供集中配置管理时，需要在启动服务之前对所需配置进行填充。这是config-seed服务的职责。config-seed服务将假设正在使用服务注册中心，并且必要的端点包含在本地配置文件中。config-seed服务以与上面描述相同的方式支持配置文件的使用。
例如，如果我们想用docker相关的配置信息来填充注册，我们可以在启动注册后执行以下操作:
- ./config-seed --profile=docker
假设运行成功，config-seed将填充必要的值，然后退出。为了让服务现在从注册表加载配置，我们必须使用以下标志之一:
再以core data服务为例:
- ./core-data --registry --profile=docker
./core-data—registry—profile=docker将使用注册中找到的配置值启动服务
注意，在使用注册时，如果您使用的配置文件不是默认的，还可以选择指定——profile / -p标志。这是因为注册表的位置仍然必须从本地配置文件中获得。此时，不支持一次使用多个概要文件。
配置结构：
配置信息被组织到分层结构中，以支持服务的逻辑分组以及版本控制，位于配置树的根级别的“edgex”名称空间之下。根命名空间将EdgeX foundry相关的配置信息与可能使用同一注册表的其他应用程序分隔开来。在根节点之下，子节点有助于分组设备服务、EdgeX核心服务、安全服务等。例如，查看配置注册表时显示的顶级节点可能如下所示:
- edgex (root namespace)
- core (edgex core services)
- devices (device services)
- security (security services)
将版本控制合并到配置层次结构中如下所示。
- edgex (root namespace)
- core (edgex core services)
- 1.0
- edgex-core-command
- edgex-core-data
- edgex-core-metadata
- 2.0
- devices (device services)
所示版本对应于给定服务的主要版本。这些并不一定等同于长期支持(LTS)版本。对于与主版本相关联的所有小版本/补丁版本，在配置中各自的服务密钥都位于主版本之下(如1.0)。在相关联的小型版本开发周期中可能需要对配置结构进行的更改只能是附加的。也就是说，一旦在主版本中设置了键名，就不会删除或更改键名，配置树的部分也不会从一个地方移动到另一个地方。通过这种方式，可以保持主版本生存期的向后兼容性。
将所有小版本/补丁版本分组到主版本下的一个好处是，终端用户配置更改需要在升级期间保持不变。除非明确告知，否则config-seed在运行时不会覆盖现有的键。因此，如果用户在EdgeX Foundry升级期间保持他们的配置注册表运行，那么只有支持point release所需的新密钥将被添加到他们的配置中，从而保留任何自定义。
可读vs可写设置
在给定的服务配置中，有一些键值可以被编辑并在服务运行时改变服务的行为，而不是那些有效地只读的键值。这些可写设置在给定的服务键下分组。例如，edgex-core-data的顶级分组是
- /edgex/core/1.0/edgex-core-data/Clients
- /edgex/core/1.0/edgex-core-data/Databases
- /edgex/core /1.0/edgex-core-data/Logging
- /edgex/core/1.0/edgex-core-data/MessageQueue
- /edgex/core/1.0/edgex-core-data/Registry
- /edgex/core/1.0/edgex-core-data/Service
- /edgex/core/1.0/edgex-core-data/Writable
在上述可写部分中发现的任何配置设置都可能被更改，并影响服务的行为，而无需重新启动。对其他设置的任何修改都需要重新启动。
注册
注册中心指的是您可以用于服务发现和集中配置管理的任何平台。对于EdgeX Foundry参考实现，这两种职责的默认提供者都是HashiCorp的Consul。与注册中心的集成是通过所有服务引用的go-mod-registry模块来处理的。
注册简介
注册中心的目标是使微服务能够查找并相互通信。当每个微服务启动时，它向注册中心注册自己，注册中心通过指定的运行状况检查端点继续定期检查其可用性。当一个微服务需要连接到另一个微服务时，它会连接到注册中心以检索目标微服务的可用主机名和端口号，然后调用目标微服务。下图显示了基本流程。
Consul是缺省注册中心实现，并提供服务注册、服务发现和运行状况检查的本机特性。请参阅领事官方网站了解更多信息:
https://www.consul.io
从物理上讲，“registry”和“configuration”管理服务组合在一起，并在同一个Consul服务器节点上运行。
Web User Interface
Consul还提供了一个web用户界面。用户可以通过web用户界面查看可用的服务列表及其运行状况。web用户界面在与HTTP API相同端口的/ui路径上可用。默认情况下是http://localhost:8500/ui。详情请参阅:
https://www.consul.io/intro/getting-started/ui.html
Running on Docker
为了便于安装和更新，EdgeX Foundry的微服务也以Docker镜像的形式发布到Docker Hub，包括Registry:
https://hub.docker.com/r/edgexfoundry/docker-core-consul/
Docker引擎准备好后，用户可以通过Docker pull命令下载最新的Consul镜像:
- docker pull edgexfoundry/docker-core-consul
然后，启动Consul使用Docker容器通过Docker run命令:
- docker run -p 8400:8400 -p 8500:8500 -p 8600:8600 –name edgex-core-consul –hostname edgex-core-consul -d edgexfoundry/docker-core-consul
$ docker login
- A Docker network is needed to enable one Docker container to communicate with another. This is preferred over use of –links that establishes a client-server relationship:
$ docker network create edgex-network
- Create a Docker volume container for EdgeX Foundry:
$ docker run -it –name edgex-files –net=edgex-network -v /data/db -v /edgex/logs -v /consul/config -v /consul/data -d edgexfoundry/docker-edgex-volume
- Create the Consul container:
$ docker run -p 8400:8400 -p 8500:8500 -p 8600:8600 –name edgex-core-consul –hostname edgex-core-consul –net=edgex-network –volumes-from edgex-files -d edgexfoundry/docker-core-consul
在本地机器上运行：要在本地机器上运行Consul，需要以下步骤:
$ consul agent -data-dir ${DATA_FOLDER} -ui -advertise 127.0.0.1 -server -bootstrap-expect 1
${DATA_FOLDER} could be any folder to put the data files of Consul, and it needs the read/write permission.
楼主
