Yeah… the bundle inline only really works cleanly if all the deps are pure ruby Once you get into needing to make sure additional dynamic C libraries are installed things get harder. It can be done, as the sensu assets let you bundle libraries if you need them. But maybe for you this isn’t the best way forward right now, unless you intend to share these across your larger org and are looking to internally host assets as a way to do that.
But to be very clear, you do not have to use assets for your in house ruby. A lot of internal use only scripting not intended to be shared widely will be written in all sorts of tooling(i have so many one off bash scripts), noone expects all of this stuff to be shared or turned into assets, that’s just highly impracticable. That’s fine, you can still prep your running sensu environments using config management (or a volume mount in the case of a container) to have those plugin scripts in place if that’s what you have to do.
For your in-house ruby plugins you can use any compatible ruby environment… install ruby gems and C libraries as you need… that’s perfectly okay to do if that’s what you need to do. In fact for linux we still offer a pre-packaged ruby environment to help with sensu-plugins for those situations where assets won’t work. It installs into /opt/ so you should be able to use it with the community sensu-plugins gems and your own ruby scripts. Take a look at this:
To be perfectly honest, assets are a pretty forward looking new concept, with the idea that people will ideally contribute sharable golang plugins that can be statically compiled cross platform to make life easier for everyone. Being able to statically compile so easily makes golang a great asset language as it simplifies so much when you plan to statically compile. Interpreted languages like ruby that are designed to rely heavily onruntime linked libraries, require more thought, it can be done… anything can be done if you spend enough clever points. The best possible assets future that I see definitely involves transitioning to golang assets, which is why we’ve spun up golang plugin template repos and an sdk to help get people started there.
The ruby runtime assets right now are a best effort to provide a bridge into that future for the existing collection of shared community maintained sensu plugin gems. It works, because we’re able to offer a ruby runtime (to build assets against)… but it does depend on well groomed gem build automation (which all the sensu-plugins in the collection have) together with docker build environments (this is why the ruby asset stuff is linux only). Even still there are some community ruby plugins that need to be redesigned before they’ll work as assets.