about to start work on getting rstudio server pro/workbench deployed into kubernetes
the idea is that i would take our rstudio server pro container with sssd/AD-controlled login/folders/sql and then build a helm chart around it so that i can deploy it to kubernetes using standard CI/CD.
and i have a few questions...
Helm:
i'll be building a helm chart for deployment.. do you have any work ongoing internally on an rstudio workbench helm chart? interested in joining forces?
Launcher:
what is the use-case with launcher? is it e.g. that the user has an on-metal installation of rstudio server pro/workbench and then wants to launch sessions/jobs into kubernetes?
what is the user security context of sessions/jobs that are launched into kubernetes? does it somehow use the same sssd user paramaters as the original?
i'm installing rstudio server pro into kubernetes,.. so how should i actually use launcher in that case...? Can i use it to distribute the user's sessions over multiple pods rather than keeping them all inside the one Kubernetes pod that i deploy
Thanks so much for reaching out here @cal1! This is exciting stuff!!
A couple of items:
Yes! We have a "beta"ish helm chart - we are currently working on improving the documentation and moving it into a public GitHub repo to more closely mirror the community! The helm repo itself is "hidden" but public, described in a GitHub gist that I will share with you in a DM. For anyone finding this after the fact, we should hopefully have a more public helm repo / GitHub repo up soonish! (I really dislike being so cagey about things, but the user experience is far less than ideal at present )
Please feel free to share feedback on using the chart, rough edges, things that could be improved, docs that would be helpful, etc.! Once we get this to a public repo, open source contributions will be more than welcome
Launcher is used by default in the helm chart - it can be used with an "on-metal install launching into Kubernetes" or as a "Kubernetes pod launching sessions into Kubernetes as separate pods." The helm chart uses the latter approach (although it is true that our public docs mostly represent the former)
The sssd story is tricky. You are welcome to use the pattern that we have done for our demo server. We split launcher into a separate container, which we are now recommending against (the current plan is for the product to do a better job of managing the launcher "seamlessly" in the future), so the only recommendation would be to add a service for the launcher too, if you use this pattern.
The other sssd pattern that is in use in some places is to just modify the startup script in our example containers to start sssd - the only risk there is if sssd stops, you will get no feedback at the Kubernetes level other than Workbench will stop being able to authenticate / provision users.
Basically, the sessions will not have "sssd running" in them (by default, although we have some customers who do that in order to maintain group memberships, Kerberos, etc.). However, if you have sssd running in the "parent" container, then Workbench will initialize the user in the session with the proper UID / home directory / etc. (the info from getent passwd myusername), so in most cases you will not need sssd in the session containers.
And finally, yes! The beauty of using launcher with Workbench in Kubernetes is that work is scheduled granularly across the cluster - every session gets its own pod, the Workbench container has no user code running within it, etc.
I hope that helps answer your questions!! Please do keep this thread open and let us know how this goes for you! We are doing a lot to improve this story at the moment and make life easier for Kubernetes administrators
We now have a public helm chart repository, and a public GitHub repository to go along with it:
We also have things listed on ArtifactHub. It is still freshly landed (this week), so feedback and recommendations are welcome as we continue to improve!!
This is exciting stuff!!
)
