Риск против вознаграждения: руководство по пониманию программных контейнеров

Те из нас, кто достаточно взрослый, могут вспомнить день, когда программное обеспечение доставлялось в основном на физических носителях. Распространение широкополосного Интернета и смартфонов привело нас к эпохе веб-сервисов — программного обеспечения, размещенного в облаке, к которому обращаются пользовательские клиенты, такие как браузеры и приложения.

Не так давно веб-приложения запускались непосредственно на физических машинах в частных центрах обработки данных. Для простоты управления эти приложения обычно были монолитными — один большой сервер содержал весь внутренний код и базу данных. Теперь услуги веб-хостинга, такие как Amazon, и распространение технологии гипервизора изменили все это. Благодаря Amazon Web Services (AWS) и таким инструментам, как VirtualBox, стало легко упаковать всю ОС в один файл.

С помощью таких сервисов, как EC2, стало легко упаковывать образы машин и объединять наборы виртуальных серверов. Появилась парадигма микросервисов — подход к архитектуре программного обеспечения, при котором большие монолитные приложения разбиваются на более мелкие специализированные сервисы, которые хорошо выполняют одну задачу. В целом такой подход упрощает масштабирование и разработку функций, поскольку узкие места обнаруживаются быстрее, а системные изменения легче изолировать.

Домашние животные для домашнего скота

Я стал инженером по инфраструктуре как раз в разгар этой тенденции. Я помню, как создавал свою первую производственную среду на Amazon, используя серию bash-скриптов. Серверы были для меня как домашние животные. Я дал каждому из них милые имена. Я внимательно следил за ними. Я быстро реагировал на предупреждения и поддерживал их в рабочем состоянии. Я относился к этим экземплярам с любовью и привязанностью, потому что было больно пытаться заменить их — как к любимому домашнему животному.

Появился Chef, инструмент управления конфигурацией, и почти сразу моя жизнь стала проще. С такими инструментами, как Chef и Puppet, вы можете избавиться от большей части ручной работы, связанной с управлением облачной системой. Вы можете использовать его конструкцию «среды» для разделения серверов разработки, подготовки и производства. Вы можете использовать его «пакеты данных» и «роли» для определения параметров конфигурации и отправки наборов изменений. Теперь все мои «домашние» слуги закончили школу послушания.

Затем, в 2013 году, появился Docker, и началась новая эра: век программного обеспечения как домашнего скота (извиняюсь перед всеми веганами в аудитории). Парадигма контейнера — это оркестровка, а не управление конфигурацией. Такие инструменты, как Kubernetes, Docker Compose и Marathon, сосредоточены на перемещении по предопределенным образам, а не на настройке значений конфигурации в запущенных экземплярах. Инфраструктура неизменна; когда контейнер выходит из строя, мы не пытаемся его починить — мы стреляем ему в голову и заменяем его. Мы больше заботимся о здоровье стада, чем отдельных животных. Мы больше не даем нашим серверам милые имена.

Награды

Контейнеры многое упрощают. Они позволяют предприятиям больше сосредоточиться на собственном особом соусе. Технические команды могут меньше беспокоиться об управлении инфраструктурой и конфигурацией и вместо этого больше беспокоиться о коде приложения. Компании могут пойти еще дальше и использовать управляемые сервисы для таких вещей, как MySQL, Cassandra, Kafka или Redis, чтобы вообще не иметь дело с уровнем данных. Есть несколько стартапов, предлагающих услуги машинного обучения «подключи и работай», которые позволяют компаниям выполнять сложную аналитику, не беспокоясь об инфраструктуре. Кульминацией этих тенденций стала бессерверная модель — подход к архитектуре программного обеспечения, который позволяет командам выпускать программное обеспечение без управления отдельной виртуальной машиной или контейнером. Сервисы AWS, такие как S3, Lambda, Kinesis и Dynamo, делают это возможным. Таким образом, если продолжить аналогию, мы перешли от домашних животных к домашнему скоту и к какой-то службе для животных по требованию.

Все это очень круто. Это безумие, что мы живем во времена, когда двенадцатилетний ребенок может раскрутить сложную программную систему несколькими щелчками мыши. Мы должны помнить, что не так давно это было невозможно. Всего несколько президентов США назад физические носители были стандартом, и только крупные компании имели средства для производства и распространения программного обеспечения. Исправление ошибок было роскошью. Теперь этот двенадцатилетний ребенок может создать учетную запись AWS и сделать свое программное обеспечение доступным для всего мира. Если есть ошибка, кто-нибудь найдет ее в Slack, и через несколько минут всем пользователям будет доступно исправление.

Риски

Очень, очень круто, но не без цены — зависимость от облачных провайдеров, таких как Amazon, означает зависимость от крупных корпораций и проприетарных технологий. Если Ричард Столлман и Эдвард Сноуден не заставили вас беспокоиться о таких вещах, то недавнее фиаско с Facebook, безусловно, должно было.

Большая абстракция от аппаратного обеспечения также влечет за собой риск снижения прозрачности и контроля. Когда что-то ломается в системе с сотнями контейнеров, мы должны надеяться, что сбой всплывет где-то, что мы сможем обнаружить. Если проблема связана с основной операционной системой или базовым оборудованием, ее может быть трудно определить. Сбой, который можно было устранить за 20 минут с помощью виртуальных машин, может занять несколько часов или дней, если у вас нет подходящего инструментария, чтобы устранить его с помощью контейнеров.

Когда речь идет о таких вещах, как Docker, нам нужно беспокоиться не только о сбоях. Существует также проблема безопасности. Какую бы контейнерную платформу мы ни использовали, мы должны быть уверены, что в ней нет бэкдоров или нераскрытых уязвимостей безопасности. Использование платформ с открытым исходным кодом также не является гарантией безопасности. Если мы полагаемся на сторонние образы контейнеров для частей нашей системы, мы можем быть уязвимы.

Заворачивать

Парадигма животноводства привлекательна по ряду причин, но не лишена и недостатков. Прежде чем спешить с контейнеризацией всего стека, технические команды должны подумать о том, является ли это правильным выбором, и убедиться, что они могут смягчить негативные последствия.

Лично я люблю работать с контейнерами. Мне не терпится увидеть, что будет происходить в ближайшие десять лет по мере появления новых платформ и парадигм. Однако, как бывший консультант по безопасности, я достаточно осторожен, чтобы знать, что у всего есть своя цена. Инженеры должны сохранять бдительность, чтобы гарантировать, что мы не отказываемся от своей автономии как пользователей и разработчиков. Даже самый простой в мире рабочий процесс CD/CI не будет стоить затрат.