Assets are a bit of a game-changer for Sensu, and there are some important aspects you need to consider before sharing your working check(handler or mutator) command as an asset in order for people to get the best benefit from the effort.
Include all binaries needed for the asset functionality
It’s very easy to build a workable check command that internally uses OS provided cmdline tools. But it can be difficult to ensure all potential users of an asset have the same set of OS provided tools installed as you do.
Some assets can be fully self-contained including all shared libraries and executables. This isn’t always possible. If your asset executables use system provided tools that aren’t bundled in your asset, please document that in the README for your repository, so users can make informed decisions to get the required tools installed via other means.
Make sure to include shared libraries in the asset’s
This is easy to overlook if you are doing testing and asset building in your own local environment where the shared libraries you need are already on the system.
For example, even if your asset builds and works in your local centos VM, a minimal centos container may not have the shared libraries your asset needs.
For existing Sensu Community Ruby plugins that use natively compiled extension dependencies, we have some CI automation that helps automate this by making use of the Ruby gem bundle tool.
If your check command requires privileged operation, you may want to refrain from generating an asset for the command at this time. Privileged functionality are best left as installable plugins, to ensure correct privileged operation via a config management system
That being said, double check to and make sure the check functionality really does need to be privledged, the need to run a check command privileged may be deficiency in the check command itself or addressed with system configuration changes.
Not all libc implementations are compatible. If you are using any shared libraries, you’ll want to make sure you advertise your asset buillds with some care. For example Alpine uses musc instead of glibc, which are binary incompatible libc implementations. Shared libraries built on Centos or Debian won’t work with Alpine.
Platform family versus platform
when setting up your asset build matching filters, you’ll want to make use of platform_family instead of platform for widest linux distribution coverage using the default filters.
You can pin asset releases to specific platform versions if needed by using a filter that matches against the platform_version attribute. Here’s an example of a filter that will match against rhel 7 and centos 7
- entity.system.platform_platform == 'rhel' - entity.system.platform_version.split('.') == '7'