• Artykuł

          

IIS w Windows Azure  

Udostępnij na: Facebook

Autor: Piotr Zieliński

Opublikowano: 2011-01-28

Wprowadzenie

W wersji Azure 1.3 usługi sieciowe hostowane są na prawdziwym IIS. Wcześniej role wykorzystywały Hosted Web Core (HWC), który miał mniejsze możliwości niż IIS (np. nie wspierał hostowania kilku aplikacji webowych). Wcześniej też każda web rola zawierała wyłącznie jedną aplikację. W wersji 1.3 mamy jednak do dyspozycji IIS, dla którego hostowanie kilku aplikacji w jednej roli nie stanowi już żadnego problemu.

Aktywacja IIS

Wykorzystanie IIS w Azure sprowadza się wyłącznie do zmiany jednego pliku konfiguracyjnego (ServiceDefinition.csdef). Wystarczy umieścić poniższy element (domyślnie jest już on dodany):

<Sites>

       <Site name="Web">

             <Bindings>

                    <Binding name="Endpoint1" endpointName="Endpoint1" />

             </Bindings>

       </Site>

</Sites>

Atrybut endpointName jako wartość przyjmuje nazwę zdefiniowanego wcześniej endpoint’a:

<Endpoints>

       <InputEndpoint name="Endpoint1" protocol="http" port="80" />

</Endpoints>

Hostowanie kilku stron  w Azure za pomocą IIS

Aby hostować kilka aplikacji w jednej roli, należy użyć nagłówka HOST (hostHeader). Po otrzymaniu zapytania IIS decyduje, którą stronę zwrócić na podstawie adresu IP, portu oraz nagłówka HOST w HTTP.  Jeśli adres IP oraz port są takie same dla naszych aplikacji, pozostaje nam tylko manipulowanie hostHeader. Modyfikujemy więc plik konfiguracyjny:

<Sites>

       <Site name="Web">

             <Bindings>

                    <Binding name="Endpoint1" endpointName="Endpoint1" />

             </Bindings>

       </Site>

       <Site  name="DrugaStrona" physicalDirectory="PrecompiledWeb\WebSite5">

             <Bindings>

                    <Binding name="Endpoint2" endpointName="Endpoint1" hostHeader="anothersite.example.com"/>

       </Bindings>       

       </Site>

</Sites>

Przede wszystkim mamy dwa elementy Site. Pierwszy z nich przeznaczony jest dla głównej strony skojarzonej z WebRole. Nie występuje w tym fragmencie nic nowego. Natomiast drugi element odpowiedzialny jest za stronę dodatkową. Aby określić fizyczną lokalizację strony, używamy atrybutu physicalDirectory. Ścieżka jest relatywna względem pliku konfiguracyjnego ServiceDefinition.csdef. Najlepiej skorzystać z opcji publikacji strony (menu kontekstowe -> Publish WebSite). Visual Studio automatycznie przekopiuje stronę do wskazanego folderu:

Po określeniu ścieżki do strony należy zdefiniować wiązanie. Korzystamy z tego samego endpoint’a (atrybut endpointName), jednak wpisujemy inny niż domyślny nagłówek host – hostHeader ustawiamy na anothersite.example.com. Następnie możemy opublikować aplikację Azure – pamiętając oczywiście o wcześniejszej lokalnej publikacji dodatkowej aplikacji web, tak aby atrybut physicalDirectory wskazywał poprawną lokalizację.

Następne pytanie brzmi: jak przetestować zaimplementowane rozwiązanie? Wpisując w przeglądarkę adres uzyskany po publikacji, zostaniemy przekierowani do głównej strony skojarzonej z WebRole, ponieważ każda przeglądarka domyślne ustawia nagłówek HOST na wartość podaną w pasku adresu. Aby oszukać przeglądarkę, musimy zmodyfikować plik hosts (znajduje się w folderze Windows\System32\Drivers\etc). Plik hosts zawiera mapowania między różnymi adresami. Wpisujemy w nim następującą linię:

65.52.75.10    anothersite.example.com

W miejsce 65.52.75.10 wstawiamy adres Azure uzyskany po wdrożeniu aplikacji. Można go znaleźć w panelu Azure:

Wpisując teraz anothersite.example.com w przeglądarce, zostaniemy przekierowani do serwera Azure (dzięki wpisowi w hosts), ale w nagłówku http; pole HOST zostanie ustawione na wartość anothersite.example.com – dzięki temu IIS zwróci nam drugą stronę z dopasowanym atrybutem hostHeader.

VirtualDirectory oraz VirtualApplication

W IIS7 istnieją dwa pojęcia: wirtualne katalogi oraz aplikacje. Aplikacja w IIS stanowi mapowanie fizycznej lokalizacji na zdalną, dostępną za pomocą danego protokołu (np. HTTP). Ponadto aplikacja w IIS może mieć przyporządkowany protokół (np. HTTPS lub HTTP) oraz tzw. application pool. Z kolei wirtualny katalog stanowi czyste mapowanie fizycznej lokalizacji na zdalną. Nie można określać odrębnego application pool dla katalogu. Jeśli zatem nie chcemy danego fizycznego katalogu kopiować do folderu aplikacji, możemy zmapować go za pomocą wirtualnego katalogu – wtedy dla zewnętrznych użytkowników będzie widoczny jako zwykła część strony.

Application pools z kolei służą do izolacji zasobów. Aplikacje odpalane w różnych pulach nie dzielą ze sobą zasobów. W przypadku gdy dana aplikacja miałaby wyciek pamięci, nie marnowałaby zasobów przeznaczonych dla aplikacji z innej puli. Przykład:

<WebRole name="NazwaRoli">

  <Sites>

    <Site name="NazwaStrona" physicalDirectory="Strona">

      ...

     <VirtualApplication name=”aplikacja” physicalDirectory="Strona\Pliki" >

        <VirtualDirectory name="Skrypty"

                          physicalDirectory="..\Skrypty" />

        <VirtualDirectory name="Style"

                          physicalDirectory="..\Style" />

      </VirtualApplication>

      ...

    </Site>

  </Sites>

  ...

</WebRole>

Różnice między HWC a IIS

Model hostingowy HWC oraz IIS różnią się między sobą. W HWC metody wejściowe (tzw. EntryPoint) uruchamiane są w tym samym procesie – WaWebHost.exe. W przypadku IIS punkt wejściowy dla roli uruchamia się w WaIISHost.exe,  a aplikacja  webowa w w3wp.exe. Różnica może wydawać się czysto techniczna, jednak powoduje ona kilka nietypowych zachowań.

Pierwsze nietypowe zachowanie dotyczy plików konfiguracyjnych. Preferowanym miejscem dla przechowania konfiguracji w Azure jest ServiceConfiguration.cscfg, jednak programiści wciąż mogą wykorzystywać plik web.config dla roli webowych. W IIS kod zawarty w metodzie startowej (OnStart) dla roli nie będzie mógł jednak uzyskać dostępu do web.config, ponieważ przetwarzany jest w całkowicie innym procesie i domyślnym plikiem konfiguracyjnym jest WaIISHost.exe.config.

Dostęp do zmiennych statycznych współdzielonych przez rolę oraz aplikację webową nie jest już możliwy, co wydaje się logiczne, gdyż pamięć w różnych procesach nie jest wspólna.

Zakończenie

Pełne wsparcie IIS daje nowe możliwości i znacząco ułatwia proces migracji już istniejących aplikacji webowych do chmury. Ze względu na specyfikę działania IIS możliwe jest hostowanie kilku aplikacji webowych w tej samej roli, ale – co ważne ze względu bezpieczeństwa – w różnych pulach (application pool).

          

Piotr Zieliński

Absolwent informatyki o specjalizacji inżynieria oprogramowania Uniwersytetu Zielonogórskiego. Posiada szereg certyfikatów z technologii Microsoft (MCP, MCTS, MCPD). W 2011 roku wyróżniony nagrodą MVP w kategorii Visual C#. Aktualnie pracuje w General Electric pisząc oprogramowanie wykorzystywane w monitorowaniu transformatorów . Platformę .NET zna od wersji 1.1 – wcześniej wykorzystywał głównie MFC oraz C++ Builder. Interesuje się wieloma technologiami m.in. ASP.NET MVC, WPF, PRISM, WCF, WCF Data Services, WWF, Azure, Silverlight, WCF RIA Services, XNA, Entity Framework, nHibernate. Oprócz czystych technologii zajmuje się również wzorcami projektowymi, bezpieczeństwem aplikacji webowych i testowaniem oprogramowania od strony programisty. W wolnych chwilach prowadzi blog o .NET i tzw. patterns & practices.