Skip to content

Wszystko o WordPressie, tworzeniu stron — i nie tylko

🛠 Zdalne tworzenie WordPress z VS Code na Amazon EC2

🛠 Zdalne tworzenie WordPress z VS Code na Amazon EC2

Czy zdarzyło się Panu/Pani stracić dzień na uruchamianie lokalnego stosu WordPress, który i tak zachowuje się inaczej niż serwer produkcyjny? XAMPP, Docker, maszyny wirtualne, każda opcja psuje się w najmniej odpowiednim momencie: raz wersja PHP jest nieodpowiednia, raz brakuje rozszerzenia, a raz klient otwiera stronę i widzi biały ekran, którego lokalnie Pan/Pani nie ma.

Visual Studio Code potrafi łączyć się ze zdalnym serwerem przez SSH równie łatwo, jak otwiera Pan/Pani folder na swoim laptopie. Żadnej magii, kod leci prosto na instancję Amazon EC2, gdzie działa już pełnoprawny serwer WWW z WordPress.

Poniżej znajduje się konfiguracja krok po kroku zestawu VS Code + AWS EC2 do tworzenia wtyczek i motywów WordPress. Od utworzenia użytkownika Linux po zapisanie obszaru roboczego, bez luk i z wyjaśnieniem każdego kroku.

💡 Szybki przegląd:

  • Tworzymy użytkownika sudo na serwerze Ubuntu i konfigurujemy klucze SSH
  • Przygotowujemy klienta Windows: OpenSSH, plik konfiguracyjny i klucz prywatny
  • Łączymy VS Code z serwerem przez Remote-SSH i otwieramy folder WordPress
  • Zapisujemy obszar roboczy, aby szybko wrócić do projektu

Wymagania wstępne

Zanim skonfiguruje Pan/Pani zdalne środowisko programistyczne, proszę upewnić się, że część serwerowa jest gotowa. Zakładam, że korzysta Pan/Pani z Windows 10 lub nowszego i dopiero zaczyna poznawać infrastrukturę chmurową. Proszę pominąć te punkty, które zostały już zrealizowane.

Instancja Amazon EC2 z Ubuntu i OpenLiteSpeed

Korzystamy z obrazu Amazon Machine Image opartego na Ubuntu z serwerem WWW OpenLiteSpeed i pełnym stosem LAMP zoptymalizowanym pod WordPress. Jeśli serwer nie został jeszcze uruchomiony, minimalne wymagania to: Ubuntu 20.04 lub 22.04 LTS i co najmniej 2 GB pamięci RAM. Przy mniej niż 2 GB composer i wp-cli będą padać z błędem braku pamięci na średnich projektach.

Użytkownik Linux z sudo

Dostęp root do codziennej pracy nie jest potrzebny i jest niebezpieczny. Proszę utworzyć zwykłego użytkownika z uprawnieniami sudo. DigitalOcean wyjaśnia ten proces w swoim poradniku. W skrócie, dwie komendy z konta root lub z prefiksem sudo:

1adduser example

Proszę wprowadzić hasło dwukrotnie, na pozostałe pytania można po prostu nacisnąć Enter. Następnie proszę dodać użytkownika do grupy sudo:

1usermod -aG sudo example

Para kluczy dla SSH

Dostęp SSH opiera się na parze kluczy. Klucz prywatny (plik bez rozszerzenia lub .pem) przechowuje Pan/Pani na swoim komputerze z Windows. Klucz publiczny (plik .pub) znajduje się na serwerze na liście autoryzowanych. Wygenerujmy parę bezpośrednio na serwerze:

1su - example
2mkdir .ssh
3chmod 700 .ssh
4touch .ssh/authorized_keys
5chmod 600 .ssh/authorized_keys
6ssh-keygen

Na zapytania ssh-keygen proszę trzykrotnie nacisnąć Enter (puste hasło dla klucza, w naszym scenariuszu nie jest potrzebne). Teraz proszę dodać klucz publiczny do listy autoryzowanych i wyświetlić klucz prywatny na ekranie:

1cat .ssh/id_rsa.pub >> .ssh/authorized_keys
2cat .ssh/id_rsa

Zobaczą Państwo blok o takim wyglądzie:

1-----BEGIN RSA PRIVATE KEY-----
2...
3-----END RSA PRIVATE KEY-----

Proszę skopiować całą zawartość (włącznie z liniami ograniczającymi) i zapisać ją w pliku tekstowym na swoim komputerze. Ścieżka może wyglądać następująco:

1C:\Users\Example\.ssh\aws-example-user.pem

Nazwa pliku jest dowolna. Folder .ssh proszę utworzyć wewnątrz swojego profilu Windows, w tym samym miejscu, gdzie znajduje się plik konfiguracyjny z następnego kroku.

Plik konfiguracyjny SSH dla Visual Studio Code

VS Code odczytuje ustawienia połączenia ze standardowego konfigu SSH. Proszę utworzyć plik tekstowy bez rozszerzenia o nazwie config w folderze C:\Users\Example\.ssh\ z następującą zawartością (więcej o formacie w man ssh_config):

1Host aws-ec2
2 HostName your-server-ip-or-domain.com
3 User example
4 IdentityFile C:\Users\Example\.ssh\aws-example-user.pem

Objaśnienie dyrektyw:

  • Host, dowolna nazwa wyświetlana w VS Code (tytuł okna i wskaźnik połączenia w lewym dolnym rogu);
  • HostName, adres IP lub domena Państwa instancji EC2;
  • User, nazwa użytkownika Ubuntu utworzonego powyżej;
  • IdentityFile, ścieżka bezwzględna do klucza prywatnego na maszynie z Windows.

Klient OpenSSH w Windows

Windows 10 i 11 mają wbudowanego klienta SSH, ale domyślnie może być nieaktywny. Proszę otworzyć „Ustawienia" → „Aplikacje" → „Funkcje dodatkowe" → „Dodaj funkcję". Proszę znaleźć na liście OpenSSH Client i kliknąć „Zainstaluj".

Instalacja klienta OpenSSH w składnikach dodatkowych systemu Windows

Visual Studio Code i rozszerzenie Remote Development

Proszę pobrać VS Code, odpowiednia będzie zarówno wersja stabilna (niebieska ikona), jak i edycja Insiders (zielona ikona, częstsze aktualizacje). Dla programowania zdalnego nie ma to znaczenia.

Zaraz po instalacji proszę dodać pakiet rozszerzeń Remote Development od Microsoft. W skład pakietu wchodzą trzy rozszerzenia. Dwa z nich, Remote, Containers i WSL, można wyłączyć, do naszego zadania nie są potrzebne. Proszę pozostawić tylko Remote, SSH.

Konfiguracja programowania zdalnego

Łączenie z serwerem

Wybór polecenia Remote-SSH Connect to Host w palecie poleceń VS Code
  • Proszę nacisnąć F1 lub kliknąć ciemnopomarańczowy przycisk w lewym dolnym rogu okna.
  • Proszę zacząć wpisywać Remote-SSH, pojawi się podpowiedź Remote-SSH: Connect to Host…. Proszę ją wybrać i nacisnąć Enter.
  • Z rozwijanej listy proszę wybrać nazwę podaną w dyrektywie Host pliku konfiguracyjnego, na przykład SSH: aws-ec2. VS Code pobiera listę hostów bezpośrednio z Państwa pliku config.
  • Gotowe, są Państwo połączeni. Otworzy się nowe okno; stare można zamknąć.

Połączenie nie spowalnia pracy, edytor działa szybko, ponieważ przez sieć przesyłane są tylko zmiany plików, a nie cały interfejs.

Wskaźnik połączenia SSH aws-ec2 w lewym dolnym rogu okna VS Code

Tworzenie obszaru roboczego

  • Proszę otworzyć panel File → Open Folder… (lub nacisnąć Ctrl+K, potem Ctrl+O, klawisze naciska się sekwencyjnie, nie jednocześnie).
  • W oknie eksploratora proszę przejść do katalogu głównego WordPressa, na przykład /var/www/example.com/. Można wkleić ścieżkę ręcznie i nacisnąć OK.

W lewym panelu „Explorer" pojawią się wszystkie pliki WordPressa. Aby dodać do obszaru roboczego inne katalogi serwera (na przykład katalog innej wtyczki lub motywu), proszę użyć polecenia File → Add Folder to Workspace….

Drzewo plików WordPress w panelu bocznym VS Code po połączeniu z serwerem

Pozostaje zapisać ten widok jako obszar roboczy, aby wracać do projektu jednym kliknięciem:

  • Proszę nacisnąć F1, zacząć wpisywać save work i wybrać Workspaces: Save Workspace As….
  • Proszę zapisać plik pod nazwą wp.code-workspace w dogodnym miejscu na serwerze (rozszerzenie .code-workspace zostanie dodane automatycznie).
  • Po zamknięciu i ponownym otwarciu VS Code obszar roboczy pojawi się w sekcji File → Recent lub załaduje się automatycznie, jeśli był ostatnio używany.

Do przełączania między kilkoma obszarami proszę użyć F1open work → wybór z listy.

Zapisane środowisko robocze wp.code-workspace na liście ostatnich projektów VS Code

Dowiązanie symboliczne (opcjonalnie)

Jeśli rozwijają Państwo konkretną wtyczkę, wygodnie jest przenieść jej pliki źródłowe do katalogu domowego użytkownika i podlinkować je wewnątrz WordPressa:

1ln -s /home/example/wp /var/www/dev.example.com/wp-content/plugins/my-plugin

Lewa ścieżka, rzeczywisty katalog z projektem, prawa, dowiązanie symboliczne wewnątrz wp-content/plugins. Takie rozwiązanie izoluje kod wtyczki od rdzenia WordPressa i ułatwia wersjonowanie.

⁉️🤔 Często zadawane pytania

Czy koniecznie trzeba używać Amazon EC2, czy wystarczy inny VPS?

Sprawdzi się dowolny serwer z Ubuntu i dostępem SSH. DigitalOcean, Linode, Vultr, Hetzner, zasada konfiguracji jest identyczna. Jedyny wymóg: co najmniej 2 GB RAM do komfortowej pracy WordPressa z debugowaniem. Na hostingu współdzielonym to podejście nie zadziała, potrzebny jest dostęp root lub sudo. VS Code Remote SSH nie jest powiązany z konkretnym dostawcą chmury: może Pan/Pani połączyć się z dowolną maszyną, na której działa sshd, nawet z Raspberry Pi w sieci lokalnej. Różnica polega wyłącznie na opóźnieniu: im bliżej znajduje się centrum danych, tym szybciej reaguje edytor.

Czy muszę płacić za transfer danych podczas pracy przez VS Code Remote SSH?

Transfer jest minimalny. VS Code przesyła przez SSH wyłącznie zmiany w plikach i polecenia terminala, nie są przesyłane tam i z powrotem ani piksele interfejsu, ani pliki binarne rozszerzeń. Typowy dzień pracy deweloperskiej zamyka się w dziesiątkach megabajtów. Rozszerzenia (w tym sam Remote-SSH) są instalowane na serwerze jednorazowo podczas pierwszego połączenia, to kilkaset megabajtów jednorazowo. Jeśli ma Pan/Pani sztywny limit transferu, proszę wyłączyć automatyczne aktualizacje rozszerzeń na zdalnym hoście przez F1 → Preferences: Configure Runtime Arguments i dodać "remote.extensionDownloader.enabled": false. Jednak dla zdecydowanej większości użytkowników jest to zbędne.

Czy można pracować na serwerze zdalnym z tabletu lub telefonu?

Formalnie tak, przez VS Code for the Web w przeglądarce, ale z zastrzeżeniami. Wersja przeglądarkowa nie obsługuje Remote SSH bezpośrednio. Obejście: uruchomić VS Code Server na instancji (to osobny produkt, proszę nie mylić z Remote SSH) i łączyć się z nim z przeglądarki. Dla tabletu z klawiaturą jest to scenariusz roboczy, dla telefonu, raczej egzotyka. Praktyczniej jest nosić lekki laptop lub Chromebook z podsystemem Linux: całe obciążenie obliczeniowe pozostaje na serwerze, klient zużywa minimum zasobów.

Co zrobić, gdy połączenie jest zrywane podczas dłuższej bezczynności?

Proszę skonfigurować keepalive w swoim pliku konfiguracyjnym SSH. W pliku C:\Users\Example\.ssh\config należy dodać dwa wiersze w sekcji danego hosta: ServerAliveInterval 60 i ServerAliveCountMax 5. Klient będzie wysyłał pakiet keepalive co 60 sekund i utrzyma połączenie do pięciu utraconych pakietów z rzędu, połączenie przetrwa do 5 minut całkowitej ciszy w sieci. Alternatywa: uruchomić tmux lub screen na serwerze dla długotrwałych procesów, aby nie stracić sesji terminala podczas rozłączenia.

Czy bezpiecznie jest przechowywać klucz prywatny w postaci jawnej na maszynie z Windows?

Plik .pem bez hasła, tak, to zwykły ciąg znaków, który może odczytać każdy, kto ma dostęp do Pana/Pani konta Windows. Środki ochrony według rosnącego poziomu bezpieczeństwa: (1) proszę ustawić hasło podczas tworzenia klucza (ssh-keygen zapyta o nie, nie należy naciskać Enter, tylko wprowadzić hasło); (2) przechowywać klucz w zaszyfrowanym wolumenie (BitLocker jest domyślnie włączony w Windows 11 Pro); (3) w środowisku produkcyjnym używać agenta SSH ze sprzętowym kluczem (YubiKey). Dla środowiska deweloperskiego rozwiązaniem kompromisowym jest klucz z hasłem: VS Code zapamięta je na czas sesji, trzeba będzie je wprowadzać raz dziennie, za to klucz jest bezużyteczny bez hasła, nawet jeśli plik wycieknie.

Co wybrać do codziennej pracy: Remote SSH czy stos lokalny

Remote SSH przez VS Code nie jest srebrną kulą. Jeśli pisze Pan/Pani wtyczkę, która potrzebuje tylko wp-cli i testów jednostkowych, lokalny Docker z wordpress-develop zbuduje się w minutę i nie wymaga internetu. Jeśli jednak debuguje Pan/Pani integrację z zewnętrznym API, sprawdza kompatybilność międzyprzeglądarkową lub pokazuje postęp klientowi, serwer zdalny ze środowiskiem produkcyjnym sprawdza się znakomicie.

W podejściu hybrydowym warto trzymać instancję deweloperską EC2 włączoną na stałe (t3.small z rezerwacją kosztuje akceptowalnie) i łączyć się z nią kiedykolwiek i skądkolwiek. Kod znajduje się na serwerze, automatyczne kopie zapasowe są włączone, a Pan/Pani nie jest przywiązany/a do konkretnej maszyny. Proszę spróbować: po tygodniu zdalnej pracy deweloperskiej nie będzie Pan/Pani chciał/a wracać do XAMPP.