Okay. Now we’re going to get here in unit three, we are going to look a bit deeper into the configuration files that the cloud provides. There’s four of them. These are the the configuration files for the cloud-specific aspects of a Magento cloud project.

So basically these take the form of four files that are added to your repository in the locations you can see on the slide there, and we’ll take a deeper look at all of those files.

First a little bit more about what does, you know, specifically in your code repository what code files and configuration files are added in addition to the Magento core application.

You’ve got ECE tools, which is the deployment scripts, basically the main thing ECE tools does is provide the scripts that are actually deploying Magento.

And these are managed by a few different repositories. The repositories have a different structure now than they did when these slides were created. So I wouldn’t take these, the bottom two things too literally, but you do have ECE tools, which are the deployment scripts, at this point, you also have cloud docker which is a local development and testing environment.

That’s one of the packages you get with cloud and also a package of Magento curated patches that Magento believes should be deployed on every cloud project. So those are some of the tools, the cloud-specific tools you get, in addition to the Magento application.

Here’s some of the files and directories that you’re going to see in the repository that you would not have seen in a normal on-premises, Magento installation, you’ve got configuration files of various kinds. Most of them are yaml files. You’ve got a m2-hotfixes directory which is where you place any patches that you wish to apply to your project. These are automatically applied during the deployment process.

So a little bit more about the read only file system.

For security purposes, most of the file system is in the cloud is read only, but you do have some directories that need to be writeable during the runtime of Magento, the var directory, for instance, contains logs that are constantly being written to during the run time of Magento, so that does need to be writeable, so your var directory is writeable, so your pub static directory is writeable, your pub media directory is writeable, and for various reasons your etc directory is also a writeable.

So now getting back to those four configuration files, we said, we’d look at in detail. The first one is in the .magento directory, routes.yaml, this has some information about how web requests are routed.

You’ve got your services.yaml in that same directory, and this is what defines services, such as your database, Redis, Elasticsearch, and RabbitMQ, if you’re using that message Q system, and then in the root of your file system, you’ve got this.magento.app.yaml, this is not in any directory, this is in the root of the file system. This is basically kind of your kitchen sink configuration file, it just has all kinds of configuration, a very wide scope to it. Any configuration that doesn’t fit in one of these more specific files, it goes into this file.

And then the magento.env.yaml file, these configurations only apply to the deployment process.

So there’s nothing here that would directly affect your site during its runtime, instead, this just changes the behavior of a deployment of code.

So the .magento.routes file defines routes, and it does so in yaml file format, basically you’ll identify the incoming route that you want to dictate the behavior of, this is an example of the default route that you’ll find on a project, which basically just says, takes that incoming URL and startup Magento, that’s what that syntax you’re seeing there is not necessarily intuitive, but that will start up Magento, if you have that in your configuration file. So every project comes with this in the configuration file, and that’s, that handles a lot of scenarios. That default variable that you’re seeing there is it just allows this file to work in different environments, each of the environments you create from production to staging to all of your temporary integration environments they’re going to have a machine-generated URL automatically created for them.

And so that’s what’s going to substitute for that default variable and that way, this same file, which is committed to your repository can be effective in multiple environments instead of having to hard code every single URL from every single environment, basically, long story short.

So you also do redirects, can do redirects, in this file, so redirects would be of this form, the first thing you’re seeing there is that the HTTP, if you get a non-secure protocol request, you can redirect that to HTTPS using that style of syntax that redirect down here in the second rule, you’ve got a star, and that is a wild card, as you’re probably familiar with the asterisk or the star usually being used, so that would target all sub domains of a particular domain. If you’re using multi-store then you have to often get into routing for sub domains.

And here’s an example at the bottom of more of a hard-coded URL, if you do need to result it adjust rules for a specific environment, you can do that, as well.

You can do advanced redirects either by that we mean regular expressions, or rules that would apply to a lot of different URLs, often this is necessarily with a replatforming to have these kinds of rules that might match a hundred different URLs.

There’s also the ability to configure routes in your cloud UI.

And also using a Magento cloud CLI, which I don’t believe we’re covering in this short class, but is covered in-depth in the full class.

So moving on to the services.yaml file.

Just a caveat here that the services file is not necessarily effective on production staging or production and staging environments and pro plans, you may need to submit a support ticket to do things like changing the elastic search server version or changing the PHP version. Sometimes you need a support ticket to do things like this.

Services, once again, is a yaml formatted file, in which you basically name a service, give it a type, in this case, this is a database service using MYSQL version 10, some people might have caught that MYSQL itself is not up to version 10 yet. This is actually MariaDB. So this is a MariaDB version 10.

Here’s your Redis service defined, here’s the version of it.

So you also are managing a storage space, how much storage space is consumed by your services, so you might’ve noticed this number of disk space jumped from the last slide, that’s just an example of how you would devote more storage to your database.

And here’s an example of adding on Elasticsearch service at version 2.4.

Also it may, you may need separate databases. You can define more than one version of any service, as long as you give it a different name.

Don’t do this just as a, you know, as an important caveat, this, it looks like the intent of the person that did this configuration was, they wanted to rename mysql to mysql2, but that is not how the cloud would interpret this configuration, instead it would destroy service mysql, the original service, and it would create a brand new empty database called mysql2. So this person thought that they were renaming their service but instead they deleted all of their database data, which would be bad.

Okay, moving on to magento.app.yaml, this is the big one, a wide scope here. It covers a lot of different things, basically, anything that’s not covered in a more specific file comes into this file.

Here’s a few things at the beginning of the file, you define the name of the application, which that’s not often changed, I’ve really never changed that, you’ve got the build flavor composer, that’s whether or not you want to use composer as part of your deployment process, you could stop composer from operating, but it would take a pretty heavy customization to the deployment process to not use composer. So I would leave that as is and use composer. And then you’ve got some runtime extensions. These are actually PHP extensions specifically, so there are a certain number of PHP extensions that Magento requires.

You don’t have to list them all here. Some are included by default without having to explicitly state them in this section, but some of the more optional ones are available to be added in this section.

Next, you’ve got a relationships section, and you do want to add a value in this section for everything in your services.yaml file, so you’ll notice that a database and Redis are given a relationship here, this has to do a lot with just kind of routing within the internal network. So there’s an example of adding that second database, in addition to adding it in services.yaml, you need to add it in this app.yaml file.

Next we’ve got the web section, and this is basically your engine X configuration or Apache, if you’re familiar with that, both are, you know, accomplishing the same job, but basically you’re declaring pub to be the root of Magento and declaring index.php to be kind of the entry point of the application.

Then moving on, we’ve got another opportunity to define storage space here. And this would be the space devoted to all of the writeable sections of the file system, so this doesn’t have to do with your Magento application code, but you know, your logs consume that storage and most notably are media usually on media or your, you know, your product images, or all the other images on your site, or take up the most storage. So that’s usually the determining factor of how much disk space you want to define is how much media do you have, or will the site have over its life.

Moving on from there, you’ve got dependency. So these would be other tools that you want to install in the operating system. So for instance, note JS is a popular tool for compiling front-end assets.

So you can define those types of tools here and have those active in your environment.

After that, we’ve got the hooks section, and this is where you customize the deployment process.

So these are scripts that run during your deployments and you have the opportunity to add your own scripts here so that you can customize that deployment process. We’ll talk more about that later.

Next you’ve got crons, another important one, this is where you define what crons will be running in the environment, the Magento kind of heartbeat cron, sometimes it’s described that is configured by default.

So, but if you have any additional crons, you can define them there. And then last but not least, you’ve got environment variables, you can add any number of environment variables here in this file.

So how would you update your version of PHP that happens in the magento.app.yaml file that we just reviewed, what is the full process for adding Elasticsearch? Well, you would need to modify two files, this, the magento.app.yaml file, you would need a section in the relationships area, and then you would also need to modify the services.yaml file, and put the version and the storage space in that file.

Question three, how would you add additional scripts to the build hook? That would just be in that, the hooks section, where you found by default Magento’s deployment scripts, and then you could also add some of your own.

So then the last configuration file we’ll take a look at is magento.env.yaml, this contains configurations related to the build, the deployment process. There’s three different phases to the deployment process, so you’re basically just modifying the behavior of the deployment process.

This file is used on all environments, and it is formatted initially into stages, you’ve got global, which affects all stages of deployment, but then more specifically, you’ve got a build deploy and a post deploy stage, so you can restrict your configurations to any or all of the stages. And then also there’s some ability to configure logging during the deployment process.

So here is an example of changing logging behavior during a deployment, you’re setting a minimum logging level, and then you’re saying you’d like a notification of deployment logs to go to both email and slack.

So here we’ve got, just kind of recapping those sections of the env.yaml, you can put PHP constants, inject PHP constants into certain PHP classes, has another ability that’s comes under customizing the behavior of the deployment process. -