Fix outdated Docker instructions (#559)

Author: ErikSchierboom

building/tooling/analyzers/docker.md

@@ -2,12 +2,43 @@
 
 Our Analyzers are deployed as Docker images.
 
-Please read the [general tooling Docker information](/docs/building/tooling/docker) to familiarize yourself with how these work.
+Please read the [general Tooling docker information](/docs/building/tooling/docker) to familiarize yourself with how these work.
 
-When we run the Analyzer's container we execute a `run.sh` script.
-To ensure this works properly the following rules must be following:
+## Integration
 
+When we run an Analyzer to analyze a solution, we run a Docker command that looks like this:
+
+```shell
+docker run \
+        --rm \
+        --network none \
+        --mount type=bind,src="${solution_dir}",dst=/solution \
+        --mount type=bind,src="${output_dir}",dst=/output \
+        --tmpfs /tmp:rw \
+        "exercism/${track_slug}-analyzer" \
+        "${exercise_slug}" "/solution" "/output"
+```
+
+You can see that we pass three arguments to the Docker image:
+
+1. The exercise slug
+2. The path to the solution's directory
+3. The path to the output directory
+
+## Conventions
+
+All our Analyzers use the following conventions in their implementation:
+
+- The `Dockerfile` is in the repo's root directory.
 - The working directory should be `/opt/analyzer`.
-- There should be a `/opt/analyzer/bin/run.sh` script that can be called with 3 parameters:
-  the `exercise slug`, the path to the `solution folder`, and the path to the `output folder`.
-  For more information see [The Interface](/docs/building/tooling/analyzers/interface).
+- The entrypoint is `/opt/analyzer/bin/run.sh`
+- The `/opt/analyzer/bin/run.sh` script takes 3 arguments:
+  1. The exercise slug
+  2. The path to the solution's directory
+  3. The path to the output directory
+
+For more information see [The Interface](/docs/building/tooling/analyzer/interface).
+
+```exercism/note
+New analyzer repos will use these conventions by default.
+```

building/tooling/representers/docker.md

@@ -4,10 +4,41 @@ Our Representers are deployed as Docker images.
 
 Please read the [general Tooling docker information](/docs/building/tooling/docker) to familiarize yourself with how these work.
 
-When we run the Representer's container we execute a `run.sh` script.
-To ensure this works properly the following rules must be following:
+## Integration
 
+When we run a Representer to create a solution representation, we run a Docker command that looks like this:
+
+```shell
+docker run \
+        --rm \
+        --network none \
+        --mount type=bind,src="${solution_dir}",dst=/solution \
+        --mount type=bind,src="${output_dir}",dst=/output \
+        --tmpfs /tmp:rw \
+        "exercism/${track_slug}-representer" \
+        "${exercise_slug}" "/solution" "/output"
+```
+
+You can see that we pass three arguments to the Docker image:
+
+1. The exercise slug
+2. The path to the solution's directory
+3. The path to the output directory
+
+## Conventions
+
+All our Representers use the following conventions in their implementation:
+
+- The `Dockerfile` is in the repo's root directory.
 - The working directory should be `/opt/representer`.
-- There should be a `/opt/representer/bin/run.sh` script that can be called with 3 parameters:
-  the `exercise slug`, the path to the `solution folder`, and the path to the `output folder`.
-  For more information see [The Interface](/docs/building/tooling/representers/interface).
+- The entrypoint is `/opt/representer/bin/run.sh`
+- The `/opt/representer/bin/run.sh` script takes 3 arguments:
+  1. The exercise slug
+  2. The path to the solution's directory
+  3. The path to the output directory
+
+For more information see [The Interface](/docs/building/tooling/test-runners/interface).
+
+```exercism/note
+New representer repos will use these conventions by default.
+```

building/tooling/test-runners/docker.md

@@ -4,10 +4,41 @@ Our Test Runners are deployed as Docker images.
 
 Please read the [general Tooling docker information](/docs/building/tooling/docker) to familiarize yourself with how these work.
 
-When we run the Test Runner's container we execute a `run.sh` script.
-To ensure this works properly the following rules must be following:
+## Integration
 
+When we run a Test Runner to test a solution, we run a Docker command that looks like this:
+
+```shell
+docker run \
+        --rm \
+        --network none \
+        --mount type=bind,src="${solution_dir}",dst=/solution \
+        --mount type=bind,src="${output_dir}",dst=/output \
+        --tmpfs /tmp:rw \
+        "exercism/${track_slug}-test-runner" \
+        "${exercise_slug}" "/solution" "/output"
+```
+
+You can see that we pass three arguments to the Docker image:
+
+1. The exercise slug
+2. The path to the solution's directory
+3. The path to the output directory
+
+## Conventions
+
+All our test runners use the following conventions in their implementation:
+
+- The `Dockerfile` is in the repo's root directory.
 - The working directory should be `/opt/test-runner`.
-- There should be a `/opt/test-runner/bin/run.sh` script that can be called with 3 parameters:
-  the `exercise slug`, the path to the `solution folder`, and the path to the `output folder`.
-  For more information see [The Interface](/docs/building/tooling/test-runners/interface).
+- The entrypoint is `/opt/test-runner/bin/run.sh`
+- The `/opt/test-runner/bin/run.sh` script takes 3 arguments:
+  1. The exercise slug
+  2. The path to the solution's directory
+  3. The path to the output directory
+
+For more information see [The Interface](/docs/building/tooling/test-runners/interface).
+
+```exercism/note
+New test runner repos will use these conventions by default.
+```