1 kwietnia na blogu firmy Cloudflare pojawił się wpis dotyczący systemu CMS EmDash, którego kod w tym dniu został również opublikowany w repozytorium w serwisie GitHub. EmDash jest określany jako „duchowy następca” znanego każdemu systemu WordPress. Już na wstępie trzeba przyznać, że sama architektura opisywanego rozwiązania zdecydowane lepiej odpowiada współczesnym standardom tworzenia aplikacji.
Przede wszystkim EmDash został oparty o dość popularny framework Astro – mamy więc do czynienia z samym kodem JavaScript, zamiast PHP/JavaScript jak w przypadku WordPress. Oprócz aspektów powiązanych stricte z tworzeniem oprogramowania w Node.js, oznacza to też konieczność odmiennego podejścia do wdrożenia tak przygotowanych serwisów. Dla Node.js nie wystarczy typowy hosting, gdzie w konkretnym katalogu umieszczamy (np. poprzez SFTP, pobranie i rozpakowanie archiwum poprzez SSH, czy też z użyciem CI/CD) kod naszej witryny, co w większości typowych sytuacji oznacza koniec prac „technicznych”.
Projekty tworzone w Node.js zwykle posiadają funkcjonalność serwera, który łatwo możemy uruchomić, co udostępni możliwość korzystania z aplikacji z poziomu localhost. Jest to z reguły w pełni wystarczające dla celów programistycznych – tym bardziej że niejednokrotnie wprowadzane zmiany w kodzie są dynamicznie przeładowywane przez serwer. Natomiast samo uruchomienie takiego serwera w środowisku produkcyjnym nie będzie szczególnie profesjonalnym sposobem – chociaż oczywiście aplikacja powinna działać poprawnie. Tutaj zalecane jest korzystanie z rozwiązań typu pm2 czy dodanie usługi systemd w celu zarządzania stanem aplikacji.
Dodatkowo wbudowany serwer uruchomi się na lokalnym porcie. Nie udostępnimy w ten sposób serwisu „na zewnątrz”. Konieczne jest więc zastosowanie reverse proxy, np. za pomocą serwera nginx – jest to absolutnie standardowe podejście dla podobnych aplikacji. Większość współczesnych hostingów umożliwia wykonanie obu tych operacji (zapewnia dostęp SSH, a konfigurację reverse proxy możemy przeprowadzić poprzez panel zarządzania), więc nie powinniśmy napotkać żadnych trudności związanych z ewentualną migracją naszych serwisów na EmDash czy też inne systemy CMS napisane w JavaScript.
Nie można zapomnieć o konteneryzacji. W tym wypadku całość procesu budowy i wdrożenia możemy w dość łatwy sposób zautomatyzować. Zwykły hosting nie pozwoli na korzystanie z Docker, natomiast nic nie stoi na przeszkodzie, aby wykorzystać własny serwer VPS – instalacja Docker, dodanie reverse proxy czy konfiguracja domeny nie są skomplikowanymi czynnościami.
EmDash ma stanowić rozwiązanie problemu bezpieczeństwa korzystania z pluginów dostępnych w systemie WordPress. Popularność tego systemu skutkuje ogromną ilością wtyczek do różnych zastosowań – od dodania prostych funkcji po zaawansowane modyfikacje kodu. Jest to łatwy cel dla różnych cyberprzestępców, bo mniej techniczne osoby raczej nie zweryfikują kodu źródłowego. Poza tym nie można się spodziewać, że takie osoby będą instalować wtyczki w inny sposób, niż ten dostępny w Kokpicie. Często wystarczy dodanie pluginu, który miałby zapewniać pewną „interesującą” funkcję, co już doprowadzi do masowych instalacji. Zdarzały się też historie zakupu znanych i całkowicie bezpiecznych pluginów przez atakujących – po prostu nowa aktualizacja dodawała „funkcje”, na których im zależało.
I co bardzo istotne, wtyczki w WordPress nie są ograniczone do konkretnego katalogu – bez żadnych trudności mogą odczytywać pliki konfiguracyjne, takie jak wp-config.php, gdzie zapisane są dostępy do bazy danych, a także (ewentualnie) poświadczenia do zewnętrznych usług. Kradzież podobnych dostępów i ich nieautoryzowane wykorzystanie może mieć tragiczne skutki. Dodatkowo przy założeniu, że konfiguracja serwera nie ogranicza dostępu do pewnych wrażliwych katalogów (chociażby poprzez użycie chroot), to złośliwa wtyczka może też odczytać ustawienia znanych usług.
Koncepcja obsługi pluginów w EmDash zakłada użycie usługi Cloudflare Workers (więc nie dotyczy deploymentów realizowanych na zarządzanych przez na środowiskach), dzięki czemu pluginy będą uruchamiane w całkowicie izolowanym środowisku wyłącznie z uprawnieniami, jakie zostaną zdefiniowane. Można to porównać do uruchamiania każdej wtyczki WordPress w osobnym kontenerze Docker – wydaje mi się jednak, że architektura EmDash nie wymaga, aby pluginy posiadały dostęp do „core” systemu.
Inna kluczowa różnica względem WordPress, ale też innych podobnych narzędzi, polega na wymaganiu korzystaniu z kluczy sprzętowych i/lub passkey (jeśli posiadamy już konto, to zadziała także logowanie poprzez Google czy Microsoft 365). To dość śmiały krok, który jednak realnie podnosi bezpieczeństwo, bo powszechnie wiadomo, że same hasła nie stanowią już wystarczającego zabezpieczenia. Dla środowisk deweloperskich możliwe jest obejście (po wejściu na /_emdash/api/setup/dev-bypass zostaniemy zalogowani), więc nawet jeśli nie możemy użyć wymaganych metod logowania, to wciąż istnieje sposobność na zapoznanie się z systemem EmDash czy realizację prac programistycznych.
Możliwa jest poza tym migracja istniejącego serwisu zbudowanego z użyciem WordPress. Wymagana w tym celu jest instalacja wtyczki emdash-exporter i wygenerowanie hasła aplikacji bądź przeprowadzenie importu witryny i przesłanie pliku XML poprzez panel EmDash. Zalecane jest użycie pierwszej wymienionej opcji, bo pozwala na dokładniejsze „rozeznanie się” w aktualnej strukturze serwisu przez plugin. Całość procesu przeprowadzamy w panelu.
EmDash ma szanse na powodzenie z uwagi na ścisłe powiązanie z Cloudflare. Nie można powiedzieć, że to kolejny projekt mający być alternatywą dla WordPress, który zakończy się za 6 miesięcy. W tym przypadku projekt ma zapewnione finansowanie, jak również pewną „gwarancję” jakości.
Nie wyobrażam sobie nagłego spadku udziału WordPress na rynku rozwiązań CMS. Aktualnie WordPress odpowiada za obsługę 40% wszystkich serwisów dostępnych w Internecie. Prostota instalacji i konfiguracji pod typowe zastosowania, brak dużych wymagań co do środowiska, ale też brak kosztów (z wyłączeniem niektórych wtyczek czy motywów) przez lata stanowiły o rozpoznawalności i uznaniu tego systemu. Nie oznacza to jednak, że WordPress pozostał dostosowany do współczesnych trendów w obszarze aplikacji internetowych – to samo dotyczy języka PHP.
Obecnie niemal podstawową technologią stosowaną do uruchomienia aplikacji jest Docker, gdzie ważne jest zachowanie minimalizacji w budowanych obrazach. Node.js do uruchomienia wymaga jednego obrazu bazowego, w którym umieszczamy kod, budujemy aplikację i ostatecznie uruchamiamy – podobnie wygląda to w przypadku Java czy Python. Wykonanie kodu PHP wymaga serwera HTTP oraz interpretera PHP (w praktyce z rozszerzeniami, których kompilacja też zajmuje czas) wraz z konfiguracjami (vhost, php.ini itd.). Ostatecznie otrzymujemy obraz o rozmiarze zbliżonym do 1.5 GB, którego złożoność może okazać się porównywalna z „tradycyjną” konfiguracją serwera HTTP. Nie jest to język tak przyjazny w konteneryzacji jak inne.
