Platformy PaaS jako narzędzie do szybkiego prototypowania cz. 8. – zarządzanie infrastrukturą z poziomu GitLab

W poprzednich częściach pokazaliśmy jak możemy w naszej prototypowanej aplikacji szybko zbudować pełny pipeline CI/CD. Następnie udało nam się przeprowadzić deployment na chmurach Heroku i Azure, oraz cały kod przedstawić w postaci Terraformowego skryptu o stanie współdzielonym w zewnętrznym magazynie. Moglibyśmy teraz ruszyć o krok dalej, pozwalając naszemu repozytorium nie tylko zarządzać kodem, ale też dbać o aplikowanie zmian w chmurze.

W celu użycia nie-personalnego konta i posiadania pewnej kontroli nad tworzoną aplikacją powinniśmy utworzyć dedykowaną jednostkę usługi (Service Principal). Na potrzeby artykułu możemy traktować ją jako rodzaj niespersonalizowanej tożsamości.

Przypisanie jednostce usługi roli „Contributor” pozwoli jej na zarządzanie dostępem do zasobów, a jednocześnie uniemożliwi zmianę w ustawieniach ról AzureRBAC i nadawanie nowych uprawnień.

Następnie możemy przygotować zarys Pipeline’u (.gitlab-ci.yml), którego ogólna idea pozwoli na przygotowanie i przetestowanie zmian w infrastrukturze naszego projektu.

Pierwsze etapy pozwolą na weryfikację i wywołanie planowania zmian, aplikacja nastąpi dopiero na pipeline master. Jako, że będziemy działali w ramach automatycznego zadania, musimy wyłączyć tryb interaktywny poprzez dodanie parametru (-input=false). Dodatkowo powinniśmy uzupełnić wszystkie zmienne środowiskowe wymagane przez aplikację.

Zatem począwszy od zmiennych aplikacyjnych TF_VARS_* możemy rozpocząć przygotowywanie naszych sekretów. Po raz kolejny chciałbym zwrócić uwagę, że wciąż nie zaadresowaliśmy wielu problemów związanych z bezpieczeństwem, a jedynie skupiamy na się na poprawie automatyzacji tworzenia infrastruktury.

Przy próbie wywołania zadania planowania nawet po ustawieniu zmiennych, możemy zobaczyć następujący błąd:

Nadszedł czas na wykorzystanie uprzednio przygotowanego Service Principal. Provider Azure wymaga pięciu zmiennych:

Zasadniczo wszystkie poza id naszej subskrybcji i ACCESS_KEY znanym z poprzedniego artykułu można pozyskać po utworzeniu roli. ARM_CLIENT_ID to tak naprawdę appId, a ARM_CLIENT_SECRET to otrzymane w odpowiedzi hasło.

Gdy zaaplikujemy wszystkie wspomniane zmiany – nasz Pipeline powinien się zazielenić 🙂

Podsumowanie

Czas chyba odpowiedzieć sobie na dwa pytania. Czy tak naszpikowany zmiennymi pipeline może być w ogóle zarządzalny? Czy to w ogóle bezpieczne?

Cóż – na pewno zmienne aplikacyjne nie powinny być ręcznie konfigurowane poprzez Gitlab’a i być tam przechowywanymi. Powinniśmy korzystać z bezpiecznego składowiska typu Vault i z niego na żądanie pobierać wartości.
Co do ogólnego bezpieczeństwa… Zadania na publicznym GitLab uruchamiane są w Dockerze i nie współdzielą stanu pomiędzy wywołaniami. Pozwalamy jednak zewnętrznemu dostawcy na trzymanie danych naszej jednostki usługi. W planie darmowym, niewiele jest sposobów na obejście tej wady, a więc musielibyśmy posłużyć się integracją z Vault. Wszystko zależy od rozmiaru projektu i naszej determinacji w celu zabezpieczenia go.

Platformy PaaS jako narzędzie do szybkiego prototypowania cz. 7. – Terraform i zarządzanie stanem przez Azure Storage

Obiecałem w poprzednich rozdziałach, że zadbamy o lekkie usprawnienia security. Lokalny stan w terraform, nie stanowi najlepszego rozwiązania wystarczy, że podejrzymy wygenerowane pliki .tfstate i niezależnie od sposobu przekazania sekretów – lądują one tam czystym tekstem. Dodatkowo jeśli więcej niż jedna osoba pracuje nad zmianami infrastruktury – stan byłby ciągle trzymany niezależnie na różnych systemach. Potencjalnymi rozwiązaniami tego problemu mógłby być wspóldzielony dysk lub nawet lepiej inny rodzaj bezpiecznego składowiska.

Składowanie stanu w Azure

W tym artykule omówimy sobie podejście wykorzystujące Azure Storage. Zaczynamy od przygotowanie dedykowanej grupy zasobów, jak i konta magazynu (Storage account).

Przygotowane w ten sposób konto magazynu da nam dostęp do stanu z każdego miejsca na świecie. Klucze dostępowe uzyskamy poprzez polecenie:

Nieco interesującym może wydać się fakt, że w wyniku zostały zwrócone od razu dwa klucze (key1 i key2). Którego z nich powinniśmy zatem używać? Czy różnią się one zakresem uprawnień?
Otóż… możemy korzystać z obu. Istnienie dwóch kluczy drastycznie ułatwia ich emigrowanie w razie skompromitowania jednego z nich. W przypadku, gdy jeden z nich wyciekł powinniśmy zadziałać w następujący sposób. W każdej aplikacji korzystającej z naszego konta magazynu, podmieniamy klucz na drugi z dostępnych. Następnie rotujemy pierwszy z nich. Istnienie dwóch aktywnych kluczy umożliwia rotację w banalny sposób chroniący nas przed jakimkolwiek downtime’m aplikacji.

Pozyskany w ten sposób klucz dla potrzeb Terraform powinniśmy umieścić w zmiennej środowiskowej:

Następnie przygotowujemy magazyn pod nasz stan termaformowy.

Jeśli chcemy obejrzeć efekt powyższych działań możemy zajrzeć np. na Portal Azure. Warto dodać, że jeżeli pominiemy wstrzyknięcie klucza do konta magazynu, a jesteśmy zalogowani z poziomu AzureCLI, polecenie i tak wykona się poprawnie po wyświetleniu nieprzyjemnego ostrzeżenia.

Przygotowane składowisko pod Terraformowy stan

Pozostał nam do ułożenia ostatni klocek naszej układanki. Powinniśmy przestawić domyślne zachowanie Terraform, aby potrafił skorzystać z przygotowanego składowiska.
Mechanizmy obsługujące zarządzanie stanem nazywane są „backendami” i są one w pełni konfigurowalne i podmienialne. Domyślne zachowanie i jego wady poznaliśmy w poprzednich artykułach, jednak ich podmiana okazuje się banalną sprawą – wykorzystuje się do tego specjalną sekcję na początku pliku (dodajmy ją do naszego config.tf):

Jako, że mamy przygotowaną już całą konfigurację możemy wykonać zestaw poleceń init (reinicjalizacja), a następnie plan i apply, a jako efekt ich wykonania powinniśmy zobaczyć, że stan wylądował w naszym magazynie.

Podsumowanie

W tym artykule przenieśliśmy zarządzanie stanem do chmury, od tego momentu w wygodny sposób i niewielkim kosztem możemy pracować infrastrukturą naszego projektu. Oczywiście planując wdrażanie większych rozwiązań warto rozważyć inne sposoby zarządzania stanem.

Platformy PaaS jako narzędzie do szybkiego prototypowania cz. 6. – Terraform

W poprzednich częściach cyklu przeszliśmy szybką drogę do stworzenia aplikacji mobilnej w oparciu o Azure App Service. Wszystkie przykłady przedstawiałem w oparciu o interfejs graficzny, którego intuicyjność pozwala poznać ogrom możliwości chmury. W pewnych okolicznościach wyklikiwanie wszystkiego może okazać się niepraktyczne, a co gorsza może prowadzić do poważnych błędów.

Terraform jest narzędziem pozwalającym wdrażać infrastrukturę jako kod (Infrastructure as a code). Opiera swoje działanie o ogromną ilość wtyczek (nazywanych provider’ami) do wszystkich popularnych dostawców chmurowych i nie tylko. W zasadzie każda usługa posiadająca swoje publiczne API może posiadać swojego provider’a. Niepełną ich listę można znaleźć pod adresem: https://www.terraform.io/docs/providers/index.html

Wszystko co chcemy zautomatyzować za pomocą terraform musi zostać zaimplementowane w języku HCL. Język ten ma charakter deklaratywny i ma wyrazić docelowy stan, a w momencie aplikacji zmian powoduje szereg wywołań API używanych providerów. Aplikacja zmian powoduje też odłożenie stanu jaki udało się osiągnąć np. w plikach terraform.tfstate, co pozwala na synchronizację i planowanie kolejnych zmian w zasobach.

Czy dałoby się jednak uniknąć przechowywania stanu? Cóż w pewnych scenariuszach byłoby to możliwe, jednak bardzo komplikowałoby to całą ideę szczególnie podczas operacji aktualizacji/zastąpienia zasobów, świadomości stworzonych metadanych i relacji między nimi oraz z powodów czysto wydajnościowych.

Praktyka

Spróbujmy przejść od tej suchej teorii do praktyki. Do utworzenia zasobów w Azure będzie nam potrzebny provider azurerm. Sprobujmy też przygotować dedykowaną grupę zasobów:

Aby zaaplikować zmiany powinniśmy wykonać:

Przetworzenie całości trochę potrwa i powinniśmy być zalogowani za pomocą lokalnego klienta Azure dostępnego na wszystkie platformy (https://docs.microsoft.com/pl-pl/cli/azure/install-azure-cli). Do tak utworzonego pliku możemy przygotować definicję planu usługi określawjącą typ i rodzaj zasobów konsumowanych przez naszą aplikację:

Proszę zwróćcie uwagę w jaki sposób połączono lokalizację oraz grupę zasobów z uprzednio utworzonym planem.

Oczywiście po edycji pliku terraform ponownie wykonujemy polecenia plan i apply. W pliku stanu oraz w logach możemy podejrzeć addytywne zachowanie terraforma.

Po zdefiniowaniu planu przyszedł czas na przygotowanie usługi, która będzie z nego korzystać i pomieści naszą aplikację. Poniższe linijki mieszczą właściwie wszystkie ekrany związane z konfiguracją naszej aplikacji, a także musiały się w niej znaleźć zmienne środowiskowe przechowujące wszystkie sekrety. O tym w jaki sposób powinniśmy zarządzać sekretami opowiemy sobie w innym artykule tego cyklu.

Kiedy podejmiemy próbę aplikacji zmian okaże się że nasz kod jest niepoprawny:

Oczywiście zmienne które zdefiniowaliśmy powinniśmy gdzieś zadeklarować. Utarło się że zmienne w terraform powinno umieścić się w plikach variables.tf lub vars.tf. Deklaracja wszystkich zmiennych wygląda w zbliżony sposób jak w innych językach programowania, a dobry opis ułatwia zarządzanie nimi.

Po dodaniu powyższych definicji przy próbie wykonania planu pojawi się ładne zapytanie o kolejne wartości:

Takie zachowania można obejść na przykład poprzez zmienne środowiskowe. Muszą one przyjąć konkretny format tj. posiadać prefiks TF_VAR_. Jeśli uda nam się zestawić pełny zestaw zmiennych, mozolnie wpisując je w konsoli utworzenie aplikacji powinno udać się bez większych przeszkód.

Podsumowanie

W tym artykule udało nam się ująć definicję naszej aplikacji w dwóch plikach. Początkowo takie usprawnienie może wydawać się nadmiarowe, jednak zarządzając większą ilością usług możemy ujrzeć zalety automatyzacji i algorytmizacji naszej pracy.

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

W poprzednim artykułach opisywałem Heroku, który idealnie pokrywa przypakdi hobbystyczne, co jednak kiedy chcemy przeprowadzić pewien mniej lub bardziej zaawansowany proof-of-concept w firmie, a management nie specjalnie ma ochotę na zawieranie nowych umów i sugeruje skorzystanie z już posiadanych przez nas subskrybcji.

W środowiskach korporacyjnych dominuje głównie dwóch dostawców pokrywających większość rynku i wyznaczających standardy dla konkurencji. Pierwszy z nich – AWS zapoczątkował wielką rewolucję chmurową, która odmieniła cały świat IT, zmuszając nawet najbardziej konserwatywne firmy jak banki do opracowania swoich rozwiązań (private cloud) lub wykorzystania chmury publicznej w części prowadzonych projektów (hybrid cloud).
Microsoft Azure powstał jako odpowiedź na rosnącą popularność chmur obliczeniowych i szybko stał się faworytem korporacji ze względu na ogromną ilość oferowanych usług w modelu SaaS (jak Office 365 i Dynamics). Jak już wspominałem wcześniej nawet jeśli twoja korporacja nie posiada jeszcze projektów realizowanych w chmurze Azure – jest duża szansa, że posiada subskrybcję Office365, czy Microsoft Dynamics.

W tym artykule chciałbym kontynuować naszą zabawę z modelem PaaS. Spróbujmy przenieść aplikację, którą zbudowaliśmy pod chmurę Heroku na Azure App Service. Jeśli nie popełniliśmy zasadniczych błędów projektowych, to nie powinniśmy stać się uzależnieni od dostawcy (ang. vendor lock-in) i migracja całości nie powinna kosztować nas zbyt dużo wysiłku.

Większość serwisów PaaS można uniezależnić całkowicie od języka programowania i platformy, poprzez odpowiednią konteneryzację. Jeśli pamiętacie heroku addons jak i buildpack’i wspomniane w poprzedniej części – to uniezależnienie się od nich stanowi klucz do uwolnienia naszego serwisu od określonego dostawcy i wspieranych przez niego technologii.

Przykładowa architektura:

źródło Azure Portal

Na czym zatem polega konteneryzacja?

Jest to rodzaj wirtualizacji na poziomie systemu operacyjnego (OS-level virtualization) i wbrew powszechnej opinii nie stanowi nowego wynalazku – jej wczesnym pierwowzorem były jail’e i chroot znany z systemów uniksowych (1982). W świecie backend developerów dopiero pojawienie się Docker’a upowszechniło konteneryzację. Od tej pory tworzone usługi i oprogramowanie mogły w całości uniezależnić się stack’u systemowego czy technologicznego.

Obraz Dockerowy można złożyć z kilku warstw za pomocą kilku wbudowanych poleceń takich jak FROM, CMD, COPY, ARG. Dla przykładu:

Po utworzeniu pliku Docker file jw. zbudowanie obrazu i uruchomienie kontenera sprowadza się do dwóch poleceń:

Rozbudowa aplikacji

W przypadku naszej aplikacji moglibyśmy wyodrębnić całą logikę poprzez przekopiowanie utworzonych artefaktów w następujący sposób:

W zasadzie poza skopiowaniem artefaktów i uruchomieniem naszej aplikacji zmieniamy jeszcze kontekst użytkownika na pozbawionego przywilejów ROOT’a (dobra praktyka).
Po próbie budowy, możemy niestety zaobserwować dość nieprzyjemny wyjątek:

W dość wymowny sposób pokazuje o czym zapomnieliśmy podczas uruchamiania/tworzenia obrazu.
Do uruchomienia potrzebujemy kilku dodatkowych zmiennych środowiskowych – w końcu w Heroku użyliśmy aż pięciu (!). Powinny one zostać przekazane do kontenera. Przygotujmy zatem plik w następującym formacie:

Wartości można oczywiście zabrać z naszej wcześniej utworzonej aplikacji na Heroku. Na powyższym przykładzie wychodzi też cena pokazanej wcześniej automagii.
Czy projektując aplikację nie pod konkretnego dostawcę podjęlibyśmy identyczną decyzję, jeśli chodzi o konfigurację podłączenia do bazy danych?
Zapewne zależałoby nam na rozdzieleniu pewnych elementów, dodatkowo moglibyśmy uniknąć zaprezentowanego wcześniej hack’a.
Kolejna próba z uwzględnieniem zmiennych środowiskowych i przekierowaniem portów pozwala już na lokalne uruchomienie skonteneryzowanej aplikacji:

Teraz wypadałoby poszerzyć nasz projekt o budowanie obrazu w pipelinie. Na szczęście przy oparciu naszego amatorskiego projektu o Gitlaba uzyskaliśmy możliwość skorzystania z ichniejszego rejestru obrazów (rozmiar całego repozytorium jak i rejestru posiada ograniczenie 10GB).
Użycie pipeline’ów w Gitlab sprawia, że uzyskanie do niego dostępu również jest banalnie proste poprzez predefiniowane zmienne:

Przygotowany etap wykonuje budowanie obrazu przy założeniu, że wcześniej odłożyliśmy je:

przykładowy rejestr

Po uruchomieniu kilku pipeline’ów zobaczymy, że rejestr zapełnia się kolejnymi tagami z kolejnymi wersjami aplikacji. Jak zatem powinniśmy decydować, która z nich powinna zostać zdepluyowan’a na nasze docelowe produkcyjne środowisko?

Można dodać do pipeline’u kolejny etap, którego celem będzie wykonanie właśnie tej operacji tj. odpowiednie tagowanie ostatniego build’a.

Et voilla. Nowy stage sprawi, że pod tagiem latest zawsze będzie się ukrywał najnowszy obraz pipeline’u masterowego.

Ktoś mógłby zadać pytanie, ale gdzie w tym wszystkim Azure? Dlaczego przygotowywać aplikację w ten sposób?
W następnej części cyklu zobaczymy uzysk z tych wszystkich operacji, ponadto zastanowimy się czy dałoby się podejść do tematu nieco inaczej.

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.

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!