Mija właśnie 10 lat od czasu, kiedy po raz pierwszy polska firma zaprezentowała na VMworld w Las Vegas studium przypadku zastosowania technologii maszyn wirtualnych do budowy środowiska Disaster Recovery dla krytycznej aplikacji biznesowej. Polska – jako rynek rozwijający się – była wspaniałym poligonem dla takich nowości. Rodzime przedsiębiorstwa relatywnie szybko, odważnie, a jednocześnie w pełni profesjonalnie adoptowały nowe technologie.
Piękno świata IT polega na tym, że jest on bardzo dynamiczny, rozwojowy i pełen wyzwań. Trend goni trend, technologia technologię. I tak 10 lat później nowoczesne wdrożenia aplikacji biznesowych są rozproszone, oparte o kontenery, uruchamiane w przeróżnych centrach danych, z uwzględnieniem chmury publicznej włącznie. To olbrzymia zmiana, ale… Czy Docker i systemy nim zarządzające – takie, jak Kubernetes – położyły kres platformom do automatyzacji/orkiestracji typu vRealize Automation czy OpenStack?
Mnożenie maszyn wirtualnych już nie wystarczy
Przed rozważeniem odpowiedzi na to pytanie warto nieco usystematyzować kilka pojęć. Otóż wirtualizacja serwerów – czy też innych zasobów fizycznych – to warstwa separująca system operacyjny od sprzętu, którą nazywamy hypervisor (termin, którego lepiej nie próbować tłumaczyć z angielskiego). Do tej kategorii zaliczymy XenServer, KVM, vSphere, Hyper-V i podobne. Istotną cechą tych rozwiązań, do której w dalszej części będziemy się odnosić to system operacyjny, który jest fundamentem dla komponentów aplikacyjnych, które będą na nim zainstalowane.
Wirtualizacja – poza konsolidacją wynikającą z warstwy abstrakcji – zapewniała jeszcze jedną cechę, którą ciężko przecenić nawet dzisiaj, a mianowicie elastyczność. Początkowo jednak powstawało niejednokrotnie o wiele za dużo maszyn wirtualnych. Przyjmowano bowiem bezpośrednie odzwierciedlenie zasobów fizycznych w środowiskach wirtualnych. Z czasem moc wirtualizacji została okiełznania, a do zarządzania nią wprowadzano sukcesywnie kolejne komponenty, które w przemyślany i kontrolowany sposób wprowadzały samoobsługę. Tak powstała automatyzacja czy raczej, jak kto woli, orkiestracja. Do tej kategorii z pewnością można zaliczyć rozwiązania takie jak vRealize Automation, OpenStack, Ansible, Terraform i wiele innych.
Innymi słowy, jeśli wymagana jest separacja dwóch różnych aplikacji to będą potrzebne dwie maszyny wirtualne, gdyż to one w środowisku wirtualnym stanowa najmniejszy możliwy byt. W czasie, gdy technologie wirtualizacji świeciły największe triumfy to wystarczało. Wdrożenia te nawet wyprzedzały swoją epokę. Podział jednego serwera fizycznego na kilka – a z biegiem czasu kilkanaście – maszyn wirtualnych pozwalał osiągać niesamowite współczynniki konsolidacji. Dziś to już za mało, ale o tym za chwilę.
Wirtualizacja – poza konsolidacją wynikającą z warstwy abstrakcji – zapewniała jeszcze jedną cechę, którą ciężko przecenić nawet dzisiaj, a mianowicie elastyczność. Początkowo – ze względu na łatwość tworzenia maszyn wirtualnych – powstawało ich niejednokrotnie o wiele za dużo. Przyjmowano bowiem bezpośrednie odzwierciedlenie zasobów fizycznych w środowiskach wirtualnych.
Wprowadzenie automatyzacji procesów zarządzania infrastrukturą IT
Z czasem moc wirtualizacji została okiełznania, a do zarządzania nią wprowadzano sukcesywnie kolejne komponenty, które w przemyślany i kontrolowany sposób wprowadzały samoobsługę. Tak powstała automatyzacja czy raczej, jak kto woli, orkiestracja. Do tej kategorii z pewnością można zaliczyć rozwiązania takie jak vRealize Automation, OpenStack, Ansible, Terraform i wiele innych.
Ich główne zadanie to automatyzacja różnych procesów zarzadzania infrastrukturą IT w różnych obszarach w sposób bezpieczny, optymalny i co do zasady pozwalający na model samoobsługowy. Dostępny przez środowisko graficzne lub przez API. Technologie te, choć coraz bardziej dojrzałe nie zdominowały rynku tak jak wcześniej sama wirtualizacja. Wynikać to może z faktu, iż w przeciwieństwie do samej wirtualizacji – szczególnie serwerów – praktycznie zawsze jest to rozwiązanie wymagające w mniejszym lub większym stopniu integracji, niejednokrotnie również w zakresie napisania kodów.
Kontenery przesunęły warstwę abstrakcji o poziom wyżej
Zanim jeszcze na dobre przedsiębiorstwa przyswoiły mechanizmy orkiestracji pojawiła się konteneryzacja, której erę rozpoczął Docker. Znowu warstwa abstrakcji została przesunięta o poziom wyżej. Teraz już nie system operacyjny a same aplikacje w kontenerach stanowią najmniejszą jednostkę granulacji. Oznacza to, że na sprzęcie fizycznym, może egzystować jeden system operacyjny lub wiele instancji w maszynach wirtualnych natomiast w tych systemach dodatków instaluje się platformę Docker, a aplikacje umieszczane są w kontenerach.
Adresy IP przypisywane do systemów operacyjnych rozszerzane są o konkretne porty tak, aby zapewnić komunikacje między poszczególnymi kontenerami. Natomiast typowe systemy plików często zamienia się na obiektową przestrzeń dostępną poprzez aplikacyjne API. Jak łatwo się domyślić nie trzeba było długo czekać, aby wraz z kontenerami pojawiły się platformy zarządzające, automatyzujące, czy jak kto woli orkiestrujące pracę kontenerów. Takimi są np. Kubernetes, Mesosphere czy OpenShift.
Orkiestracja maszyn wirtualnych a orkiestracja kontenerów
Czy to oznacza, że wcześniejsze rozwiązania odchodzą do lamusa? Wydaje się ze w pewnym sensie odpowiedzią na to pytanie są poprzednie akapity, w których wykazaliśmy, że są to technologie rozłączne i wzajemnie się uzupełniające. Jak już zostało to powiedziane, kontenery do pracy również wymagają systemu operacyjnego, a to wprost oznacza, że platformy typu OpenStack czy vRA jak najbardziej mają sens bo ich działanie zapewnia zasoby rożnego typu w warstwie poniżej systemu operacyjnego, czego nawet nie jest świadomy ani Docker, ani komponenty nim zarządzające. Kontenery z natury rzeczy są nieco bliżej biznesu – pośrednio oczywiście, ponieważ w naturalny sposób są narzędziem w rękach programisty. Tego zaś nie interesuje środowisko sieciowe, serwerowe czy macierzowe a nawet i bardzo często sam system operacyjny. Programista, żeby tworzyć musi mieć środowisko uruchomieniowy dla swoich kodów i wydaje się, że Docker i Kubernetes doskonale się do tego nadają.
Zanim jeszcze na dobre przedsiębiorstwa przyswoiły mechanizmy orkiestracji pojawiła się konteneryzacja, której erę rozpoczął Docker. Znowu warstwa abstrakcji została przesunięta o poziom wyżej. Teraz już nie system operacyjny a same aplikacje w kontenerach stanowią najmniejszą jednostkę granulacji. Oznacza to, że na sprzęcie fizycznym, może egzystować jeden system operacyjny lub wiele instancji w maszynach wirtualnych natomiast w tych systemach dodatków instaluje się platformę Docker, a aplikacje umieszczane są w kontenerach. nie trzeba było długo czekać, aby wraz z kontenerami pojawiły się platformy zarządzające, automatyzujące pracę kontenerów, np. Kubernetes, Mesosphere czy OpenShift.
Nie zmienia to jednak faktu, że podwaliny pod te komponenty też trzeba wykreować i zarządzać nimi w optymalny, najlepiej zoptymalizowany sposób. I właśnie dlatego znana dzisiaj automatyzacja infrastruktury – mimo dużego postępu – również sens ma, a może szczególne w środowiskach deweloperskich i testowych. Szczególna korzyść można zauważyć wtedy, kiedy efekt synergii jest największy – gdy jedno środowisko automatycznie wywołuje procesy w drugim.
Konieczna ewolucja platform takich, jak OpenStack czy vRA
Warto jednak zauważyć, że wspomniana na początku dynamika zmian w świecie IT pozwolili rozwiązaniom takim, jak OpenStack czy vRA trwać bez ruchu i rozsądnego rozwoju. Będzie przecież grupa ludzi która zamiast łączyć to co najlepsze w obu opisanych wcześniej obszarach, po prostu z jednego z nich zrezygnuje na rzecz drugiego. Mogą to być np. programiści. Wcześniej, to właśnie oni niejednokrotnie budowali sobie rozwiązani typu OpenStack, aby automatyzować procesy infrastrukturalne, jak choćby kopie migawkowy, nie mając dostępu administracyjnego do zarządzania w organizacji platformami takimi, jak vSphere czy Hyper-V/System Center. Docker i Kubernetes zwalnia ich z obowiązku dbania o warstwę niższą pozostawiając jednak pełnie możliwości i całkowita kontrole nad warstwą aplikacji i komunikacją w ramach tej warstwy.
Kontenery do pracy również wymagają systemu operacyjnego, a to wprost oznacza, że platformy typu OpenStack czy vRA jak najbardziej mają sens bo ich działanie zapewnia zasoby rożnego typu w warstwie poniżej systemu operacyjnego, czego nawet nie jest świadomy ani Docker, ani komponenty nim zarządzające. Kontenery z natury rzeczy są nieco bliżej biznesu – pośrednio oczywiście, ponieważ w naturalny sposób są narzędziem w rękach programisty. Tego zaś nie interesuje środowisko sieciowe, serwerowe czy macierzowe a nawet i bardzo często sam system operacyjny. Programista, żeby tworzyć musi mieć środowisko uruchomieniowy dla swoich kodów i wydaje się, że Docker i Kubernetes doskonale się do tego nadają.
W dobie rozkwitu realnych implementacji metodologii Agile – a są w Polsce takie przypadki, – oraz idących za nimi transformacji IT do DevOps oraz CI/CD korzystanie z dobrodziejstw obu warstw wydaje się wygodne, jeśli nie absolutnie konieczne do uzyskania pełni możliwości nowoczesnych środowisk. Oczywiście opisane tu obszary to tylko jedno z zagadnień w tej dziedzinie. Innym, naturalnie już dzisiaj wymagającym przemyślenia w różnych warstwach i na różnych etapach wdrożeń jest bezpieczeństwo aplikacji, infrastruktury i procesów. Z pewnością na tą tematykę również znajdzie się miejsce na łamach ITwiz.
Krzysztof Waszkiewicz
architekt
Artykuł ukazał się na łamach Magazynu ITwiz nr. 6-7/2018. Szczegóły dotyczące publikacji wraz z formularzem dla osób zainteresowanych zakupem wydania dostępne są na stronie: https://itwiz.pl/kiosk
