-
Notifications
You must be signed in to change notification settings - Fork 82
Documented ibexa/cloud package #2985
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: 5.0
Are you sure you want to change the base?
Changes from all commits
efeb0a5
7815d84
2060a44
f8b7e1e
350b333
1c434e7
9ff9ab2
29f39b2
92ff475
029dc09
2a2451a
29696f8
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,147 @@ | ||
| --- | ||
| description: Environment variables automatically generated based on Ibexa Cloud relationships and routes. | ||
|
Check failure on line 2 in docs/ibexa_cloud/environment_variables.md
|
||
| --- | ||
|
|
||
| # Environment variables on Ibexa Cloud | ||
|
|
||
| [[= product_name_cloud =]] automatically generates environment variables based on the Upsun relationships and routes configuration. | ||
|
Check notice on line 7 in docs/ibexa_cloud/environment_variables.md
|
||
| It parses `PLATFORM_RELATIONSHIPS` and `PLATFORM_ROUTES` environment variables and exposes them as application-specific variables. | ||
|
|
||
| Environment variable prefixes are created by converting relationship names to uppercase and replacing hyphens with underscores. | ||
|
Check notice on line 10 in docs/ibexa_cloud/environment_variables.md
|
||
|
|
||
| When multiple endpoints are defined for a single relationship, numerical indices are used for all entries except the first one, for example: `SOLR`, `SOLR_1_`, `SOLR_2`. | ||
|
Check notice on line 12 in docs/ibexa_cloud/environment_variables.md
|
||
| When multiple services of the same type are present, environment variables are exposed for each service accordingly based on their relationship names. | ||
|
Check notice on line 13 in docs/ibexa_cloud/environment_variables.md
|
||
|
|
||
| ## Using environment variables in configuration files | ||
|
Check notice on line 15 in docs/ibexa_cloud/environment_variables.md
|
||
|
|
||
| If you're referencing [[= product_name_cloud =]] environment variables in your configuration files, you must define placeholder values for them in your `.env` file to prevent Symfony container initialization failures. | ||
|
|
||
| Do it only for the variables that are required for the Symfony container to build. | ||
|
Check notice on line 19 in docs/ibexa_cloud/environment_variables.md
|
||
|
|
||
| For example, if your `doctrine.yaml` uses a [database variable](#database-variables) created for a relationship named `pgsql`: | ||
|
|
||
| ``` yaml | ||
| doctrine: | ||
| dbal: | ||
| url: '%env(resolve:PGSQL_URL)%' | ||
| ``` | ||
|
|
||
| You must define a placeholder value in `.env`: | ||
|
|
||
| ``` env | ||
| PGSQL_URL="postgresql://app:!ChangeMe!@127.0.0.1:5432/app?serverVersion=16&charset=utf8" | ||
| ``` | ||
|
|
||
| The actual value of the environment variable is provided by [[= product_name_cloud =]] at runtime. | ||
|
Check notice on line 35 in docs/ibexa_cloud/environment_variables.md
|
||
| The placeholder in `.env` is only required to prevent Symfony container compilation errors during build. | ||
|
|
||
| ## Relationship naming conventions | ||
|
|
||
| You can choose relationship names freely in `.platform.app.yaml` for most services. | ||
|
|
||
| The only required names are: | ||
|
|
||
| - `dfs_database` - DFS database (required for DFS functionality) | ||
| - `redissession` or `valkeysession` - Redis/Valkey for sessions (required for dedicated session storage) | ||
|
|
||
| Common relationship name include: | ||
|
|
||
| - `database` - main application database | ||
| - `rediscache` - Redis for cache | ||
| - `elasticsearch` - Elasticsearch search service | ||
| - `solr` - Solr search service | ||
|
|
||
| ## Database variables | ||
|
|
||
| For MySQL and PostgreSQL databases, the following variables are generated based on the relationship name (e.g., `database`): | ||
|
Check notice on line 56 in docs/ibexa_cloud/environment_variables.md
|
||
|
|
||
| - `{RELATIONSHIP_NAME}_URL` - full database URL with charset and server version | ||
|
Check notice on line 58 in docs/ibexa_cloud/environment_variables.md
|
||
| - `{RELATIONSHIP_NAME}_USER` / `{RELATIONSHIP_NAME}_USERNAME` - database user | ||
| - `{RELATIONSHIP_NAME}_PASSWORD` - database password | ||
| - `{RELATIONSHIP_NAME}_HOST` - database host | ||
| - `{RELATIONSHIP_NAME}_PORT` - database port | ||
| - `{RELATIONSHIP_NAME}_NAME` / `{RELATIONSHIP_NAME}_DATABASE` - database name | ||
| - `{RELATIONSHIP_NAME}_DRIVER` - database driver | ||
| - `{RELATIONSHIP_NAME}_SERVER` - database server | ||
|
|
||
| For example, for a relationship called `database` the environment variables are named `DATABASE_URL`, `DATABASE_HOST`, `DATABASE_USER`, etc. | ||
|
Check notice on line 67 in docs/ibexa_cloud/environment_variables.md
|
||
|
|
||
| For more information about database configuration, see [Databases](databases.md). | ||
|
|
||
| ## DFS database variables | ||
|
Check notice on line 71 in docs/ibexa_cloud/environment_variables.md
|
||
|
|
||
| When using [distributed file storage (DFS) using a separate database](clustering.md#dfs-io-handler), you must use the relationship name `dfs_database`. | ||
|
Check notice on line 73 in docs/ibexa_cloud/environment_variables.md
|
||
| In addition to the database variables listed above, additional DFS-specific variables are created when `PLATFORMSH_DFS_NFS_PATH` is set: | ||
|
Check notice on line 74 in docs/ibexa_cloud/environment_variables.md
|
||
|
|
||
| - `DFS_NFS_PATH` - NFS path for DFS storage | ||
| - `DFS_DATABASE_CHARSET` - database character set | ||
| - `DFS_DATABASE_COLLATION` - database collation | ||
|
|
||
| ## Cache variables | ||
|
|
||
| For Redis, Valkey, and Memcached cache services, the following variables are available. | ||
|
Check failure on line 82 in docs/ibexa_cloud/environment_variables.md
|
||
|
|
||
| - `{RELATIONSHIP_NAME}_URL` (Redis/Valkey only) | ||
| - `{RELATIONSHIP_NAME}_HOST` | ||
| - `{RELATIONSHIP_NAME}_PORT` | ||
| - `{RELATIONSHIP_NAME}_SCHEME` (Redis/Valkey only) | ||
|
|
||
| In addition, the following global variables are defined: | ||
|
Check notice on line 89 in docs/ibexa_cloud/environment_variables.md
|
||
|
|
||
| - `CACHE_POOL` - either `cache.redis` or `cache.memcached` | ||
| - `CACHE_DSN` - cache connection string | ||
|
|
||
| !!! note | ||
| Redis/Valkey services have higher priority than Memcached services when building the global cache variables. | ||
|
|
||
| For more information about persistence cache configuration, see [Persistence cache](persistence_cache.md). | ||
|
|
||
| ## Session variables | ||
|
|
||
| For Redis-based session storage, the following variables are available. | ||
|
|
||
| - `SESSION_HANDLER_ID` - session handler class name | ||
| - `SESSION_SAVE_PATH` - Redis connection in `host:port` format | ||
|
|
||
| The system looks for a relationships named `redissession` or `valkeysession` first. | ||
| If not found, it uses the first available Redis-compatible service. | ||
|
|
||
| For more information about session configuration, see [Sessions](sessions.md). | ||
|
|
||
| ## Search engine variables | ||
|
|
||
| ### Solr | ||
|
|
||
| For Solr search engine configuration, the following variables are generated: | ||
|
Check notice on line 115 in docs/ibexa_cloud/environment_variables.md
|
||
|
|
||
| - `SEARCH_ENGINE` - set to `solr` | ||
| - `SOLR_DSN` - Solr connection string | ||
| - `SOLR_CORE` - Solr core name | ||
| - `{RELATIONSHIP_NAME}_HOST` | ||
| - `{RELATIONSHIP_NAME}_PORT` | ||
| - `{RELATIONSHIP_NAME}_NAME` / `{RELATIONSHIP_NAME}_DATABASE` | ||
|
|
||
| For more information, see [Solr search engine](solr_overview.md). | ||
|
|
||
| ### Elasticsearch | ||
|
|
||
| For Elasticsearch search engine configuration, the following variables are generated: | ||
|
Check notice on line 128 in docs/ibexa_cloud/environment_variables.md
|
||
|
|
||
| - `SEARCH_ENGINE` - set to `elasticsearch` | ||
| - `ELASTICSEARCH_DSN` - Elasticsearch connection string | ||
| - `{RELATIONSHIP_NAME}_URL` | ||
| - `{RELATIONSHIP_NAME}_HOST` | ||
| - `{RELATIONSHIP_NAME}_PORT` | ||
| - `{RELATIONSHIP_NAME}_SCHEME` | ||
|
|
||
| For more information, see [Elasticsearch](elasticsearch_overview.md). | ||
|
|
||
| ## HTTP cache variables (Varnish) | ||
|
Check notice on line 139 in docs/ibexa_cloud/environment_variables.md
|
||
|
|
||
| For Varnish-based HTTP caching, the following variables are available. | ||
|
|
||
| - `HTTPCACHE_PURGE_TYPE` - set to `varnish` | ||
| - `HTTPCACHE_PURGE_SERVER` - Varnish server address | ||
| - `HTTPCACHE_VARNISH_INVALIDATE_TOKEN` - token for cache invalidation | ||
|
|
||
| For more information about HTTP cache and Varnish configuration, see [HTTP cache](http_cache.md). | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if the strict naming requirement makes sense now - Redis, Elasticsearch, Solr and databases don't have to be named in any specific way. The only required ones are
dfs_databaseandredissession.Developers can have multirepo setup with many services, and environmental variables are exposed accordingly. So maybe we shouldn't enforce the setup with word "use" - wdyt?