Локальний веб-сервер Symfony
Дата оновлення перекладу 2024-06-06
Локальний веб-сервер Symfony
Ви можете запускати додатки Symfony з будь-яким веб-сервером (Apache, nginx, внутрішній веб-сервер PHP та ін.). Однак Symfony надає власний веб-сервер, щоб зробити вас продуктивнішим під час розробки ваших додатків.
Хоча цей сервер не призначено для використання у виробництві, він підтримує HTTP/2, TLS/SSL, автоматичне генерування сертифікатів безпеки, локальні домени і багато інших функцій, які рано чи пізно знадобляться вам під час розробки веб-проектів. Більш того, сервер не привʼязано до Symfony, і ви також можете використовувати його з будь-яким PHP-додатком, і навіть з HTML або додатками однієї сторінки.
Установка
Сервер Symfony є частиною бінарності symfony
, створеної, коли ви
встановлюєте Symfony, і має підтримку для Linux, macOS і Windows.
Note
Ви можете переглянути та зробити свій внесок до джерела Symfony CLI у symfony-cli/symfony-cli GitHub repository.
Початок роботи
Сервер Symfony запускається один раз у проекті, тому у вас може вийти декілька екземплярів (кожний з них слухатиме різні порти). Ось типовий робочий процес обслуговування проекту Symfony:
1 2 3 4 5 6 7 8
$ cd my-project/
$ symfony server:start
[OK] Web server listening on http://127.0.0.1:....
...
# Тепер, перейдіть по заданому URL або виконайте цю команду:
$ symfony open:local
Запуск сервера таким чином може відобразити повідомлення логу у консолі, тому ви не зможете виконувати інші команди одночасно. Якщо ви хочете, ви можете запустити сервер Symfony фоново:
1 2 3 4 5 6 7 8 9
$ cd my-project/
# запустіть сервер фоново
$ symfony server:start -d
# продовжуйте працювати та виконувати інші команди...
# покажіть останні повідомлення логу
$ symfony server:log
Tip
В macOS, при запуску сервера Symfony ви можете побачити попередження, яке запитає вас: _"Чи хочете ви, щоб додаток приймав вхідні зʼєднання мережі?"_. Це відбувається при запуску непідписаних додатків, які не входять у перелік списку брандмауера. Рішенням буде виконанняя цієї команди, яка підписує бінарність Symfony:
1
$ sudo codesign --force --deep --sign - $(whereis -q symfony)
Підключення PHP-FPM
Note
PHP-FPM повинен бути встановлений локально для використання сервера Symfony.
Коли сервер запускається, він перевіряє web/index_dev.php
, web/index.php
,
public/app_dev.php
, public/app.php
у такому порядку. Якщо знайдено один з
них, сервер автоматично запуститься з підключеним PHP-FPM. В інших випадках, сервер
запуститься без PHP-FPM і відобразить сторінку Сторінка не знайдена
, при спробі
отримати доступ до файлу .php
у браузері.
Tip
Коли присутні і index.html
, і фронт-контролер, на кшталт index.php
, сервер
запуститься з підключеним PHP-FPM, але index.html
буде головувати над фронт-контролером.
Це означає, що коли в public
або web
є файл index.html
, він буде відображений
замість index.php
, что покаже, наприклад, додаток Symfony.
Підключення TLS
Локальний перегляд безпечної версії ваших додатків важливий для того, щоб виявити проблеми зі змішаним змістом якомога раніше, і щоб запускати бібліотеки, що працюють лише на HTTPS. За традицією, це було боляче та складно налаштовувати, але сервер Symfony все автоматизує. Спочатку виконайте команду:
1
$ symfony server:ca:install
Ця команда створює локальний авторитет сертифікату, реєструє його у вашому сховищі
довіри системи у Firefox (необхідно лише для цього браузера), і створює сертифікат
за замовчуванням для localhost
і 127.0.0.1
. Іншими словами, вона робить за
вас все.
Tip
Якщо ви робите це у WSL (Windows Subsystem for Linux), новостворений
локальний центр сертифікації потрібно вручну імпортувати у Windows. Файл
знаходиться в wsl
за адресою ~/.symfony5/certs/default.p12
. Найпростіший спосіб -
запустити explorer.exe \`wslpath -w $HOME/.symfony5/certs\`
з wsl
і двічі клацнути файл default.p12
.
До перегляду вашого локального додатку з HTTPS замість HTTP, перезапустіть його сервер, зупинивши та запустивши його знову.
Різні PHP-налаштування для кожного проекту
Вибір іншої версії PHP
Якщо у вас на компʼютері встановлено декілька версій PHP, ви можете повідомити
Symfony, яку використовувати, створивши файл під назвою .php-version
у
кореневому каталозі додатку:
1 2 3 4 5 6 7
$ cd my-project/
# використовувати конкретну версію PHP
$ echo 7.4 > .php-version
# використовувати будь-яку доступну версію PHP 8.x
$ echo 8 > .php-version
Tip
Сервер Symfony траверсує структуру каталогів до кореневого каталогу, тому ви
можете створити файл .php-version
в якомусь батьківському каталозі, щоб
встановити однакову PHP-версію для групи проектів під цим каталогом.
Виконайте команду нижче, якщо ви не памʼятаєте всі встановлені на вашому компʼютері PHP-версії:
1 2 3 4 5
$ symfony local:php:list
# Ви побачите всі підтримувані SAPI (CGI, FastCGI, та ін.) для кожної версії.
# FastCGI (php-fpm) використовується там, де можливо; потім CGI (який також діє як
# сервер FastCGIserver), і, нарешті, сервер відкочується до звичайного CGI.
Перевизначення опцій конфігурації PHP для кожного проекту
Ви можете змінити значення будь-якої опції конфігурації прогону PHP для проекту, створивши
файл під назвою php.ini
у кореневому каталозі проекту. Додайте лише опції, які хочете
перевизначити:
1 2 3 4 5 6
$ cd my-project/
# цей проект перевизначає лише часовий пояс PHP за замовчуванням
$ cat php.ini
[Date]
date.timezone = Asia/Tokyo
Виконання команд з різними версіями PHP
При запуску різних PHP-версій корисно використовувати основну команду symfony
в якості обгортки команди php
. Це дозволяє вам завжди обирати найкращу версію
PHP у відповідності з проектом, який виконує команди. Це також автоматично завантажує
змінні середовища, що важливо при виконанні не-Symfony команд:
1 2 3 4 5 6
# виконує команду з версією PHP за замовчуванням
$ php -r "..."
# виконує команду з верією PHP, обраною проектом
# (або верією PHP за замовчуванням, якщо проект не обирав версію)
$ symfony php -r "..."
Імена локальних доменів
За замовчуванням, проекти доступні з довільного порту локального IP 127.0.0.1
.
Однак, іноді лучше асоціювати з ними імʼя домену:
- Це зручніше, коли ви безперервно працюєте над одним проектом, так як номери портів можуть змінюватися, а домени - ні;
- Поведінка деяких додатків залежить від їх доменів/субдоменів;
- Наявність стабільних кінцевих точок, на кшталт локального перенаправлення URL для OAuth2.
Налаштування локального проксі
Локальні домени можливі завдяки локальному проксі, наданому сервером Symfony. Якщо це перший раз, коли ви запукаєте проксі, ви повинні сконфігурувати його наступним чином:
Відкрийте налаштування проксі нашої ОС:
Встановіть наступний URL як значення Автоматичної конфігурації проксі:
http://127.0.0.1:7080/proxy.pac
Тепер, виконайте цю команду, щоб запустити проксі:
1
$ symfony proxy:start
Якщо проксі не працює так, як пояснюється у наступних розділах, перевірте, що:
- Деякі браузери (наприклад, Chrome) вимагають повторного застосування налаштувань
проксі (шляхом натискання кнопки
Re-apply settings
на сторінціchrome://net-internals/#proxy
) або повного перезапуску після запуску проксі. Інакше, ви побачите помилку "Ця веб-сторінка недоступна" (ERR_NAME_NOT_RESOLVED
); - Деякі ОС (наприклад, macOS) не застосовують за замовчуванням налаштування проксі до
локальних хостів та доменів. Вам може знадобитися видалити
*.local
та/або інші IP-адреси з цього списку. - Операційна система Windows вимагає
localhost
замість127.0.0.1
. під час конфігурації автоматичного проксі, інакше ви не зможете отримати доступ до до вашого локального домену з браузера, запущеного в Windows.
Визначення локального домену
За замовчуванням, Symfony пропонує .wip
(що означає Незавершена робота)
для локальних доменів. Ви можете визначити локальний домен для вашого проекту
наступним чином:
1 2
$ cd my-project/
$ symfony proxy:domain:attach my-domain
Якщо ви встановили локальний проксі, як пояснюється у попередньому розділі, ви
тепер можете перейти на https://my-domain.wip
, щоб отримати доступ до вашого
локального проекту з новим користувацьким доменом.
Tip
Перейдіть за URL http://127.0.0.1:7080, щоб отримати повний список локальних каталогів проекту, їх користувацькі домени та номери портів.
Ви також можете додати підставний домен:
1
$ symfony proxy:domain:attach "*.my-domain"
Щоб він співпадав з піддоменами на кшталт https://admin.my-domain.wip
, https://other.my-domain.wip
...
При виконанні команд консолі, додайте змінну середовища https_proxy
, щоб
користувацькі домени запрацювали:
1 2 3 4 5 6 7 8
# Приклад з curl
$ https_proxy=$(symfony proxy:url) curl https://my-domain.wip
# Приклад з Blackfire та curl
$ https_proxy=$(symfony proxy:url) blackfire curl https://my-domain.wip
# Приклад з Cypress
$ https_proxy=$(symfony proxy:url) ./node_modules/bin/cypress open
Caution
Хоча імена змінних середовища завжди визначаються у верхньому регістрі, змінна середовища інша, ніж решта змінних середовища, і її імʼя прописується у нижньому регістрі.
Tip
Якщо ви надаєте перевагу використанню іншого TLD, відредагуйте файл
~/.symfony/proxy.json
(де ~
означає шлях до вашого каталогу
користувача) та змініть значення опції tld
з wip
на будь-який
інший TLD.
Довгострокові команди
Довгострокові команди, так як ті, що компілюють фронтенд веб-ресурси, блокують
термінал, і ви не можете виконувати інші команди у той же час. Сервер Symfony
надає команду run
, щоб огорнути їх наступним чином:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
# скомпілюйте ресурси Webpack, використовуючи Symfony Encore ... але зробіть це
# фоново, щоб не блокувати термінал
$ symfony run -d yarn encore dev --watch
# продовжуйте працювати та виконувати інші команди...
# час від часу перевіряйте логи команд, якщо хочете
$ symfony server:log
# і ви також можете перевірити, чи виконується ще команда
$ symfony server:status
Web server listening on ...
Command "yarn ..." running with PID ...
# зупиніть веб-сервер (і всі асоційовані команди), коли ви закінчите
$ symfony server:stop
Файл конфігурації
Існує декілька опцій, які ви можете встановити, використовуючи файл конфігурації .symfony.local.yaml
:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
# Встановлює domain1.wip і domain2.wip для поточного проекту
proxy:
domains:
- domain1
- domain2
http:
document_root: public/ # Шлях до кореню документа проекту
passthru: index.php # Індекс passthru проекту
port: 8000 # Форсувати порт, який буде використано для запуску сервера
preferred_port: 8001 # Бажаний порт HTTP [за замовчуванням: 8000]
p12: path/to/p12_cert # Імʼя файлу, що містить сертифікат TLS, для використання у форматі p12
allow_http: true # Запобігти авто-перенаправленню з HTTP на HTTPS
no_tls: true # Використати HTTP замість HTTPS
daemon: true # Запустити сервер у фоновому режимі
use_gzip: true # Увімкнути стискання GZIP
Caution
- Установка доменів у цьому файлі конфігурації перевизначить всі домени, які ви встановили
-
для поточного проекту, використовуючи команду
proxy:domain:attach
, коли ви запустите
сервер.
Конфігурація робітників
Якщо ви хочете, щоб якісь процеси запускалися автоматично, разом з веб-сервером
(symfony server:start
), додайте файл конфігурації у ваш проект:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
# .symfony.local.yaml
workers:
# вбудована команда, яка будує та споглядає за ресурсами фронтенду
# yarn_encore_watch:
# cmd: ['yarn', 'encore', 'dev', '--watch']
yarn_encore_watch: ~
# вбудована команда, яка запускає споживача месенджера
# messenger_consume_async:
# cmd: ['symfony', 'console', 'messenger:consume', 'async']
# watch: ['config', 'src', 'templates', 'vendor']
messenger_consume_async: ~
# ви також можете додати власні користувацькі команди
build_spa:
cmd: ['yarn', '--cwd', './spa/', 'dev']
Tip
Можливо, ви захочете не запускати робітників у деяких середовищах, таких як CI. Ви можете скористатися опцією
--no-workers
, щоб запустити сервер без запуску робітників.
Інтеграція Docker
Локальний сервер Symfony надає повну інтеграцію Docker для проектів, які її використовують. Щоб дізнатися більше про Docker і Symfony, див. Використання Docker з Symfony.
Коли веб-сервер визначає, що для проекту запущено Docker Compose, він автоматично демонструє деякі змінні середовища.
Через API docker-compose
, він шукає розкриті порти, використовувані для
розповсюджених сервісів. Коли він виявляє той, про який знає, він використовує
імʼя сервісу, щоб продемонструвати змінні середовища.
Розгляньте наступну конфігурацію:
1 2 3 4
# docker-compose.yaml
services:
database:
ports: [3306]
Веб-сервер визначає, що сервіс, що розкриває порт 3306
працює для проекту.
Він розуміє, що це - сервіс MySQL, і створює змінні середовища відповідно до
імені сервісу (database
) в якості префіксу: DATABASE_URL
, DATABASE_HOST
, ...
Якщо сервіс не знаходиться у списку підтримуваних нижче, встановлюються загальні
змінні середовища: PORT
, IP
, и HOST
.
Якщо імена docker-compose.yaml
не співпадають з угодами Symfony, додайте
ярлик, щоб перевизначити префікс змінних середовища:
1 2 3 4 5 6
# docker-compose.yaml
services:
db:
ports: [3306]
labels:
com.symfony.server.service-prefix: 'DATABASE'
У цьому прикладі сервіс називається db
, тому змінні середовища матимуть префікс
DB_
, але так як com.symfony.server.service-prefix
встановлено як DATABASE
,
веб-сервер створює змінні середовища, що починаються з DATABASE_
замість того, що
очікується конфігурацією Symfony за замовчуванням.
Ось список всіх підтримуваних сервісів з їх портами та префіксом Symfony за замовчуванням:
?????? | ???? | ??????? Symfony ?? ????????????? |
---|---|---|
MySQL | 3306 | DATABASE_ |
PostgreSQL | 5432 | DATABASE_ |
Redis | 6379 | REDIS_ |
Memcached | 11211 | MEMCACHED_ |
RabbitMQ | 5672 | RABBITMQ_ (?????????? ??????????? ?? ???????? ????? ?????? ?????????? Docker RABBITMQ_DEFAULT_USER ? RABBITMQ_DEFAULT_PASS ) |
Elasticsearch | 9200 | ELASTICSEARCH_ |
MongoDB | 27017 | MONGODB_ (?????????? ?? ????? ?????? ?????????? Docker MONGO_DATABASE ) |
Kafka | 9092 | KAFKA_ |
MailCatcher | 1025/1080 or 25/80 | MAILER_ |
Blackfire | 8707 | BLACKFIRE_ |
Mercure | 80 | ?????? ????????????? MERCURE_PUBLIC_URL ? MERCURE_URL (?????? ???? ? ??????????? Docker dunglas/mercure ) |
Ви можете відкрити інтерфейси веб-управління для сервісів, які їх демонструють:
1 2
$ symfony open:local:webmail
$ symfony open:local:rabbitmq
Або натиснути на посилання у розділі "Server" в панелі інструментів веб-налагодження.
Tip
Щоб налагодити та перерахувати всі експортовані змінні середовища, виконайте
symfony var:export --debug
.
Tip
Для деяких сервісів, веб-сервер також демонструє змінні середовища, що розуміються
інструментами CLI, повʼязаними з сервісом. Наприклад, запуск symfony run psql
автоматично підʼєднає вас до сервера PostgreSQL, що працює у контейнері, без необхідності
вказувати імʼя користувача, пароль або імʼя БД.
Коли запущені сервіси Docker, перейдіть на сторінку вашого додатку Symfony та перевірте розділ "Symfony Server" в панелі інструментів веб-налагодження; ви побачите, що "Docker Compose" - "Up".
Note
Якщо ви не хочете, щоб для сервісу демонструвались змінні середовища,
встановіть ярлик com.symfony.server.service-ignore
як true
:
1 2 3 4 5 6
# docker-compose.yaml
services:
db:
ports: [3306]
labels:
com.symfony.server.service-ignore: true
Якщо ваш файд Docker Compose не знаходиться у корені проекту, використайте змінні
середовища COMPOSE_FILE
і COMPOSE_PROJECT_NAME
, щоб визначити його місцезнаходження,
так само, як для docker-compose
:
1 2 3 4 5
# запустіть ваші контейнери:
COMPOSE_FILE=docker/docker-compose.yaml COMPOSE_PROJECT_NAME=project_name docker-compose up -d
# запустіть будь-яку команду Symfony CLI:
COMPOSE_FILE=docker/docker-compose.yaml COMPOSE_PROJECT_NAME=project_name symfony var:export
Note
Якщо у вас більше одного файлу Docker Compose, ви можете надати їх всі,
розділюючи :
, як пояснюється у _`довіднику змінних середовища Docker compose CLI`.
Caution
При використанні бінарності Symfony з php bin/console
(консоль symfony ...
),
бінарність буде завжди використовувати змінні середовища, визначені через
Docker, і буде інтегрувати локальні змінні середовища. Наприклад, якщо ви встановите
інше імʼя БД у вашому файлі .env.test
(DATABASE_URL=mysql://db_user:db_password@127.0.0.1:3306/test
),
і якщо ви виконаєте symfony console doctrine:database:drop --force --env=test
,
команда скине БД, визначену у вашій конфігурації Docker, а не "тестову".
Caution
Подібно до інших веб-серверів, цей інструмент автоматично розкриває всі змінні середовища, доступні в контексті CLI. Переконайтеся, що цей локальний сервер не доступний у вашій локальній мережі без вашої згоди, щоб уникнути проблем з безпекою.
Інтеграція Platform.sh
Локальний сервер Symfony надає повну, але не обовʼязкову, інтеграцію з Platform.sh - сервісом, оптимізованим для запуску ваших додатків Symfony у хмарів. Він надає такі функції як створення середовищ, бекапів/ миттєвих знімків, і навіть доступ до копії даних виробництва з вашої локальної машини, щоб допомогти з налагодженням будь-яких проблем.
Прочитайте технічні документи SymfonyCloud.