Słowniczek – Cloud DevOps-a

Słowniczek – Cloud DevOps-a

W moim pierwszym wpisie na blogu napisałem, że będę poruszał zagadnienia związane z technologiami chmurowymi, certyfikacją w IT, zadaniach związanych z pracą devopsa oraz od czasu do czasu pojawią się tematy miękkie. Pora więc na dawkę teorii związaną z podstawowymi pojęciami, które każdy devops powinien znać. Dowiecie się kim tak naprawdę jest cloud devops. Rozwinę skróty takie jak CI/CD, serverless, cloud native, IaC, GitOps i kilka innych. Serdecznie zapraszam po solidną i skondensowaną dawkę informacji.

Cloud DevOps

Zacznę dość standardowo: termin DevOps zawiera w sobie dwa akronimy, a mianowicie Dev od słowa Development i Ops od Operations. Osoba na tym stanowisku łączy zadania z tych dwóch grup. Może zatem zajmować się zarówno rozwojem oprogramowania jak i jego administracją już w trakcie działania aplikacji na serwerach. Nasuwa się zatem pytanie po co jednak łączyć te dwie odpowiedzialności skoro wcześniej były one rozdzielone na różne zespoły?

Wszystko sprowadza się do czasu i pieniędzy. Dzięki takiemu połączeniu nasze zespoły programistów są bardziej zwinne. Przy zachowaniu odpowiednich wytycznych możemy szybciej wypuszczać kolejne wersje aplikacji i w krótszym czasie otrzymywać zwrotkę czy wszystko działa jak należy. Takie podeście pozwala oszczędzać cenny czas i pieniądze. Wcześniej gdy zespoły były bardziej podzielone sprzężenie zwrotne następowało dużo rzadziej, a to wpływało na większe problemy z wyprowadzeniem błędów. Działo się tak ponieważ od momentu wydania nowej wersji do wykrycia ewentualnego błędu upływało więcej czasu. Z tego względu często na tym błędzie były już budowane kolejne iteracje oprogramowania, które trzeba było wycofywać lub przerabiać by rozwiązać problem.

Oto typowa pętla pokazująca zarówno model pracy devops-a podzielony na etapy jak i tożsamy z nim proces CI/CD.

źródło: https://www.pngkey.com/

Dodatek cloud odnosi się do technologii chmurowych. Tak naprawdę wydaje mi się, że większość obecnych specjalistów devops mogłoby o sobie mowić cloud devops ponieważ w większym lub mniejszym stopniu na co dzień mają oni styczność z którąś formą chmury: publiczną, prywatną czy hybrydową. Z czasem ten odsetek będzie tylko rósł. Jeśli jesteś devopsem, który nie słyszał jeszcze o chmurze lub nie chcesz o niej słyszeć to według mnie jest to brnięcie w ślepy zaułek.

CI/CD – Continuous integration and delivery

Devops wykorzystuje wiele narzędzi w celu skracania czasu dostarczania oprogramowania i automatyzacji tego procesu. Związany jest z tym następny ważny skrót CI/CD – continuous integration and continuous delivery. Ciągła integracja i ciągłe dostarczanie. Rozwinięcie tego skrótu oraz wyjaśnienie na czym polega ten proces jest chyba jednym z najczęściej zadawanych pytań rekrutacyjnych dla junior devops.

Jest to zautomatyzowany sposób dostarczania oprogramowania. Część CI polega na wysyłaniu nowych partii kodu do zdalnego repozytorium, w którym w sposób automatyczny nasz kod jest budowany i testowany. Po udanych testach artefakt może zostać użyty w dalszej części wdrażania. Artefaktem może być zarówno plik binarny, obraz dokera lub inny rodzaj pliku, który może być użyty do deploymentu aplikacji.

CD – continuous delivery odpowiedzialny jest za przeprowadzenie procesu instalacji/aktualizacji oprogramowania do nowej wersji na środowiskach nieprodukcyjnych i ostatecznie zatwierdzenie przez człowieka instalacji na środowisku produkcyjnym. W przypadku continuous deployment cały proces jest zautomatyzowany włącznie z instalacją na produkcji. Po więcej na temat deploymentu i najczęściej stosowanych strategii wdrażania odsyłam do jednego z moich wcześniejszych wpisów.

Cloud

Rozwój technologii i skala zapotrzebowania na usługi obliczeniowe przyczyniły się do powstania chmur publicznych. Cloud to mówiąc najprościej wielkie centra serwerowe, w których możemy wynajmować moce obliczeniowe na dane okresy czasu. Pierwsze tego typu usługi na świecie dotyczyły hostingu maszyn wirtualnych i kolejki do wspomagania pracy asynchronicznej. Z czasem w odpowiedzi na oczekiwania klientów chmury rozwijały się i dostarczały coraz bardziej wyspecjalizowanych usług. W przypadku największych dostawców chmurowych obecny wachlarz usług wynosi kilka setek różnych serwisów od ogólnego przeznaczenia do bardzo specjalistycznych.

W zamian za oddanie odpowiedzialności za fizyczne maszyny zyskaliśmy niższe koszty, zwinność, bezpieczeństwo, globalną skalę, wydajność, niezawodność.

Przez odpowiedzialność mam na myśli zakres obowiązków jaki dzieli między sobą dostawca chmury a klient. Ogólnie przyjmuje się następujące akronimy w podziale tych odpowiedzialności:

  • On-Premises (wszystkim zajmujemy się sami),
  • IaaS – Infrastructure as a service,
  • PaaS – Platform as a service,
  • SaaS – Software as a service

Na grafice poniżej znaleźć można informacje co wchodzi w dany zakres usługi

żródło: https://medium.com/

Serverless

Wspominając o chmurach nie mogę nie wyjaśnić skrótu serverless, a raczej usług typu serverless. Mówiąc najprościej jest to podejście, w którym osoba korzystająca z takiej usługi całkowicie nie przejmuje się serwerami oraz infrastrukturą, na których dane usługi pracują. To jednak nie wszystko. Dodatkowo usługa powinna móc zejść od poziomu zero, czyli gdy z niej nie korzystamy = nie ponosimy za to kosztów oraz być w stanie skalować się poziomów niebotycznie dużych (nie będę pisał nieskończonych bo zawsze gdzieś jest koniec 😊).

Niestety słówko „serverless” jest do przesady używane przez marketingowców. Wkładane jest wszędzie gdzie tylko się da łamiąc czasem te zasady. Przykładowo AWS kilka miesięcy temu wypuściło Amazon Aurora Serverless v2, które do zera się nie składa. (post na LinkedIni z ciekawymi komentarzami praktyków na temat tej usługi).

Cloud Native

O to jaka jest definicja słowa Cloud Native toczone są spory. Dla mnie Cloud Native to usługi oferowane przez dostawców chmury, które są nierozłączne z danym cloudem. Stosunek ceny do możliwości jest dużo lepszy niż rozwiązania on-premise. Nie czuję się na tyle kompetentny by wchodzić w większe szczegóły, ale mogę was odesłać do kapitalnego artykułu Przemka Malaka, który jest cloud native specjalistą.

IaC – Infrastructure as Code

Dzięki powstaniu chmur zyskaliśmy możliwość wynajmowania w bardzo elastyczny sposób zasobów sprzętowych. Naturalnie następnym krokiem musiało być zautomatyzowanie tego procesu za pomocą IaC. Infrastruktura jako kod pozwala na tworzenie, modyfikacje i usuwanie infry w przewidywalny powtarzalny sposób. Zasoby definiujemy za pomocą kodu co pozwala na zapis historii zmian, wprowadzanie kroków zatwierdzania, możliwość wprowadzania walidacji polityk przed implementacją w zależności od środowiska. Dzięki zapisowi infrastruktury jako kodu możemy wersjonować naszą infrę i dzielić się nią z innymi zespołami, a dodatkowo eliminujemy pracę manualną i błędy ludzkie z niej wynikające.

Jest to kluczowa praktyka DevOps ponieważ dzięki temu możemy zautomatyzować jeszcze bardziej proces deploymentu aplikacji. Mamy przykładowo możliwość w sposób automatyczny postawić środowisko identyczne do produkcyjnego, sprawdzić naszą aplikację i zwolnić zasoby płacąc tylko za wykorzystany czas.

Obecnie najpopularniejszym narzędziem do pracy z IaC jest hashicorp Terraform, który jest niezależny od dostawcy chmury. Naturalnie prawie każda chmura ma swoje własne narzędzie do IaC, ale ograniczają się one do swojego „własnego podwórka”. Są to np. dla AWS – AWS Cloud Formation, Azure – Azure Resource Menager, GCP – Google Cloud Deployment Manager.

Konteneryzacja i Witrualizacja

Każdy z tych tematów zasługuje na więcej aniżeli jeden wpis. Ciężko jest w kilku zdaniach wyjaśnić o co chodzi tym bardziej jeśli wcześniej nie mieliśmy styczności z opisywanymi zagadnieniami. Proszę zatem o przymknięcie oka na zastosowane przeze mnie uproszczenia.

Wirtualizacja polega na zasymulowaniu systemu operacyjnego, zasobów i sterowników. Maszyna wirtualna tworzy środowisko, na którym mamy możliwość wykonywać procesy obliczeniowe i możemy mieć wiele takich wirtualnych maszyn odpalonych na jednym fizycznym komputerze. Konteneryzacja jest podobna, ale dużo lżejsza pod względem wymagań do uruchomienia ponieważ nie musimy dla każdego kontenera uruchamiać osobnego OS (systemu operacyjnego), a kontenery możemy bardzo szybko postawić i zamykać. Podobnie jak w przypadku maszyn wirtualnych możemy na nich wykonywać różne operacje. Poniżej wrzucam uproszczoną grafikę ukazującą różnice między wirtualizacją a konteneryzacją.

źródło: https://res.armor.com/


Naturalnie każda z tych technologii ma swoje wady i zalety, po szczegóły odsyłam do zewnętrznego materiału.

GitOps

Jest to metodologia czerpiąca pełnymi garściami z kultury Devops. Skupia się na automatyzacji ciągłego wdrażania aplikacji oraz automatyzacji w tworzeniu infrastruktury. Dla gitops jak to się ładnie mówi jedynym źródłem prawdy czyli „single source of truth” są repozytoria, w których trzymane są dane konfiguracyjne środowisk i kody źródłowe aplikacji. W procesie wydawania nowych wersji oprogramowania tworzone są za pomocą IaC środowiska testowe, na których aplikację są sprawdzane i po przejściu testów w kilka minut zamykane. Po więcej na temat gitopsa odsyłam do materiału na GitLab.

Podsumowanie

Trudno w jednym wpisie wymienić wszystkie ważniejsze pojęcia. W internecie znajdziecie inne słowniki, w których wpisano dziesiątki różnych terminów i magicznych buzzword. Z większością się spotkacie, a o części nie usłyszycie. W tym wpisie starałem się jednak wybrać technologie, które każdy devops powinien znać. Nie musimy być w nich ekspertami, ale na pewno powinniśmy poruszać się w nich biegle.

Comments are closed.