Platformy PaaS jako narzędzie do szybkiego prototypowania cz.1.

Koncepcja PaaS stanowi jeden z modeli chmury obliczeniowej opierającej się o usługi związane z uruchamianiem i zarządzaniem aplikacjami w ramach określonego ekosystemu. Wśród dostawców występuje ogromne zróżnicowanie oferowanych usług i rodzajów wsparcia. W ramach krótkiej serii artykułów chciałbym pokazać jak „ugryźć” temat i jak możemy za w miarę niewielkie pieniądze lub całkowicie za darmo z naszej lokalnej aplikacji wylądować z projektem działającym gdzieś w sieci.

Heroku

Jako pierwszego dostawcę w tym cyklu chciałbym przedstawić Heroku. Nie posiadają oni własnej infrastruktury, natomiast korzystają z Amazonowej platformy EC2. Od początku Heroku posiadało doskonałe wsparcie dla języka Ruby, z czasem jednak paletę wspieranych technologii poszerzono w tym także o Javę i NodeJS. Podobnie jak większość dostawców także i w tym przypadku mamy podstawowy zestaw narzędzi zupełnie darmowy.

Wdrażana aplikacja uruchamiana jest w oparciu o skonteneryzowane środowisko Linuxowe. Kontener taki w przypadku tego dostawcy nazywany jest „dyno” i to jego użytkowanie i typ stanowi podstawę rozliczenia. Dla przykładu najtańsze „dyno” posiada ograniczenie do 512 MB RAM, wyłącza się po 30 minut nieaktywności, ale… pozwala nam ekspresowo przetestować małego POC’a lub stanowić podstawę prezentacji (jako alternatywa dla ngrok’a).

Konto można założyć za pomocą dość prostego formularza. Warto zainstalować także lokalnego klienta heroku pozwalającego na wygodne zarządzanie całą platformą

W paru krokach spróbuję przedstawić w jaki sposób można zbudować aplikację opartą o framework SpringBoot odpytującą zewnętrzne API. Dość interesujące publiczne API znajdziemy [tutaj]. W ramach małego PoC’a spróbujemy odpytać jeden z endpointów.
Na początek proponuję wykorzystać [Spring initializr] i wybrać Javę 14. Z zależności użyję Reactive Web i Lombok’a – tak przygotowany projekt można umieścić w repozytorium Gitlab’owym, co daje dostęp do dość wygodnych i bardzo zaawansowanych pipeline’ów. W podstawowej konfiguracji otrzymujemy również 2000 minut procesora – w sam raz dla mniejszych i mniej aktywnych projektów realizowanych hobbystycznie.

Przygotowujemy źródło niezbędnej konfiguracji (application.yml):

Zarówno klucz prywatny jak i publiczny możemy uzyskać rejestrując się w serwisie Marvel’a. Pamiętajcie, żeby traktować owe dane jako poufne i nie commitować ich do publicznego repozytorium. Pracując w środowisku chmurowym warto wyrabiać w sobie dobre nawyki związane z security także dla własnego bezpieczeństwa. Przykładowo uzyskanie niepowołanego dostępu do naszych kluczy AWS’owych może skutkować narażeniem na poważne koszty.

Przykładowy kod kliencki – odpytanie jednego z endpointów API:

Aby sprawdzić czy wszystko działa i czy z naszej aplikacji da się połączyć z Marvelowym API musimy przygotować najprostszy endpoint:

Przygotowaną aplikację możemy potestować lokalnie i jeśli wszystko działa jak powinno, możemy spróbować podjąć próbę deploymentu.

Wdrożenie

Gdy mamy przygotowany kod – powinniśmy się zająć miejscem na którym zdeployujemy naszą aplikację. Po zalogowaniu się do panelu Heroku możemy stworzyć nową aplikację:


Kolejna formatka pozwala na podjęcie decyzji, gdzie chcemy by fizycznie znajdował się nasz kontener z aplikacją. Z wszystkich regionów AWS do wyboru są dwa (Stany Zjednoczone i Europa). Możemy też choć nie musimy nadać naszej aplikacji nazwę, po przejściu tego kroku w odpowiedzi mamy gotową aplikację typu Hello World czekającą na zastąpienie ciekawszym (bo naszym) projektem.

Wróćmy na chwilę do naszej aplikacji. Sugerowałem użycie gitlaba, ze względu na doskonałe CI/CD, które dostarcza. Dodatkowo Gitlab Pipelines posiadają bardzo niski punkt wejścia.

Przykładowo poniższy kawałek kodu pozwala nam na zdefiniowanie etapu (stage) build z jednym zadaniem (job) o nazwie build. Gitlabowy runner w pierwszym kroku pobiera obraz dockerowy posiadający maven i Javę 14, a następnie uruchamiany jest na nim build (clean package).

Jak zatem powiązać nasz build z przygotowaną aplikacją w chmurze Heroku? Wystarczy dobrać odpowiednie narzędzie do deploymentu. Jednym z tego typu narzędzi jest dpl używany także przez Travis’a – posiadający wsparcie dla kilkunastu największych dostawców chmurowych (min. Azure i AWS).

Rozbudowa naszego pipeline’u o deployment na Heroku staje się banalnie prosta:

Cała magia dzieje się w linijce:

HEROKU_APP_NAME i HEROKU_API_KEY są zmiennymi środowiskowymi, które możemy zdefiniować w ramach naszego projektu na Gitlabie. Nazwę aplikacji na Heroku znajdziemy bez trudu po zalogowaniu do głównego dashboard. Klucz (token) można stworzyć wywołując odpowiednie polecenie z CLI.

Tutaj bardzo ważna uwaga. Powyższy klucz daje pełny dostęp do konta Heroku – nie należy go udostępniać, ani commbitować do publicznych repozytoriów. W przypadku Gitlab – możemy umieścić go w chronionej zmiennej środowiskowej:

Chroniona zmienna środowiskowa w Gitlab, sprawi że będzie ona przekazywana ona tylko i wyłącznie do pipeline’ów uruchamianych na chronionych gałęziach (np. master – stąd zadanie deploymentu zostało w zawężone właśnie do tej gałęzi). Dodatkowo dodanie maskowania sprawi, że wartość nie zostanie wypisana w logach runnerów. Oczywiście nie jest to idealne zabezpieczenie, a zatem nie traktujcie powyższego rozwiązania jako wzorca do powielenia w produkcyjnej aplikacji.

Po uzupełnieniu zmiennych środowiskowych. Nasz pipeline powinien już działać i wdrożenie aplikacji do chmury Heroku powinno się wykonać.

W logach runner’a na GitLab można podpatrzeć działanie maskowania zmiennych środowiskowych:

Ostatecznie aplikacja powinna być dostępna pod URLem https://<nazwa naszej aplikacji>.herokuapp.com/marvelheroes. Na tym etapie możemy nie być jeszcze w stanie połączyć się z API Marvel’a które definiowaliśmy na początku. Czego brakuje? Oczywiście kluczy. W ustawieniu ich dla naszej aplikacji pomoże nieoceniony Heroku CLI.

Poniższe polecenia pozwalają na wyświetlenie istniejących zmiennych środowiskowych i ustawienie interesujących nas kluczy dla aplikacji:

Teraz pozostaje nam tylko odpytać naszą aplikację za pomocą curl’a i powinniśmy uzyskać interesującą nas odpowiedź.

Podsumowanie

W tym pozornie krótkim artykule udało się nam przejść przez wszystkie kroki wymagane do postawienia prostego hobbystycznego projektu.

Od wygenerowania aplikacji, poprzez przygotowanie i skonfigurowanie miejsca w chmurze Heroku aż po zestawienie prostego pipeline’u. Warto zwrócić uwagę, że najwięcej kodu i wysiłku nawet w tak banalnym przykładzie zajęło stworzenie naszej aplikacji. To też ukazuje potęgę rozwiązań typu PaaS -> developer może skupiać się na tym co dla niego najważniejsze, czyli tworzeniu własnego projektu.

WeeklyJavaSnippets#2 Singletons in Java

Singleton – wzorzec czy antywzorzec?

Wśród programistów, często spotykam się z opinią, że Singleton stanowi antywzorzec. Niestety, rzadko też słyszę dobre argumenty podpierające tą tezę. Fakt, jest on jednym z najpowszechniejszej stosowanych wzorców projektowych i jednym z pierwszych jaki poznaje każdy programista. Konsekwencjami tego jest olbrzymia ilość błędnych implementacji, które krążą po repozytoriach i potrafią przyprawić o prawdziwy zawrót głowy podczas czytania kodu i poszukiwania przyczyny problemów.

Czytaj dalej WeeklyJavaSnippets#2 Singletons in Java

WeeklyJavaSnippets#1 Splitting and joining Strings in Java

Wpadłem na pomysł kolejnego cyklu, który mógłby się przewijać na tym blogu, stanowiącego zbiór krótkich kawałków kodu czasem oczywistych, czasem nie, które… robią swoją robotę. Czy kiedykolwiek czułeś, że wynajdujesz koło po raz n-ty? Czy pozornie prosta operacja to kolejne i kolejne linijki kodu? Wezwij Drużynę A… Wybaczcie zapędziłem się.  Po prostu zerknij na Java Snippets! A zatem nie przeciągając…

String – split i join

Założę się, że nie raz zazdrościliście Pythonowi:

Czytaj dalej WeeklyJavaSnippets#1 Splitting and joining Strings in Java

ZeroTurnaround cheatsheets – nie tylko dla Javowców

Zapewne większość z was kojarzy firmę ZeroTurnaround – to twórcy świetnego narzędzia JRebel, pozwalającego na przeładowywanie kodu w locie, co znacząco pomaga przy pracy z cięższymi projektami. W zasadzie największą wadą tego rozwiązania były koszty licencji, jednak kto pracował, ten miał okazję docenić, gdy nie musiał czekać X minut na cały redeploy aplikacji.. Ale nie o tym i nie jest wpis sponsorowany 🙂 Chłopaki i dziewczyny z ZT na swoim blogu wrzucają fajne skrótowe cheatsheety, które mogą przydać się każdemu z was:

To tyle 🙂 Wielkie dzięki ZeroTurnaround!

Widmo krąży po Javie… widmo boilerplate’u

Problem (?)

W zasadzie ktokolwiek zajmujący się Javą, a mający w swoim życiorysie romans z platformą .NET przyzna, że Java nie jest zwięzłym językiem. Już sam kod akcesorów, które trzeba tworzyć/generować za każdym razem potrafi doskonale zaciemnić nam obraz klasy. Dla przykładu znany z konkurencyjnej platformy mechanizm Properties doskonale adresuje ten problem, skracając boilerplate do minimum, jak i pozostawia programistę w pełnej kontroli:

Czytaj dalej Widmo krąży po Javie… widmo boilerplate’u