Gem issues with example docker-compose.yml during client container initialization

[genofedanzo]

When using the example docker-compose.yml I ran into a problem where the client container would try to run parallel gem installations of sstarcher/aws and mailer plugins which both have dependencies on unf_ext. It seems to create a race condition where one gem starts to build unf_ext and the other begins to build unf_ext and wipes out the priors work as seen here:

https://github.com/sstarcher/sensu-plugins-aws/archive/master.tar.gz
Downloading      sensu-plugins/mailer:master
https://github.com/sensu-plugins/sensu-plugins-mailer/archive/master.tar.gz
Building         sensu-plugins/mailer:master
Building         sstarcher/aws:master
Installing       sensu-plugins/mailer:master
Installing       sstarcher/aws:master
ERROR:  Error installing sensu-plugins-mailer-1.2.0.gem:
        ERROR: Failed to build gem native extension.

    current directory: /opt/sensu/embedded/lib/ruby/gems/2.4.0/gems/unf_ext-0.0.7.4/ext/unf_ext
/opt/sensu/embedded/bin/ruby -r ./siteconf20170911-31-1dglfcg.rb extconf.rb
checking for -lstdc++... yes
creating Makefile

current directory: /opt/sensu/embedded/lib/ruby/gems/2.4.0/gems/unf_ext-0.0.7.4/ext/unf_ext
make "DESTDIR=" clean

current directory: /opt/sensu/embedded/lib/ruby/gems/2.4.0/gems/unf_ext-0.0.7.4/ext/unf_ext
make "DESTDIR="
compiling unf.cc
In file included from unf.cc:1:0:
unf/normalizer.hh:11:19: fatal error: util.hh: No such file or directory
compilation terminated.
Makefile:209: recipe for target 'unf.o' failed
make: *** [unf.o] Error 1

make failed, exit code 2

Gem files will remain installed in /opt/sensu/embedded/lib/ruby/gems/2.4.0/gems/unf_ext-0.0.7.4 for inspection.
Results logged to /opt/sensu/embedded/lib/ruby/gems/2.4.0/extensions/x86_64-linux/2.4.0/unf_ext-0.0.7.4/gem_make.out

I've worked around this by preventing the install script from backgrounding each plugin install. I can submit a PR but I'm not sure if this is the best approach.

[sstarcher]

Due to the parallel installation I don't know if a good option exists. One option would be to install unf_ext prior to running the installation.

[genofedanzo]

That would work. Although I guess it could come up any time there are shared native extension dependencies in multiple packages. Maybe don't parallelize it? I'm just not sure how often it would come up and the speed increase is nice. What I think is important is that people can run the example compose file and bring up a working cluster. After getting past the compile issue I ran into CLIENT_ADDRESS not being populated (which I got going with 127.0.0.1 but I believe that makes the server run checks against itself and not the actual client?) and then uchiwa needs env vars for SENSU_DC_NAME, SENSU_HOSTNAME and SENSU_SERVICE_PORT in order to hit the API and show the registered clients. I can create a PR for the uchiwa vars.

[sstarcher]

@genofedanzo part of the problem may have been that the sstarcher/aws repo that was reference is very out dated. I pushed the upstream updates back to sstarcher/sensu-plugins-aws. Try doing the example install again.

[genofedanzo]

@sstarcher looks like it still has the dependency. Drop the parallel install to prevent it coming up again in the future? Bake this gem into the image? Seems like it could come up again. What did you think about the uchiwa vars I mentioned that are needed to connect to the API? Would you like me to create a PR or open a separate issue? I'd like to help so others don't have to troubleshoot as much as I did.

[sstarcher]

ya, the uchiwa vars need fixed in the README. The docker-compose.yaml works and it may make more sense to just remove the example out of the README and link to the docker-compose.yaml

As for the parallel build I would be fine with a flag to turn it off. I don't recommend doing the RUNTIME install. I would recommend building a new dockerfile based off this dockerfile and putting in a

RUN gem install unf_ext
RUN /bin/install aws,mailer

[genofedanzo]

That makes sense. Dropping the sample compose config out of the readme and linking to the repo compose file makes sense. Wish I realized it existed before but I ended up learning a bunch while troubleshooting. I hadn't heard of dumb-init or envtpl and now I'm using them in my own images. Thanks for the help.

[sstarcher]

@genofedanzo haha np, sorry for not keeping that README as up to date. Hopefully I'll get around to updating it and add a comment about troubleshooting the parallel build.