Як розгорнути додаток Symfony
Дата оновлення перекладу 2023-06-14
Як розгорнути додаток Symfony
Розгортання додатку Symfony може бути складним та різноманітним завданням, в залежності від установки та вимог вашого додатку. Ця стаття не є покроковим керівництвом, вона являє собою загальний перелік найбільш розповсюджених вимог та ідей для розгортання.
Основи розгортання Symfony
Типові кроки при розгортанні додатку Symfony включають в себе:
- Завантажте ваш код на сервер виробництва;
- Встановіть ваші залежності постачальника (зазвичай робиться через Composer і може бути виконано до завантаження);
- Запуск переміщень бази даних або схожі завдання по оновленню змінених структур даних;
- Очищення (і, за бажанням, розігрів) вашого кешу.
Розгортання може також включати в себе наступні задачі:
- Тегування конкретної версії вашого коду в якості релізу в сховищі вашого початкового коду;
- Створення тимчасової ділянки підготовки виробництва для побудови вашої оновленої установки "офлайн";
- Запуск будь-яких доступних тестів, щоб переконатися в стабільності коду та/або серверу;
- Видалення будь-яких непотрібних файлів з каталогу
public/
для підтримання чистоти вашого середовища виробництва; - Очищення зовнішніх систем кешування (як Memcached або Redis).
Як розгорнути додаток Symfony
Існує декілька шляхів розгортання вашого додатку Symfony. Почніть з декількох базових стратегій розгортання, а потім нарощуйте сили.
Базове перенесення файлу
Найбазовішим способом розгортання додатку є копіювання файлів вручну за допомогою FTP/SCP (або схожого методу). Цей спосіб має свої недоліки, так як вам буде не вистачати контролю над системою по мірі прогресу покращень. Цей метод також потребує деяких ручних дій після перенесення файлів (див. Розповсюджені задачі розгортання).
Використання системи управління початковим кодом
Якщо ви використовуєте системи управління початковим кодом (наприклад, Git або SVN), ви можете спростити собі життя, якщо ваша жива інсталяція також буде копією вашого сховища. Коли ви будете готові до покращення (апгрейде), все, що вам необхідно буде зробити - це викликати останні оновлення з вашої системи контролю початкового коду. При використанні Git розповсюдженим підходом є створення тегу для кожного релізу та перевірка відповідного тегу при розгортанні (див. Тегування Git).
Це полегшує оновлення ваших файлів, але вам все ще необхідно турбуватися про те, щоб виконувати інші кроки вручну (див. Розповсюджені задачі розгортання).
Використання платформ в якості сервісу
Використання платформи у якості сервісу (PaaS) може бути чудовим способом розгорнути ваш застосунок Symfony швидко та легко. Існує безліч PaaS, but we recommend Platform.sh as it provides a dedicated Symfony integration and helps fund the Symfony development.
Використання скриптів побудови та інших інструментів
Існують також інструменти, які полегшують муки розгортання. Деякі з них були спеціально підігнані під вимоги Symfony.
- Deployer
- Ще одний рідний перезапис PHP Capistrano, з деякими готовими рецептами для Symfony.
- Ansistrano
- Роль Ansible, яка дозволяє вам конфігурувати потужне розгортання через YAML-файли.
- Magallanes
- Цей інструмент розгортання, схожий на Capistrano, вбудобваний в PHP і може бути легшим для PHP-розробників в контексті його розширення під їх потреби.
- Fabric
- Ця бібліотека, заснована на Python, надає базовий набір операцій для виконання локальних або віддалених shell-команд та завантаження/вивантаження файлів.
- Capistrano з плагіном Symfony
- Capistrano - це віддалена автоматизація сервера та інструмент розгортання, написаний на Ruby. Плагін Symfony - це плагін для полегшення задач, пов'язаних з Symfony, заснований на Capifony (який працює лише з Capistrano 2).
Розповсюджені задачі розгортання
До і після розгортання вашого початкового коду, існує перелік найбільш розповсюджених речей, які вам знадобиться зробити:
A) Перевірка вимог
Існують деякі технічні вимоги для запуску додатків Symfony . На вашій машині розробки, рекомендованим способом перевірки цих вимог є Symfony CLI. Однак, на вашому сервері виробництва, ви можете вирішити на встановлювати цей інструмент Symfony CLI. В таких випадках, встановіть цей інший пакет у вашому додатку:
1
$ composer require symfony/requirements-checker
Потім, переконайтеся, що перевірник додано у ваші скрипти Composer:
1 2 3 4 5 6 7 8 9 10 11 12
{
"...": "...",
"scripts": {
"auto-scripts": {
"vendor/bin/requirements-checker": "php-script",
"...": "..."
},
"...": "..."
}
}
B) Конфігурація ваших змінних середовища
Більшість додатків Symfony зчитують конфігурацію зі змінних середовища. При локальінй
розробці ви зазвичай зберігаєте її в .env
та .env.local
(для локальних
перевизначень). Але при виробництві у вас є два варіанти:
- Створити "справжні" змінні середовища. Те, як ви встановлюєте змінні середовища, залежить від ваших налаштувань: вони можуть бути встановлені у командній строці, у вашій конфігурації Nginx або через інші методи, надані вашими сервісами хостингу;
- Або створити файл
.env.local
як вашу локальну розробку.
У жодного варіанту немає суттєвих переваг: використовуйте той, який найбільш природнй у вашому середовищі хостингу.
Tip
Ви можете не хотіти, щоб ваш застосунок обробляв файли .env.*
за кожним заптом.
Ви можете згенерувати оптимізований .env.local.php
, який перевизначає всі інші
файли конфігурації:
1
$ composer dump-env prod
Згенерований файл буде містити всю конфігурацію, що зберігається в .env
. Якщо ви
хочете покладатися лише на змінні середовища, згенеруйте його без значень, використовуючи:
1
$ composer dump-env prod --empty
Якщо composer
не встановлено на вашому сервері, ви можете згенерувати цей оптимізований
файл за допомогою команди, наданої самою Symfony, яку ви маєте зареєструвати у вашому додатку
перед використанням:
1 2 3
# config/services.yaml
services:
Symfony\Component\Dotenv\Command\DotenvDumpCommand: ~
1
$ APP_ENV=prod APP_DEBUG=0 php bin/console dotenv:dump
C) Установка/оновлення ваших постачальників
Ваші постачальники можуть бути оновлені до перенесення вашого початкового
коду (тобто ви оновлюєте каталог vendor/
, потім переносите його з вашим
початковим кодом) або ж після, вже на сервері. В будь-якому випадку, просто
оновіть ваших постачальників так, як завжди:
1
$ composer install --no-dev --optimize-autoloader
Tip
Прапорець --optimize-autoloader
значно покращує продуктивність автозавантажувача
Composer, шляхом побудови "карти класів". Прапорець --no-dev
переконується в тому,
що пакети розробки не встановлені в середовищі виробництва.
Caution
Якщо ви отримаєте помилку "клас не знайдено" під час цього кроку, вам може
знадобитися запустити export SYMFONY_ENV=prod
(або export APP_ENV=prod
,
якщо ви використовуєте Symfony Flex) перед тим, як використати
цю команду, щоб скрипти post-install-cmd
запускалися в середовищі prod
.
D) Очищення вашого кешу Symfony
Переконайтеся в тому, що ви очистили та розігріли ваш кеш Symfony:
1
$ php bin/console cache:clear --env=prod --no-debug
E) Інші речі!
Існує ще безліч інших речей, які вам може знадобитися зробити, в залежності від вашої установки:
- Запуск будь-яких переміщень бази даних
- Очищення вашого APC-кешу
- Додавання/змінення робіт CRON
- Побудова та мінімізація ваших ресурсів з Webpack Encore
- Відправка ресурсів у CDN
- На загальних хостингових платформах, які використовують веб-сервер Apache, вам може знадобитися встановити пакет symfony/apache-pack
- інше
Життєвий цикл додатку: безперервна інтеграція, контроль якості та ін.
Незважаючи на те, що цей запис покриває технічні деталі розгортання, повний життєвий цикл коду від розробки до виробництва може мати більше кроків: розгортання для підготовки, контроль якості, проведення тестів і т.д.
Використання підготовки, тестування, контролю якості, безперервної інтеграції, переміщень бази даних та можливості відкату в якості невдачі сильно рекомендуються. Існують прості і більш складні інструменти, і можна зробити розгортання таким легким (або складним), як того потребує ваше середовище.
Не забудьте, що розгортання вашого додатку також включає в себе оновлення будь-якої залежності (зазвичай через Composer), переміщення вашої DB, очищення вашого кешу и другие потнециальные вещи, как перемещение ресурсов в CDN (дис. Розповсюджені задачі розгортання).
Діагностика та усунення несправностей
Розгортання, що не використовують файл composer.json
Кореневий каталог проекту
(значення якого використовується через параметр kernel.project_dir
та метод
getProjectDir()) обчислюється
Symfony автоматично, як каталог, де зберігаєтся основний файл composer.json
.
В розгортаннях, що не використовують файл composer.json
, вам знадобиться
перевизначити метод getProjectDir()
як пояснюється у цьому розділі .