Platformy PaaS jako narzędzie do szybkiego prototypowania cz. 5. – PostgreSQL for Azure

W poprzedniej części naszego cyklu udało nam się z sukcesem przenieść naszą aplikację pod postacią obrazu Docker’owego na Azure. Jednak na Heroku wciąż pozostała baza danych, co sugeruje, że nasza migracja jest wciąż niepełna. W tym artykule chciałbym skupić się na postawieniu dedykowanej bazy danych w chmurze Microsoft’u.

W portalu po wpisaniu frazy Azure Database for PostgreSQL będziemy mogli wybrać jeden z czterech rodzajów wdrożeń. Każdy z nich różni się skalą, możliwościami i kosztami.

Dla przykładowej aplikacji zrealizowanej przez nas w tym cyklu artykułów interesuje nas pojedynczy serwer, który powinien wytrzymać obciążenie aplikacji prototypowej.

Kolejne ekrany pozwolą na dokonfigurowanie wybranej opcji.Pamiętajmy, że w naszym przykładzie zagadnienia security spłycam do minimum, zatem starajcie się chronić hasła które ustawiacie.

Aprowizacja bazy potrwa chwilę, jednak jak się można domyślić utworzona przez nas baza będzie posiadała tylko użytkownika administracyjnego. Odwiedzenie bazy danych pozwoli na lekkie poluzowanie polityki bezpieczeństwa. Zacznijmy od lekkiej liberalizacji ustawień Firewall’a poprzez zezwolenie na dostęp z innych usług Azure. Jeśli chcemy pracować z naszym klientem bazy danych(psql) powinniśmy także odblokować nasz adres IP.

Do dalszej konfiguracji konieczny już będzie klient psql, ale jeśli nie chcemy go instalować wystarczy, że skorzystamy z AzureCLI otrzymamy wygodny terminal zaszyty w przeglądarce internetowej.

Nie ma znaczenia czy dalszą konfigurację wykonamy z terminala, czy z przeglądarki, do połączenia potrzebujemy jednak klienta psql:

Następnie należy utworzyć kolejno bazę danych, rolę i odpowiednie przywileje:

Po utworzeniu nowej roli, możemy zaktualizować nasze połączenia. Przykładowy connection string będzie wyglądał następująco:

I tyle, po restarcie nasza aplikacja powinna już uruchamiać się i korzystać z bazy świeżo utworzonej w Azure.

Jeśli dotrwaliście aż dotąd, można uznać że to ostatni punkt migracji. Jedyną pozostałością jaka została po Heroku, to dług w postaci dziwnie podzielonych properties zawierających poświadczenia bazodanowe.

Platformy PaaS jako narzędzie do szybkiego prototypowania cz. 4. – Azure App Service

Zanim ruszymy dalej z artykułami chmurowymi, krótkie ostrzeżenie -korzystając z AWS, czy Azure powinniśmy pamiętać, że subskrybujemy usługi płatne – do założenia konta potrzebna jest karta debetowa lub kredytowa (i niestety wszelkiego rodzaju prepaidy odpadają). Dodatkowo wiele oferowanych usług klasy Enterprise po prostu kosztuje krocie, należy więc za każdym razem sprzątać testowane przez nas usługi i kontrolować koszty. Powinniśmy też zadbać o ochronę naszego konta i dostępu do zasobów tj. włączyć MFA, chronić tokeny, stosować zasadę minimalnych uprawnień itd.
Jakiekolwiek zaniedbanie w tej dziedzinie może narazić nas na spore koszty.
Sami dostawcy oferują na swoich stronach zestawy najlepszych praktyk dot. bezpieczeństwa https://aws.amazon.com/architecture/security-identity-compliance/ i https://azure.microsoft.com/mediahandler/files/resourcefiles/security-best-practices-for-azure-solutions/Azure%20Security%20Best%20Practices.pdf z którymi zdecydowanie warto się zapoznać.

Zarówno w Azure jak i w AWS jako nowi użytkownicy możemy liczyć na pakiet powitalny w postaci sporego zestawu darmowych usług (w pewnych granicach oczywiście). Bazowa oferta pozwoli jednak na spokojny deployment prototypowanej aplikacji w modelu PaaS za free (https://azure.microsoft.com/pl-pl/pricing/details/app-service/windows/). Darmowa oferta nie jest tak dobra w porównaniu do Heroku, ale jest to poniekąd cena za ogromną uniwersalność całej platformy. Ufff… wydaje mi się, że na tym etapie możemy zakończyć informacje wstępne i spróbować założyć konto. Nie będę opisywał tego etapu, ale posiadanie już konta w usługach Microsoft skraca drastycznie cały proces – wystarczy uregulować kwestie dot. płatności i możemy działać.

Konfiguracja

Po pierwszym zalogowaniu do portalu azure (http://portal.azure.com/) zobaczymy następujące wręcz „komiksowe” menu do zarządzania zasobami.

Azure portal – dashboard

W wyszukiwarce znajdujemy App Services i klikamy + Add. Pojawia się menu w którym możemy właściwie wyklikać całą naszą aplikację:

Gdy dopiero zaczynamy naszą przygodę z Azure zapewne będziemy musieli utworzyć pierwszą grupę zasobów. Z początku ten obiekt może wydawać się czymś nadmiarowym, bo dlaczego nie utworzyć zasobu bezpośrednio na naszej subskrybcji? Spójrzmy na konto Azure z perspektywy na przykład dużej firmy – możemy mieć w niej zdefiniowane, wiele aplikacji i środowiska, często użytkowanych przez rozmaite zespoły. W takim heterogonicznym świecie łatwo stracić możliwość zarządzania całością i jakiejkolwiek kontroli kosztów. Wydzielenie grup zasobów np. z podziałem na aplikacje pozwala uzyskać nam pełną kontrolę nad naszą chmurą i płatnościami.

Z ustawień dotyczących deploymedntu pozostaje odpowiedni dobór nazwy jak i typu samego deploymentu:

Czym różni się sposób publikacji Code vs Docker Container? Code pozwala na zdefiniowanie wdrożenia w analogiczny sposób jak w przypadku Heroku – opieralibyśmy się o zbudowanie aplikacji ze źródeł po stronie Azure’a. Przygotowaliśmy sobie obraz Dockerowy po to by maksymalnie uniezależnić się od konkretnego dostawcy, zatem skorzystamy z tego i wybierzemy Docker Container.

Kolejny ekran konfiguracji oczekuje wartości, które powinniśmy już znać z poprzedniej odsłony naszego cyklu:

Przygotowaliśmy już obraz, posiadamy rejestr w Gitlab, wypadałoby wprowadzić właściwy adres rejestru, nazwę użytkownika, hasło, a także obraz – zdobyć je można w Gitlabie w Settings -> Repository -> Deploy Tokens.

W scope tworzonego token’a interesuje nas tylko możliwość odczytu obrazów w repozytorium – z punktu widzenia deploymentu jest to zupełnie wystarczające. Hasło pojawi się jednorazowo, jeśli nie skopiujemy go pozostaje nam utworzenie kolejnego token’u.

Pełną nazwę obrazu jak i adres repozytorium, uzyskamy na zakładce Container Registry.

Po wypełnieniu formatki i kliknięciu na URL możemy zauważyć, że nasza aplikacja nie startuje.

Oglądając Container Settings możemy zobaczyć logi ze startu – brakuje nam zmiennych środowiskowych. Na szczęście odłożyliśmy potrzebne dane budując kontener.

Uzupełnienie konfiguracji powinniśmy wykonać w sekcji Configuration. Oprócz zmiennych środowiskowych, które wykorzystywaliśmy uruchamiając obraz Dockerowy powinniśmy dodać jeszcze jedną: WEBSITES_PORT. W skrócie wskazuje ona na którym porcie nasłuchuje nasza aplikacja – w tym przypadku należy ustawić ją na 8080.

W zasadzie to tyle – ponowne odwiedziny URL z naszą aplikacją sprawią, że będziemy w stanie już korzystać z naszego API.