Привет, меня зовут Алексей Коростелёв. Я работаю в компании Magecom как DevOps Engineer.
Моя статья основана на докладе, с которым я выступал на Magento Meetup Online, и будет она о вариантах хостинга Magento, у которых есть в названии похожее слово Cloud.
Привет, меня зовут Алексей Коростелёв. Я работаю в компании Magecom как DevOps Engineer.
Моя статья основана на докладе, с которым я выступал на Magento Meetup Online, и будет она о вариантах хостинга Magento, у которых есть в названии похожее слово Cloud.
Magento Cloud — это платформа как сервис, которая включает себя два плана: starter и pro.
Честно говоря, starter ни разу не встречал нигде, обычно все используют pro. Разница между ними заключается в наличии или в отсутствии кластера. Из названия становится понятно, что pro содержит кластер из трёх нод, а стартер — нет.
На диаграмме ниже можно посмотреть, из чего он состоит.
Это три ноды в Amazon Environment и Fastly, как кеширующий Content Delivery Network. По сути, это Varnish распределенный.
Далее рассмотрим то, что у нас в кластере, в самих нодах.
В ноде работают приложения, такие как PHP, MySQL, MariaDB, Galera Cluster, Redis, RabbitMQ, Elasticsearch и Nginx.
В Magento Cloud есть 5 файлов, которые позволяют управлять ее поведением:
Далее мы их подробнее рассмотрим и увидим, что можно в них настраивать.
# Enable extensions required by Magento 2
runtime:
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 -e
php ./vendor/bin/ece-tools build:generate
php ./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 jobs
crons:
cronrun:
spec: «* * * * *»
cmd: «php bin/magento cron:run»
Я считаю, что это наиболее важный и емкий файл, где можно что-либо настроить.
# The services of the project.
#
# Each service listed will be deployed to power your project.
mysql:
type: mysql:10.4
disk: 4096
redis:
type: redis:5.0
elasticsearch:
type: elasticsearch:6.5
disk: 1024
rabbitmq:
type: rabbitmq:3.7
disk: 1024
В этом файле мы можем управлять версиями приложений. Например, тут написано MySQL, но по сути это MariaDB версии 10.4, либо можем другие версии ставить.
Диск — это размер дисковой памяти, сколько мы выделяем для базы. Версия Redis, Elasticsearch с размером диска и RabbitMQ.
Нужно понимать, что этот файл работает только для стартера и для integration environment. В Magento Cloud Pro с кластерной архитектурой, чтобы поменять эти вещи — изменить размер диска или версию — нужно писать в саппорт.
Здесь хочу ещё показать полезные команды.
Команда — 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 и так всегда рекомендует делать.
case «${BITBUCKET_BRANCH}» in
«staging»)
echo «Setting Stage details»
REMOTE_BRANCH=${REMOTE_BRANCH_STAGE}
REMOTE_REPO=${REMOTE_REPO_STAGE}
INSTANCE="Stage»
;
«master»)
echo «Setting Prod details»
REMOTE_BRANCH=${REMOTE_BRANCH_PROD}
REMOTE_REPO=${REMOTE_REPO_PROD}
INSTANCE="Prod»
;
esac
git remote add ${REMOTE_REPO} ${REMOTE_GIT_URL}
git push -v ${REMOTE_REPO} HEAD:${REMOTE_BRANCH} -f &
sleep 10
exit 0
Здесь ещё хочу поделиться наработкой по deployment. Это кусочек скрипта из BitBucket.
У Magento Cloud есть свой репозиторий, но работать с ним крайне неудобно, потому что там нет своих дашбордов, чтобы видеть свои pull requests и другие вещи.
В данном случае у нас разработка кода идет в BitBucket и GitLab. Потом при помощи вот этого скрипта, который по сути всего лишь добавляет ремоут репозиторий Magento Cloud, он просто пушит в него определенную ветку.
Ветка здесь основная production, не мастер.
Production, staging и integration — это три дефолтных environments.
Если мы пушим в эти ветки код, то у нас автоматически начнется deployment в этих environments. Это очень удобно и не требует никакой ручной работы.
В основном, все вопросы решаются через Magento Support.
Всё работает через тикеты, есть много документации, обучения.
На этом закончим с Magento Cloud.
Если мы хотим больше какого-либо управления, драйва и острых ощущений, мы настраиваем свой кластер.
В нем мы разделяем:
Они работают независимо, маршрутизация админ/не админ происходит на уровне 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, если нам нужно почистить кэш.
После того, как мы всё настроили, и у нас много инстансов в работе, нам надо как-то доставлять код на все эти инстансы, поэтому и возникает сложная задача.
Вручную править десятки инстансов будет тяжело. У амазона свой код деплой, вот как раз про него я и хочу рассказать.
Мой подход — практически с zero downtime. Downtime возможен на менее, чем минуту, если у нас происходят изменения в базе при setup:upgrade. Если у нас нет изменений в базе, то он происходит вообще незаметно.
Что мы для этого делаем?
На каком-то CI — это может быть отдельный инстанс с Jenkins, Bitbucket-pipeline или где угодно ещё — отдельно мы собираем артефакт:
Повторюсь, что это всё доступно только в том случае, если мы настроили config.php. Как я указал ранее, очень важная часть деплоя.
В нем описывается минифицируемый или нет, какие мы темы собираем, какие языки в темах, может быть, мы bundling решили включить — это всё должно быть в этом файле. Мы можем его сдампить командой, которую я раньше показал.
Дальше мы собираем tar — мы не сжимаем, а просто собираем весь этот код в один файл. Это нужно для ускорения. То есть, у нас сетевые задержки минимальные, и нам не обязательно сжимать — нам проще засунуть это в один файл и отправить на S3 bucket на Amazon.
С этого S3 bucket мы запускаем Amazon CodеDeploy — это, по сути, все команды в CI tool. У нас две deploy конфигурации для frontend, то есть public для клиентов и вторая конфигурация для admin. Пример команд ниже
Дальше покажу скрипты деплоя.
Структура папок на инстансах, которые у нас поднимаются с образа, который предварительно настроен, то есть, в нем уже установлен PHP-FPM, Nginx, возможно, New Relic или ещё что-то, что нам нужно.
Из «Golden Image» мы подымаем новые инстансы, в котором у нас следующая структура:
/var/www/
----- current ## symlink in nginx conf «root /var/www/current/pub;»
Current это не папка, а symlink, который ссылается на последний релиз в папке releases:
----- releases ## folder with different code versions
В папке релиз каждый раз во время деплоя создается новая папка, в которой у нас новый код, и если все деплой команды прошли успешно мы переключаем symlink на новую папку.
----- shared ## mountable resource like EFS with «media»
Shared — это подмонтированная файловая система EFS. Здесь медиа и и другие папки на которые мы делаем symlinks в Magento, наприер pub/media, var/log, var/report.
----- temp ## exists only when «AWS CodeDeploy» works
Temp — это временная папка, и она нужна для CodeDeploy, куда он стягивает и распаковывает артефакт, который мы создали в CI tool.
version: 0.0
os: linux
files:
— source: /
destination: /var/www/temp
hooks:
AfterInstall:
— location: deploy/scripts/prepare_magento2
timeout: 1500
runas: root
Это файл, который управляет запуском СodeDeploy.
Он довольно простой, в yml-формате. У него есть source (это временная папка, куда он будет распаковывать). После этого он выполняет скрипт, в котором и происходит вся магия:
#!/bin/bash
set -e
RELEASE_NAME="`date +%Y%m%d%H%M%S`»
RELEASE_PATH="/var/www/releases/$RELEASE_NAME»
mv /var/www/temp $RELEASE_PATH
chown -R apache. $RELEASE_PATH
if [«$DEPLOYMENT_GROUP_NAME» == «prod-admin»]
then
aws s3 cp s3://config-files/prod_env.php $RELEASE_PATH/app/etc/env.php
sudo -u apache php $RELEASE_PATH/bin/magento app:config:import
sudo -u apache php $RELEASE_PATH/bin/magento setup:upgrade --keep-generated
sed -i 's/#//g' /var/spool/cron/apache
fi
if [«$DEPLOYMENT_GROUP_NAME» == «prod-public»]
then
aws s3 cp s3://config-files/prod_env.php $RELEASE_PATH/app/etc/env.php
fi
cd $RELEASE_PATH
# File and Directory Permissions
rm -rf $RELEASE_PATH/pub/media && ln -s /var/www/shared/media $RELEASE_PATH/pub/media
#Moving cache flush to Job servers alone
if [«$DEPLOYMENT_GROUP_NAME» == «prod-admin»]
then
sudo -u apache php $RELEASE_PATH/bin/magento cache:flush
fi
rm -rf /var/www/html && ln -s $RELEASE_PATH /var/www/html
service nginx restart
service php-fpm restart
cd /var/www/releases && ls -t | tail -n+2 | xargs rm -rf
Для того, чтобы сделать каждую деплой папку уникальной, чтобы не было у нас пересечения во временах, делается с date до секунды.
Здесь будет просто набор цифр: месяц, день, час, минута, секунда, то есть она скорее всего никогда не будет одинаковой:
RELEASE_NAME="`date +%Y%m%d%H%M%S`»
Дальше release path, он у нас находится в папке релизы. Указывает название директория, который мы создали:
RELEASE_PATH="/var/www/releases/$RELEASE_NAME»
Для ускорения мы производим move, то есть мы перемещаем содержимое папки temp в релиз-директорию:
mv /var/www/temp $RELEASE_PATH
Далее в зависимости от того, какая deployment группа — admin или public — мы запускаем различные команды. Например, cron у нас работает только в admin группе.
Также в admin группе мы выполняем setup:upgrade, потому что public группа может ещё запускаться не только при обновлении кода, но и когда у нас сработал autoscaling.
Естественно, что при autoscaling, когда создаются новые инстансы, и инстансам тяжело, нам не нужно запускать setup:upgrade и не нужно чистить кэш. Поэтому здесь это разделено.
Копируем файлик env.php, который уже настроенный на подключение к базе, Redis и Elasticsearch:
aws s3 cp s3://config-files/prod_env.php $RELEASE_PATH/app/etc/env.php
Следующий этап — мы просто удаляем папку media, которая создалась при composer install и заменяем ее на symlink с расшаренной папки, которая у нас монтируется на каждый инстанс:
rm -rf $RELEASE_PATH/pub/media && ln -s /var/www/shared/media $RELEASE_PATH/pub/media
Если все прошло без ошибок, удаляем ссылку curent и создаем ее заново на папку с новым релизом.
После этого, для того, чтобы веб-сервер и php подхватил эти изменениям, мы перезапускаем эти два сервиса.
В конце, чтобы у нас не накапливалась много папок со старым кодом, мы чистим предыдущие релизы.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.