I had a conversation with Dr. Ogg user in slack this week, and I thought it was important to summarize here so people doing Google searches have a chance to find it as it may help them with similar
Okay here’s the editted conversation.
Dr. Ogg i have some ruby gem’s / plugins i have written for the legacy sensu, and i would like to build a package for sensu go, anyone have a good guide on how to do this? some of the gems have lots of dependencies (other gems and some have libc). Thanks.
jspaleta hey, yeah so if they are packages as gems you definitely have a way forward
Dr. Ogg yah they are all gems
jspaleta If you just want to use them as ruby gems… you don’t have to do much different… other than provide a ruby env to install them in.
jspaleta for assets, you can follow the same pattern we are using for the gems under the sensu-plugins repository if you want to package Sensu assets you can build against the ruby runtime asset docker images we use.
jspaleta So the one thing you might have to do when building assets… if your ruby deps need C libraries installed… you may have to provide custom build scripting to supplement what we have setup as an addon repo
jspaleta anything terribly complicated using a lot of other commands via shell spawns…like calling chrome browser… might not be worth trying to create as an asset… but you always have the ability to install your gems ahead of time… you dont have to use assets… assets are new… old way of pre-provisioning checks into your target hosts is still fine
Dr. Ogg yah will take a look, was hoping to use assets
jspaleta the big difference now in Sensu Go, is because sensu itself doesn’t rely on a specific language interpreter (like Ruby) you have to make sure your targets have a Ruby env available
jspaleta you may find a way to bundle all of what you need in an asset… its not impossible…but it might not be worth putting chrome into the asset…and just make sure your targets have needed additional commands installed ahead of time. That’s workable for in-house assets, but problematic for anything you want to share with others on Bonsai.
jspaleta let me find you a couple of examples that have to use a custom Docker file because of C library deps in the gem deps
jspaleta let me show you a simple example… without the need for the override
jspaleta sensu-plugins-disk-checks… is the easy case… no native C library extensions needed in the gem deps… in that repo the travis.yml is a little simplier and just uses the Dockerfiles from the helper repo
jspaleta Okay take a look at sensu-plugins-postgres repo right now. Its a good example with a little bit of complexity. Because it needs the libpg library… we had to override the default Dockerfiles used by the asset build helper repo in the travisCI build automation.
jspaleta in the travis.yml you’ll see a before_deploy: section where the override Dockerfiles are copied over
jspaleta if you want to add additional binaries or libraries into the asset /bin lib/ you can… your automation will proably just looking veyr different than what we set up to support sensu-plugins
jspaleta and as always keep in mind that alpine doesn’t use glibc… so you have ot build special for alpine