You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is the following use-case feasible? (More-detailed questions at the end of this msg.)
Summary
I am investigating implementing a docker-nfs-server to primarily to provide convenient "snapshot" mechanism for my team's nfs servers with the nfs-filesystem purposely inside the nfs-server container, as part of the docker image and not externally mounted from the docker host or anywhere else.
Purpose, desired features and integrations
Convenient and powerful snapshots. We're attempting to enable a means to fully snapshot nfs-server content (filesystem files and complete docker-container state). This seems potentially more easy, powerful, and/or convenient than trying to snapshot with zfs or some other alternative, at least because of the power and convenience of docker (maybe?) enabling easier-to-manage "full system snapshots".
Run on a LUKS mount within the docker-nfs-server image. Run the nfs-server process, within the docker-nfs-server image/container, on top of a LUKS-based "filesystem in a file," for data-security purpose (and keep the LUKS-decryption secret/key stored separately from the docker-nfs-server image). We realize this may take some of my custom modifications of docker-nfs-server.
Our current environment's scale is SMALL
Pls note: our targeted network environment and nfs-client load is small enough, and the docker host beefy enough (CPU, memory, etc), where I am not yet concerned about system-performance things.
Questions
Is something like this use case part of the original intent for this (docker-nfs-server) project?
Is the LUKS integration feasible (with the NFS-served files and the LUKS mount inside the image/container)?
Does anyone see any additional problem with this (above) application/use case?
Are there any specific constraints or limitations (in this context) for which we should be aware?
The text was updated successfully, but these errors were encountered:
johnnyutahh
changed the title
Docker-nfs-server as a "data/system snapshot engine": feasible?
docker-nfs-server as a "data/system snapshot engine": feasible?
Jul 4, 2020
Does "Provide the files to be shared over NFS ... from... files baked into custom image" mean that the docker-nfs-server container would read-and-write files directly from another docker container that contains/stores the files?
If so, by what means does it do this -- ie, how does the docker-nfs-server container communicate with files served by the filesystem in the "data container"?
(I'm unclear on what Docker's copy command does in this context; specifically, what does "baked into" mean? Which files get copied where, etc?)
At some point I'll be "cracking the hood and rebuilding the engine" (hopefully it's a minor rebuild, if no rebuild at all) to support my use case, which is totally cool and what I initially expected to do anyway.
I am trying to get @ehough 's attention by other means with as of yet no success. I've been preparing to do this work at some near-term, future point in hopes that Eric comes in and says "oh yeah, this is easy, just do 'X'" and saves my team some effort, while we work on other-more-pressing tasks.
In any case, the output from Eric's efforts looks (without yet testing it) remarkably good, and my team and I are very appreciative to not have to build a more-robust nfs-server container from scratch. Thanks Eric!
Is the following use-case feasible? (More-detailed questions at the end of this msg.)
Summary
I am investigating implementing a docker-nfs-server to primarily to provide convenient "snapshot" mechanism for my team's nfs servers with the nfs-filesystem purposely inside the nfs-server container, as part of the docker image and not externally mounted from the docker host or anywhere else.
Purpose, desired features and integrations
Our current environment's scale is SMALL
Pls note: our targeted network environment and nfs-client load is small enough, and the docker host beefy enough (CPU, memory, etc), where I am not yet concerned about system-performance things.
Questions
The text was updated successfully, but these errors were encountered: