SoftGrid – wirtualizacja aplikacji, cz. I - Instalacja

Autor: Barbara Wróbel

Opublikowano: 26 czerwca 2007

Zawartość strony

	Wstęp
	Idea działania
	Powstawanie pakietu
	Konfiguracja aplikacji
	Przeczytaj pozostałe części tego artykułu

Wstęp

Od lat jednym z podstawowych wyzwań, któremu każdego dnia stawiali czoło administratorzy była instalacja aplikacji. Radzono sobie z tym na różne sposoby. Począwszy od indywidualnego podejścia do klienta, czyli „ręcznego” instalowania aplikacji na każdym komputerze po rozwiązania bardziej zaawansowane, jak chociażby wykorzystanie w tym celu możliwości Group Policy czy też System Management Server. Trzeba przyznać, że pomysłów na realizację procesu instalacji było wiele.

Tuż obok dotychczasowych rozwiązań coraz głośniej ostatnio o nurcie technologii bazujących na wirtualizacji. Microsoft SoftGrid, będący niejako produktem nabytym przez Microsoft na skutek przejęcia firmy Softricity, udowadnia, że właśnie technologie wirtualizacji aplikacji mogą wnieść zupełnie odmienne podejście do kwestii instalacji i działania oprogramowania. Projektanci tego rozwiązania starali się skupić przede wszystkim na następujących wyzwaniach funkcjonowania aplikacji:

• Zapewnienie centralnego zarządzania aplikacjami i ich składowania przy jednoczesnym wykorzystaniu mocy obliczeniowych stacji klienckich
• Eliminowanie konfliktów aplikacji (również konfliktów wynikających z równoległego działania kilku wersji tej samej aplikacji na jednej maszynie), co szczególnego znaczenia nabiera w środowiskach terminalowych
• Szybkie i efektywne dostarczanie aplikacji z uwzględnieniem ograniczeń wynikających z przepustowości łącz
• Kontrola licencjonowania aplikacji
• Kontrola rzeczywistego wykorzystania aplikacji
• Sprawne uaktualnianie aplikacji

Jaki twórcy SoftGrid mieli pomysł na realizację tych celów prześledzimy w poniższym artykule, przy okazji uczestnicząc w procesie wdrażania nowej, wirtualnej aplikacji.

 Do początku strony

Idea działania

Tradycyjna instalacja i funkcjonowanie większości obecnych aplikacji pociąga za sobą konieczność ingerencji w system operacyjny. Oprogramowanie podczas instalacji dokonuje zwykle w mniejszym lub większym stopniu modyfikacji tak kluczowych elementów systemu, jak rejestr, biblioteki dll czy chociażby pliki ini. Oczywiście nie pozostaje to bez wpływu na funkcjonowanie systemu i to często wpływu negatywnego. SoftGrid zmienia diametralnie ten model zachowania. Eliminuje bowiem konieczność instalacji aplikacji bezpośrednio na stacji klienckiej, a tym samym ingerencji w system. Aplikacja może być bez problemu uruchomiona na kliencie, ale wcale nie musi wcześniej być na nim zainstalowana. Zanim zobaczymy jak tego dokonuje, wymieńmy trzy podstawowe elementy SoftGrid, dzięki którym to jest możliwe, a mianowicie:

• SoftGrid Virtual Application Server
• SoftGrid for Windows Desktops Client
• SoftGrid Sequencer

Cały proces wdrażania aplikacji rozpoczyna się zwykle od zastosowania ostatniego z wymienionych komponentów, czyli sequencera. Przy jego użyciu utworzony zostaje pakiet aplikacji, który następnie umieszczany jest na serwerze. Stamtąd już rozpoczyna się jego dystrybucja do klientów. Każda zapakowana w ten sposób aplikacja dostarczana jest do klienta w postaci strumienia i tworzy swego rodzaju zamknięte, wirtualne środowisko kontrolowane przez mechanizm o nazwie System Guard. Taka aplikacja dysponuje własnymi „wirtualnymi” kluczami rejestru i osobistym zestawem plików niezbędnych do jej funkcjonowania, do których to ma pełne uprawnienia. Natomiast dostęp do rzeczywistego rejestru na stacji klienckiej, czy też znajdujących się tam plików systemowych, jest przyznawany jej już tylko na prawach odczytu, co zapobiega ewentualnemu uszkodzeniu tych elementów systemu.

Takie odizolowanie oprogramowania ma też oczywiście plusy w przypadku konieczności zainstalowania aplikacji, które w normalnym środowisku nie mogłyby współistnieć ze względu na konflikty, które pomiędzy nimi zachodzą. Za sprawą SoftGrid każda aplikacja żyje we „własnym świecie” nie zakłócając działania innego oprogramowania.

Teraz już nie ma problemu, by na jednym systemie zainstalować chociażby dwie wersje Office: Office 97 i Office 2003. I tu może ktoś zapytać, po co właściwie jednemu użytkownikowi dwie wersje Office równocześnie? Potrzeba takiej instalacji wcale nie wydaje się już tak nieuzasadniona, gdy przypomnimy sobie o usługach terminalowych. To zwykle serwer usług terminalowych dostarcza aplikacji klientom o różnego rodzaju potrzebach. Do tej pory, by móc korzystać z kilku wersji tej samej aplikacji, konieczne często było instalowanie ich na oddzielnych serwerach terminalowych lub skorzystanie z oprogramowania firm trzecich. Obecnie, dzięki specjalnej wersji SoftGrid przeznaczonej dla obsługi usług terminalowych, jeden serwer terminalowy bez problemu może udostępniać kilka wersji tego samego oprogramowania.

Ale przecież nie tylko równoległe wersje tego samego oprogramowania są problemem. Tak naprawdę wdrażanie każdej nowej aplikacji wymaga wcześniejszego przetestowania, czy przypadkiem szkodliwie nie wpłynie na pozostałe istniejące już aplikacje. SoftGrid, dzięki swojej idei działania, eliminuje konieczność tego rodzaju testów.

Za chwilę posłużywszy się przykładem wdrożenia aplikacji Adobe Reader, i prześledzimy bliżej konfigurację trzech wspomnianych na początku komponentów SoftGrid. Zanim to jednak nastąpi jedna bardzo ważna uwaga. Pomimo dużych możliwości SoftGrid nie każdy rodzaj oprogramowania jest on w stanie obsługiwać. Do kategorii oprogramowania, z których wirtualizacją SoftGrid sobie nie poradzi, należą na pewno: Internet Explorer, sterowniki urządzeń, poprawki systemowe, oprogramowanie antywirusowe. Wszystko są to elementy zbyt ściśle powiązane z systemem, by ich wirtualizacja mogła się udać.

 Do początku strony

Powstawanie pakietu

Pomimo, iż to SoftGrid Virtual Application Server jest sercem całego systemu zaczniemy od punktu, gdzie wszystko się zaczyna, czyli od stworzenia pakietu aplikacji. Narzędziem, które posłuży temu celowi, jest SoftGrid sequencer. Nadzoruje on proces instalacji, by następnie na podstawie analizy tego procesu stworzyć odpowiedni pakiet. Dla ułatwienia można posłużyć się tu specjalnym kreatorem, co też poniżej zrobimy. W tym celu należy z menu „File” sequencera wybrać „New package…”, które to polecenie de facto, jak się zaraz okaże, przeprowadzi nas poprzez trzy odrębne kreatory (Package Configuration Wizard, Installation Wizard oraz Application Wizard).

I choć kreator kojarzy się zwykle z czymś banalnie prostym, co wymaga w dużej mierze zatwierdzania tego, co proponuje, tutaj aż tak prosto nie będzie. Na jego poszczególnych etapach trzeba będzie podejmować dość świadome decyzje, a prawie każda pomyłka będzie skutkować tym, że po prostu aplikacja potem nam na kliencie nie zadziała. Już nawet przed uruchomieniem kreatora należy właściwie wybrać maszynę, na której zostanie on uruchomiony. Bardzo zalecane jest, by była to maszyna z czystym systemem operacyjnym, bez żadnego dodatkowego oprogramowania (które mogłoby zafałszować obraz zmian instalacyjnych aplikacji) i co najważniejsze, musi ona posiadać dodatkową partycję oznaczoną literką Q. Dlaczego? Z bardzo prostego powodu. Podczas podłączania się klienta do serwera generowany jest wirtualny dysk Q, na którym to dysku SoftGrid umiejscawia aplikację na czas jej uruchomienia. By zatem aplikacja posiadała w tworzonym pakiecie odpowiednie odwołania do tego dysku, musi on być właśnie wskazany w procesie tworzenia pakietu jako miejsce instalacji (tak zupełnie na marginesie - dysk Q jest domyślnym dyskiem, lecz oczywiście istnieje możliwość jego zmiany).

Ale wracając do naszego kreatora „New package…” - na wstępie określamy w nim w polu „Suite Name” nazwę naszej aplikacji. Przy ustalaniu tytułu aplikacji i komentarza (pola „Title” i „Comments”) tak naprawdę mamy pełną dowolność, choć oczywiście zdrowy rozsądek jak zwykle podpowiada, żeby wpisać tu coś, co jednak będzie nam się kojarzyło z aplikacją.

Poniżej na formatce mamy kilka pól, które są dla naszego procesu strategiczne, a mianowicie:

• „protocol” – określamy tu protokół, którym aplikacja będzie przesyłana z serwera do klienta; domyślnie jest to protokół RTSP ale również można wybrać tu połączenie szyfrowane w oparciu o protokół RTSPS
• „hostname” – nazwa serwera SoftGrid
• „port” – wykorzystywany numer portu, w przypadku protokołu RTSP jak widać domyślnie jest to 554
• „path” – ścieżka określająca położenie pakietu

Tu skupmy się może na ostatnim polu „path”. By zrozumieć jego znaczenie odwołajmy się na chwilę do instalacji SoftGrid Virtual Application Server. Podczas tej instalacji wskazywany jest katalog „content”, w którym będą składowane wszystkie utworzone pakiety. W katalogu tym można utworzyć podkatalogi dla poszczególnych aplikacji i nazwę właśnie takiego podkatalogu (w tym przypadku adobe_reader) należy tu podać (Rys. 1). Po utworzeniu pakietu aplikacji przekopiujemy wszystkie pliki wchodzące w jego skład do katalogu content\ adobe_reader na serwerze.

Rys. 1. Nazwa podkatalogu.

Następnie wybieramy systemy, dla których pakiet ma być dostępny (Rys. 2).

Rys. 2. Systemy, dla których pakiet ma być dostępny.

Przechodzimy do określenia, czy chcemy użyć kompresji w momencie przesyłania strumienia do klienta oraz ustalamy wartość pola „block size” (Rys. 3). Parametr „block size” określa wielkość przesyłanego bloku w drugiej fazie przesyłania aplikacji. I jakkolwiek tajemniczo by to nie brzmiało, na razie nie podejmę dokładniejszej próby wyjaśniania tego terminu. Zapamiętajmy go jednak, gdyż za chwilę do niego powrócimy.

Rys. 3. Wartość pola „block size”.

Po przejściu dalej pojawia się znajomy moment dla tych wszystkich, którzy choć raz w życiu tworzyli pakiet instalacyjny (chociażby za pomocą programu WinInstall), w którym po kliknięciu przycisku „Begin Monitoring...”, rozpoczyna się analizowanie przebiegu instalacji (Rys. 4).

Rys. 4. Analizowanie przebiegu instalacji.

Przykładowo instalowaną aplikacją jest tu akurat Adobe Reader. Zwróćmy jednakże uwagę na lokalizację, którą dla niego podajemy. Zgodnie z tym, co było powiedziane wcześniej, umieszczamy naszą aplikację na dysku Q i podajemy katalog, w którym zostanie ona zainstalowana. Nazwa tego katalogu powinna być zgodna z formatem 8.3, co między innymi wyklucza możliwość użycia spacji (Rys. 5).

Rys. 5. Nazwa katalogu zgodna z formatem 8.3.

Po zakończeniu procesu instalacji poproszeni jesteśmy jeszcze o wskazanie katalogu, do którego aplikacja była instalowana, czyli w naszym przypadku Q:\adobe (Rys. 6). Zalecane jest również, by w tym punkcie kreatora uruchomić aplikację w celu odpowiedniego, wstępnego jej skonfigurowania, np. by zatwierdzić umowę licencyjną, która pojawia się zwykle podczas pierwszego uruchomienia aplikacji.

Rys. 6. Wskazanie katalogu, do którego aplikacja była instalowana.

Następnie możemy również dodać do pakietu wszystkie te pliki, które nie znalazły się tam w czasie instalacji, a które naszym zdaniem powinny tam zostać umieszczone. Domyślnie kreator dodaje tu pliki związane z Microsoft Installer (Rys. 7). W przypadku, gdy instalowana aplikacja nie jest aplikacją typu msi możemy tutaj wybrać „Do nothing”.

Rys. 7. Domyślnie kreator dodaje pliki związane z Microsoft Installer.

 Do początku strony

Konfiguracja aplikacji

Skoro rzeczywisty proces instalacji mamy już za sobą, należy jeszcze aplikację w pakiecie odpowiednio skonfigurować. Jak widać poniżej, SoftGrid na podstawie odnalezionych skrótów sam proponuje co można uznać za aplikację. Oczywiście pozostawiamy tutaj tylko to, co naprawdę chcemy opublikować dla klienta – w tym przypadku Adobe Reader 8, resztę usuwamy (Rys. 8). W tym okienku kreatora korzystając z przycisku „Edit” możemy również określić miejsce, gdzie skrót do danej aplikacji chcemy umieścić u klienta (czyli czy ma być to pulpit, menu start, czy też jakieś inne miejsce). Dodatkowo dokonujemy wyboru rozszerzeń, z którymi dana aplikacja ma zostać skojarzona i przechodzimy dalej.

Rys. 8. Konfiguracja aplikacji.

Wreszcie stajemy przed niepozorną formatką zatytułowaną „Launch aplications” (Rys. 9). Jak sugeruje jej nagłówek, naszym zadaniem będzie to uruchomienie aplikacji. Nie jest to jednak takie zwyczajne uruchomienie. Na skutek niego aplikacja podzielona zostaje na dwie części. Pierwsza część zawierać będzie wszystko to, co jest absolutnym minimum, by uruchomić aplikację. Jeśli chcemy, by zawierała jeszcze jakieś dodatkowe funkcjonalności aplikacji - również w tym momencie należy się do nich odwołać poprzez ich otwarcie. Część pierwsza zajmuje zwykle około 20-40% wielkości całego pakietu aplikacji i jest przesyłana do klienta w całości, gdy po raz pierwszy uruchomi on aplikację. Reszta danych aplikacji znajdzie się w drugiej części. I tu właśnie powróćmy do wspomnianego wcześniej, zagadkowego pola „block size” (Rys. 3). Otóż część druga aplikacji tak naprawdę przesyłana jest tylko wtedy, gdy nastąpi taka potrzeba i w odróżnieniu od części pierwszej nie jest ona przesyłana w całości. Część druga podzielona jest na bloki, których rozmiar określony jest właśnie przez parametr „block size” i w postaci takiego strumienia bloków następuje dostarczanie danych.

Rys. 9. Formatka „Launch aplications.

Tym sposobem zakończyliśmy proces instalacji i konfiguracji pakietu aplikacji. Pozostaje już tylko jego zapisanie i przeniesienie utworzonych w ten sposób plików na serwer. Pliki te będą mieć następujące rozszerzenia:

• .sft – główny plik zawierający aplikację
• .ico – plik ikony aplikacji
• .osd – plik odpowiedzialny za wywołanie aplikacji na kliencie
• .sprj – plik projektu

 Do początku strony

Przeczytaj pozostałe części tego artykułu

• SoftGrid – wirtualizacja aplikacji, cz. II: zarządzanie

Do początku strony