matrix-docker-ansible-deploy/roles/matrix-postgres/defaults/main.yml

matrix_postgres_enabled: true

matrix_postgres_connection_hostname: ""
matrix_postgres_connection_username: ""
matrix_postgres_connection_password: ""
matrix_postgres_db_name: ""

matrix_postgres_base_path: "{{ matrix_base_data_path }}/postgres"
matrix_postgres_data_path: "{{ matrix_postgres_base_path }}/data"

matrix_postgres_docker_image_v9: "postgres:9.6.16-alpine"
matrix_postgres_docker_image_v10: "postgres:10.11-alpine"
matrix_postgres_docker_image_v11: "postgres:11.6-alpine"
matrix_postgres_docker_image_v12: "postgres:12.1-alpine"
matrix_postgres_docker_image_latest: "{{ matrix_postgres_docker_image_v12 }}"

# This variable is assigned at runtime. Overriding its value has no effect.
matrix_postgres_docker_image_to_use: '{{ matrix_postgres_docker_image_latest }}'

matrix_postgres_docker_image_force_pull: "{{ matrix_postgres_docker_image_to_use.endswith(':latest') }}"

# A list of extra arguments to pass to the container
matrix_postgres_container_extra_arguments: []

# Controls whether the matrix-postgres container exposes a port (tcp/5432 in the
# container) that can be used to access the database from outside the container (e.g. with psql)
#
# psql postgresql://username:password@localhost:<port>/database_name
#
# Takes an "<ip>:<port>" or "<port>" value (e.g. "127.0.0.1:5432"), or empty string to not expose.
matrix_postgres_container_postgres_bind_port: ""

matrix_postgres_tool_synapse_janitor: "https://raw.githubusercontent.com/xwiki-labs/synapse_scripts/0b3f035951932ceb396631de3fc701043b9723bc/synapse_janitor.sql"
Make roles more independent of one another With this change, the following roles are now only dependent on the minimal `matrix-base` role: - `matrix-corporal` - `matrix-coturn` - `matrix-mailer` - `matrix-mxisd` - `matrix-postgres` - `matrix-riot-web` - `matrix-synapse` The `matrix-nginx-proxy` role still does too much and remains dependent on the others. Wiring up the various (now-independent) roles happens via a glue variables file (`group_vars/matrix-servers`). It's triggered for all hosts in the `matrix-servers` group. According to Ansible's rules of priority, we have the following chain of inclusion/overriding now: - role defaults (mostly empty or good for independent usage) - playbook glue variables (`group_vars/matrix-servers`) - inventory host variables (`inventory/host_vars/matrix.<your-domain>`) All roles default to enabling their main component (e.g. `matrix_mxisd_enabled: true`, `matrix_riot_web_enabled: true`). Reasoning: if a role is included in a playbook (especially separately, in another playbook), it should "work" by default. Our playbook disables some of those if they are not generally useful (e.g. `matrix_corporal_enabled: false`). 2019-01-17 00:05:48 +08:00			`matrix_postgres_enabled: true`

			`matrix_postgres_connection_hostname: ""`
			`matrix_postgres_connection_username: ""`
			`matrix_postgres_connection_password: ""`
			`matrix_postgres_db_name: ""`
Split playbook into multiple roles As suggested in #63 (Github issue), splitting the playbook's logic into multiple roles will be beneficial for maintainability. This patch realizes this split. Still, some components affect others, so the roles are not really independent of one another. For example: - disabling mxisd (`matrix_mxisd_enabled: false`), causes Synapse and riot-web to reconfigure themselves with other (public) Identity servers. - enabling matrix-corporal (`matrix_corporal_enabled: true`) affects how reverse-proxying (by `matrix-nginx-proxy`) is done, in order to put matrix-corporal's gateway server in front of Synapse We may be able to move away from such dependencies in the future, at the expense of a more complicated manual configuration, but it's probably not worth sacrificing the convenience we have now. As part of this work, the way we do "start components" has been redone now to use a loop, as suggested in #65 (Github issue). This should make restarting faster and more reliable. 2019-01-12 23:53:00 +08:00
			`matrix_postgres_base_path: "{{ matrix_base_data_path }}/postgres"`
			`matrix_postgres_data_path: "{{ matrix_postgres_base_path }}/data"`

Update postgres versions (12.0 -> 12.1, etc) 2019-11-21 23:38:37 +08:00			`matrix_postgres_docker_image_v9: "postgres:9.6.16-alpine"`
			`matrix_postgres_docker_image_v10: "postgres:10.11-alpine"`
			`matrix_postgres_docker_image_v11: "postgres:11.6-alpine"`
			`matrix_postgres_docker_image_v12: "postgres:12.1-alpine"`
Add support for Postgres v12 2019-10-04 13:51:32 +08:00			`matrix_postgres_docker_image_latest: "{{ matrix_postgres_docker_image_v12 }}"`
Add the possibility to pass extra flags to the docker container 2019-04-30 22:35:18 +08:00
Automatically force-pull :latest images We do use some `:latest` images by default for the following services: - matrix-dimension - Goofys (in the matrix-synapse role) - matrix-bridge-appservice-irc - matrix-bridge-appservice-discord - matrix-bridge-mautrix-facebook - matrix-bridge-mautrix-whatsapp It's terribly unfortunate that those software projects don't release anything other than `:latest`, but that's how it is for now. Updating that software requires that users manually do `docker pull` on the server. The playbook didn't force-repull images that it already had. With this patch, it starts doing so. Any image tagged `:latest` will be force re-pulled by the playbook every time it's executed. It should be noted that even though we ask the `docker_image` module to force-pull, it only reports "changed" when it actually pulls something new. This is nice, because it lets people know exactly when something gets updated, as opposed to giving the indication that it's always updating the images (even though it isn't). 2019-06-10 19:23:51 +08:00			`# This variable is assigned at runtime. Overriding its value has no effect.`
			`matrix_postgres_docker_image_to_use: '{{ matrix_postgres_docker_image_latest }}'`

			`matrix_postgres_docker_image_force_pull: "{{ matrix_postgres_docker_image_to_use.endswith(':latest') }}"`

Add the possibility to pass extra flags to the docker container 2019-04-30 22:35:18 +08:00			`# A list of extra arguments to pass to the container`
			`matrix_postgres_container_extra_arguments: []`
Add config option to be able to access database outside of container 2019-06-10 09:35:35 +08:00
			`# Controls whether the matrix-postgres container exposes a port (tcp/5432 in the`
Explain matrix_postgres_container_postgres_bind_port a little more Previously, it only mentioned exposing for psql-usage purposes. Realistically, it can be used for much more. Especially given that psql can be easily accessed via our matrix-postgres-cli script, without exposing the container port. 2019-06-10 13:24:37 +08:00			`# container) that can be used to access the database from outside the container (e.g. with psql)`
Add config option to be able to access database outside of container 2019-06-10 09:35:35 +08:00			`#`
			`# psql postgresql://username:password@localhost:<port>/database_name`
			`#`
			`# Takes an "<ip>:<port>" or "<port>" value (e.g. "127.0.0.1:5432"), or empty string to not expose.`
			`matrix_postgres_container_postgres_bind_port: ""`
Add Synapse Maintenance docs and synapse-janitor integration 2019-07-08 14:38:24 +08:00
			`matrix_postgres_tool_synapse_janitor: "https://raw.githubusercontent.com/xwiki-labs/synapse_scripts/0b3f035951932ceb396631de3fc701043b9723bc/synapse_janitor.sql"`