Azure dla programistów: jakie możliwości daje deweloperom chmura?

Developers! Developers! Developers! Developers! w wykonaniu Steve'a Ballmera doskonale oddaje filozofię rozwoju Azure, która od początku istnienia chmury Microsoft skupia się na dostarczaniu usług PaaS. Programiści mogą je traktować jak klocki Lego do budowy aplikacji. Przykładami takich klocków są usługi do hostowania aplikacji webowych, bazy danych, które będą poruszone w artykule. Dodatkowo istnieją usługi Azure wspierające pracę deweloperów, takie jak DevTest Lab, odpowiedzialne za automatyzację tworzenia maszyn wirtualnych.

W codziennej pracy dewelopera często wykorzystuje się maszyny wirtualne. Używa się ich jako środowisko pracy, do testów aplikacji czy przetestowania nowej konfiguracji systemu operacyjnego lub tworzonego rozwiązania. Azure posiada usługę DevTest Lab, która ułatwia i rozszerza możliwości używania maszyn wirtualnych przez programistów. Pierwszym ułatwieniem jest automatyczne wyłączanie i włączanie maszyn wirtualnych na podstawie harmonogramu. W Azure rozliczanie pracy odbywa się minutowo, a maszyna używana w celach deweloperskich i testowych zazwyczaj nie musi pracować 24 godziny przez 7 dni w tygodniu. W przypadku działania od 9 do 18, od poniedziałku do piątku, płacimy jedynie 25% kosztów generowanych przez maszynę pracującą cały czas. Innym ułatwieniem są automatycznie instalowane aplikacje oraz skrypty uruchomione w trakcie tworzenia maszyny wirtualnej. Skrypty i aplikacje w DevTest Lab określa się mianem Artefaktów. Aplikacje można wybrać z predefiniowanej listy lub - jeśli jest ona niewystarczająca - stworzyć własne repozytorium.

Aby skonfigurować DevTest Lab, konieczne jest stworzenie usługi. Można to zrobić na wiele sposobów, ale najprostszą drogą jest portal.azure.com. Po zalogowaniu się na stronie, należy przejść do przycisku Nowy (lewy górny róg) i wpisać w wyszukiwarkę DevTest Lab, a następnie wybrać DevTest Lab i – dalej – Utwórz.

W nowym panelu konfiguracji usługi podajemy nazwę usługi DevTest Lab oraz region, w którym ją tworzymy. Dodatkowo w pozycji Automatyczne zamykanie można skonfigurować wyłączanie maszyn wirtualnych o wyznaczonej porze. Można też ustawić wysłanie powiadomienia przed wyłączaniem - przez webhook do innej usługi, np. integrację z popularnym Slackiem. Po wypełnieniu wszystkich parametrów klikamy Utwórz.

Kreator tworzenia nowej maszyny wirtualnej znajduje się w samej usłudze DevTest Lab, uruchamiania się go za pomocą przycisku Dodaj.

Pierwszym krokiem w tworzeniu maszyny wirtualnej jest wybór szablonu (bazy), z jakiej zostanie stworzona. W momencie pisania artykułu jest 170 dostępnych szablonów z różnymi systemami operacyjnymi i preinstalowanym oprogramowaniem. Do wyboru są między innymi maszyny z Windows Server, Ubuntu, FreeBSD, RedHat, Centos, Oracle Linux, Debian czy CoreOS. Po wybraniu bazy należy podać nazwę maszyny wirtualnej, nazwę użytkownika, hasło (w przypadku maszyn z Linuksem może być to również klucz SSH). Dodatkowo wybiera się rozmiar maszyny wirtualnej oraz typ dysku (HDD lub SSD). Klikając na Utwórz rozpocznie się proces wdrażania maszyny wirtualnej. Opcjonalnie przed utworzeniem można wybrać artefakty do zainstalowania na tworzonej maszynie lub zaawansowane ustawienia.

Dodawanie artefaktów polega na wybraniu z listy elementu, który ma zostać zainstalowany. Artefakty są pobierane z publicznego repozytorium Microsoft utrzymywanego w repozytorium GitHub. Istnieje możliwość dodania własnych artefaktów do publicznego repozytorium korzystając z Pull requests, czyli publicznego wysłania propozycji zmiany. Przykładem takiego zewnętrznego artefaktu na liście jest AWS CLI.

Dodatkowo w kreatorze znajdują się zaawansowane opcje konfiguracji. Dwie z nich są szczególnie pomocne. Pierwszą jest automatyczne kasowanie maszyny wirtualnej po wyznaczonej dacie. To przydatne zwłaszcza w sytuacjach, w których maszyna jest tworzona na tak zwane 5 minut, zwykle do sprawdzenia nowej funkcji lub sposobu konfiguracji usługi. Pozwala to na utrzymanie porządku i kosztów w ryzach, bez konieczności pamiętania o sprzątaniu po testach. Drugą opcją jest tworzenie automatycznie wielu takich samych maszyn wirtualnych na podstawie z kreatora. Wystarczy podać, ile maszyn wirtualnych ma zostać wykreowanych. Sprawdza się to w sytuacjach, gdy mamy środowisko złożone z wielu serwerów albo kiedy prowadzimy warsztaty i chcemy mieć spójne środowisko dla każdego z kursantów.

Po utworzeniu w konfiguracji maszyny można sprawdzić jej działanie, adres IP oraz nazwę DNS czy włączyć lub wyłączyć maszynę. Dodatkowo dla maszyn wirtualnych można wygenerować plik połączenia pulpitu zdalnego.

Dodatkowo w konfiguracji całego DevTest Lab można ustawić różnego rodzaju polityki wymuszane na użytkownikach DevTest Lab. Popularne ustawienia to dozwolone rozmiary maszyn do wykorzystania, maksymalna liczba maszyn wirtualnych per użytkownik czy w całym laboratorium oraz wymuszone harmonogramy wyłączania i włączania maszyn wirtualnych.

Jednym z najpopularniejszych scenariuszy użycia serwerów w Internecie jest hostowanie aplikacji przeglądarkowych. W Microsoft Azure możemy to zrobić na kilka sposobów, ale najwygodniejszym jest wykorzystanie platformy jako usługi (PaaS) - Azure Web App. Usługa nie wymaga przygotowania maszyny wirtualnej - wystarczy wgrać swoją aplikację, wprowadzić ustawienia i udostępniać ją użytkownikom. W praktyce Azure Web App to automatycznie zarządzane farmy maszyn wirtualnych z Windows Server i serwerem IIS lub Debiana z serwerem Apache. W dużym uproszczeniu można to porównać do bardzo zaawansowanego hostingu, ale z większą ilością funkcji.

Azure Web Apps wspiera wiele języków programowania takich jak: .NET, Java, PHP, Phyton, Go i node.js. Dodatkowo wersja Web Apps na Debianie pozwala korzystać z kontenerów Dockerowych. Pozwala to na użycie dowolnego języka, który działa poprawnie na Linuksie w kontenerze.

Tworzenie – tak jak w przypadku DevTest Lab – wymaga zalogowania się do portal.azure.com. Następnie należy wybrać przycisk Nowy (lewy górny róg) i wpisać w wyszukiwarkę Web App, wybrać Aplikacja sieci Web i – dalej – Utwórz. Można też skorzystać z innych szablonów, które oprócz Web App utworzą również bazę danych (SQL Database, MySQL lub PostgreSQL). [img=09]Przy tworzeniu należy podać nazwę aplikacji. Jest to publiczna nazwa w domenie azurewebsites.net, ale po stworzeniu można użyć własnej domeny. Dla domeny azurewebsites.net Web App ma skonfigurowany certyfikat SSL. Dodatkowo wybieramy Plan App Servcie. Jest to dedykowana pula maszyn dla aplikacji. Jeden App Service Plan może współdzielić infrastrukturę dla wielu Web App. Domyślnie tworzony App Service Plan jest bezpłatny i pozwala utrzymywać do 10 Web Apps. Ostatnią opcją w kreatorze jest wybór integracji z usługą Application Insight. Application Insight to narzędzie do monitoringu i analizy wydajności aplikacji od strony serwerowej jak i użytkownika.

Główny ekran Web App pokazuje aktualne podstawowe ustawienia, jak adres aplikacji, adres serwerów FTP/FTPS. Daje również możliwości zatrzymania, uruchomienia ponownie lub pobrania profilu publikowania, który zawiera techniczne konto do połączenia się między innymi serwerem FTP.

Do wdrażania aplikacji oprócz FTP można wykorzystać bardziej zaawansowane opcje, takie jak Visual Studio Team Servcies, OneDrive, Lokalne repozytorium Git, GitHub, Bitbucket, Dropbox. Inną możliwą opcją wdrażania jest integracja z rozwiązaniami Continuous Integration/Continuous Delivery, np. Jenkins.Konfiguracja Lokalnego repozytorium Git odbywa się poprzez wybranie go jako źródła w Opcjach Wdrożenia.

Wgrywanie aplikacji do Lokalnego repozytorium Git odbywa się poprzez sklonowanie repozytorium na dysk z wykorzystaniem adresu URL klonowania podanego na pierwszej stronie konfiguracji Web App. Publikacja nowej wersji aplikacji polega na wgraniu jej do repozytorium na lokalnym dysku, a następnie wykonaniu polecenia git commit (zatwierdzeniu zmian w repozytorium) i wypchnięciu nowej wersji plików do Web App za pomocą polecenia git push.

Jedną z zalet wykorzystania repozytorium Git jest możliwość przełączania się pomiędzy wersjami za pomocą kilku kliknięć.

Inną istotną opcją jest skalowanie wydajności Web App za pomocą zwiększania rozmiaru (pionowo) lub dodanie kolejnych serwerów (poziome). Zwiększanie rozmiaru odbywa się poprzez wybór większego planu i restart aplikacji.

Skalowanie poziome odbywa się za pomocą ręcznego ustalenia liczby instancji lub - idąc dalej, w bardziej zaawansowane scenariusze, takie jak automatyczne dodawanie lub usuwanie serwerów - na podstawie obciążenia aplikacji.

Następną przydatną opcją w Web App jest Uwierzytelnianie/autoryzacja na poziomie usługi. Pozwala to na uwierzytelnianie użytkownika za pomocą różnych zewnętrznych usług, takich jak konto Facebook, Google czy za pośrednictwem Office 365 (Azure Active Directory).

Polecenie DROP DATABASE to według popularnego jakiś czas temu filmu o stażyście najszybszy sposób wdrożenia bazy typu NoSQL. Azure posiada równie szybkie do wdrożenia bazy NoSQL, klasyczne bazy relacyjne czy rozwiązania do przechowywanie danych typu Big Data.

Z baz relacyjnych dostępnych jako usługa na Microsoft Azure, możemy wyróżnić usługi zbudowane na trzech silnikach: SQL Database (bazujące na SQL Server), MySQL oraz PostgreSQL. Wszystkie trzy cechuje to, że nie trzeba zarządzać w żaden sposób maszyną na której są uruchomione, mają automatycznie skonfigurowane backupy z 35 dniowym czasem retencji (plany typu Standard i wyżej), lepsze SLA niż maszyna wirtualna czy automatyczne aktualizacje wykonywane za administratora.

Tworzenie - tak jak w poprzednich przypadkach - zaczyna się od zalogowania się do portal.azure.com, przejścia do przycisku Nowy (lewy górny róg) i wpisania w wyszukiwarkę MySQL, następnie należy wybrać Usługa Azure Database for MySQL i – dalej – Utwórz.

Kreator tworzenia nowej instancji MySQL należy wypełnić wymaganymi parametrami, takimi jak nazwa serwera, login administratora i hasło, w jakim regionie ma zostać utworzona instancja czy wersja MySQL i wydajność serwera.

W głównym panelu usługi możemy sprawdzić podstawowe parametry serwera, takie jak wersja, adres serwera, nazwa głównego administratora, aktualną utylizację instancji czy przywrócić dane z kopii zapasowej.

Dostępna konfiguracja samej instancji składa się z kliku elementów. Pierwszym z nich jest zapora sieciowa. Domyślnie przyjmuje ona tylko połączenia z innych usług Azure. Odblokowanie ruchu dla innych adresów odbywa się w prosty sposób, można to zrobić klikając Dodaj mój adres IP lub wprowadzając zakres adresów IP, dla których ma zostać ruch do instancji. Dodatkowo domyślna konfiguracja MySQL w Azure wymusza szyfrowane połączenia do MySQL, ale można to wyłączyć.

Kolejnym elementem konfiguracji jest panel parametrów serwera. Jest to odpowiednik pliku konfiguracyjnego, przez który edytuje się konfigurację serwera jeśli zarządzamy nim samodzielnie.

Funkcją wartą uwagi jest też sposób odtwarzania bazy danych. Przy przywróceniu bazy danych należy wybrać konkretną datę wraz z godziną, z której ma być przywrócona kopia zapasowa oraz podać nową nazwę serwera i kliknąć OK. Na tym polega przywrócenie kopii zapasowej.

Reszta użycia bazy MySQL niczym nie różni się od takiej, którą można zainstalować na własnym serwerze.

Przykładem baz NoSQL jest Azure Cosmos DB. Azure Cosmos DB powstała od podstaw z myślą o dystrybucji globalnej i skalowaniu w poziomie. Oferuje gotową do użycia dystrybucję globalną w dowolnej liczbie regionów oraz skalowanie i replikowanie danych. Cosmos DB zostało stworzone przez Microsoft na potrzeby wewnętrzne już w 2010 roku do obsługi petabajtów danych wytwarzanych między innymi przez usługi związane z Bing.

Samo Cosmos DB to dokumentowa baza danych składająca pojedyncze rekordy w postaci JSON, które nie posiadają sztywnego schematu jak w przypadku bazy relacyjnej. Cosmo DB posiada dwie unikalne cechy na tle innych chmurowych baz NoSQL. Pierwszym jest umowa SLA, która oprócz dostępności definiuje też przepustowość, opóźnienia oraz spójność danych w zależności od trybu sesji. Drugą cechą jest sposób dostępu do danych. Microsoft oferuje 4 tryby dostępu:

• natywny protokół SQL poprzez API Http Rest,
• typu klucz wartość również przez API Http Rest,
• natywne API zgodne z MongoDB
• Gremlin (grafowy język zapytań)

Zgodność z API MongoDB pozwala w łatwy sposób użyć Cosmo DB zamiast MongoDB czy uzyskać przenaszalność aplikacji.Tworzenie nowej instancji Cosmo DB sprowadza się do podania nazwy usługi, wyboru API dostępowego oraz regionu podstawowego, w którym zostanie stworzona.

Najciekawszą funkcją Cosmo DB jest jej replikacja pomiędzy inne regiony Azure, które mogą przechowywać aktualne kopie bazy tylko do odczytu. Pozwala to na tworzenie globalnie dostępnych aplikacji z szybkim dostępem do danych. Sama konfiguracja replikacji polega na przejściu do panelu replikacji, następnie wybrania nowego regionu z mapy, do którego mają być replikowane dane i kliknięciu Zapisz. Dodatkowo jeśli posiadamy już replikę danych w innym regionie to można też zmienić region główny za pomocą ręcznego przepięcia trybu Failover.

W przypadku, gdy chcemy przeprowadzić migrację do NoSQL w sposób lepszy niż DROP DATABASE, dla Cosmo DB dostępne jest narzędzie do automatycznej migracji danych. Dane źródłowe mogą pochodzić z plików JSON, MongoDB, eksportu bazy MongoDB, SQL Server, plików CSV czy Amazon DynamoDB.

Samo narzędzie posiada kreator graficzny, który przeprowadza użytkownika przez migrację oraz w przypadku bardziej zaawansowanych migracji czy też automatyzacji dostępna jest wersja działając z linii poleceń.

Przedstawione usługi to tylko drobny wycinek dostępnych możliwości Azure dla budowy aplikacji i wsparcia programistów.

W następnym artykule zostanie przedstawiony sposób budowy aplikacji do przetwarzania i raportowania danych na przykładzie otwartych danych z transakcji na brytyjskim rynku nieruchomości.

Korzystając z okazji, zachęcam do udziału w konkursie Upoluj serwer2, w ramach którego powstał ten artykuł.

Jeśli macie pytania na temat Azure lub interesują Was inne kwestie z nim związane, zapraszam do pozostawienia komentarza.