Всё, что нужно знать о Magento & Cloud

Magento Cloud

Magento Cloud — это платформа как сервис, которая включает себя два плана: starter и pro. 

Честно говоря, starter ни разу не встречал нигде, обычно все используют pro. Разница между ними заключается в наличии или в отсутствии кластера. Из названия становится понятно, что pro содержит кластер из трёх нод, а стартер — нет. 

На диаграмме ниже можно посмотреть, из чего он состоит. 

Это три ноды в Amazon Environment и Fastly, как кеширующий Content Delivery Network. По сути, это Varnish распределенный.

• CDN, WAF, IO. Это Fastly, который в себя также включает Web Application Firewall — довольно удобная штука, интеллектуальный и умеет блочить каких-нибудь назойливых ботов. А image optimization может на лету оптимизировать картинки до такого вида, который нравится Google PageSpeed. 
• Performance Tools. Это New Relic — очень удобная тулза для мониторинга и дебаггинга. Мониторит Magento приложения, то есть, PHP и также включает мониторинг инстансов. Показывает такие метрики, как CPU, память, диск и другие. Также включен сюда BlackFire, который помогает более подробно рассмотреть, что у нас происходит с Magento в случае боттлнеков или проблем с перформансом. 
• Magento Commerce (Enterprise). Собственно сама Magento с enterprise-поддержкой, которая по опциональности включает BI и B2B extensions.
• Platform as a Service. В данном случае предоставляют свой GIT, а через Composer подтягиваются все вендоры. 
• Cloud infrastructure. Сама инфраструктура, которая находится на Amazon. 

Magento Cloud Applications & Configurations

Далее рассмотрим то, что у нас в кластере, в самих нодах.

В ноде работают приложения, такие как PHP, MySQL, MariaDB, Galera Cluster, Redis, RabbitMQ, Elasticsearch и Nginx.

В Magento Cloud есть 5 файлов, которые позволяют управлять ее поведением:

• .magentо.app.yaml;
• .magento.env.yaml;
• .magento-vars.php;
• .magento/routes.yaml;
• .magento/services.yaml.

Далее мы их подробнее рассмотрим и увидим, что можно в них настраивать. 

.magentо.app.yaml

Я считаю, что это наиболее важный и емкий файл, где можно что-либо настроить.

• extensions — здесь мы управляем extensions для PHP. То есть, если нам нужно для нашей Magento какие-то дополнительные вещи, как Sodium или что-то в этом роде, мы добавляем это сюда. 
• mounts — секция, которая описывает папки, которые могут быть перезаписываемые. Естественно, это медиа, потому что мы добавляем или загружаем картинки, она должна быть записываемой. «etc» здесь — конфигурационный файл доступный для записи, когда мы что-то настраиваем в env.php или config.php. «var» — логи и ещё какие-то дополнительные файлы. Опционально некоторые делают на время разработки доступной для записи папку static. Это позволяет нам деплоить статику без запуска полного деплоя. Все остальное только read only. Ничего больше нельзя менять, можно менять только через репозиторий и деплой.
• hooks — это по сути этапы деплоя. Первый этап — билд, то есть здесь происходит composer install, идет дальше di:compile, static content deploy. Но static content deploy здесь может идти, если все правильно настроено и сконфигурировано в config.php — это идеальное состояние. Если у нас этого нет, то у нас билд статики происходит в деплой фазе с даунтаймом. Дальше идет собственно деплой, то есть, собранный артефакт заливается на инстансы. Дальше, если у нас настроено не оптимально, и статика не собрана, здесь происходит сбор статики, который занимает какое-то время. После этого идет setup:upgrade, то есть база обновляется. Дальше идет post_deploy hook — здесь можно описать какие-нибудь дополнительные скрипты по warmup. Например, мы хотим, чтобы какие-то определенные страницы, на этом этапе «прогрелись».
• crons — следующая секция, где мы можем управлять крон-задачами. По дефолту здесь стоит дефолтный Magento крон, но также мы можем добавлять сюда свои какие-то скрипты или PHP команды.

.magento/services.yaml

В этом файле мы можем управлять версиями приложений. Например, тут написано MySQL, но по сути это MariaDB версии 10.4, либо можем другие версии ставить. 

Диск — это размер дисковой памяти, сколько мы выделяем для базы. Версия Redis, Elasticsearch с размером диска и RabbitMQ.

Нужно понимать, что этот файл работает только для стартера и для integration environment. В Magento Cloud Pro с кластерной архитектурой, чтобы поменять эти вещи — изменить размер диска или версию — нужно писать в саппорт.

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

Здесь хочу ещё показать полезные команды.

Команда — vendor/bin/ece-tools wizard:ideal-state — позволяет нам определить, насколько у нас идеально настроен процесс деплоя. В данном случае это: включена ли минификация или нет, где у нас происходит билд статики и другие параметры. 

Вернёмся к тому важному файлу config.php и настройками в нём. Это очень важно, если мы хотим настроить практически zero downtime deployment. 

Получается, что в этом случае мы можем собирать полностью Magento — от composer до static-content:deploy — без подключения к базе и без влияния на environment. Для этого нужно, чтобы нужные настройки темы были в этом файле. 

Мы должны его сдампить — для этого есть определенная команда —  vendor/bin/ece-tools config:dump. Он нам позволяет сдампить эти настройки в config.php, который мы после этого должны скопировать к себе и залить в Git репозиторий. Тогда у нас это всё будет происходить в билд фазе без влияния на продакшн.

Ещё одна полезная команда — vendor/bin/ece-tools db-dump, то есть он делает дамп базы, которую можно будет потом скачать из темповой директории при помощи SCP. 

Это, что касается Magento Cloud CLI. 

Тоже самое для config.php мы можем записать следующей командой — bin/magento app:config:dump scopes themes. Эта команда нам позволит сдампить конфигурации темы и скоуп в config.php и после этого собирать статику без подключения к базе. Ну и соответственно закоммитить его. 

Разница в Magento Cloud и просто Magento по сути в ece-tool, который ставится через composer. 

Это vendor, в котором очень много происходит модификаций, то есть он накладывает свои патчи для адаптации под Magento Cloud Environment, накладывает security tool, security патчи и другие вещи. Его нужно держать постоянно обновленным, что Magento и так всегда рекомендует делать.

Magento Cloud Deployment Approach

Здесь ещё хочу поделиться наработкой по deployment. Это кусочек скрипта из BitBucket. 

У Magento Cloud есть свой репозиторий, но работать с ним крайне неудобно, потому что там нет своих дашбордов, чтобы видеть свои pull requests и другие вещи. 

В данном случае у нас разработка кода идет в BitBucket и GitLab. Потом при помощи вот этого скрипта, который по сути всего лишь добавляет ремоут репозиторий Magento Cloud, он просто пушит в него определенную ветку. 

Ветка здесь основная production, не мастер. 

Production, staging и integration — это три дефолтных environments. 

Если мы пушим в эти ветки код, то у нас автоматически начнется deployment в этих environments. Это очень удобно и не требует никакой ручной работы.

Magento Support

В основном, все вопросы решаются через Magento Support. 

Всё работает через тикеты, есть много документации, обучения. 

На этом закончим с Magento Cloud.

AWS Cloud & Magento

Если мы хотим больше какого-либо управления, драйва и острых ощущений, мы настраиваем свой кластер. 

В нем мы разделяем: 

• Admin, то есть Magento Backend уровень. У нас здесь есть несколько инстансов с отдельно работающим backend;
• Public. Здесь у нас autoscaling group, в которой работают инстансы для frontend, то есть для клиентов. 

Они работают независимо, маршрутизация админ/не админ происходит на уровне Load Balancer. Если у нас идет admin путь в URL, то мы направляем на админ инстанс. 

Также здесь есть Elastic File System — это, грубо говоря, Network File System (сетевая файловая система). Здесь у нас есть медиа общая для всех инстансов, логи или другие файлы, которые должны быть persistent и доступны со всех инстансов.

Так же есть возможность использовать Master-Slave replication,  правда, доступно это в  enterprise-решении. 

В Magento community  одна база. В основном, я настраиваю Aurora. 

Также есть Redis для сессий и Redis для Magentо кэша. 

Full page cache у нас вынесен в Varnish, для чего у нас настроены Varnish инстанс/инстансы, которые мы чистим из Magento, если нам нужно почистить кэш.

Artifact

После того, как мы всё настроили, и у нас много инстансов в работе, нам надо как-то доставлять код на все эти инстансы, поэтому и возникает сложная задача. 

Вручную править десятки инстансов будет тяжело. У амазона свой код деплой, вот как раз про него я и хочу рассказать. 

Мой подход — практически с zero downtime. Downtime возможен на менее, чем минуту, если у нас происходят изменения в базе при setup:upgrade. Если у нас нет изменений в базе, то он происходит вообще незаметно. 

Что мы для этого делаем? 

На каком-то CI — это может быть отдельный инстанс с Jenkins, Bitbucket-pipeline или где угодно ещё — отдельно мы собираем артефакт:

• composer install
• bin/magento setup:di:compile
• bin/magento setup:static-content:deploy -j 4
• tar cf prd.tar ./* --exclude=».git» --exclude="prd.tar» --exclude=»./app/etc/env.php»
• aws s3 cp prd.tar s3://prod-artifact/ --quiet

Повторюсь, что это всё доступно только в том случае, если мы настроили config.php. Как я указал ранее, очень важная часть деплоя.

В нем описывается минифицируемый или нет, какие мы темы собираем, какие языки в темах, может быть, мы bundling решили включить — это всё должно быть в этом файле. Мы можем его сдампить командой, которую я раньше показал.

Дальше мы собираем tar — мы не сжимаем, а просто собираем весь этот код в один файл. Это нужно для ускорения. То есть, у нас сетевые задержки минимальные, и нам не обязательно сжимать — нам проще засунуть это в один файл и отправить на S3 bucket на Amazon. 

С этого S3 bucket мы запускаем Amazon CodеDeploy — это, по сути, все команды в CI tool. У нас две deploy конфигурации для frontend, то есть public для клиентов и вторая конфигурация для admin. Пример команд ниже

• aws deploy create-deployment --output text --region=us-west-1 --application-name prod --deployment-group-name prod-admin --description «PRD Deployment» --s3-location bucket=prod-artifact,bundleType=tar,key=prd.tar
• aws deploy create-deployment --output text --region=us-west-1 --application-name prod --deployment-group-name prod-public --description «PRD Deployment» --s3-location bucket=prod-artifact,bundleType=tar,key=prd.tar

Дальше покажу скрипты деплоя.

Структура папок на инстансах, которые у нас поднимаются с образа, который предварительно настроен, то есть, в нем уже установлен PHP-FPM, Nginx, возможно, New Relic или ещё что-то, что нам нужно.

Из «Golden Image» мы подымаем новые инстансы, в котором у нас следующая структура:

Current  это не папка, а symlink, который ссылается на последний релиз в папке releases:

В папке релиз каждый раз во время деплоя создается новая папка, в которой у нас новый код, и если все деплой команды прошли успешно мы переключаем symlink на новую папку. 

Shared — это подмонтированная файловая система EFS. Здесь медиа и и другие папки на которые мы делаем symlinks в Magento, наприер  pub/media, var/log, var/report.

Temp — это временная папка, и она нужна для CodeDeploy, куда он стягивает и распаковывает артефакт, который мы создали в CI tool. 

app.spec.yml

Это файл, который управляет запуском СodeDeploy.

Он довольно простой, в yml-формате. У него есть source (это временная папка, куда он будет распаковывать). После этого он выполняет скрипт, в котором и происходит вся магия:

Для того, чтобы сделать каждую деплой папку уникальной, чтобы не было у нас пересечения во временах, делается с date до секунды. 

Здесь будет просто набор цифр: месяц, день, час, минута, секунда, то есть она скорее всего никогда не будет одинаковой:

Дальше release path, он у нас находится в папке релизы. Указывает название директория, который мы создали:

Для ускорения мы производим move, то есть мы перемещаем содержимое папки temp в релиз-директорию:

Далее в зависимости от того, какая deployment группа — admin или public — мы запускаем различные команды. Например, cron у нас работает только в admin группе.

Также в admin группе мы выполняем setup:upgrade, потому что public группа может ещё запускаться не только при обновлении кода, но и когда у нас сработал autoscaling. 

Естественно, что при autoscaling, когда создаются новые инстансы, и инстансам тяжело, нам не нужно запускать setup:upgrade и не нужно чистить кэш. Поэтому здесь это разделено. 

Копируем файлик env.php, который уже настроенный на подключение к базе, Redis и Elasticsearch:

Следующий этап — мы просто удаляем папку media, которая создалась при composer install и заменяем ее на symlink с расшаренной папки, которая у нас монтируется на каждый инстанс:

Если все прошло без ошибок, удаляем ссылку curent и создаем ее заново на папку с новым релизом.

После этого, для того, чтобы веб-сервер и php подхватил эти изменениям, мы перезапускаем эти два сервиса. 

В конце, чтобы у нас не накапливалась много папок со старым кодом, мы чистим предыдущие релизы.