Symfony CLI — новый инструмент для локальной разработки

  • Tutorial

В декабре 2018-го, на конфиренции Lisbon SymfonyCon Фабиэн Потансье — создетель фреймворка Symfony представил некий symfony.phar — инструмент для быстрого создания Symfony-приложений на основе официальных шаблонов проекта: skeleton, website-skeleton или demo. Также он позволяет запускать локальный веб-сервер для разработки.


Затем инструмент был переписан на языке Golang, что позволило реализовать много дополнительных возможностей таких, как поддержка https протокола для локального веб-сервера, тесная интеграция с SymfonyCloud и прочее! Приглашаю тебя, уважаемый читатель, познакомиться с этим инструментом подробнее, поскольку он работает не только в контексте фреймворка Symfony.


В этой статье мы рассмотрим инструмент, в контексте локальной разработки и не будем затрагивать интеграцию с SymfonyCloud.


Создание проекта


Чтобы создать новый Symfony проект, основанный на одном из официальных шаблонов, нужно запустить команду:


$ symfony new [--full | --demo] <path-to-project>

По умолчанию используется минимальный шаблон skeleton. Чтобы установить website-skeleton нужно запустить команду с опцией --full. Соответственно, для установки demo проекта необходимо запускать команду с опцией --demo.


Под капотом symfony new выполняет команду composer create-project, затем инициализирует новый Git репозиторий и сразу создаёт Initial commit.


symfony new


Локальный сервер


Для запуска сервера достаточно в корне приложения запустить команду


$ symfony serve

symfony serve


она проанализирует доступные SAPI на используемой машине и выберет лучший вариант из существующих, пользуясь следующими приоритетами: на первом месте PHP FPM, дальше PHP CGI и в конце PHP CLI. Список доступных SAPI можно посмотреть командой:


$ symfony local:php:list

symfony local:php:list


После этого команда запустит сервер, который будет доступен по адресу 127.0.0.1 и подберёт свободный порт начиная с 8000.


По умолчанию сервер запускается в интерактивном режиме. Мы сразу видим логи сервера и приложения, но наш терминал заблокирован. Сервер можно запустить в режиме демона. Для этого нужно добавить опцию -d при запуске команды symfony serve.


Логи можно будет посмотреть, запустив команду:


$ symfony server:log

также можно посмотреть статус запущеного сервера используя команду:


$ symfony server:status

чтобы остановить запущенный сервер используется команда:


$ symfony server:stop

UPD: Раньше для запуска сервера мы использовали пакет symfony/web-server-bundle. С появлением Symfony CLI этот пакет становится не очень актуальным, так как он умеет только запускать сервер, используя PHP CLI SAPI и не поддерживает HTTPS, доменные имена, PHP FPM SAPI и прочее.


Поддержка TLS


Некоторые сторонние сервисы или библиотеки требуют отправлять запросы, используя HTTPS протокол. Symfony CLI предоставляет возможность очень легко настроить поддержку TLS, установив дополнительные компоненты, с помощью следующей команды:


$ symfony server:ca:install

symfony server:ca:install


после чего достаточно перезапустить ваш браузер и вуаля — поддержка TLS настроена! Запускаете сервер командой symfony serve и можно перейти на сайт по HTTPS протоколу.


Мне не совсем нравится открывать все проекты по адресу https://127.0.0.1:8000 или https://localhost:8000, а вам? Это приносит свои неудобства: если запущено несколько проектов одновременно — нужно запоминать на каком порту какой проект работает; при перезапуске сервера порты могут меняться и т.п.


Symfony CLI решает и этот вопрос! Он предоставляет для нас proxy-сервер, с помощью которого можно создавать красивые доменные имена. Для этого нужно привязать к нашему проекту желаемое домменое имя с помощью команды:


$ symfony proxy:domain:attach <domain-name>

symfony proxy:domain:attach


таким образом домен demo-project.com привязался к директории с проектом. Далее нам нужно запустить proxy-сервер командой:


$ symfony proxy:start

symfony proxy:start


Мы запустили proxy-сервер в режиме демона и он доступен у нас по адресу http://127.0.0.1:7080, можем открыть его в браузере:


symfony proxy server


где увидим список доменов, пути к проектам в файловой системе и статус сервера для каждого проекта. На данном скриншоте видно то, что все сервера находятся в статусе Stopped, то есть они пока не запущены. Следующим шагом нам нужно добавить этот proxy-сервер в настройки ОС


macOS Proxy Config


На этом настройка proxy-сервера заканчивается, далее нужно запустить сервер уже известной нам командой symfony serve. Помимо IP-адреса с портом мы увидим наше доменное имя, по которому можем перейти в браузере! Ко всем доменным именам добавляется постфикс .wip.


symfony serve


То есть в случае использования proxy-сервера flow запуска проекта немного меняется:


  1. Запускаем proxy-сервер
    $ symfony proxy:start
  2. Запускаем сервер для приложения
    $ symfony serve

Для завершения работы с проектом "зеркалируем" действия, описанные выше:


  1. Останавливаем сервер
    $ symfony server:stop
  2. Останавливаем proxy-сервер
    $ symfony proxy:stop

Для упрощения данных операций рекоммендую использовать утилиту GNU Make.


Переключение версий PHP


Если вы используете разные версии PHP на разных проектах, вы наверняка сталкивались с проблемой переключения между версиями. Было бы здорово иметь какой-то автоматический инструмент для этого, не так ли? Symfony CLI умеет решать и эту проблему! Вам достаточно создать файл .php-version в корне проекта и в качестве содержимого указать желаемую версию.


$ echo "7.2" > .php-version

php-version


Как видно на скриншоте выше, Symfony CLI прочитал файл .php-version и запустил сервер, используя версию, указанную в этом файле.


Так же Symfony CLI предоставляет нам обёртку над PHP CLI, которая тоже учитывает версию PHP, указанную в файле .php-version. То есть если вам нужно вызывать консольные скрипты, например bin/console — используйте её.


$ symfony php

symfony php


Для удобства можно создать алиас для этой команды, чтобы сэкономить время и избежать ошибок в написании команды. К примеру, я создал для себя алиас sphp:


$ echo "alias sphp='symfony php'" >> ~/.bash_profile && source ~/.bash_profile

Symfony CLI предоставляет аналогичную обёртку для Composer, поэтому с ним у вас также не возникнет никаких проблем. Для удобства можно создать алиас и для этой обёртки. У меня это scomposer:


$ echo "alias scomposer='symfony composer'" >> ~/.bash_profile && source ~/.bash_profile

Проверка на уязвимые пакеты


В качестве бонуса Symfony CLI предоставляет команду для проверки на наличие уязвимых composer-пакетов в вашем проекте. Больше не прийдётся устанавливать в проект зависимость Symfony Security Checker. Так же официальная документация говорит о том, что версия встроенная в Symfony CLI работает оптимальнее за счёт того, что она не делает HTTP запросы на официальный API. Запустить проверку можно командой:


$ symfony security:check

symfony  security:check


Заключение


Symfony CLI — это довольно-таки удобный компонент локальной инфраструктуры приложения. У него есть возможность запускать веб-сервер с поддержкой HTTPS протокола, создавать доменные имена, автоматизировать переключение версии PHP для каждого проекта, проверять зависимости на наличие уязвимостей.


Официальную документацию компонента можно найти по этой ссылке.
Любые вопросы и проблемы можно описывать в официальном репозитории symfony/cli на GitHub.


Делитесь вашим опытом работы с данным инструментом в комментариях.


Спасибо за внимание!

Комментарии 20

    0
    Немного завидно, работаю часто с Python/Django, батареек конечно много, но из коробки таких фич как https и прокси в дев режиме нет.
      0
      Пакет однозначно неплох для старта проекта, но в большинстве случаев при разработке используется Docker, что позволяет гарантировать одинаковый набор пакетов на дев и прод стенде. Поэтому использовать Symfony CLI для сервера я бы не стал.
        +3

        Но… заголовок вроде как намекает...

          0

          Я имею ввиду, что для локальной разработки в качестве сервера я бы его не взял. Исключительно для создания каркаса приложения и проверки пакетов.

          0

          Ну одинаковый набор пакетов гарантирует и композер. Или вы про пакеты ОС? А вообще согласен на все сто.

            0

            Я про пакеты операционной системы, включая особые скомпилированные сборки(например, ffmpeg с особыми кодаками или curl с поддержкой Гост шифрования).

          0
          А я правильно понимаю, что код утилиты закрыт? Или я просто найти не смог?
            0
            Пока что код утилиты закрыт. Как говорят разработчики, на данный момент они не планируют открывать код проекта.
            +3
            Небольшое дополнение. Если в корне проекта разместить php.ini, то утилита переопределит значения выбранного SAPI значениями из этого файла.

            Вполне годна штука, если нет желания возиться с докером для локальной разработки.
              0
              Верно, спасибо за дополнение!
              0
              1. Зачем это надо, если у Симфони и так есть пакет для поднятия cli-сервера, он даже напоминает как этот пакет называется при установке фреймворка?
              2. Что у этой утилиты в плане блокирования I/O?
                +4
                Пакет у Symfony может работать только с CLI SAPI, данная утилита прекрасно дружит с php-fpm + умеет в https и привязку доменов. Кроме этого, локальная разработка лишь 30% функционала этой утилиты, большей частью она была создана для управления проектом связке локальная разработка + prod в symfony clouds, там много интересных плюшек по клонированию окружения проекта из prodа в локальный dev и тд. Подробнее можно в презентации Фабиена посмотреть symfonycasts.com/screencast/symfonycon2018/back-to-basics
                  +3
                  Ага, большое спасибо. greeflas возможно, стоит добавить в статью?
                    +1
                    Добавил обновление про symfony/web-server-bundle. Возможности интеграции с SymfonyCloud возможно опишу в другой статье.
                –3
                Не понимаю, зачем это сделано.
                Какую проблему это решает?
                Кто целевая аудитория этой штуковины?

                Почему просто нельзя взять обычный nginx, для которого хватает примитивного конфига из плутора десятков типичных строк, сроутить его на свой бесплатный поддомен, поддомен на 127.0.0.1, а бесплатный настоящий SSL сертификат получить через DNS.
                Это же значительно проще, чем ставить всякие хаки с прокси.
                  0
                  для тех, кто умеет в nginx, certbot и прочие радости — эта штука и не нужна. эта штука для тех кто по шпаргалке три команды выполнил и с радостью может кодить
                    +1

                    Или для тех, кого уже достало по два раза в день копипастить конфиги nginx, PHP, может Docker и ко из проекта в проект.

                  +1

                  Без поддержки докера, ценность данной фичи сомнительна

                    –2
                    Сижу в докере, смысла этой утилиты не вижу(, а так круто конечно. А вот composer в GO переписали бы, этор было бы круто)))
                      +1
                      точно, а заодно и PHP переписать на Go стоит, почему бы и нет, всё переписанное на GO ведь становится лучше!

                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                    Самое читаемое