nats-docker

nats-docker copied to clipboard

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.

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?

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

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  

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

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.

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

@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.

@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

-e NATS_ARGS="-js"

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