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.
This way we can all use the same dev image. It also means one less
variable in our containers that paths/scripts need to account for.
VS Code can automatically update the remote user's uid in the container
to avoid permission issues in mounted dirs.
Changes to Docker-related files/configuration don't occur in a vacuum.
They are made in coordination with changes to the main repository, so it
doesn't make sense to track them separately.
Note: Removing the 'windows' Docker files completely. No one has has
used them in a long, long time. The client build would be broken in
there anyways, the image is based on .NET Framework 3.5!
John Colvin