I just learned that Bitbucket offers per-repo cloud storage for arbitary
files (the "Downloads" section on the web gui). Doing this before adding
another third-party deb to our build (rakurai), which is quite large at
140MB. We don't want to pack that into our repo.
To ensure it is unique on the main host (i.e., outside the container). Get rid
of devcontainer_initialize.sh, all it did was run "mkdir". Something this
trivial can be inlined in the devcontainer.json (less indirection this way).
Break up large RUN steps (where many apt pkgs are installed at once) to
smaller incremental ones. If 'docker build' fails on a particular RUN
step, it can be re-run from the last successful step, so smaller steps
better preserve progress.
The previous name, 'johncolvin/bluetradingsystems', was chosen in a
misguided effort to adhere to a naming convention recommended by Docker
Hub (https://docs.docker.com/docker-hub/repos/create/). In hindsight,
this convention isn't well suited to our use case. Our images are shared
by multiple users (e.g., sparkd dev users all use the same sparkd-dev
image), so it doesn't make sense to name the repository after an
arbitrary user.
Leave the image's default user as 'root' so we can modify the non-root user's
uid/gid. This is a common technique used in containers to gain file permissions
in mounted dirs.
The default user's uid/gid can't be changed because a bash process runs under
their ownership as long as the container is up. A user's uid/gid cannot be
changed while that user owns a process (at least not via 'usermod').
Bugs (fixed):
* The default user does not have sudo permission in the container,
unless the user is specified explicitly in the 'docker exec' cmd
(via -u <user>).
Cause: When the default user is specified with a specific group
(in this case, its namesake 'bts'), it is excluded from all other
groups, including 'sudo'.
This is a more accurate and appropriate name than 'spark-dev' because
the image is designed to build/run Sparkd and the Spark Api Server (both
of which are daemons, hence the appropriateness of the 'd' suffix). It
isn't designed to build/run the front-end desktop application, Spark.
arham