- nebula 版本：v2-ga
- 部署方式（分布式 / 单机 / Docker / DBaaS）：docker swarm
- 硬件信息
- 问题的具体描述
docker swarm 部署，docker-stack.yaml直接改的v1的例子，meta/storage/graph的port依然是45500，44500，3699，只把image换成了v2
有以下几个问题：
- 在初次启动时，是否有用到.conf文件？docker-stack.yaml和conf文件里的参数值完全不一样
docker-stack.yaml:
nebula-storaged.conf:
-
将其改为–local_config=true后，是否需要调整为与docker-stack.yaml里的参数值一致？
-
将要在实验用的服务器上装两块ssd作为数据盘，请问要如何更改配置文件中的–data_path参数？
这里的data_path是容器内的路径还是宿主机目录？/disk1/path, /disk2/path 该怎么改？
我的理解是在编写docker-stack.yaml时，
storaged的volume:
- [宿主机目录1]：/data/storage
- [宿主机目录2]：/data/storage
[宿主机目录]为ssd的mount point的绝对路径(相对路径会自动挂到系统盘/var/lib/docker/volumes/ 下), 假设两块ssd挂载点不一样.
nebula-storaged.conf: --data_path仍为默认值data/storage
- 会用到 conf 文件，docker-stack.yaml 里的配置，会覆盖 conf。
- 哪个文件的 –local_config？
- nebula-storaged.conf 为两个地址 --data_path=/data/storage1,/data/storage2， 然后在 volume 配置：
- [宿主机目录1]：/data/storage1
- [宿主机目录2]：/data/storage2
只会覆盖不会overwrite conf文件对么。所以针对第二个问题，设置local_config=true后需要根据docker-stack.yaml来改conf文件
storaged的配置文件
可能我没说明白，覆盖某个 key
比如你的 conf 是 local_config=false，然后 docker-stack.yaml 里 local_config=true。
那实际启动后，是 true 的配置。但是你进入到容器里，看到的 local_config 文件还是 false。
其实是相当于
bin/nebula-storaged --flagfile xxx/nebula-storaged.conf --local_config=true
覆盖某个key的问题我已经理解了，谢谢。
不好意思，我之前也没有说明白。
我是打算修改配置文件commit成新的image。在配置文件中加入–local-conf=true，把ip之类的的所有参数都改好。
比如，我已经生成了新的镜像nebula-storaged:local-conf
在新的docker-stack.yml里：
image：nebula-storaged:local-conf
env_file:
- ./nebula.env
command:
<由于已经改了conf，这里可以不写参数值了>
请问我这个操作是合理的吗
不太合理，这样以为这如果升级的话，你每次都要重新编译镜像，或者哪天换了其他机器，你也要更新镜像。
比较合理的是，你镜像就用官方的，然后把配置写在 docker-stack.yml，或者把配置写成一个文件，然后 挂到容器里。
这种方法要如何指定以该文件作为启动时的配置文件呢？
假设外部文件挂到/usr/local/nebula/etc/目录下,外部文件叫nebula-storaged.conf.local
在docker-stack.yml中的command: -bin/nebula-storaged --flagfile etc/nebula-storaged.conf.local这样吗？
可以直接挂成 nebula-storaged.conf 不需要 nebula-storaged.conf.local 的呀
docekrfile 里写好了 ENTRYPOINT，如果指定 nebula-storaged.conf.local 要改 enterpoint ，不是特别好
我将外部文件夹挂到etc目录
storaged0:
image: vesoft/nebula-storaged:v2-nightly
env_file:
- ./nebula.env
# command:
# - --meta_server_addrs=192.168.5.100:45500
# - --local_ip=192.168.5.100
# - --ws_ip=192.168.5.100
# - --port=44500
# - --ws_http_port=12000
# - --data_path=/data/storage
# - --log_dir=/logs
# - --v=0
# - --minloglevel=0
deploy:
replicas: 1
restart_policy:
condition: on-failure
placement:
constraints:
- node.hostname == java-env
depends_on:
- metad0
healthcheck:
test: ["CMD", "curl", "-f", "http://192.168.5.100:12000/status"]
interval: 30s
timeout: 10s
retries: 3
start_period: 20s
ports:
- target: 12000
published: 12000
protocol: tcp
mode: host
- target: 12002
published: 12002
protocol: tcp
mode: host
volumes:
- data-storaged0:/data/storage
- logs-storaged0:/logs
- config-file:/usr/local/nebula/etc
networks:
- nebula-net
这是已经修改好的conf （特地将民loglevel改为2，以便后面通过show configs验证是否生效）
启动后容器内看到的conf文件
在console中查看，发现minloglevel依旧是0
你看到容器内的 conf 文件是 minloglevel=2 了，说明已经改成功了。
- 如果你设置了 local_config, 那这台 storage 的日志级别就是你设置的 2
- 如果你没设置，那还是用的 meta 里的默认。
不管你那种方式，show configs 看到的就是 meta 的级别，是不会显示 2 的，除非用 update configs 来改。
如果你只是想验证 conf 的配置生效没，可以换一个 --log_dir 的路径，然后验证好了以后，再改回来。（其实你这个配置文件已经是改成功了的，只是 log 级别和 show configs 这个地方不太友好）
