Упаковка и развертывание веб-сайта Symfony - PullRequest
0 голосов
/ 05 июля 2018

Я новичок в Symfony из мира .NET. Используя документацию Symfony (4), мне удалось создать простой веб-сайт. Сейчас я хочу запустить его в жизнь, но я изо всех сил пытаюсь найти какую-либо полезную информацию, что мне следует сделать, чтобы «упаковать» все необходимое и развернуть его. Действительно, есть страница с описанием развертывания ( Как развернуть приложение Symfony ), но мне не хватает информации о:

  • что включать / исключать (очевидно, я не хочу упаковывать dev зависимостей, и развертывание composer файлов также, кажется, не имеет никакого смысла)
  • что изменить (есть файл .env - содержащий APP_ENV и APP_SECRET - где я могу использовать эти значения?)
  • мой хостинг использует папку www для публичного представления. Нужно ли что-то менять / настраивать перед переименованием каталога public в www?
  • мне нужно настроить .htaccess, чтобы не маршрутизировать изображения / css / js через PHP?

Моя текущая структура проекта:

+ bin
+ config
+ public
  + css
  - index.php
+ src
  + Controller
  - Kernel.php
+ templates
+ var
+ vendor
- .env
- .gitignore
- composer.json
- composer.lock
- symfony.lock

Редактировать (2018-07-17):

  • Я использую Git
  • может быть развернут из ветки git с именем production (когда я нажимаю на эту ветку, он вызывает composer install --no-dev)
  • Настройка имени общедоступного каталога выполняется в composer.json

Пример дополнительной конфигурации в composer.json:

"extra": {
    "symfony": {
        "allow-contrib": false
    },
    "public-dir": "www"
}

Что касается моего первоначального вопроса - я сейчас использую возможность размещения с помощью git. В этом случае мне также нужны файлы композитора. Моя первоначальная мысль заключалась в том, чтобы собрать и упаковать минимум вещей, а затем развернуть этот пакет на сервере. (Теперь у меня все еще есть развернутые файлы bin, файлы композитора или .gitignore (и, возможно, еще более странные)).

Ответы [ 2 ]

0 голосов
/ 18 июля 2018

TL; DR

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Затем в своем хуке после получения (он же ваш сценарий развертывания) вы запустите установку composer и упомянутый chown.

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

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

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

0 голосов
/ 15 июля 2018

Ну, я сделаю снимок.

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

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

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

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

Файл .env по умолчанию работает только в режиме разработки. (обратите внимание на часть 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]
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...