Skip to content

Latest commit

 

History

History
69 lines (66 loc) · 3.65 KB

FAQ.md

File metadata and controls

69 lines (66 loc) · 3.65 KB

FAQ:

  1. "How do I give some users extra software?"
    • Add the appropriate installation commands to their Dockerfile-{username}. Example: RUN apk add git
  2. "How do I get into a container as root?"
    • On the Docker host: docker exec -ti jumper-{username} /bin/sh
  3. "Is user data preserved between container restarts?"
    • Yes, unless deleted. Containers run in --detach mode and retain their data unless deleted with docker rm. Note: the patching process requires old containers be deleted and the halt_all_users.sh script deletes containers.
  4. "Is user data preserved between container rebuilds?"
    • By default, no.
  5. "How can I make user's home directory persistent?"
    • Map a directory/drive/mount on your Docker host to /jumper/home in the container when the container is run. Check out the run_all_users.sh script for examples. See also: docker.com/tutorials/dockervolumes
  6. "What do I do when a user leaves the company?"
    1. docker kill jumper-{username}
    2. mv /path/to/Dockerfile-{username} /somewhere/else/
    3. docker export jumper-{username} > /tmp/jumper-{username}.tar
    4. docker rm jumper-{username}
    5. docker rmi company/jumper-{username}:X.Y
  7. "How to limit which servers a person can jump to from Jumper?"
    • Not part of this product yet, and limiting hosts doesn't make sense unless using a jumper-root setup where access to root's private ssh key is protected with sudo.
  8. "What about git, or other devel software?"
    • You can install anything you want by putting the needed commands in the Dockerfile, but jumper isn't meant to be a good devel environment. Your source control repos should have their own VIP(s) and your users should keep their local code on their workstations where their IDEs are. If you find your containers are getting too big you're probably using jumper the wrong way. Jumper is just an SSH tier.
  9. "Can I use Ubuntu for the base Dockerfile instead?"
    • Yes, but each container's memory usage will be at least 10x greater. A base ubuntu:16.04 image is 129MB, alpine:3.5 is 3.9MB.
  10. "How can I stop all containers for a bit without deleting them?"
    • ./jumper/stop_all_users.sh
  11. "How can I start all containers previously stopped?"
    • ./jumper/start_all_users.sh
  12. "What files need to be updated if I want to change the image tag?"
  13. "This looks complicated."
    • Relax, it's just shell scripts, a couple Dockerfiles and customized but normal SSH configs.
  14. "Can I use passwords? My employees don't know how to generate SSH keys."
    • Don't give them system access. You have bigger problems.
  15. "Oh, come on man, just tell me what to run."
    • ssh-keygen -t rsa -b 8192 -f ~/.ssh/id_rsa -N ''
    • The public key will be ~/.ssh/id_rsa.pub

Other thoughts

  1. Why not put an image on Docker hub so we can just run containers without worrying about building a base image?
    • It feels like a waste of time in this case. In real-world scenarios admins will need to control when, if, and how they patch their images. Putting a base image on Docker hub will get new sysadmins up-and-running a bit quicker, but it's only saving them 1 command, and they'll eventually need to build their own base images anyway.
    • Furthermore OS patches that relate to the Alpine image Jumper is based on get released on their own schedule, and Jumper's updates do not automatically sync up with them.