Konsolowa aplikacja działająca w chmurze, czyli Azure WebJobs okiem początkującego

Azure WebJobs, Microsoft Azure

W wielu znanych mi firmach aplikacje typu LOB (Line of Business) są coraz częściej przenoszone do chmury. Już nie tylko portale dla klientów oraz partnerów biznesowych, ale również systemy CRM, ERP, ESB i inne z różnych przyczyn wynoszone są poza infrastrukturę organizacji. Z moich doświadczeń za decyzją o przeniesieniu lub uruchomieniu systemu w chmurze stoją zazwyczaj kwestie finansowe oraz możliwość dostarczenia danej, pożądanej funkcjonalności w niezwykle krótkim czasie. Znany jest mi przypadek pewnej firmy, w której koszt wdrożenia systemu CRM za pomocą własnego działu IT i wewnętrznej infrastruktury utrzymywanej przez tenże dział (bez kosztów utrzymania oraz implementacji ewentualnych zmian funkcjonalnych!) był porównywalny ze stworzeniem, wdrożeniem przez zewnętrznego dostawcę oraz utrzymaniem systemu w chmurze przez około 10 lat (!). Nie dziwie się, że słysząc o podobnych przypadkach biznes, jeśli tylko może „omija” własny dział IT i coraz chętniej korzysta oferty dostawców rozwiązań chmurowych.

Tyle tytułem wstępu (a właściwie nic niewnoszącej do tematu dygresji :)), właściwym tematem tego tekstu jest bowiem uruchomienie prostej aplikacji .EXE na infrastrukturze Microsoft Azure. Jakiś czas temu spotkałem się z wymaganiem, polegającym na przenoszeniu danych wpisanych w formularz kontaktowy na stronie WWW (Azure Web Site) do Microsoft Dynamics 365. W docelowym systemie dane z formularzy miały pojawiać się jako rekordy potencjalnych klientów (lead). Nadrzędnym założeniem budowanego rozwiązania (oczywiście poza dostarczeniem określonej funkcjonalności) miała być prostota oraz niski koszt utrzymania. Omawiana funkcjonalność nie była w żaden sposób krytyczna dla biznesu klienta. Stanowiła ona jedynie dodatek („nice to have”) do budowanego zupełnie w innym celu systemu. Na etapie analizy, ze względu na koszt utrzymania oraz niewielkie potrzeby (przeniesienie kilkudziesięciu rekordów na dobę) odpadły opcje utrzymywania omawianego komponentu wewnętrznie, lub w modelach IasS (Infrastructure as a Service z wykorzystaniem Azure Virtual Machines) lub PaaS (Azure Worker Roles). Pojawił się natomiast pomysł wykorzystania technologii Azure WebJobs, która to (ze względu na prostotę tworzenia oraz utrzymywania oprogramowania) idealnie pasowała do omawianego scenariusza.

W tym miejscu pragnę zaznaczyć, że poniższy tekst zawiera głównie spostrzeżenia początkującego w omawianym temacie. Być może pewne omawiane kwestie da się rozwiązać w inny, lepszy sposób. Celem artykułu jest jedynie zasygnalizowanie pewnych tematów oraz problemów, które możemy napotkać w czasie pierwszych „macanek” z aplikacjami konsolowymi, uruchamianymi w chmurze MS.

Czym jest Azure WebJob? Jest to po prostu aplikacja konsolowa, uruchamiana na infrastrukturze Microsoft Azure w kontekście istniejącego Web Site’u. Nie wymaga ona uruchamiania żadnych nowych komponentów, usług lub systemów operacyjnych w chmurze. Może być uruchamiana cyklicznie, na żądanie lub działać w sposób ciągły. Nie będę w tym miejscu koncentrował się na szczegółach implementacji. Zakładam, że każdy średnio zaawansowany czytelnik potrafi za pomocą .NET odczytać dane z bazy SQL jednego systemu i wysłać je przez usługę sieciową do innego. Chciałbym natomiast zwrócić uwagę na kilka kwestii, z którymi nie byłem wcześniej zaznajomiony, a którym musiałem poświęcić nieco czasu, żeby ostatecznie uruchomić stworzony komponent w chmurze.

Konfiguracja Azure WebJob Dashboard & Storage

Azure Dashboard and Storage wykorzystywane są w największym skrócie do gromadzenia (storage) oraz prezentowania (dashboard) informacji nt. przebiegu działania oraz ewentualnych błędów naszej aplikacji. Świetny tekst, opisujący działanie ww. komponentów znajdziecie na stronie: https://blog.kloud.com.au/2016/03/14/azure-webjob-logs-demystified/. Przed pierwszym uruchomieniem naszego programu w chmurze powinniśmy skonfigurować parametry połączenia do ww. usług. Musimy zrobić to w ustawieniach naszej głównej aplikacji.

Pomimo tego, że tworząc z poziomu Visual Studio projekt WebJoba otrzymujemy domyślnie App.config zawierający omawiane wpisy, aplikacja po wdrożeniu do chmury nie jest w stanie z nich skorzystać.

1
2
3
4
5
6
<connectionStrings>
<!-- The format of the connection string is "DefaultEndpointsProtocol=https;AccountName=NAME;AccountKey=KEY" -->
<!-- For local execution, the value can be set either in this config file or through environment variables -->
<add name="AzureWebJobsDashboard" connectionString="" />
<add name="AzureWebJobsStorage" connectionString="" />
</connectionStrings>
<connectionStrings>
<!-- The format of the connection string is "DefaultEndpointsProtocol=https;AccountName=NAME;AccountKey=KEY" -->
<!-- For local execution, the value can be set either in this config file or through environment variables -->
<add name="AzureWebJobsDashboard" connectionString="" />
<add name="AzureWebJobsStorage" connectionString="" />
</connectionStrings>

Konfiguracja parametrów połączenia na poziomie całej aplikacji rozwiązuje omawiany problem. Działający panel przedstawia się natomiast następująco:

Logowanie błędów oraz przebiegu aplikacji (trace)

Tworząc aplikację zaimplementowałem logowanie informacji o jej przebiegu za pomocą klasy System.Diagnostic.Trace. Informacje zbierane w ten sposób możemy zapisywać w zdalnym systemie plikowym naszej aplikacji hostowanej w chmurze lub w usłudze Azure Storage w pojemnikach typu Blob. Z różnych przyczyn (takich jak np.: konieczność stosowania dodatkowych narzędzi takich jak konsola lub klient FTP lub uciążliwe przeklikiwanie się przez Portal Azure w celu odnalezienia interesujących informacji ) żadna z tych metod nie wydawała mi się optymalna. Pomyślałem, że dobrze byłoby mieć możliwość weryfikacji działania aplikacji z poziomu wspomnianego w poprzednim punkcie panelu informacyjnego. Niestety, za pomocą narzędzi dostępnych z poziomu portalu Azure nijak nie mogłem uzyskać pożądanego rezultatu. Rozwiązanie problemu okazało się banalne. Okazało się, że informacje „wyrzucane” na konsolę za pomocą metody System.Console.WriteLine (lub pokrewnych) są widoczne z poziomu panelu webowego w ramach standardowego „outputu” uruchamianej aplikacji :).

Rozwiązanie to wiąże się oczywiście z pewnymi minusami,  takimi jak np.: brak możliwości jakiejkolwiek konfiguracji poziomów logowania, definiowania polis oraz docelowego miejsca logowania, a także brak możliwości ściągnięcia plików z informacjami na lokalny dysk. W bardzo prostych scenariuszach takich jak opisywany powyżej, sprawdza się natomiast doskonale. Oczywiście możemy również połączyć obie metody i poza tradycyjnym „trace’owaniem” przebiegu informacji – wyrzucać co bardziej istotne informacje na standardowe wyjście.

Połączenie FTP.

Na początku moja aplikacja wdrożona w środowisku Azure nie uruchamiała się poprawnie i nieładnie mówiąc „rzygała dziwnymi błędami”. Pierwsza myśl, która przyszła mi do głowy polegała na weryfikacji tego, czy wszystkie niezbędne pliki aplikacji zostały zapisane w chmurze właściwie (aplikację umieściłem na serwerach MS za pomocą dostępnego z poziomu Visual Studio narzędzia Web Deploy). Postanowiłem sprawdzić, jakie pliki faktycznie znajdują się w chmurze, łącząc się ze zdalnym systemem za pomocą protokołu FTP. Niestety pierwsze próby połączeń zakończyły się niepowodzeniem. Finalnie okazało się, że nazwa użytkownika FTP, którą definiujemy na portalu Azure w sekcji „Deployment Credentials” przy połączeniu FTP musi zawierać dodatkowo informacje o naszej aplikacji webowej. Czyli: „NazwaAplikacji\NazwaUżytkownika”, zamiast po prostu „NazwaUżytkownika”. Zanim odkryłem co i jak, kolejne kilkanaście minut poszło się kochać.

Tak wiem… Straszna lameriada z mojej strony… Zwłaszcza, że pełną, wymaganą nazwę użytkownika FTP możemy odnaleźć na portalu w sekcji „Overview” naszej aplikacji :).

Kiedy już przebrnąłem przez ww. tematy i pozostawiłem działającą w chmurze aplikację samej sobie, do głowy przyszła mi następująca myśl: „Jakie to cholernie proste”:D. Zamierzam zgłębiać omawiany temat w najbliższym czasie. Wszystkie znaki na ziemi i niebie wskazują bowiem na to, że w nadchodzących latach (choćbyśmy bardzo chcieli) od chmurowego potwora nie uciekniemy.

Total Views: 650 ,