-
-
Notifications
You must be signed in to change notification settings - Fork 593
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Centrifugo v6 roadmap #832
Comments
During last two weeks I was working on Centrifugo v6. The focus in v6 is configuration refactoring - make it unified, structured, more explicit. In the current state it's becoming very hard to maintain and add new features – so as part of Centrifugo v6 implementing the configuration framework which is simple to read and extend in the code. Also, I want to provide a unified way to set secrets for all entities inside arrays - like inside list of proxies, list of consumers configuration. And a unified config key validation (shown now as warnings on Centrifugo v5 start). To show one example how config will change, this is what we could have in Centrifugo v5 now: {
"token_hmac_secret_key": "XXX",
"admin_password": "XXX",
"admin_secret": "XXX",
"api_key": "XXX",
"allowed_origins": ["http://localhost:3000"],
"presence": true,
"namespaces": [
{"name": "ns", "presence": true}
]
} In Centrifugo v6 becomes: {
"client": {
"token": {
"hmac_secret_key": "XXX"
},
"allowed_origins": [
"http://localhost:3000"
]
},
"admin": {
"password": "XXX",
"secret": "XXX"
},
"http_api": {
"key": "XXX"
},
"channel": {
"without_namespace": {
"presence": true
},
"namespaces": [
{
"name": "ns",
"presence": true
}
]
}
} Or in YAML: ---
client:
token:
hmac_secret_key: XXX
allowed_origins:
- http://localhost:3000
admin:
password: XXX
secret: XXX
http_api:
key: XXX
channel:
without_namespace:
presence: true
namespaces:
- name: ns
presence: true Only top-level structure is different, nested keys like channel options stay the same. In the code configuration will be a single readable Go struct instead of manually crafted (using viper key getters) different structs. |
Hello @FZambia! In my custom server (on top of the Centrifuge library) I use this approach to configure outgoing proxy connections. Maybe some of my ideas will seem interesting to you. Configure all outgoing connections # Outgoing connections configuration
connections:
connection-name-01: # connection name
nats: # connection type ("nats", "http" or "grpc")
# options specific for NATS connection
address:
- nats://127.0.0.1:4222
- nats://localhost
# possible credentials (or nothing if insecure connect)
jwt-token: "" # priority 0 (if enabled)
nkey: "" # priority 1 (if enabled) only for NATS
user: "" # priority 2 (if enabled)
password: ""
token: "" # priority 3 (if enabled) only fo NATS
# TLS configuration (if enabled)
tls:
cert: "" # path to cert file
key: ""
insecure-skip-verify: false
server-name: ""
# other TLS options ...
connection-name-02:
grpc:
# options specific for gRPC connection
url: grpc://127.0.0.1:12000
credentials-key: authorization
credentials-value: qwerty
# any other options ...
tls:
# TLS options ...
connection-name-03:
http:
# options specific for HTTP connection
url: https://127.0.0.1:8443
user: alex
password: qwerty
# any other options ... Organize connections to pools # Proxy connections pool configuration
proxies:
dev-proxy: # proxy pool name
timeout: "15s" # default timeout 5s (if not set)
connections:
connection-name-01:
endpoint: dev # for NATS or gRPC it means subject "dev.<method>", may be empty
priority: 1 # default 0, maximum 255 (uint8), if all priorites equivalent it means "roundrobin"
timeout: "2s" # overwirte default timeout, if no respond after timeout, call next priority connector
connection-name-03:
endpoint: api/dev/proxy # for HTTP it means "<addr>/api/dev/proxy/<method>", may be empty
priority: 2
headers:
- Cookie
prod-proxy:
connections:
connection-name-01:
endpoint: v1
connection-name-03:
endpoint: api/v1/proxy Define default proxy settings # Default proxy settings
defaults:
proxy: # map calls to proxy from poll
connect: prod-proxy
refresh: prod-proxy
rpc: dev-proxy Define overrides for namespaces namespace:
personal:
history-size: 100
join-leave: true
force-join-leave: true
proxy:
publish: dev-proxy |
Thx @matsuev , I guess I found a couple of ideas from your conf to consider:
But need to stop at some point and find good balance between changes and user difficulties during v5->v6 config migrations. |
Another feature of Centrifugo v6 - possibility to get the configuration file with all defaults for all all available configuration options. It will be possible using the command like:
Also, in dry-run mode it will be posted to STDOUT instead of file:
Finally, it's possible to provide this command a base configuration file - so the result will inherit option values from base file and will extend it with defaults for everything else:
|
One more feature of Centrifugo v6 – possibility to use separate Redis configurations for broker functionality and for presence management. |
Attaching example of full JSON file with default configuration values using the command:
|
In addition to ❯ ./centrifugo defaultenv
CENTRIFUGO_ADDRESS=""
CENTRIFUGO_ADMIN_ENABLED=false
CENTRIFUGO_ADMIN_EXTERNAL=false
CENTRIFUGO_ADMIN_HANDLER_PREFIX=""
CENTRIFUGO_ADMIN_INSECURE=false
CENTRIFUGO_ADMIN_PASSWORD=""
CENTRIFUGO_ADMIN_SECRET=""
... Which prints all config options as environment vars with default values to STDOUT. It also supports base config file to inherit values from: ./centrifugo defaultenv -b config.json |
This is an issue to collect information about Centrifugo v6 in one place. There is no date for the release defined yet. This post will be updated.
The text was updated successfully, but these errors were encountered: