Ryzyko kontra nagroda: przewodnik po zrozumieniu kontenerów oprogramowania

Ci z nas, którzy są wystarczająco dorośli, pamiętają dzień, w którym oprogramowanie było dostarczane głównie na nośnikach fizycznych. Rozpowszechnienie szerokopasmowego Internetu i smartfonów doprowadziło nas do ery usług internetowych — oprogramowania hostowanego w chmurze, do którego mają dostęp klienci użytkowników, takich jak przeglądarki i aplikacje.

Jeszcze nie tak dawno aplikacje webowe były uruchamiane bezpośrednio na fizycznych maszynach w prywatnych centrach danych. W celu ułatwienia zarządzania aplikacje te były zwykle monolityczne — jeden duży serwer zawierał cały kod zaplecza i bazę danych. Teraz usługi hostingowe, takie jak Amazon i rozpowszechnienie technologii hiperwizorów, zmieniły to wszystko. Dzięki Amazon Web Services (AWS) i narzędziom takim jak VirtualBox spakowanie całego systemu operacyjnego w jednym pliku stało się łatwe.

Korzystając z usług takich jak EC2, pakowanie obrazów maszyn i łączenie zestawów serwerów wirtualnych stało się łatwe. Wraz z nim pojawił się paradygmat mikrousług — podejście do architektury oprogramowania, w którym duże, monolityczne aplikacje są dzielone na mniejsze, ukierunkowane usługi, które dobrze wykonują jedną rzecz. Ogólnie rzecz biorąc, takie podejście pozwala na łatwiejsze skalowanie i opracowywanie funkcji, ponieważ wąskie gardła są szybciej znajdowane, a zmiany systemowe łatwiejsze do wyizolowania.

Zwierzęta do żywego inwentarza

Zostałem inżynierem infrastruktury w szczytowym momencie tego trendu. Przypominam sobie, jak budowałem moje pierwsze środowisko produkcyjne w Amazon, używając serii skryptów bash. Kelnerzy byli dla mnie jak zwierzęta domowe. Każdemu z nich nadałam urocze imiona. Monitorowałem ich uważnie. Szybko reagowałem na alerty i utrzymywałem je w dobrym stanie. Traktowałem te przypadki z miłością i uczuciem, ponieważ próba ich zastąpienia była bolesna — podobnie jak ukochanego zwierzaka.

Pojawił się Chef, narzędzie do zarządzania konfiguracją i niemal od razu moje życie stało się łatwiejsze. Dzięki narzędziom takim jak Chef i Puppet możesz wyeliminować większość ręcznego bólu związanego z zarządzaniem systemem w chmurze. Możesz użyć jego konstrukcji „środowisk”, aby oddzielić serwery programistyczne, pomostowe i produkcyjne. Możesz użyć jego „torebek danych” i „roli” do zdefiniowania parametrów konfiguracyjnych i wypychania zestawów zmian. Teraz wszystkie moje „zwierzątkowe” serwery ukończyły szkołę posłuszeństwa.

W 2013 roku pojawił się Docker i rozpoczęła się nowa era: era oprogramowania jako żywego inwentarza (przepraszam wszystkich wegan na widowni). Paradygmat kontenera dotyczy orkiestracji, a nie zarządzania konfiguracją. Narzędzia takie jak Kubernetes, Docker Compose i Marathon skupiają się na poruszaniu się po predefiniowanych obrazach zamiast dostosowywania wartości konfiguracji w uruchomionych instancjach. Infrastruktura jest niezmienna; kiedy pojemnik się zepsuje, nie próbujemy go naprawiać – strzelamy mu w głowę i wymieniamy. Bardziej dbamy o zdrowie stada niż pojedynczych zwierząt. Nie nadajemy już naszym serwerom uroczych imion.

Nagrody

Kontenery ułatwiają wiele rzeczy. Pozwalają firmom bardziej skupić się na własnym, specjalnym sosie. Zespoły techniczne mogą mniej martwić się o zarządzanie infrastrukturą i konfiguracją, a zamiast tego martwić się głównie o kod aplikacji. Firmy mogą pójść o krok dalej i korzystać z usług zarządzanych dla takich rzeczy jak MySQL, Cassandra, Kafka czy Redis, aby w ogóle nie zajmować się warstwą danych. Istnieje kilka startupów oferujących usługi uczenia maszynowego typu „plug and play”, które umożliwiają firmom przeprowadzanie zaawansowanych analiz bez martwienia się o infrastrukturę. Kulminacją tych trendów jest model bezserwerowy — podejście do architektury oprogramowania, które umożliwia zespołom wydawanie oprogramowania bez zarządzania pojedynczą maszyną wirtualną lub kontenerem. Umożliwiają to usługi AWS, takie jak S3, Lambda, Kinesis i Dynamo. Aby rozszerzyć analogię, przeszliśmy od zwierząt domowych do inwentarza żywego, do pewnego rodzaju usług dla zwierząt na żądanie.

Wszystko to jest bardzo fajne. To szaleństwo, że żyjemy w czasach, w których dwunastoletni dzieciak może za pomocą kilku kliknięć uruchomić wyrafinowany system oprogramowania. Pamiętajmy, że jeszcze nie tak dawno było to niemożliwe. Zaledwie kilka prezydentów USA temu nośniki fizyczne były standardem i tylko duże firmy miały środki na produkcję i dystrybucję oprogramowania. Naprawy błędów były luksusem. Teraz ten dwunastoletni dzieciak może założyć konto AWS i udostępnić swoje oprogramowanie całemu światu. Jeśli pojawi się błąd, ktoś go zaatakuje na Slacku i za kilka minut poprawka jest dostępna dla wszystkich użytkowników.

Ryzyko

Bardzo, bardzo fajnie, ale nie bez swojej ceny – poleganie na dostawcach chmury, takich jak Amazon, oznacza poleganie na wielkich korporacjach i własnych technologiach. Jeśli Richard Stallman i Edward Snowden nie sprawili, że martwisz się takimi rzeczami, niedawna porażka z Facebookiem z pewnością powinna.

Większa abstrakcja od sprzętu niesie ze sobą również ryzyko mniejszej przejrzystości i kontroli. Kiedy coś się zepsuje w systemie obsługującym setki kontenerów, musimy mieć nadzieję, że awaria wypłynie gdzieś, gdzie uda nam się wykryć. Jeśli problem dotyczy systemu operacyjnego hosta lub sprzętu bazowego, jego ustalenie może być trudne. Jeśli nie masz odpowiedniej instrumentacji, awaria, która mogła zostać rozwiązana w ciągu 20 minut przy użyciu maszyn wirtualnych, może zająć godziny lub dni przy użyciu kontenerów.

Nie chodzi tylko o awarie, o które musimy się martwić, jeśli chodzi o rzeczy takie jak Docker. Jest też problem bezpieczeństwa. Bez względu na to, z jakiej platformy kontenerowej korzystamy, musimy ufać, że nie ma tylnych drzwi ani nieujawnionych luk w zabezpieczeniach. Korzystanie z platform open source również nie gwarantuje bezpieczeństwa. Jeśli polegamy na obrazach kontenerów innych firm dla części naszego systemu, możemy być podatni na ataki.

Zakończyć

Paradygmat inwentarza żywego jest atrakcyjny z wielu powodów, ale nie jest pozbawiony wad. Przed przystąpieniem do konteneryzacji całego stosu zespoły techniczne muszą zastanowić się, czy jest to właściwy wybór i upewnić się, że mogą złagodzić negatywne skutki.

Osobiście uwielbiam pracować z kontenerami. Jestem podekscytowany, widząc, jak potoczą się sprawy w ciągu najbliższych dziesięciu lat, gdy pojawią się nowe platformy i paradygmaty. Jednak jako były konsultant ds. bezpieczeństwa jestem na tyle ostrożny, że wiem, że wszystko ma swoją cenę. To do inżynierów należy zachowanie czujności, aby upewnić się, że nie zrezygnujemy z naszej autonomii jako użytkowników i programistów. Nawet najłatwiejszy obieg CD/CI na świecie nie byłby wart swojej ceny.