devydave/alakazam
0
0
Fork 0
forked from moritz/alakazam
Code Pull Requests Activity

update README

Browse Source
This commit is contained in:
Moritz
2024-05-02 15:22:01 +02:00
parent 8701911504
commit cb2e71013f
5 changed files with 294 additions and 247 deletions
Download Patch File Download Diff File Expand all files Collapse all files

212
README.md
View File

@ -1,123 +1,88 @@
# Alakazam
Proof-of-concept meta-configuration app-connector abra wrapper.
Alakazam is a meta-configuration app-connector and an abra wrapper, designed as a proof-of-concept to simplify the management of environment configuration files across multiple instances.
## Problem Statement
- managing a lot of env files can be error prone
- copy pasting env files
- loosing the overview of configuration differences between instances
- env files can be long, how to see what are defaults and what are customizations
- updating env files is a manual process of comparing the env files
- env files of recipes can change, how to keep up to date with them?
- no way to define default configurations that should always be applied
- if you have global configs for all your apps you have to copy paste them
- connecting two apps requires manual effort of specific env file changes and sharing secrets
- i.E. the effort of configuring SSO for multiple apps
## Alakazam Advantages
Managing numerous environment (env) files can be prone to errors such as:
- Have a global configuration that applies on every instance:
- avoid copy pasta errors
- avoid forgetting important configurations
- Reduce manual configuration overhead for connecting multiple apps
- exchange domains
- share secrets
- set specific env vars
- Have a minimal configuration file for each instance
- it should only contain parameters that differ from the defaults and the global configuration
- Set a global subdomain convention
- each app will always have the same subdomain
- Set up an instance with multiple connected apps in one run
- Automatic updates of the env configurations
- avoid manual env configuration at all
- Automatic mass updates
- Specify the versions for all your apps
- Hierarchical configuration structure with inheritance
- don't lose track of large scales of configurations
- Frequent copy-pasting mistakes.
- Difficulty maintaining an overview of configuration differences across instances.
- Laborious manual processes required for updating env files, particularly when underlying recipe env configurations change.
- Challenges in defining default configurations that should consistently apply across all apps and all instances.
- Manual effort required for app integration (e.g., SSO), including configuring environment files and exchanging secrets.
## Advantages of Alakazam
- **Global Configuration**: Prevents errors related to manual copying and pasting and ensures no critical configurations are overlooked.
- **Reduced Manual Configuration**: Facilitates the connection between multiple applications (i.E. SSO) through domain exchanges, secret sharing, and specific environmental variables.
- **Minimal Configuration Files**: Each instance configuration only contains parameters that deviate from the defaults or global configurations, simplifying management.
- **Standardized Subdomain Conventions**: Ensures consistent subdomain use across apps.
- **Simplified Setup**: Allows for the setup of an instance with multiple connected apps in one run.
- **Automatic Env Configuration Updates**: Eliminates manual env configuration.
- **Automatic Batch Updates**: update all apps of a group of instances at once.
- **Hierarchical Configuration Structure**: Supports configuration inheritance for ease of managing large-scale configurations.
## How does it work
`alakazam` is a wrapper around `abra` with the purpose of automating the whole deployment process of multiple apps. It takes `yaml` configuration files and generates the .env files used by `abra`. Based on the `yaml` configuration it's also able to generate, insert and exchange secretes between apps. It can deploy/update multiple apps at once and run post deploy hooks on all these apps. All configurations are structured hierarchically in `yaml` files, that can inherit properties from the layers above.
`alakazam` serves as a wrapper for `abra`, automating the deployment process for multiple apps.
It utilizes YAML configuration files to generate the necessary .env files and manage secret exchanges between applications.
It supports the deployment or updating of multiple apps simultaneously and can execute post-deploy hooks.
All configurations are hierarchically structured in YAML files, which can inherit properties from the layers above.
## Configuration
### Concept
Each configuration can be templated with jinja2 and global variables.
There are the following three general types of configuration files:
Configuration files support templating with Jinja2 and global variables, facilitating dynamic adjustments. The primary types of configuration files include:
1. `alaka.yml`
- It contains global configurations for a specific hierarchical layer
- all the apps under this layer will inherit the properties defined here.
- i.e. smtp config, language, app versions
- It can contain specify the subdomains for specific recipes
- i.e. `cloud.example.com` for each nextcloud app
- This configuration is for the operator to avoid copy pasta errors, reduce manual and duplicate configurations and keep the same naming convention
2. `./example.com.yml` (`<your-domain>.yml`)
- a minimalist configuration per instance
- an **instance** means a collection of apps that are integrated with each other
- one server / vm can contain multiple instances
- contains at least:
- the apps to be installed
- the filename contains the *instance domain*, which is used to create all the app subdomains
- if the server is not extra specified it is also used as server on which the apps should be deployed (see [Templating Configurations](#templating-configurations) )
- can optionally contain instance specific configurations for each app, overwriting the inherited `alaka.yml` configurations
3. `combine.yml`
- contains the configuration steps that are required to combine apps with each other
- This configuration should not be touched by the operator
- at the moment it's part of the `alakazam` repository
- In future it should be split into the recipes repositories and maintained by the recipe maintainer
1. **`alaka.yml`**: Contains global configurations for a hierarchical layer, affecting all subordinate apps.
2. **`example.com.yml`** (`<your-domain>.yml`): A minimalist configuration for each instance, specifying the apps to be installed, the instance domain and optionally instance specific configurations.
- an **instance** means a collection of apps that are integrated with each other (one server / vm can contain multiple instances)
3. **`combine.yml`**: Manages configurations required to integrate multiple apps with each other.
- This configuration should not be touched by the operator.
- At the moment it's part of the `alakazam` repository.
- In future it should be split into the recipes repositories and maintained by the recipe maintainer.
### App Configuration
`alaka.yml`, `example.com.yml` and `combine.yml` contain a similar structure to configure the individual apps.
For each app the following `<app_configurations>` steps can be used:
`alaka.yml`, `example.com.yml` and `combine.yml` contain a similar configuration structure.
For each app/recipe the following `<app_configurations>` can be used:
- `uncomment:`
- uncomment each matching line (i.E. `compose.smtp.yml`)
- **`uncomment`/`comment`**: Manages the active status of lines in configuration files, such as uncommenting needed variables .
- it matches against parts of the line (i.E. `compose.smtp.yml`)
- this is useful for env variables that are used multiple times like `COMPOSE_FILE`
- `comment:`
- the opposite of `uncomment`, comment unwanted env variables
- `env:`
- set the value for env variables (implicit uncommenting variables)
- `execute:`
- `abra.sh` commands that should be executed after deployment
- `secrets:`
- insert a specific value into a secret
- for secrets that can not be generated, i.e. smtp passwords
- TODO: use secrets from encrypted files to avoid plain text secrets
- `subdomain`:
- contains the subdomain that should be used for a specific app
- **`env`**: Sets values for environment variables.
- **`execute`**: Specifies `abra.sh` commands to run post-deployment.
- **`secrets`**: Inserts specific values (i.E. smtp passwords) into secrets; future updates will support encrypted file usage.
- **`subdomain`**: Specifies the subdomain scheme for individual recipes and apps. (not available in `combine.yml`)
- i.e. `cloud.example.com` for nextcloud
- (not available in `combine.yml`)
- `version`
- contains the recipe version, that should be deployed
- if not specified, the newest version will be used
- (not available in `combine.yml`)
- **`version`**: Controls the recipe version to deploy; if unspecified, the latest version is used. (not available in `combine.yml`)
The `combine.yml` configuration additionally contains
The `combine.yml` configuration additionally contains:
- `shared_secrets:`
- **`shared_secrets`**: Specifies secret sharing between apps.
- `<source_secret_name>:<target_secret_name>`
- a mapping to define which secrets should be shared between two apps
### Configuration Structure
1. `alaka.yml` and `example.com.yml`
- the `<app_recipe>` entries in `alaka.yml` define global app configurations that should be inherited by all underlaying configurations
- in `example.com.yml` the entries `<app_recipe>` define which apps should be installed
- the `<app_configuration>` is configured according to [App Configuration](#app-configuration) above
Configuration can be simplified into a single `example.com.yml` or expanded into multiple layered `alaka.yml` files for complex deployments. This allows for easy maintenance of multiple instances or groups.
These configurations are designed to modularize and simplify the management of app settings and integrations, making it easier to maintain and scale your deployments.
**1. `alaka.yml` and `example.com.yml`**
- **`alaka.yml`**: Contains global app configurations (`<app_recipe>`) which are inherited by all configurations within its hierarchical layer. This ensures consistent settings across multiple applications.
- **`example.com.yml`**: Specifies which apps should be deployed (`<app_recipe>` entries), focusing on the individual needs of each instance.
- Configurations within these files are structured as follows, with specific `<app_configuration>` settings detailed in the [App Configuration](#app-configuration) section:
```
<app_recipe>:
<app_configurations>
```
3. `combine.yml`
- it contains the `<target_app_configurations>` that should be applied to the target app if both the `<target_app_recipe>` and the `<source_app_recipe>` is part of the same instance (`example.com.yml`)
- the `<target_app_configurations>` is configured according to [App Configuration](#app-configuration) above
**3. `combine.yml`**
- This file orchestrates the integration between multiple apps within the same instance (`example.com.yml`), applying `<target_app_configurations>` to ensure seamless functionality between connected applications.
- The configuration for each app combination is structured as follows, again `<target_app_configurations>` is following the guidelines set in the [App Configuration](#app-configuration) section:
```
<target_app_recipe>:
@ -125,9 +90,10 @@ The `combine.yml` configuration additionally contains
<target_app_configurations>
```
### Templating Configurations
Each configuration file can have a `GLOBALS` section, that cat be used to template the configuration with global variables.
Each configuration file can include a `GLOBALS` section that allows for templating with global variables, making it easier to manage repetitive values across different configurations. Here is how you can define and use these global variables:
```
GLOBALS:
@ -142,14 +108,18 @@ nextcloud:
MAIL_FROM_ADDRESS: "{{smtp_user}}"
```
The `server` variable is used to specify on which server the instance should be deployed. If it's not specified the instance domain from the filename `example.com.yml` is taken.
- **`server`**: Specifies the server where the instance will be deployed. If not provided, the instance domain is automatically taken from the `example.com.yml` file name.
## Inheriting Configuration Structure
In the simplest case it's possible to have only one `example.com.yml` and place all the necessary configuration in there. If you want to maintain multiple similar instances you can merge the common app configurations inside a global `alaka.yml`. If the deployment gets more complex it is possible to group instances inside folder and have an `alaka.yml` for each group.
For even more complexity each group can inherit the app configurations from the upper groups.
Alakazam supports a flexible inheritance model for configuration management, allowing for both simplicity and complexity depending on your deployment needs:
The following example shows how this configuration structure can be used to deploy complex systems:
- **Simple Configuration**: For straightforward setups, you can manage everything within a single `example.com.yml` file, placing all necessary configurations directly in this document.
- **Multiple Similar Instances**: To manage multiple similar instances efficiently, common application configurations can be centralized in a global `alaka.yml`. This method reduces duplication by allowing shared settings across multiple instances.
- **Grouped Instances**: For more complex setups, instances can be organized into folders, each with its own `alaka.yml`. This structure allows for group-specific configurations, making it easier to manage settings at different levels of your infrastructure hierarchy.
- **Inherited Configurations**: In even more complex scenarios, each group can inherit configurations from the levels above it. This cascading setup ensures that changes at a higher level can be automatically applied to all subordinate groups and instances, maintaining consistency and ease of updates across your entire environment.
This hierarchical approach to configuration is designed to scale with your system’s complexity and can be visualized through the following example diagram:
[File Structure](./config_file_structure.png)
@ -160,14 +130,19 @@ The following example shows how this configuration structure can be used to depl
### Install alakazam
TODO
To install Alakazam, follow these steps to clone the repository and set up the executable:
```bash
git clone https://git.coopcloud.tech/moritz/alakazam.git
cd alakazam
ln -s $PWD/alakazam.sh ~/.local/bin/alakazam
# Ensure `~/.local/bin` is in your `$PATH`
```
## Create a new instance:
1. The `example.com.yml` is created by the operator to define the domain and required apps
- a simple example could look like this:
To set up a new instance with Alakazam, begin by specifying the required applications in `example.com.yml`. The name of this file determines the domain for the instance.
Here's an example configuration:
```
traefik:
@ -182,43 +157,20 @@ element-web:
rallly:
```
2. `./alakazam.py -p example.com.yml config`
for each app the env files are generated:
Ensure that DNS records are set up for all your applications. The simplest approach is to create a `CNAME` record for the wildcard domain `*.example.com` to cover all subdomains used by the apps.
- The app configurations from `combine.yml` are taken if the source app and the target app are part of the instace
- the app configuration of all the upper `alaka.yml` files are merged
- the inherited configuration is overwritten by the instance configuration `example.com.yml` and applied to the env file
2. `./alakazam.py -p example.com.yml secrets`
for each app the secrets are inserted:
For a more comprehensive configuration, refer to the example in [./examples/alaka.yml](./examples/alaka.yml), which can also serve as a template for single-instance configurations (`example.com.yml`).
4. for each app the `combine.yml` configs are applied on the env files and secrets are inserted
- the shared_secrets are generated
- `<source_app_recipe>.example.com` is replaced in the `<target_app_recipe>` env file according to `subdomain` configuration
5. all the remaining secrets are generated
4. `./alakazam.py deploy-apps`
- each app is deployed
- the `execute` commands from `defaults.yml`, `configs.yml` and `combine.yml` are executed
Steps to initialize the instance:
Step 3. (`./alakazam.py setup-apps`) should be executed every time the config is changed or the recipe env file is updated. It regenerates the env files and creates all the necessary secrets.
The env files itself shouldn't be edited manually anymore.
1. **Generate .env Files**: `./alakazam -p example.com.yml config`
2. **Insert Secrets**: `./alakazam -p example.com.yml secrets`
3. **Deploy Applications**: `./alakazam -p example.com.yml deploy -r`
- the `-r` flag executes post-deployment hooks after each deployment
## Conceptual Questions
### Updating All Instances
- Possible abra integration
- An independent wrapper for abra, that uses abras `--machine` output
- A go binary that is build on top of the abra library
- An abra command like `abra compose`
To update all instances:
- Put `config.yml` into `~/.abra/servers/<server>/` or let the user decide?
- Should we move completely away from .env files?
- This would skip the translation step into env files
- It reduces the complexity!
- Recipes couldn't be run with `docker compose` only anymore
- Is this still possible?
- Where should the `combine.yml` be maintained?
- Separated config for each recipe?
- better configuration versioning for different recipe versions
- harder to maintain the recipes: requires knowledge about the connectable apps
- Global config?
1. **Update Environment Files**: `alakazam -p example.com.yml config` to refresh .env files. It's a good practice to keep these files under version control (e.g., in a Git repository at `~/.abra/example.com`) and review changes with `git diff` before proceeding.
2. **Upgrade Applications**: `./alakazam -p example.com.yml upgrade` to update all applications.

197
examples/alaka.yml Normal file
View File

@ -0,0 +1,197 @@
GLOBALS:
smtp_password: your_super_secret_password
smtp_password_urlencoded: your_super_secret_password
bbb_secret: your_super_secret_password
turn_secret: your_super_secret_password
basic_auth_password: your_super_secret_password
loki_url: https://loki.monitoring.example.com/loki/api/v1/push
basic_auth_hash: your_super_secret_password
smtp_user: noreply
smtp_domain: example.com
smtp_host: mail.example.com
authentik:
subdomain: login.example.com
env:
EXTRA_DOMAINS: ', `example.com`'
AUTHENTIK_EMAIL__HOST: "{{smtp_host}}"
AUTHENTIK_EMAIL__USERNAME: "{{smtp_user}}@{{smtp_domain}}"
AUTHENTIK_EMAIL__FROM: "{{smtp_user}}@{{smtp_domain}}"
DEFAULT_LANGUAGE: de
APPLICATIONS: '{"Calendar": "https://nextcloud.example.com/apps/calendar/", "BBB": "https://nextcloud.example.com/apps/bbb"}'
uncomment:
- calendar.svg
- bbb.jpg
execute:
- worker set_admin_pass
- worker apply_blueprints
- worker add_applications
- local set_icons
secrets:
email_pass: "{{smtp_password}}"
nextcloud:
subdomain: files.example.com
env:
SMTP_AUTHTYPE: LOGIN
SMTP_HOST: "{{smtp_host}}"
SMTP_SECURE: tls
SMTP_NAME: "{{smtp_user}}@{{smtp_domain}}"
SMTP_PORT: 587
DEFAULT_QUOTA: "100 MB"
MAIL_FROM_ADDRESS: "{{smtp_user}}"
MAIL_DOMAIN: "{{smtp_domain}}"
APPS: "calendar"
BBB_URL: "https://talk.example.com/bigbluebutton/"
uncomment:
- compose.smtp.yml
- SECRET_SMTP_PASSWORD_VERSION
- compose.apps.yml
- SECRET_BBB_SECRET_VERSION
secrets:
bbb_secret: "{{bbb_secret}}"
smtp_password: "{{smtp_password}}"
execute:
- app install_bbb
- app set_default_quota
- app install_apps
- app run_occ 'app:disable dashboard'
wordpress:
subdomain: blog.example.com
env:
LOCALE: 'de_DE'
DEFAULT_USER_ROLE: administrator
SMTP_HOST: "{{smtp_host}}"
MAIL_FROM: "{{smtp_user}}@{{smtp_domain}}"
SMTP_USER: "{{smtp_user}}@{{smtp_domain}}"
ADMIN_EMAIL: "{{smtp_user}}@{{smtp_domain}}"
uncomment:
- SMTP_PORT
- SMTP_AUTH
- SMTP_OVERRIDE_FROM
- SMTP_TLS
- SECRET_SMTP_PASSWORD_VERSION
- compose.smtp.yml
- compose.mailrelay.yml
- EXTRA_DOMAINS
secrets:
smtp_password: "{{smtp_password}}"
execute:
- app core_install
vikunja:
subdomain: todo.example.com
env:
SMTP_HOST: "{{smtp_host}}"
SMTP_AUTHTYPE: login
SMTP_USER: "{{smtp_user}}"
SMTP_FROM_EMAIL: "{{smtp_user}}@{{smtp_domain}}"
uncomment:
- compose.smtp.yml
- SMTP_ENABLED
- SECRET_SMTP_PASSWORD_VERSION
secrets:
smtp_password: "{{smtp_password}}"
matrix-synapse:
subdomain: matrix.example.com
env:
ADMIN_EMAIL: "{{smtp_user}}@{{smtp_domain}}"
SMTP_APP_NAME: mail
SMTP_FROM: "{{smtp_user}}@{{smtp_domain}}"
SMTP_HOST: "{{smtp_host}}"
SMTP_PORT: 587
SMTP_USER: "{{smtp_user}}@{{smtp_domain}}"
ENCRYPTED_BY_DEFAULT: off
TURN_URIS: '["turns:talk.example.com:5349?transport=tcp"]'
RETENTION_MAX_LIFETIME: 2y
ALLOWED_LIFETIME_MAX: 2y
uncomment:
- POST_DEPLOY_CMDS
- compose.smtp.yml
- SMTP_ENABLED
- SECRET_SMTP_PASSWORD_VERSION
- compose.turn.yml
- TURN_ENABLED
- TURN_ALLOW_GUESTS
- SECRET_TURN_SHARED_SECRET_VERSION
secrets:
smtp_password: "{{smtp_password}}"
turn_shared_secret: "{{turn_secret}}"
element-web:
subdomain: chat.example.com
wekan:
subdomain: board.example.com
env:
MAIL_URL: "smtp://{{smtp_user}}%40{{smtp_domain}}:{{smtp_password_urlencoded}}@{{smtp_host}}:587"
MAIL_FROM: "Wekan Notifications <{{smtp_user}}@{{smtp_domain}}>"
uncomment:
- PASSWORD_LOGIN_ENABLED
backup-bot-two:
subdomain: backup.example.com
uncomment:
- SECRET_AWS_SECRET_ACCESS_KEY_VERSION
- compose.s3.yml
onlyoffice:
subdomain: office.example.com
env:
AUTO_ASSEMBLY_ENABLED: "true"
outline:
subdomain: outline.example.com
env:
DEFAULT_LANGUAGE: de_DE
SMTP_HOST: "{{smtp_host}}"
SMTP_PORT: 465
SMTP_USERNAME: "{{smtp_user}}@{{smtp_domain}}"
SMTP_FROM_EMAIL: "{{smtp_user}}@{{smtp_domain}}"
uncomment:
- compose.smtp.yml
- SMTP_ENABLED
- SMTP_SECURE
- SECRET_SMTP_PASSWORD_VERSION
secrets:
smtp_password: "{{smtp_password}}"
rallly:
subdomain: poll.example.com
env:
SUPPORT_EMAIL: "{{smtp_user}}@{{smtp_domain}}"
SMTP_HOST: "{{smtp_host}}"
SMTP_USER: "{{smtp_user}}@{{smtp_domain}}"
secrets:
smtp_pwd: "{{smtp_password}}"
hedgedoc:
subdomain: pad.example.com
env:
CMD_ALLOW_ANONYMOUS: true
CMD_ALLOW_ANONYMOUS_EDITS: true
CMD_ALLOW_FREEURL: true
CMD_COOKIE_POLICY: none
pretix:
subdomain: tickets.example.com
env:
SMTP_FROM: "{{smtp_user}}@{{smtp_domain}}"
SMTP_HOST: "{{smtp_host}}"
SMTP_USER: "{{smtp_user}}@{{smtp_domain}}"
SMTP_PORT: 587
SMTP_TLS: on
SMTP_SSL: off
secrets:
smtp_password: "{{smtp_password}}"
traefik:
env:
DASHBOARD_ENABLED: false
LETS_ENCRYPT_EMAIL: "{{smtp_user}}@{{smtp_domain}}"
METRICS_ENABLED: 1
BASIC_AUTH: 1
secrets:
usersfile: "{{basic_auth_hash}}"
uncomment:
- compose.host.yml
- compose.metrics.yml
- compose.basicauth.yml
- SECRET_USERSFILE_VERSION
monitoring-ng:
subdomain: monitoring.example.com
env:
LOKI_PUSH_URL: "{{loki_url}}"
uncomment:
- compose.promtail.yml
- SECRET_BASIC_AUTH_VERSION
secrets:
basic_auth: "{{basic_auth_password}}"

18
examples/config.yml
View File

@ -1,18 +0,0 @@
domain: example-domain.com
server: example-server.com
apps:
authentik:
env:
WELCOME_MESSAGE: "Welcome to CoopCloud"
wekan:
nextcloud:
onlyoffice:
wordpress:
subdomain: "blog.special-domain.com"
vikunja:
subdomain: "todo.example.com"
matrix-synapse:
element-web:
env:
SERVER_NAME: testmatrix
BRAND: testmatrix

99
examples/defaults.yml
View File

@ -1,99 +0,0 @@
GLOBALS:
smtp_password: top-secret
smtp_user: noreply
smtp_domain: example.com
smtp_host: mail.example.com
authentik:
subdomain: example.com
env:
AUTHENTIK_EMAIL__HOST: "{{smtp_host}}"
AUTHENTIK_EMAIL__USERNAME: "{{smtp_user}}@{{smtp_domain}}"
AUTHENTIK_EMAIL__FROM: "{{smtp_user}}@{{smtp_domain}}"
DEFAULT_LANGUAGE: de
execute:
- worker set_admin_pass
- worker apply_blueprints
- worker apply_blueprints
- worker add_applications # Todo: fix this command
- local set_icons
secrets:
email_pass: "{{smtp_password}}"
nextcloud:
subdomain: cloud.example.com
env:
SMTP_AUTHTYPE: LOGIN
SMTP_HOST: "{{smtp_host}}"
SMTP_SECURE: tls
SMTP_NAME: "{{smtp_user}}@{{smtp_domain}}"
SMTP_PORT: 587
MAIL_FROM_ADDRESS: "{{smtp_user}}"
MAIL_DOMAIN: "{{smtp_domain}}"
APPS: "calendar"
BBB_URL: "https://talk.example.com/bigbluebutton/"
uncomment:
- compose.smtp.yml
- SECRET_SMTP_PASSWORD_VERSION
- compose.apps.yml
- SECRET_BBB_SECRET_VERSION
secrets:
smtp_password: "{{smtp_password}}"
execute:
- app install_bbb
- app set_default_quota
- app install_apps
# - app run_occ 'app:disable dashboard' # Todo: fix this command
wordpress:
env:
LOCALE: 'de_DE'
DEFAULT_USER_ROLE: administrator
SMTP_HOST: "{{smtp_host}}"
MAIL_FROM: "{{smtp_user}}@{{smtp_domain}}"
uncomment:
- SMTP_PORT
- SMTP_AUTH
- SMTP_TLS
- SECRET_SMTP_PASSWORD_VERSION
secrets:
smtp_password: "{{smtp_password}}"
execute:
- app core_install
vikunja:
env:
SMTP_HOST: "{{smtp_host}}"
SMTP_AUTHTYPE: login
SMTP_USER: "{{smtp_user}}"
SMTP_FROM_EMAIL: "{{smtp_user}}@{{smtp_domain}}"
uncomment:
- compose.smtp.yml
- SMTP_ENABLED
- SECRET_SMTP_PASSWORD_VERSION
secrets:
smtp_password: "{{smtp_password}}"
matrix-synapse:
subdomain: matrix.example.com
env:
SMTP_APP_NAME: mail
SMTP_FROM: "{{smtp_user}}@{{smtp_domain}}"
SMTP_HOST: "{{smtp_host}}"
SMTP_PORT: 587
SMTP_USER: "{{smtp_user}}@{{smtp_domain}}"
ENCRYPTED_BY_DEFAULT: "off"
uncomment:
- POST_DEPLOY_CMDS
- compose.smtp.yml
- SMTP_ENABLED
- SECRET_SMTP_PASSWORD_VERSION
secrets:
smtp_password: "{{smtp_password}}"
element-web:
subdomain: chat.example.com
wekan:
subdomain: board.example.com
env:
# TODO fix format for smtp_password
MAIL_URL: "smtp://{{smtp_user}}%40{{smtp_domain}}%3A{{smtp_password}}@{{smtp_host}}:587/"
MAIL_FROM: "Wekan Notifications <{{smtp_user}}@{{smtp_domain}}>"
uncomment:
- PASSWORD_LOGIN_ENABLED
backup-bot-two:
subdomain: backup.example.com

15
examples/example.com.yml Normal file
View File

@ -0,0 +1,15 @@
traefik:
backup-bot-two:
monitoring-ng:
authentik:
nextcloud:
onlyoffice:
wordpress:
vikunja:
wekan:
matrix-synapse:
element-web:
rallly:
outline:
hedgedoc:
pretix: