-
Notifications
You must be signed in to change notification settings - Fork 784
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create plugin example #83
Comments
Changing direction with this, the implementation of a plugin will remain the same but the way in which they are built and run is ideally going to fit into one of two categories: Building Public PluginsShared plugins won't be merged into the main Benthos codebase, and therefore won't be part of the main distributed binary. Instead, you will be recommended to create a plugin project (the template for this is TBD) where the compiled plugin (a The ability for Benthos to do this has already been added in: 128e896. However, there are issues in creating these plugins that need to be resolved. Building Private PluginsIf you are building plugins intended for private use then advice is going to be to compile them into either a fork or use Benthos as a framework in a new project. Framework is recommended since it means easier upgrades to track the main project. However, if you intend to also use public shared plugins you should create them the same way (and just don't share them.) |
IssuesI've been reading up on Go plugins and experimenting with Benthos and it seems as though the versioning of a plugin is extremely strict. Not only does a plugin need to compile against the exact same dependency tree as the Benthos version it is loaded by, but it is also not able to use vendoring for this purpose, and neither can Benthos. Even the smallest difference (like, for example, the value of GOPATH) between the Benthos build and the plugin build seem to break the plugin. It seems as though the Go team have primarily implemented plugins with the assumption that they are compiled along with the binary they are loaded with. Since that completely defeats the purpose of our use of plugins we will have to find a way of working around that. I imagine this will require isolating the Benthos build system so that it can be exactly reproduced by any teams building a plugin. Short term goalsI need to change the Benthos build system to no longer use vendoring. The vendor directory isn't yet checked into master, it was my intention to do this eventually but since we might have to scrap vendoring I'll simply proceed as if that was never the case. The build system also needs to be designed to make it extremely easy for other teams to reproduce the exact conditions of the packaged builds. This needs to be the case for both the binary distributions and the docker images. Long term goalsWork out how we're going to advise people to distribute their plugins, considering that versioning is so crucial here this won't be trivial |
Wow, I guess that’s why terraform uses a custom plugin implementation https://github.com/hashicorp/go-plugin. What are your thoughts on their approach? I’m not sure it fits the benthos use case, but the issues you’ve described above with native plugins seem to make this approach a no go from my perspective. The only way it seems feasible is if all plugins were included in the benthos repo and built along with the core, which kind of defeats the point. Guess I need to think about this some more |
I'd be worried about the overhead of using RPC, could always give it a go. I've got an example of a plugin using official Go plugins: https://github.com/Jeffail/benthos-plugin-example, it's actually very simple, would be great if we could find a nice way of doing the builds. |
Don't get me wrong, the example implementation looks awesome! and I agree with the RPC concerns. However, after doing some more reading on go plugins, the limitations seem to be a pretty difficult problem to solve. |
Hi, where I can see this plugin example: https://github.com/Jeffail/benthos/blob/feature/plugin-example/lib/input/plugins/mysql.go#L48 - this link is expired |
Hey @silentnull, sorry, I've updated the first post as there's now a project demoing this: https://github.com/Jeffail/benthos-plugin-example |
Hey @Jeffail . Yep, I saw this repo, but there is only simple benthos plugin example, but I will extended example with mysql :) Is possible get source code of plugin for mysql ? |
@silentnull ah right, I've pushed that example branch back so you can see, the link should work again now. I'll make sure it exists in the example project before I delete again. |
Hey @Jeffail . Yes, now the link works 👍 Thank you. |
Hey @Jeffail . I have a question to Manager type. It has function GetCache. Function works as Get property and returns Cache object. Where this object is declared ? |
@silentnull, the caches are defined in the The plugin example implements the The choice is yours really, the main advantage of using |
Closing this for now, we have https://github.com/benthosdev/benthos-plugin-example and my advice from here onwards is going to be to maintain your own |
Would be good to have a standard implementation of a plugin to share, a good starting point is adapting #76 into one.
Edit: Here's an example of an isolated plugin project: https://github.com/Jeffail/benthos-plugin-example
I still need to create a build system that makes plugins built this way viable. However, you can copy/paste the implementation within
main.go
and use that to build a plugin directly into a fork of Benthos, or a project that uses Benthos as a framework and that should work right now.The text was updated successfully, but these errors were encountered: