-
-
Notifications
You must be signed in to change notification settings - Fork 10
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
PLATFORM_RELATIONSHIPS environment variable and mapping .platform.app.yaml
and services.yaml
#9
Comments
Services to be considered: |
What are the databases that we currently support in the add-on? Postgres only or is MySQL/MariaDB also supported? |
DDEV supports MariaDB 5.5-10.8, MySQL 5.5-8.0, and Postgres 9-14. That's a superset of what Platform supports, so every database type and version Platform supports should work. I've manually tested a variety of MariaDB/MySQL/Postgres but haven't tested all permutations. |
Thanks @rfay . I'm also describing here what
|
Added more details about the relationship object for common services. |
I was hoping for examples of the variable PLATFORM_RELATIONSHIPS. BTW, your blog.blackfire.io example is in a private repo, the link doesn't work. If you could update with the PLATFORM_RELATIONSHIPS env variable that you expect or have, that would be great. |
@rfay I updated the description 🙂 . You have an example with the database. |
.platform.app.yaml
and services.yaml
.platform.app.yaml
and services.yaml
Exposing # .environment
export APP_DATABASE_HOST=$(echo $PLATFORM_RELATIONSHIPS | base64 --decode | jq -r ".database[0].host")
export APP_DATABASE_PORT=$(echo $PLATFORM_RELATIONSHIPS | base64 --decode | jq -r ".database[0].port")
export APP_DATABASE_NAME=$(echo $PLATFORM_RELATIONSHIPS | base64 --decode | jq -r ".database[0].path")
export APP_DATABASE_USER=$(echo $PLATFORM_RELATIONSHIPS | base64 --decode | jq -r ".database[0].username")
export APP_DATABASE_PASSWORD=$(echo $PLATFORM_RELATIONSHIPS | base64 --decode | jq -r ".database[0].password") The Laravel bridge, which is recommended to use along with a Laravel app (and used in the Laravel template), has the same purpose : populating the expected environment variables so that the Laravel app is properly configured: // $config is a Platformsh\ConfigReader\Config instance, from the ConfigReader library
$credentials = $config->credentials($relationshipName);
setEnvVar('DB_CONNECTION', $credentials['scheme']);
setEnvVar('DB_HOST', $credentials['host']);
setEnvVar('DB_PORT', $credentials['port']);
setEnvVar('DB_DATABASE', $credentials['path']);
setEnvVar('DB_USERNAME', $credentials['username']);
setEnvVar('DB_PASSWORD', $credentials['password']); The difference from the previous example is that the Laravel bridge uses the Config Reader (a PHP library provided by Platform.sh) to read the Those are only 2 examples, but would apply to any project pulled from PSH, that users would expect to work (almost) right away using DDEV. And for it to work, it needs |
Their apps wouldn't connect to PSH services, but local ones provided by DDEV. All the details to connect to these local services (host, credentials, etc) would be provided by the |
Thanks for explaining this. There are a some implications here.
Can we construct a master PLATFORM_RELATIONSHIPS that is essentially static? Giving directions on how to contact each service regardless of whether they've decided to use that service? |
Thanks for these precisions!
|
Creating json with just jq, https://spin.atomicobject.com/2021/06/08/jq-creating-updating-json/ |
@flovntp points out in slack:
|
With
|
Services are configured in
.platform/services.yaml
and referenced in.platform.app.yaml
.Let's reflect them in DDEV, in
config.platformsh.yaml
.A lot of services are available in Platform.sh, but we want to reflect the ones that are already available out-of-the-box in DDEV.
Configuring them includes the exposure of the
$PLATFORM_RELATIONSHIPS
environment variable, which contains a base64 encoded JSON blob.We need to ensure that we expose the correct information and credentials about the services we configure.
Example of decoded blob:
hostname
,port
,path
(DB name),username
,password
, etc... should get the corresponding for the DDEV database, e.g. (values presented below are examples only, they may differ from real values from DDEV):The JSON value should then be encoded in base64:
The information exposed is up to the service (each service has a dedicated page, e.g. MariaDB).
Services to configure and to expose in
$PLATFORM_RELATIONSHIPS
Properties in the Relationship JSON object
Each service has its own set of properties, but most are common.
All documented properties must be present, even if they are not used in DDEV.
Meaningful Properties
username
null
if not needed)password
null
otherwise)port
scheme
mysql
,redis
,pgsql
,amqp
,http
, ...)path
Set to
null
when not neededservice
postgresql12
)ip
hostmame
type
services.yaml
Properties that must be present, but can be left with default values
fragment
null
public
false
cluster
rel
scheme
query
{"is_master": true}
Otherwise, set to
{}
host_mapped
false
The text was updated successfully, but these errors were encountered: