Aktualizacja Plesk Obsidian: nowe funkcje dla dostawców usług hostingowych

Dokładne rozdzielenie wersji i komponentów

Zgodnie z udokumentowanym stanem na dzień 2 października 2026 r. dla Produkt podstawowy Plesk Obsidian 18.0.81, aktualizacja 2. Ta aktualizacja została wydana 29 września 2026 r. i usuwa krytyczną lukę w zabezpieczeniach. Nowe funkcje panelu opisane w tym artykule są częścią wydania Plesk Obsidian 18.0.81 z 15 września 2026 r.; natomiast aktualizacja 1 i aktualizacja 2 zawierają udokumentowane poprawki błędów i zabezpieczeń.

Mogą jednak pojawić się późniejsze aktualizacje, które nie zmieniają podstawowej wersji 18.0.81 Update 2: W dzienniku zmian wymieniono na przykład aktualizacje rozszerzeń, takich jak SSL It! i Let’s Encrypt z 29 września, a także aktualizacje pakietów PHP z 30 września 2026 r. Kto mówi jedynie o „aktualnej wersji Plesk“, pomija zatem informację istotną dla planowania i wsparcia technicznego.

Plesk rozróżnia kilka poziomów aktualizacji. Pakiety Plesk obejmują sam panel oraz funkcje bezpośrednio z nim związane. Oprócz tego dostępne są pakiety usług i rozszerzenia udostępniane przez Plesk, które zapewniają dodatkowe możliwości lub umożliwiają integrację z usługami zewnętrznymi. Nowy numer wersji rozszerzenia nie oznacza zatem, że rdzeń Plesk również został zaktualizowany – i odwrotnie.

Ponadto każda Panel hostingowy w ramach systemu operacyjnego istnieją kolejne poziomy: pakiety systemu operacyjnego oraz komponenty innych producentów, takie jak bazy danych, środowiska uruchomieniowe PHP, serwery WWW i usługi pocztowe. Ich źródła pakietów, cykle wsparcia technicznego i zależności niekoniecznie pokrywają się z harmonogramem wydawania aktualizacji Plesk. Dla dostawcy usług ten podział ma znaczenie praktyczne, ponieważ rodzaje błędów, okna serwisowe i zakresy odpowiedzialności mogą się różnić w zależności od danego komponentu.

W dokumentacji stanu należy zatem zawsze podawać konkretną kombinację: wersję Plesk wraz z numerem aktualizacji, wersję zainstalowanego rozszerzenia, system operacyjny oraz odpowiednie pakiety środowiska uruchomieniowego. W przypadku funkcji związanych z certyfikatami lub aplikacjami należy również uwzględnić zastosowaną integrację. Dzięki temu można na przykład ustalić, czy zmiana pochodzi z SSL It!, integracji Let’s Encrypt czy z rdzenia panelu. Zapobiega to niejasnym oczekiwaniom w komunikatach skierowanych do klientów i ułatwia zawężanie zakresu problemu podczas obsługi technicznej.

Jak aktualizacje Plesk wpływają na dostawców

W ramach linii Obsidian 18.0 aktualizacje są wydawane na bieżąco i sekwencyjnie zainstalowane. Nie można pominąć poszczególnych aktualizacji pośrednich. Tworzy to zdefiniowaną ścieżkę aktualizacji, ale nie zwalnia dostawcy z obowiązku sprawdzenia własnego środowiska: im więcej stron internetowych klientów, indywidualnych zależności PHP i rozszerzeń obsługuje serwer, tym ważniejsze jest ustalenie, która zmiana ma wpływ na daną klasę usług.

Plesk opisuje automatyczne aktualizacje dla własnych aktualizacji oraz oddzielne opcje dla dostarczonych komponentów stron trzecich i pakietów systemowych. Strona dokumentacji zawiera jednak sprzeczne informacje dotyczące domyślnego stanu opcji dotyczących komponentów stron trzecich. Administratorzy nie powinni zatem zakładać, że istnieje globalne ustawienie domyślne, lecz sprawdzić faktycznie ustawione opcje dla każdego serwera w sekcji Tools & Settings > Update Settings sprawdzić. Należy zachować szczególną ostrożność, ponieważ nowsze komponenty mogą być niekompatybilne ze stronami internetowymi hostowanymi.

W przypadku wielu instancji klientów to rozróżnienie stanowi zaletę, o ile zostanie przełożone na konkretne procesy. Korekty w panelu i zmiany związane z bezpieczeństwem można planować w oparciu o ich zakres; natomiast wymiana komponentów podlega odrębnej ocenie zgodności. Oferta hostingu zarządzanego nie musi od razu uwzględniać każdej dostępnej wersji pakietu. Decydujące znaczenie ma to, które wersje pasują do uzgodnionego stosu, przetestowanej bazy klientów oraz przewidzianego modelu wsparcia.

Korzyści płynące z najnowszych wersji Obsidianu obejmują kilka obszarów działalności: funkcje diagnostyczne pozwalają uporządkować obsługę pierwszego poziomu, nowe narzędzia do hostingu aplikacji poszerzają opcje taryfowe, a funkcje związane z certyfikatami i pomocą techniczną dotyczą bezpieczeństwa oraz zarządzania uprawnieniami. Artykuł ten omawia również wcześniejsze podstawy i zmiany w tej linii produktów Plesk Obsidian 2025: Rewolucyjne innowacje dla hostingu internetowego . Jednak w przypadku obecnego wprowadzenia na rynek decydujące znaczenie ma konkretny składnik, a nie sama nazwa produktu.

Automatyzacja nie jest zatem decyzją o ogólnym zezwoleniu. Sensowne jest rozróżnienie między regularną instalacją udokumentowanych aktualizacji Plesk a świadomie kontrolowanymi zmianami w środowisku klienta. Szczególnie w przypadku serwerów współdzielonych takie rozróżnienie chroni przed sytuacją, w której niezauważona zmiana komponentu wpływa jednocześnie na wiele niezależnych od siebie stron internetowych. Nie zastępuje to testów, ale sprawia, że ryzyko staje się widoczne i możliwe do przypisania.

Nowe funkcje w zależności od scenariusza hostingu

W przypadku hostingu współdzielonego jednym z pierwszych zastosowań jest szybsza identyfikacja problemów z domenami. Dane zawarte w Plesk Obsidian 18.0.81 – ogólnodostępna diagnostyka DNS obejmuje testy dotyczące rozpoznawania nazw, aspektów związanych z rekordami MX, protokołu DNSSEC, serwerów nazw oraz wygaśnięcia domeny. Przejrzysty raport wyświetlany w panelu może pomóc pracownikom pomocy technicznej w uporządkowanym sprawdzaniu problemów związanych z DNS, pocztą elektroniczną i delegowaniem przed eskalacją sprawy.

Raport ten jest jednak Diagnoza ani automatycznej korekty. W szczególności nie uwzględniono obecnie aliasów domen. Nawet jeśli wynik wskazuje na błędną delegację lub strefę, usunięcie problemu może leżeć w gestii rejestratora lub zewnętrznego operatora DNS. Jako narzędzie wsparcia technicznego funkcja ta jest zatem szczególnie przydatna, gdy w zgłoszeniu jasno określono zakres odpowiedzialności oraz kolejny etap eskalacji.

Drugim obszarem jest Hosting aplikacji dla agencji i programistów. Node.js Toolkit 2.5.0 oferuje centralny przegląd aktywowanych aplikacji Node.js oraz konfigurację istniejących projektów za pomocą jednego kliknięcia. Funkcja automatycznego wykrywania rozpoznaje wiele popularnych frameworków serwerowych, a także statyczne interfejsy użytkownika. Ponadto rozszerzenie pnpm jest obsługiwane wyłącznie w środowisku Plesk dla systemu Linux. Ogranicza to powtarzające się pojedyncze czynności, nie gwarantuje jednak, że każde indywidualne wdrożenie będzie mogło zostać przejęte bez zmian.

Nowe rozszerzenie Python 1.0.0 jest również przeznaczone dla systemów Linux i zapewnia obsługę języka Python na poziomie domeny, środowiska wirtualne, zależności, zmienne środowiskowe oraz szyfrowane sekrety. Aplikacje działają w tym przypadku jako aplikacje WSGI za pośrednictwem Phusion Passenger; uprawnienie „Python support management“ można kontrolować za pomocą planów usług i subskrypcji. Może to stać się kontrolowaną cechą taryfy, a nie automatycznie zamiennikiem każdej architektury opartej na języku Python.

Trzeci obszar obejmuje certyfikaty i funkcje pomocnicze. W wersji 18.0.81 SSL It! obsługuje weryfikację DNS jako alternatywę dla weryfikacji HTTP w przypadku wspomnianych integracji ext-acme i ext-letsencrypt. Ma to znaczenie na przykład w przypadku domen bez otwartego portu 80. Warunkiem pozostaje odpowiedni sposób ustawiania wpisów DNS w faktycznie właściwej strefie; samo wyświetlenie rekordu nie zapewnia uprawnień do zapisu.

W wersji 18.0.81 funkcja MCP jest domyślnie wyłączona i można ją podłączyć za pośrednictwem konta WebPros. Administratorzy określają w panel.ini typy użytkowników, którzy mogą łączyć się z klientami MCP. Jego przydatność zależy zatem nie tylko od funkcji, ale także od ról, uprawnień i protokołów. Funkcje rozszerzeń zależne od platformy, zewnętrzna obsługa DNS oraz architektura aplikacji klienta decydują łącznie o tym, które nowości powinny znaleźć się w poszczególnych planach taryfowych.

Porównanie funkcji na potrzeby planowania produktów

W przypadku planowania produktów sama nazwa „Plesk Obsidian” nie wystarczy: istotne w tym kontekście funkcje pochodzą częściowo z produktu podstawowego, a częściowo z rozszerzeń o odrębnych wersjach. Dlatego dostawca nie powinien oceniać funkcji wyłącznie pod kątem ich przydatności, lecz uwzględniać w cenniku również system operacyjny, model udostępniania oraz zależności techniczne.

W zestawieniu tym wyraźnie rozróżniono funkcje platformy od usług taryfowych, które można wprowadzić na rynek. Diagnostyka DNS może być szeroko dostępna jako narzędzie wsparcia technicznego. Natomiast Python powinien być dostępny wyłącznie w ofertach dla systemu Linux, których zasady zarządzania uprawnieniami i ograniczenia wsparcia technicznego są do tego dostosowane. W przypadku Node.js dostawca musi rozróżnić poszczególne podfunkcje: pnpm jest udokumentowany wyłącznie dla systemu Linux, podczas gdy dziennik zmian nie nakłada odpowiednich ograniczeń na centralny przegląd i autokonfigurację.

Również funkcje certyfikatów i MCP wymagają wyboru konkretnego produktu zamiast globalnej aktywacji. W przypadku DNS-01 o praktycznej użyteczności decyduje przynależność do strefy. W przypadku MCP połączenie techniczne stanowi jedynie część projektu; decydujące znaczenie mają uprawnione osoby, przejrzyste procedury oraz sposób postępowania w przypadku działań powodujących skutki uboczne.

Diagnoza DNS i certyfikaty w dziale pomocy technicznej

Ogólnodostępna wersja Plesk Obsidian 18.0.81 Diagnostyka DNA nadaje się jako wstępna ocena techniczna zgłoszenia dotyczącego domeny. W panelu opcja „Troubleshoot DNS“ otwiera przejrzysty raport dotyczący rozpoznawania adresów DNS, sprawdzeń związanych z rekordami MX, protokołu DNSSEC, problemów z serwerami nazw oraz daty wygaśnięcia domeny. Skraca to wstępną weryfikację, ale nie zastępuje ani analizy strefy autorytatywnej, ani uzgodnień z rejestratorem lub zewnętrznym operatorem DNS.

Aby zapewnić powtarzalny przebieg procedury pierwszego poziomu, dział wsparcia powinien najpierw zarejestrować główną domenę, której dotyczy zgłoszenie, oraz sam raport, a następnie przypisać kompetencje i stopień powagi. Jeśli na przykład raport wskazuje na błędną delegację, jej korekta często wykracza poza zakres kompetencji panelu. Ważne jest również udokumentowane ograniczenie: aliasy domen nie są obecnie objęte tą kontrolą.

W celu diagnozy w wierszu poleceń dziennik zmian zawiera następujące wywołanie z neutralną domeną przykładową. Przed użyciem administrator powinien sprawdzić pomoc lub dokumentację poleceń dotyczącą faktycznie zainstalowanej wersji Plesk. Na podstawie samej składni podanej w dzienniku zmian nie można wywnioskować żadnych dalszych gwarancji dotyczących wszystkich skutków działania tego polecenia.

plesk repair dns -n -j -check-resolution example.com

W przypadku certyfikatów rozszerzonych Walidacja DNS-01 możliwy zakres zastosowania: w Plesk Obsidian 18.0.81 można używać funkcji SSL It! jako alternatywy dla walidacji HTTP przy wydawaniu i przedłużaniu certyfikatów. Ma to znaczenie np. w przypadku domen API lub pocztowych, w których port 80 jest celowo zamknięty. Plesk wyświetla wymagane wpisy DNS i zapisuje wybraną metodę dla każdej domeny na potrzeby przyszłych przedłużeń.

Proces ten nie zakończy się jednak automatycznie powodzeniem tylko dlatego, że wyświetlany jest rekord. Operator musi mieć uprawnienia do zapisu w faktycznie właściwej strefie DNS lub odpowiednio skonfigurowaną ścieżkę automatyzacji. Zgodnie z dziennikiem zmian walidacja DNS wprowadzona w wersji 18.0.81 dotyczy wyłącznie integracji ext-acme i ext-letsencrypt w SSL It!, a nie ogólnie wszystkich dostawców certyfikatów.

Osobną kwestią jest późniejsza aktualizacja rozszerzająca SSL It! 1.24.0 z dnia 29 września 2026 r. W tej wersji można zabezpieczyć domenę bez hostingu za pomocą panelu lub wiersza poleceń przy użyciu certyfikatu typu wildcard; automatyczne przedłużenie odbywa się również w formie certyfikatu typu wildcard. To uzupełnienie nie stanowi części pierwotnego zakresu funkcji Plesk Obsidian 18.0.81, lecz podlega własnemu systemowi numeracji wersji i harmonogramowi wydawania rozszerzenia.

Hosting aplikacji jako opcja taryfowa z możliwością kontroli

Dzięki najnowszym rozszerzeniom hosting aplikacji można lepiej wyodrębnić jako opcję taryfową. Zestaw narzędzi Node.js Toolkit 2.5.0 zapewnia centralny przegląd aktywowanych aplikacji Node.js oraz konfigurację istniejących projektów za pomocą jednego kliknięcia. Ponadto rozszerzenie to obsługuje menedżera pakietów pnpm w środowisku Plesk dla systemu Linux. Dzięki temu dostawca może ustandaryzować powtarzające się zadania konfiguracyjne bez konieczności traktowania każdej aplikacji klienta jako oddzielnego serwera.

Zgodnie z dziennikiem zmian funkcja rozpoznawania projektów obejmuje między innymi Express, Next.js, NestJS i Nuxt.js, a także statyczne interfejsy użytkownika oparte na React, Vue.js, Angular lub Vite. Plesk może utworzyć plik startowy zgodny z Passengerem, uwzględnić na stałe zakodowane porty oraz ustawić katalog główny dokumentów, przy czym zmiany są wyświetlane przed potwierdzeniem. Statyczne interfejsy użytkownika są kompilowane i dostarczane bez konieczności utrzymywania stale uruchomionego procesu Node.js.

Ta automatyzacja jest pomocna, ale nie zastępuje przeglądu architektury. Liczne procesy, kolejki workerów, specjalne serwery proxy odwrotne, zewnętrzne sekrety lub własne potoki kompilacji mogą wymagać dodatkowych zasad operacyjnych. Zgodnie z dziennikiem zmian ograniczenie dotyczące systemu Linux odnosi się wyraźnie do pnpm; w przypadku centralnego przeglądu domen i automatycznej konfiguracji jednym kliknięciem nie wskazano tam żadnego odpowiedniego ograniczenia platformowego. Opisy taryf powinny zatem oddzielnie wymieniać te podfunkcje.

Rozszerzenie Python 1.0.0 udostępnia w systemie Linux możliwość oddzielnego zarządzania dla każdej domeny. Klienci mogą tworzyć środowiska wirtualne, instalować zależności za pośrednictwem interfejsu użytkownika, przeglądać metadane z pliku pyproject.toml oraz zarządzać zmiennymi środowiskowymi i zaszyfrowanymi sekretami. Dostęp do tej funkcji jest przyznawany poprzez uprawnienie „Zarządzanie obsługą języka Python“ w planach usług i subskrypcjach.

Z technicznego punktu widzenia aplikacje te działają jako Aplikacje WSGI za pośrednictwem Phusion Passenger; konfigurację serwera WWW generuje automatycznie Plesk. Pakiet „Python Web App“ może zatem obejmować na przykład środowiska wirtualne, określony limit zasobów oraz wsparcie dla klasycznych projektów WSGI. Nie oznacza to jednak, że ten sam pakiet obejmuje złożone stosy ASGI, stale działające procesy robocze lub specjalistyczne architektury kontenerowe.

Artykuł ten może pomóc w zrozumieniu starszych funkcji i zmian w interfejsie użytkownika Plesk Obsidian: przegląd nowości i ulepszeń można wykorzystać jako uzupełnienie. W przypadku nowych taryf kluczowe znaczenie ma wspólne udokumentowanie wersji rozszerzonej, udokumentowanych ograniczeń platformy, uprawnień oraz konkretnych typów aplikacji, które są obsługiwane.

Stopniowe wdrażanie aktualizacji do środowiska produkcyjnego

W środowisku dostawcy usług hostingowych aktualizacja panelu hostingowego nie powinna rozpoczynać się po pierwszym kliknięciu na głównym serwerze produkcyjnym. Najpierw utwórz Inwentaryzacja z wersji Plesk, stanów systemów operacyjnych, włączonych rozszerzeń oraz aplikacji klientów działających na tych platformach. Istotne są również zależności zewnętrzne, takie jak dostawcy usług DNS, serwery przekaźnikowe poczty elektronicznej, kopie zapasowe, własne pakiety PHP oraz procesy wdrażania. Dzięki temu widać, które systemy mają ten sam stan, a które przypadki szczególne wymagają odrębnego traktowania.

Następnie sprawdź zależności dla poszczególnych klas serwerów. Aktualizacja produktu podstawowego może mieć inne skutki niż aktualizacja rozszerzenia lub komponentu zewnętrznego. Również pakiety dostarczane przez system operacyjny stanowią odrębny obszar konserwacji. Plesk wyraźnie rozróżnia te kategorie; w szczególności aktualizacje komponentów stron trzecich mogą mieć wpływ na strony internetowe, jeśli nie są one przygotowane na zmienione wersje lub środowiska uruchomieniowe.

Następnie zaleca się przeprowadzenie reprezentatywnego instancja pilotażowa zamiast dowolnego serwera testowego. Powinno ono odzwierciedlać typowe konfiguracje taryfowe: na przykład klasyczne strony internetowe oparte na systemie CMS, domeny pocztowe, korzystanie z baz danych, a także aktywowane aplikacje Node.js lub Python, o ile są one oferowane. Celem nie jest symulowanie całkowitej identyczności z środowiskiem produkcyjnym, lecz wcześniejsze uwidocznienie istotnych kombinacji systemów operacyjnych, rozszerzeń i aplikacji klientów.

W celu wdrożenia produkcyjnego należy ustalić okno serwisowe z jasno określoną kolejnością działań. Najpierw zaktualizuj ograniczoną grupę serwerów, przeanalizuj wyniki obserwacji, a dopiero potem rozszerz wdrożenie. Następnie sprawdź dostępność paneli, zaplanowane kopie zapasowe, usługi internetowe i pocztowe, przedłużenia certyfikatów oraz komunikaty o błędach w odpowiednich aplikacjach. Kontrole te zmniejszają niepewność, nie stanowią jednak gwarancji braku awarii ani pełnej kompatybilności aplikacji.

Jeśli chodzi o planowanie wydajności, firma Plesk podaje minimalne wymagania wynoszące 1 GB pamięci RAM plus 1 GB przestrzeni swap w systemie Linux oraz 2 GB pamięci RAM w systemie Windows. W przypadku hostingu współdzielonego jako ogólne zalecenie podaje się 1 GB pamięci RAM na każde 40–50 stron internetowych, pod warunkiem że nie więcej niż dziesięć procent wszystkich hostowanych stron internetowych odnotowuje stałą lub regularną liczbę odwiedzających w tygodniu lub miesiącu. Takie Wartości orientacyjne dotyczące zasobów nie stanowią gwarancji przepustowości i nie zastępują pomiaru własnego obciążenia: aktywność bazy danych, natężenie ruchu pocztowego, oprogramowanie zabezpieczające oraz rodzaj aplikacji mogą znacząco wpłynąć na zapotrzebowanie.

Rozpoznawanie źródeł błędów i priorytetów bezpieczeństwa

Powtarzające się błędy wynikają zazwyczaj z nieprecyzyjnych ograniczeń dotyczących produktów. Dlatego przy każdym ogłoszeniu należy podać konkretną wersję produktu podstawowego lub rozszerzenia. Nie wolno ogólnie reklamować funkcji Node.js lub Python w planach taryfowych dla systemu Windows, jeśli jest ona udokumentowana wyłącznie dla Plesk dla systemu Linux. Podobnie hosting Python z WSGI za pośrednictwem Passenger nie oznacza dopuszczenia dowolnych architektur ASGI, Worker lub kontenerowych.

• Funkcję DNS-01 należy uwzględnić w planie taryfowym dopiero wtedy, gdy dostępny jest dostęp zapisu do autorytatywnej strefy DNS lub odpowiednia ścieżka automatyzacji.
• Nie należy traktować opcji automatycznych aktualizacji Plesk, komponentów innych producentów i pakietów systemowych jako tożsamych; należy sprawdzić faktyczne ustawienia dla każdego serwera w sekcji „Narzędzia i ustawienia > Ustawienia aktualizacji“.
• Przed wdrożeniem nowych funkcji należy sprawdzić rozszerzenia, uprawnienia i systemy operacyjne dla każdej linii produktów.
• W przypadku MCP należy przed przyznaniem uprawnień określić dopuszczalne grupy użytkowników, ścieżki zatwierdzania oraz protokołowanie działań.

Die Priorytet bezpieczeństwa nie zależy wyłącznie od dogodności terminu konserwacji. Na dzień publikacji artykułu aktualną, udokumentowaną wersją poprawki dla tej linii wydania podstawowego jest Plesk Obsidian 18.0.81 Update 2 z 29 września 2026 r.; Firma Plesk zwraca uwagę na krytyczną lukę w zabezpieczeniach i zaleca jak najszybszą instalację tej aktualizacji. Aktualizacja 1 z 21 września zawierała również krytyczną poprawkę bezpieczeństwa, która w dzienniku zmian została wyraźnie wymieniona w odniesieniu do systemu Linux. W przypadku systemów Linux nie należy zatem pozostawać na wersji Aktualizacja 1.

W dzienniku zmian z września wymieniono również krytyczne poprawki bezpieczeństwa dla Node.js Toolkit 2.5.0 z 14 września 2026 r. oraz Site Import 1.12.2 z 23 września 2026 r. Dlatego należy zawsze sprawdzić, czy dany komponent jest zainstalowany, i traktować rdzeń panelu, rozszerzenia, pakiety PHP oraz inne dodatki jako oddzielne ścieżki aktualizacji. Późniejsza aktualizacja rozszerzenia lub wersji PHP nie zastępuje zalegającej aktualizacji produktu podstawowego.

MCP zasługuje na ograniczoną Działalność pilotażowa zamiast natychmiastowej, szeroko zakrojonej aktywacji. Funkcja ta jest domyślnie wyłączona; administratorzy mogą w panel.ini określić, jakie typy użytkowników mogą łączyć się z klientami MCP. Należy z góry ustalić, jakie zadania mają być obsługiwane, kto może weryfikować zmiany oraz w jaki sposób będą śledzone nietypowe lub niepożądane działania. Integracja z AI nie zastępuje ani modeli ról, ani zarządzania zmianami, ani przeglądów technicznych.

Ostrzeżenie: Komponenty stron trzecich nie powinny być wdrażane w sposób niekontrolowany we wszystkich środowiskach klientów wyłącznie ze względu na dostępność nowszej wersji. Plesk zwraca uwagę na możliwe niezgodności z hostowanymi stronami internetowymi; jednocześnie aktualna strona dokumentacji zawiera sprzeczne informacje dotyczące tego, czy odpowiednia funkcja automatyczna jest domyślnie włączona. W związku z tym należy sprawdzić dla każdego serwera w sekcji Tools & Settings > Update Settings ustalone opcje oraz zaplanować stopniowe wdrażanie dla popularnych okresów obowiązywania i wtyczek z udziałem reprezentatywnej grupy pilotażowej.

Wybór między aktualizacją a przeniesieniem serwera

Wybór między Aktualizacja na miejscu a przenoszenie serwera rozpoczyna się od stanu aktualnego, a nie od pożądanej wersji Obsidian. Aktualizacja na tym samym serwerze wymaga, aby system operacyjny i zainstalowana wersja wyjściowa Plesk były obsługiwane w ramach przewidzianej ścieżki aktualizacji. Dodatkowo sprawdź używane rozszerzenia, własne dostosowania oraz dostępną przestrzeń na kopie zapasowe. Fakt, że dana ścieżka aktualizacji jest technicznie możliwa, nie oznacza jeszcze, że jest ona odpowiednia dla każdego środowiska klienta.

W dokumentacji dotyczącej aktualizacji Plesk Onyx podano bezpośrednie ścieżki aktualizacji do Obsidianu dla wersji 17.0, 17.5 i 17.8. Starsze lub nieobsługiwane środowiska źródłowe mogą wymagać przeniesienia na nowy serwer Obsidian, o ile wersja źródłowa nadaje się do migracji. Przeniesienie to umożliwia przygotowanie systemu operacyjnego, rozkładu zasobów oraz zestawu rozszerzeń niezależnie od starego systemu.

Warto szczególnie rozważyć wybór nowego serwera docelowego, jeśli obecny system operacyjny zbliża się do końca okresu wsparcia, platforma była przez długi czas dostosowywana do indywidualnych potrzeb lub ma miejsce kilka znaczących zmian wersji. Wymagania systemowe Plesk stanowią w tym przypadku jedynie minimalne kryteria planowania. Przy ustalaniu docelowej wielkości należy również uwzględnić liczbę stron internetowych, skrzynek pocztowych, baz danych, usług bezpieczeństwa, przestrzeni na kopie zapasowe oraz przewidywane obciążenie po migracji.

Na stronie Aktualizacja poprzez przeniesienie istniejące środowisko zostanie przeniesione na serwer z zainstalowanym oprogramowaniem Plesk Obsidian. Zgodnie z dokumentacją dotyczącą aktualizacji warunkiem koniecznym jest, aby system operacyjny serwera docelowego był obsługiwany, a zainstalowana wersja wyjściowa pozwalała na migrację do Obsidian. Dlatego przed rozpoczęciem planowania należy sprawdzić, czy ta opcja jest dostępna, biorąc pod uwagę konkretną wersję źródłową.

Aby zapewnić aktualną, obsługiwana i przejrzystą instalację, najczęściej najlepszym rozwiązaniem jest terminowe instalowanie poprawek po sporządzeniu spisu i przeprowadzeniu wdrożenia pilotażowego. W przypadku nowych rozszerzeń lub funkcji specyficznych dla systemu Linux wskazane jest przeprowadzenie ukierunkowanej fazy pilotażowej. Jeśli wsparcie dla systemu operacyjnego, wersja wyjściowa lub istniejące ograniczenia techniczne ograniczają możliwości, należy najpierw przeprowadzić Przygotowano migrację . To, który wariant jest odpowiedni, wynika ze statusu wsparcia technicznego, kompatybilności i modelu operacyjnego – a nie z ogólnego zezwolenia na wdrożenie do środowiska produkcyjnego.