Update docs on self-building and remove useless variable

`matrix_container_images_self_build` was not really doing anything
anymore. It previously was influencing `matrix_*_self_build` variables,
but it's no longer the case since some time ago.

Individual `matrix_*_self_build` variables are still available.
People that would like to toggle self-building for a specific component
ought to use those.

These variables are also controlled automatically (via
`group_vars/matrix_servers`) depending on `matrix_architecture`.

In other words, self-building is being done automatically for
all components when they don't have a prebuilt image for the specified
architecture. Some components only support `amd64`, while others also
have images for other architectures.
master
Slavi Pantaleev 4 years ago
parent 635f385971
commit de545f9c5f

@ -1,6 +1,6 @@
# Alternative architectures
As stated in the [Prerequisites](prerequisites.md), currently only x86_64 is supported. However, it is possible to set the target architecture, and some tools can be built on the host or other measures can be used.
As stated in the [Prerequisites](prerequisites.md), currently only `x86_64` is fully supported. However, it is possible to set the target architecture, and some tools can be built on the host or other measures can be used.
To that end add the following variable to your `vars.yaml` file:
@ -21,9 +21,6 @@ matrix_architecture: "arm32"
## Implementation details
This subsection is used for a reminder, how the different roles implement architecture differences. This is **not** aimed at the users, so one does not have to do anything based on this subsection.
For `amd64`, prebuilt images are used everywhere (because all images are available for this architecture).
On most roles [self-building](self-building.md) is used if the architecture is not `amd64`, however there are some special cases:
- `matrix-bridge-mautrix-facebook`: there is a pre-built Docker image for `arm64` as well
- `matrix-bridge-mautrix-hangouts`: there is a pre-built Docker image for `arm64` as well
- `matrix-nginx-proxy`: Certbot has a pre-built Docker image for both `arm32` and `arm64`, however tagging is used, which requires special handling.
For other architectures, components which have a prebuilt image make use of it. If the component is not available for the specific architecture, [self-building](self-building.md) will be used. Not all components support self-building though, so your mileage may vary.

@ -2,22 +2,23 @@
**Caution: self-building does not have to be used on its own. See the [Alternative Architectures](alternative-architectures.md) page.**
The playbook supports the self-building of some of its components. This may be useful for architectures besides x86_64, which have no Docker images right now (e g. the armv7 for the Raspberry Pi). Some playbook roles have been updated, so they build the necessary image on the host. It needs more space, as some build tools need to be present (like Java, for ma1sd).
The playbook supports the self-building of various components, which don't have a container image for your architecture. For `amd64`, self-building is not required.
To use these modification there is a variable that needs to be switched to enable this functionality. Add this to your `vars.yaml` file:
```yaml
matrix_container_images_self_build: true
```
Setting that variable will self-build every role which supports self-building. Self-building can be set on a per-role basis as well.
For other architectures (e.g. `arm32`, `arm64`), ready-made container images are used when available. If there's no ready-made image for a specific component and said component supports self-building, an image will be built on the host. Building images like this takes more time and resources (some build tools need to get installed by the playbook to assist building).
To make use of self-building, you don't need to do anything besides change your architecture variable (e.g. `matrix_architecture: arm64`). If a component has an image for the specified architecture, the playbook will use it. If not, it will build the image.
Note that **not all components support self-building yet**.
List of roles where self-building the Docker image is currently possible:
- `matrix-synapse`
- `matrix-riot-web`
- `matrix-coturn`
- `matrix-ma1sd`
- `matrix-mailer`
- `matrix-mautrix-facebook`
- `matrix-mautrix-hangouts`
- `matrix-mx-puppet-skype`
- `matrix-bridge-mautrix-facebook`
- `matrix-bridge-mautrix-hangouts`
- `matrix-bridge-mx-puppet-skype`
Adding self-building support to other roles is welcome. Feel free to contribute!
If you'd like **to force self-building** even if an image is available for your architecture, look into the `matrix_*_self_build` variables provided by individual roles.

@ -99,7 +99,3 @@ run_setup: true
run_self_check: true
run_start: true
run_stop: true
# Building every docker image from source on the target host
# Controlling docker image build is possible on a per unit base
matrix_container_images_self_build: false

Loading…
Cancel
Save