* Rebuilding the image will not accidentally assign a different UID to `bugsink`
this would be "extremely annoying" in the context of bind-mounts and volumes.
* Ensures predictable ownership for bind-mounts and Docker volumes at build time.
* Avoids collisions with existing host accounts
Considerations for 14237:
* well below the 65535 limit, keeping it compatible with default subuid/subgid mappings.
* Positioned above 1000 to steer clear of standard system and regular user ranges.
* Not so large that older filesystems or tooling (e.g., simple NFS exports) might have issues.
See #176
Before this commit, the COPY command was still used to copy-over 2 files from
the working dir. Alhtough this was probably fine in practice (docker build
typically happens from a checked out state that matches the wheel you're
docker-building) it's not what's on the tin ("from wheel") and it opens up
the possiblity of subtle bugs (file mismatches when building from a different
state). Better prevent those.
My reasoning is twofold:
1. a count of 1 is actually probably "enough for many setups" because ingestion
is very fast anyway (just store the file); while the lower memory-footprint
that comes with having fewer workers means that adoption of Bugsink will be
easier.
2. tuning the variable is going to be less annoying if there's no default that
might override "in the wrong direction" (i.e. the interaction between
`WEB_CONCURRENCY` and `GUNICORN_CMD_ARGS`)
See #101 (where the concept of customizability was discussed, though not the
present idea of chaning the default).
Our goal with having Docker in the first place is to make it easy to
deploy the application. 'just migrating' is a good idea for that goal
in general, but the more so because running migration commands when
the container isn't running yet, while the container refuses to run
without them having run putch you in a catch-22.
(the above may not be strictly true when you run with a database that's
external to your image, i.e. with mysql, because then you can use 'run'
rather than 'exec', but even that feels a bit 'wrongish', because run
starts a container that is then left around for `docker ps -a` to see)
for sqlite containers it's even more pressing, because the writes-to-db
go to different databases for each of the incantations of run (including
server-start). Even if I get this to work (I can't find the solution
in 15 minutes) it will be so clunky to be unworkable.
Theoretical concerns about not migrating on-server-start (but rather,
as part of some CI/CD script or something) will have take take a back-seat
to the reasoning above... if they even hold up at all).
This is more canonical with stuff 'elsewhere on the internet'
we already did it behind-the-scenes for 'recommended gunicorn', so the
harmonization is in having the same default for the rest.
* I'd rather harmonize with "the docker way" than with my own recommended setup
* slim: expectation is that this is smaller (not checked)
* this is a 2-stage build (slim has no gcc, needed for mysql)
* PEP668 does not apply here ("externally managed"), which leads to
* better ergonomics: no env/bin/some-command
