From cb2e71013fc63eb9028e368bb8d96055c1d9c499 Mon Sep 17 00:00:00 2001 From: Moritz Date: Thu, 2 May 2024 15:22:01 +0200 Subject: [PATCH] update README --- README.md | 212 +++++++++++++++------------------------ examples/alaka.yml | 197 ++++++++++++++++++++++++++++++++++++ examples/config.yml | 18 ---- examples/defaults.yml | 99 ------------------ examples/example.com.yml | 15 +++ 5 files changed, 294 insertions(+), 247 deletions(-) create mode 100644 examples/alaka.yml delete mode 100644 examples/config.yml delete mode 100644 examples/defaults.yml create mode 100644 examples/example.com.yml diff --git a/README.md b/README.md index 79b0937..901ee43 100644 --- a/README.md +++ b/README.md @@ -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` (`.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`** (`.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 `` steps can be used: +`alaka.yml`, `example.com.yml` and `combine.yml` contain a similar configuration structure. +For each app/recipe the following `` 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. - `:` - - a mapping to define which secrets should be shared between two apps ### Configuration Structure -1. `alaka.yml` and `example.com.yml` - - the `` entries in `alaka.yml` define global app configurations that should be inherited by all underlaying configurations - - in `example.com.yml` the entries `` define which apps should be installed - - the `` 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 (``) 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 (`` entries), focusing on the individual needs of each instance. + - Configurations within these files are structured as follows, with specific `` settings detailed in the [App Configuration](#app-configuration) section: ``` : ``` - -3. `combine.yml` - - it contains the `` that should be applied to the target app if both the `` and the `` is part of the same instance (`example.com.yml`) - - the `` 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 `` to ensure seamless functionality between connected applications. + - The configuration for each app combination is structured as follows, again `` is following the guidelines set in the [App Configuration](#app-configuration) section: ``` : @@ -125,9 +90,10 @@ The `combine.yml` configuration additionally contains ``` + ### 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 - - `.example.com` is replaced in the `` 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//` 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. diff --git a/examples/alaka.yml b/examples/alaka.yml new file mode 100644 index 0000000..2c4ba89 --- /dev/null +++ b/examples/alaka.yml @@ -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}}" diff --git a/examples/config.yml b/examples/config.yml deleted file mode 100644 index 88c1e2f..0000000 --- a/examples/config.yml +++ /dev/null @@ -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 diff --git a/examples/defaults.yml b/examples/defaults.yml deleted file mode 100644 index e83e3b8..0000000 --- a/examples/defaults.yml +++ /dev/null @@ -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 diff --git a/examples/example.com.yml b/examples/example.com.yml new file mode 100644 index 0000000..5e1b044 --- /dev/null +++ b/examples/example.com.yml @@ -0,0 +1,15 @@ +traefik: +backup-bot-two: +monitoring-ng: +authentik: +nextcloud: +onlyoffice: +wordpress: +vikunja: +wekan: +matrix-synapse: +element-web: +rallly: +outline: +hedgedoc: +pretix: