README.md: Run prettier.

Author: alexmv

README.md

@@ -6,15 +6,15 @@ This is a container image for running [Zulip](https://zulip.com)
 ([GitHub](https://github.com/zulip/zulip)) in
 [production][prod-overview]. Image available from:
 
-* [**Docker Hub**](https://hub.docker.com/r/zulip/docker-zulip) (`docker pull zulip/docker-zulip:5.7-0`)
+- [**Docker Hub**](https://hub.docker.com/r/zulip/docker-zulip) (`docker pull zulip/docker-zulip:5.7-0`)
 
 Current Zulip version: `5.7`
 Current Docker image version: `5.7-0`
 
-Project status: **Alpha**.  While this project works and is
+Project status: **Alpha**. While this project works and is
 used by many sites in production, configuring is substantially more
 error-prone than the [normal Zulip installer][normal-install] (which
-Just Works).  We recommend this project if you want to host Zulip
+Just Works). We recommend this project if you want to host Zulip
 using Docker, but both setting up and maintaining a Zulip server is
 simpler and less error-prone with the normal installer than with Docker.
 
@@ -41,17 +41,17 @@ next section.
 ### The Docker data storage model
 
 Docker and other container systems are built around shareable
-container images.  An image is a read-only template with instructions
-for creating a container.  Often, an image is based on another image,
-with a bit of additional customization.  For example, Zulip's
+container images. An image is a read-only template with instructions
+for creating a container. Often, an image is based on another image,
+with a bit of additional customization. For example, Zulip's
 `zulip-postgresql` image extends the standard `postgresql` image (by
-installing a couple `postgres` extensions).  And the `zulip` image is
+installing a couple `postgres` extensions). And the `zulip` image is
 built on top of a standard `ubuntu` image, adding all the code for a Zulip
 application/web server.
 
 Every time you boot a container based on a given image, it's like
 booting off a CD-ROM: you get the exact same image (and anything
-written to the image's filesystem is lost).  To handle persistent
+written to the image's filesystem is lost). To handle persistent
 state that needs to persist after the Docker equivalent of a reboot or
 upgrades (like uploaded files or the Zulip database), container
 systems let you configure certain directories inside the container
@@ -69,19 +69,19 @@ backed up, to ensure that Zulip's data is backed up.
 
 To use `docker-zulip`, you need the following:
 
-* An installation of [Docker][install-docker] and
+- An installation of [Docker][install-docker] and
   [Docker Compose][install-docker-compose] or a Kubernetes runtime
   engine.
-* We [recommend at least 2GB of available RAM][prod-requirements] for
+- We [recommend at least 2GB of available RAM][prod-requirements] for
   running a production Zulip server; you'll want 4GB if you're
-  building the container (rather than using the prebuilt images).  If
+  building the container (rather than using the prebuilt images). If
   you're just testing and/or aren't expecting a lot of users/messages,
   you can get away with significantly less especially for the
   `postgres`, `memcached`, etc. containers, because Docker makes it
   easy to sharply limit the RAM allocated to the services Zulip
   depends on, like redis, memcached, and postgresql (at the cost of
   potential performance issues).
-* This project doesn't support `docker-rootless`; Zulip needs root
+- This project doesn't support `docker-rootless`; Zulip needs root
   access to set properties like the maximum number of open file
   descriptions via `ulimit` (which is important for it to handle
   thousands of connected clients).
@@ -113,62 +113,62 @@ setting environment variables declared in the `zulip -> environment`
 section of the `docker-compose.yml` file; this image follows that
 convention.
 
-**Mandatory settings**.  You must configure these settings (more
+**Mandatory settings**. You must configure these settings (more
 discussion in the main [Zulip installation docs][install-normal]):
 
-* `SETTING_EXTERNAL_HOST`: The hostname your users will use to
-  connect to your Zulip server.  If you're testing on your laptop,
+- `SETTING_EXTERNAL_HOST`: The hostname your users will use to
+  connect to your Zulip server. If you're testing on your laptop,
   the default of `localhost.localdomain` is great.
-* `SETTING_ZULIP_ADMINISTRATOR`: The email address to receive error
+- `SETTING_ZULIP_ADMINISTRATOR`: The email address to receive error
   and support emails generated by the Zulip server and its users.
 
-**Mandatory settings for serious use**.  Before you allow
+**Mandatory settings for serious use**. Before you allow
 production traffic, you need to also set these:
 
-* `POSTGRES_PASSWORD` and `SECRETS_postgres_password` should both be a
+- `POSTGRES_PASSWORD` and `SECRETS_postgres_password` should both be a
   password for the Zulip container to authenticate to the Postgres
-  container.  Since you won't use this directly, you just want a long,
-  randomly generated string.  While `SECRETS_postgres_password` is
+  container. Since you won't use this directly, you just want a long,
+  randomly generated string. While `SECRETS_postgres_password` is
   synced to the Zulip container on every boot, `POSTGRES_PASSWORD` is
   only accessed by the postgres container on first boot, so if you
   later want to change your postgres password after booting the
   container, you'll need to either do an
   [ALTER ROLE][postgres-alter-role] query inside the `postgres`
   container or rebuild the postgres database (only if you don't need
   your data!).
-* `RABBITMQ_DEFAULT_PASS` and `SECRETS_rabbitmq_password` are similar,
+- `RABBITMQ_DEFAULT_PASS` and `SECRETS_rabbitmq_password` are similar,
   just for the RabbitMQ container.
-* `MEMCACHED_PASSWORD` and `SECRETS_memcached_password` are similar,
+- `MEMCACHED_PASSWORD` and `SECRETS_memcached_password` are similar,
   just for the memcached container.
-* `REDIS_PASSWORD` and `SECRETS_redis_password` are similar, just for
+- `REDIS_PASSWORD` and `SECRETS_redis_password` are similar, just for
   the Redis container.
-* `SECRETS_secret_key` should be a long (e.g. 50 characters), random
-  string.  This value is important to keep secret and constant over
+- `SECRETS_secret_key` should be a long (e.g. 50 characters), random
+  string. This value is important to keep secret and constant over
   time, since it is used to (among other things) sign login cookies
   (so if you change this, all your users will be forcibly logged out).
-* `SETTING_EMAIL_*`: Where you configure Zulip's ability to send
+- `SETTING_EMAIL_*`: Where you configure Zulip's ability to send
   [outgoing email][outgoing-email].
 
 [postgres-alter-role]: https://www.postgresql.org/docs/9.3/static/sql-alterrole.html
 
 **Other settings**. If an environment variable name doesn't start with
 `SETTING` or `SECRETS` in `docker-compose.yml`, it is specific to the
-Docker environment.  Standard [Zulip server settings][server-settings]
+Docker environment. Standard [Zulip server settings][server-settings]
 are secrets are set using the following syntax:
 
-* `SETTING_MY_SETTING` will become `MY_SETTING` in
+- `SETTING_MY_SETTING` will become `MY_SETTING` in
   `/etc/zulip/settings.py`
-* `SECRETS_my_secret` will become `my_secret` in
+- `SECRETS_my_secret` will become `my_secret` in
   `/etc/zulip/zulip-secrets.conf`.
 
 Reading the comments in the sample
 [Zulip's settings.py file][prod-settings-template] is the best way to
 learn about the full set of Zulip's supported server-level settings.
 
 Most settings in Zulip are just strings, but some are lists (etc.)
-which you need to encode in the YAML file.  For example,
+which you need to encode in the YAML file. For example,
 
-* For `AUTHENTICATION_BACKENDS`, you enter `ZULIP_AUTH_BACKENDS` as a
+- For `AUTHENTICATION_BACKENDS`, you enter `ZULIP_AUTH_BACKENDS` as a
   comma-separated list of the backend names
   (E.g. `"EmailAuthBackend,GitHubAuthBackend"`).
 
@@ -179,9 +179,9 @@ the multithreaded mode). This algorithm might see the host's memory, not the
 docker container's memory. Set to `QUEUE_WORKERS_MULTIPROCESS` to `true` or
 `false` to override the automatic calculation.
 
-**SSL Certificates**.  By default, the image will generate a self-signed cert.
+**SSL Certificates**. By default, the image will generate a self-signed cert.
 You can set `SSL_CERTIFICATE_GENERATION: "certbot"` within `docker-compose.yml`
-to enable automatically-renewed Let's Encrypt certificates.  By using certbot
+to enable automatically-renewed Let's Encrypt certificates. By using certbot
 here, you are agreeing to the [Let's Encrypt
 ToS](https://community.letsencrypt.org/tos).
 
@@ -203,12 +203,12 @@ The way the environment variables configuration process described in
 the last section works is that the `entrypoint.sh` script that runs
 when the Docker image starts up will generate a
 [Zulip settings.py file][server-settings] file based on your settings
-every time you boot the container.  This is convenient, in that you
+every time you boot the container. This is convenient, in that you
 only need to edit the `docker-compose.yml` file to configure your
 Zulip server's settings.
 
 An alternative approach is to set `MANUAL_CONFIGURATION: "True"` and
-`LINK_SETTINGS_TO_DATA: "True"` in `docker-compose.yml`.  If you do that, you
+`LINK_SETTINGS_TO_DATA: "True"` in `docker-compose.yml`. If you do that, you
 can provide a `settings.py` file and a `zulip-secrets.conf` file in
 `/opt/docker/zulip/zulip/settings/etc-zulip/`, and the container will use those.
 
@@ -221,7 +221,7 @@ docker-compose pull
 docker-compose up
 ```
 
-This will boot the 5 containers declared in `docker-compose.yml`.  The
+This will boot the 5 containers declared in `docker-compose.yml`. The
 `docker-compose` command will print a bunch of output, and then
 eventually hang once everything is happily booted, usually ending with
 a bunch of lines like this:
@@ -236,7 +236,7 @@ You can inspect what containers are running in another shell with
 `docker-compose ps` (remember to `cd` into the `docker-zulip`
 directory first).
 
-If you hit `Ctrl-C`, that will stop your Zulip server cluster.  If
+If you hit `Ctrl-C`, that will stop your Zulip server cluster. If
 you'd prefer to have the containers run in the background, you can use
 `docker-compose up -d`.
 
@@ -246,10 +246,10 @@ running `docker-compose build`; see also
 
 ### Connecting to your Zulip server
 
-You can now connect to your Zulip server.  For example, if you set
+You can now connect to your Zulip server. For example, if you set
 this up on a laptop with the default port mappings and
 `SETTING_EXTERNAL_HOST`, typing `http://localhost/` will take you to
-your server.  Note that in this default scenario, (1) you'll have to
+your server. Note that in this default scenario, (1) you'll have to
 proceed past a self-signed SSL error, and (2) you won't be able to
 login until you create an organization, but visiting the URL is a good
 way to confirm that your networking configuration is working
@@ -304,7 +304,7 @@ A Kubernetes pod file is in the `kubernetes/` folder; you can run it
 with `kubectl create -f ./kubernetes/`.
 
 You should read the `docker-compose` section above to understand how
-this works, since it's a very similar setup.  You'll want to clone
+this works, since it's a very similar setup. You'll want to clone
 this repository, edit the `zulip-rc.yml` to configure the image, etc.
 
 ### Installing minikube for testing
@@ -327,7 +327,7 @@ https://chat.zulip.org/#narrow/stream/21-provision-help/subject/K8.20and.20Helm/
 
 This image is not designed to make it easy to run multiple copies of
 the `zulip` application server container (and you need to know a lot
-about Zulip to do this sort of thing successfully).  If you're
+about Zulip to do this sort of thing successfully). If you're
 interested in running a high-availablity Zulip installation, your best
 bet is to get in touch with the Zulip support team at
 `[email protected]`.
@@ -354,9 +354,9 @@ in the Docker environment (`docker-compose.yml`).
 ## Upgrading the Zulip container
 
 You can upgrade your Zulip installation to any newer version of Zulip
-with the following instructions.  At a high level, the strategy is to
+with the following instructions. At a high level, the strategy is to
 download a new image, stop the `zulip` container, and then boot it
-back up with the new image.  When the upgraded `zulip` container boots
+back up with the new image. When the upgraded `zulip` container boots
 the first time, it will run the necessary database migrations with
 `manage.py migrate`.
 
@@ -365,7 +365,7 @@ to use `manage.py migrate` to downgrade the database schema manually.
 
 If you are using old `galexrt/docker-zulip` images (from Zulip 1.8.1 or
 older), you need to upgrade the postgres image from
-`quay.io/galexrt/postgres-zulip-tsearchextras:latest`.  Refer to the
+`quay.io/galexrt/postgres-zulip-tsearchextras:latest`. Refer to the
 [instructions for upgrading from the old galexrt/docker-zulip](#upgrading-from-the-old-galexrtdocker-zulip)
 section.
 
@@ -382,9 +382,8 @@ section.
    Note that `docker-zulip` did not support for Zulip's built-in
    `restore-backup` tool before Zulip 3.0.
 
-1. Pull the new image version, e.g. for `2.0.8` run: `docker pull
-zulip/docker-zulip:2.0.8-0`.  We recommend always upgrading to the
-latest minor release within a major release series.
+1. Pull the new image version, e.g. for `2.0.8` run: `docker pull zulip/docker-zulip:2.0.8-0`. We recommend always upgrading to the
+   latest minor release within a major release series.
 
 2. Update this project to the corresponding `docker-zulip` version and
    resolve any merge conflicts in `docker-compose.yml`.
@@ -394,14 +393,15 @@ latest minor release within a major release series.
    the `2.1.2` release).
 
    **Note:** Do not make any changes to the database version or
-   volume.  If there is a difference in database version, leave those
+   volume. If there is a difference in database version, leave those
    unchanged for now, and complete that upgrade separately after the
    Zulip upgrade; see [the section below][pg-upgrade].
 
    [pg-upgrade]: #upgrading-zulipzulip-postgresql-to-14
 
 3. Verify that your updated `docker-compose.yml` points to the desired image version,
-e.g.:
+   e.g.:
+
 ```yml
 zulip:
   image: "zulip/docker-zulip:2.0.1-0"
@@ -428,8 +428,8 @@ docker-compose exec -u zulip zulip cat /home/zulip/deployments/current/version.p
 ### Upgrading from a Git repository
 
 1. Edit `docker-compose.yml` to comment out the `image` line, and
-  specify the Git commit you'd like to build the zulip container from.
-  E.g.:
+   specify the Git commit you'd like to build the zulip container from.
+   E.g.:
 
 ```
   zulip:
@@ -458,7 +458,7 @@ The Docker Compose configuration for version 6.0-0 and higher default
 to using PostgreSQL 14, as the previously-used PostgreSQL 10 is no
 longer supported. Because the data is specific to the version of
 PostgreSQL which is running, it must be dumped and re-loaded into a
-new volume to upgrade.  PostgreSQL 14 will refuse to start if provided
+new volume to upgrade. PostgreSQL 14 will refuse to start if provided
 with un-migrated data from PostgreSQL 10.
 
 The provided `upgrade-postgresql` tool will dump the contents of the
@@ -476,7 +476,7 @@ upgraded the major postgres version).
 
 These instructions assume that you have not changed the default
 Postgres data path (`/opt/docker/zulip/postgresql/data`) in your
-`docker-compose.yml`.  If you have changed it, please replace all
+`docker-compose.yml`. If you have changed it, please replace all
 occurences of `/opt/docker/zulip/postgresql/data` with your path.
 
 1. Make a backup of your Zulip Postgres data dir.
@@ -485,6 +485,7 @@ occurences of `/opt/docker/zulip/postgresql/data` with your path.
    `docker stop` and not `docker-compose stop`).
 
 3. Create a new (upgraded) Postgres container using a different data directory:
+
 ```
 docker run -d \
       --name postgresnew \
@@ -496,34 +497,39 @@ docker run -d \
 ```
 
 4. Use `pg_dumpall` to dump all data from the existing Postgres container to
-the new Postgres container:
+   the new Postgres container:
+
 ```
 docker-compose exec database pg_dumpall -U postgres | \
     docker exec -i postgresnew psql -U postgres
 ```
 
 5. Stop and remove both Postgres containers:
+
 ```
 docker-compose rm --stop database
 docker rm --stop postgresnew
 ```
 
 6. Edit your `docker-compose.yml` to use the
-`zulip/zulip-postgresql:latest` image for the `database` container
-(this is the default in `zulip/docker-zulip`).
+   `zulip/zulip-postgresql:latest` image for the `database` container
+   (this is the default in `zulip/docker-zulip`).
 
 7. Replace the old Postgres data directory with upgraded data directory:
+
 ```
 mv /opt/docker/zulip/postgresql/data /opt/docker/zulip/postgresql/old
 mv /opt/docker/zulip/postgresql/new /opt/docker/zulip/postgresql/data
 ```
 
 8. Delete the old existing containers:
+
 ```
 docker-compose rm
 ```
 
 9. Start Zulip up again:
+
 ```
 docker-compose up
 ```
@@ -535,11 +541,11 @@ That should be it. Your Postgres data has now been updated to use the
 
 Common issues include:
 
-* Invalid configuration resulting in the `zulip` container not
+- Invalid configuration resulting in the `zulip` container not
   starting; check `docker-compose ps` to see if it started, and then
   read the logs for the Zulip container to see why it failed.
-* A new Zulip setting not being passed through the Docker
-  [entrypoint.sh script](/entrypoint.sh) properly.  If you
+- A new Zulip setting not being passed through the Docker
+  [entrypoint.sh script](/entrypoint.sh) properly. If you
   run into this sort of problem you can work around it by specifying a
   `ZULIP_CUSTOM_SETTINGS` with one setting per line below, but please
   report an issue so that we can fix this for everyone else.
@@ -557,15 +563,15 @@ documentation, so we'd love any and all feedback!
 ## Contributing
 
 We love community contributions, and respond quickly to issues and
-PRs.  Some particularly useful ways to contribute right now are:
+PRs. Some particularly useful ways to contribute right now are:
 
-* Contribute to this documentation by opening issues about what
+- Contribute to this documentation by opening issues about what
   confused you or submitting pull requests!
-* Reporting bugs or rough edges!
+- Reporting bugs or rough edges!
 
 ## Credits
 
-Huge thanks to everyone who has contributed.  Special thanks to
+Huge thanks to everyone who has contributed. Special thanks to
 [Alexander Trost](http://github.com/galexrt/), who created
 `docker-zulip` and did a huge amount of the early work required to
 make a high-quality Docker image for Zulip possible.