W jaki sposób manifest aplikacji Twelve-Factor jest stosowany w projektach PHP?

Właśnie przeczytałem Twelve-Factor App, która wygląda jak dość obszerny zestaw reguł do zastosowania w aplikacji internetowej. Używa Pythona lub rails w swoich przykładach, ale nigdy php... Zastanawiałem się Jakie czynniki manifestu można zastosować do projektów PHP i jak ?

Thanks

Author: Naoise Golden, 2011-11-24
Source

4 answers

Krótka odpowiedź:

Wszystkie punkty dotyczą PHP , ponieważ Manifest app twelve factor odnosi się specjalnie do aplikacji internetowych.

PHP ma bardzo trudny czas na dostosowanie się do czynnika dwunastego, w szczególności w punktach 2, 7, 8 9 (jako efekt uboczny 7 i 8) i 12 (częściowo). Właściwie to jest pierwszy naprawdę uzasadniony argument, który usłyszałem w całym" PHP sucks " rant, który jest powszechny w społecznościach Ruby i Python (nie zrozum mnie źle, myślę, że Ruby i Python są lepsze języków, ale nie nienawidzę PHP i zdecydowanie nienawidzę" mój język jest lepszy".)

Biorąc to pod uwagę, może być tak, że twój projekt PHP nie jest aplikacją internetową lub SaaS, ale prostą stroną internetową, więc możesz po prostu uznać, że twelve factor nie jest potrzebny.

Długa odpowiedź: Analiza punkt po punkcie brzmiałaby:

  1. Codebase: not an issue

  2. Zależności: Sposób działania PEAR jest dość sprzeczny z tym punktem, ponieważ pear zależności są instalowane w całym systemie i zazwyczaj nie masz skonsolidowanego manifestu, aby je zadeklarować. Jest również zwykle, gdy konfiguracja PHP wymaga dodania pakietów do instalacji systemu operacyjnego, aby uzyskać dostęp do niektórych bibliotek. W końcu AFAIK nie ma w PHP narzędzia do zapewnienia izolacji jak "virtualenv", "rbenv" lub " rvm " (lub jeśli istnieje nie jest popularny wśród społeczności PHP) Edit: Composer ( http://getcomposer.org / ) wydaje się, że postępuje słusznie w odniesieniu do zależności, nadal nie izoluje wersji PHP, ale dla całej reszty powinno być dobrze.

  3. Config: niektóre frameworki PHP nie nadają się do tego, ale są na pewno inne, które dobrze sobie radzą, więc nie jest to wada samej platformy

  4. Usługi wspierające: nie powinny być dużym problemem, pomimo być może konieczności hakowania niektórych frameworków, aby zarządzać usługami jako zasobami

    {22]}

  5. Build, release, run: to jest całkowicie appliable do PHP, ponieważ definitywnie nie dotyczy to tylko "kompilacji". Można argumentować, że kilka projektów i platform hostingowych na społeczności PHP nadużywa bezpośredniego FTP, itp. ale to nie jest wada samego PHP i nie ma realnej przeszkody w robieniu rzeczy dobrze w odniesieniu do tego elementu.

  6. Procesy: to definitywnie dotyczy PHP. PHP jest w stanie uruchamiać procesy czysto bezstanowe( nacisk kładziony jest na słowo bezstan), a właściwie kilka ramy ułatwiają Ci życie. Na przykład symfony zapewnia gotowe zarządzanie sesjami za pomocą pamięci memcached lub bazy danych zamiast zwykłych sesji

  7. Wiązanie portów: Po prostu ten punkt w zasadzie wymaga odwrócenia proxy i osadzenia rzeczywistego serwera www w aplikacji, zamiast być oddzielonym komponentem. Stawia to PHP w bardzo trudnej sytuacji do spełnienia. Mimo to istnieją sposoby na to (patrz odpowiedź o używaniu PHP jako FastCGI) to zdecydowanie nie jest najpopularniejszy ani najlepiej obsługiwany sposób obsługi aplikacji PHP, jak to jest w innych społecznościach (np. Ruby, Node.js).

  8. Procesy: to nie jest niemożliwe w PHP. Jednak kilka elementów stawia PHP w trudnej sytuacji do spełnienia. A mianowicie brak dobrego wsparcia dla elementów 6 i 7; fakt, że API PHP do wywoływania nowych procesów nie jest naprawdę miłe w pracy; a szczególnie sposób, w jaki mod_php Apache radzi sobie z ich pracownikami (co jest zdecydowanie najbardziej common deployment schema for PHP)

  9. Disposability: Jeśli używasz odpowiednich narzędzi, nie ma nic nieodłącznego w PHP, aby uniemożliwić tworzenie szybkich, jednorazowych, uporządkowanych procesów internetowych i roboczych. Jednak uważam, że ponieważ podstawowy model procesu jest trudny do wdrożenia zgodnie z punktami 7 i 8, to 9 staje się nieco kłopotliwe jako efekt uboczny

  10. Parytet Dev / prod: to jest bardzo agnostyczne dla platformy i powiedziałbym, że jedno z najtrudniejszych do zrobienia racja. PHP nie jest wyjątkiem od tej reguły, ale nie ma też konkretnej przeszkody. W rzeczywistości większość narzędzi wymienionych w manifeście może być zastosowana do projektu PHP

  11. Logs: posiadanie aplikacji agnostycznej systemu logów w środowisku wykonawczym jest całkowicie wykonalne w PHP

  12. Procesy administracyjne: najważniejszą wadą PHP w tym punkcie jest brak powłoki REPL. Co do reszty, kilka frameworków takich jak Symfony pozwala możesz programować zadania administratora (np. migracje baz danych oparte na Doctine) i uruchamiać je w tym samym środowisku ,co twoje "zwykłe" środowisko internetowe.

Ponieważ społeczność PHP ewoluuje, być może już naprawiła niektóre z wymienionych błędów.

 15
Author: Juan Pablo Saraceno,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-04-29 13:30:44

Build, release, Run: dotyczy skompilowanego kodu, co nie ma miejsca w PHP. Więc to punkt nie jest czymś, na co trzeba patrzeć.

Nie twierdzę żadnego autorytetu w tej sprawie 12 factor, ale mój odczyt tej sekcji jest taki, że autor by się nie zgodził. Nie chodzi tylko o kompilację, ale o zarządzanie zależnościami zarówno w małych (migawkach kodu), jak i w dużych (dowolnych bibliotekach używanych przez kod).

Wyobraź sobie, że jesteś nowym dev ' em i mówią:, jest to niestandardowa aplikacja php, więc...

A) kod niestandardowy to tak naprawdę dwa podprojekty, które są w repo A i repo B.

B) musisz utworzyć układ katalogu w taki sposób, a następnie

C) sprawdź kod dla każdego podprojektu w tym podkatalogu i tym podkatalogu.

D) będziesz również potrzebował tych trzech bibliotek PHP open source:

Wersja 3.1 Biblioteki Foo, Wersja 2.3 paska bibliotecznego oraz Wersja 5.6 biblioteki Bat.

E) pobierz je z ich stron projektu domowego i rozpakować je, a następnie skopiować je do tego katalogu, tego katalogu i innego katalogu.

F) następnie musisz ustawić te konfiguracje w zewnętrznej bibliotece,

G) i te konfiguracje w naszych dwóch niestandardowych projektach kodu.

H) gdy to wszystko się skończy, tar / gzip to wszystko, wgraj to na serwer QA i rozpakuj do htdocs.

Nie ma kompilacji w tym zestawie kroków, ale można się założyć, że jest dużo budynków.

Skonfigurowanie tego wszystkiego i działanie to krok budowania.

Użycie tar/gzip do zrobienia migawki roboczej kompilacji jest krokiem release.

SCP ' ING/rozpakowanie go do katalogu htdocs serwera QA jest krokiem uruchomieniowym.

Można powiedzieć, że niektóre z powyższych kroków są niepotrzebne - biblioteki powinny być wdrożone na poziomie systemu, a jedynie zaimportowane. Z 12factors.net strony powiedziałbym, że autor woli, aby importować je wyjątkowo i indywidualnie do aplikacji. Pomija problemy z wersjonowaniem zależności kosztem większej ilości miejsca na dysku(nikogo to nie obchodzi). Istnieje więcej kłopotów w zarządzaniu wszystkimi tymi zależnościami jako local-to-the-app, ale to jest punkt schematu build/release / runtime.

 3
Author: Steven J. Owens,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-05-26 01:01:39

Mogło się to zmienić, odkąd to przeczytałeś - jest teraz kilka przykładów PHP, chociaż kilka z nich wydaje się negacjami koncepcji dwunastu czynników.

Jednym ze sposobów, w jaki normalne strony mod_php naruszają 12-factor, jest VII. Wiązanie portów . Z manifestu:

Aplikacja twelve-factor jest całkowicie samodzielna i nie polega na wstrzyknięciu serwera www do środowiska wykonawczego w celu utworzenia usługi sieciowej. Aplikacja internetowa eksportuje HTTP jako usługa poprzez powiązanie z portem i nasłuchiwanie żądań wchodzących na ten port.

Jednak apache / php może być nakłoniony do tego światopoglądu za pomocą czegoś takiego:

Https://gist.github.com/1398498

Nie idealne, ale to działa w większości przypadków. Aby go przetestować, zainstaluj Foremana:

Gem install foreman

Następnie uruchom go w katalogu, do którego sklonowałeś gist:

Foreman start

Then odwiedź

Http://localhost:5000/foo

 2
Author: Erik Kastner,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-11-28 00:01:00

NIE TRAKTUJ TEGO POSTA JAKO ODNIESIENIA, TO ZOSTAŁO NAPISANE W 2011 ROKU, WIELE RZECZY SIĘ ZMIENIŁO OD TEGO CZASU... ŚWIAT PROGRAMOWANIA JEST W CIĄGŁEJ EWOLUCJI. PUNKT WIDZENIA NA ROK 2011 NIEKONIECZNIE JEST NADAL AKTUALNY W 2018 ROKU.

Po prostu przeczytałem kilka linijek każdego punktu i oto moja analiza dokumentu:

  1. Baza kodowa : Każdy, php lub nie powinien mieć bazę kodową nawet dla małych projektów

  2. Dependecies : PHP wykorzystuje biblioteki includes i code, które zawsze powinny być w stanie łatwo portować, po prostu kopiując kod na serwer. Czasami używasz PEAR i jeśli serwer go nie obsługuje, musisz ręcznie skopiować i zainstalować pear. Używam Zend Framework przez większość czasu, więc to tylko kopiowanie kodu frameworka z FTP upload.

  3. Config: często Aplikacje php mają zapisywalny plik konfiguracyjny, w którym przechowujesz konfiguracje. Gdzie przechowujesz to twoja wybór jako programista, ale zwykle znajduje się w katalogu głównym aplikacji lub w folderze Ustawienia/Konfiguracja.

  4. Backing Services : PHP używa backing service przez większość czasu, takich jak MySQL. Inne popularne usługi w zależności od aplikacji to twitter i facebook. Używasz ich API do komunikacji z nimi i przechowywania / pobierania danych do pracy.

  5. Build, release, Run : dotyczy skompilowanego kodu, co nie ma miejsca w PHP. Więc ten punkt nie jest coś, na co musisz spojrzeć.

  6. Processes : HTTP jest bezstanowy i jest obsługiwany, więc zwykle nie masz procesu poza serwerem WWW. Nie jest to do końca prawdą, ponieważ usługa internetowa może być dołączona do aplikacji, z którymi pakietujesz lub tworzysz dla niej. Ale ze względu na standardy, zwykle nie musisz używać procesów w świecie sieci.

  7. Port binding : PHP w ogóle nie stosuje się do wiązania portów, ponieważ nie jest to proces, który łączy się z adres, Apache, NGinx lub Lighttpd robi to za Ciebie. Czytanie #6/7 sprawia, że rozumiem, że strona internetowa nigdy nie może być aplikacją dwunastu czynników.

  8. Concurrency: Ponownie ten punkt traktuje o procesach, które nie mają zastosowania do stron internetowych PHP. Punkt ten dotyczy serwera obsługującego treści.

  9. Disposability: ten punkt omawia jak szybki powinien być proces. Oczywiście, strony internetowe PHP nie są procesem, ale zawsze należy pamiętać, że Twoja strona powinna wykonywać strony tak szybko, jak to możliwe... Zawsze pomyśl o tym bloku lub innym bloku kodu i sprawdź, czy jest on zoptymalizowany.

  10. Parytet Dev / Prod: ten punkt ma kluczowe znaczenie w rozwoju każdej aplikacji. Nigdy nie chcesz mieć dużej przerwy między dwiema wersjami aplikacji lub aktualizacja może stać się kłopotliwe. Ponadto nigdy nie twórz wersji aplikacji dostosowanych do klienta. Zawsze znajdź sposoby, aby umożliwić konfigurację/Dostosowanie aplikacji na poziomie szablonu, dzięki czemu można ją zachować jak najbliżej wszystkich zainstalowanych wersji wszędzie.

  11. Logi : logi są zawsze dobrą rzeczą, pozwalają śledzić proces kodu bez konieczności wyświetlania go na ekranie. Moją ulubioną taktyką jest "tail-f logfile" wewnątrz konsoli Linuksa i spojrzenie na to, co się dzieje, gdy wykonuję mój kod.

  12. Procesy administracyjne: Nie dotyczy, w php nie masz procesów, ale masz strony, które możesz zabezpieczyć nazwami użytkowników i hasła.

 -2
Author: Mathieu Dumoulin,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2018-02-08 14:40:13