convoy
convoy copied to clipboard
rancher
S3 backend for convoy
I think it will be nice to add an object storage backend to rancher through convoy. With docker 1.10 it can easily plug to s3 with this container
https://github.com/childsb/s3fs-container
https://abrv8.wordpress.com/2016/01/25/docker-1-10-shared-namespace-s3-fun/
I think all that is required then is to create a convoy s3 stack in the catalog and integrate it with rancher volume so that one can easily add object storage to rancher
I am not very convinced that S3 is a good way to use as file system. It meant to be objectstore only. The performance cannot be anywhere near a filesystem like NFS. Amazon also has EFS which should be supported by Convoy using vfs driver.
Ok. Well i never meant for a filesystem. I was just feeling it could still be nice for a rancher infrastructure to support object storage option like s3 and swift for cheaper storage. Just additional option if worthy. On Apr 7, 2016 2:04 PM, "Sheng Yang" [email protected] wrote:
I am not very convinced that S3 is a good way to use as file system. It meant to be objectstore only. The performance cannot be anywhere near a filesystem like NFS. Amazon also has EFS which should be supported by Convoy using vfs driver.
— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/rancher/convoy/issues/82#issuecomment-207031115
We're planning the backup/restore feature on Rancher, using currently supported objectstore in Convoy, say S3/VFS. It will need quite some work on Rancher side though.
S3 based FS delivered via convoy would in fact be useful for me - I store configuration data, and other static (or rarely changed) data on S3.
I'm considering deploying S3fs to several hosts to share this data as it is. In my own use case, this is mostly static data, rarely changed config files and such - things I would really only mount read-only in the consumer-containers - and I would push any writes from another with something more appropriate like s3cmd.
I will, however look in to EFS - I've not see this product at all? OIC - is brand new, need an invite :) Off to get invite.
Efs is quite costly for long period storage. Actually that's actually same reason for us. We just need a bucket to be dumping all artifacts in our rancher infrastructure for later recovery. On Apr 7, 2016 8:26 PM, "Rob Nelson" [email protected] wrote:
S3 based FS delivered via convoy would in fact be useful for me - I store configuration data, and other static (or rarely changed) data on S3.
I'm considering deploying S3fs to several hosts to share this data as it is. In my own use case, this is mostly static data, rarely changed config files and such - things I would really only mount read-only in the consumer-containers - and I would push any writes from another with something more appropriate like s3cmd.
I will, however look in to EFS - I've not see this product at all? OIC - is brand new, need an invite :) Off to get invite.
— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/rancher/convoy/issues/82#issuecomment-207147988
ouch - yeah - S3 @ $0.03/GB-month vs EFS @ $0.30/GB-noth is quite a jump - TBH, we'd be likely to use both solutions. (I have an EFS use case that would quite definitely save me money and headache!)
however the S3fs still remains a potential solution for us - it's more useful in many cases than a simple pull - more reliable to simply have a whole bucket of files present on the machine than to have to write scripts to curl or pull some other way.
@yasker Rancher will provide a container like convoy-nfs for s3fs, considering what @guruvan and @lavvy said? For me s3fs will work like described by them.
What does the codebase in https://github.com/rancher/convoy/tree/master/s3 do, if not provide a volume driver?
@yasker I don't appreciate your immediate nay-saying the topic before you have any evidence- the object store nature doesn't seem to really be in conflict, and performance, in many cases, looks good or even great, as seen by goofys. Certainly bulk transfers going +100MB/s aint bad, if that's your use case. Please have more modesty about what you know and be more open to ideas, even ones that don't immediately make sense to you!
Definitely for small files within a docker volume, backing directly to S3 will really help with a lot of containers that need persistent data. For larger files and volumes, its a good one to test on the practical level.
One of my use cases is running applications on my computer at home but having my stateful data stored in the cloud (S3 preferable, but even going further it would be even more convenient if stored in Google Drive!).
I'm interested in this as a feature as well. I would use AWS EFS, however it's only available in specific regions, and our architecture has Rancher clusters running in regions that currently aren't supported (eg us-west-1).
We're not planning to storage a large amount in S3, just data that one container in a stack populates via a Web UI and another container that processes the data out of a shared filesystem. Updating the app to use S3 internally to share data is currently not an option.
