Skip to content
This repository has been archived by the owner on Apr 26, 2024. It is now read-only.

Merge the Complement testing Docker images into a single, multi-purpose image. #12881

Merged
merged 28 commits into from
Jun 8, 2022
Merged
Show file tree
Hide file tree
Changes from 24 commits
Commits
Show all changes
28 commits
Select commit Hold shift + click to select a range
e4137c1
Mutiny: oust the monolith image and replace with the workers image
reivilibre May 24, 2022
865fa26
Update references in Dockerfile
reivilibre May 24, 2022
edc7fcd
Update complement.sh to use the unified image
reivilibre May 24, 2022
15215bd
Make it possible to disable Redis with an env var
reivilibre May 26, 2022
97699e3
Require START_POSTGRES=1 to start Postgres
reivilibre May 26, 2022
9cd96d2
Make the Complement Synapse launcher able to handle all 3 scenarios
reivilibre May 26, 2022
3a588a0
Don't enable Redis for the monolith case
reivilibre May 26, 2022
7bc03a6
Burn env vars into the image (sad and hopefully temporary)
reivilibre May 26, 2022
bf37bf3
Newsfile
reivilibre May 26, 2022
facccd0
Bring back the experimental features
reivilibre May 26, 2022
7e9884a
Apply suggestions from Rich
reivilibre May 30, 2022
423e212
Remove mention of 'worker' from entrypoint
reivilibre May 30, 2022
470fabe
Pass the environment variables straight through, with no burning!
reivilibre May 30, 2022
b0241e7
Add back SYNAPSE_VERSION build arguments
reivilibre May 30, 2022
3537762
Automatically disable Redis only for no-worker instances
reivilibre May 31, 2022
8ae3da7
Improve Complement documentation about 'Stuff' :)
reivilibre May 31, 2022
33aeb67
Update the contributing guide
reivilibre May 31, 2022
9f8d317
Update README-testing.md
reivilibre May 31, 2022
9531da6
Fix sentence that dropped off
reivilibre May 31, 2022
2beae8f
Update docker/README-testing.md
reivilibre May 31, 2022
bc5d529
Apply suggestions from code review
reivilibre May 31, 2022
166b046
Remove obsolete START_REDIS
reivilibre May 31, 2022
4a739ca
Fix comment explaining the overwritten config file
reivilibre May 31, 2022
1af38ef
Convert workers-shared.yaml to Jinja2 and import the original file ra…
reivilibre Jun 1, 2022
6daac8a
Add comment about how it fits in
reivilibre Jun 6, 2022
6c01955
Merge branch 'develop' into rei/one_complement_image
reivilibre Jun 6, 2022
2fd415b
Update docker/configure_workers_and_start.py
reivilibre Jun 8, 2022
b548132
Move comment to top of file and rephrase slightly
reivilibre Jun 8, 2022
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions changelog.d/12881.misc
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
Merge the Complement testing Docker images into a single, multi-purpose image.
3 changes: 2 additions & 1 deletion docker/Dockerfile-workers
Original file line number Diff line number Diff line change
@@ -1,5 +1,6 @@
# Inherit from the official Synapse docker image
FROM matrixdotorg/synapse
ARG SYNAPSE_VERSION=latest
FROM matrixdotorg/synapse:$SYNAPSE_VERSION

# Install deps
RUN \
Expand Down
97 changes: 46 additions & 51 deletions docker/README-testing.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,79 +8,50 @@ docker images that can be run inside Complement for testing purposes.

Note that running Synapse's unit tests from within the docker image is not supported.

## Testing with SQLite and single-process Synapse
## Using the Complement launch script

> Note that `scripts-dev/complement.sh` is a script that will automatically build
> and run an SQLite-based, single-process of Synapse against Complement.
`scripts-dev/complement.sh` is a script that will automatically build
and run Synapse against Complement.
Consult the [contributing guide][guideComplementSh] for instructions on how to use it.

The instructions below will set up Complement testing for a single-process,
SQLite-based Synapse deployment.

Start by building the base Synapse docker image. If you wish to run tests with the latest
release of Synapse, instead of your current checkout, you can skip this step. From the
root of the repository:

```sh
docker build -t matrixdotorg/synapse -f docker/Dockerfile .
```

This will build an image with the tag `matrixdotorg/synapse`.

Next, build the Synapse image for Complement.
[guideComplementSh]: https://matrix-org.github.io/synapse/latest/development/contributing_guide.html#run-the-integration-tests-complement

```sh
docker build -t complement-synapse -f "docker/complement/Dockerfile" docker/complement
```
## Building and running the images manually

This will build an image with the tag `complement-synapse`, which can be handed to
Complement for testing via the `COMPLEMENT_BASE_IMAGE` environment variable. Refer to
[Complement's documentation](https://github.com/matrix-org/complement/#running) for
how to run the tests, as well as the various available command line flags.

## Testing with PostgreSQL and single or multi-process Synapse
Under some circumstances, you may wish to build the images manually.
The instructions below will lead you to doing that.

The above docker image only supports running Synapse with SQLite and in a
single-process topology. The following instructions are used to build a Synapse image for
Complement that supports either single or multi-process topology with a PostgreSQL
database backend.

As with the single-process image, build the base Synapse docker image. If you wish to run
tests with the latest release of Synapse, instead of your current checkout, you can skip
this step. From the root of the repository:
Start by building the base Synapse docker image. If you wish to run tests with the latest
release of Synapse, instead of your current checkout, you can skip this step. From the
root of the repository:

```sh
docker build -t matrixdotorg/synapse -f docker/Dockerfile .
```

This will build an image with the tag `matrixdotorg/synapse`.

Next, we build a new image with worker support based on `matrixdotorg/synapse:latest`.
Again, from the root of the repository:
Next, build the workerised Synapse docker image, which is a layer over the base
image.

```sh
docker build -t matrixdotorg/synapse-workers -f docker/Dockerfile-workers .
```

This will build an image with the tag` matrixdotorg/synapse-workers`.

It's worth noting at this point that this image is fully functional, and
can be used for testing against locally. See instructions for using the container
under
[Running the Dockerfile-worker image standalone](#running-the-dockerfile-worker-image-standalone)
below.

Finally, build the Synapse image for Complement, which is based on
`matrixdotorg/synapse-workers`.
Finally, build the multi-purpose image for Complement, which is a layer over the workers image.

```sh
docker build -t matrixdotorg/complement-synapse-workers -f docker/complement/SynapseWorkers.Dockerfile docker/complement
docker build -t complement-synapse -f docker/complement/Dockerfile docker/complement
```

This will build an image with the tag `complement-synapse-workers`, which can be handed to
This will build an image with the tag `complement-synapse`, which can be handed to
Complement for testing via the `COMPLEMENT_BASE_IMAGE` environment variable. Refer to
[Complement's documentation](https://github.com/matrix-org/complement/#running) for
how to run the tests, as well as the various available command line flags.

See [the Complement image README](./complement/README.md) for information about the
expected environment variables.


## Running the Dockerfile-worker image standalone

For manual testing of a multi-process Synapse instance in Docker,
Expand Down Expand Up @@ -113,6 +84,9 @@ docker run -d --name synapse \
...substituting `POSTGRES*` variables for those that match a postgres host you have
available (usually a running postgres docker container).


### Workers

The `SYNAPSE_WORKER_TYPES` environment variable is a comma-separated list of workers to
use when running the container. All possible worker names are defined by the keys of the
`WORKERS_CONFIG` variable in [this script](configure_workers_and_start.py), which the
Expand All @@ -125,8 +99,11 @@ type, simply specify the type multiple times in `SYNAPSE_WORKER_TYPES`
(e.g `SYNAPSE_WORKER_TYPES=event_creator,event_creator...`).

Otherwise, `SYNAPSE_WORKER_TYPES` can either be left empty or unset to spawn no workers
(leaving only the main process). The container is configured to use redis-based worker
mode.
(leaving only the main process).
The container will only be configured to use Redis-based worker mode if there are
workers enabled.

### Logging

Logs for workers and the main process are logged to stdout and can be viewed with
standard `docker logs` tooling. Worker logs contain their worker name
Expand All @@ -136,3 +113,21 @@ Setting `SYNAPSE_WORKERS_WRITE_LOGS_TO_DISK=1` will cause worker logs to be writ
`<data_dir>/logs/<worker_name>.log`. Logs are kept for 1 week and rotate every day at 00:
00, according to the container's clock. Logging for the main process must still be
configured by modifying the homeserver's log config in your Synapse data volume.


### Application Services

Setting the `SYNAPSE_AS_REGISTRATION_DIR` environment variable to the path of
a directory (within the container) will cause the configuration script to scan
that directory for `.yaml`/`.yml` registration files.
Synapse will be configured to load these configuration files.


### TLS Termination

Nginx is present in the image to route requests to the appropriate workers,
but it does not serve TLS by default.

You can configure `SYNAPSE_TLS_CERT` and `SYNAPSE_TLS_KEY` to point to a
TLS certificate and key (respectively), both in PEM (textual) format.
In this case, Nginx will additionally serve using HTTPS on port 8448.
49 changes: 36 additions & 13 deletions docker/complement/Dockerfile
Original file line number Diff line number Diff line change
@@ -1,22 +1,45 @@
# A dockerfile which builds an image suitable for testing Synapse under
# complement.

# This dockerfile builds on top of 'docker/Dockerfile-workers' in matrix-org/synapse
# by including a built-in postgres instance, as well as setting up the homeserver so
# that it is ready for testing via Complement.
#
# Instructions for building this image from those it depends on is detailed in this guide:
# https://github.com/matrix-org/synapse/blob/develop/docker/README-testing.md#testing-with-postgresql-and-single-or-multi-process-synapse
ARG SYNAPSE_VERSION=latest
FROM matrixdotorg/synapse-workers:$SYNAPSE_VERSION

# Install postgresql
RUN apt-get update && \
DEBIAN_FRONTEND=noninteractive apt-get install --no-install-recommends -y postgresql-13

# Configure a user and create a database for Synapse
RUN pg_ctlcluster 13 main start && su postgres -c "echo \
\"ALTER USER postgres PASSWORD 'somesecret'; \
CREATE DATABASE synapse \
ENCODING 'UTF8' \
LC_COLLATE='C' \
LC_CTYPE='C' \
template=template0;\" | psql" && pg_ctlcluster 13 main stop

# Extend the shared homeserver config to disable rate-limiting,
# set Complement's static shared secret, enable registration, amongst other
# tweaks to get Synapse ready for testing.
# To do this, we copy the old template out of the way and then include it
# with Jinja2.
RUN mv /conf/shared.yaml.j2 /conf/shared-orig.yaml.j2
COPY conf/workers-shared-extra.yaml.j2 /conf/shared.yaml.j2

FROM matrixdotorg/synapse:${SYNAPSE_VERSION}

ENV SERVER_NAME=localhost

COPY conf/* /conf/
WORKDIR /data

# generate a signing key
RUN generate_signing_key -o /conf/server.signing.key
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we not still need a signing key? or is that generated somewhere else?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This isn't something I've touched (although the overall diff will make that less than obvious) — presumably it generated a signing key before. That said, this one eluded me for a bit!

It's in start.py (called by configure_workers_and_start.py):

synapse/docker/start.py

Lines 115 to 126 in 7f92ac4

# Hopefully we already have a signing key, but generate one if not.
args = [
sys.executable,
"-m",
"synapse.app.homeserver",
"--config-path",
config_path,
# tell synapse to put generated keys in /data rather than /compiled
"--keys-directory",
config_dir,
"--generate-keys",
]

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it is something you've changed... or at least, I don't understand why you're saying it's not.

Anyway, if start.py sorts it out, I guess that's fine.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't write that file — it was already here: e4137c1 (#12881); the diff is just confusing because I deleted the monolith-only image which is what the red part of this diff (that your comment is on) corresponds to

COPY conf/postgres.supervisord.conf /etc/supervisor/conf.d/postgres.conf

WORKDIR /data
# Copy the entrypoint
COPY conf/start_for_complement.sh /

# Expose nginx's listener ports
EXPOSE 8008 8448

ENTRYPOINT ["/conf/start.sh"]
ENTRYPOINT ["/start_for_complement.sh"]

# Update the healthcheck to have a shorter check interval
HEALTHCHECK --start-period=5s --interval=1s --timeout=1s \
CMD curl -fSs http://localhost:8008/health || exit 1
CMD /bin/sh /healthcheck.sh
33 changes: 32 additions & 1 deletion docker/complement/README.md
Original file line number Diff line number Diff line change
@@ -1 +1,32 @@
Stuff for building the docker image used for testing under complement.
# Unified Complement image for Synapse

This is an image for testing Synapse with [the *Complement* integration test suite][complement].
It contains some insecure defaults that are only suitable for testing purposes,
so **please don't use this image for a production server**.

This multi-purpose image is built on top of `Dockerfile-workers` in the parent directory
and can be switched using environment variables between the following configurations:

- Monolithic Synapse with SQLite (`SYNAPSE_COMPLEMENT_DATABASE=sqlite`)
- Monolithic Synapse with Postgres (`SYNAPSE_COMPLEMENT_DATABASE=postgres`)
- Workerised Synapse with Postgres (`SYNAPSE_COMPLEMENT_DATABASE=postgres` and `SYNAPSE_COMPLEMENT_USE_WORKERS=true`)

The image is self-contained; it contains an integrated Postgres, Redis and Nginx.


## How to get Complement to pass the environment variables through

To pass these environment variables, use [Complement's `COMPLEMENT_SHARE_ENV_PREFIX`][complementEnv]
variable to configure an environment prefix to pass through, then prefix the above options
with that prefix.

Example:
```
COMPLEMENT_SHARE_ENV_PREFIX=PASS_ PASS_SYNAPSE_COMPLEMENT_DATABASE=postgres
```

Consult `scripts-dev/complement.sh` in the repository root for a real example.


[complement]: https://github.com/matrix-org/complement
[complementEnv]: https://github.com/matrix-org/complement/pull/382
40 changes: 0 additions & 40 deletions docker/complement/SynapseWorkers.Dockerfile

This file was deleted.

This file was deleted.

Loading