Ubuntu 20.04, WSL2, VSCode i Drupal 8 - Naprawianie „gotów”

Microsoft w końcu dostarczył fantastyczne rozwiązanie do tworzenia aplikacji dla systemu Linux w systemie Windows.  Podsystem Windows dla systemu Linux, WSL2, jest dość łatwy do zainstalowania i uruchomienia, zwłaszcza jeśli znasz już system Linux.  Nawet jeśli nie, istnieje wiele bardzo dobrych artykułów na temat uruchamiania i uruchamiania podstawowej instalacji.

Tworzenie aplikacji Linux PHP przy użyciu VSCode w systemie Windows 10 jest tak stabilne i bezproblemowe, jak to tylko możliwe. Mimo to kilka „gotcha”, na które natknąłem się, nie zostało opisanych w żadnym z artykułów, które znalazłem na temat konfigurowania LAMP na Ubuntu i WSL2.

Miałem ograniczone doświadczenie z Linuksem i mocno polegałem na artykułach napisanych przez tych, którzy byli przede mną.  Chociaż udało mi się uzyskać większość drogi, napotkałem kilka problemów z uruchomieniem Drupala 8 bez błędów i debugowaniem działającym w VSCode.  Rozwiązania zostały znalezione w sekcjach komentarzy do pytań zamieszczonych w Internecie. Zajęło to wiele godzin poszukiwań i mam nadzieję uratować ludzi, prezentując rozwiązania, które znalazłem w tym jednym artykule.

Moje środowisko to  Windows 10 20H2, Ubuntu 20.04, PHP 7.3, MariaDB 10.4.17, Drupal 8.9.13, Xdebug 3.02, Windows Terminal, VSCode z Remote - WSL i PHP Debug autorstwa Felixa Beckera.  Używam WSL z Powershell w Terminalu Windows.

Zanim zaczniemy, oto kilka zaleceń, które mogą oszczędzić Twój czas.

Instalowanie i używanie apt-fast zamiast apt może naprawdę przyspieszyć instalacje i aktualizacje.  Tam, gdzie mieszkam, internet ma niską przepustowość i jest wolny, a apt-fast jest znacznie szybszy niż apt.

Możesz „tworzyć kopię zapasową i przywracać” swoją dystrybucję Linuksa za pomocą WSL Export and Import. Jak w przypadku każdego systemu, wskazane jest, aby zawsze utrzymywać bieżącą kopię zapasową.

Mariadb instaluje się dobrze, ale nie można uruchomić ponownie ani uzyskać statusu

Instalacja Mariadb poszła dobrze.  Brak błędów i ostrzeżeń.  Kiedy próbowałem sprawdzić status, pojawił się błąd dotyczący systemu.

$>systemctl status mysql
System nie został uruchomiony z systemem systemd jako systemem init (PID 1). Nie mogę działać.

Powodem tego błędu jest to, że Microsoft nie obsługuje systemd w WSL.  Na szczęście Arkane Systems stworzyło pakiet system-genie, aby umożliwić systemd .  Proponuję dokładnie przeczytać ich stronę internetową przed wypróbowaniem poniższych instrukcji, które zostały zaczerpnięte z tej strony. Istnieją nieco inne instrukcje dla dystrybucji innych niż Ubuntu.

Najpierw musisz zainstalować .Siatka 5.0 czasu pracy

$>szybka aktualizacja sudo apt
$>sudo sudo apt-szybka instalacja -y apt-transport-https
$>szybka aktualizacja sudo apt
$>sudo apt-fast install -y dotnet-sdk-5.0

Następnie musimy skonfigurować repozytorium wsl-transdebian

$>sudo apt-szybka instalacja apt-transport-https
$>wget -O /etc/apt/zaufany.gpg.d/wsl-transdebian.gpg https://arkane-systems.github.io/wsl-transdebian/apt/wsl-transdebian.gpg
$>chmod a+r /etc/apt/zaufany.gpg.d/wsl-transdebian.gpg
$>kot << EOF > /etc/apt/źródła.lista.d/wsl-transdebian.lista
$>deb https://arkane-systems.github.io/wsl-transdebian/apt/bulseye main
$>deb-src https://arkane-systems.github.io/wsl-transdebian/apt/bulseye main
$>apt-szybka aktualizacja

Teraz możemy zainstalować pakiet system-genie.

sudo apt-fast install -y systemd-genie

Wyjdź z powłoki Linux, a następnie wyłącz WSL z powłoki Power

PS C:\Users\UsrName>wsl --shutdown

Uruchom ponownie WSL za pomocą dżina z wiersza polecenia Powershell.

PS C:\Users\UsrName>wsl genie --s

Zobaczysz „Oczekiwanie na systemd… .!!!!!!!!!!!!!!!”.  Pełne załadowanie zajmuje 180 sekund.  Poczekaj, aż się skończy.  Kiedy to zrobisz, twoje nowe okno powłoki powinno wyglądać tak:

Czekam na systemd… !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Upłynął limit czasu oczekiwania, aż systemd przejdzie w stan działania.
Może to wskazywać na błąd konfiguracji systemu.
Próbuję kontynuować.

Potwierdź, że Genie jest zainstalowane i systemd działa:

systemctl status mariadb

Powinieneś otrzymać wyjście statusu dla mariadb.  Zauważ, że systemctl status mysql również działa.

Arkane Systems zaleca zamknięcie sesji WSL genie za pomocą wsl -shutdown.  Spowoduje to zwolnienie całej pamięci używanej przez WSL w systemie Windows.

Drupal instaluje się, ale nie ładuje CSS

Po uruchomieniu podstawowej instalacji Drupala 8 strony nie były sformatowane.  Przeglądanie źródła strony wykazało, że nie ładowano żadnych plików CSS. Zajęło mi dwa dni, aby to rozgryźć, ale krótka historia jest taka, że ​​Drupal zakłada, że ​​apache2 używa katalogu /tmp, ale tak nie jest.  Domyślnie apache2 jest skonfigurowany do korzystania z prywatnego katalogu tmp.  O dziwo wywołanie sys_get_temp_dir() z php return /tmp, ale nie tego używa apache2.  Kiedy Drupal tworzy swoje zoptymalizowane pliki css i js, najpierw próbuje zapisać je w folderze /tmp, a następnie przenosi je do folderu docelowego, zazwyczaj sites/default/files/css i /js. Ale apache2 nie używa /tmp, więc ten proces się nie powiedzie, a żaden z plików css ani js. Odznaczenie zagregowanych plików CSS i JavaScript ominie to, ale wtedy wszystkie pojedyncze pliki css i js zostaną załadowane, więc nie jest to rozwiązanie.

Możesz potwierdzić ten problem /tmp nie jest dostępny za pomocą następującego prostego pliku php. Tworzy plik tmp i wyświetla nazwę pliku.  Początkowo nazwa pliku będzie pusta, ponieważ wywołanie tmpfile() zwraca NULL.  Umieściłem następujący kod w teście.php i wywołałem go z mojej strony, localhost/mysite/test.php

Echo "\n";
Echo "\n";
Echo "\n";
Echo "\n";
Echo "\n";
Echo "

Jeśli wyświetlisz źródło strony \r\n, znajdziesz nowy wiersz w tym ciągu.";
 
Echo "

testowanie

";
$tmpDir = sys_get_temp_dir( );
Echo "

Katalog TMP = '$tmpDir'

";
$plik = tmpfile();
$ścieżka = stream_get_meta_data($file)['uri'];
Echo "

Ścieżka pliku tmp = '$ścieżka'

";
 
Echo "\n";
Echo "\n";
?>
 
Spowodowało to "Ścieżka pliku tmp ="

Znalazłem rozwiązanie tego problemu w komentarzach do pytania Stackoverflow użytkownika One In a Million Apps.  To rozwiązanie zmienia konfigurację Apache2 z PrivateTmp=true na PrivateTmp=false. Zwróć uwagę, że zmiana apache2 na korzystanie z prywatnego katalogu tmp została wykonana ze względów bezpieczeństwa, a większość aplikacji można skonfigurować tak, aby używała innego folderu tmp.  Próbowałem tego z Drupalem, ale nie mogłem go uruchomić. To moja pierwsza próba uruchomienia Drupala na Linuksie i chciałem, aby rzeczy „po prostu działały” na moim laptopie bez troski o bezpieczeństwo.

Najpierw poszukaj pliku zawierającego PrivateTmp, używając tego z katalogu /lib:

%>sudo find / -mount -type f -exec grep -e "PrivateTmp" '' ';' -wydrukować

To dało mi długą listę dopasowań.  Poszukaj tego, który zawiera plik apache2.usługa.  W moim przypadku został znaleziony w /usr/lib/systemd/system/apache2.usługa.  skopiuj ten plik do /etc. informator. Edytuj /etc/apache2.services i zmień PrivateTmp=true na PrivateTmp=false, zapisz i uruchom ponownie usługę Apache2.

systemctl uruchom ponownie Apache2

Ponownie uruchom test.ponownie stronę php i powinieneś wyświetlić plik tmp o nazwie, potwierdzający dostęp do folderu /tmp.

Wyczyść wszystkie pamięci podręczne Drupala i przeładuj strony.  Powinny teraz wyświetlać się poprawnie. Nie wiem dlaczego, ale funkcja Drupal Clear Cache nie zawsze działa u mnie.  Ręczne usuwanie wszystkich plików w sites/default/files/css js, a następnie używanie PhpMyAdmin do opróżniania tabel pamięci podręcznej zawsze działa.

Konfigurowanie debugowania VSCode

Skonfiguruj Xdebuga

Najpierw zainstaluj pakiety Remote - WSL i PHP Debug by Felix Becker w VSCode.

Następnie zainstalowałem Xdebug

sudo apt-szybki php7.3-xdebug

Ta zainstalowana wersja 3.02 Xdebug.

Próbowałem go skonfigurować, postępując zgodnie z wieloma przykładami w Internecie.  Nic nie działało.  Okazuje się, że większość przykładów dotyczy Xdebug 2.x, a te ustawienia konfiguracyjne nie działają już z 3.x

W końcu udało mi się go uruchomić z następującym php.ustawienia ini.

Musiałem dodać następujące elementy do obu /etc/php/7.3/apach2/php.ini i /etc/php/7.3/cli/php.ini w moim systemie.

Możesz znaleźć lokalizację swojego xdebuga.więc przechodząc do pliku katalogu /lib, a następnie uruchamiając

znajdź -nazwa xdebug.więc [xdebug]
zend_extension = ./lib/php/20180731/xdebug.więc
xdebug.start_with_request = wyzwalacz
xdebug.tryb = debugowanie
xdebug.odkryj_host_klienta = 1
xdebug.log = /tmp/xdebug_remote.log
xdebug.port_klienta = 9003

Skonfiguruj VSCode

Zdalne debugowanie w VSCode wykorzystuje uruchomienie.plik json przechowywany w katalogu głównym katalogu projektu w .vscode/uruchom.json.

Możesz stworzyć uruchomienie.json przez interfejs VSCode, ale łatwiej mi go utworzyć ręcznie.  Przejdź do katalogu głównego swojej witryny i utwórz .katalog vscode. Utwórz uruchomienie.json i załaduj go do VSCode.

$>mkdir .vskod
$>cd .vskod
$>dotykowe uruchomienie.json
$>uruchom kod.json

Umieść następujący json w pliku i zapisz go.

// Użyj IntelliSense, aby poznać możliwe atrybuty.
// Najedź, aby wyświetlić opisy istniejących atrybutów.
// Aby uzyskać więcej informacji, odwiedź: https://go.Microsoft.pl/fwlink/?link=830387
"wersja": "0.2.0",
"konfiguracje": [

"name": "Słuchaj XDebug",
"typ": "php",
"żądanie": "uruchom",
„port”: 9003,
"stopOnEntry": prawda,
"log": prawda,
"Odwzorowania ścieżek":

"/var/www/html": "$workspaceRoot"

,

"name": "Uruchom aktualnie otwarty skrypt",
"typ": "php",
"żądanie": "uruchom",
"program": "$plik",
"cwd": "$fileDirname",
„port”: 9003

]

Uwaga pod pathMappings, gdzie mam „/var/www/html”, powinieneś umieścić pełną ścieżkę do katalogu głównego Twojej witryny.

Zamknij VSCode. W wierszu WSL Linux wróć do katalogu głównego witryny i załaduj projekt w VSCode.  Zakładając, że nadal jesteś w .katalog vscode,

$>cd…
$>kod .

Powinno to załadować projekt w VSCode, a po lewej stronie powinno być widoczne pełne drzewo katalogów projektu.  Otwórz swoją stronę startową, taką jak indeks.php i dodaj punkt przerwania.  Naciśnij klawisz F5, aby rozpocząć debugowanie.  Przejdź do przeglądarki internetowej i załaduj stronę. Przełącz się z powrotem na VSCode i powinieneś zobaczyć, że zatrzymało się w punkcie przerwania.

Kod nie działa z powłoką zsh

Domyślnie WSL jest skonfigurowany do pracy z powłoką Bash i widzi ścieżkę do pliku wykonywalnego VSCode w PATH.  Przełączyłem się na zsh, a VSCode już nie działał.  Poprawka polegała na wstawieniu aliasu w .zshrc

$>cd ~
$>kod .zshrc

Dodaj następujący alias, który wskazuje pełną ścieżkę do folderu z kodem wykonywalnym, jak widać w Ubuntu w WSL.  Zastąp YourUserName swoją rzeczywistą nazwą użytkownika Windows.

alias code="/mnt/c/Users/NazwaUżytkownika/AppData/Local/Programs/Microsoft\ VS\ Code/bin/code"

Teraz musisz ponownie załadować konfigurację zsh za pomocą

$>źródło .zshrc

Kod powinien się teraz załadować z powłoki zsh.

Otóż ​​to!!  Te kroki w końcu sprawiły, że debugowanie Drupala i VSCode działa poprawnie u mnie.  Zajęło mi dwa dni, aby to wszystko rozgryźć. jestem noobem! Mam nadzieję, że to działa i zaoszczędzi trochę czasu some.

Tylko przypomnienie mojego otoczenia.  Windows 10 20H2, Ubuntu 20.04, PHP 7.3, MariaDB 10.4.17, Drupal 8.9.13, Xdebug 3.02, Windows Terminal, VSCode z Remote - WSL i PHP Debug autorstwa Felixa Beckera.

Szczęśliwego kodowania!