Я просто прочитал Twelve-Factor App, который выглядит как довольно полный набор правил для применения в веб-приложении. Он использует python или рельсы в своих примерах, но никогда не php... Мне было интересно, , какие факторы манифеста могут быть применены к проектам PHP и как?
Спасибо
Короткий ответ:
Все точки применимы к PHP, поскольку двенадцатифакторный манифест приложения предназначен специально для веб-приложений.
PHP очень тяжело соблюдает двенадцать факторов, в частности, в пунктах 2, 7, 8 9 (как побочный эффект 7 и 8) и 12 (частично). Собственно, что первый действительно обоснованный аргумент, который я слышал во всём "PHP sucks" rant, который распространен в сообществах Ruby и Python (не поймите меня неправильно, я думаю, что Ruby и Python - лучшие языки, но я не ненавижу PHP, и окончательно ненавижу "мой язык лучше".)
Будучи сказанным, может быть, что ваш PHP-проект не является веб-приложением или SaaS, а просто простым веб-сайтом, поэтому вы можете просто считать, что двенадцать факторов не являются необходимостью.
Длинный ответ:. Поэтапный анализ:
Codebase: не проблема
Зависимости:, как работает PEAR, против этой точки, поскольку зависимости груши установлены в системе, и обычно у вас нет консолидированного манифеста, чтобы объявить их. Также обычно для установки PHP требуется, чтобы вы добавляли пакеты в установку ОС, чтобы получить доступ к некоторым библиотекам. Наконец, AFAIK не является инструментом в PHP для обеспечения изоляции, такой как "virtualenv", "rbenv" или "rvm" (или, если он существует, не пользуется популярностью среди сообщества PHP) Редактировать: Композитор (http://getcomposer.org/), похоже, делает правильное отношение к зависимостям, он все еще не изолирует версию PHP, но для остальных это должно быть хорошо.
Конфигурация: Некоторые фреймворки PHP не очень хорошо подходят для этого, но есть, безусловно, другие, которые преуспевают, поэтому это не является недостатком самой платформы
Резервные службы не должны быть большой проблемой, несмотря на то, что, возможно, придется немного взломать некоторые фреймворки, чтобы управлять сервисами как ресурсами
Сборка, выпуск, запуск:, это полностью применимо к PHP, поскольку это окончательно не касается только "компиляции". Можно утверждать, что несколько проектов и хостинговых платформ в сообществе PHP злоупотребляют прямым FTP и т.д., Но это не является недостатком самого PHP, и нет никаких реальных препятствий для правильного использования этого элемента.
Процессы:. Это определенно относится к PHP. PHP вполне способен запускать чисто безпартийные процессы (акцент делается на слово "без гражданства" ), и на самом деле несколько рамок делают вашу жизнь легкой для этого. Например, symfony предоставляет готовое управление сеансом с memcached или хранилищем базы данных вместо обычных сеансов.
Связывание с портами:. По сравнению с этим, этот пункт в основном требует от вас обратного прокси-сервера и фактического веб-сервера, встроенного в приложение, вместо того, чтобы быть отделенным компонентом. Это ставит PHP в очень трудное положение. Несмотря на то, что есть способы сделать это (см. Ответ об использовании PHP как FastCGI), который определенно не является наиболее распространенным и наилучшим способом поддержки PHP-приложения, как в других сообществах (например, Ruby, Node.js).
Процессы: Это не невозможно в PHP. Однако несколько элементов ставят PHP в трудное положение. А именно отсутствие хорошей поддержки пунктов 6 и 7; тот факт, что PHP API для создания новых процессов на самом деле не очень приятно работать; и особенно то, как Apache mod_php обрабатывает своих работников (что на сегодняшний день является наиболее распространенной схемой развертывания для PHP)
Опорная способность: Если вы используете правильные инструменты, PHP не имеет ничего общего с PHP, чтобы не создавать быстрых, одноразовых, аккуратных веб-процессов и рабочих процессов. Однако я считаю, что, поскольку базовую модель процесса трудно реализовать в соответствии с точками 7 и 8, тогда 9 становится немного громоздким как побочный эффект
Параметр Dev/prod: Это очень несовместимо с платформой, и я бы сказал, что один из самых трудных действий - это сделать правильно. PHP не является исключением из этого правила, но у него тоже нет особых препятствий. Фактически большинство инструментов, названных в манифесте, могут быть применены к проекту PHP
Журналы: Наличие агностика вашего приложения в системе регистрации в исполняемой среде полностью выполнимо на PHP
Процессы администратора:Самым важным недостатком PHP в этом отношении является отсутствие оболочки REPL. Что касается остальных, несколько инфраструктур, таких как Symfony, позволяют вам программировать задачи администратора (например, миграции на основе Doctine) и запускать их в той же среде, что и ваша "обычная" веб-среда.
Поскольку сообщество PHP развивается, возможно, он уже исправил некоторые из упомянутых ошибок.
Сборка, выпуск, запуск: применимо к скомпилированному коду, что не относится к PHP. Итак, это точка - это не то, что вам нужно посмотреть.
Я не претендую на какие-либо полномочия в отношении этих 12 факторов, но мой комментарий к этому разделу заключается в том, что автор не согласится. Это не только компиляция, но и управление зависимостями как в малом (моментальный снимок кода), так и в целом (любые библиотеки, используемые в коде).
Представьте, что вы новый разработчик, и они говорят: "Хорошо, это обычное приложение php, поэтому...
a) Пользовательский код - это действительно два подпроекта, которые находятся в репо A и repo B.
b) Вам нужно будет создать макет каталога так, а затем
c) проверьте код для каждого подпроекта в этот подкаталог и этот подкаталог.
d) Вам также понадобятся эти три библиотеки PHP с открытым исходным кодом:
версия 3.1 библиотеки Foo, версии 2.3 библиотеки Bar и версия 5.6 библиотеки Bat.
e) загрузите их со своих исходных сайтов проекта и распакуйте их, затем скопируйте их в этот каталог, этот каталог и другой каталог.
f), вам нужно будет установить эти конфигурации во внешней библиотеке,
g) и эти конфиги в наших двух пользовательских проектах кода.
h), как только все будет выполнено, tar/gzip все это, загрузите его на сервер QA и распакуйте его в htdocs.
В этом наборе шагов нет компиляции, но вы можете сделать ставку на создание большого количества объектов.
Получение всей этой настройки и работы - это шаг сборки.
Использование tar/gzip для создания моментального снимка рабочей сборки - это шаг выпуска.
SCP'ing/распаковка его в каталог htdocs сервера QA - это этап выполнения.
Вы можете сказать, что некоторые из этих шагов выше не нужны - библиотеки должны быть развернуты на системном уровне и просто импортированы. С сайта 12factors.net я бы сказал, что автор предпочитает импортировать их уникально и индивидуально для приложения. Это оборачивает проблемы управления версиями зависимостей за счет большего дискового пространства (не для того, чтобы кто-то заботился). Есть больше проблем в управлении всеми этими зависимостями как локальное приложение, но тогда это точка сборки/выпуска/времени выполнения.
Возможно, он изменился с момента его чтения - сейчас есть несколько примеров PHP, хотя некоторые из них кажутся отрицаниями концепции двенадцатифактора.
Один из способов, которым обычные сайты mod_php нарушают двенадцать факторов, приходит с VII. Связывание портов. Из манифеста:
Приложение с двенадцатью факторами полностью самодостаточно и не полагается на инсталляцию веб-сервера во время выполнения в среду выполнения, чтобы создать веб-интерфейс. Веб-приложение экспортирует HTTP как услугу путем привязки к порту и прослушивания запросов, поступающих на этот порт.
Однако apache/php можно уговорить в этом мировоззрении с чем-то вроде этого:
https://gist.github.com/1398498
Не идеально, но он работает по большей части. Чтобы проверить это, установите мастера:
Мастер установки драгоценных камней
затем запустите его в каталоге, в который вы клонировали суть:
стартовый старт
затем посетите
Я просто прочитал несколько строк каждой точки, и здесь идет мой анализ документа:
Codebase: каждый, php или не должен иметь кодовую базу даже для небольших проектов
Dependecies. PHP использует библиотеки и библиотеки кода, которые вы всегда можете легко переносить, просто скопировав код на сервер. Иногда вы используете PEAR, а затем, если сервер не поддерживает его, вам необходимо скопировать и установить грушу вручную. Я использую Zend Framework большую часть времени, поэтому он просто копирует код фреймворка с загрузкой ftp.
Конфигурация. Обычно для приложений php имеется файл конфигурации для записи, в который вы храните конфигурации. Где вы храните его, вы выбираете разработчика, но обычно это либо в корне вашего приложения, либо в папке настроек/конфигурации.
Резервные службы. PHP использует службу поддержки большую часть времени, например MySQL. Другие общие службы в зависимости от вашего приложения - твиттер и facebook. Вы используете свой API для связи с ними и хранения/извлечения данных для работы.
Сборка, выпуск, запуск. Применимо к скомпилированному коду, который не относится к PHP. Таким образом, этот момент не является чем-то, что вам нужно посмотреть.
Процессы. HTTP является безстоящим и обслуживается, поэтому вы, как правило, не имеете никакого процесса, кроме веб-сервера. Это не совсем так, поскольку веб-сервис может быть связан с приложениями, которые вы упаковываете или создаете для него. Но, ради стандартов, вам обычно не нужно использовать процессы в веб-мире.
привязка к портам. PHP не применяется к привязке к порту вообще, потому что это не процесс, который перехватывает адрес, Apache, NGinx или Lighttpd делает это для вас. Чтение № 6/7 заставляет меня понять, что веб-сайт никогда не может быть приложением с двенадцатью факторами.
Concurrency: снова этот пункт рассматривает процессы, которые не относятся к веб-страницам PHP. Этот момент применяется к серверу, обслуживающему контент.
Располагаемость. В этом пункте обсуждается, как быстро должен быть процесс. Очевидно, что веб-сайты PHP, не являющиеся процессом, не должны применяться, но всегда отмечайте, что ваш сайт должен выполнять страницы как можно быстрее... Всегда думайте об этом блоке или блоке кода и смотрите, оптимизирован ли он.
Dev/Prod Parity. Этот момент имеет решающее значение в любой разработке приложений. Вы никогда не хотите иметь большой разрыв между двумя версиями приложений, или обновление может стать проблемой. Кроме того, никогда не создавайте клиентские версии приложения. Всегда находите способы настроить или настроить приложение на уровне шаблона, чтобы вы могли максимально приблизить ваше приложение к всем установленным версиям.
Журналы. Журналы всегда хороши, они позволяют вам следить за процессом вашего кода, не выводить его на экран. Моя любимая тактика - "tail -f logfile" внутри консоли linux и посмотреть, что происходит, когда я выполняю свой код.
Процессы администратора. Не применимо. В php у вас нет процессов, но у вас есть страницы, которые вы можете защитить с помощью имен пользователей и паролей.