nats.docs/jetstream/multi-tenancy/resource_management.md

Multi Tenancy and Resource Management

JetStream is compatible with NATS 2.0 Multi Tenancy using Accounts. A JetStream enabled server supports creating fully isolated JetStream environments for different accounts.

To enable JetStream in a server we have to configure it at the top level first:

jetstream: enabled

This will dynamically determine the available resources. It's recommended that you set specific limits though:

jetstream {
    store_dir: /data/jetstream
    max_mem: 1G
    max_file: 100G
}

At this point JetStream will be enabled and if you have a server that does not have accounts enabled all users in the server would have access to JetStream

jetstream {
    store_dir: /data/jetstream
    max_mem: 1G
    max_file: 100G
}

accounts {
    HR: {
        jetstream: enabled
    }
}

Here the HR account would have access to all the resources configured on the server, we can restrict it:

jetstream {
    store_dir: /data/jetstream
    max_mem: 1G
    max_file: 100G
}

accounts {
    HR: {
        jetstream {
            max_mem: 512M
            max_file: 1G
            max_streams: 10
            max_consumers: 100
        }
    }
}

Now the HR account it limited in various dimensions.

If you try to configure JetStream for an account without enabling it globally you'll get a warning and the account designated as System cannot have JetStream enabled.

nats CLI

As part of the JetStream efforts a new nats CLI is being developed to act as a single point of access to the NATS eco system.

This CLI has been seen throughout the guide, it's available in the Docker containers today and downloadable on the Releases page.

Configuration Contexts

The CLI has a number of environment configuration settings - where your NATS server is, credentials, TLS keys and more:

$ nats --help
...
  -s, --server=NATS_URL         NATS servers
      --user=NATS_USER          Username of Token
      --password=NATS_PASSWORD  Password
      --creds=NATS_CREDS        User credentials
      --nkey=NATS_NKEY          User NKEY
      --tlscert=NATS_CERT       TLS public certificate
      --tlskey=NATS_KEY         TLS private key
      --tlsca=NATS_CA           TLS certificate authority chain
      --timeout=NATS_TIMEOUT    Time to wait on responses from NATS
      --context=CONTEXT         NATS Configuration Context to use for access
...

You can set these using the CLI flag, the environmet variable - like NATS_URL - or using our context feature.

A context is a named configuration that stores all these settings, you can switch between access configurations and designate a default.

Creating one is easy, just specify the same settings to the nats context save

$ nats context save example --server nats://nats.example.net:4222 --description 'Example.Net Server'
$ nats context save local --server nats://localhost:4222 --description 'Local Host' --select 
$ nats context ls
Known contexts:

   example             Example.Net Server
   local*              Local Host

We passed --select to the local one meaning it will be the default when nothing is set.

$ nats rtt
nats://localhost:4222:

   nats://127.0.0.1:4222: 245.115µs
       nats://[::1]:4222: 390.239µs

$ nats rtt --context example
nats://nats.example.net:4222:

   nats://192.0.2.10:4222: 41.560815ms
   nats://192.0.2.11:4222: 41.486609ms
   nats://192.0.2.12:4222: 41.178009ms

The nats context select command can be used to set the default context.

All nats commands are context aware and the nats context command has various commands to view, edit and remove contexts.

Server URLs and Credential paths can be resolved via the nsc command by specifying an url, for example to find user new within the orders account of the acme operator you can use this:

$ nats context save example --description 'Example.Net Server' --nsc nsc://acme/orders/new

The server list and credentials path will now be resolved via nsc, if these are specifically set in the context, the specific context configuration will take precedence.