Hey @maaz, sorry I didn’t look at this one right of way since I don’t have all the answers without doing a bit of digging and testing.
Re: Rook / OpenEBS / Rancher Longhorn. We don’t currently have an easy way to enable privileged containers within gravity, although I have encountered privileged containers in other packages as a defaul. Traditionally we’ve tried to promote best practices around security by hard coding those best practices. But like you’re experiencing, we’ve come across a few projects now that don’t provide any guidance on how to run without requiring privileged containers, even though its probably not that hard to do.
The unfortunate answer is we don’t provide an easy way to do this, but I do think allowing or exposing configuration for privileged containers may be something we need to evaluate.
The only workaround I can think of that works with the current release, is it’s possible to extend the planet base image we use within gravity, that changes the systemd units for apiserver and kubelet to allow privileged containers. https://gravitational.com/gravity/docs/pack/#user-defined-base-image
Be careful with this approach though, as Gravity and Planet do tend to be tied together, so you will need to make sure you track our planet releases in order to avoid any surprises.
Re: 2-stage application deployment
This is absolutely possible, it just requires a bit of scripting or programming work to setup the install job. Our hook system for install, actually lets you run just about any container or pod as an install hook. So in your application manifest, when defining the install hook, you can point it to you’re own container which will do the install, or you can just write a script that the container will run. The hook itself will mount the app directory, which means it can be as simple as a script that’s included in you’re app directory to perform the install.
I put together a similar example to this a couple months ago just to demo how to install two helm charts: https://github.com/gravitational/quickstart/blob/kevin/examples/multi-cluster/examples/multi-helm-install/resources/install.sh
The way this works is:
- The app.yaml defines an install hook as a separate file (install.yaml)
- The install.yaml, just references a random linux image that contains bash, in this case ubuntu:18.04
- Gravity when it runs the Job as the install hook, will tweak the job to add mounts for the contents of the application directory, which include an install.sh bash script.
- The install.sh bash script runs with whatever steps or logic is embedded in the script. So this could be a very simple
kubectl apply -f /var/lib/gravity/resources/step1.yaml, kubectl wait <condition>, kubectl apply -f /var/lib/gravity/resources/step2.yaml script, or something with far more complex logic.
I hope that helps.
