configuration reference
#3111
Replies: 2 comments
-
|
I 100% agree with you. After being asked a few questions I posted the complete config for the demo server. I will post it also below. Do you suggest we even expand on that and have a single working configuration that shows every possible config, or are you suggesting we have small examples listed for things specific to some use cases? Almost like https://examples.deno.land/ but for NATS config setups? NATS Demo Server Configuration |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Hi Derek,
sorry for the late reply. Thank you for this configuration. It's really
helpful.
A complete configuration with all options listed like this is good enough.
But if you'd like to go the extra mile, well how do you know what's a
commonly used configuration, but I think that what you wrote with the deno
examples is a very good idea.
Derek Collison ***@***.***> schrieb am Mo., 9. Mai 2022,
02:35:
… I 100% agree with you.
After being asked a few questions I posted the complete config for the
demo server. I will post it also below. Do you suggest we even expand on
that and have a single working configuration that shows every possible
config, or are you suggesting we have small examples listed for things
specific to some use cases? Almost like https://examples.deno.land/ but
for NATS config setups?
NATS Demo Server Configuration
port: 4222
https: 8222
server_name: us-central-nats-demo
max_connections: 250000
max_subscriptions: 200000
reconnect_error_reports: 3600
max_traced_msg_len: 64
logfile_size_limit: 2GB
log_file: "/var/log/nats-server.log"
jetstream {
store_dir: /var/jetstream
max_mem_store: 10GiB
max_file_store: 410GiB
}
tls {
cert_file: "/etc/letsencrypt/live/demo.nats.io/fullchain.pem"
key_file: "/etc/letsencrypt/live/demo.nats.io/privkey.pem"
timeout: "5s"
}
# Allow both TLS and non-TLS to work on same port.
allow_non_tls: true
leafnodes {
port: 7422
tls {
cert_file: "/etc/letsencrypt/live/demo.nats.io/fullchain.pem"
key_file: "/etc/letsencrypt/live/demo.nats.io/privkey.pem"
timeout: "5s"
}
}
no_auth_user: demo-user
demo_perms = {
publish = {
# Do not allow deletion of MQTT streams
deny = ["$JS.API.STREAM.DELETE.$MQTT_msgs", "$JS.API.STREAM.DELETE.$MQTT_rmsgs", "$JS.API.STREAM.DELETE.$MQTT_sess"]
}
}
accounts {
default: {
jetstream: {
max_mem: 8GiB
max_store: 400GiB
max_streams: 1024
max_consumers: 8192
}
users = [ { user: demo-user, permissions: $demo_perms} ]
}
$SYS: {
users = [ { nkey: UDEMO3ZANTMUGPSBS3H54WKJN3TNVGQBJUQFCT7H4MUQLCRRQ26CWIIP } ]
}
}
websocket {
port: 8443
compression: true
handshake_timeout: "5s"
tls {
cert_file: "/etc/letsencrypt/live/demo.nats.io/fullchain.pem"
key_file: "/etc/letsencrypt/live/demo.nats.io/privkey.pem"
timeout: "5s"
}
no_auth_user: demo-user
}
mqtt {
port: 1883
tls {
cert_file: "/etc/letsencrypt/live/demo.nats.io/fullchain.pem"
key_file: "/etc/letsencrypt/live/demo.nats.io/privkey.pem"
timeout: "5s"
}
no_auth_user: demo-user
ack_wait: "1m"
max_ack_pending: 1024
}
—
Reply to this email directly, view it on GitHub
<#3111 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AU4VVIQJASXLFC2375N2BA3VJBMUDANCNFSM5VMQVXQA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I don't like the documentation very much, because it's all over the place.
For instance I'd like to run nats-server with jetstream and also websocket.
It's all very complicated. All I wanted is to notify a user that they received a new message.
But for that I need to configure nats-server, send a JWT, configure the nats server for jwt auth and it's all too much.
For instance I have a keycloak server to manage the user credentials and generate JWT. It's an oidc server.
I would probably have to manuall extract the public keys from the
/.well-known/openid-configurationI think I might be better off not using nats and just a plain old websocket connection, be it reliable or not.
But why I made this thread, except to vent my frustration is, I'm missing a complete server configuration reference.
The whole deal in 1 place, so I don't have to jump around grey on white menu items (the readability is poop).
Also the docs could use dark mode. Working at night burns my eyes with the white background.
I liked nats (gnatsd) because it was simple and accessible.
Now it has become something not simple and rather inaccessible.
When asking about the robustness of nats-ws I receive a marketing babble response without answering my concrete question.
Nats is becoming yet another monster hidden behind heaps of text that you have to search through, wasting time or just wiggle that credit card and use the hosted service.
Sending messages, not a very complicated topic. And the clients look simple enough.
But there should be some quickstarts for certain scenarios. Using an oidc server is not unheard of (IAM for you cloudheads).
TLS is also a default.
To not waste more time: A complete configuration reference would be great to have, not this topic based thing with badly readable menu items.
Why quickstarts? Because when you're just getting into a topic your head is full of everything. You just want to solve your problem and you want to get started, now, not in 2 days when you've devoured the documentation is went back n forth of various configuration topics,which then lead to github repo text etc. All over the place. Not a good learning experience.
Beta Was this translation helpful? Give feedback.
All reactions