Skip to content

3. Conventions

Tanishq Rupaal edited this page Jun 10, 2023 · 3 revisions

This page in the wiki is just to explain the conventions I used and recommend using with this image.

All the images here are primarily meant to be used as a linux system for work. The idea is to have a container with a persistent storage directory that stays intact even across container spin down and spin up cycles. The shell history or any required configuration file can be shared with the container for persistence as well. The structure of the docker_work directory is something like this →

$ tree docker_work -a
docker_work
└── .zsh_history

The directory can also container say run.sh as a script that can be customized to contain any custom script instructions needed to get a container ready for work or any initial automation to run every session. This can be directly run from the persistence directory as it's automatically mounted as described in the example workflow. The .zsh_history file is also automatically copied in and out from the home directory within the container by the start and stop functions.

The images are also built with the intention of SSH-ing into it and making use of tmux to work on. While they can be exec-ed into as well, using SSH has the following advantages →

  • The container can be deployed on separate machines (like cloud VMs) and then SSH-ed into via non-standard ports
  • Using SSH allows dynamic port forwarding allowing easy access to web-based services exposed within the container through browsers with the appropriate proxy setup
  • It also fixes certain visual discrepancies that appear when exec-ing into the image (example - the shell autocompletion color is overridden by the default color which makes it look weird)

The password is randomly generated and stored in the current_docker_password file in the current directory as well as printed out when the container is built and run.

The start_work function also includes a $@, mainly to add other port publish arguments or volume mounts arguments if necessary. One such example is for adding a Go-lang based directory structure, for which, the argument passed to the start_work command can be as follows →

-v /path/to/host/go_programs/:/root/go/src

Other general conventions followed for building/running the images are →

  • Port mapping follows convention → shared port = port + 50000
  • Port for dynamic port forwarding when SSH-ing into the container = 65500
  • Volume mount to /persist (helps with persistence across runs or sessions)
  • General tool installations should be under /opt inside the container, while executables should be under /opt/executables (has already been added to path within the Dockerfiles)
  • Optionally maintain a run.sh file for custom stuff to run when the container starts (also helps with persistence of custom script instructions)

Read Next → Image-Builds

Clone this wiki locally