Docker docs

[njam]

For #15

@stephenh wdyt? Please let me know if I something is not described clearly and should be extended. And feel free to edit as you see fit.

[njam]

Thanks for the feedback, it helped! I've changed it to use docker's built-in -u, --user flag, instead of passing in those environment variables and using sudo in the container. It seems simpler and easier to understand.

Is the owner of the files as-exposed-to-the-container, or the owner as-exposed-to-our-real-filesystem?

It will affect both. I think it's how bind mounts work, which is used when mounting a folder from the host into the container.

What do you think about making some scripts

I thought about that too. I would be particularly interested in a script that spawns and controls the client and the server process, so I can easily and quickly mirror a directory to a remote host. Something like you described in the todo "easy setup/install process". I'm working on some scripts now. But IMO we could merge this first.

[stephenh]

Cool, looks great. Thanks!

[njam]

I was trying to create a shell script, which would use screen to launch a mirror server process using SSH, and a client process at the same time. Unfortunately I think it's not the right way, because it's not very reliable and when something goes wrong it's difficult to understand what went wrong.

#!/bin/bash
set -e

IMAGE=${IMAGE:-quay.io/stephenh/mirror:latest}
PATH_LOCAL=${PATH_LOCAL:-$(pwd)}
PATH_REMOTE=${PATH_REMOTE:-\$(mktemp -dt)}
SSH_DESTINATION=${1}
SSH_HOST=$(cut -d "@" -f 2 <<< ${SSH_DESTINATION})

SERVER="\
ssh -L 49172:localhost:49172 ${SSH_DESTINATION} -t ' \
  echo 999999 | sudo tee /proc/sys/fs/inotify/{max_user_watches,max_queued_events,max_user_instances} >/dev/null && \
  sudo docker run --rm --init -it -u \$(id -u):\$(id -g) -v ${PATH_REMOTE}:/data ${IMAGE} server \
'
"

CLIENT="\
docker run --rm --init -it -u \$(id -u):\$(id -g) -v ${PATH_LOCAL}:/data ${IMAGE} client \
  --local-root /data \
  --remote-root /data \
  --host localhost
"

cat << EOF > /tmp/docker-connect.screenrc
bindkey "^[[1;5A" focus up
bindkey "^[[1;5B" focus down
sessionname mirror-connect-${PATH_LOCAL}
split
screen -t mirror-server 0 ${SERVER}
focus down
screen -t mirror-client 1 ${CLIENT}
EOF

screen -c /tmp/docker-connect.screenrc

It would probably be better to use a more powerful programming language to spawn the two processes, control them and show useful information about their status to the user.

Just fyi

[stephenh]

Nice, I agree something out of the box like this would be great. Screen is not actually a bad idea, but not entirely surprised it's not super robust. Thanks for the update!