3 ms·

Can you elaborate a bit? Do you mount something like a S3 bucket inside of a container?

• garganzol 4y ago
  Yes, exactly. The mount point is then used as a general disk for container data.
  • mixmastamyk 4y ago
    Interesting, so why do that? Is it just to simplify your client code? Instead of using the s3 api, you just save files in a standard (virtual) file system? Any other benefits or reliability/performance drawbacks? Maybe to avoid uuids and use standard fs paths?
    • arcastroe 4y ago
      I use it, for example, for Gitea storage. My host doesn't have a lot of storage, but I use reclone so that it all goes directly onto Google Drive (unlimited paid storage). Gitea also has a private docker container registry built in, which quickly grows large into several (hundred) gigabytes. It all works perfectly well with rclone. This makes my host stateless. Just run gitea docker image with Google-Drive backed storage. It works great because both git repositories and docker images are backed by files that are essentially immutable. An example that would not work well would be trying to run a container whose storage is a SQLite file that updates often. Trying to sync that SQLite file to google drive with rclone would be a bad idea.
      • mixmastamyk 4y ago
        Ok, so one reason is that it’s someone else’s app, where adding cloud support would be impractical.
    • garganzol 4y ago
      Cloud drive approach considerably simplifies the code. You can use shell scripts, Unix tools, 3rd party apps. You can combine them. This approach gives a lot of freedom and power. It is just Unix but with a cloud. Such approach also protects you from a vendor lock-in: you can use any cloud storage you like today. Performance drawbacks are evident - if a file is not cached in the local cache then it takes some time to get it there. But it does not really matter for the most apps because that initial lag is relatively short. Reliability has been perfect so far.
      • mixmastamyk 4y ago
        Neat thanks.