Adobe Commerce Cloud architecture under the hood
Adobe Commerce Cloud/Magento Cloud is a platform as a service (PaaS) Magento 2 hosting.
Magento Cloud infrastructure. The infrastructure itself, which is on Amazon.
Next, let’s look at what we have in the cluster, in the nodes themselves.
Each node runs applications of all required software such as PHP, MySQL, MariaDB, Galera Cluster, Redis, RabbitMQ, Elasticsearch, and Nginx. This approach is really bad. We can’t consider calling this solution cloud.It is more like a single server installation.
The architecture diagram looks like this ->
You can use this script to install Magento on a single server:
Let's take a look at what this beast has under the hood!
Magento Cloud has 5 files that allow you to control its behavior:
.magento.app.yaml;
.magento.env.yaml;.magento-vars.php;.magento / routes.yaml;.magento / services.yaml.
Next, we will take a closer look at them and see what you can customize in them.
# Enable extensions required by Magento 2runtime:extensions:- redis- xsl- blackfire- newrelic- sodium…# The mounts that will be performed when the package is deployed.mounts:“Var”: “shared: files / var”“App / etc”: “shared: files / etc”“Pub / media”: “shared: files / media”“Pub / static”: “shared: files / static”hooks:# We run build hooks before your application has been packaged.build: |set -ephp ./vendor/bin/ece-tools build: generatephp ./vendor/bin/ece-tools build: transfer# We run deploy hook after your application has been deployed and started.deploy: |php ./vendor/bin/ece-tools deploy# We run post deploy hook to clean and warm the cache. Available with ECE-Tools 2002.0.10.post_deploy: |php ./vendor/bin/ece-tools post-deploy# Default Magento 2 cron jobscrons:cronrun:spec: “* * * * *”cmd: “php bin / magento cron: run”
.magento.app.yaml
This is the most important and capacious file where you can customize anything.
extensions — This is where we manage PHP extensions. That is, if we need some additional things for our Magento, like lib Sodium, apcu,phpredis or something like that, we add it here.
mounts is a section that describes folders that can be rewritable. Naturally, this is media, because we add or upload pictures, it must be recordable. “Etc” here is a config file available for writing when we configure something in env.php or config.php. “Var” — logs and some other additional files. Optionally, some make the static folder writable during development. This allows us to deploy statics without running a full deployment. Everything else is read only. Nothing else can be changed, you can change only through the repository and deployment.
hooks are essentially deployment stages. The first stage is build, that is, composer install takes place here, di: compile, static content deploy goes further. But static content deploy can go here if everything is properly configured and configured in config.php — this is the perfect state. If we don’t have this, then our statics build takes place in the deployment phase with downtime. Next comes the actual deployment, that is, the collected artifact is uploaded to the instances. Further, if our settings are not optimal, and the statics are not collected, the collection of statics takes place here, which takes some time. After that comes setup: upgrade, that is, the database is updated. Next comes the post_deploy hook — here you can describe any additional scripts for warmup. For example, we want some specific pages to “warm up” at this stage.
cron is the next section where we can manage crone tasks. By default, here is the default Magento kronor, but we can also add our own scripts or PHP commands here.
.magento / services.yaml
# The services of the project.## Each service listed will be deployed to power your project.mysql:type: mysql: 10.4disk: 4096redis:type: redis: 5.0elasticsearch:type: elasticsearch: 6.5disk: 1024rabbitmq:type: rabbitmq: 3.7disk: 1024
In this file, we can manage versions of applications. For example, MySQL is written here, but in fact it is MariaDB version 10.4, or we can install other versions.
Disk is the amount of disk space we allocate for the base. Redis version, Elasticsearch with disk size and RabbitMQ.
You need to understand that this file only works for the starter and for the integration environment. In Magento Cloud Pro with a cluster architecture, to change these things — change the disk size or version — you need to write to the support.
Magento Cloud CLI
vendor / bin / ece-tools
vendor / bin / ece-tools wizard: ideal-state “Verifies ideal state of configuration”
vendor / bin / ece-tools config: dump “Dump configuration for static content deployment”
vendor / bin / ece-tools db-dump
Preparing config.php for deployment without database connection
bin / magento app: config: dump scopes themes
Commit config.php
Here I also want to show you some useful commands.
The command — vendor / bin / ece-tools wizard: ideal-state — allows us to determine how ideally our deployment process is. In this case, it is: whether minification is enabled or not, where we have statics build and other parameters.
Let’s go back to that important config.php file and the settings in it. This is very important if we want to set up almost zero downtime deployment.
It turns out that in this case we can build completely Magento — from composer to static-content: deploy — without connecting to the base and without affecting the environment. To do this, you need to have the desired theme settings in this file.
We have to dump it — there is a specific command for this — vendor / bin / ece-tools config: dump. It allows us to dump these settings in config.php, which we then have to copy to ourselves and upload to the Git repository. Then all this will happen in the build phase without affecting production.
Another useful command is vendor / bin / ece-tools db-dump, that is, it makes a dump of the database, which can then be downloaded from the temp directory using SCP.
That’s as far as Magento Cloud CLI is concerned.
We can write the same for config.php with the following command — bin / magento app: config: dump scopes themes. This command will allow us to dump the theme and scope configurations in config.php and then collect statics without connecting to the database. Well, commit it accordingly.
The difference in Magento Cloud and just Magento is essentially in the ece-tool, which is installed via composer.
This is a vendor in which there are a lot of modifications, that is, it applies its own patches for adaptation to Magento Cloud Environment, applies security tool, security patches and other things. It needs to be kept constantly updated, which Magento always recommends doing.
We can’t recommend anybody to use Magento Cloud on production. It doesn’t have good performance because of the lousy architecture, lack of auto-scaling, and has limited resources. Magento Cloud is suitable for micro-projects and for development (how not to make cloud) and education purposes only!
