Commit graph

22 commits

Author SHA1 Message Date
Slavi Pantaleev 38c4e464c1 Fix self-check for Hydrogen and Cinny when running under a subpath 2023-02-17 09:20:22 +02:00
Aine c98f40c836
Update hydrogen 0.3.7 -> 0.3.8 2023-02-14 17:49:16 +00:00
Slavi Pantaleev eb7292f274 Add matrix_client_hydrogen_hostname and fix Hydrogen serving at non-root-path 2023-02-14 10:57:13 +02:00
Slavi Pantaleev 6a52be7987 Add (native) Traefik support to matrix-client-hydrogen
Previously, it had to go through matrix-nginx-proxy.
It's exposed to Traefik directly via container labels now

Serving at a path other than `/` doesn't work well yet.
2023-02-14 09:58:35 +02:00
Slavi Pantaleev 64e2b26ed5 Fix Hydrogen failing to start
We were mounting our own configuration to
`/usr/share/nginx/html/config.json`, which is a symlink to
`/tmp/config.json`. So we effectively mount our file to
`/tmp/config.json`.

When starting:

- if Hydrogen sees a `CONFIG_OVERRIDE` environment variable,
  it will try to save it into our read-only config file and fail.

- if Hydrogen doesn't see a `CONFIG_OVERRIDE` environment variable (the
  path we go through, because we don't pass such a variable),
  it will try to copy its bundled configuration (`/config.json.bundled`)
  to `/tmp/config.json`. Because our configuration is mounted as read-only, it will
  fail.

In both cases, it will fail with:

> cp: can't create '/tmp/config.json': File exists

Source: 3720de36bb/docker/dynamic-config.sh

We work around this by mounting our configuration on top of the bundled
one (`/config.json.bundled`). We then let Hydrogen's startup script copy
it to `/tmp/config.json` (a tmpfs we've mounted into the container) and use it from there.
2023-02-14 09:49:22 +02:00
Aine a1ef28681a
Update Hydrogen 0.3.6 -> 0.3.7 2023-02-10 14:40:50 +00:00
Slavi Pantaleev d0b2a50768 Upgrade Hydrogen (v0.3.5 -> v0.3.6) 2022-12-20 21:36:39 +02:00
Matthew Cengia 3453fff901
Use upstream Docker image for amd64 rather than self-build 2022-12-11 21:25:43 +11:00
Slavi Pantaleev 2688e8bfc3 Optimize initial installation by not reloading systemd after each .service install
We expect `--tags=start` to handle systemd reloading, so we don't need
to do it manually each time we install/uninstall a .service file.
2022-11-27 10:02:45 +02:00
Slavi Pantaleev 16c18b0344 Upgrade Hydrogen (v0.3.4 -> v0.3.5) 2022-11-25 18:59:01 +02:00
Slavi Pantaleev a04f6f4e3d Optimize uninstall tasks a bit
- forego removing Docker images - it's not effective anyway, because it
  only removes the last version.. which is a drop in the bucket, usually

- do not reload systemd - it's none of our business. `--tags=start`,
  etc., handle this

- combine all uninstall tasks under a single block, which only runs if
  we detect traces (a leftover systemd .service file) of the component.
  If no such .service is detected, we skip them all. This may lead to
  incorect cleanup in rare cases, but is good enough for the most part.
2022-11-25 17:28:57 +02:00
Slavi Pantaleev 61f67d8f0a Add install-* tags for quicker runs 2022-11-25 16:02:51 +02:00
Slavi Pantaleev 7c2a7a8eb6 Replace most import_tasks calls with include_tasks for improved performance 2022-11-24 11:33:45 +02:00
Slavi Pantaleev 0ea7cb5d18 Remove various init.yml files - initialize systemd services, etc., statically (not at runtime) 2022-11-23 11:45:46 +02:00
Aine 19b59f9ded
Update Hydrogen 0.3.3 -> 0.3.4 2022-11-10 17:56:59 +00:00
Slavi Pantaleev a4e2a3bc07 Upgrade Hydrogen (v0.3.2 -> v0.3.3) 2022-11-04 17:07:29 +02:00
Slavi Pantaleev d3bd1ca024 matrix_*_retries_{count,delay} -> devture_playbook_help_*_retries_{count,delay} 2022-11-04 16:44:29 +02:00
Slavi Pantaleev 7086c0ebe3 matrix_host_command_sh -> devture_systemd_docker_base_host_command_sh (via com.devture.ansible.role.systemd_docker_base) 2022-11-04 16:40:25 +02:00
Slavi Pantaleev a9a81460ec matrix_host_command_docker -> devture_systemd_docker_base_host_command_docker (via com.devture.ansible.role.systemd_docker_base) 2022-11-04 16:39:35 +02:00
Slavi Pantaleev 835d2e9581 matrix_systemd_path -> devture_systemd_docker_base_systemd_path (via com.devture.ansible.role.systemd_docker_base) 2022-11-04 16:38:38 +02:00
Slavi Pantaleev f03f716989 matrix_systemd_unit_home_path -> devture_systemd_docker_base_systemd_unit_home_path (via com.devture.ansible.role.systemd_docker_base) 2022-11-04 16:37:47 +02:00
Slavi Pantaleev 410a915a8a Move roles/matrix* to roles/custom/matrix*
This paves the way for installing other roles into `roles/galaxy` using `ansible-galaxy`,
similar to how it's done in:

- https://github.com/spantaleev/gitea-docker-ansible-deploy
- https://github.com/spantaleev/nextcloud-docker-ansible-deploy

In the near future, we'll be removing a lot of the shared role code from here
and using upstream roles for it. Some of the core `matrix-*` roles have
already been extracted out into other reusable roles:

- https://github.com/devture/com.devture.ansible.role.postgres
- https://github.com/devture/com.devture.ansible.role.systemd_docker_base
- https://github.com/devture/com.devture.ansible.role.timesync
- https://github.com/devture/com.devture.ansible.role.vars_preserver
- https://github.com/devture/com.devture.ansible.role.playbook_runtime_messages
- https://github.com/devture/com.devture.ansible.role.playbook_help

We just need to migrate to those.
2022-11-03 09:11:29 +02:00