Intermediate 5: Multi-app configuration
The information in this post is accurate as of the published date . Please make sure to check any linked documentation within the post for changes/updates.
Review
From the previous lessons, you’ve gotten used to configuring and deploying repositories to Platform.sh with three files:
-
.platform/routes.yaml
: for handling requests -
.platform/services.yaml
: for configuring and defining services -
.platform.app.yaml
: for defining build and deploy steps for the application
Configuring multiple applications
On Platform.sh, it’s just as easy to define multiple application containers within your repositories.
Take a look at the repository tree below:
.
├── .platform
│ ├── routes.yaml
│ └── services.yaml
├── .platform.app.yaml
├── README.md
├── ....
├── application code
└── ...
This could be the repository structure for any project deployed on Platform.sh, but let’s begin by assuming that it represents a PHP-based CMS like Drupal or WordPress. Every bit of code and configuration exists in the root of the repository in this case, but the following would be equally valid:
.
├── .platform
│ ├── routes.yaml
│ └── services.yaml
└── drupal
├── .platform.app.yaml
├── README.md
├── ....
├── application code
└── ....
Here, all of our application code and application configuration can be nested inside of a subdirectory called drupal
. This doesn’t just enable you to clean up your codebase a bit, but also to define an application container as a submodule (which becomes more relevant as you add more applications).
Now, let’s say that I plan on decoupling my application - that is, I want to rely less on Drupal’s built-in frontend tooling (Twig) and instead leverage its JSON API and consume content data with a different frontend. Next.js is looking promising, so I may want to create a new development environment to test out the changes.
If you already have a Next.js project to start playing with, one way to test it is with the following:
.
├── .platform
│ ├── routes.yaml
│ └── services.yaml
├── drupal
| ├── .platform.app.yaml
| ├── README.md
| ├── ....
| ├── application code
| └── ....
└── nextjs
├── .platform.app.yaml
├── README.md
├── ....
├── application code
└── ....
Next.js gets its own subdirectory called nextjs
that contains its application code and it’s own .platform.app.yaml
file to configure its builds and deployments. In our new environment we can test and merge this new application into production when we’re satisfied. From that point on each environment will inherit this new architecture, giving them copies of both application containers every time.
Shared configuration
If we revisit the new structure of the repository, you’ll notice that the project-level .platform
subdirectory hasn’t moved from its original location. This is because configuration here is considered shared across app containers.
Services
For services, that means that a database defined in .platform/services.yaml
db:
type: mariadb:10.4
disk: 2048
can be accessed from both applications (if necessary) with identical relationship
definitions.
relationships:
database: 'db:mysql'
Routes
Route definitions simply get added to the same .platform/routes.yaml
file for all applications.
https://api.{default}/:
type: upstream
upstream: "drupal:http"
id: "api"
cache:
enabled: true
cookies: ['/^SS?ESS/', '/^Drupal.visitor/']
https://www.api.{default}/:
type: redirect
to: "https://api.{default}/"
https://www.{default}/:
type: redirect
to: "https://{default}/"
https://{default}/:
type: upstream
primary: true
id: "client"
upstream: "nextjs:http"
The above snippet
- Modifies the
drupal
app’s url to theapi
subdomain. - Directs traffic at the root domain to the
nextjs
application.
Next: Multi-app reusability
-
Shouldn’t be?:
https://www.{default}/: type: redirect to: "https://{default}/"
0 -
Right you are! Updated, and thanks!
0
Please sign in to leave a comment.
Comments
2 comments