11.04.20234 min
Aleksandra Koprucka
Capgemini

Aleksandra KopruckaIT Catalog & Portfolio ManagerCapgemini

Co znaczy zapakować aplikację w pudełko?

Zapoznaj się z tematem aplikacji zapakowanych w pudełko oraz odkryj nowy podcast o IT.

Co znaczy zapakować aplikację w pudełko?

Jak myślisz, czy da się zoptymalizować pracę przy projekcie i ustrzec użytkowników przed brakiem dostępności aplikacji? Jak myślisz, czy to możliwe, że jako osoba korzystająca z usług banku już nie będziesz borykać się z brakiem dostępu do bankowości elektronicznej, np. z powodu prac serwisowych? Choć wydaje się to niemożliwe, to świat IT wdraża rozwiązania, które urzeczywistniają powyższe scenariusze.

Konteneryzacja, bo o niej tu mowa, jest stosunkowo nową technologią, która wkracza prężnym krokiem do świata IT. Choć technologie oparte o kontenery są na razie skomplikowane a na rynku pracy mało jest jeszcze specjalistów, którzy mają dużą wiedzę w tym temacie, to warto się na chwilę pochylić nad aplikacjami „zapakowanymi w pudełko”.

Konteneryzacja to proces polegający na „pakowaniu” aplikacji, a nawet całych systemów operacyjnych, w kontenery. Kontener natomiast jest to zespół procesów na komputerze czy serwerze, który jest odizolowany od całej reszty przez specjalne mechanizmy. W uproszczeniu kontener można przyrównać do bańki, w której żyją procesy i przetwarzają dane, a te natomiast przesyłane są w różne miejsca, niezależnie od tego, co się dzieje na samym serwerze.

Kojarzyć się to może z wirtualizacją, ale należy zwrócić uwagę na fakt, że są to dwie odmienne technologie. Niektórzy twierdzą nawet, że konteneryzacja to następny poziom wirtualizacji. Skąd zatem takie przeświadczenie? Podstawową różnicą między maszynami wirtualnymi a kontenerami jest wielkość i sprawność.

Kontenery zawierają tylko to, co dana aplikacja potrzebuje do życia, wykorzystując jądro systemu operacyjnego hosta. VM-kę, z drugiej strony, obrazowo można przedstawić jako cały komputer ze wszystkimi komponentami jak np. kompletny system operacyjny (łącznie z jądrem) i zwirtualizowane podzespoły sprzętowe (CPU, dyski, kontrolery SCSI). Tak więc cała logika konteneryzacji polega na zminimalizowaniu maszyny wirtualnej do rozmiarów aplikacji i jej zależności, balansując pomiędzy oszczędnością zasobów a zarządzalnością wynikowym kontenerem.

Drugą ważną kwestią jest wspomniana wcześniej sprawność – aplikacja w kontenerze może być z powrotem dostępna nawet kilka sekund po inicjacji restartu lub awarii hosta. Jest to kusząca opcja dla firm, które inwestują w projekty związane z administrowaniem aplikacji – pełna dostępność inżynierów, bez impaktu dla użytkowników, z jednoczesną oszczędnością, jeśli chodzi o prace nad projektem po godzinach. Może to być jedna z kluczowych kwestii przy podejmowaniu decyzji o tym, czy migrować do Kubernetesa. 

Osoby pracujące na stanowiskach konsultantów i architektów, które specjalizują się w konteneryzacji, próbują swoich klientów przeprowadzić przez te innowacyjne narzędzia i procesy w sposób, możliwie jak najmniej ryzykowny. 

Kluczowe jest uświadomienie klientowi, że częściowo prawdą jest, że Kubernetes jest kolejnym Platform as a Service. Co prawda zmigrowana platforma będzie utrzymywana przez chmurę, ale istotne jest, że to specjaliści będą nad tą platformą też czuwać - mówi Damian Naprawa, Software Architect w Capgemini Polska

Wyzwaniem dla specjalistów jest wyjaśnienie biznesowi, czym jest konteneryzacja i jakie korzyści wynikają z migracji. Osoby pracujące w Kubernetes mogą na co dzień zmagać się z różnymi zadaniami - od stworzenia kontenera na rzecz jednego czy kilku użytkowników, migracją infrastruktury do kontenerów i ostatecznie wsparciem dla tego rozwiązania.

Na czym należy się skupić i od czego trzeba zacząć migrację do Kubernetesa, jeśli klient wyrazi chęć przeprowadzenia takiego procesu? W pierwszej kolejności należy przeprowadzić visibility study, czyli przyjrzeć się regulacjom danej firmy i standardami zabezpieczeń. Kolejnym krokiem na początku podróży migracyjnej, jaki warto podjąć to sprawdzenie, czy organizacja ma już wdrożoną kulturę devops lub na jakim jest ona poziomie. Pozwoli to na łatwiejsze przejście do Kubernetesa.

A z technicznego punktu widzenia? Jedną z opcji w procesie CI/CD jest takie skonstruowanie pipeline’ów niskim nakładem pracy i kosztów, aby produkowały obraz kontenerowy z każdego serwisu. Następnie można wprowadzić skalowanie obrazów, co byłoby pierwszym krokiem w stronę security. Posiadając działające serwisy i kod zamknięty w obrazach, warto się zastanowić nad zmianą tych serwisów tak, aby korzystały z kontenerów, a nie kodów.

Kolejnym etapem jest weryfikacja kosztów infrastruktury oraz kosztów całego projektu i sprawdzenie czy business case "się spina” i czy klient jest w stanie zapłacić taką kwotę, aby osiągnąć zamierzony cel – a lista elementów zawartych w kosztorysie jest dość długa. 

Jeżeli wizja, którą przedstawiamy klientowi jest dla niego zadowalająca to pora na wdrażanie całego planu w życie. Dobrą praktyką jest spisanie dokumentacji HLD i LLD, wykonanie dobrego projektu
i estymowanie jego czasu. Kolejno należy się zastanowić, od czego zacząć migrację i jakie podejście zastosować, wymienić wady i zalety i przedstawić je klientowi, aby mógł zadecydować, które podejście zastosować.

Jaki jest must have przy tworzeniu kontenerów? Co jest killer case'em dla klienta? Jakie mogą być showstoppery przy migracji do Kubernetesa? Co tak właściwie kryje się w kosztorysie? Jeżeli chcesz dowiedzieć się więcej, zasubskrybuj podcast TechChatter, już niedługo pojawi się nowy odcinek na temat Kubernetesa.

<p>Loading...</p>