gvisor.dev: Update WordPress example to recommend not sandboxing the database.

PiperOrigin-RevId: 465654131

g3doc/user_guide/tutorials/docker-compose.md

@@ -16,7 +16,14 @@ We will specify two services, a `wordpress` service for the Wordpress Apache
 server, and a `db` service for MySQL. We will configure Wordpress to connect to
 MySQL via the `db` service host name.
 
-> **Note:** Docker Compose uses it's own network by default and allows services
+> **Note**: This example uses gVisor to sandbox the frontend web server, but not
+> the MySQL database backend. In a production setup, due to
+> [the I/O overhead](../../architecture_guide/performance) imposed by gVisor,
+> **it is not recommended to run your database in a sandbox**. The frontend is
+> the critical component with the largest outside attack surface, where gVisor's
+> security/performance trade-off makes the most sense.
+
+> **Note**: Docker Compose uses it's own network by default and allows services
 > to communicate using their service name. Docker Compose does this by setting
 > up a DNS server at IP address 127.0.0.11 and configuring containers to use it
 > via [resolv.conf][resolv.conf]. This IP is not addressable inside a gVisor
@@ -24,7 +31,7 @@ MySQL via the `db` service host name.
 > `8.8.8.8` and use a network that allows routing to it. See
 > [Networking in Compose][compose-networking] for more details.
 
-> **Note:** The `runtime` field was removed from services in the 3.x version of
+> **Note**: The `runtime` field was removed from services in the 3.x version of
 > the API in versions of docker-compose < 1.27.0. You will need to write your
 > `docker-compose.yaml` file using the 2.x format or use docker-compose >=
 > 1.27.0. See this [issue](https://github.com/docker/compose/issues/6239) for
@@ -46,6 +53,8 @@ services:
        MYSQL_PASSWORD: wordpress
      # All services must be on the same network to communicate.
      network_mode: "bridge"
+     # Uncomment the following line if you want to sandbox the database.
+     #runtime: "runsc"
 
    wordpress:
      depends_on:

g3doc/user_guide/tutorials/docker.md

@@ -13,6 +13,13 @@ document assumes that the runtime name chosen is `runsc`.
 Now, let's deploy a WordPress site using Docker. WordPress site requires two
 containers: web server in the frontend, MySQL database in the backend.
 
+> **Note**: This example uses gVisor to sandbox the frontend web server, but not
+> the MySQL database backend. In a production setup, due to
+> [the I/O overhead](../../architecture_guide/performance) imposed by gVisor,
+> **it is not recommended to run your database in a sandbox**. The frontend is
+> the critical component with the largest outside attack surface, where gVisor's
+> security/performance trade-off makes the most sense.
+
 First, let's define a few environment variables that are shared between both
 containers:
 
@@ -25,38 +32,40 @@ export MYSQL_USER=wordpress
 Next, let's start the database container running MySQL and wait until the
 database is initialized:
 
-```bash
-docker run --runtime=runsc --name mysql -d \
-  -e MYSQL_RANDOM_ROOT_PASSWORD=1 \
-  -e MYSQL_PASSWORD="${MYSQL_PASSWORD}" \
-  -e MYSQL_DATABASE="${MYSQL_DB}" \
-  -e MYSQL_USER="${MYSQL_USER}" \
-  mysql:5.7
+```shell
+# If you want to sandbox the database, add --runtime=runsc to this command.
+$ docker run --name mysql -d \
+    -e MYSQL_RANDOM_ROOT_PASSWORD=1 \
+    -e MYSQL_PASSWORD="${MYSQL_PASSWORD}" \
+    -e MYSQL_DATABASE="${MYSQL_DB}" \
+    -e MYSQL_USER="${MYSQL_USER}" \
+    mysql:5.7
 
 # Wait until this message appears in the log.
-docker logs mysql |& grep 'port: 3306  MySQL Community Server (GPL)'
+$ docker logs mysql |& grep 'port: 3306  MySQL Community Server (GPL)'
 ```
 
 Once the database is running, you can start the WordPress frontend. We use the
 `--link` option to connect the frontend to the database, and expose the
 WordPress to port 8080 on the localhost.
 
-```bash
-docker run --runtime=runsc --name wordpress -d \
-  --link mysql:mysql \
-  -p 8080:80 \
-  -e WORDPRESS_DB_HOST=mysql \
-  -e WORDPRESS_DB_USER="${MYSQL_USER}" \
-  -e WORDPRESS_DB_PASSWORD="${MYSQL_PASSWORD}" \
-  -e WORDPRESS_DB_NAME="${MYSQL_DB}" \
-  -e WORDPRESS_TABLE_PREFIX=wp_ \
-  wordpress
+```shell
+$ docker run --runtime=runsc --name wordpress -d \
+    --link mysql:mysql \
+    -p 8080:80 \
+    -e WORDPRESS_DB_HOST=mysql \
+    -e WORDPRESS_DB_USER="${MYSQL_USER}" \
+    -e WORDPRESS_DB_PASSWORD="${MYSQL_PASSWORD}" \
+    -e WORDPRESS_DB_NAME="${MYSQL_DB}" \
+    -e WORDPRESS_TABLE_PREFIX=wp_ \
+    wordpress
 ```
 
 Now, you can access the WordPress website pointing your favorite browser to
 <http://localhost:8080>.
 
-Congratulations! You have just deployed a WordPress site using Docker.
+Congratulations! You have just deployed a WordPress site using Docker and
+gVisor.
 
 ### What's next
 

g3doc/user_guide/tutorials/kubernetes.md

@@ -48,6 +48,13 @@ two pods: web server in the frontend, MySQL database in the backend. Both
 applications use PersistentVolumes to store the site data data. In addition,
 they use secret store to share MySQL password between them.
 
+> **Note**: This example uses gVisor to sandbox the frontend web server, but not
+> the MySQL database backend. In a production setup, due to
+> [the I/O overhead](../../architecture_guide/performance) imposed by gVisor,
+> **it is not recommended to run your database in a sandbox**. The frontend is
+> the critical component with the largest outside attack surface, where gVisor's
+> security/performance trade-off makes the most sense.
+
 First, let's download the deployment configuration files to add the runtime
 class annotation to them:
 
@@ -181,7 +188,7 @@ spec:
         app: wordpress
         tier: mysql
     spec:
-      runtimeClassName: gvisor   # ADD THIS LINE
+      #runtimeClassName: gvisor  # Uncomment this line if you want to sandbox the database.
       containers:
       - image: mysql:5.6
         name: mysql