#5 Support for Remote Storage (S3)

Open
opened 3 years ago by Ghost · 3 comments
Ghost commented 3 years ago

Following https://docs.joinpeertube.org/admin-remote-storage (and maybe in the future direct access to S3), would the peertube-helm chart be open / interrested in supporting configuration of the S3 storage config ?

Following https://docs.joinpeertube.org/admin-remote-storage (and maybe in the future direct access to S3), would the peertube-helm chart be open / interrested in supporting configuration of the S3 storage config ?
Poster
Owner

Hello!

It could be interesting indeed!

Currently the helm chart does not handle persistent volume at all, instead it assumes that a pvc is created in kubernetes, and passed to the deployement as it.

(I did that to avoid deleting the PVC by accident when upgrading/deleting the helm deployment ^^")

I am not familiar with s3, but a native possibility could be to have a provisionner in k8s, create a pvc and use the CSI capacities so peertube see it as a standard filesystem?

However to use it "from inside" the docker with the s3fs cli as stated in the documentation, I think we may add an env variable to support S3_STORAGE here

After that, you need a docker image builded with the cli (which seems not the case of the official image ) but the chart already allow the use of any custom image.

The tricky part is to launch the cli and mount the fuse filesystem. Perhaps we may override the command used by the container, for example if the S3_STORAGE env var exists 🤔

This part should be the same for kubernetes, either we use helm or not, eg, a standard deployment with kubectl apply will have the same problematic. So, if you have already done that for kubernetes, it's just a matter of converting it to helm template 🤞

Anyway I would be very interrested by your idea and opinion about this!

Thanks a lot for the idea :-)

Hello! It could be interesting indeed! Currently the helm chart does not handle persistent volume at all, instead it assumes that a pvc is created in kubernetes, and passed to the deployement as it. (I did that to avoid deleting the PVC by accident when upgrading/deleting the helm deployment ^^") I am not familiar with s3, but a native possibility could be to have a provisionner in k8s, create a pvc and use the CSI capacities so peertube see it as a standard filesystem? However to use it "from inside" the docker with the s3fs cli as stated in the documentation, I think we may add an env variable to support `S3_STORAGE` [here](https://git.lecygnenoir.info/LecygneNoir/peertube-helm/src/branch/master/templates/deployment.yaml#L132) After that, you need a docker image builded with the cli (which seems not the case of the [official image](https://hub.docker.com/layers/chocobozzz/peertube/v3.1.0-buster/images/sha256-455af623efb8297e5c25d1b3838b604b1c507227a5d10600eb39b69574883a7d?context=explore) ) but the chart already allow the use of any custom image. The tricky part is to launch the cli and mount the fuse filesystem. Perhaps we may override the `command` used by the container, for example if the `S3_STORAGE` env var exists 🤔 This part should be the same for kubernetes, either we use helm or not, eg, a standard deployment with `kubectl apply` will have the same problematic. So, if you have already done that for kubernetes, it's just a matter of converting it to helm template 🤞 Anyway I would be very interrested by your idea and opinion about this! Thanks a lot for the idea :-)
Ghost commented 3 years ago
Poster

Thanks for taking the time to look into this !

We've just published our deployment files on https://forge.extranet.logilab.fr/open-source/peertube-on-kubernetes and the way we ended up doing it is with a s3fs side car with a "shared volume".

The approach with CSI is very promising and probably more stable, after checking out https://github.com/informatics-lab/s3-fuse-flex-volume (untested) and finding the newer https://github.com/ctrox/csi-s3 (untested too) we will probably invest some time to test that out.

Another future improvement is native-s3 support in peertube (don't know where it fits on the roadmap).

Thanks for taking the time to look into this ! We've just published our deployment files on https://forge.extranet.logilab.fr/open-source/peertube-on-kubernetes and the way we ended up doing it is with a s3fs side car with a "shared volume". The approach with CSI is very promising and probably more stable, after checking out https://github.com/informatics-lab/s3-fuse-flex-volume (untested) and finding the newer https://github.com/ctrox/csi-s3 (untested too) we will probably invest some time to test that out. Another future improvement is native-s3 support in peertube (don't know where it fits on the roadmap).
Poster
Owner

Ooooh, the sidecar is a good idea indeed!

By the way, technically it's the same with CSI, they mount shared volume between the CSI driver and the final pod thanks to a deamonset deployment on each node, so if it works with the sidecar, it should work with CSI too 👍

I have to admit I am curious to know if you notive some real difference (ease? Performance?) between a manual sidecar and/or the CSI.

We may add a sidecar in the helm chart if you feel it's the better way to do so!

Ooooh, the sidecar is a good idea indeed! By the way, technically it's the same with CSI, they mount shared volume between the CSI driver and the final pod thanks to a deamonset deployment on each node, so if it works with the sidecar, it should work with CSI too 👍 I have to admit I am curious to know if you notive some real difference (ease? Performance?) between a manual sidecar and/or the CSI. We may add a sidecar in the helm chart if you feel it's the better way to do so!
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.