search

vapor-ware / synse-sdk

SDK for Synse Plugins in Go
https://synse.readthedocs.io/en/latest/sdk/intro/
GNU General Public License v3.0
3 stars 4 forks source link

document different deployment strategies and requirements #15

Closed edaniszewski closed 6 years ago

edaniszewski commented 7 years ago

have some notes on this - it seems like there are three ways that a synse plugin could be deployed:

1.) within the same container as synse-server. this would probably be the case for the plugin emulator. we probably wouldn't run anything like this in production, but for an open source user, they could be free to create a custom build with their plugin directly integrated into the container.

2.) as a sidecar container. this means that each plugin that runs would be in its own container. this is good for modularity, etc. if there is a plugin failure it could also make it easy to restart the plugin (just restart the container). it could also provide an easy way to get logs for the plugin (e.g. the same way as all the other containers). with the current setup, to get this to work, we'd need everything connected to a shared volume (synse-server needs access to their unix socket..). alternatively, the gRPC comms layer can become configurable for unix socket or just regular ol' tcp. would require some additional changes to support, but seems feasible. the question then becomes: how does synse-server discover the plugins? w/ unix socket, discovery is just a matter of finding the socket file in the well-known dir. perhaps with tcp, no discovery would happen (at least initially) and it would just need to set via container configuration.

3.) on the host machine. the plugins can run on the host. this potentially makes servicing/debugging more difficult. running on the host gives them direct access to the host (no need to mount things into container or configure with the --privileged flag, or whatever else). they can all drop their socket files to a well-known place that is volume-mounted into synse-server to access that way.

thoughts on this are welcome. choosing which of the above we will use for our deployments will help focus development in that direction, but all can be supported eventually. also, if there is something here that I missed, let me know.

having all of this written up nicely with examples/diagrams in a doc somewhere should be the deliverable for this issue.

edaniszewski commented 6 years ago

started a rough doc on this. it starts to narrow things down and identify issues/questions and subsequent work items.

https://docs.google.com/document/d/14dxJzyPQNhEKUrGyBHyrDBP1I-kDDXVNPsI2-r06eXc/edit

edaniszewski commented 6 years ago

I think this can be closed now as it has matured enough and the design/expectations haven't changed much since the last comment.