Windows Server 2008

Praktyka wdrażania IIS 7.0 Udostępnij na: Facebook

Autor: Fergus Strachan

Opublikowano: 27 stycznia 2009

Zawartość strony
 Do biegu, gotowi, test   Do biegu, gotowi, test
 Moja konfiguracja testowa   Moja konfiguracja testowa
 Ważne ulepszenia dla administratorów IT   Ważne ulepszenia dla administratorów IT
 Architektura IIS   Architektura IIS
 Tryby zintegrowany i klasyczny   Tryby zintegrowany i klasyczny
 Moduły i funkcjonalność   Moduły i funkcjonalność
 Migracja aplikacji www   Migracja aplikacji www
 Podsumowanie   Podsumowanie

Kod do pobrania jest dostępny w pliku: IIS72008_07.exe (861 KB)

Zespół IIS w firmie Microsoft twierdzi, że Internet Information Services (IIS) 7.0 to najlepsza wersja w historii IIS. Ustanawia ona nowe standardy, oferuje podstawowe ulepszenia oraz wnosi nowe możliwości konsolidacji środowisk www. IIS 7.0, dołączony do Windows Server 2008 oraz Windows Vista SP1, już króluje w Microsoft.com, a kilka firm zajmujących się hostingiem stron www już zaczęło udostępniać IIS 7.0 projektantom i programistom Web, którzy chcą przenieść swoje istniejące aplikacje Web na nową platformę serwera www.

W tym artykule analizuję kluczowe ulepszenia IIS 7.0, które są najważniejsze dla specjalistów IT, a następnie przechodzę do szczegółów dotyczących migracji aplikacji ASP.NET oraz PHP. Najpierw jednak chcę przedstawić laboratorium testowe przypominające podstawowe środowisko produkcyjne.

To bardzo ważne zadanie. Przed wdrożeniem IIS 7.0 na serwerach produkcyjnych trzeba poświecić czas na zrobienie dokładnych testów w środowisku laboratoryjnym, sprawiając, że aplikacje Web będą bez problemu działać nanowym serwerze.

Do biegu, gotowi, test

Moje laboratorium testowe zawiera działające systemy Windows Server 2003 oraz IIS 6.0, które udostępnią aplikacje ASP.NET, a także serwery z uruchomioną dystrybucją Linuksa Ubuntu 7.10 oraz Apache HTTP Server 2.2, które udostępniają aplikacje www oparte na PHP.

Moim podstawowym celem jest wdrożenie Windows Server 2008 w systemach testowych i produkcyjnych, a następnie przeniesienie złożonych aplikacji Web w celu zastąpienia egzemplarzy IIS 6.0 i Apache przez IIS 7.0.

Mam dwie kluczowe aplikacje www: DotNetNuke 4.7 oraz osCommerce 3.0a4. DotNetNuke jest strukturą opartą na ASP.NET 2.0 i Microsoft SQL Server. Druga aplikacja, osCommerce, jest najnowszą wersją alfa bogatego w funkcje rozwiązania e-commerce, zbudowanego na PHP oraz MySQL. Wstawmy więc te zaawansowane aplikacje do IIS 7.0!

Chcę wyraźnie zaznaczyć, że nie jest moim zamiarem porównywanie wersji oprogramowania, produktów lub platform. Jest jednak kilka korzyści przechodzenia do standardu Windows Server 2008 i IIS 7, które chcę wskazać. Mianowicie, zmniejsza to złożoność administracji i może zminimalizować całkowitą liczbę uruchomionych serwerów www.

Na rysunku 1 pokazany jest widok laboratorium testowego, z którego korzystam w tym artykule. Aby prześledzić moje wyjaśnienia we własnym środowisku testowym, można znaleźć łącza do wymaganych komponentów oprogramowania, a także szczegółowe instrukcje instalacji krok po kroku, w towarzyszącym artykułowi materiale, dostępnym w części Code Downloads (Kody do pobrania) na stronie TechNet Magazine.

Rysunek 1: Środowisko testowe do rozwijania IIS 7.0.

Warto odnotować, że gdy pisałem podsumowanie tego artykułu, Microsoft wypuścił narzędzie wiersza poleceń (MSDeploy.exe) do obsługi wdrażania, synchronizacji i migracji aplikacji www do wersji IIS 6.0 oraz 7.0. Zalecam sprawdzenie tego narzędzia. Szczegółowe informacje można znaleźć w blogu zespołu Microsoft Web Deployment, na stronie go.microsoft.com/fwlink/?LinkId=118272.

 Do początku strony Do początku strony

Moja konfiguracja testowa

W czasie pisania tego artykułu, Windows Server 2008 był nadal w wersji przedpremierowej, dlatego też nie zastępowałem systemu Windows Server 2003 na kontrolerze domeny lub Sewerach baz danych.

Mając oficjalne wydanie Windows Server 2008, można rozważyć również migrację infrastruktury Active Directory. Przenoszenie baz danych SQL Server 2005 i MySQL na SQL Server 2008 również wykracza poza zakres tego artykułu.

Wdrożyłem SQL Server 2008 na moim próbnym serwerze, głownie dlatego, że wymaga to mniej wysiłku niż instalowanie SQL Server 2005 z Service Pack 2. DotNetNuke bez problemu działał z bazą danych SQL Server 2008. Instalowanie MySQL 5.0 w Windows Server 2008 było także proste i nie było żadnych komplikacji.

Chociaż IIS 7.0 jest dostępny w instalacji Server Core, nie korzystałem z Server Core z powodu pewnych wymagań dla mojego testowania. Mój próbny serwer wymagał pełnej instalacji, ponieważ jest to mój główny system testowy. Ponadto Microsoft .NET Framework nie jest dostępne w instalacji Server Core.

PHP dobrze działa w Server Core, lecz moim celem jest konsolidacja aplikacji ASP.NET i PHP, więc Server Core po prostu nie jest tu brane pod uwagę. Dopóki.NET Framework nie jest obsługiwane przez Server Core, trzeba wykonać pełną instalację, aby obsługiwać aplikacje ASP.NET. Szczegółowe wskazówki dotyczące instalacji środowiska testowego można znaleźć w pliku 01_install_testlab.htm w dołączonym materiale.

Wybrałem wykonanie czystej instalacji Windows Server 2008 (w przeciwieństwie do aktualizacji istniejących serwerów). Między innymi, czysta instalacja ułatwia implementację etapowego scenariusza migracji, jak na rysunku 2. Podstawową strategią jest utrzymanie w ruchu istniejących zespołów serwerów www do czasu, gdy wszystkie istotne komponenty aplikacji nie zostaną z powodzeniem przetestowane na próbnym serwerze i przeniesione do nowego zespołu serwerów IIS 7.0.

Rysunek 2: Etapowe przełączanie na IIS 7.0.

DNS entries ... – Pozycje DNS wskazują na oryginalne serwery, które obsługują farmy Web

Revelant DNS ... – Odpowiednie zapisy DNS są teraz aktualizowane, aby wskazywać przeglądarkom nowe farmy Web IIS 7

A final ... – Ostateczny test akceptacji i wylogowanie potwierdza, że przenoszona aplikacja WEB działająca na nowym serwerze produkcyjnym warunki i niezawodności, wydajności i szczególnych wymagań firmowych.

Deployment OK – Wdrożenie powiodło się

Copies of ... – Kopie farm Web są wdrażane na serwerze próbnym IIS 7.0

Once verified ... – Po weryfikacji podczas pracy, aplikacje Web są przenoszone do nowej farmy serwerów IIS 7.0, Mogą byc przenoszone pojedynczo lub w grupie.

Migration OK – Migracja powiodła się

Applications are ... – Aplikacje są testowane, aby sprawdzić czy działają bez problemów z kompatybilnością. Problemy można naprawić bez wpływu na farmy Web, które są nadal obsługiwane na oryginalnych serwerach.

Można przenieść od razu wszystkie istniejące aplikacje lub robić to stopniowo, w zależności od złożoności naszego środowiska.

Po przeprowadzeniu ostatecznego testu akceptacji na nowej farmie serwerów www, dla każdej aplikacji lub lokalizacji, można dokonać zamiany zmieniając odpowiednie zapisy DNS, aby skierować przeglądarki do nowej farmy IIS 7.0. To utrzyma przestoje i zakłócenia na minimalnym poziomie.

 Do początku strony Do początku strony

Ważne ulepszenia dla administratorów IT

MSDN Magazine zawiera doskonały artykuł Mike’a Volodarsky’ego, zatytułowany „Explore the Web Server for Windows Vista and Beyond” (dostępny na stronie msdn2.microsoft.com/magazine/cc163453.aspx), w którym można znaleźć najnowsze informacje na temat ulepszeń w IIS 7.0.

Inną dobrą lekturą jest post w blogu zespołu Microsoft.com, pod tytułem „The Tasty Morsels Found in Dogfood” (dostępny na stronie go.microsoft.com/fwlink/?LinkId=117436). Tekst ten podsumowuje początkowe doświadczenia członków zespołu z IIS 7.0. Jednym słowem, podali oni Następujący ranking najważniejszych ulepszeń:

  1. Uproszczona konfiguracja.
  2. Znakomita kompatybilność.
  3. Brak metabazy.
  4. Scentralizowana konfiguracja poprzez plik applicationHost.config, umieszczony na udziale UNC.
  5. Delegowana konfiguracja za pomocą plików web.config files w katalogach aplikacji.
  6. Ulepszone narzędzia zarządzania.
  7. Śledzenie nieudanych żądań.
  8. Filtrowanie żądań bez konieczności użycia URLScan.
  9. Uproszczone możliwości synchronizacji zawartości poprzez udziały UNC.
  10. Buforowanie wyjścia dynamicznej zawartości.

Uproszczona konfiguracja jest zdecydowanie na mojej liście. We wpisie w swoim blogu, zespół Microsoft.com przedstawia, jak można wdrożyć wszystkie funkcje IIS 7.0 (lub, oczywiście, tylko funkcje, które chcemy) za pomocą pojedynczego wiesza polecenia. Z zapałem włączyłem ten sposób postępowania do mojej instrukcji konfiguracji laboratorium testowego, korzystając z wiersza polecenia potkanego na rysunku 3.

Co prawda, to polecenie jest dość długie. (Aby je skopiować, lepiej skopiować je i wkleić ze strony TechNet Magazine Web, zamiast ręcznego przepisywania.) Chociaż to polecenie umieszcza wszystkie dostępne moduły w komputerze IIS 7.0, nie obejmuje PHP. IIS 7.0 nie zawiera PHP, a pomysł pobierania i instalowania pakietów systemu Debian przez Internet jest obcą koncepcją dla Windows Package Manager (pkgmgr.exe). Wejdźmy w Windows Automated Installation Kit (AIK).

Rysunek 3 Wdrażanie funkcji IIS 7.0 za pomocą pojedynczego wiersza polecenia

start /w pkgmgr.exe /iu:IIS-WebServerRole;IIS-WebServer;IIS-CommonHttpFeatures;IIS-StaticContent;

IIS-DefaultDocument;IIS-DirectoryBrowsing;IIS-HttpErrors;IIS-HttpRedirect;

IIS-ApplicationDevelopment;IIS-ASPNET;IIS-NetFxExtensibility;IIS-ASP;IIS-CGI;

IIS-ISAPIExtensions;IIS-ISAPIFilter;IIS-ServerSideIncludes;IIS-HealthAndDiagnostics;

IIS-HttpLogging;IIS-LoggingLibraries;IIS-RequestMonitor;IIS-HttpTracing;IIS-CustomLogging;

IIS-ODBCLogging;IIS-Security;IIS-BasicAuthentication;IIS-WindowsAuthentication;

IIS-DigestAuthentication;IIS-ClientCertificateMappingAuthentication;

IIS-IISCertificateMappingAuthentication;IIS-URLAuthorization;IIS-RequestFiltering;

IIS-IPSecurity;IIS-Performance;IIS-HttpCompressionStatic;IIS-HttpCompressionDynamic;

IIS--WebServerManagementTools;IIS-ManagementConsole;IIS-ManagementScriptingTools;

IIS-ManagementService;IIS-IIS6ManagementCompatibility;IIS-Metabase;IIS-WMICompatibility;

IIS-LegacyScripts;IIS-LegacySnapIn;IIS-FTPPublishingService;IIS-FTPServer;IIS-FTPManagement;

WAS-WindowsActivationService;WAS-ProcessModel;WAS-NetFxEnvironment;WAS-ConfigurationAPI



# Polecenie dostarczone przez zespół Microsoft.com (blogs.technet.com/mscom).

Za pomocą AIK można utworzyć niestandardową instalację DVD dla Windows Server 2008, która zawiera IIS 7.0 oraz PHP 5. Można również włączyć MySQL, pliki aplikacji Web oraz inne komponenty, które są potrzebne w naszym wdrożeniu. Wszystkie komponenty mogą być częścią ustawień Windows Server 2008, co pozwala wprowadzić dostosowanie konsekwentnie we wszystkich serwerach Web. Nie ma potrzeby edytowania wierszy poleceń lub pliku konfiguracji.

Można nawet tworzyć niestandardowe DVD dla całkiem nienadzorowanych instalacji. AIK zawiera dokumentację i narzędzia do tworzenia pliku AutoUnattend.xml, który następnie umieszczamy w głównym folderze DVD. W pliku Custom Image Deployment.htm w dołączonych materiach podano instrukcje krok po kroku.

Wielu administratorów zgadza się również, że kompatybilność jest kluczowym ulepszeniem. Rozpoczynając działanie, oczekiwałem, że napotkam kilka problemów ze zgodnością z DotNetNuke i osCommerce, lecz przejście do IIS 7.0 jest raczej bezbolesne, pomimo faktu, że obydwie te aplikacje zawierają zaawansowane funkcje, takie jak uwierzytelnianie formularzy oraz adresy URL przyjazne dla mechanizmów wyszukiwania.

Korzystając z DotNetNuke, nie napotkałem żadnych problemów dopóki nie przeszedłem do złożonego scenariusza farmy serwerów www z udostępnianiem zawartości UNC na 64-bitowej platformie. Problem jednak był dość niewielki. Ostatecznie ta ulepszona kompatybilność oznacza, że potrzeba mniej czasu, aby nasze aplikacje zaczęły działać pod IIS 7.0.

Jeśli zdarzy się, że napotkamy problem ze zgodnością z naszymi aplikacjami Web, wbudowana diagnostyka oraz obsługa śledzenia szybko staną się jedną z naszych ulubionych funkcji. Szczegółowe informacje diagnostyki są bardzo konkretne, a proponowane ścieżki rozwiązań są użyteczne i rzeczywiście działają.

Rysunek 4 pokazuje informacje diagnostyki, które otrzymujemy przy uruchomionym DotNetNuke 4.7 w IIS 7.0 w zintegrowanym trybie. W tym przykładzie są trzy opcje (pokazane w części „Rzeczy, które można spróbować”). Zmiana aplikacji w celu obsługi trybu zintegrowanego jest prawdopodobnie najlepszym wyborem dla programistów DotNetNuke. Ignorowanie tego błędu jest przypuszczalnie zły pomysłem. Wybieram trzecią opcję, włączenie modelu klasycznego poprzez przełączenie aplikacji Web na Classic .NET AppPool, ponieważ chcę uruchomić niezmieniony DotNetNuke 4.7 na IIS 7.0.

Rysunek 4: Informacje d iagnostyki dla DotNetNuke uruchomionego w trybie zintegrowanym.

 Do początku strony Do początku strony

Architektura IIS

Można by się zastanawiać, czym są te zintegrowane i klasyczne tryby i dlaczego mają wpływ na aplikacje ASP.NET (DotNetNuke), a nie na aplikacje PHP (osCommerce). Aby lepiej to zrozumieć, trzeba najpierw popatrzeć na architekturę IIS 7.0.

Poprzednie wersje włączały ASP.NET do serwera www przede wszystkim poprzez rozszerzenie ISAPI (aspnet_isapi.dll). Z drugiej strony IIS 7.0 pozwala na podłączanie modułów ASP.NET bezpośrednio do serwera za pośrednictwem globalnego modułu HTTP o nazwie ManagedEngine, który ładuje ASP.NET Support DLL (webengine.dll) do potoku przetwarzania żądania IIS 7.0.

Wbudowane moduły korzystają z API dla IIS Web Server Core do rejestracji określonych zdarzeń w potoku, takich jak BeginRequest, Authenticate­Request, AuthorizeRequest oraz Execute­RequestHandler. ManagedEngine zapewnia również konieczną obsługę zintegrowanych modułów ASP.NET w potoku żądań. Dzięki nowej architekturze, IIS 7.0 może odwoływać się od modułów własnych oraz ASP.NET na każdym etapie przetwarzania żądania, niezależnie od żądanego typu zawartości.

Rozważmy jako przykład uwierzytelnianie użytkownika ASP.NET. W IIS 6.0 jest możliwe, aby moduł HTTP oparty na ASP.NET rejestrował zdarzenia On­Authenticate (takie jak Forms­Authentication.OnAuthenticate oraz Win­dows­Authentication.OnAuthenticate) do ustawienia tożsamości użytkownika w bieżącym HttpContext. To działa doskonale w czasie uruchomienia ASP.NET, lecz nie można użyć tego kodu ASP.NET, aby chronić zasoby zagrożone poprzez aplikacje Web oparte na PHP.

Zgodnie ze swoją konfiguracją mapy skryptu, IIS 6.0 przesyła żądania dla typów zawartości ASP.NET do aspnet_isapi.dll, lecz nie przesyła żądań dla typów zawartości PHP do rozszerzenia ISAPI dla ASP.NET. W końcu ASP.NET nie przetwarza kodu PHP, co oznacza także, że uwierzytelnianie ASP.NET nie działa, gdy żądana jest strona PHP. A zatem w przypadku IIS 6.0 trzeba dublować logiczne uwierzytelnianie, ponieważ aplikacje PHP muszą implementować swoje własne mechanizmy uwierzytelniania.

IIS 7.0 stosuje model przetwarzania sterowany zdarzeniami, który obsługuje mieszanie i dopasowywanie poszczególnych modułów w potoku żądania. Wśród innych komponentów, wraz z IIS 7.0 otrzymujemy zarządzane moduły WindowsAuthentication oraz FormsAuthentication, które wywołują zdarzenia OnAuthenticate, gdy potok żądania wyrzuca zdarzenie AuthenticateRequest. Można mieć teraz wbudowany moduł, taki jak Request­FilteringModule lub IpRestrictionModule, obsługujący zdarzenie BeginRequest, aby jak najszybciej odrzucać krytyczne żądania, a następnie uruchamiać niestandardowy kod uwierzytelniania ASP.NET przy zdarzaniu AuthenticateRequest. Można też mieć FastCgiModule z uruchomionym mechanizmem wykonywania skryptu PHP (php-cgi.exe) przy zdarzeniu Execute­RequestHandler, aby przetwarzać strony PHP.

Wynikiem tej zintegrowanej architektury jest fakt, że programiści stron www nie muszą dublować kodu, aby implementować typową logikę biznesową. Można też dostosować kod uwierzytelniania ASP.NET do ochrony wszystkich zasobów IIS, łącznie z aplikacjami PHP. Za pomocą modułów ASP.NET można wykonywać inne zadania przed i po przetwarzaniu, jak ponowne zapisywanie URL, niestandardowe śledzenie oraz rejestrowanie błędów.

 Do początku strony Do początku strony

Tryby zintegrowany i klasyczny

Ubocznym efektem nowej architektury jest fakt, że istniejące aplikacje ASP.NET mogą wymagać zmian kodu i konfiguracji, które powinny być realizowane przez programistów aplikacji, aby zmiany te nie prowadziły do konfliktów między modułami w potoku żądania.

Jeśli nie można natychmiast przenieść istniejącej aplikacji www, można w puli aplikacji włączyć tryb klasyczny, którego roboczy proces używa do uruchamiania aplikacji Web. IIS 7.0 nie ładuje ManagedEngine do procesu roboczego w klasycznym trybie, co w tym przypadku oznacza, że potok żądania nie może określić lub wywołać modułów ASP.NET.

Zamiast tego IIS 7.0 aktywuje pewną liczbę procedur obsługi ISAPI, które są oparte na IsapiModule (aspnet_isapi.dll), aby przetworzyć typy zawartości ASP.NET w sposób podobny do IIS 6.0. Możemy to zobaczyć, analizując punkt dotyczący procedur obsługi pod system.web­Server w pliku applicationHost.config, który domyślnie można znaleźć w folderze %WinDir%\­System32\InetSrv\Config.

Dla przykładu poszukajmy łańcucha aspx i znajdziemy jeden wpis wskazujący na PageHandlerFactory-Integrated (załadowany w robocze procesy puli aplikacji trybu zintegrowanego zgodnie z ustawieniem preCondition="integratedMode") oraz inne wpisy wskazujące na PageHandlerFactory-ISAPI-2.0 oraz PageHandlerFactory-ISAPI-2.0-64 (załadowane w robocze procesy puli aplikacji trybu klasycznego zgodnie z ustawieniem preCondition="classicMode").

Ponieważ tryb potoku jest ustawiony ma poziomie puli aplikacji, IIS 7.0 może uruchamiać aplikacje www równocześnie w trybie zintegrowanym i klasycznym. A procesy robocze wymagają jedynie uruchomienia w innych pulach aplikacji, lecz mogą być udostępniane na tym samym serwerze.

Pamiętajmy, że tryb zintegrowany i klasyczny mają wpływ tylko na to, jak IIS 7.0 włącza ASP.NET po potoku żądania. Te tryby potoku nie mają bezpośredniego wpływu na aplikacje PHP.

FastCgiModule i wszystkie inne wbudowane moduły ładują się bez wstępnych warunków trybu potoku, zarówno w trybie zintegrowanym, jak i klasycznym. FastCGI jest preferowanym interfejsem do uruchamiania mechanizmu wykonywania skryptów PHP w IIS 7.0. Zamiast stosowania FastCGI, można także utworzyć mapowanie procedury obsługi dla mechanizmu wykonywania skryptów PHP poprzez CGI, lub można użyć IsapiModule w połączeniu z PHP-ISAPI (php4isapi.dll).

Myślę jednak, że te alternatywy konfiguracji w stylu IIS 6.0 są teraz przestarzałe, gdy FastCGI oferuje znacznie ulepszoną wydajność i stabilność. CGI jest wolniejsze, ponieważ IIS musi inicjalizować nowy proces CGI dla każdego żądania http, podczas gdy FastCGI ponownie wykorzystuje procesy CGI dla wielu żądań. ISAPI wymaga wersji PHP z bezpiecznymi wątkami, co pociąga za sobą większe obciążenie niż uruchamianie PHP w innej wersji.

Zapewne jeszcze ważniejszy jest fakt, że nie wszystkie rozszerzenia PHP są dostępne w wersji z bezpiecznymi wątkami, a uruchamianie rozszerzeń bez bezpiecznych wątków za pomocą ISAPI jest złym pomysłem, ponieważ może spowodować problemy ze stabilnością serwera. Z drugiej strony, FastCGI jest środowiskiem z pojedynczą współbieżnością, tak jak CGI. W zastosowaniu do zwykłego uruchamiania wersji PHP bez bezpiecznych wątków, FastCGI jest stabilny i szybki, i jest to właściwa metoda postępowania z PHP 5 na IIS 7.0. Jest to również dostępne w IIS 6.0, jeśli nie jesteśmy jeszcze gotowi na przejście do IIS 7.0.

 Do początku strony Do początku strony

Moduły i funkcjonalność

Funkcje IIS 7.0 mają architekturę wysoce modularną – lub, jak przedstawiają to programiści IIS – zestaw funkcji złożony z komponentów. To dobra wiadomość dla administratorów serwerów www, którzy chcą utrzymywać miejsce w pamięci i powierzchnię ataku IIS 7.0 na możliwie niskim poziomie. Uaktywniając rożne moduły, a nawet zastępując standardowe moduły modułami niestandardowymi, możemy uzyskać pełną kontrolę nad funkcjami IIS 7.0 na naszych serwerach Web.

Aby uruchomić ASP.NET w trybie zintegrowanym lub klasycznym, jak również aplikacje PHP na tym samym serwerze, musimy przynajmniej zainstalować rolę Web Server oraz podstawowe moduły do obsługi przetwarzania żądania, konfigurację serwera, ASP.NET, ISAPI oraz CGI (który zawiera moduł FastCGI). To można zrobić za pomocą następującego wiersza polecenia:

start /w pkgmgr /iu:IIS-WebServerRole;

WAS-WindowsActivationService;WAS-ProcessModel;

WAS-ConfigurationAPI;IIS-ASPNET;

IIS-NetFxExtensibility;WAS-NetFxEnvironment;

IIS-ISAPIExtensions;IIS-ISAPIFilter;IIS-CGI

W zasadzie wolę instalować IIS 7.0 ze wszystkimi dostępnymi opcjami na moim próbnym serwerze, aby wszystkie komponenty i narzędzia administracyjne były dostępne, co pozwala szybko uruchomić moje aplikacje www.

Moją strategią jest zapewnienie działania, a następnie zawężenie konfiguracji, odinstalowując usługi ról i blokując moduły. Kiedy aplikacja zaczyna działać, dodaję z powrotem usługi i moduły ról, które wcześniej usunąłem.

Można również wybrać zastosowanie modułu Package Manager (pkgmgr.exe) lub narzędzia wiersza poleceń IIS 7.0 (appcmd.exe) albo bezpośrednią edycję sekcji globalModules w pliku applicationHost.config, lecz uważam, że narzędzia graficzne są bardzo wygodne. Trzeba pamiętać, że niektóre moduły, jakie jak RequestFilteringModule oraz StaticCompressionModule, są całkiem przydatne, chociaż są one – mówiąc wprost — niepotrzebne do uruchomienia naszych aplikacji Web.

Jeśli odinstalujemy moduł, który jest wymagany dla puli aplikacji, otrzymamy błąd HTTP przy wchodzeniu do naszej aplikacji Web, jak pokazano na rysunku 5.

Rysunek 5: Aplikacja ASP.NET nie działa w trybie klasycznym, ponieważ brakuje modułu IsapiModule.

Uwaga: najlepszą praktyką jest zainstalowanie i włączenie takiego samego zestawu modułów na wszystkich serwerach IIS 7.0. Aby sprawdzić zainstalowane komponenty, przechodzimy do HKEY_LOCAL_MACHINE\Software\Microsoft\InetStp\Components\ i sprawdzamy klucze rejestru. Wartość REG_DWORD równa 0000 0001 dla klucza rejestru, takiego jak NetFxEnvironment lub CGI, wskazuje, że odpowiedni komponent jest zainstalowany.

 Do początku strony Do początku strony

Migracja aplikacji www

Dość teorii, teraz czas zakasać rękawy i przenieść niektóre aplikacje do IIS 7.0. Jak wspomniałem wcześniej, mój próbny serwer ma uruchomiony IIS 7.0 ze wszystkimi dostępnymi komponentami i PHP 5 w trybie bez bezpiecznych wątków zarejestrowanym z FastCGI. Zanim zacznę, muszę zadać sobie kilka podstawowych pytań:

  • Czy aplikacja wymaga systemu zarządzania bazą danych, takiego jak SQL Server lub MySQL?
  • Czy trzeba instalować lub konfigurować dodatkowe komponenty, takie jak połączenia ODBC, obiekty COM lub certyfikaty SSL?
  • Czy aplikacja wymaga specjalnych kont usługi i podwyższonych lokalnie lub zdalnie uprawnień dostępu do udziałów plikowych lub innych zasobów?
  • Czy są jakieś zależności w funkcjach specyficznych dla platform, które nie są dostępne w IIS 7.0, takie jak zależności w module Apache do przepisywania URL (mod_rewrite)?

Zadawanie takich pytań pomoże szybciej uruchamiać nasze aplikacje Web w IIS 7.0. Na przykład, jeśli próbujemy przechodzić do aplikacji PHP z Apache 2.2, który wykorzystuje mod_rewrite (powiedzmy, z życzliwości dla mechanizmu przeszukiwania lub aby się chronić przed zabraniem pasma przez wewnętrznie połączone obrazy), będziemy mieć problem zanim nie zaimplementujemy kompatybilnego rozwiązania niestandardowego przepisywania URL w IIS 7.0.

Na szczęście osCommerce nie wymaga funkcji mod_rewrite w IIS 7.0, lecz wystarczają pakiety optymalizacji mechanizmu przeszukiwania.

Teraz gdy określiłem i zainstalowałem wymagane dodatkowe komponenty na prowizorycznym serwerze, jestem gotów uruchomić moje aplikacje www. Tutaj znów jest kilka pytań, które chcę sobie zadać:

  • Jaka jest najprostsza konfiguracja, której mogę użyć do obsługi aplikacji Web?
  • Jaka konfiguracja jest obecnie stosowana w środowisku produkcyjnym?
  • Czy mogę zoptymalizować konfigurację aplikacji Web na nowej platformie?
  • Jaki jest minimalny zestaw usług i modułów roli, które aplikacja Web potrzebuje do działania w pożądanej konfiguracji?

Uruchamianie aplikacji Web w najprostszej konfiguracji jest szybką metodą sprawdzenia czy ona działa. Jeśli wszystko wygląda dobrze, czas zastosować konfigurację podobną do istniejącego środowiska produkcyjnego i zaimportować dane produkcyjne do testowych baz danych. Oczywiście jakieś problem mogą się ujawnić dopiero w zaawansowanych konfiguracjach.

Można by również zwrócić uwagę na możliwości wprowadzenia ulepszeń przy tworzeniu lustrzanej kopii naszej konfiguracji produkcyjnej w laboratorium testowym. Umieszczenie pliku applicationHost.config na udziale UNC jest doskonałym sposobem zcentralizowania konfiguracji wielu serwerów www.

Aby zwiększyć tolerancję na błędy poprzez nadmiarowość i synchronizację zawartości, rozważmy zaimplementowanie replikacji Distributed File System (DFS). Jest to mechanizm replikacji wielonadrzędnej (ang. multimaster) opartej na stanie, dostępny w Windows Server 2003 R2 oraz Windows Server 2008. Można także zminimalizować wymagania dotyczące pamięci w interfejsach www, umieszczając pliki zawartości aplikacji Web na udziałach UNC.

Inne potencjalne optymalizacje mogą wiązać się z zabezpieczeniami lub dynamicznym buforowaniem. W moim laboratorium testowym nie zajmuję się optymalizacją zabezpieczeń ani wydajności, ponieważ wykracza to poza zakres tego artykułu. Nie konfigurowałem również DFS, aby uniknąć instalowania dalszych serwerów.

W dołączonym materiale znajdują się instrukcje krok po kroku, które podają uproszczony przykład udostępniania pliku applicationHost.config i zawartości Web na udziałach UNC. Na rysunku 6 pokazano, jak za pomocą DFS implementować zespoły serwerów oparte na UNC.

Rysunek 6: Wdrożenie zespołu serwerów Web z plikiem applicationHost.config oraz zawartością Web na udziałach UNC.

 Do początku strony Do początku strony

Podsumowanie

IIS 7.0 jest imponującą platformą serwera Web. Przedstawia przeprojektowaną główną architekturę, pozostawiając blisko 100 procent wstecznej zgodności z 6.0. Powinna pozwolić na uruchamianie bez modyfikacji większości istniejących aplikacji Web ASP.NET. Przy takim zakresie zmian w architekturze, nie można zakładać, że nie napotkamy na problemy z kompatybilnością.

Niezależnie, czy przenosimy aplikacje ASP.NET, czy PHP Web do IIS 7.0, najlepiej przyjąć podejście stopniowe z naciskiem na właściwe planowanie, przygotowanie, testowanie i dokumentowanie kodu oraz zmiany konfiguracji.

IIS 7.0 jest warty włożonej w niego pracy. Ma wiele ulepszeń w takich obszarach, jak bezpieczeństwo, wydajność, konfigurowalność oraz elastyczność. Omówienie ich wszystkich wymagałoby całej książki. Scentralizowana konfiguracja i udostępnianie zawartości w oparciu o udziały UNC, delegowana konfiguracja za pomocą plików web.config w katalogach aplikacji, ulepszone narzędzia zarządzania, szczegółowe informacje diagnostyczne i śledzenie nieudanych żądań oraz buforowanie dynamicznego wyjścia, są pewnymi sposobami podbicia serc administratorów sieci Web.

Z możliwości łączenia modułów wbudowanych w potokach przetwarzania żądań korzystają programiści ASP.NET. A ulepszenia wydajności i stabilności, które zostały wprowadzone wraz z FastCGI w IIS 7.0 są świetnymi wiadomościami dla programistów aplikacji PHP.

Jest jeszcze jedna ważna rzecz, która pomaga specjalistom IT w odniesieniu sukcesu z IIS 7.0: Microsoft IIS Community Portal (www.iis.net). Zawiera on wszystkie potrzebne informacje, obejmujące szczegółowe artykuły o nowej architekturze, kod źródłowy dla programistów C++ oraz ASP.NET, pokazujący, jak tworzyć moduły 7.0, oraz szczegółowe instrukcje wywoływania uruchamiania aplikacji PHP. Trzeba z pewnością sprawdzić tę witrynę. To dobre miejsce, gdzie można w pierwszej kolejności szukać odpowiedzi na pytania związane z IIS.

 Do początku strony Do początku strony

Windows Server 2008