Раздел 5.3. Контейнеры и Оркестрация: Война за стандарт (2013 — 2016)

Мы входим в 2013 год. Облака (AWS) уже существуют, но использовать их — это боль. Разработчики и сисадмины находятся в состоянии холодной войны. Первые хотят обновлять код каждый час, вторые хотят ничего не трогать, чтобы сервер не упал.

В этом разделе мы увидим, как 5-минутная презентация уничтожила эту войну, и как Google использовала «Звездный путь», чтобы не дать Amazon захватить мир.

Раздел 5.3. Контейнеры и Оркестрация: Война за стандарт (2013 — 2016)

В начале 2010-х индустрия страдала от проблемы, которую называли «Матрица Ада» (The Matrix of Hell).

Представьте таблицу.

По горизонтали: Десятки языков и фреймворков (Python 2.7, Python 3.0, Ruby on Rails, Node.js, Java, Go).
По вертикали: Десятки сред исполнения (ноутбук разработчика, тестовый сервер, продакшен-сервер на Debian, облако AWS на Amazon Linux, облако Azure).

Проблема: Вам нужно, чтобы любая ячейка по горизонтали работала в любой ячейке по вертикали. Это был кошмар.

Разработчик пишет код на своем MacBook. Все работает.
Он отправляет код сисадмину.
Сисадмин запускает его на Red Hat Linux, и всё падает, потому что версия библиотеки openssl на сервере старая, а пути к файлам другие.

Главная фраза десятилетия: «Но на моей машине это работает!» ("It works on my machine!"). Компании тратили миллионы долларов на то, чтобы просто заставить код работать в продакшене так же, как он работал в разработке.

А. Docker: Спасение от «Matrix of Hell»

Сюжет: Демо, изменившее мир

15 марта 2013 года. Санта-Клара, конференция PyCon. На сцену для «молниеносного доклада» (Lightning Talk) выходит Соломон Хайкс. Он основатель маленького стартапа dotCloud, который находится на грани банкротства. Они пытались делать платформу (PaaS), но проигрывали гигантам вроде Heroku. У Соломона есть всего 5 минут. Он не показывает красивые слайды. Он открывает черный терминал.

«Привет, я Соломон. Я хочу показать вам инструмент, который мы сделали внутри dotCloud. Мы называем его Docker».

Он пишет команду: docker run hello-world. Бац — запускается процесс. Он пишет другую. Бац — запускается база данных Redis. Зал молчит. Люди не понимают, что происходит. Это выглядит как обычная виртуальная машина (VM), но она запускается за миллисекунды, а не за минуты. И она не требует установки отдельной ОС.

Когда Хайкс заканчивает, зал взрывается аплодисментами. Люди поняли: он только что показал Святой Грааль.

Метафора: Грузовой контейнер

Хайкс объяснил суть Docker через гениальную аналогию с логистикой.

До 1956 года: Грузчики в портах страдали. Мешки с кофе, бочки с нефтью, пианино и автомобили — всё имело разную форму. Грузить это на корабль было долго и опасно (пианино могло раздавить мешки с кофе).
После 1956 года: Малкольм Маклин придумал стандартный стальной контейнер.
- Капитану корабля всё равно, что внутри — кофе или пианино. Он просто грузит стандартные ящики размером 20 футов.
- Водителю грузовика всё равно. Крановщику всё равно.

Docker сделал то же самое для софта. Docker — это стандартный контейнер.

Внутри: Ваш код + библиотеки + настройки + кусочек операционной системы (файловая система).
Снаружи: Стандартный интерфейс.

Разработчик упаковывает приложение в контейнер на своем ноутбуке. Этот контейнер гарантированно запустится на сервере AWS, в дата-центре банка или на умном чайнике, и будет работать точно так же. Проблема «разных версий библиотек» исчезла. Контейнер носит свои библиотеки с собой.

Техническая суть: Linux Containers (LXC)

Справедливости ради, Хайкс не изобрел контейнеры. Технология изоляции процессов (cgroups и namespaces) была в ядре Linux годами (ее использовали Google и Parallels). Но использовать LXC было так же сложно, как управлять вертолетом. Docker сделал LXC доступным для масс. Он сделал его простым, как одна команда docker run.

Результат: Стартап dotCloud закрылся, но переродился в компанию Docker Inc., которая через год стоила миллиард долларов. Хайкс стал иконой DevOps.

Б. Kubernetes: Звездный путь Google

К 2014 году Docker победил. Все упаковывали софт в контейнеры. Но возникла новая проблема: «А как управлять тысячами этих контейнеров?». Если у вас приложение состоит из 50 микросервисов, и каждый запущен в 10 экземплярах для надежности, у вас 500 контейнеров.

Кто следит, чтобы они не падали?
Кто распределяет их по физическим серверам?
Как они находят друг друга в сети?

Это называется Оркестрация. Началась «Война Оркестраторов»:

Docker Swarm: Решение от самой Docker Inc. Простое, встроенное, но функционально слабое.
Apache Mesos: Мощное, но сложное, как управление космодромом (использовалось в Twitter и Airbnb).
...и тут проснулась Google.

Секретное оружие: Borg

В Google смеялись над хайпом вокруг Docker. Дело в том, что Google использовала контейнеры уже 10 лет. Вся инфраструктура Google (Поиск, Gmail, YouTube, Maps) работала на секретной внутренней системе под названием Borg. Borg управлял миллионами серверов как единым суперкомпьютером. Инженеры Google даже не знали, на каком физическом сервере работает их код. Они просто говорили Боргу: «Запусти мне это», и Борг находил место.

Бизнес-контекст: Google Cloud безнадежно проигрывал войну облаков компании Amazon (AWS). AWS была лидером в сдаче в аренду виртуальных машин (EC2). Google поняла: «Если мы будем играть по правилам Amazon (продавать виртуалки), мы проиграем. Нам нужно сменить правила игры. Нам нужно сделать так, чтобы людям стало всё равно, на чьих виртуалках они сидят».

Трое инженеров Google — Брендан Бёрнс, Джо Беда и Крейг Маклаклен — предложили дерзкий план:

«Давайте построим Open Source версию системы Borg. Если весь мир перейдет на неё, то индустрия стандартизируется. Мы превратим инфраструктуру AWS в дешевый товар (Commodity)».

Project Seven: Привет от «Звездного пути»

Проект назвали Project Seven. Это отсылка к персонажу сериала «Звездный путь: Вояджер» (Star Trek: Voyager) — Седьмая-из-девяти (Seven of Nine).

Она была Боргом (киборгом из злого коллективного разума), которую спасли люди, и она стала доброй и человечной.
Точно так же Kubernetes должен был стать «добрым Borg-ом» для всех людей, освобожденным из секретных лабораторий Google.

Пасхалка: Посмотрите на логотип Kubernetes (синий штурвал). Посчитайте спицы (ручки). Их ровно семь. Это дань уважения Project Seven.

Позже проекту дали имя Kubernetes (с греческого — «Кормчий» или «Пилот»). Отсюда сокращение K8s (K + 8 букв + s).

Победа: Как убить конкурента подарком

В 2015 году Google выпускает Kubernetes 1.0. Но они делают нечто странное. Вместо того чтобы продавать его или держать контроль, они отдают его в нейтральный фонд CNCF (Cloud Native Computing Foundation). Они отдают права на код Linux Foundation.

Зачем? (Стратегия) Это был шах и мат компании Docker Inc. Docker Inc. хотела встроить свой оркестратор (Swarm) в Docker и стать монополистом, контролирующим, как запускаются приложения. Google сказала индустрии:

«Смотрите, вот Kubernetes. Он мощнее, чем Swarm (потому что основан на 10-летнем опыте Borg), и он НИЧЕЙ. Он общий. Не бойтесь вендор-лока. Microsoft, Red Hat, IBM — присоединяйтесь!»

Индустрия (Red Hat, IBM, Microsoft, Intel) мгновенно объединилась вокруг Kubernetes, чтобы не зависеть от капризов Docker Inc. и Amazon.

Результат: Docker Swarm умер. Apache Mesos ушел в узкую нишу. Kubernetes стал стандартом. Сегодня K8s называют «Операционной системой для облака». Если вы знаете Kubernetes, вы можете развернуть свое приложение на AWS, Google Cloud, Azure или на серверах в подвале — команды одни и те же.

Итог раздела 5.3

Мы прошли путь от хаоса зависимостей («Matrix of Hell») к идеальному порядку.

Docker стандартизировал «кирпич» (Контейнер). Теперь любой код упакован одинаково.
Kubernetes стандартизировал «стройку» (Оркестрация). Теперь мы управляем тысячами контейнеров как единым целым.

Теперь у нас есть бесконечное железо (AWS) и роботы, которые управляют софтом на этом железе (K8s). Инфраструктура готова к работе с данными такого объема, который раньше и не снился. В следующем модуле мы увидим, как мы научились обрабатывать эти данные в реальном времени, создав нервную систему для бизнеса — Apache Kafka.