Hello everyone,
I’ve been working through getting sensu-plugins-postgres packaged up as an asset across the ruby-runtime asset supported linux distribution targets. If you want to help test the assets before they are officially released as part of sensu-plugins you can find them here.
https://bonsai.sensu.io/assets/jspaleta/sensu-plugins-postgres/versions/4.0.0-pre-jef.1
Here’s some very important findings that I’ll be writing up as guidance for dealing with native extensions in ruby assets, using the postgresl plugin as an example to pattern on.
1. Need to use customized build process
For now you must customize the build process facilitated by the sensu-go-bonsai-asset helper repository. The Dockerfiles provided by the automation in that helper repository make it possible to build assets against the ruby runtime environment but they are not abstracted enough yet to deal with native extensions.
Right now you must adapt the Dockerfiles to ensure the OS provided libraries needed by the native extensions are installed prior to building the asset.
I’d love to make a general workflow, but the needs for each native extension can be varied so I’m not sure its possible to do it. What is possible is you can inject your custom Dockerfiles into the build process prior to running the asset build scripts.
2. Alpine will trip you up
Alpine by default uses libressl and not openssl, so building anything that requires ssl libs can be a little tricky as libressl-dev and libopenssl.-dev apk packages conflict with each other. This can be a real head scratcher when building assets. Alpine is just different than other linux distributions you may be use to using. You just have to be aware of it and be extra vigilant to test the Alpine assets.
3. Make sure you include shared libraries
You have to make sure you include the system libraries needed by the native extensions.
This seems to be tripping up a lot of people because the quick local test on the system you prototyped on probably has the necessary shared libraries installed and things appear to work.
I think I came up with the correct abstracted Dockerfile logic to solve this as a best practice that will catch most of the situations. But we also need to develop a good CI test regime to test for this after we build assets to ensure shared libraries work in a “blank” environment. There’s a lot of room left to refactor the helper repository to help catch these problems.