Deployment aplikacji – jak wdrażać projekt w chmurę

Na początku artykułu chciałem zaznaczyć, że wszystkie zaprezentowane poniżej metody zostały omówione na przykładzie aplikacji webowych – WebApps. Wydaje mi się, że są one najlepszym typem aplikacji na sam początek, zwłaszcza jeśli chodzi o zobrazowanie poszczególnych komponentów Azure’a oraz sam deployment aplikacji na serwer. Innymi rodzajami omówionymi w poprzednim artykule zajmiemy się w przyszłości.

Deployment polega na przeniesieniu źródeł – skryptów (np. PHP czy JavaScript) lub skompilowanych binarek (ASP.NET), do katalogu /site/wwwroot na serwerze znajdującym się w chmurze. Można wykorzystać tutaj tradycyjny protokół FTP, przenieść aplikację z wykorzystaniem narzędzi i środowisk developerskich takich jak np. Visual Studio lub przygotować specjalną paczkę – Web Deploy Package, która później zostaje wrzucona za pośrednictwem PowerShell’a. Jedziemy 🙂

Wrzucanie plików za pomocą FTP oraz FTPS

Najprostsza możliwa metoda. Łączymy się z Azure za pomocą protokołu FTP (lub FTPS, gdy chcesz czuć się bezpieczniej) i przenosisz pliki z lokalnego komputera na serwer znajdujący się w chmurze. Podstawowe informacje na temat samego połączenia FTP (nazwę hosta, użytkownika) znajdziesz w zakładce właściwości (properties) web aplikacji. Jeśli nie znasz danych potrzebnych do uwierzytelnienia, albo chcesz dodać nowego użytkownika, odwiedź zakładkę Poświadczenie wdrożenia (deployment credentials) w której możesz dodać nowe konto lub zmodyfikować hasło już istniejącego. Do skopiowania plików na serwer możesz wykorzystać programy takie jak FileZilla czy TotalCommander.

Formularz dodawania użytkowników dla deploymentu
Formularz dodawania użytkowników dla deploymentu

Dostęp do serwera za pośrednictwem Kudu Debug Console

Pliki można ręcznie przenieść za pomocą portalu Kudu. Możesz się do niego dostać klikając zakładkę Narzędzia zaawansowane (Advanced tools), a następnie w przejdź. W przeglądarce zostanie otwarta nowa karta z lekko zmodyfikowanym adresem web aplikacji. W adresie została dodana fraza scm: [nazwa- aplikacji].scm.azurewebsites.com – warto zapamiętać ten link. O ile się nie mylę, skrót ten pochodzi od Site Content Manager. Następnie rozwijamy zakładkę Debug Console i wybieramy CMD. W przeglądarce zostanie wyświetlona cała struktura katalogów znajdujących się na serwerze (screen poniżej). Wybieramy folder site, a następnie wwwroot. W tym miejscu możesz już przenosić pliki pojedynczo, lub przeciągnąć plik *.zip (drag and drop) zawierający źródła aplikacji. Spakowana paczka zostanie automatycznie rozpakowana przez Kudu.

Deployment aplikacji z wykorzystaniem portalu Kudu
Deployment aplikacji z wykorzystaniem portalu Kudu

Portal Kudu jest dołączany jest do każdej aplikacji. Wykorzystywany jest do analizy oraz debugowania wszelkich problemów. Podejrzysz tutaj zmienne środowiskowe, dostępne na maszynie wirtualnej, logi aplikacji oraz WebJob’ów (bez konieczności pobierania ich przez FTP). Dostęp do plików pozwala na tzw. „live editing”. Klikasz w plik, uruchamia się prosty edytor tekstowy, dzięki któremu możesz modyfikować ich zawartość np. na produkcji (proszę mi tego używać tylko w nagłych przypadkach!). Masz również dostęp do konsolki systemowej. Kudu jest otwartym projektem, postęp prac jak i kod źródłowy można przejrzeć na GitHubie.

Systemy kontroli wersji oraz aplikacje hostujące pliki w chmurze

Jednym z najatrakcyjniejszych sposobów na deployment aplikacji jest wykorzystanie zdalnych repozytoriów takich jak np. GitHub czy Bitbucket. Metoda ta doskonale sprawuje się w przypadku, gdy nad projektem pracuje wielu programistów. Z każdym wypchniętym commit’em uruchamiany jest continuous deployment, dzięki któremu stan aplikacji jest automatycznie aktualizowany.

Zacznijmy od konfiguracji. W zakładce Wdrożenie aplikacji (App Deployment) kliknij w Opcje wdrożenia (Deployment options). Wybierz jedno z dostępnych źródeł z list (u mnie padło na GitHub’a). Następnie będziesz musiał dokonać autoryzacji – powiązania wybranego źródła z Azure’m. Kolejnym krokiem jest wybranie z którego repozytorium będą pobierane pliki. Na sam koniec pozostaje wybór interesującego nas branch’a (prawdopodobnie będzie to master). Testy wydajnościowe zostawmy na razie w spokoju. Klikaj OK. Po kilku sekundach, w górnym prawym rogu, powinieneś zobaczyć powiadomienie o zakończonej konfiguracji.

Źrodła deploymentu aplikacji
Źrodła deploymentu aplikacji

Klikając ponownie na Opcje wdrożenia powinieneś zobaczyć historię ostatnich zmian. W moim przypadku podpiąłem dopiero co stworzone repozytorium, dlatego znajduje się tam tylko „Initial commit”. Klikając w niego można podejrzeć nieco więcej szczegółów, np. kto jest autorem ostatnich zmian lub jak długo trwał deployment aplikacji na serwer. Możesz spróbować zmodyfikować na GitHub’ie plik readme i podejrzeć czy coś zmieniło się w historii wdrożeń. Proponuję jeszcze odwiedzić aplikację za pośrednictwem Kudu i sprawdzić, czy zmiany wprowadzone z poziomu GitHub’a są już w chmurze. Gdybyś z jakiego powodu stwierdzisz, że nie chcesz już korzystać z wskazanego repozytorium (np. z powodu zmiany jego adresu lub branch’a) wystarczy że w zakładce Opcje wdrożenia klikniesz przycisk Rozłącz (disconnect) – u góry.

Proces integracji z aplikacjami przechowującymi pliki w chmurze, typu OneDrive czy Dropbox przebiega podobnie. W sekcji źródeł wybierz OneDrive i dokonaj autoryzacji. Następnie zamiast repozytorium wskaż folder, z którego będą pobierane pliki z kodem źródłowym. Jeśli wśród nich dojdzie do jakiejkolwiek zmiany, zostanie wykonany automatyczny deployment aplikacji. Wystarczy, że tylko skopiujesz pliki do folderu, proces synchronizacji rozpocznie się automatycznie.

Deployment aplikacji z wykorzystaniem Visual Studio

Publikowanie aplikacji za pośrednictwem Visual Studio wymusza jej lokalne przebudowanie przed każdym wdrożeniem na serwer. Zaczniemy od stworzenia domyślnej aplikacji webowej (niech to będzie ASP.MVC). Kiedy IDE zainicjuje projekt (możesz przetestować czy działa i jak wygląda 🙂 ) kliknij prawym przyciskiem myszy w Solution Explor’erze na jego nazwę, a następnie wybierz Publish. Powinieneś zobaczyć okno deploymentu. Wybieramy Microsoft Azure App Service. W następnym kroku wskaż swoją subskrypcję oraz grupę zasobów w ramach której dostępna będzie aplikacja. Jeśli jeszcze nie posiadasz takiej grupy, możesz ją teraz stworzyć (App Service Plan również), klikając w przycisk New po prawej stronie – przykładowa konfiguracja:

Tworzenie grupy zasobów oraz planu aplikacji z Visual Studio
Tworzenie grupy zasobów oraz planu aplikacji z Visual Studio

Proces tworzenia grupy i planu zajmuje kilka sekund. Zanim wykonasz deployment możesz jeszcze zweryfikować stan połączenia z chmurą. Jeśli wszystko będzie ok, możesz śmiało wdrażać aplikację. Gdy wszystko będzie już gotowe przeglądarka internetowa powinna automatycznie otworzyć kartę z aplikacją – niestety jej pierwsze załadowanie po ostatnim deployment’cie trochę potrwa.

Web Deploy Package oraz PowerShell

Proces tworzenia paczki wygląda podobnie jak deploy z Visual Studio. Klikamy prawym przyciskiem myszy na projekt, następnie Publish. Teraz wybierz zakładkę Connection. W sekcji Publish method wybierz Web Deploy Package. Określ miejsce zapisu paczki oraz nazwę aplikacji:

Deployment aplikacji do Web Deploy Package
Deployment aplikacji do Web Deploy Package

Polecam podejrzeć sobie zawartość wygenerowanego pliku 🙂 Znajdziesz w nim wszystkie niezbędne pliki: źródła, biblioteki i dll’ki, skompilowane binarnia itp. Teraz możemy zabrać się za wypchnięcie paczki na serwer. Czas na trochę PowerShell’a:

Add-AzureAccount – logowanie do Azure. Po zatwierdzeniu komendy od razu zostaje wyświetlone okienko, za pomocą którego możesz zalogować,

Get-AzureSubscription -Default – wyświetla informacje na temat obecnie aktywnej subskrypcji. Jeśli posiadasz ich kilka możesz wyświetlić je wszystkie pomijając parametr -Default. Żeby wybrać określoną subskrypcję należy posłużyć się poleceniem Select-AzureSubscription.

Publish-AzureWebSiteProject -Name [nazwa-aplikacji] -Package [sciezka-do-paczki] – wykonuje deployment aplikacji na podstawie ścieżki do pliku *.zip oraz nazwy aplikacji, na którą ma zostać wykonane wdrożenie.

Uff byłoby tego, mam nadzieję, że każdy znajdzie tutaj coś dla siebie. Ja osobiście preferuję deployment aplikacji z wykorzystaniem repozytorium Git’owego – zwłaszcza gdy pracujemy z innymi developerami nad czymś większym 🙂