Skip to content
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

Open
FZambia opened this issue Jun 16, 2024 · 3 comments
Open

Centrifugo v6 roadmap #832

FZambia opened this issue Jun 16, 2024 · 3 comments

Comments

@FZambia
Copy link
Member

FZambia commented Jun 16, 2024

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.

  1. Remove SockJS transport - [feature removal] Remove SockJS transport #765
  2. Remove Tarantool engine - [feature removal] Remove experimental Tarantool engine  #830
  3. Revisit TLS configurations - [feature] Revisit TLS configurations #831
  4. Revisit configuration of arrays of objects - [feature] Possibility to use separate environment variables for options inside arrays #841
@FZambia FZambia pinned this issue Jun 16, 2024
@FZambia
Copy link
Member Author

FZambia commented Sep 18, 2024

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.

@matsuev
Copy link

matsuev commented Sep 18, 2024

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

@FZambia
Copy link
Member Author

FZambia commented Sep 18, 2024

Thx @matsuev , I guess I found a couple of ideas from your conf to consider:

  • nats url is better to be an array on Centrifugo level
  • some nats auth options can make sense – but I'll leave this for the future most probably
  • I'll try to think whether making entities like namespaces or proxies a map instead of array can be a good move, but there are considerations I have that the array fits better to not be limited in name to be a valid map key in YAML/TOML and thus not break existing configurations. Will try to check whether it's possible without breaking changes.
  • Think more on proxy configuration inside the namespace. I want to get rid of granular_proxy_mode option – and somehow combine global and granular proxy configurations to work together. So may be part of this initiative.

But need to stop at some point and find good balance between changes and user difficulties during v5->v6 config migrations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants