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

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

what to include/exclude (obviously I don't want to pack dev dependencies, and deploying composer files also doesn't seems to make any sense)

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

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

what to change (there's .env file - containing APP_ENV and APP_SECRET - where do I use those values?)

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

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

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

my hosting uses folder www for public presentation, do I have to change/configure something before renaming public directory just to www?

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

do I have to configure .htaccess to not route images/css/js trough 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]

TL; DR

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

Создание контейнера без сохранения состояния

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

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

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

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

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

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

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

Теперь к правильным ответам

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

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

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

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

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

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

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

Затем в вашем обработчике post-receive (также известном как ваш сценарий развертывания) вы запустите установку композитора и упомянутый файл chown.

Незапрошенная консультация

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

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