Closed makefriend8 closed 1 year ago
https://json.schemastore.org/github-workflow.json
One advantage of using yml is that it provides prompts while writing, making it suitable for configuration files.
It is more beginner-friendly and can be assisted by IDE for configuration.
TRANS_BY_GPT3
After supporting YAML or JSON, it is more convenient for JavaScript to read and write, making it easier to create management systems.
Configuration files are essentially APIs for the system, and it is best if they can be accessed by JavaScript. In essence, HTTP APIs are also the same.
Therefore, supporting this feature is very beneficial for usability.
Since this feature doubles the maintenance workload, with both conf and yaml/json configurations, the work for reload and utest also doubles. Therefore, we need to consider whether to support yaml or json, and can only choose one.
TRANS_BY_GPT3
I found the configuration file for NGINX is not good, with two issues:
The format is conf, which is not as easily parsed as yaml.
It is only possible to start the container through a file, which can be cumbersome.
Actually, YAML cannot solve the second problem either. On the contrary, Redis is very good at it. It is all simple key-value configuration, for example:
# Accept connections on the specified port, default is 6379 (IANA #815344).
# If port 0 is specified Redis will not listen on a TCP socket.
port 6379
This is the configuration file, and it can also be specified through the command line:
redis-server /etc/redis.conf --port 16379
For containers, command line parameters or environment variables are more user-friendly. Configuration files like conf and yaml are not ideal.
Refer to the Redis Configuration documentation for more information.
Usage: ./redis-server [/path/to/redis.conf] [options]
./redis-server - (read config from stdin)
./redis-server -v or --version
./redis-server -h or --help
./redis-server --test-memory <megabytes>
Examples:
./redis-server (run the server with default conf)
./redis-server /etc/redis/6379.conf
./redis-server --port 7777
./redis-server --port 7777 --replicaof 127.0.0.1 8888
./redis-server /etc/myredis.conf --loglevel verbose
Sentinel mode:
./redis-server /etc/sentinel.conf --sentinel
In other words, we should actually support the Redis approach rather than YAML, for example:
./objs/srs -c conf/srs.conf --listen 19350 --hls.enabled on
We can ignore vhost because it's too troublesome. We only need to support the configuration of the default vhost. This way, when starting the SRS container, it will be very convenient to specify these parameters and very user-friendly.
TRANS_BY_GPT3
What was said earlier is incorrect. The best way to configure Grafana is through environment variables. The new configuration for SRS will also support overriding through environment variables, which is ideal for cloud-native environments.
For example, to start Grafana:
docker run --rm -it --name grafana \
--env GF_SECURITY_ADMIN_USER=admin \
--env GF_SECURITY_ADMIN_PASSWORD=12345678 \
--env GF_DATABASE_TYPE=mysql \
--env GF_DATABASE_HOST=host.docker.internal:3306 \
--env GF_DATABASE_NAME=grafana \
--env GF_DATABASE_USER=root \
--env GF_DATABASE_PASSWORD= \
--env GF_INSTALL_PLUGINS=tencentcloud-monitor-app \
-p 3000:3000 \
grafana/grafana
Using the local MySQL, install a plugin and specify all settings through environment variables. This makes it very convenient to start in K8s or similar Docker environments.
TRANS_BY_GPT3
Have you considered switching the configuration file of srs to YAML? After all, the configuration file may need to be read and parsed by many files. Using a common structure would make it easier for various programming languages to directly use libraries for reading and writing.
Consider the following scenario: srs needs to read configuration items from other configuration files, or other components need to read configuration items from srs.
By default, k8s uses the YAML format, and Spring also supports YAML format. From a business perspective, YAML is a widely used configuration file format, especially within Docker environments.
For comparisons, you can refer to the wiki page: https://en.wikipedia.org/wiki/YAML#Comparison_with_JSON
For design objectives, you can refer to: https://yaml.org/spec/1.2/spec.html#id2708649
Of course, the spacing issue in YAML must be handled with the help of tools, otherwise the readability will be compromised.
TRANS_BY_GPT3