Упаковка и развертывание веб-сайта Symfony

Ответ 1

Хорошо, я сделаю снимок.

что включать/исключать (очевидно, я не хочу упаковывать зависимости dev, а развертывание композиционных файлов также не имеет никакого смысла)

Я замечаю, что у вас нет .gitignore. Если вы не используете GIT (вы должны) посмотреть на gitignore по умолчанию, он скажет вам, какие папки вам не нужны.

Вы правы, поставщики не нужны. Файл блокировки композитора содержит точные версии, которые вы используете. Просто создайте composer install только вы скопировали файлы на сервер. Самый простой способ "развертывания" - использовать git (hub), а также настроить ssh-ключ на вашем сервере и предоставить ему доступ для чтения к вашему git-репо. (Развернуть ключ)

что изменить (там.env файл - содержащий APP_ENV и APP_SECRET - где я могу использовать эти значения?)

Файл.env работает только в режиме dev по умолчанию. (обратите внимание на часть require-dev в вашем composer.json).

Symfony рекомендует использовать "реальные" переменные среды в производстве, но вы можете использовать файл .env. Для этого вам нужно будет двигаться "symfony/dotenv" от require-dev, чтобы require в composer.json. (Сделайте обновление после)

Вы также захотите установить APP_ENV на prod на вашем сервере, настроить db acccess и mailer.

мой хостинг использует папку www для публичной презентации, мне нужно что-то изменить/настроить, прежде чем переименовать общедоступный каталог только на www?

Я не буду отвечать полностью, это займет слишком много времени. Настройте apache, чтобы указать на ваш публичный каталог с помощью VirtualHost. Подробнее здесь: https://symfony.com/doc/current/setup/web_server_configuration.html

мне нужно настроить.htaccess, чтобы не маршрутизировать изображения /css/js через PHP?

Если вы установили пакет apache, вы получите файл .htaccess и игнорируете файлы.

# If the requested filename exists, simply serve it.
# We only want to let Apache serve files and not directories.
RewriteCond %{REQUEST_FILENAME} -f
RewriteRule ^ - [L]

Таким образом, запрошенные файлы не будут попадать в ваш PHP-код. Если файл не существует, Symfony обработает запрос. Я рекомендую игнорировать общие расширения файлов, например:

# Do not allow image requests to hit symfony
RewriteCond %{REQUEST_URI} \.(gif|jpg|jpeg|png|ico|map)$ [NC]
RewriteRule .* - [L]

Ответ 2

TL; DR

Поскольку PHP не является компилируемым языком, процесс сборки в плане компиляции кода в исполняемый файл здесь не уместен.

Создание контейнера без гражданства

Однако, если вы разрабатываете веб-приложение и хотите его развернуть, ваш лучший способ пойти (что означает, отраслевой стандарт) - это "построить" из него контейнер без гражданства. В этом контейнере у вас будет типичный Apache + PHP или Ngnix + PHP-FPM (или даже PHP с PM-PM). Это будет ваш прикладной процесс, открытый портом 80: красивый, безгосударственный и масштабируемый контейнер докеров.

В процессе создания контейнера идея состоит в том, что вы устанавливаете версию PHP по вашему выбору (с соответствующими расширениями) и веб-сервер или процесс, который будет выполняться через порт HTTP. Затем вы вытаскиваете свой код в контейнере с помощью git и устанавливаете переменные среды и выполняете установку композитора. Результатом будет изображение докера с версией вашего приложения в нем, доступным по порту 80.

Подробнее об этом здесь.

Мммм, нет, я не делаю контейнеров

Конечно, это не может быть для вас, в зависимости от того, насколько ваше приложение следует принципам двенадцатифакторного приложения и где вы собираетесь его разместить.

Если вы хотите, чтобы развернуть на виртуальный хостинг, вам нужно будет изменить public папку для корневого каталога документов вашего хостинг - провайдера. Поскольку у вас нет доступа к среде выполнения PHP на общедоступном хостинге, вам нужно будет скопировать ваш.env файл и отправить его на веб-хостинг (что является ужасно неуверенной практикой).

Чтобы настроить автоматическое развертывание, вам следует выбрать ssh. Если у вас нет консольного доступа к вашему веб-хостингу, то git-ftp, вероятно, ваш лучший друг здесь. Используя webhooks (например, в Github), в событии post-receive вы разворачиваете свой код с помощью скрипта, который будет содержать, помимо прочего, установку композитора (с заблокированными зависимостями) и все, что угодно, на www -data user (или пользователь веб-сервера, если на то пошло).

Теперь, для правильных ответов

Сказав это, я постараюсь ответить на ваши вопросы:

1. Ты прав. vendor/ должен оставаться вне дома. Однако не composer.lock. В принципе, вам нужно развернуть весь код, живущий в вашем репозитории.

2. В вашем сценарии развертывания (да, у вас его будет один), вы должны создать новый.env файл, который будет добавлен. Да, вам нужны все параметры там, но, очевидно, со значениями для производственной среды.

3. Да, вы должны переименовать Symfony public папки для www. Насколько мне известно, вы не должны сталкиваться с проблемами. То есть, если вы не используете сервер Symfony для разработки. Но простой простой php -S localhost:8000 -t www в вашем проекте будет достаточным для целей разработки. Я пользуюсь этим все время.

   4. Если вы используете apache, да, вы должны включить в развертывание.htaccess.

Ваше обновление

Поэтому я вижу, что ваш хостинг имеет возможности развертывания git. Это хорошо. В этом случае должен быть способ настроить крюк post-receive в репо, находящемся там. Этот пост-прием может выполнять любую команду bash, например, установку композитора. Тем не менее, это будет исполняемый композитор, но я не уверен, что это будет включено. Что вы можете сделать, так это загрузить composer.phar в корневой каталог вашего хостинга. Это композитор, в одном исполняемом файле.

Затем, в вашем post-receive hook (также как ваш скрипт развертывания), вы запустите установку композитора и упомянутый chown.

Не запрашиваемый совет

Я понимаю, что ваши требования должны развертываться на веб-хостинге. Тем не менее, вы ищете преимущества CI/CD таким образом, чтобы это не был в настоящее время промышленным стандартом. Веб-хосты не предназначены для конвейеров развертывания. То, как вы делаете это сейчас, может вызвать у вас некоторую боль в будущем, особенно при добавлении некоторых других вспомогательных услуг или масштабирования и т.д....

Теперь, если ваше приложение мало и просто, вы, вероятно, можете игнорировать мои слова.