- "How do I give some users extra software?"
- Add the appropriate installation commands to their
Dockerfile-{username}. Example:
RUN apk add git
- Add the appropriate installation commands to their
Dockerfile-{username}. Example:
- "How do I get into a container as root?"
- On the Docker host:
docker exec -ti jumper-{username} /bin/sh
- On the Docker host:
- "Is user data preserved between container restarts?"
- Yes, unless deleted. Containers run in
--detach
mode and retain their data unless deleted withdocker rm
. Note: the patching process requires old containers be deleted and the halt_all_users.sh script deletes containers.
- Yes, unless deleted. Containers run in
- "Is user data preserved between container rebuilds?"
- By default, no.
- "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
- Map a directory/drive/mount on your Docker host to /jumper/home
in the container when the container is run. Check out the
- "What do I do when a user leaves the company?"
docker kill jumper-{username}
mv /path/to/Dockerfile-{username} /somewhere/else/
docker export jumper-{username} > /tmp/jumper-{username}.tar
docker rm jumper-{username}
docker rmi company/jumper-{username}:X.Y
- "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.
- "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.
- "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.
- "How can I stop all containers for a bit without deleting them?"
./jumper/stop_all_users.sh
- "How can I start all containers previously stopped?"
./jumper/start_all_users.sh
- "What files need to be updated if I want to change the image tag?"
- The
FROM
line in all of the user Dockerfiles, and theimage_tag
variable in jumper/cfg/settings.sh
- The
- "This looks complicated."
- Relax, it's just shell scripts, a couple Dockerfiles and customized but normal SSH configs.
- "Can I use passwords? My employees don't know how to generate SSH
keys."
- Don't give them system access. You have bigger problems.
- "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
- 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.