Jak hostować aplikacje w GCP

W ramach podcastu “Porozmawiajmy o IT” miałem okazję porozmawiać z Piotrem Gocłowskim o hostowaniu aplikacji w Google Cloud Platform.

Posłuchaj naszej rozmowy w wersji audio 🎧 👇

Cześć, mój dzisiejszy gość w branży technologii jest już od 10 lat, początkowo związany z automatyką przemysłową, a konkretnie sieciami IoT i komunikacją szeregową, Cloud Architect w GCP, posiadacz kilku certyfikatów GCP. Na co dzień doradza i pomaga klientom w rozwiązywaniu problemów związanych właśnie z chmurą GCP. Fan Raspberry Pi Nintendo, a prywatnie szczęśliwy mąż i ojciec dwóch żywiołowych córek.

Moim i Waszym gościem jest Piotr Gocłowski.

Cześć, Piotr! Bardzo miło mi gościć Cię w podcaście.

Cześć, Krzysztof. Mnie również jest bardzo miło być tutaj. Dzięki wielkie za zaproszenie.

Przyjemność po mojej stronie. Dzisiaj będę z Tobą rozmawiał, jako że specjalizujesz się w chmurze GCP. Poruszymy temat hostowania aplikacji w GCP. Myślę, że nie tylko ja, ale i słuchacze wiele się dowiedzą.

Ale na początku chciałbym Cię zapytać, czy może coś pominąłem we wstępie w przedstawieniu Twojej osoby i tego, gdzie pracujesz.

W FOTC pracuję jako Cloud Architect, na co dzień zajmuję się wsparciem i konsultacjami dla naszych aktualnych i przyszłych klientów. FOTC jest partnerem Google Cloud i pełni rolę takiego przewodnika po chmurowej technologii. Dodatkowo oferujemy 500 dolarów na start, w formie vouchera, by móc swobodnie i bez stresu przetestować usługi GCP. Chmura może wydawać się na początku nieco skomplikowana na początku przygody, dlatego świadczymy też wsparcie techniczne. Więc zawsze można wysłać nam pytanie związane z GCP, korzystając z naszego dedykowanego adresu suportowego.

Fajnie, dzięki za to dopowiedzenie. Oczywiście wszystkie linki dodam później w notatce do odcinka, tak że jeśli ktoś jest zainteresowany, to śmiało można sobie odwiedzić stronę i dowiedzieć się więcej.

Fajnie, to skoro mamy już tę wprowadzającą część za sobą, to może przejdźmy do takiego standardowego pytania, które zawsze zadaję na początku, czyli: Czy słuchasz podcastów? Jeśli tak, to może masz jakieś swoje ulubione audycje, o których chciałbyś powiedzieć?

Tak, słucham. Co prawda nie bardzo regularnie, ale jeżeli mogę, mam czas i coś mnie bardzo zajmie, to słucham. Wiadomo, Porozmawiajmy o IT — zacznę od tego.

Dzięki.

Swojego czasu słuchałem Z pasją o mocnych stronach, Dominika Jurczyka; Na podsłuchu (Niebezpiecznik); Więcej niż oszczędzanie pieniędzy, Michała Szafrańskiego; nie tak dawno Podsiadło Kotarski Podcast (pod kątem, powiedzmy, humorystycznym); i DevTalk Aniserowicza, ale on już chyba nie jest niestety wydawany. Tak że taka krótka lista.

Nie taka krótka. Fajnie, dzięki za te rekomendacje. Dobrze, mówimy o GCP, ale oczywiście dla niektórych słuchaczy to może być niejasny skrót, więc na początku chciałbym Cię zapytać, czym właściwie jest GCP, ten obszar IT, w którym się specjalizujesz.

Generalnie jest to chmura obliczeniowa, czyli taki zestaw, grupa, zbiór usług przeznaczonych dla informatyków, programistów, ludzi z IT. Cechuje ją łatwość użycia, prosty interfejs użytkownika, TAR przez przeglądarkę. Jest też dostęp programistyczny poprzez właśnie RESTful API, mamy też biblioteki dla najpopularniejszych języków programowania. Możemy za pomocą kilku kliknięć lub wywołań API uruchamiać usługi, które normalnie wymagałyby sporej infrastruktury, sporo pracy i sporej liczby urządzeń w naszej serwerowni — jeśli byśmy taką mieli. Wynajmujemy u dostawcy chmurowego sprzęt. Sprzęt jest pod maską, a na zewnątrz mamy ładnie to opakowane w usługę.

Oczywiście dostawcą tej usługi jest w tym przypadku Google, bo mówimy o Google Cloud Platform. Dzisiaj oczywiście mówimy o GCP, ale wybieramy sobie taki fragment całego spektrum różnych tematów związanych z GCP pt. hostowanie aplikacji w chmurze. I dla osób, które wchodzą dopiero do branży IT może się wydawać, że standardowych podejściem jest hostowanie aplikacji w chmurze, ale nie tak dawno wcale nie było to takie oczywiste. Pamiętam jeszcze czasy, kiedy serwery pod biurkiem służyły właśnie do tego, później wchodziły kolokacje itd. Z tego punktu widzenia hostowanie aplikacji w chmurze wcale nie jest takie defaultowe, jakby się mogło wydawać.

I chciałbym Cię zapytać: czy z Twojego punktu widzenia w dzisiejszych czasach, jeśli mówimy o hostowaniu aplikacji, to w domyśle mówimy chmura, czy to już jest defaultowe, standardowe podejście wg Ciebie?

Wydaje mi się, że nie jest może defaultowe. W ogóle bardzo ciekawe pytanie. Na pewno widać, że rośnie zainteresowanie, ale to zależy też od klienta: czy mamy do czynienia z korporacją, czy mniejszą lub średnią firmą. Widać po prostu ten trend rosnący. Chmura jest idealna dla korporacji. Mają one trochę większe potrzeby niż standardowa mała/średnia firma i wymaga też odrobiny wiedzy do wystartowania. Poziom wymaganej wiedzy nie jest jakiś bardzo wysoki do takich podstawowych rzeczy, jak np. uruchomienie aplikacji na maszynie wirtualnej, ale wiadomo, coś tam trzeba poczytać. To dla, powiedzmy, takich prostych stron internetowych, typu mechanik czy strona zakładu fryzjerskiego, to wiadomo, że raczej te firmy hostingowe jeszcze są wybierane, ale nie jest to reguła. Wydaje mi się, że to powoli już przestaje dominować.

Chmura jest idealna dla korporacji. Mają one trochę większe potrzeby niż standardowa mała/średnia firma i wymaga też odrobiny wiedzy do wystartowania. Poziom wymaganej wiedzy nie jest jakiś bardzo wysoki do takich podstawowych rzeczy, jak np. uruchomienie aplikacji na maszynie wirtualnej, ale wiadomo, coś tam trzeba poczytać.

Pewnie należy się spodziewać, że w przyszłości ten trend będzie się umacniał, będzie coraz więcej aplikacji, które na początku standardowo właśnie w chmurze są uruchamiane. I tutaj dostawcy tego typu usług, również Google daje szereg różnych możliwości hostowania aplikacji w chmurze, po to, żeby dobrać właśnie do danego rozwiązania, do wielkości, do skali, do planów rozwojowych aplikacji właściwą usługę.

Stąd moje pytanie do Ciebie, Piotrek, jak to wygląda właśnie w GCP. Jakie mamy sposoby hostowania aplikacji? Z czego możemy wybierać?

Mamy do wyboru kilka usług dosyć rozbudowanych. Część z nich jest trochę skomplikowana, część nieco prostsza i powiedzmy, można zacząć od Compute Engine. Jest to usługa typu IaaS, czyli Infrastructure as a Service. Uruchamiamy tam maszyny wirtualne, przez kilku innych dostawców nazywane też VPS-ami. I jest to taka usługa, która jest praktycznie u każdego dostawcy, zarówno chmurowego, jak i hostingowego. Wybieramy sobie typ maszyny, system operacyjny i potem po uruchomieniu takiej maszyny możemy tam łatwo wgrać naszą aplikację i po prostu ją już hostować. Pokazywać światu.

Drugą usługą może być np. Kubernetes Engine (wymowa zależy od osoby mówiącej), w skrócie K8s. I to jest Container as a Service. To jest taki, można powiedzieć, zarządzany przez Google Kubernetes i po prostu nie musimy go konfigurować na początku, tak samo, jakby to było on-premises, czyli u nas gdzieś tam w sieci. Na pewno jest znacznie szybszy do uruchomienia, do wystartowania z nim.

Mamy też App Engine. To jest taka usługa, a właściwie Platform as a Service. To jest taka typowa usługa, o której się mówi, gdy pada słowo serverless. W niej uruchamiamy nasz kod, napisany np. w takich popularnych językach, jak GS, Java, Rubi, C Sharp, Python. Generalnie jest to taka usługa, w której nie martwimy się o system operacyjny i o maszynę, która tam pod spodem napędza tę usługę. Tak że na głowie mamy tylko pisanie kodu. To na pewno dla programistów jest wygodniejsze.

Mamy jeszcze np. taką usługę, jak Cloud Run. Ona jest nieco podobna, z tym że tutaj nie dostarczamy gotowego kodu, a konkretnie już skonteneryzowaną aplikację. I musimy sobie ją wcześniej przygotować na naszej stacji roboczej, wgrać do repozytorium Google i potem możemy bardzo łatwo i szybko uruchomić ten kontener. Wiadomo, kontenery, podejście kontenerowe rozwiązują ten nasz słynny problem: U mnie działa. A u mnie nie. Możemy łatwo przenosić aplikację.

Kolejną taką usługą, która upraszcza mocno uruchamianie szczególnie bardzo prostych kodów, skryptów, to jest Cloud Function. To jest taka usługa, którą można opisać jako Function as a Service, czyli ona jeszcze bardziej szczegółowo umożliwia zdeployowanie tego kodu na poziomie pojedynczej funkcji. Tak samo tutaj mamy do dyspozycji najpopularniejsze języki, typu GS, Phyton, Java. Z tym że tutaj jest troszeczkę inaczej, bo ta usługa jest dla zdarzeń. Czyli mamy jakieś zdarzenie i wyzwalamy tę funkcję. Możemy je podzielić na dwa typy funkcji wyzwalanych za pomocą zapytania http albo za pomocą zdarzenia z innej usługi w ekosystemie Google. To może być np. zmiana w Cloud Storage, czyli takiej usłudze do przechowywania, może to być nowa wiadomość w Pub/Sub, albo z Firebase’a. Taki SDK do tworzenia aplikacji mobilnych. I moim zdaniem jest to najprostszy sposób, żeby pobawić się serwo losowymi usługami, w sensie w ogóle, żeby zobaczyć, jak to się robi, ponieważ wdrażanie takiego przykładowego kodu to jest dosłownie 3–5 minut. I możemy utrzymać publiczną funkcję wyzwalaną właśnie URL-em.

I ostatnia taka usługa, która nie wiem, czy powinna się tu znaleźć, ale wspomnę o niej, bo ona właściwie służy do przechowywania — właśnie Cloud Storage. To jest taka usługa podobna do S3 AWS-a. Taki storage obiektowy, gdzie możemy przechowywać duże ilości danych. Bardzo duże. Właściwie nigdzie nie ma opisanego limitu. Jest limit dla pojedynczego pliku, który wynosi 5 TB. I ta usługa jest dosyć tania. I dlaczego tutaj jest? Ponieważ można tam hostować strony statyczne, jeśli ktoś potrzebuje prostej strony, wizytówki, która jakoś bardzo się nie zmienia. Wtedy można użyć tego Cloud Storage. Polega to na tym, że umieszczamy tam pliki naszej strony, HTML-e i skrypty JS-owe i to działa praktycznie od razu.

I dodałbym jeszcze ostatnią rzecz, już nawet nie usługę, ale rozróżnienie, czym się różnią te usługi w kontekście: odpowiedzialność użytkownika vs odpowiedzialność Google. W tych usługach typu Compute Engine Google odpowiada za maszynę pod spodem, ale użytkownik już wtedy zajmuje się od systemu operacyjnego w górę, czyli musi po prostu utrzymywać ten system i jeśli coś zrobi nie tak, to Google nie pomoże w tym. Bo to będzie wina tego usera. A w przypadku usługi typu serverless w App Engine jedyne za co odpowiadamy to kod. I wszystko, co poniżej, już nas nie interesuje.

Jasne, czyli po prostu dysponując rozwiązaniami typu Compute Engine, my odpowiadamy za to, żeby oprogramowanie działało poprawnie, mamy wówczas pewnie większą możliwość konfiguracji, dostosowania tego typu rozwiązania, ale musimy być świadomi tego, że to na nas będzie spoczywała odpowiedzialność za ewentualne upgrade’y, patchowanie i wszelkie tego typu rzeczy.

Rozpocząłeś przedstawianie tych różnych sposobów hostowania aplikacji od tego, że takie usługi typu Compute Engine to jest de facto core’owa rzecz dostępna u każdego providera. Myślę, że można śmiało powiedzieć, że takie maszyny wirtualne to najstarszy sposób. Co prawda nie dysponuję żadnymi konkretnymi statystykami, ale z tego, co obserwuję, myślę, że to jest jeszcze na tyle popularny sposób, że warto na pewno powiedzieć więcej na temat tego, czym się charakteryzuje Compute Engine, jak działa, w jaki sposób rozliczamy się za tego typu rozwiązaniami. Gdybyś mógł więcej na ten temat powiedzieć.

Jasne. To zaczniemy może od tego rozliczania, skoro poruszyłeś ten temat. Generalnie jeśli uruchamiamy maszynę wirtualną, to płacimy za typ maszyny. Te typy są predefiniowane. Właściwie są też customowe, ale uprośćmy: mamy predefiniowane typy maszyn z różną liczbą rdzeni CPU i różną ilością pamięci RAM. I to jest pierwszy składnik ceny. Wiadomo, im więcej rdzeni i więcej RAM-u, tym więcej płacimy za taką VMkę.

Kolejnym niezależnym składnikiem jest cena storage’u, w sensie tego dysku. I za ten dysk płacimy oddzielnie. Tam też mamy do wyboru, czy to będzie dysk SSD, czy dysk o zbliżonej wydajności do HDD.

I ostatnim, często zapominanym składnikiem, jest ruch wychodzący od naszej maszyny. Czyli jeśli użytkownicy dostają się do naszej usługi, do naszej aplikacji, to płacimy za ilość danych, która zostanie pobrana do nich. Ciekawostka: nie płacimy za ruch przychodzący do VMek.

A! Jeszcze jeden składnik to jest cena, to jest konkretnie, czy mamy publiczny adres IP na VMce, czy nie. I może być też publiczny adres IP stały lub zmienny. Wiadomo, stały jest najlepszy, możemy podpiąć domenę, możemy to jakoś fajnie upublicznić, ale jest też droższe.

Największym składnikiem, wiadomo, jest zawsze ten typ maszyny, czyli CPU i RAM. Jeszcze dodam, czym się charakteryzuje Compute Engine. Generalnie mamy predefiniowane typy maszyn, mamy też maszyny typu SPOT, tzn. to jest taki checkbox, który możemy zaznaczyć, i wtedy taka maszyna SPOT jest dużo tańsza. Pracuje 91% taniej, ale ma jedną wadę, dosyć poważną. Raz na jakiś czas zostanie wyłączona.

To jest taki, można powiedzieć, zapas dla Google, dla innych usług. I jeśli Google to wywłaszczy, to wtedy taka maszyna pada. Można ją potem włączyć, jeśli będą dostępne, ale jest to kiepski wybór np. na web server. Możemy też włączyć szyfrowanie w maszynach wirtualnych i takie dodatkowe zabezpieczenia integralności dysków. Generalnie Google bardzo wysoko stoi, jeżeli chodzi o bezpieczeństwo. I ciężko mi porównać z innymi operatorami, ale jest dosyć wysoko. Nie słyszałem ostatnio, żeby były jakieś wycieki, czy żeby ktoś znalazł jakąś dużą podatność w tym Compute Engine.

Są jeszcze automatyczne rekomendacje do maszyn. Czyli jeśli np. sobie wyklikamy maszynę, która jest dosyć droga, to po jakimś czasie Google przeanalizuje pracę tej maszyny i powie nam, że np. powinieneś zmienić tę maszynę na mniejszą, bo po prostu nie wykorzystujesz już jej w pełni.

Mamy też grupy instancji w Compute Engine. Polega to na tym, że możemy sobie stworzyć taką grupę instancji, uruchomić taniej naszą aplikację i wtedy wykorzystać skalowanie. I to dotyczy zarządzalnych grup instancji. Możemy w ten sposób po prostu skalować naszą aplikację dla większej lub mniejszej liczby użytkowników. Jeśli chodzi o backupy, to Compute Engine jest moim zdaniem bardzo wygodny, ponieważ istnieje niezależność dysku od maszyny. Czyli możemy np. tę maszynę włączyć, odpiąć od niej ten dysk, podłączyć do innej maszyny, możemy zrobić kopię, możemy zrobić snapshot, możemy zrobić harmonogram robienia backupów bez naszego nadzoru, i to jest bardzo wygodne.

I jeszcze jedną istotną cechą Compute Engine są sieci chmurowe VPC. Google to bardzo fajnie rozwiązał. To są takie prywatne sieci per projekt, podobne do sieci LAN, one są globalne i w każdym regionie możemy sobie utworzyć podsieci tych sieci. Adresacja tam jest taka jak w sieci lokalnej, czyli zgodna z RFC 1918, i automatycznie już są dodawane ścieżki routingu pomiędzy tymi podsieciami. Więc jeżeli uruchomimy sobie w USA jakąś maszynę i, powiedzmy, w Warszawie, to możemy bardzo łatwo skomunikować je za pomocą tego VPC z użyciem prywatnych adresów IP.

I jeszcze dosyć unikalna rzecz, bardzo fajna, jest taka, że podsieci GCP są regionalne, czyli możemy łatwo tworzyć np. grupę instancji, która będzie się rozciągała na cały region, w różnych zonach. I jeśli jedna zona by nam padła (to się zdarza bardzo, bardzo rzadko), to jest dodatkowa zona czy dwie zony, które zawsze będą działać.

I jeszcze jedną istotną cechą Compute Engine są sieci chmurowe VPC. Google to bardzo fajnie rozwiązał. To są takie prywatne sieci per projekt, podobne do sieci LAN, one są globalne i w każdym regionie możemy sobie utworzyć podsieci tych sieci. Adresacja tam jest taka jak w sieci lokalnej, czyli zgodna z RFC 1918, i automatycznie już są dodawane ścieżki routingu pomiędzy tymi podsieciami. Więc jeżeli uruchomimy sobie w USA jakąś maszynę i, powiedzmy, w Warszawie, to możemy bardzo łatwo skomunikować je za pomocą tego VPC z użyciem prywatnych adresów IP.

👉 Czytaj dalej na: https://porozmawiajmyoit.pl/poit-165-jak-hostowac-aplikacje-w-gcp/

--

--

Dev and life blog. Thoughts about programming, design patterns, Ruby and life.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store