Дата обновления перевода: 2021-05-27

Как развернуть приложение Symfony

Развёртывание приложения Symfony может быть сложной и разнообразной задачей, в зависимости от установки и требований вашего приложения. Эта статья не является пошаговым руководством, она представляет собой общий список наиболее распространённых требований и идей для развёртывания.

Основы развёртывания Symfony

Типичные шаги, предпринимаемые при развёртывании приложения Symfony включают в себя:

  1. Загрузите ваш код на сервер производства;
  2. Установите ваши зависимости поставщика (обычно делается через Composer и может быть выполнено до загрузки);
  3. Запуск перемещений базы данных или схожие задания по обновлению измененных структур данных;
  4. Очистка (и по желанию разогрев) вашего кеша.

Развёртывание может также включать в себя следующие задачи:

  • Тегирование конкретной версии вашего кода в качестве резила в хранилище вашего исходного кода;
  • Создание временного участка подготовки производства для построения вашей обновлённой установки “оффлайн”;
  • Запуск любых доступных тестов, чтобы убедиться в стабильности кода и/или сервера;
  • Удаление любых ненужных файлов из каталога public/ для поддержания чистоты вашего окружения производства;
  • Очистка внешних систем кеширования (как Memcached или Redis).

Как развернуть приложение Symfony

Существует несколько путей развёртывания вашего приложения Symfony. Начните с нескольких базовых стратегий развёртывания и после наращивайте силы.

Базовый перенос файла

Самым базовым способом развёртывания приложения является копирование файлов вручную с помощью FTP/SCP (или схожего метода). Этот способ имеет свои недостатки, так как вам будет не хватать контроля над системой по мере прогрессирования улучшений. Этот метод также требует некоторых ручных действий после переноса файлов (см. `Распространённые задачи после развёртывания`_).

Использование системы управления исходным кодом

Если вы используете системы управления исходным кодом (например, Git или SVN), вы можете упростить себе жизнь, если ваша живая инсталляция также будет копией вашего хранилища. Когда вы будете готовы к улучшению (апгрейду), все что вам нужно будет сделать - это вызвать последние обновления из вашей системы контроля исходного кода. При использовании Git распространённым подходом является создание тега для каждого релиза и проверка соответствующего тега при развёртывании (см. `Тегирование Git`_).

Это облегчает обновление ваших файлов, но вам все еще надо беспокоиться о том, чтобы выполнять другие шаги вручную (см. `Распространённые задачи после развёртывания`_).

Использование платформ в качестве сервиса

Использование платвормы в качестве сервиса (PaaS) может быть отличным способом развернут ваше приложение Symfony быстро и лекго. Существует множество PaaS, ниже перечислены те, что хорошо работают с Symfony:

Использование скриптов сборки и других инструментов

Существуют также инструменты, которые облегчают муки развёртывания. Некоторые из них были специально подогнаны под требования Symfony.

EasyDeployBundle
Пакет 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

Then, make sure that the checker is included in your Composer scripts:

 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 (для локальных переопределений). Но при производстве у вас есть два варианта:

  1. Создать “настоящие” переменные окружения. То, как вы устанваливаете переменные окружения, зависит от ваших настроек: они могут быть установлены в командной строке, в вашей конфигурации Nginx или черещ другие методы, предоставленные вашими сервисами хостинга;
  2. Или создать файл .env.local как вашу локальную разработку.

Ни у одного варианта нет существенных преимуществ: используйте тот, который наиболее природный в вашем окружении хостинга.

Tip

Вы можете не хотеть, чтобы ваше приложение обрабатывало файлы .env.* по каждому запросу. Вы можете сгенерировать оптимизированный .env.local.php, который переопределяет все другие файлы конфигурации:

1
$ composer dump-env prod

Сгенерированный файл будет содержать всю конфигурацию, храняющуюся в .env. Если вы хотите полагаться только на переменные окружения, сгенерируйте его без значений, используя:

1
$ composer dump-env prod --empty

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) Другие вещи!

Существует еще масса других вещей, которые вам может понадобиться сделать, в зависимости от вашей установки:

Жизненный цикл приложения: непрерывная интеграция, контроль качества и др.

Несмотря на то, что эта запись покрывает технические детали развёртывания, полный жизненный цикл кода от разработки до прозводства может иметь больше шагов: развёртывание для подготовки, контроль качества, проведение тестов и т.д.

Использование подготовки, тестированя, контроля качества, непрерывной интеграции, перемещений базы данных и возможности отката в случае провала сильно рекомендуются. Существуют простые и более сложные инструменты, и можно сделать развёртывание таким лёгким (или мудрёным), как требует этого ваше окружение.

Не забудьте, что развёртывание вашего приложения также включает в себя обновление любой зависимости (обычно через Composer), перемещение вашей DB, очистку вашего кеша и другие потнециальные вещи, как перемещение ресурсов в CDN (см. `Распространённые задачи после развёртывания`_).

Диагностика и устранение неполадок

Развёртывания, не использующие файл composer.json

Корневой каталог проекта (значение которого используется через параметр kernel.project_dir и метод getProjectDir()) высчитывается Symfony автоматически, как каталог, где хранится основной файл composer.json.

В развертываниях, не использующих файл composer.json, вам понадобится переопределить мтеод getProjectDir() method как объясняется в этом разделе.

Эта документация является переводом официальной документации Symfony и предоставляется по свободной лицензии CC BY-SA 3.0.