Container filesystem access for easily downloading/uploading files

[sanderson]

In some cases, applications and/or their supporting services (databases, caches, etc.) write files to the filesystem that users would like to download. There currently isn't an easy way to access and securely copy files in most components. @glinton had a great idea of a fetch command, that would securely copy files from a remote container to your local machine. Here's my initial thoughts:

# Pattern
nanobox fetch [component.id] remote/path local/path

# Example
nanobox fetch data.mongodb /data/exports/12-12-17.csv ~/local/exports-dir

# Or even recursive copies
nanobox fetch worker.jobs --recursive /app/jobs/* ~/local/dir

[danhunsaker]

In addition to nanobox fetch [-r|--recursive] [<remote>] <component>.<id> remote/path local/path, we'd also want the reverse, nanobox send [-r|--recursive] [<remote>] <component>.<id> local/path remote/path...

[sanderson]

Good call @danhunsaker. So in summary, here's the suggested patterns:

# fetch pattern
nanobox fetch [-r|--recursive] [<remote>] <component>.<id> remote/path local/path

# send pattern
nanobox send [-r|--recursive] [<remote>] <component>.<id> local/path remote/path

I should note that fetch and send are only suggestions. There may be better options for the names of these commands

I think we also need to be sure to include support for bash file name arguments in the path:

# Example
nanobox fetch data.storage remote/storage/path/{file1,file2} local/storage/path

[danhunsaker]

To be clear, Bash will probably interpret those list args for us, so it would more acurately be support for listing multiple source files and a single destination.

Still. Agreed. With naming subject to change, of course.

[sanderson]

While the recent availability of app SSH keys in user dashboards provides another solution to this problem (ssh, sftp, scp, ect.), I still think this would be a valuable addition to streamlining the file send/fetch workflow.

[danhunsaker]

Especially since the SSH server is only available on the Docker host, not inside the containers, and there'd be no way to connect directly to any of the containers even if they did have SSH running anyway. 😊

[glinton]

Yes, the app SSH keys would require the same workaround, copying the file from the docker container to the host, then rsyncing down. It just saves a step as they don't have to do anything with their key.

Also, duplicate of #302