Cannot see nodes/services/any in the UI

[simongareste]

Hi,

When builder the Dockerfile and going to the inferface, I can't see anything concerning my nodes or services in the UI. When I go inside the container and try to wget my nodes for example, I receive them (wget $CONSUL_HTTP_ADDR/v1/catalog/nodes works). While I'm in the container, I can see them in consul_services.json.

Could it be because it tries to consult them directly, instead of asking the $CONSUL_HTTP_ADDR for information ?

If it still calls $CONSUL_HTTP_ADDR, then my network configuration is not the reason for this.

But then, when I try to build/launch from scratch (i.e without docker), running bundle exec consul-templaterb -c http://192.168.1.27:8500 samples/consul-ui/*.erb, the UI is still accessible, I see that the json files are filed (consul_nodes.json, consul_services.json), but I still don't see data present in the static html files of consul-ui (consul-templaterb/samples/consul-ui/consul-timeline-ui.html, built from the consul-templaterb/samples/consul-ui/consul-timeline-ui.html.erb file).

Perhaps the following errors in the browser (FF 77) console is the reason?

ReferenceError: navBarDecorator is not definedconsul-keys-ui.html:91:37
ReferenceError: fetchedResponseDecorator is not definedtypes.js:11:9

If not, could you please explain me where I missed a step?

[pierresouchay]

Hello @simongareste ,

Indeed, by default, on docker, environment variables are not exported.
As explained in https://hub.docker.com/r/discoverycriteo/consul-templaterb, you have to run it with docker with docker run --env CONSUL_HTTP_ADDR=$CONSUL_HTTP_ADDR -p 8080:80/tcp discoverycriteo/consul-templaterb in your case (since $CONSUL_HTTP_ADDR contains the server you want to reach.

The reason why it works without docker is that consul-templaterb uses by default CONSUL_HTTP_ADDR from the environment unless you use the flag -c. If the flag -c is not specified and CONSUL_HTTP_ADDR is not present either, then, it will use by default http://localhost:8500.

I am gonna check for the issues you mentioned: about navBarDecorator and fetchedResponseDecorator. (It is a plugin system we are using internally at Criteo, so, it migt be a little bit less tested). Still, is the UI correctly responding or does it breaks everything?

[pierresouchay]

@simongareste,

Indeed, thank you for you bug report: there was a bug fixed by 3a1dea9 (a missing resource containing the decorator) in the Dockerfile.

I released a new Docker version 1.26.2 - should work on your machine now.

I will work with this new version, human tested a few seconds ago!

Sorry for such lame bug (to be fair, we don't use docker for this app in our real-world deployments, that's why).

To test again:
docker pull discoverycriteo/consul-templaterb
and run again with:
docker run --env CONSUL_HTTP_ADDR=$CONSUL_HTTP_ADDR -p 8080:80/tcp discoverycriteo/consul-templaterb

Thanks a lot for the bug report and feel free to create Pull Request if you modify the templates and want your changes included in the default version.

You can also have a look at https://github.com/criteo/consul-templaterb/blob/master/samples/consul-ui/decorators.js.erb to customize your UI (for instance, linking some metadata of your Consul nodes/services with internal services of yours).

[simongareste]

Hi,

Indeed, with the javascript fixed it works as expected (I wasn't clear in my previous post, I did had everything working in the container, except the view displayed in my browser - the files were all valid, my env variable was correctly interpretated).

However, I believe you still have an issue in the repository, as the Gemfile.lock provided here states

BUNDLED WITH
   2.1.4

whereas the docker image ruby:2.5 comes with bundler 1.17.2. Because of this, building the image by directly building the Dockerfile upon clone won't work :

[...]
Step 5/10 : RUN bundle install
 ---> Running in 6507a122ed1f
You must use Bundler 2 or greater with this lockfile.
The command '/bin/sh -c bundle install' returned a non-zero code: 20

I see a few options to fix this:

• update rubygems in the Dockerfile before running bundle install: RUN gem update --system. This leads to a warning (Warning: the running version of Bundler (2.1.2) is older than the version that created the lockfile (2.1.4). We suggest you to upgrade to the version that created the lockfile by running gem install bundler:2.1.4.), but compiles successfully, and works (my consul-ui is working fine)
• do not ship the Gemfile.lock in the image, by adding Gemfile.lock to the .dockerignore file (or even remove the Gemfile.lock altogether). This would lead to a variation of gems in the image, depending on the time/date of the build, which may or may not be a super idea. May I suggest, however, to lighten the image and speed up the build by removing everything that is not necessary, starting with the .git folder and a few others files? I can do a pull request for this one.
• upgrade the ruby image used, to one that is using the same bundle version as the one in your Gemfile.lock. This looks messy.
• rebuild and recommit the Gemfile.lock with a 1.17.x version.
• other options: I'm pretty sure there are a lot more options, these are the simplest that come to mind :)

[pierresouchay]

@simongareste Arf... dependencies management with Ruby... I'll have a look, thank you!

Since you seem to know more than I do about dependency managemen with Ruby and Docker, would you like to create a Pull-Request?