Comments (14)
Services to be considered:
from ddev-platformsh.
What are the databases that we currently support in the add-on? Postgres only or is MySQL/MariaDB also supported?
from ddev-platformsh.
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.
from ddev-platformsh.
Thanks @rfay .
I'm also describing here what $PLATFORM_RELATIONSHIPS
env var contains. We need to expose it for the services we support, as it may be used in various situations, such as:
- Application services configuration
- blog.blackfire.io example
- Laravel template example, which uses the Laravel bridge, which leverages the config reader
- Environment variables mapping using a
.environment
file, which gets sourced when FPM is started, before cron commands are run, and when logging into the container over SSH (example with Akeneo) - Build/Deploy hooks
from ddev-platformsh.
Added more details about the relationship object for common services.
from ddev-platformsh.
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.
from ddev-platformsh.
@rfay I updated the description 🙂 . You have an example with the database.
Regarding blog.blackfire.io, I know but I can't add you (not enough seats)
from ddev-platformsh.
Exposing $PLATFORM_RELATIONSHIPS
would ensure that any app pulled from Platform.sh would work without any configuration change. Users leverage this env var in different ways, as I explained in my previous comment. As an example, they may configure their database by extracting the credentials our of $PLATFORM_RELATIONSHIPS
and exposing the env vars that their app is expecting. This is what is done in the Akeneo template, since Akeneo expects the $APP_DATABASE_*
variables to be populated:
# .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 $PLATFORM_RELATIONSHIPS
variable.
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 $PLATFORM_RELATIONSHIPS
to be exposed 😉 .
from ddev-platformsh.
Exposing $PLATFORM_RELATIONSHIPS would ensure that any app pulled from Platform.sh would work without any configuration change
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 $PLATFORM_RELATIONSHIPS
variable
from ddev-platformsh.
Thanks for explaining this.
There are a some implications here.
- The normal usage of DDEV with a known project type generates settings for that project type. For example, for Drupal9, ddev will generate a settings.ddev.php and make settings.php include it. We would have to turn that off with
disable_settings_management: true
- Currently DDEV tries to do all this configuration work without starting a project. That means it doesn't have a predictable environment to work in, doesn't have jq or base64 to use directly. Sprig, which is already built into the golang template features here, has base64 encoding capability with
b64enc
, http://masterminds.github.io/sprig/encoding.html. However, the data structure we have to create and then encode is probably too complex for the install.yaml.
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?
from ddev-platformsh.
Thanks for these precisions!
- Settings management: I think we probably should disable settings management as you suggest, but let's discuss it today.
- I'm not sure this can be handled without starting the project, since it needs the services to be started I guess. Regarding your suggestion of constructing a
$PLATFORM_RELATIONSHIPS
that is essentially static, I don't know. If it's possible yes, but is it? Anyway, we could expose everything that's available for sure.
from ddev-platformsh.
Creating json with just jq, https://spin.atomicobject.com/2021/06/08/jq-creating-updating-json/
from ddev-platformsh.
@flovntp points out in slack:
i don't know if it helps but to get (dynamic) credentials into the .environment file, this is how i did :
https://github.com/flovntp/platformsh-symfony-template/blob/symfony-6.1-php8.1-webapp/.environment#L5
export DATABASE_HOST=$(echo $PLATFORM_RELATIONSHIPS | base64 --decode | jq -r ".database[0].host")
export DATABASE_PORT=$(echo $PLATFORM_RELATIONSHIPS | base64 --decode | jq -r ".database[0].port")
export DATABASE_NAME=$(echo $PLATFORM_RELATIONSHIPS | base64 --decode | jq -r ".database[0].path")
export DATABASE_USER=$(echo $PLATFORM_RELATIONSHIPS | base64 --decode | jq -r ".database[0].username")
export DATABASE_PASSWORD=$(echo $PLATFORM_RELATIONSHIPS | base64 --decode | jq -r ".database[0].password")
export DATABASE_URL="postgresql://${DATABASE_USER}:${DATABASE_PASSWORD}@${DATABASE_HOST}:${DATABASE_PORT}/${DATABASE_NAME}?serverVersion=14&charset=utf8"
from ddev-platformsh.
With
- #48
blog.blackfire.io works out of the box, nothing to do.
from ddev-platformsh.
Related Issues (20)
- Consider `settings_management_disabled: true` for platform.sh projects
- Remove PLATFORM_MOUNTS and PLATFORM_DIR
- Environment variables must be set much earlier for php-fpm HOT 7
- Tests aren't valid if they don't get to content-checking point HOT 1
- config files and config mismatches HOT 1
- Support multi-app configuration (.platform.app.yaml isn't always in the root (and applications.yaml is a thing too)) HOT 10
- Homebrew base64 does not support `base64 -w` HOT 18
- interface conversion: interface {} is bool, not string HOT 6
- Magento2 doesn't work with add-on: "Cannot find the main route for Magento. Please add `id: magento_route` to your routes.yaml" HOT 6
- [docs] README should explain that `ddev get` is when config translation happens, and you need to repeat if changing Platform config
- shasum is also required and must be handled
- Support redis 7.0 + 6.2 HOT 3
- How to override platform.sh environment variables set in `.ddev/config.platformsh.yaml` ? HOT 5
- ddev get ddev/ddev-platformsh ends with Syntax Error (Ibexa) HOT 9
- Problem on MacOs with base64 option HOT 2
- Python-based app fails to start HOT 2
- Support `composer_version: 2.5.x` or warn if it is not supported HOT 1
- There are no commands defined in the "self" namespace. HOT 1
- upstream value in `PLATFORM_ROUTES` is incorrect HOT 2
- Add-on should no longer use `ddev config` to update web environment
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ddev-platformsh.