ashnur · January 21, 2020 10:48 · Dec 29, 2019 · Dec 14, 2019 · Dec 14, 2019 · Dec 14, 2019
diff --git a/Running GUI applications inside Docker containers.md b/Running GUI applications inside Docker containers.md
@@ -17,7 +17,7 @@ applications, and from the user's mouse and keyboard input. Therefore, applicati
 
 So, to run a GUI application in a `docker` container, you've got to provide a way for it
 to communicate to the X server running on the host. One way to go about it is to use `host`
-networking (`--network host`). In this case the container shares the `host`'s networking namespace.
+networking (`--network host`). In this case the container shares the host's networking namespace.
 I.e. container’s network stack is *not* isolated from the Docker host. Particularly, the container
 can connect to any servers running on the host.
 

diff --git a/Running GUI applications inside Docker containers.md b/Running GUI applications inside Docker containers.md
@@ -56,7 +56,7 @@ docker run --rm \
     "${chrome_cmd[@]}"
 ```
 
-If you decide to use `cypress/included` image, you've got to override the default entrypoint (`entrypoint ''`):
+If you decide to use `cypress/included` image, you've got to override the default entrypoint (`--entrypoint ''`):
 
 ```sh
 chrome_cmd=(

diff --git a/Running GUI applications inside Docker containers.md b/Running GUI applications inside Docker containers.md
@@ -1,4 +1,4 @@
-Let's with the basics of how X Window System works. X uses client-server model.
+Let's start with the basics of how X Window System works. X uses client-server model.
 An X server program runs on a computer with a graphical display and communicates
 with various client programs (X clients). The X server acts as a go-between for the user and
 the client programs, accepting requests for graphical output
@@ -18,7 +18,7 @@ applications, and from the user's mouse and keyboard input. Therefore, applicati
 So, to run a GUI application in a `docker` container, you've got to provide a way for it
 to communicate to the X server running on the host. One way to go about it is to use `host`
 networking (`--network host`). In this case the container shares the `host`'s networking namespace.
-I.e. container’s network stack is not isolated from the Docker host. Particularly, the container
+I.e. container’s network stack is *not* isolated from the Docker host. Particularly, the container
 can connect to any servers running on the host.
 
 Also, you've got to let the container authenticate to the X server. Again, one way to achieve this is to use

diff --git a/Running GUI applications inside Docker containers.md b/Running GUI applications inside Docker containers.md
@@ -129,6 +129,20 @@ xvfb-run sh -c '
 [`import`][3] is an ImageMagick utility that captures some or all of an X server screen,
 [`eog`][4] is an image viewer.
 
+And how to run `cypress` tests in a `docker` container:
+
+```sh
+docker run -it --rm \
+    --network host \
+    -v ~/.Xauthority:/root/.Xauthority:ro \
+    -e DISPLAY \
+    -v $PWD:/e2e \
+    -w /e2e \
+    --entrypoint '' \
+    cypress/included:3.6.1 \
+    npx cypress open
+```
+
 [3]: https://imagemagick.org/script/import.php
 [4]: https://wiki.gnome.org/Apps/EyeOfGnome
 

diff --git a/Running GUI applications inside Docker containers.md b/Running GUI applications inside Docker containers.md
@@ -94,7 +94,7 @@ As a bonus, here's how to take a screenshot of a browser running under `xvfb-run
 `./1.sh`:
 
 ```sh
-#!/bin/bash
+#!/usr/bin/env bash
 set -eu
 chrome_cmd=(
     google-chrome

diff --git a/Running GUI applications inside Docker containers.md b/Running GUI applications inside Docker containers.md
@@ -89,7 +89,7 @@ docker container run --rm \
     chromium-browser --no-sandbox
 ```
 
-As a bonus, here's how to make a screenshot of a browser running under `xvfb-run`:
+As a bonus, here's how to take a screenshot of a browser running under `xvfb-run`:
 
 `./1.sh`:
 

diff --git a/Running GUI applications inside Docker containers.md b/Running GUI applications inside Docker containers.md
@@ -126,7 +126,7 @@ xvfb-run sh -c '
 ./1.sh && eog 1.png
 ```
 
-[`import`][3] is one of the ImageMagick utilities that captures some or all of an X server screen,
+[`import`][3] is an ImageMagick utility that captures some or all of an X server screen,
 [`eog`][4] is an image viewer.
 
 [3]: https://imagemagick.org/script/import.php

diff --git a/Running GUI applications inside Docker containers.md b/Running GUI applications inside Docker containers.md
@@ -89,6 +89,49 @@ docker container run --rm \
     chromium-browser --no-sandbox
 ```
 
+As a bonus, here's how to make a screenshot of a browser running under `xvfb-run`:
+
+`./1.sh`:
+
+```sh
+#!/bin/bash
+set -eu
+chrome_cmd=(
+    google-chrome
+        --disable-gpu
+        --no-sandbox
+        --no-first-run
+        https://google.com
+)
+docker run --rm \
+    -v $PWD:/d \
+    -w /d \
+    --entrypoint ./2.sh \
+    cypress/browsers:node12.6.0-chrome77 \
+    "${chrome_cmd[@]}"
+```
+
+`./2.sh`:
+
+```sh
+#!/bin/sh
+xvfb-run sh -c '
+    "$@" \
+    & sleep 2 \
+    && import -window root 1.png
+' -- "$@"
+```
+
+```sh
+./1.sh && eog 1.png
+```
+
+[`import`][3] is one of the ImageMagick utilities that captures some or all of an X server screen,
+[`eog`][4] is an image viewer.
+
+[3]: https://imagemagick.org/script/import.php
+[4]: https://wiki.gnome.org/Apps/EyeOfGnome
+
 P.S. If you do anything memory instensive with Chrome it might crash. That's because by default
 `/dev/shm` size in a `docker` container is 64MB. You can remedy it either by adding
 `--disable-dev-shm-usage` to Chrome, or `--ipc=host` to `docker run`.

diff --git a/Running GUI applications inside Docker containers.md b/Running GUI applications inside Docker containers.md
@@ -38,7 +38,7 @@ that it's okay to run under `root` account:
 [6:6:1214/141504.683039:ERROR:zygote_host_impl_linux.cc(89)] Running as root without --no-sandbox is not supported. See https://crbug.com/638180.
 ```
 
-And `--no-first-run` makes it not show the popup where you can make `Chrome` the default browser, and all.
+And `--no-first-run` makes it not show the Fisrt Launch popup.
 
 ```sh
 chrome_cmd=(

diff --git a/Running GUI applications inside Docker containers.md b/Running GUI applications inside Docker containers.md
@@ -43,6 +43,7 @@ And `--no-first-run` makes it not show the popup where you can make `Chrome` the
 ```sh
 chrome_cmd=(
     google-chrome
+        --disable-gpu
         --no-sandbox
         --no-first-run
         https://google.com
@@ -55,8 +56,7 @@ docker run --rm \
     "${chrome_cmd[@]}"
 ```
 
-If you decide to use `cypress/included` image, you've got to add `--disable-gpu` flag for Chrome,
-or else it won't start for some reason. And override the default entrypoint (`entrypoint ''`):
+If you decide to use `cypress/included` image, you've got to override the default entrypoint (`entrypoint ''`):
 
 ```sh
 chrome_cmd=(

diff --git a/Running GUI applications inside Docker containers.md b/Running GUI applications inside Docker containers.md
@@ -31,7 +31,7 @@ the `DISPLAY` variable from the host into the container (`--env DISPLAY`).
 
 [1]: https://www.x.org/archive/X11R6.8.1/doc/X.7.html#sect4
 
-As for the Chrome we need `--disable-gpu` flag. Otherwise it won't start. `--no-sandbox` tells it
+As for Chrome we need `--disable-gpu` flag. Otherwise it won't start. `--no-sandbox` tells it
 that it's okay to run under `root` account:
 
 ```
@@ -43,7 +43,6 @@ And `--no-first-run` makes it not show the popup where you can make `Chrome` the
 ```sh
 chrome_cmd=(
     google-chrome
-        --disable-gpu
         --no-sandbox
         --no-first-run
         https://google.com
@@ -52,30 +51,49 @@ docker run --rm \
     --network host \
     --volume ~/.Xauthority:/root/.Xauthority:ro \
     --env DISPLAY \
-    --entrypoint sh \
-    cypress/included:3.6.1 \
-    -c "${chrome_cmd[*]@Q}"
+    cypress/browsers:node12.6.0-chrome77 \
+    "${chrome_cmd[@]}"
 ```
 
-If you do anything memory instensive with Chrome it might crash. That's because by default
-`/dev/shm` size in a `docker` container is 64MB. You can remedy it either by adding
-`--disable-dev-shm-usage` to `google-chrome`, or `--ipc=host` to `docker run`.
-More on it here:
+If you decide to use `cypress/included` image, you've got to add `--disable-gpu` flag for Chrome,
+or else it won't start for some reason. And override the default entrypoint (`entrypoint ''`):
 
-https://sondnm.github.io/blog/2018/09/08/i-just-learnt-about-/dev/shm/
-https://peter.sh/experiments/chromium-command-line-switches/
-https://docs.docker.com/engine/reference/run/#ipc-settings---ipc
+```sh
+chrome_cmd=(
+    google-chrome
+        --disable-gpu
+        --no-sandbox
+        --no-first-run
+        https://google.com
+)
+docker run --rm \
+    --network host \
+    --volume ~/.Xauthority:/root/.Xauthority:ro \
+    --env DISPLAY \
+    --entrypoint '' \
+    cypress/included:3.8.0 \
+    "${chrome_cmd[@]}"
+```
 
-Or using [`zenika/alpine-chrome`][2] image:
+Or using the [`zenika/alpine-chrome`][2] image:
 
 [2]: https://hub.docker.com/r/zenika/alpine-chrome/
 
-```
+```sh
 docker container run --rm \
     --network=host \
     --volume ~/.Xauthority:/home/chrome/.Xauthority:ro \
     --env DISPLAY \
     --entrypoint '' \
     zenika/alpine-chrome \
     chromium-browser --no-sandbox
-```
+```
+
+P.S. If you do anything memory instensive with Chrome it might crash. That's because by default
+`/dev/shm` size in a `docker` container is 64MB. You can remedy it either by adding
+`--disable-dev-shm-usage` to Chrome, or `--ipc=host` to `docker run`.
+More on it here:
+
+https://sondnm.github.io/blog/2018/09/08/i-just-learnt-about-/dev/shm/
+https://peter.sh/experiments/chromium-command-line-switches/
+https://docs.docker.com/engine/reference/run/#ipc-settings---ipc
diff --git a/Running GUI applications inside Docker containers.md b/Running GUI applications inside Docker containers.md
@@ -21,7 +21,7 @@ networking (`--network host`). In this case the container shares the `host`'s ne
 I.e. container’s network stack is not isolated from the Docker host. Particularly, the container
 can connect to any servers running on the host.
 
-Also, you've got to let the container authenticate to the X server. Again, one way is to use
+Also, you've got to let the container authenticate to the X server. Again, one way to achieve this is to use
 cookie-based authentication. For that you've got to share the `~/.Xauthority` file with the container
 (`--volume ~/.Xauthority:/root/.Xauthority:ro`).
 

diff --git a/Running GUI applications inside Docker containers.md b/Running GUI applications inside Docker containers.md
@@ -16,7 +16,7 @@ applications, and from the user's mouse and keyboard input. Therefore, applicati
 ![](https://upload.wikimedia.org/wikipedia/commons/thumb/0/03/X_client_server_example.svg/250px-X_client_server_example.svg.png)
 
 So, to run a GUI application in a `docker` container, you've got to provide a way for it
-to communicate to the X server running on the host. One way to go about it is to `host`
+to communicate to the X server running on the host. One way to go about it is to use `host`
 networking (`--network host`). In this case the container shares the `host`'s networking namespace.
 I.e. container’s network stack is not isolated from the Docker host. Particularly, the container
 can connect to any servers running on the host.
@@ -66,7 +66,9 @@ https://sondnm.github.io/blog/2018/09/08/i-just-learnt-about-/dev/shm/
 https://peter.sh/experiments/chromium-command-line-switches/
 https://docs.docker.com/engine/reference/run/#ipc-settings---ipc
 
-Or using `zenika/alpine-chrome` image:
+Or using [`zenika/alpine-chrome`][2] image:
+
+[2]: https://hub.docker.com/r/zenika/alpine-chrome/
 
 ```
 docker container run --rm \

diff --git a/Running GUI applications inside Docker containers.md b/Running GUI applications inside Docker containers.md
@@ -0,0 +1,79 @@
+Let's with the basics of how X Window System works. X uses client-server model.
+An X server program runs on a computer with a graphical display and communicates
+with various client programs (X clients). The X server acts as a go-between for the user and
+the client programs, accepting requests for graphical output
+from the client programs and displaying them to the user (display),
+and receiving user input (keyboard, mouse) and transmitting it to the client programs.
+
+In X, the server runs on the user's computer, while the clients may run on remote machines.
+This terminology reverses the common notion of client–server systems, where the client
+normally runs on the user's local computer and the server runs on the remote computer.
+The X Window terminology takes the perspective that the X Window program is at the
+centre of all activity, i.e. the X Window program accepts and responds to requests from
+applications, and from the user's mouse and keyboard input. Therefore, applications
+(on remote computers) are viewed as clients of the X Window server program.
+
+![](https://upload.wikimedia.org/wikipedia/commons/thumb/0/03/X_client_server_example.svg/250px-X_client_server_example.svg.png)
+
+So, to run a GUI application in a `docker` container, you've got to provide a way for it
+to communicate to the X server running on the host. One way to go about it is to `host`
+networking (`--network host`). In this case the container shares the `host`'s networking namespace.
+I.e. container’s network stack is not isolated from the Docker host. Particularly, the container
+can connect to any servers running on the host.
+
+Also, you've got to let the container authenticate to the X server. Again, one way is to use
+cookie-based authentication. For that you've got to share the `~/.Xauthority` file with the container
+(`--volume ~/.Xauthority:/root/.Xauthority:ro`).
+
+And you've got to tell the container where the X server is running. For that the [`DISPLAY` variable][1] is used.
+Since the container is going to have access to the host's network namespace, you can simply pass
+the `DISPLAY` variable from the host into the container (`--env DISPLAY`).
+
+[1]: https://www.x.org/archive/X11R6.8.1/doc/X.7.html#sect4
+
+As for the Chrome we need `--disable-gpu` flag. Otherwise it won't start. `--no-sandbox` tells it
+that it's okay to run under `root` account:
+
+```
+[6:6:1214/141504.683039:ERROR:zygote_host_impl_linux.cc(89)] Running as root without --no-sandbox is not supported. See https://crbug.com/638180.
+```
+
+And `--no-first-run` makes it not show the popup where you can make `Chrome` the default browser, and all.
+
+```sh
+chrome_cmd=(
+    google-chrome
+        --disable-gpu
+        --no-sandbox
+        --no-first-run
+        https://google.com
+)
+docker run --rm \
+    --network host \
+    --volume ~/.Xauthority:/root/.Xauthority:ro \
+    --env DISPLAY \
+    --entrypoint sh \
+    cypress/included:3.6.1 \
+    -c "${chrome_cmd[*]@Q}"
+```
+
+If you do anything memory instensive with Chrome it might crash. That's because by default
+`/dev/shm` size in a `docker` container is 64MB. You can remedy it either by adding
+`--disable-dev-shm-usage` to `google-chrome`, or `--ipc=host` to `docker run`.
+More on it here:
+
+https://sondnm.github.io/blog/2018/09/08/i-just-learnt-about-/dev/shm/
+https://peter.sh/experiments/chromium-command-line-switches/
+https://docs.docker.com/engine/reference/run/#ipc-settings---ipc
+
+Or using `zenika/alpine-chrome` image:
+
+```
+docker container run --rm \
+    --network=host \
+    --volume ~/.Xauthority:/home/chrome/.Xauthority:ro \
+    --env DISPLAY \
+    --entrypoint '' \
+    zenika/alpine-chrome \
+    chromium-browser --no-sandbox
+```