nats-io/nats-docker

default configuration file is not loaded anymore

rmoriz opened this issue · 6 comments

Hi,

I think with baa13d5#diff-d1c0d0786d1f92a5922402e9cc85ca93L31 the default config at /etc/nats/nats-server.conf got silently ignored and nats starts with the default configuration.

This is an issue as the provided config file configured http monitor by default and many readmes and tutorials assume this behaviour. This is also inconsistent with the current image readme https://github.com/docker-library/docs/tree/master/nats

I also suggest to print the configuration file in use on startup as there is no indication which config file is loaded, even when using -DVV flags.

I noticed that the Alpine image was not using the config file indeed. Note that the one from scratch does. We will fix that on the alpine one.
As for the printing of which configuration file is used, this would be in the NATS Server itself, nothing that we can do in this repo itself. I have created PR: nats-io/nats-server#1451 in the server to track this.

@kozlovic do you have an ETA for when the alpine fix will be released? We have put a temporary fix in docker file for alpine image:

We replaced:

CMD ["nats-server"]

with:

ENTRYPOINT ["nats-server"]
CMD ["--config", "/etc/nats/nats-server.conf"]

With that fix the monitoring endpoint defined in our nats-server.conf now works

Not sure if we update the docker image without an update of that NATS Server. I guess we could.
But remember that you can always pass the config or monitoring port through command line.
I could even argue that we should probably remove the config file because it was more of an example, but it defines auth for route as such:

authorization {
    user: ruser
    password: T0pS3cr3t
    timeout: 2
  }

which is not necessarily what people would use in normal deployments.

Whatever you decide, please keep the readme at https://hub.docker.com/_/nats and https://docs.nats.io/nats-server/nats_docker in sync as they assume that monitoring is enabled on port 8222

@rmoriz Understood. We will likely leave the config file, but the point is that you are not constrained to use the internal default config file. You can always pass it your own or specify some config through command line. Regardless, I believe that we should fix the Alpine docker file so that it does use the embedded config, same as the SCRATCH one.

@rmoriz @aleybovich For your information, I have tried with the entrypoint similar to yours (and our scratch), but that is not valid for official images where we have to follow some guidelines. So I have updated it (merged) and there is a PR for official images that passes test and is going to be reviewed by the Docker team. Once merged, the alpine image should be recreated.