Уточнение от переводчика: пост, перевод которого вы видите перед собой, был написан 23 февраля 2017 года, по мотивам исходного поста Moby/Docker в продакшене. История провала, перевод которого (за авторством olegchir) здесь, на Хабре, вызвал живые обсуждения. Просьба читать, делая поправку на дату написания — оригинальный текст написан почти год назад!

Относиться к тексту можно по-разному. Попробуйте, наслаждаясь утренним кофе, посмотреть на себя через призму восприятия автора, и подумайте, как бы он, с его опытом и отношением к работе, отреагировал, услышав тот или иной совет по поводу Docker?

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

Мы рассмотрим уроки, извлеченные из всех последних общений и статей, но, для начала — уточнение, напоминание и немного контекста.

Отказ от ответственности: предполагаемая аудитория

Большое количество комментарием показло, что мир делится на людей всего 10 типов:

1) Любители

Обычно поддерживают тестовые или хобби-проекты, где нет реальных пользоваталей. Могут полагать, что использование бета-версии Ubuntu — нормально, и называют все “стабильное” устаревшим.

Нельзя его винить: на его-то машине код работает.

2) Профессионалы

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

… потому что может не работать в системе, куда заходят ещё 586 миллионов пользователей.

К какому типу аудитории относитесь вы?

Граница между этими мирами весьма тонкая, однако, очевидно, у них очень разные стандарты и ожидания.

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

Задумайтесь на минуту о ваших собственных стандартах. Чего вы ожидаете достичь при помощи Docker? Что вы потеряете, если произойдет сбой всех систем, где он у вас запущен, и повредятся смонтированные тома хранения? Это важный фактор, который может повлиять на ваш выбор.

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

Docker совершенно не готов поддерживать обработку пенсии моей мамы, как кто-то может даже думать обратное??? Что же, думаю, накопленный опыт работы с Docker не был достаточно хорошо документирован.

В чем вы хотите быть уверены для начала использования Docker-а?

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

У меня было время собрать отзывы о различных условиях работы и самому проверить еще пару.

Мы рассмотрим результаты исследований: то, что было сочтено уверенно работающим, что — не работающим, что — испытывающим периодические сбои или как просто эпически неуспешное.

Внимание, спойлер: в случае с Docker нет ничего, что бы гарантированно работало.

Отказ от ответственности: понимайте риски и последствия

Я склонен доверять своим собственным стандартам (как профессионал, которому приходится обращаться с реальными деньгами) и следовать полученным выводам (т.к. доверяю надежным источникам, работающим с системами реального мира).

К примеру, если комбинация ОС и файловой системы помечена как “не подойдет: зарегистрирован катастрофический сбой файловой системы с потерей данных всего тома“, она (с моей точки зрения) не готова для работы в продакшене, но вполне подойдет для использования студентом, которому требуется раз-другой запустить что-нибудь в поднятой vagrant-ом виртуалке.

Вы можете столкнуться, а можете и не столкнуться с приведёнными проблемами. В любом случае, они упоминаются, поскольку их существование "в природе" подтверждено людьми, которые столкнулись с ними. Если ваше окружение окажется достаточно близким к использованному этими людьми, вы на верном пути к тому, чтобы стать следующим свидетелем.

Худшее, что может случиться — и обычно случается — с Docker-ом, это то, что все будет ОК во время проверки на тестовом стенде, а проблемы могут всплыть гораздо позже, после внедрения, когда вы уже не сможете просто взять и откатить все изменения.

CoreOS

CoreOS — это ОС, которая только и умеет, что запускать контейнеры, и предназначена исключительно для запуска контейнеров.

В прошлой статье я сделал вывод, что CoreOS может оказаться единственной системой, на которой может успешно использовать Docker. Это утверждение может быть верным, а может и не быть.

Мы отказались от идеи использования CoreOS.

Во-первых, основным преимуществом Docker является унификация окружений разработки и продакшена. Наличие отдельной ОС в продакшене только для работы контейнеров полностью разрушает этот момент.

Во-вторых, Debian (мы сидели на Debian) объявили о следующем major-релизе в первом квартале 2017 года. Поскольку потребуется много усилий, чтобы разобраться в текущей системе, и перенести все на CoreOS — без гарантии успеха — гораздо разумнее было решить подождать следующего релиза Debian.

CentOS/RHEL

CentOS/RHEL 6

Docker на CentOS/RHEL 6 — "не подойдет: известны проблемы с файловой системой, до полной потери данных на томе"

1. Различные известные проблемы с драйвером devicemapper.
2. Критические проблемы с томами LVM в связке с devicemapper, приводящие к повреждению данных, падению контейнера и зависанию демона Docker, требующие жесткой перезагрузки.
3. Пакеты Docker не поддерживаются в этом дистрибутиве. Существует множество критических исправлений ошибок, которые были выпущены в пакетах CentOS/RHEL 7, но не были перенесены (бэкпортированы) в пакеты CentOS/RHEL 6.

Единственный вменяемый способ перейти на Docker в крупной компании, все еще работающей на RHEL 6 => не делать этого!

CentOS/RHEL 7

Первоначально, работая на ядре ветки 3, RedHat бекпортировал в него функции из ядра ветки 4, что было обязательным для запуска Docker.

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

Существуют различные проблемы с использованием томов LVM, в зависимости от версии ОС.

В остальном, может и повезти, и нет, причем результат для вас может быть другим, чем для меня.

Начиная с CentOS 7.0, RedHat рекомендовал некоторые настройки, но сейчас я уже не могу найти эту страницу на их сайте. Во всяком случае, для более поздних версий есть множество критических исправлений, поэтому вы всегда ДОЛЖНЫ обновляться до последней версии.

Начиная с CentOS 7.2 RedHat рекомендует и поддерживает исключительно XFS, и они выставляют специальные флаги конфигурации. AUFS более не существует, OverlayFS официально считается нестабильным, BTRFS — в бета-статусе (technology preview).

Сотрудники RedHat признаются, что им очень трудно создать подходящие условия для работы Docker, и это является серьезной проблемой, потому что они перепродают Docker как часть своего решения OpenShift. Попробуйте сделать продукт на нестабильном ядре!

Если вы любите играть с огнем, то эта ОС, похоже, для вас!

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

Debian

Debian 8 jessie (stable)

Основная причина проблем, с которыми мы столкнулись, заключалась в том, что, как рассказывалось в прошлой статье, мы использовали Debian (stable) на продакшене.

Грубо говоря, Debian заморозила ядро на версии, которая не поддерживает ничего, что требуется Docker-у, а несколько компонентов, которые присутствуют, содержат ошибки.

Docker на Debian — серьезный "не подойдёт: в драйвере AUFS (и не только) присутствует большое число проблем, от чего хост обычно крашится, потенциально разрушая данные, и это только вершина айсберга.

Использование Docker на Debian 8 — гарантированно, на 100%, самоубийственный шаг, и так было с момента создания Docker несколько лет назад. Меня убивает мысль, что никто никогда не документировал это до сего дня.

Я хотел показать вам график экземпляров AWS, падающих, как домино, но у меня нет подходящего инструмента для мониторинга и отрисовки, поэтому вместо этого я приведу диаграмму фортепиано, которая выглядит сходным образом.

Типичный каскадный отказ Docker на нашей тестовой системе.

Типичный каскадный отказ Docker на наших тестовых системах: Сбой тестового слейва… следующий делает попытку принять нагрузку через две минуты… и тоже умирает… Этот конкретный каскад произвел 6 попыток обойти проблему, что несколько больше, чем обычно, но ничего необычного.

У вас должны быть настроены алармы в CloudWatch для автоматического перезапуска мертвых хостов и отправки уведомлений о сбоях.

Кстати: вы также можете настроить аларм в CloudWatch для автоматической отправки готового отчета о проблеме вашему регулятору каждый раз, когда висит проблема, продолжающаяся более 5 минут.

Я не хвастаюсь, но мы неплохо поддерживали Docker. Забудьте о Chaos Monkey, это детская игра, попробуйте запустить торговые системы, обрабатывающие миллиарды долларов — на Docker [1].

[1] Пожалуйста, не делайте этого. Это ужасная идея!

Debian 9 stretch

Debian stretch запланирован стать стабильным в 2017 (примечание: должен был стать релизом, пока я пишу и редактирую эту статью).

Он будет содержать ядро 4.10, которое оказалось последним из LTS, опубликованным к тому времени.

На момент выпуска Debian Stretch станет самой современной стабильной операционной системой, и у нее, как утверждается, будут все замечательным функции, необходимые для запуска Docker (конечно, пока требования Docker не изменятся).

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

Ubuntu

Ubuntu всегда был более свежим, чем обычные серверные дистрибутивы.

К сожалению, я не знаю серьезных компаний, которые работают на Ubuntu. Это стало источником больших недопониманий в сообществе любителей Docker, потому что разработчики и любители-блоггеры тестируют все на последнем Ubuntu (даже LTS [2]), но они совершенно не представляет себе эксплуатацию продакшен-систем в реальном мире (RHEL, CentOS, Debian или что-то из этих экзотических Unix/BSD/Solaris).

Я не могу прокомментировать ситуацию с LTS 16, поскольку я не использую этот релиз. Это единственный дистрибутив, в котором доступны Overlay2 и ZFS, что дает еще несколько возможностей для проверки и, возможно, отыщется что-то работающее?

Релиз LTS 14 является окончательным "не подойдет": слишком старый, не имеет необходимых компонентов.

[2] Я получил немало комментариев и недружелюбных писем от людей, советующих «просто» использовать последнюю бета-версию Ubuntu. Как будто миграция всех работающих систем, изменение дистрибутива и переход на бета-платформу, которая даже не существовала в момент тестов, было бы разумным решением.

---

Уточнение: как я уже говорил, я не вернусь на Docker, поэтому не хочу тратить час на поиск и сбор ссылок, но, похоже, сделать это все же придется, поскольку я сам получаю их теперь в самом необычном виде.

Я получил довольно оскорбительное письмо от парня, который явно находится в любительской лиге, поскольку пишет, что «любой идиот может запустить Docker на Ubuntu», а затем переходит к перечислению списка пакетов ПО и расширенных системных настроек, которые являются обязательными для запуска Docker на Ubuntu, т.е. того, что, предположительно «каждый может найти через 5 секунд при помощи Google».

В основе его сообщения лежит этот отчет об ошибке, который на самом деле является первым результатом в Google для запросов «Ubuntu docker not working» и «Ubuntu docker crash»: Ubuntu 16.04 install for 1.11.2 hangs.

В этом отчете об ошибке, опубликованном в июне 2016 года, подчеркивается, что установщик на Ubuntu просто не выполняет свою задачу вообще, потому что не устанавливает некоторые зависимости, требуемые Docker для запуска, а дальше море комментариев со способами обхода проблемы от разных пользователей, и наплевательское #WONTFIX от разработчиков Docker.

Последний ответ сотрудник Docker дает через 5 месяцев, и пишет, что установщик на Ubuntu не будет поправлен никогда, однако следующая major-версия Docker может использовать какие-то другие компоненты, поэтому проблема как таковая может и не пропасть.

Недавно была выпущена новая версия (v1.13) — через 8 месяцев после того ответа — и пока не подтверждено, проявляется ли та же ошибка в ней, однако точно известно, что она содержит новые изменения в самом Docker, ломающие старые настройки.

Довольно обычно на фоне того, что можно ожидать от Docker. Вот чеклист для проверки:

• Все ли поломано настолько, что Docker не может работать вообще? ДА.
• Поломано ли это для всех пользователей, скажем, крупного дистрибутива? ДА.
• Есть ли своевременный ответ от разработчиков, подтверждающий наличие проблемы? НЕТ.
• Содержит ли подтверждение признание существования проблемы и указание уровня её серьезности? НЕТ.
• Планируется ли какое-либо исправление? НЕТ.
• Существует ли множество способов обхода проблемы, имеющих разный уровень опасности и сложности? ДА.
• Будет ли проблема когда-нибудь исправлена? КТО ЗНАЕТ.
• Будет ли исправление, если оно когда-либо случится, бекпортировано? НИКОГДА.
• Является ли универсальным ответом на все сообщения о проблеме совет "просто обновиться до последней версии"? КОНЕЧНО.

---

AWS Container Service

AWS имеет AMI, специально подготовленный для запуска Docker. Он основан на Ubuntu.

Как подтверждают их внутренние источники, у AWS возникли серьезные проблемы в обеспечении работы Docker хотя бы как-то достаточно хорошо.

В результате, они выпустили AMI, собрав кастомную ОСь с кастомным пакетом Docker с кастомными исправлениями ошибок и кастомными же backport-ами. И после выпуска они все еще тратят массу усилий и проводят постоянные тесты, чтобы все это работало вместе.

Если вы привязаны к Docker и работаете на AWS, ваше единственное спасение может состоять в том, чтобы переложит возню с ним на плечи AWS.

Google Container Service

Google предлагает контейнеры как сервис. Google просто предоставляет интерфейс Docker, контейнеры запускаются на внутренних технологиях контейнеризации Google, которые могут и не страдать от всех недостатков реализации Docker.

Поймите меня правильно! Контейнеры прекрасны как концепция, проблема не в теории, а в практической реализации и инструментах, доступных нам (то есть Docker-е), которые в лучшем случае являются экспериментальными.

Если вы действительно хотите играть с Docker (или контейнерами), и не работаете на AWS, то вариант от Google будет вашим единственным надежным выбором, тем более, что он идет с Kubernetes для оркестрации, что выделяет решение от Google в отдельную лигу.

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

OpenShift

Невозможно построить стабильный продукт на поломанном ядре, однако RedHat пытается.

Из отзывов, которые у меня были, они изо всех сил стараются смягчить проблемы Docker, и с переменным успехом. В вашем случае результат может оказаться другим.

Считая, что оба последних варианта ориентируются на крупные компании, которым есть что терять, я действительно сомневаюсь в целесообразности подобного выбора (т.е. выбора чего-нибудь, что построено поверх Докера).

Лучше всего попробовать использовать "обычные" облака: AWS, Google или Azure. Использование виртуальных машин, плюс предлагаемых провайдерами сервисов даст, плюс-минус, 90% того, что умеет Docker, и 90% того, чего Docker не умеет. Это лучшая долгосрочная стратегия.

Скорее всего, в вашем случае, причиной желания запуска OpenShift может стать невозможность использовать публичное облако. Что же, это довольно тяжелый путь к цели! (Удачи вам в этом. Пожалуйста, напишите комментарий, каков оказался ваш опыт)

Итого

• CentOS/RHEL: Русская рулетка.
• Debian: Выпрыгнуть из самолета голым.
• Ubuntu: Не уверен Поправка: LOL.

• CoreOS: Не стоит усилий.

  
  
• AWS Containers: Ваше единственное спасение, если вы вынуждены иметь дело разом и с Docker, и с AWS.
• Google Containers: Единственный практичный способ запуска Docker, который не является абсолютно безумным.
• OpenShift: Не уверен. Зависит от того, насколько хорошо смогут работать поддержка и инженеры.

Бизнес-перспектива

Docker не имеет бизнес-модели и не может монетизироваться. Справедливости ради стоит сказать, что они делают релизы на всех платформах (в т.ч. Mac/Windows) и интегрируют всевозможные функции (Swarm) в отчаянных попытках: 1) не позволить любому конкуренту иметь какую-либо отличительную особенность; 2) заставить всех использовать именно Docker и инструменты Docker; 3) полностью удержать клиентов в своей экосистеме; 4) публиковать тонну новостей, статей и выпусков в процессе, увеличивая хайп; и 5) оправдать собственную рыночную оценку.

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

В то же время, конкуренты, а именно Amazon, Microsoft, Google, Pivotal и RedHat, конкурируют самыми разными способами, и зарабатывают на контейнерах больше денег, чем сам Docker, в то время как компания CoreOS работает над ОС (CoreOS) и конкурирующей технологией контейнеризации (Rocket).

В результате, много крупных рыночных игроков с большой "огневой мощью" нацеливаются на активное и решительное соревнование с Docker. Им совершенно не интересно позволить Docker привязать к себе кого бы то ни было. И по одиночке, и все вместе они заинтересованы в смерти Docker и замене его чем-то другим.

Назовем это войной контейнеров. Посмотрим, к чему она приведёт.

В настоящее время Google лидирует, они заменяют Docker, и они являются единственными, кто может обеспечить оркестрацию из коробки (Kubernetes).

Заключение

Говорил ли я, что Docker — нестабильный, "игрушечный" проект?

Конечно, кто-то скажет, что описанные проблемы даже не существовали, или уже остались в прошлом. Они не в прошлом, проблемы очень актуальны и очень реальны. Docker страдает от критических ошибок, что делает его непригодным для использования во всех крупных дистрибутивах, ошибок, которые постоянно мешают в течение многих лет, некоторые из них присутствуют по-прежнему, даже сегодня.

Если вы поищете строчку с конкретной комбинацией «Docker + версия + файловая система + ОС» в Google, вы найдете ссылки на множество проблем, в любой момент времени в прошлом, вплоть до момента появления Docker на свет. Это тайна, как что-то может быть так сильно падучим, и никто об этом не пишет (на самом деле, было несколько статей, они просто оказались потерянными под массой рекламы и быстрых оценочных суждений). Последним программным обеспечением с таким уровнем ожиданий и с таким уровнем отказов был MongoDB.

Я не смог найти никого на планете, кто бы использовал Docker серьезно, успешно и без особенных хлопот. Опыт, упомянутый в этой статье, был приобретен кровью, кровью сотрудников и компаний, которые усердно учились Docker-у, в то время как каждая секунда простоя стоила 1000 долларов.

Надеюсь, мы можем учиться на своих и чужих ошибках, и не повторять их.

Если вам интересно, следовало ли вам заняться Docker-ом годы назад => Ответом будет "черт возьми, нет, вам не пришлось стреляться!" Вы можете сказать это своему боссу (даже сегодня пользы от Docker немного, если вокруг не развернута оркестрация, что само по себе является довольно экспериментальным вопросом).

Если вам интересно, следует ли вам начать использовать Docker сегодня, хотя у вас хорошо работают и текущие способы запуска вашего ПО, и у вас есть какие-либо ожидания относительно качества работы => Разумным ответом будет совет подождать до выхода RHEL 8 и Debian 10. Не гоните. Вещи должны устояться и пакеты не должны развиваться быстрее дистрибутивов, на которых будут использоваться.

Если вы любите играть с огнем => посмотрите в сторону Google Container Engine в Google Cloud. Определенно высокий риск, возможная польза также высока.

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

Хочу ли я потратить еще несколько сотен часов, чтобы снова собрать эту информацию? Неа. Я предпочту провести вечер на Tinder, чем с Docker-ом. До свидания, Докер!

Что дальше?

Вернемся ко мне. У моего плана действий по управлению контейнерами и облаками был большой недостаток, который я пропустил: средний срок пребывания в технических компаниях по-прежнему измеряется не в больших годах, поэтому 2017 год начался с того, что меня переманили на новое место.

Плохая новость: никаких облаков и Docker там, куда я иду. Никаких новостей о прорывах в технологиях. Сиди, и делай свою работу сам.

Хорошие новости: не придется "играть" с миллиардами долларов других людей… поскольку я продвигаюсь как минимум на 3 порядка! Теперь моей "песочницей" будет работа с пенсиями нескольких миллионов американцев, в том числе кого-то из тех людей, которые читают этот блог.

Будьте уверены: ваша пенсия в хороших руках!