Уточнение от переводчика: пост, перевод которого вы видите перед собой, был написан 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.

ship crash shipt it revert


Единственный вменяемый способ перейти на 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-crash-illustrated
Типичный каскадный отказ 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 порядка! Теперь моей "песочницей" будет работа с пенсиями нескольких миллионов американцев, в том числе кого-то из тех людей, которые читают этот блог.


docker your pension fund 100% certified not dockeri


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

Комментарии (25)


  1. relgames
    11.01.2018 11:52

    Ни одного конкретного примера.


    Есть же официальная compatibility matrix https://success.docker.com/article/Compatibility_Matrix


    Сами используем kubernetes, проблем не наблюдаем.


    1. achekalin Автор
      11.01.2018 12:03

      Это серия из двух постов (точнее, конечно, их переводы), написанных в конце 2016 и начале 2017 года, а в мире Docker-а события меняются быстро. Основные претензии оригинального автора приведены в первом посте, здесь как бы завершение истории — так, как он сам ее воспринимает.


      1. P6i
        12.01.2018 09:59

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


        1. achekalin Автор
          12.01.2018 10:40

          Интересно, а где он мог найти мануал, как точно делать, чтобы 100% работало? Думаю, в американском пенсионном фонде ссылка уже не нужна, а вот здесь, на хабре, пригодилась бы.



          1. P6i
            13.01.2018 13:42

            Что касается системы — ответ Вам дал relgames ранее, что касается самих контейнеров и билда их, бэстпрактикс — их уже уйма.

            Докер на разных проектах с 1.7 версии, системы были debian/ubuntu/gentoo (Слава Богу, Centos миновал). В контейнерах микросервисы (да те что по парадигме 12 факторов, во всяком случаи по-максимому пытаются этой парадигме следовать, которые прекрано работают в докер контейнерах. Пихать стэйтфул в докер и пытаться писать в последний слой фс или еще какое-то извращени — хватило ума так не делать, это посыл к прошлой статье кстати) писаные на java, go, nodejs. На одном проекте был хороший pps по сети, да там активно использовался net:host.


    1. antage
      11.01.2018 23:16

      Ни одного конкретного примера.

      Из проблем с которыми сталкивался лично на debian 8:


      1. Kernel panic на linux 3.16 в aufs (вылечилось переходом на 4.9 и overlayfs).
      2. Иногда, после обновления ядра и перезагрузки сервера, docker отказывался запускать контейнеры. В логе ошибка, что контейнер с таким именем уже есть (хотя его нет). Полное удаление /var/lib/docker и перезагрузка никак не помогала. Спасал только откат на предыдущую версия ядра. В какой-то версии докера этот баг пофиксили.

      Из недавнего: если запустить параллельно 10-20 docker pull на один и тот же образ, то скачанный образ может оказаться поврежденным.


      1. achekalin Автор
        12.01.2018 10:53

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

        А ваш опыт заставляет вздрогнуть. И это в восьмерке, на которую так надеялся автор оригинального поста!


      1. relgames
        12.01.2018 15:37

        Да, мы тоже сталкивались (и сталкиваемся) с проблемами, например, docker stop иногда вешает контейнеры. Проблема в том, что у нас своя конфигурация, а не рекомендованная.

        Мы попробовали CentOS 7.3 и последний Docker на devicemapper, работает отлично.


        1. achekalin Автор
          12.01.2018 15:41

          Думаю, по прошествии некоторого времени и автор поста смог бы найти (с какой-то попытки) работающую комбинацию. Но на момент его тестов (притом что в то время Докер уже использовался им в проде) на его взгляд стабильных решений то ли еще не существовало, то ли ему не получилось её найти.
          Приведенная вами ссылка тут уже упоминалась в комментариях. Однако была ли она доступна автору оригинального поста во время его злоключений — не берусь сказать, думаю, что нет.


  1. achekalin Автор
    11.01.2018 12:03

    del


  1. UncleAndy
    11.01.2018 17:01

    Я так понимаю, что рассмотрены только варианты что-бы оно работало «из коробки»? Варианты со сборкой нужного ядра для хоста и ручной установкой всех нужных утилит не рассматриваются?


    1. achekalin Автор
      11.01.2018 17:09
      +1

      Думаю, автор оригинального поста именно об этом полпоста и писал: что на продакшене, где цена простоя высока, он привык видеть стабильные решения, а, по его стандартам, вариант «взять свежую версию ядра и собрать самому» к таковым не относятся.

      По сути, да, его вопросы легко сводятся к «когда же в дистирибутивах появится надежная, из коробки работающая поддержка докера, а в докере — надежная же поддержка этих дистрибутивов?!»


    1. PoisonousJohn
      12.01.2018 16:22

      Вопрос в том — зачем? Ведь докер говорит о том, что должно работать одинаково на всех системах. Build, Ship, and Run Any App, Anywhere


      1. achekalin Автор
        12.01.2018 16:26

        Судя по полученным автором результатом, верить словам докера по меньшей мере неосмотрительно. Даже описанная в посте чехарда с невозможностью правильно определить, какое ядро в системе (пункт про Centos/RHEL7), и должным образом настроиться под него «дорого» стоят в реальной жизни. В смысле нервов админов, конечно.
        Я бы поверил скорее в то (и принял), что пусть под одной системой, но работает железобетонно, чем под всеми, но под частью даже инсталлер лажается.


        1. PoisonousJohn
          12.01.2018 16:41

          Согласен. Но учитывая, что докер построен вокруг именно такой идеологии, то в случае с одной системой его выгода сомнительна.


  1. Bal
    11.01.2018 19:10

    Дочитал внимательно до места, где описывается невозможность использования Docker под Ubuntu а продакшне, а дальше уже по диагонали. Можете считать меня тем самым любителем в классификации, но Docker под Ubuntu прекрасно работает несколько лет на десятке очень разнородных машин (от выделенных серверов до копеечных VPS) и сотне контейнеров. При чём я, как раз, не гонюсь за новыми версиями. Вот, буквально вчера обнаружил, что на одной из машин docker-compose даже не поддерживает ключик -f в команде logs :) И до сих пор не сталкивался с проблемами docker. Хотя, конечно, может, мне просто так везло :)


    1. dmitry_ch
      11.01.2018 23:36

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


  1. QtRoS
    11.01.2018 23:38

    Kubernetes хорошо, а Docker плохо. Но Kubernetes использует Docker. Как так?


    1. achekalin Автор
      12.01.2018 10:50

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


  1. nanoraptorok
    12.01.2018 10:00

    «есть 10 типа людей», а не «10 типов», если вы имеете в виду бинарную систему счисления.


    1. achekalin Автор
      12.01.2018 10:03

      Тогда теряется многозначность при чтении. И, если уж говорить в русле поста (где автор, по большей части, рассказывает, как его учили жить), предвижу поток комментов «У вас написано есть 10 типа людей, а по-русски согласовывается как 10 типов».
      Немного изменил предложение, возможно, теперь получше.


      1. QtRoS
        12.01.2018 22:12

        Обычно в таком случае я пишу «Всего типов людей 10». Можно прочитать и как 2, и как 10.


  1. Ipeacocks
    14.01.2018 01:48

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

    Вы пишете о Докере, а потом говорите что что-то не так с CentOS/RHEL 7? Что же с ним не так?


    1. dmitry_ch
      14.01.2018 19:43

      Автор оригинального поста, полагаю, сильно изумился бы вопросу. Докер — не самодостаточная программа, а некий механизм, управляющий возможностями, предоставляемыми ОСью. Если Докер никак не может понять, как это делать в RHEL7, то, похоже, Докер не может показать устойчивый детектинг (почему — в тексте рассказано), притом не то чтобы всегда не может, а нет уверенности, что при обновлении ОС (в т.ч. ядра) ничего не сломается, т.к. обещаний от авторов Докера не было никаких.
      Как вариант, Докер мог не заявлять CentOS/RHEL 7 в списке поддерживаемых.