PowerShell nie jest prostą kopią skryptowych środowisk administracyjnych rodem z Unixa. To pełnoprawny framework i obiektowy język programowania do tworzenia aplikacji administracyjnych w środowiskach Windows/.Net 2.0.

Wygląda na to, że Microsoft znów zdecydował się na poważną zmianę modelu zarządzania aplikacjami. Obok bogatych interfejsów graficznych coraz częściej pojawia się konsola tekstowa, w której administratorzy wprowadzają komendy "z palca". Celem Microsoftu nie jest jednak powrót do starych unixowych tradycji, o czym świadczy najnowsze środowisko administracyjne o nazwie PowerShell. Ma ono zupełnie inną filozofię i zasady działania niż np. powłoki unixowe typu bash czy nawet cmd używane w Windows NT.

Wielka fuzja możliwości

Windows PowerShell (nazwa kodowa Monad) to połączenie pewnych pomysłów z narzędzi ksh/bash, języka typu Ruby (o bardzo czytelnej i prostej składni) oraz modelu obiektowego systemu operacyjnego. Bruce Payette, autor języka PowerShell, porównuje go do stosowanego w AS/400 Command Language (CL) czy VMS Digital Command Language (DCL). Różnica polega na tym, że PowerShell to nie tylko systemowy język skryptowy, ale także pełnoprawny język programowania. Można w nim łączyć elementy dostępne za pośrednictwem infrastruktury WMI, tworzyć własne funkcje, skrypty, klasy, a nawet konstruować okienka Windows Forms. Niezależnie od tego można za jego pomocą tworzyć rozwiązania oparte wyłącznie na linii poleceń.

Tam gdzie w csh czy bash uruchamiamy zewnętrzny proces czy wbudowane polecenie tekstowe, w PowerShell odwołujemy się do modelu obiektowego .Net i tworzymy instancję obiektu, przekazujemy potrzebne parametry analizowane za pośrednictwem ujednoliconego parsera. Taki jednostkowy obiekt wykonujący daną operację nazywa się cmdlet. Zaleta takiego rozwiązania jest dosyć oczywista - do dyspozycji mamy logicznie uporządkowaną strukturę obiektów, a nie olbrzymi zbiór różnorodnych poleceń i "programików pomocniczych".

Za tym idą dalsze zmiany, jak np. możliwość rejestrowania własnych operacji, zamykanie pewnych sekwencji w ramach "złożonego" obiektu cmdlet itp. Obiekty cmdlet są obiektami .Net, można więc ograniczać możliwość ich działania na stacjach roboczych tylko do tych, które są podpisane kluczem administratora domeny. Innymi słowy, PowerShell jest kolejnym językiem działającym w ramach .Net, ukierunkowanym na funkcje administracyjne. PowerShell ma być dostępny w Vista i Longhorn Server, ale też mają być wersje dla starszych systemów operacyjnych (dla wszystkich, na których da się uruchomić środowisko .Net 2.0). Finalny produkt do starszych wersji ma się pojawić pod koniec tego roku, jeszcze przed premierą Vista - obecnie dostępna jest wersja RC1.

Interaktywnie i obiektowo

W ciekawy sposób tworzy się własne mechanizmy rozszerzające PowerShell. Podstawową "szyną" komunikacyjną jest tzw. object pipeline. W powłokach unixowych takim kanałem komunikacyjnym jest tzw. standardowe wyjście. Komunikacja wyglądała w taki sposób, że jeden program zapisywał tekst to strumienia, a kolejny w potoku czytał go i parsował. Nie jest to idealny mechanizm do przekazywania bardziej skomplikowanych struktur. W tym celu, w przypadku obiektu .Net, wypadałoby go odpowiednio "zserializować" i to właśnie w PowerShell zostało zrobione.

Dzięki restrykcyjnej kontroli typów obie strony potoku mogą się łatwo i bezpiecznie odwoływać do właściwości takich obiektów. Jeden cmdlet może pozwalać na wiele różnych sposobów "wyprowadzania" informacji - może ją pokazać jako tekst administratorowi albo - właśnie udostępnić jako kolekcję kolejnemu obiektowi uczestniczącemu w przetwarzaniu potoku.

Jednak równocześnie PowerShell jest środowiskiem interaktywnym. Przede wszystkim nie pisze się w nim dużych bloków programu, lecz wydaje polecenia. Polega to głównie na przekierowaniu do zmiennej tego, co zostało wysyłane do potoku. Tej samej zmiennej można zresztą zaraz potem użyć jako parametru wejściowego dla innego obiektu cmdlet. Warto też dodać, że mechanizm skryptów przewiduje "wykonywanie" operacji (np. na rejestrze) zdalnie, na innych komputerach.

Jeżeli tworzona aplikacja firmy trzeciej ma własne mechanizmy konfiguracyjne, można zdefiniować mechanizm typu provider, który pozwoli administratorowi z poziomu PowerShell manipulować poszczególnymi wpisami. Jeżeli określimy operatory typu "kopiuj", "usuń", "ustaw parametr" - będzie mógł używając skryptów skonfigurować dany system za pośrednictwem PowerShell. Dokumentacja narzuca pewne konwencje określające jak mają być nazwane i zorganizowane takie operatory, by z punktu widzenia administratora praca z pojemnikiem na konfigurację dowolnej aplikacji odbywała się w analogiczny sposób.

Dodanie własnego obiektu cmdlet to tak naprawdę napisanie klasy, która dziedziczy np. z CustomPSSnapIn. W naszym konkretnym przypadku (aplikacja z własnymi narzędziami konfiguracyjnymi) należy oprogramować ogólny interfejs przekazywania parametrów (częścią PowerShell jest ujednolicony parser linii poleceń) oraz elementy związane z konfiguracją.

Następnie taki obiekt trzeba zarejestrować w środowisku i nadać mu odpowiednie uprawnienia. Prawa mogą być także przypisywane poszczególnym funkcjom. Funkcje, klasy czy cmdlety PowerShell uruchamiane są w ramach specjalnego środowiska. Może ono zawierać sesje (runspaces), które konstruują logiczny model uruchomieniowy używając cmdletów, poleceń systemowych czy innych operacji.

Wygodnie i bezpiecznie

PowerShell wygląda bardzo ciekawie, ale jest jeszcze jedno "ale". W świecie Unixów potok i linia poleceń to naturalne sposoby interakcji z aplikacjami. Typowa aplikacja, np. program do nagrywania płyt CD, to tak naprawdę narzędzie dostępne z linii poleceń, do którego potem może powstać zewnętrzny program z graficznym interfejsem użytkownika uruchamiającym w tle narzędzie konsolowe. W takim scenariuszu można napisać skrypt, który na przykład coś przetworzy, skompresuje i nagra. W przypadku aplikacji Windows jest odwrotnie - to interfejs określa to, co ma dziać się "pod spodem".

Obecnie wiele aplikacji pisanych jest w taki sposób, że udostępniają model obiektowy zgodnie z COM, który pozwala "z zewnątrz" sterować ich działaniem. Czasami spotyka się także systemy zawierające odpowiednie komponenty typu WMI provider. Co prawda PowerShell ma mechanizmy, które pozwalają skorzystać z WMI, ale już nie z obiektów COM, a w każdym razie nie bezpośrednio.

PowerShell ma być podstawowym mechanizmem do zarządzania np. Exchange 12. Być może, jeżeli rzeczywiście 100% konfiguracji w Windows da się osiągnąć za pomocą cmdletów, z czasem także inni producenci pójdą tą drogą, oferując odpowiednie interfejsy i mechanizmy do własnych aplikacji.

Można też na to spojrzeć z innej strony. Windows "od zawsze" ma mechanizm tworzenia skryptów administracyjnych - Scripting Engine, w którym rejestrowane są konkretne interpretatory języków, zwykle VBScript i JScript. Ponieważ jednak z tych właśnie mechanizmów najczęściej korzystały konie trojańskie i wszelki inny złośliwy kod, mechanizmy te są obecnie domyślnie blokowane przez systemy antywirusowe i to zwykle bez pytania użytkownika o zgodę. Z podobnych powodów podczas instalacji nowych aplikacji również nie są stosowane mechanizmy VB/JScript.

Dzięki całej warstwie bezpieczeństwa - rozbudowanym mechanizmom autoryzacji, podpisywaniu obiektów, weryfikacji nadawcy - PowerShell zapewnia znacznie większe bezpieczeństwo niż łatwe dla programistów, ale w praktyce niedziałające rozwiązania skryptowe. W środowisku firmowym ze zdefiniowaną polityką bezpieczeństwa PowerShell będzie na pewno godnym (i zdecydowanie lepszym) następcą VBScript czy cmd. Będzie też obsługiwał starsze systemy i łatwo go będzie zainstalować, używając polis GPO. Pozostaje jednak kwestia, czy na komputerach domowych nie pojawi się wkrótce całkiem nowa klasa problemów.

PowerShell a MOM i SMS

Wprowadzanie PowerShell zbiega się w czasie z zapowiedzią pewnych nowości w ofercie rozwiązań administracyjnych Microsoftu. Wraz z wprowadzeniem Visual Studio 2005 Microsoft zaoferował mechanizm DSI - Dynamic System Initiative. Częścią tej inicjatywy są narzędzia wchodzące w skład Visual Studio Team Suite przeznaczone do definiowania "fizycznej" architektury aplikacji (SDM - System Definition Model).

SDM to element projektu aplikacji, model architektoniczny, opisujący rozproszony system. Założenie jest takie, że SDM powstaje przy użyciu narzędzi deweloperskich jako "obraz" aplikacji do wdrożenia. Do tego są dostępne proste mechanizmy sprawdzające, czy dane komponenty mogą działać w tak zamodelowanym środowisku. Mechanizm ma także działać "w drugą stronę", by w ramach rozwiązania można było wykorzystać szablon obrazujący ograniczenia danego środowiska korporacyjnego. SDM może być także narzędziem wspomagającym

system zarządzania infrastrukturą (przynajmniej teoretycznie), informując go o niedostępności określonego zasobu sprzętowego lub logicznego.

Na ostatniej konferencji Management Summit Microsoft zaproponował nową rodzinę narzędzi System Center zastępujących dotychczasowy MOM (Microsoft Operation Manager) i SMS (System Management Server). Jednym z elementów tego rozwiązania jest System Center Service Desk - narzędzie do gromadzenia informacji dotyczących IT - m.in. o procedurach postępowania czy aktualnej konfiguracji. Jest ono pewnego rodzaju łącznikiem pomiędzy MOM - "planowanie" i "monitoring" a SMS - warstwa operacyjna obejmująca konfigurację infrastruktury.

Dzięki SCSD powstaje IT Infrastructure Library oraz Microsoft Configuration Database Management. Rozwiązaniem do przechowywania danych o konfiguracji jest oczywiście SQL Server 2005, przepływem steruje Workflow Foundation, a integracja z innymi narzędziami ma być możliwa dzięki wykorzystaniu BizTalk Ser-ver 2006.

W odróżnieniu od MOM, Service Desk obsługuje pełen przepływ informacji - od zgłoszenia usterki, przez weryfikację i zatwierdzenie przez administratorów, aż po stworzenie pakietu SMS usuwającego problem na serwerze lub stacji roboczej. SCSD przechowa przy tym pełną informację o tym, co dokładnie działo się w korporacyjnej sieci w określonym momencie.

Tak naprawdę jest to narzędzie do zgromadzenia pewnej "wiedzy" o zależnościach pomiędzy systemami. Jeżeli Microsoft zapewni integrację tego rozwiązania także z SDM, co raczej nie stanie się na etapie pierwszej wersji tego pakietu planowanej na połowę 2007 r., będzie można mówić o zmianie jakościowej w dziedzinie utrzymania rozbudowanych rozwiązań IT.

Problemy u podstaw

Problem z zarządzaniem konfiguracją aplikacji przynajmniej częściowo bierze się stąd, że podczas ich tworzenia programista prawie nigdy nie uwzględnia kształtu docelowej infrastruktury. Serwer deweloperski ma zwykle "wygodną" konfigurację, tak by wszystko działało bez zwracania uwagi np. na odpowiednie zabezpieczenia, ograniczenia związane z uprawnieniami itp. Podczas cząstkowych testów funkcjonalnych weryfikacja bywa tylko pobieżna, więc... w trakcie wdrożenia pod presją czasu drobne problemy mogą urastać do dużych.

Inna sprawa, że zespół programistyczny prawie nigdy nie zastanawia się, jak jego "dziełem" administrator ma zarządzać. Dobrze jeżeli w trakcie projektu powstanie dokument opisujący zasady konfiguracji czy chociaż rady dotyczące wdrożenia. Praktyka w tej dziedzinie nie skłania do optymizmu.