Etap 3: Od zera do produkcji

5.0 version
Maintained

Od zera do produkcji

Lubię działać szybko. Chcę, żeby nasz mały projekt był gotowy jak najszybciej. Teraz. Na produkcji. Ponieważ jeszcze niczego nie opracowaliśmy, zaczniemy od uruchomienia ładnej i prostej strony „W budowie”. Spodoba Ci się to!

Spędź trochę czasu wyszukując idealny, staromodny i animowany GIF „W budowie” w Internecie. Ja zamierzam użyć tego:

../_images/under-construction.gif

Mówiłem Ci, że będzie fajnie.

Inicjalizacja projektu

Stwórz nowy projekt Symfony za pomocą narzędzia symfony CLI, które wcześniej wspólnie zainstalowaliśmy:

1
2
$ symfony new guestbook --version=5.0
$ cd guestbook

Ta komenda opakowuje (ang. wrap) narzędzie Composer, które ułatwia tworzenie projektów Symfony. Wykorzystuje szkielet projektu, który zawiera minimalną liczbę zależności - komponenty Symfony, które są potrzebne w prawie każdym projekcie: narzędzie konsolowe i abstrakcję HTTP potrzebną do tworzenia aplikacji internetowych.

Jeśli spojrzysz na repozytorium GitHub szkieletu, zauważysz, że jest prawie puste. Zawiera tylko plik composer.json, ale katalog guestbook jest pełen plików. Jak to w ogóle możliwe? Odpowiedź znajduje się w pakiecie symfony/flex. Symfony Flex jest wtyczką narzędzia Composer, która podpina się do procesu instalacji. Kiedy wykryje pakiet, na który ma przepis (ang. recipe), wykonuje go.

Kluczowym elementem Symfony Recipe jest plik manifestu, który zawiera operacje pozwalające automatycznie zarejestrować pakiet w aplikacji Symfony. Nie musisz czytać pliku README, aby zainstalować pakiet przy pomocy Symfony. Automatyzacja jest kluczową cechą Symfony.

Jako że Git jest zainstalowany na naszej maszynie, polecenie symfony new stworzyło dla nas również repozytorium Git i dokonało pierwszego zatwierdzenia (ang. commit).

Przyjrzyj się strukturze katalogów:

1
2
3
4
5
6
7
8
9
├── bin/
├── composer.json
├── composer.lock
├── config/
├── public/
├── src/
├── symfony.lock
├── var/
└── vendor/

Katalog bin/ zawiera kluczowy program CLI: console. Będziesz z niego korzystać przez cały czas.

Katalog config/ składa się z zestawu domyślnych plików konfiguracyjnych. Jeden plik na pakiet. Będziesz je modyfikować w niewielkim stopniu - ufanie domyślnym ustawieniom jest prawie zawsze dobrym pomysłem.

Katalog public/ jest katalogiem publicznym, a skrypt index.php jest głównym punktem wejścia dla wszystkich dynamicznych zasobów HTTP.

Katalog src/ zawiera cały kod, który napiszesz; tam spędzisz większość czasu. Domyślnie wszystkie klasy PHP w tym katalogu korzystają z przestrzeni nazw App. To jest Twój dom. Twój kod. Logika Twojej domeny. Symfony ma tam bardzo mało do powiedzenia.

Katalog var/ zawiera pamięć podręczną, logi i pliki generowane podczas uruchamiania aplikacji. Możesz zostawić je w spokoju. Jest to jedyny katalog, który musi mieć prawa zapisu na produkcji.

Katalog vendor/ zawiera wszystkie pakiety zainstalowane przez narzędzie Composer, włącznie z samym Symfony. To nasza tajna broń, by być bardziej produktywnym. Nie wymyślajmy koła na nowo. Będziesz korzystał z istniejących bibliotek, aby wykonać żmudną pracę. Nie ruszaj tego katalogu - zarządza nim Composer.

To wszystko, co musisz na razie wiedzieć.

Tworzenie zasobów publicznych

Wszystko wewnątrz katalogu public/ jest dostępne przez przeglądarkę. Na przykład, jeśli przeniesiesz animowany plik GIF (nazwijmy go under-construction.gif) do nowego katalogu public/images/, będzie on dostępny pod adresem URL: https://localhost/images/under-construction.gif.

Pobierz mój obrazek GIF tutaj:

1
2
$ mkdir public/images/
$ php -r "copy('http://clipartmag.com/images/website-under-construction-image-6.gif', 'public/images/under-construction.gif');"

Uruchomienie lokalnego serwera WWW

symfony CLI jest dostarczany z serwerem WWW, który jest zoptymalizowany pod kątem pracy programistycznej. Nie zaskoczę Cię mówiąc, że współpracuje dobrze z Symfony. Nigdy jednak nie używaj go w środowisku produkcyjnym.

Z katalogu projektu, uruchom serwer WWW w tle (flaga -d):

1
$ symfony server:start -d

Serwer rozpoczął pracę na pierwszym dostępnym porcie, zaczynając od 8000. Jako skrót, otwórz stronę internetową w przeglądarce z CLI:

1
$ symfony open:local

Teraz, Twoja ulubiona przeglądarka powinna otworzyć nową kartę, na której wyświetla się coś podobnego do poniższego rysunku:

Wskazówka

Aby rozwiązywać problemy, uruchom komendę symfony server:log; śledzi ona logi z serwera WWW, PHP i Twojej aplikacji.

Przejdź do /images/under-construction.gif. Czy wygląda w ten sposób?

Dobrze? Zatwierdźmy więc (ang. commit) naszą pracę:

1
2
$ git add public/images
$ git commit -m'Add the under construction image'

Dodawanie favicony

Aby uniknąć bycia „spamowanym” przez błędy HTTP 404 w logach z powodu brakującej favicony wymaganej przez przeglądarki, dodajmy jedną teraz:

1
2
3
$ php -r "copy('https://symfony.com/favicon.ico', 'public/favicon.ico');"
$ git add public/
$ git commit -m'Add a favicon'

Przygotowanie do wdrożenia dla środowiska produkcyjnego

A co z wdrożeniem naszej pracy w środowisku produkcyjnym? Wiem, że nie mamy jeszcze nawet odpowiedniej strony HTML, aby powitać naszych gości, ale możliwość zobaczenia małego obrazka „w budowie” na serwerze produkcyjnym byłaby wielkim krokiem naprzód. I znasz motto: „Wdrażaj wcześnie i często”.

Możesz umieścić tę aplikację na hostingu dowolnego dostawcy wspierającego PHP… co oznacza prawie wszystkich dostępnych dostawców usług hostingowych. Sprawdź jednak kilka rzeczy: chcemy mieć najnowszą wersję PHP i możliwość hostowania usług takich jak baza danych, kolejka itp.

Ja wybrałem SymfonyCloud. Dostarcza nam wszystkiego, czego potrzebujemy, i pomaga finansować rozwój Symfony.

symfony CLI ma wbudowane wsparcie dla SymfonyCloud. Zainicjujmy projekt SymfonyCloud:

1
$ symfony project:init

Polecenie to tworzy kilka plików wymaganych przez SymfonyCloud, a mianowicie .symfony/services.yaml, .symfony/routes.yaml i .symfony.cloud.yaml.

Dodaj je do Gita i zatwierdź (ang. commit):

1
2
$ git add .
$ git commit -m"Add SymfonyCloud configuration"

Informacja

Używanie ogólnego i niebezpiecznego git add . działa poprawnie, ponieważ wygenerowany został plik .gitignore, który automatycznie wyklucza wszystkie pliki, których nie chcemy zatwierdzić (ang. commit).

Idziemy na produkcję

Wdrażamy?

Stwórz nowy projekt SymfonyCloud:

1
$ symfony project:create --title="Guestbook" --plan=development

To polecenie wykonuje szereg operacji:

  • Uwierzytelnia Cię przy jego pierwszym uruchomieniu, używając danych do logowania serwisu SymfonyConnect.
  • Tworzy nowy projekt na SymfonyCloud. Hosting projektu rozwojowego (ang. development project) na platformie SymfonyCloud jest bezpłatny przez pierwsze 7 dni.

Zatem wdrażajmy:

1
$ symfony deploy

Kod jest wdrażany przez wysyłanie zmian (ang. push) do repozytorium Git. Po wykonaniu polecenia zostanie zwrócona nazwa domeny, którą możesz wykorzystać, aby uzyskać dostęp do wdrożonego projektu.

Sprawdź, czy wszystko poszło dobrze:

1
$ symfony open:remote

Powinna pojawić się strona błędu 404, ale przejście pod adres: /images/under-construction.gif powinno pokazać, co do tej pory zrobiliśmy.

Zauważ, że nie otrzymujesz pięknej, domyślnej strony Symfony na SymfonyCloud. Dlaczego? Wkrótce dowiesz się, że Symfony obsługuje kilka środowisk i SymfonyCloud automatycznie wdrożył kod w środowisku produkcyjnym.

Wskazówka

Jeśli chcesz usunąć projekt na SymfonyCloud, użyj polecenia project:delete.


This work, including the code samples, is licensed under a Creative Commons BY-NC-SA 4.0 license.