Run JetStream without command

[Lancetnik]

Is any abilities to configure nats conatiner to run with JetStream mode without using command argument (special label, env variable, etc)?
Now I can't find any official solution to run NatsJS as a Github Action service (GHA doesn't support command attribute).
I don't wont to use or create custom image on top of the official one, suppose, should be a legal solution.

[bruth]

Hi @Lancetnik, are you saying you don't want to pass a command argument to docker run? e.g.

docker run -p 4222:4222 nats -js

If so, why?

The alternative is to create a config file and mount it at /etc/nats/nats-server.conf

docker run -p 4222:4222 -v nats.conf:/etc/nats/nats-server.conf nats

Where the config file would, at a minimum, be:

jetstream: enabled

Out of curiosity, what is the use case for running it in Github Actions?

[Lancetnik]

I am working on event-driven framework and should test a huge part of functions on a real external dependencies.
So, I have a some e2e test with real services in my CI
Decision with a config file should be what I need to do, but manipulating volumes in CI is not so comfortable too, by it is still the way.
Little note: configuration of container services via env variables is a lead practice, can't understand why NATS choose a command arguments way

[Lancetnik]

docker run -p 4222:4222 nats -js

GHA syntax pretty close to docker-compose, but there no option to setup command argument like we can do in compose

nats:
    image: nats
    command: -js
    ports:
      - 4222:4222
      - 8222:8222  

[Lancetnik]

@bruth anyway, thx for the answer. Will try to include config volume to my CI

[ripienaar]

Agree something more flexible in the container would be nice.

But there are some options as pointed out, I do it by just replacing the entry point until something better exist.

https://github.com/nats-io/jetstream-gh-action/blob/03c67127e04647dc7b0fea6ee243a3284dd87c95/.github/workflows/update.yaml#L17

As nats (and the containers) are open source you are welcome to contribute improvements.

[Lancetnik]

@ripienaar thanks, it looks better than config as a volume

[bruth]

@Lancetnik Understood regarding the env-to-config pattern for containers. It simply has not been something strongly requested, so supported was not added proactively.

A simple option would be to support -e NATS_ARGS="-js" for passing CLI options. I have seen fancier implementations where env vars map to config-file options and the container builds the config based on the passed options.

However, in the meantime, go with @ripienaar's suggestion to not deal with the volume.

[Lancetnik]

@bruth looks like you can add smth like get_env_or_default instead simple default to all of these functions to check flags from env at first here

This way we have a priority: default < env < config < command-line, that looks reasonable

[Lancetnik]

-e NATS_ARGS="-js"

Looks worse, I suppose, cuz u need to merge it with a command-line args and solve duplications