* DockerHub-README.md: reword ambiguous command
Being unfamiliar with the docker options, I thought the square brackets could be part of the command.
Instead, they refer to the sentence *after* the command, that is, they meant "optionally".
To remove the ambiguity, I put into onto different lines with an explanation.
* DockerHub-README.md: reword again, -v by default
- only leave the command with -v as an example
- grammar
- httpS link
Current docker-entrypoint.sh [0][1] runs
gosu mitmproxy "$@"
for mitmproxy, mitmdump and mitmweb. There is a problem with this
approach: bash becomes a parent process for mitmproxy [2][3], but when
signals are sent by docker-compose to mitmproxy container they are sent
to bash, but they are not delivered to mitmproxy [4]. This leads to a
slow shutdown of the container, because by default docker sends SIGTERM,
waits for 10 seconds and then sends SIGKILL if the container is still
alive [5].
This patch solves the issue by replacing bash process with mitmproxy
entirely using "exec" - this way the signals are delivered to mitmproxy
directly.
To test the patch a Dockerfile [6] that applies the patch to the release
image from the dockerhub could be used along with slighly modified
compose.yml [7]. With the patch bash is no longer running inside the
container [8] and the `docker compose down` time on my machine drops
from 10.3s to 0.5s [9].
0. https://github.com/mitmproxy/mitmproxy/blob/main/release/docker/docker-entrypoint.sh
1. To confirm that this is what's actually in the image:
```
> docker run mitmproxy/mitmproxy grep gosu /usr/local/bin/docker-entrypoint.sh
gosu mitmproxy "$@"
```
2. compose.yaml
```
services:
mitmproxy-test:
image: mitmproxy/mitmproxy
command: ["mitmweb"]
# https://github.com/mitmproxy/mitmproxy/issues/5727
stdin_open: true
tty: true
```
3. We can see that the parent PID for mitmweb is the pid of bash.
```
> docker compose up -d
[+] Running 2/2
⠿ Network mitmproxy_default Created 0.1s
⠿ Container mitmproxy-mitmproxy-test-1 Started 0.5s
> docker compose top
mitmproxy-mitmproxy-test-1
UID PID PPID C STIME TTY TIME CMD
root 31227 31202 0 16:12 pts/0 00:00:00 /bin/bash /usr/local/bin/docker-entrypoint.sh mitmweb
root 31314 31227 1 16:12 pts/0 00:00:01 /usr/local/bin/python /usr/local/bin/mitmweb
```
4. https://unix.stackexchange.com/a/196053
5. https://docs.docker.com/compose/faq/#why-do-my-services-take-10-seconds-to-recreate-or-stop
6. Dockerfile:
```
FROM mitmproxy/mitmproxy
RUN sed -i 's/^ gosu mitmproxy/ exec gosu mitmproxy/' /usr/local/bin/docker-entrypoint.sh
```
7. compose.yaml to build an image from Dockerfile and use it:
```
services:
mitmproxy-test:
build:
dockerfile: Dockerfile
context: .
command: ["mitmweb"]
# https://github.com/mitmproxy/mitmproxy/issues/5727
stdin_open: true
tty: true
```
8. With the patch:
```
> docker compose top
mitmproxy-mitmproxy-test-1
UID PID PPID C STIME TTY TIME CMD
root 4994 4970 50 17:00 pts/0 00:00:02 /usr/local/bin/python /usr/local/bin/mitmweb
```
9. Without the patch:
```
> docker compose down
[+] Running 2/2
⠿ Container mitmproxy-mitmproxy-test-1 Removed 10.2s
⠿ Network mitmproxy_default Removed 0.1s
```
With the patch:
```
> docker compose down
[+] Running 2/2
⠿ Container mitmproxy-mitmproxy-test-1 Removed 0.4s
⠿ Network mitmproxy_default Removed 0.1s
```
it turns out pull requests from trusted contributors do have access to secrets,
so we can't do that check. Checking for the repo only doesn't make much sense.
This greatly improves startup time as pyinstaller doesn't have to
unpack everything on startup. The same also applies to macOS and Linux,
but there we 1) don't have installers to hide all the files and
2) have a filesystem that deals much better with lots of small files.
Additionally, simplify cibuild to be a bit more reasonable.
Vadim