Moby/Docker в продакшене. История провала

https://thehftguy.com/2016/11/01/docker-in-production-an-history-of-failure/
  • Перевод

Примечание переводчика: в предыдущей статье о подготовке к девопс-конференциям, Gryphon88 задал резонный вопрос: как отличить cutting-edge и хайп? Нижеследующая статья наполнена сочной незамутненной истерикой, которую так приятно читать с утра, попивая чашечку кофе. Минус в том, что она написана в ноябре 2016, но нетленка не стареет. Если после прочтения захочется добавки, есть комментарии на Hacker News. А у тебя, юзернейм, такой же ад? Пиши в комментариях. Итак, начнем.


В первый раз я встретился с Докером в начале 2015. Мы экспериментировали с ним, чтобы понять, для чего бы его можно употребить. В то время нельзя было запустить контейнер в фоне, не было команд чтобы посмотреть что запущено, зайти под дебагом или SSH внутрь контейнера. Эксперимент оказался быстрым, Докер был признан бесполезным и более похожим на альфу или прототип, чем на релиз.


Промотаем нашу историю до 2016. Новая работа, новая компания, и хайп вокруг докера поднялся безумный. Разработчики уже выкатили докер в продакшен, так что сбежать с него не удастся. Хорошая новость в том, что команда run наконец-то заработала, мы можем запускать и останавливать контейнеры. Оно шевелится!


У нас 12 докеризованных приложений, бегающих на проде прямо в момент написания этой заметки, размазанные на 31 хост на AWS (по одному приложению на хост, дальше объясню — почему).


Эта заметка рассказывает, как мы путешествовали вместе с Докером — путешествие полное опасностей и неожиданных поворотов.



Докер: Проблемы в продакшене


Докер: Поломки и регрессии в обновлениях


Мы использовали следующие версии (или по крайней мере, попытались это сделать):
1.6 => 1.7 => 1.8 => 1.9 => 1.10 => 1.11 => 1.12


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


И обновились только через 3 месяца, потому что необходим был фикс, доступный только в свежих версиях. Ветка 1.6 оказалась уже заброшеной.


Версии 1.7 и 1.8 не запускались. Мы перешли на 1.9 только чтобы спустя две недели найти критический баг в этой версии, поэтому пришлось (снова!) обновляться до 1.10.


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


Большая чатсь хитрых регрессий, на которые мы напоролись, оказалась связанной с сетью. Докер полностью абстрагирует хостовую сеть. От этого случается большая заваруха с пробросом портов, хаками DNS и виртуальных сетей.


Бонус: Докер убрали из официальных репозиториев Debian, поэтому покет переименовался из docker.io в docker-engine. Документация созданная до этого изменения — устарела.


Докер: Старые образы нельзя удалять


Наиболее желаемая, и болезненно отсутствующая фича — команда для удаления старых образов (старше чем X дней, или не используемых Х дней, неважно). Дисковое пространство — это критическая проблема, учитывая что образы часто обновляются и могут занимать более 1 Gb.


Единственный способ очищать место — это запускать следующий хак каждый день, скорей всего по крону:


 docker images -q -a | xargs --no-run-if-empty docker rmi  

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


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


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


Докер: Поддержка в ядре (точнее, ее отсутствие)


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


Мы используем Debian Stable c backports в проде. Мы начали с Debian Jessie 3.16.7-ckt20-1 (ее релизнули в ноябре 2015). У нее был большой критичный баг, из-за которого хаотично крашились хосты (в среднем, каждые несколько часов).


Докер: Нестабильные драйвера файловой системы


У докера есть куча драйверов для подсистемы хранения. Единственный (якобы) ревностно поддерживаемый — AUFS.


Драйвер AUFS нестабилен. Включая критические баги, приводящие к панике ядра и повреждениям данных.


Он сломан (как минимум) на всех ядрах linux-3.16.x. Лечения не существует.


Мы часто обновляемся вслед за Дебианом и ядром. Дебиан выложил специальные патчи вне обычного цикла. Был один большой багфикс AUFS где-то в марте 2016. Мы думали, что это ТОТ САМЫЙ ФИКС, но нет. После него паники начали случаться реже (каждую неделю вместо каждого дня), но баг никуда не исчез.


Однажды летом случилась реграессия прямо в мажорном обновлении, которая притащила с собой предыдущий критичный баг. Он начал убивать сервера CI один за другим, со средним перерывом в 2 часа между умерщвлениями.


В 2016 случилось множество фиксов AUFS. Некоторые критичные проблемы починилсь, но куча других всё еще существует. AUFS нестабилен как минимум на всех ядрах linux-3.16.x.


  • Debian Stable сосет на 3.16. Нестабильно. Нельзя ничего сделать кроме как переключиться на Debian Testing (который использует четвертое ядро).
  • Ubuntu LTS работает на 3.19. Нет никаких гарантий, что последнее обновление починило на нем проблему. Менять нашу основную операционную систему было бы огромной проблемой, но мы так отчаялись, что даже рассматривали этот вариант какое-то время.
  • RHEL/CentOS-6 работает на ядре 2.x, RHEL/CentoS-7 — на ядре 3.10 (с кучей бэкпортов от рэдхата RedHat).

Linux 4.x: ядро официально прекратило поддержку докера


Широко известен факт, что у AUFS бесконечно проблем, что разработчики считают ее мертвым грузом. Ради будущих поколений, AFUS выбросили из четвертого ядра.


Не существует никакого неофициального патча для ее поддержки, нет никакого опционального модуля, бэкпорта или чего-то такого, ничего. AUFS полностью исчезла.


(драматическая пауза)


.


.


.


Как тогда докер работает без AUFS? Ну, он не работает.


(драматическая пауза)


.


.


.


Поэтому чуваки из докера написали новую файловую систему, называющуюся overlay.


"OverlayFS — это современная union файловая система, похожая на AUFS. В сравнении с AUFS, OverlayFS спроектирована проще, присутствует в мейнлайне ядра Linux с версии 3.18, и потенциально работает быстрее".Docker OverlayFS driver


Заметьте, что ее не бэкпортнули в существующие дистрибутивы. Докер не то чтобы заботится об обратной совместимости.


Кстати, "overlay" — это имя как для модуля ядра (разработанного мантейнерами Linux), и для докерного драйвера, который ее использует (является частью докера и разрабатывается докером). Они — два совершенно разных компонента (возможно, с пересечением в истории и списке разработчиков). Проблемы в основном относятся к драйверу, а не к файловой системе как таковой.


Overlay: история неуспеха


Драйвер файловой системы — это сложное программное обеспечение, и оно требует огромного уровня надежности. Старички помнят, как Linux мигрировал с ext3 на ext4. Его не сразу написали, еще больше времени дебажили, и в конце концов ext4 стал основной файловой системой во всех популярных дистрибутивах.


Сделать новую файловую систему за 1 год — невыполнимая миссия. Это даже забавно, учитывая что задача легла не на кого-нибудь, а на Докер, с его послужным списком из нестабильностей и жутких поломманных обновлений — в точности того, чего не хочется видеть в файловой системе.


Короче. В этой истории всё пошло не так. Жуткие истории до сих пор населяют кэш Гугла.


Разработку Overlay бросили в течение года после первого релиза.


драматическая пауза


.


.


.


Время для Overlay2!


"Драйвер overlay2 призван решить ограничения overlay, но он совместим только с ядрами Linux 4.0 и старше, и docker 1.12" — статья "Overlay vs Overlay2 storage drivers"


Сделать файлуху за год — всё еще невыполнимая миссия. Докер попытался и опростоволосился. Тем не менее, они продолжают пробовать! Посмотрим, как это обернется на дистанции в несколько лет.


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


Выводы: как мы видим на примере Overlay и Overlay2. Нет бэкпортов. Нет патчей. Нет совместимости со старыми версиями. Докер просто идет вперед и ломает вещи :) Если вы хотите использовать Докер, придется тоже двигаться вперед, успевая за релизами докера, ядра, дистрибутива, файловых систем, и некоторых зависимостей.


Бонус: всемирное падение Докера


2 июня 2016, примерно в 9 утра (по Лондонскому времени). Новые ключи пушатся в публичный репозиторий докера.


Прямым следствием этого является то, что любой apt-get update (или аналог) на системе, в которую подключен сломанный репозиторий, падает с ошибкой "Error https://apt.dockerproject.org/ Hash Sum mismatch".


Это проблема случилась по всему миру. Она повлияла на ВСЕ системы на планете, к которым подключен репозиторий Докера. На всех версиях Debian и Ubuntu, вне запвисимости от версии операционной системы и докера.


Все пайплайны непрерывной интеграции в мире, основывающиеся на установке/обновлении докера или установке/обновлении системы — сломались. Невозможно запустить обновление или апгрейд существующей системы. Невозможно сделать новую систему, на которую устанавливался бы докер.


Через некоторое время. Новость от сотрудника докера: "Есть новости. Я поднял этот вопрос внутри компании, но люди, которые могут это починить, находятся в часовом поясе Сан Франциско (8 часов разницы с Лондоном — прим. автора), поэтому их еще нет на работе."


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


Пауза, в ходе которой мы употребили всю наличную еду и выпивку.


Новость от чувака из Докера во Флориде, примерно 3 часа дня по Лондонскому времени. Он проснулся, обнаружил ошибку, и работает над фиксом.


Позже были переопубликованы ключи и пакеты.


Мы попробовали и подтвердили работоспособность фикса примерно в 5 дня (по Лондону).


По сути случилось 7 часовое общемировое падение систем, исключительно по причине поломки Докера. Всё что осталось от этого события — несколько сообщений на страничке бага на GitHub. Никакого постмортема. Немного (или вообще никаких?) технических новостей или освещения в прессе, несмотря на катастрофичность проблемы.


Docker Registry


Реестр хранит и обслуживает образы докера.


Автоматическая сборка CI ===> (при удаче) заливка образа в ===> docker registry
Команда на разворачивание <=== залить образ из <=== docker registry


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


Существует 3 версии реестра:


  • Registry v1 — устаревший и заброшенный
  • Registry v2 — полностью переписанный на Go, впервые релизнутый в апреле 2015
  • Trusted Registry — (платный?) сервис, на который много раз ссылается документация, не уверен что понимаю — что это, просто пропускаем его.

Реестр: Забросить и Сломать


Реестр v2 — это полностью переписанный софт. Реестр v1 был отправлен на пенсию сразу же после выпуска v2.


Мы обязаны установить новую штуку (снова!) просто чтобы докер продолжал работать. Они поменяли конфигурацию, урлы, пути, ендпоинты.


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


Выводы: не доверяй никакому инструменту или API из докера. Они постоянно забрасываются и ломаются.


Одна из целей реестра v2 была в создании более качественного API. Это задокументировано здесь, 9 месяцев назад существовала документация, о которой мы уже и не помним.


Реестр: Нельзя очищать образы


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


Реестр просто растёт вечно. Наш реестр может расти на 50 GB в неделю.


У нас нет сервера с бесконечным размером диска. Наш реестр несколько раз переполнял свободное место, превращая пайплайн сборки в ад, а потом мы перешли на S3.


Выводы: Необходимо использовать S3 для хранения образов (это поддерживается из коробки).


Мы делали ручную зачистку всего 3 раза. Во всех случаях нам приходилось остановить реестр, стереть всё на диске и запустить новый контейнер. (К счастью, мы можем пересобирать последние докерные образы с помощью CI).


Выводы: ручное удаление любого файла или директории с диска реестра ПОВРЕДИТ его.


И на сегодняшний день всё так же невозможно удалить образ из реестра. Никакого API тоже нет. (Одна из главных целей создания v2 была в дизайне хорошего API. Миссия провалилась).


Докер: релизный цикл


Релизный цикл докера является единственной константой в экосистеме Докера:


  • Забросить что-то готовое
  • Сделать вместо этого новую штуку и зарелизить
  • Заигнорить существующих пользователей и совместимость с прошлыми версиями

Релизный цикл применим, но не ограничивается следующим: докер, фичи, файловые системы, реестр, всё API…


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


"Мы делаем софт не для того, чтобы его кто-то использовал, а потому что нам нравится делать новые вещи" — будущая эпитафия Докера


Текущий статус-кво Докера в нашей компании


Рост в вебе и микросервисах


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


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


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


В течение года появилось несколько патчей и регрессий. С тех пор мы начали играться с поиском проблем Докера и методами их обхода. Это боль, но не похоже чтобы она оттолкнула людей от внедрения Докера. Внутри компании постоянно существует запрос на использование Докера, и на его поддержку.


Заметка: никакие из этих проблем не коснулись наших клиентов и их денег. Мы довольно успешно сдерживаем буйство Докера.


Запрещено использовать в ядре


Имеются критические приложения, написанные на Эрланге, поддерживаемые и управляемые несколькими ребятами из команды "core".


Они попробовали запускать некоторые из них в Докере. Это не сработало. По какой-то причине, приложения на Эрланге и Докер вместе не сосуществуют.


Это делалось очень давно, и мы не помним всех подробностей. У Эрланга есть конкретные идеи на тему, как должна работать система и сеть, и ожидаемая нагрузка была в тысячах запросов в секунду. Любая нестабильность или несовместимость может считаться выдающейся неудачей. (Мы точно знаем, что в версиях, которые мы использовали для тестирования, присутствовала куча важных проблем со стабильностью).


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


Мы используем Эрланг только для критичных приложений. Например, его юзают чуваки из ядра, которые отвечают за систему оплаты, которая провела в этом месяце 96 миллионов баксов. Кроме того, на нем работает парочка приложений и баз данных, находящихся под их ответственностью.


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


Запрещено использовать в DBA


Докер задуман быть stateless. Контейнеры не имеют хранилища на диске, всё что происходит — эфемерно и уходит, когда контейнер останавливатеся. Не подразумевается, что контейнеры будут хранить данные. На самом деле, они спроектированы чтобы НЕ ХРАНИТЬ данные. Любоая попытка действовать против этой философии приводит к несчастьям.


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


Короче. Докер НЕ ДОЛЖЕН ЗАПУСКАТЬ базы данных в продакшене, by design.


Всё хуже. Помните постоянные паники ядра при использовании докера?


Краш уничтожит базу данных и повлияет на все системы, которые с ней соединены. Этот баг случается хаотически, но срабатывает чаще при интенсивном использовании. База данных — это предельно интенсивная по IO нагрузка, и значит — гарантированная паника ядра. Плюс, существует другой баг, который может поломать маунт докера (уничтожая все данные) и, возможно, системную файловую систему хоста (если они находятся на одном диске).


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


Заключение: Вы ОБЯЗАНЫ НЕ ЗАПУСКАТЬ на Докере базы данных в продакшене, НИКОГДА.


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


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


Личное мнение


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


В данный момент периметр контролируется, охраняется, ограниченный несколькими stateless веб-приложениями и микросервисами. Это всё неважные вещи, они могут докеризовываться и крашиться каждый день, мне наплевать.


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


Сценарий кошмара: обновление кластера с бухгалтерским софтом, сейчас держащего на себе 23M денег клиентов (M — сокращение для миллионов долларов). Люди постоянно спрашивают архитектора, почему бы не переложить эту базу в докер, и лицо архитектора в такие моменты словами не передать.


Мой долг — перед клиентами. Защищать их, и их деньги.


Выживаем с Докером на продакшене


Как Докер хочет выглядеть:




Что такое Докер на самом деле:



Следите за релизами и ченжлогами


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


ansible '*' -m shell -a "uname -a"


Позвольте докеру умирать


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


Время от времени мы мониторим сервера, находим мертвые и перезапускаем с форсом.


Имейте по 3 инстанса всего на свете


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


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


Большую часть времени, крашатся CI и тестовые инстансы. (На них работает куча интенсивных тестов, и проблемы там возникают особо адовые). У нас их много. Бывают вечера, когда они крашатся по 3 штуки одновременно.


Не кладите данные в Докер


Сервисы, которые держат в себе данные, не докеризуются.


Докер спроетирован так, чтобы НЕ ХРАНИТЬ данные. Не пытайтесь идти против этого, это рецепт боли и унижений.


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


Не запускайте ничего важного в Докере


Докер ОБЯЗАТЕЛЬНО сломается. Докер УНИЧТОЖИТ всё, к чему притронулся.


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


Кладите докер на масштабирующиеся группы


Докеризованные приложения должны работать на автомасштабирующихся группах. (Заметка: у нас это сделано всё еще не до конца.)


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


План на будущее


Docker


Невероятное испытание при использовании Докера — прийти к работающей комбинации ядро + дистрибутив + версия докера + файловая система.


Прямо сейчас. Мы не знаем, НИКАКОЙ комбинации, которая является действительно стабильной (может быть, такой не существует?). Мы активно ищем её, постоянно тестируя новые системы и патчи.


Цель: найти стабильную экосистему для запуска докера.


Требуется 5 лет чтобы сделать хороший, стабильный софт, а Docker v1.0 имеет возраст всего лишь 28 месяцев, и у него не было времени повзрослеть.


Время обновления железа — 3 года, цикл релизов дистрибутив — 18-36 месяцев. Докер не существовал на предыдущем цикле, поэтому мы не можем оценить совместимость с ним. Хуже того, он зависит от множества продвинутых внутренних систем, которые довольно новы и тоже не успели ни повзрослеть, ни добраться до дистрибутивов.


Он может стать хорошим продуктом лет через 5. Подождем и посмотрим.


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


Используйте автоматически масштабирующиеся группы


Докер ограничен stateless приложениями. Если приложения может быть пакетизировано в Docker Image, оно может быть пакетизировано в AMI (Amazon Machine Image — прим. пер.). Если приложение может запускаться в докере, оно также может запускаться в автоматически масштабирующейся группе.


Большинство людей игнорируют это, но Docker бесполезен на AWS, и на самом деле это шаг назад.


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


Контейнеры бесполезны на облачных провайдерах. Всегда существует инстанс правильного размера. Просто создайте его с тем количеством памяти/процессора, которое реально нужно приложению. (Минимально на AWS можно сделать t2.nano, который стоит 5 баксов в месяц за 512MB и 5% CPU).


Во-вторых, наибольшее преимущество контейнеров проявляется в системах с системой полной оркестрации всего, позволяющей автоматически управлять всеми командами (create/stop/start/rolling-update/canary-release/blue-green-deployment). Таких систем оркестрации в данный момент не существует. (В этот момент на сцену выходят всякие Nomad/Mesos/Kubernetes, но они пока недостаточно хороши).


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


Создавайте автоматически масштабирующиеся группы для каждого сервиса, и собирайте AMI на каждую версию (совет: используйте Packer чтобы собирасть AMI). Люди уже знакомы с управлением AMI и инстансами на AWS, здесь нечего особо изучать, и тут нет никакого подвоха. В результате развертывание получается преотличное и полностью автоматизированное. Автомасштабируемые группы года на три опередили экосистему Докера.


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


CoreOS


Важно: Docker and CoreOS созданы различными компаниями, это нужно учитывать.


Чтобы еще раз пнуть Докер, он зависит от кучи новых внутренних подсистем. Классический дистрибутив не может обновлять их вне выпуска мажорных релизов, даже если бы очень хотел.


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


Цель: проверить стабильность экосистемы CoreOS.


Во всеобщей схеме всего, возможно отделить сервера для запуска контейнеров (на CoreOS) от обычных серверов (на Debian). Не предполагается, что контейнеры должны знать (или беспокоиться) о том, на какой операционной системе они выполняются.


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


Цель: исследовать разворачивание CoreOS в целом.


Kubernetes


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


Проблема с Докером в том, что он ничего из этого не делает. Это просто тупая контейнерная система. Она имеет все недостатки контейнеров без каких-либо преимуществ.


Сейчас не существует ни одной хорошей, проверенной в бою, готовой для продакшена системы оркестрации.


  • Mesos не предназначен для Docker
  • Docker Swarm не заслуживает доверия
  • Nomad умеет только самые простые фичи
  • Kubernetes новый и экспериментальный

Kubernetes — единственный из этих проектов, предназначенный для решения сложных проблем с контейнерами. У него есть ресурсы, которых нет ни у кого больше (например, Google имеет долгую историю использования контейнеров на больших масштабах, они имеют гугол денег и других ресурсов в собственном пользовании, и они знают, как писать работающий софт).


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


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


Вопрос не в том, стоит ли внедрять Kubernetes. Вопрос в том, когда это делать?


Задача: продолжать наблюдать за Kubernetes.


Заметка: Kubernetes требует для своего запуска докер. Он будет подвержен всем проблемам докера. (Например, не пытайтесь запустить Kubernetes ни на чем, кроме CoreOS).


Google Cloud: Google Container Engine


Как мы говорили раньше, не существует никакой известной стабильной комбинации: операционная система + дистрибутив + версия докера, поэтому не существует стабильной экосистемы для запуска на ней Kubernetes. Это — проблема.


Но существует потенциальный вокрэраунд: Google Container Engine. Он хостится на Kubernetes (и Docker) как сервис, часть Google Cloud.


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


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


Цель: перейти на Google Cloud, начиная с филиалов, не привязанных к AWS. Игнорирвать оставшуюся часть перечисленных здесь задач, т.к. они становятся нерелевантными.


Google Container Engine: еще одна причина, почему Google Cloud — это будущее, и AWS — это прошлое (в т.ч. на 33% более дешевые инстансы со в 3 раза большей скоростью и IOPS в среднем).


Disclaimer (прочитайте, прежде чем комментировать!)


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


Честно сказать, у нас были ожидания выше среднего, и мы воспринимаем проблемы с продакшеном довольно (слишком?) серьезно.


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


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


В любом случае, чтобы ни случилось в прошлом — прошлое уже в прошлом. Наиболее важная часть — план на будущее. Это то, что вам точно нужно знать, если собираетесь внедрять Докер (или использовать Амазон вместо этого).

Метки:
Поделиться публикацией
Комментарии 166
  • –13
    О чём статья то? Ну кроме «мы попытались но не взлетели»
    У меня конечно не супер прод., но и сервисы различные и БД вполне живут в докер и ни разу не испытывал проблем.

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

    Сорри, не заметил что перевод, но мнение не меняет этот факт :)
    • +16
      Чтобы не писать бесполезные комментарии, читайте статьи полностью.
      • –8

        Прочитал полностью. Не знаю, зачем. Читается как обычная чернуха-заказуха. Очень похоже по звучанию на микрософтовские Гет Зе Врактс. Претензии заключаются в том, что Docker нет ещё 5 лет (через 5 лет напишут: "Да он древний как мамонт!") и сложно настраивать (Нет кнопочки "Пыщь! Готово")

        • +21
          Спокойно, выдохните :-)
          Если все будут только рассказывать мимимишные истории как всё круто, не случится никакого прогресса.

          Автор ругается в первую очередь на баги. В багтрекере их 2596 незакрытых.
          Посмотреть можно здесь: https://github.com/moby/moby/issues
          После прочтения статьи, я на полчаса забурился в багтрекер, там попадаются очень интересные экземпляры.
          Например вот этот: https://github.com/moby/moby/issues/20997 появился в результате рейса между libnetwork и командой. Но его давно починили. А вот этот еще не починили: https://github.com/moby/moby/issues/27381.
          • –9
            Если полагаться на количество открытых тикетов, то надо бы упомянуть и про закрытые — их 13656.
            • +16
              Шестнадцать тысяч багов за два года.

              Шестнадцать.
              Тысяч.
              Багов.
              В.
              Релизах.

              Вы действительно считаете это нормальным? Они вообще тестируют билды перед выпуском новой версии?
              • +2
                Да хоть капсом хоть прописью — GH не умеет объединять issues; пользователи вольны запускать в контейнерах всякое говно (по типу оракловской JVM), видят разные проблемы по разному и не могут отделить проблемы «своего» софта от проблем ядра или докера; в свежих процах тоже баги бывают, которые выглядат вообще адово (у самих на свежем железе с докером — хехе — черт знает что творилось пока дебиановский мэйллист не прочитали и микрокод не проадейтили).

                Поэтому этот номер какбы вообще ниачем.
                • +1
                  Oracle JVM тут причем? Отлично работает, а главное — выполняет то, что должна выполнять и не ломает обратной совместимости.
                  • 0
                    2015-12-23 10:12 — «Internal team reported that physical memory and CPU do not reflect Docker resource limits. This should be fixed in 9 and back ported to 8.»
                    Фиксы прибыли в январе 2017 :D
                    • +1
                      Свою главную задачу hotspot выполняет на ура, а то, что там какая-то проблема совместимости с докером — проблема докера.
                      • 0

                        JVM уже умеет в cgroups? Docker делает изоляцию и лимитирование ресурсов через cgroups и namespaces (тут только изоляция). Для cgroups нужна поддержка, потому что иначе софт не видит лимиты, установленные cgroups, но ядро их форсит (free в контейнере, например).


                        Так вот, в JVM добавили эту поддержку или нет? Если нет, то это проблема JVM и отсутствия поддержки ядерных механизмов изоляции :)

                        • 0
                          Вот именно, докеру нужно изолировать, как это сделать — проблема докера. А то, что в JVM добавят поддержку — это доброй воли жест.
                          • 0
                            Изолировать нужно не докеру — докер просто инструмент. Изоляция нужна пользователю JVM. Поддержка пользователей для разработчиков JVM — жест доброй воли?
                            • 0
                              А JVM не инструмент?
                              • –2
                                Конечно, тоже инструмент. Я только говорю о то что проблемы поддержки это проблемы людей, а не JVM или docker или OC на которой они работают… Перекладывать проблемы на софт — странный способ ухода от решения.
                              • +4

                                С изолированием докер как раз справляется. А вот JVM в изолированном окружении, насколько я понял ситуацию, работает как-то неправильно.

                                • +2

                                  Нет-нет, вы тут путаете один момент: cgroups — ядерный механизм, который работает.


                                  То что JVM его не поддерживает проблема исключительно JVM, потому что если JVM попытается сожрать больше памяти чем позволяет cgroup, то апп вылетит в трубу — именно так оно и работало в Java 8, и это неоднократно поднималось на SO.

                • +5
                  Что такое? Раскритиковали ваш любимый докер?

                  Как бы это и мой любимый докер, только после этой статьи мы его в лайве использовать не будем, хотя подумывали. По вполне объективным причинам, описанным в статье.
                  • –12

                    Где? Где в статье объективные причины? Не вижу, процитируйте, пожалуйста, хотя бы одну. Я вижу только пачку натужно выдуманных придирок. Не все хотят пользоваться облаками Амазона и Гугла, а все остальные придирки одинаково применимы к любой сложной программе.

                    • –15

                      Что, других аргументов, кроме минусов в карму, нет? Тролотьё тупое.

                      • +8

                        А за этот каммент я вам минус в карму ткнул. Чтоб потом вопросов "за что?!" не возникало.

                      • +1

                        Мне хватает багов в драйверах ФС, фокусов с поломкой реп и неполных реализаций API.


                        Запустите-ка через API контейнер так же как это делается через CLI с опцией --init. Про AUFS я уже писал.

                • +14

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


                  И это при том что у нас всего 3 докеризованных приложения.

                  • +1

                    Так это тогда похоже баг cgroups в ядре linux, а не doker-а.

                    • +2

                      Это был баг AUFS, из-за древности ядра overlay2 недоступен, а с другими драйверами dockerd тупо не заводится.


                      После обнов он какбы починился, теперь вместо зависания контейнера, и dockerd вслед за ним, контейнер становится "Dead" и никак не удаляется, но это лечится рестартом dockerd.

                  • –3
                    а что в карму так слабо насерили? Слабаки :D
                  • 0
                    Время видимо совсем поздно или я не очень понял, а для каких целей они начали его собственно использовать, какие задачи они хотели решить docker'om или просто они пошли на волне хайпа, а их софт оказался не готов ни к микросервисам ни к докеру ни к нагрузкам, как они вообще тогда тестировали все это.
                    • +11
                      Судя по заметке, с точки зрения описания он им всем подошел. Так подошел, что они даже и сейчас следят за обновлениями и не выкидывают. Не понравились им баги и отношение разработчиков. Баги начались на обновлениях и других разных местах, которые на нагрузочное просто так не покажет. Да и нагрузки тогда были другие. Отношение разработчиков вообще вещь нестабильная — вон захотел CEO докера взять и название поменять, взял и поменял, ночью без объявления войны :-)
                      • +1
                        Насколько я понял, им не понравилась скорость смены технологий и то, что перед прекращением разработки технологии последняя не работала без проблем.
                    • +5
                      Согласен частично со статьей, замечал как бд удалялась, хотя был создан volumes. Да и Mysql каким-то чудом вылазил из контейнера и его проц был запущен на внешней среде.
                      • 0
                        Пардо, но вот вылез мускул на хост из cgroups — это докер виноват чтоли?
                      • +7
                        Короче. Докер НЕ ДОЛЖЕН ЗАПУСКАТЬ базы данных в продакшене, by design.

                        более 100 с чем то серверов(изолированных друг от друга), всё в продакшене, есть очень нагруженные узлы (4 сервера в кластере), ну так 600 млн. записей в базу в сутки, записи — строки(в среднем 200-300 символов), всё работает через докер. Я не знаю, что у вас там, может железо.
                        • +16
                          Можете поделиться магической комбинацией версии дистрибутива, ядра и докера? Отправим гуманитарной помощью автору статьи. На Хакерньюзе так вообще ChromeOS советуют :)
                          • +7
                            На Хакерньюзе так вообще ChromeOS советуют :)

                            Ничего смешного, кстати. Именно её Google Cloud Platform предлагает для создания хостов под докер (update: точнее под контейнеры).


                            Container-Optimized OS 57-9202.74.0 stable
                            Kernel: ChromiumOS-4.4.4 Kubernetes: 1.5.4 Docker: 1.11.2
                            • 0
                              Извините, могу писать один раз в сутки.
                              Конфигурация обычная.
                              Ubuntu 14.04.5 LTS
                              (GNU/Linux 4.4.0-31-generic x86_64)
                              lxc-docker-1.9.0, Docker version 1.9.1
                              от 128 RAM до 512 на основном узле
                            • +8
                              есть очень нагруженные узлы (4 сервера в кластере), ну так 600 млн. записей в базу в сутки, записи — строки(в среднем 200-300 символов)

                              TPS = 600000000/(246060) = 6944
                              Transaction size = .25 KB (или больше если юникод)
                              Speed = 6944*.25 = 1736 KB/s = 13888 Kb/s


                              Т.е. получилось, что поток на докер у вас что-то около 13 Mb/s (если у вас юникод строки то в 1-6 раз больше в зависимости от языка) в чистых данных. Если вы все написали аккуратно, то протокольная добавка (общение клиента с базой) увеличит эту цифру раза в два-три. Этого просто недостаточно, чтоб увидеть какие эффекты возникают в сетевой подситстеме под нагрузкой. А то что в docker все очень специфично с точки зрения сети автор прав на 100%.

                              • –1

                                Да и диск такой нагрузкой не продавить толком.

                            • +13

                              Всё — правда. Чувствуется, что выстрадано — прошли по ВСЕМ косякам. Но:


                              1. История неуспеха — одна, а историй успеха — больше.
                              2. Чуть-чуть устарело (улучшения улучшаются).
                              3. Мы (коммьюнити) продолжаем есть кактус.
                              4. Они (те, кто описан) — продолжают есть.

                              Так что, я бы расширил вывод:
                              Пользуйтесь, но помните что БЫВАЛО и так.

                              • +8
                                История неуспеха — одна, а историй успеха — больше.

                                Многие никогда не поделятся своей историей неуспеха. По различным соображениям.
                                И, по большому счёту, у этих ребят скорее история успеха — они работают, и инструмент у них тоже, худо-бедно, но работает.
                                • 0
                                  Я бы еще расширил вывод. Пользуйтесь, но смотрите и на альтернативы. Существует НЕ ТОЛЬКО ДОКЕР. С LXC, например, не было бы проблем с aufs (поскольку он не используется), но были бы проблемы с оркестрацией (поскольку ее бы пришлось реализовывать самостоятельно).
                                  • 0
                                    Ну без оркестрации, инфраструктуры вокруг контейнера — это не альтернатива. Я бы скорее сказал например про rkt, который сам поддерживает докер-образы (образа?), а его поддерживает, например, kubernetes, насколько я помню.
                                • +14
                                  ого, как такое в топ прошло?

                                  [sarcasm] Критика докера же запрещена, а еретиков всегда сливают? [/sarcasm]

                                  а если серьёзно, docker — чудесный инструмент, но стоит 2596 раз подумать, прежде чем тащить его в прод, да ещё и в такой области как финансы (число неслучайное, это количество issues открытых на данный момент, и большинство из них — баги)

                                  и да, проекту help всегда wanted по починке этого кошмара
                                  • +1
                                    Не смотря на то что статья вызвала негатив, и я в целом желаю докеру добра (да-да, я из тех про кого сарказм) — у докера есть серьёзные проблемы, которые сами разработчики решать не хотят, а PR — не принимают. Для примера — проблема с раздуванием образа из-за необходимости в chmod скопированных файлов.
                                    • 0

                                      Я правильно понимаю, что и в 2017 эта проблема все ещё есть?

                                      • +2
                                        К сожалению — да. Эта и кучка других проблем которые я встречаю ещё на самом старте, в самом начале использования докера. И основная проблема в первую очередь в том что никто из разработчиков не хочет это всё решать, даже при уже предложенных PR (впрочем я уже написал коммент на эту тему выше ...). Радует что докер выдал пинка всей этой индустрии, печалит что похоже докеру прийдётся умереть, освободить место для более открытых к изменениям технологий…
                                        • 0

                                          В целом многие родовые проблемы всё же решаются. Из последнего — multi-target например.

                                          • 0
                                            Те проблемы с которыми я сталкиваюсь висят на гитхабе с датами типа 2014 года… мультитаргет — хорошо что он есть, но мне лично он не нужен.
                                            • 0

                                              multi-target (пускай и в несколько иной формулировке) тоже так висел.

                                  • +2

                                    Как человек, очень далекий от всего веба, спрошу:


                                    1. Сейчас докер production ready?
                                    2. Они его использовали/используют, героически ужёвывая кактус, или они его выкинули и пользуются чем-то другим, что решает их проблему?
                                    3. Зачем, вот зачем писать свою собственную ФС?!
                                  • +6
                                    Прям как про опыт внедрения OpenStack в нашей компании написано. Тоже не взлетело (выкинули после года использования), породив бурю отрицательных эмоций. Все лень статью про это написать.
                                    • 0
                                      Ну что же вы, мы тут как раз на OpenStack смотрели, думали, искали за и против. Возможно ваша статья была бы полезной если бы мы решили все же его взять )
                                      • +1
                                        Если у вас небольшая/средняя инсталляция и нужны KVM/VMWare, рекомендую рассмотреть OpenNebula.
                                      • +6
                                        Поддерживаю, наберитесь сил и напишите статью, пожалуйста.
                                        • 0
                                          Да, очень интересно. Хотя-бы в личку если можно, основные косяки, если на статью времени нет.
                                          • +2
                                            А на что перешли, если не секрет?
                                            • 0
                                              Дружище соберитесь! Как раз смотрим на OpenStack т.к. напрягает юзание на прямую vsphere от VMware

                                              ПЛЮСУЮ К НАПИСАНИЮ СТАТЬИ.
                                            • +1

                                              В свое время из-за overlayfs пришлось вручную собирать в контейнере coreutils, ибо tail -f тупо не работал на том дистрибутиве, который был в контейнере. Тот ещё кактус.

                                              • +5

                                                Надо Умпутуну в radio-t накинуть. :) У него же как раз финансовая сфера, миллионы транзакций и долларов, сервера на Amazon и Docker в production.

                                                • 0
                                                  Ты его знаешь? Накинь :) Иначе как-то некрасиво, если я буду со своими переводами к уважаемым сэрам лезть каждый раз
                                                  • 0
                                                    В темах слушателей уже висит)
                                                    • +1
                                                      Статья от ноября прошлого года, её там обсудили уже и не раз.
                                                      • 0

                                                        Ссылки не подкинете?

                                                        • +1
                                                          https://radio-t.com/p/2016/11/05/podcast-520/
                                                          После этого пару раз статью вспоминали в следующих выпусках, но тут уж сорян, найти не могу.
                                                          • 0
                                                            После статьи напрягся, переслушал подкаст — расслабился, вообщем все в порядке, едем дальше.
                                                • +2
                                                  Используем в проде на 40 серверов, примерно по 20-30 контейнеров на сервер — полет нормальный. CentOS 7 если что. На Debian тоже были такие себе ощущения от докера, мог валиться без видимых причин. Ну и по опыту есть несколько простых правил, с которыми огребать проблем будете меньше:

                                                  1. отказывайтесь от privileged режима
                                                  2. уменьшайте количество слоев в конечных образах
                                                  3. не пилите докер там, где это не нужно
                                                  • +3
                                                    Н нас тут централизация/докеризация всего и вся идёт полным ходом уже больше года.
                                                    Закуплен гигантский хост на Амазоне, в него воткнут докер, на котором крутятся около 1000 контейнеров.
                                                    ПРОД
                                                    В специальном Skype канале «Central Outages» постоянная движуха — самое частое сообщение: docker daemon not responding, please restart it.
                                                    Из моего личного опыта — докер действительно хорош, если не перебарщивать с количеством контейнеров на хосте. Пока их до сотни — нормальный сервер справляется с этим зоопарком хорошо. Потом надо быть уже сильно храбрым.
                                                    Наши опсы — самые храбрые в мире :)
                                                    • 0
                                                      Мне интересно, какой план придумали ваши девопсы, когда у Амазона деградирует железо, и надо перезапустить инстанс.
                                                      Держать второй про запас как-то накладно, и EBS надо перетыкать
                                                      • 0
                                                        Вот это — любопытный вопрос :)
                                                        Задам-ка я его нашим опсам ;)
                                                  • +3

                                                    Статья отличная, но не нетленка.


                                                    Значительная часть проблем была исправлена, добавили docker system prune/docker image prune, перешли на новый релизный цикл, перешли на overlay и так далее.

                                                    • 0
                                                      Ну, еще бы GC registry сделали без полной остановки, были бы вообще молодцы :)
                                                      • +1

                                                        Вроде сторонние регистры в это умеют.

                                                        • 0
                                                          Спасибо, погуглю
                                                          • +1

                                                            Например, Gitlab Container Registry.

                                                            • 0

                                                              Ну и Artifactory конечно.

                                                              • 0
                                                                Мне пока https://www.sonatype.com/docker понравился, там и pypi есть и maven и все задаром :)
                                                                А за Артефактори платить 25к в год жаба того, поддушивает.
                                                                • 0

                                                                  И работает? Задаром-то?


                                                                  Кстати, откуда 25к взялось, когда $85 в месяц?

                                                                  • 0
                                                                    Ок, цены разные:
                                                                    https://www.jfrog.com/pricing/
                                                                    С поддержкой S3 — только enterprise
                                                                    https://www.jfrog.com/artifactory/versions/
                                                                    • 0

                                                                      Как у бесплатного Нексуса с поддержкой S3?
                                                                      Что вы подразумеваете под "поддержкой S3", кстати? Что ваши артифакты лежат на Amazon S3? Потому что если да, то вам SaaS на AWS за $98 в месяц, и в догонку вопрос "а зачем вам S3", если не секрет?

                                                                      • 0
                                                                        Прошу прощение за запутывание — конечно же s3 нам необходим для других артефактов, а не для слоев образов докера.
                                                                        Поддержка s3 — это значит, что софтина может через s3api положить в бакет объект и взять оттуда же. Да, наши артефакты(не docker) лежат на s3.
                                                                        Что есть SaaS на AWS? Понял, это Artifactory.
                                                                        Вы знаете, интересный вопрос, можно даже попробовать посмотреть в эту сторону :)
                                                                        А S3 нам нужен был(и, наверное, есть), потому что это самый дешевый и безгеморный способ отказоустойчивого хранения блобов.
                                                                        • 0

                                                                          Ну так я вам предлагаю другой безгеморойный способ хранить бинарники, зачем вам теперь S3?

                                                      • –1
                                                        Linux 4.x: ядро официально прекратило поддержку докера
                                                        Хотелось бы увидеть официальное заявления разработчиков ядра или сразу пишите, что Вы про AUFS.

                                                        Следующий момент:
                                                        Поэтому чуваки из докера написали новую файловую систему, называющуюся overlay.

                                                        Опять же, где это написано? Разарабы оверлея — ребята из SUSE и на прямую к докеру не относится.

                                                        После такого — дальше читать не тянет, но дочитаю, еще чет интересное найду)
                                                        • +6
                                                          По поводу hash mismatch. Это официальный факап команды админов. Причём не докера, а автора. Потому что все пользователи чужих мирроров делятся на две группы: те, кто уже имеют локальные зеркала и тех, кто пока не понимает зачем это.

                                                          aptly — наше всё.
                                                          • 0
                                                            Если б aptly умел еще и RPM, тогда было бы «наше все»*2…
                                                            • 0
                                                              У rpm должны же быть свои методы поддерживать консистентные мирроры. Хотя в статье обсуждался debian, так что aptly.
                                                              • 0
                                                                Да вот хотелось бы one tool to rule them all.
                                                                Ибо aptly удобно не только для тупого зеркалирования(с чем бы, наверное, и rsync справился), но и для полного менеджмента собственными репами.

                                                                Кстати, в aptly исью присутствует:
                                                                https://github.com/smira/aptly/issues/39
                                                                • +2

                                                                  Есть one tool to rule them all. Умеет и rpm, и debian и сами Докер образы, и еще много много всего.

                                                                  • +1
                                                                    но за 25к в год.
                                                                    Да, забыл добавить, что должно быть или недорого или бесплатно :)
                                                        • –4
                                                          Статья выглядит так, будто чуваки сделали ВСЕ что нельзя делать с докером, кубером и так далее (ставить приложения со стейтом в докер, ставить туда же в докер базы данных, запускать меньше трех инстансов), набрали много боли, а потом написали гневную статью и в выводах переписали общеизвестные истины, написанные чуть ли не в каждой статье про оркестрацию микросервисов
                                                          • +8
                                                            При этом аргументы про «третью версию файловой системы» вы пропускаете.
                                                            • –5
                                                              так я и проблемы не вижу

                                                              обновляются без обратной совместимости?
                                                              ну ок, мы деплоимся по blue-green, уже было такое что так обновлялись месяц с версии еластика 1.4 на 5.2.2 — на таком скачке совместимость вобще раздолбана ко всем чертям
                                                              естественно из-за blue-green нашли проблему раньше чем положили рабочую систему, доработались, поставились
                                                              whats problem?

                                                              баги из-за которого рестартует хост?
                                                              ну ладно, у меня приложуха живет не меньше ( иногда и больше) чем в трех контейнерах на трех разных хостах в трех разным датацентрах, имея в пуле еще десяток свободных машинок, один инстанс переедет, потом вернется ( когда и тот упадет )
                                                              неприятно, ссыплет в логи, но фатальным трудно назвать
                                                              опять же, это должно пройти через blue-green

                                                              почему чувакам было так больно от рестарта машинки?
                                                              отчего они вобще ходили по хостам и руками поднимали контейнеры?
                                                              непонятно

                                                              еще раз, все это пилится не для того чтобы гарантировать аптаймы по несколько лет — все это пилится для того чтобы легко переживать частые падения
                                                              • +5
                                                                Расскажите, где в референсной модели приложений на докере хранятся персистентные данные.

                                                                Спасибо.
                                                                • 0
                                                                  Тут:
                                                                  https://docs.docker.com/engine/extend/plugins_volume/
                                                                  https://docs.docker.com/engine/extend/legacy_plugins/
                                                                  https://store.docker.com/search?category=volume&q=&type=plugin
                                                                  • +7
                                                                    Просто скажите, что «docker не умеет персистентность». Надо сказать, что вслед за персистентностью возникает вопрос консистентности и доступности. Если у меня внешнее блочное хранилище, то будет ли моя СУБД высокодоступной, если я её (при использовании внешнего хранилища) засуну в докер?

                                                                    Интуиция мне говорит, что нет.
                                                                    • 0
                                                                      Может я чего-то не понимаю, но чем Вам не нравится использование внешних вольюмов?
                                                                      • +7
                                                                        То, что не существует референсной работающей реализации докера.

                                                                        Есть реализация, которая полагается на «большого дядю, который делает надёжно». Референсной реализации «надёжно» — нет. Потому что если мы притащим любые средства распределённого хранения данных (ceph, gluster, etc), как тут же окажется, что нужны нормальные средства администрирования и деплоя, и что без них ничего «надёжно» не живёт. А когда появляются нормальные средства деплоя, то оказывается, что модель докера — унылое говно и с реальностью боевого продакшена не соотносится.
                                                                        • 0
                                                                          ОК, с этим согласен.
                                                                          Вообще говоря, может в некотором будущем ситуация изменится и вслед за CNI, получим и CSI:
                                                                          https://mesosphere.com/blog/2017/03/30/csi-towards-universal-storage-interface-for-containers/
                                                                          Но пока имеем то, что имеем — и на этом спасибо :)
                                                                          • +1
                                                                            Между N и S есть гигантская разница. Network is stateless. Следующий IP-пакет (в худших случаях — следующая сессия) может обрабатываться где угодно кем угодно). У S — если пользователь пришёл за Новый Документ (14).doc, то он хочет его получить именно оттуда, где он есть, а не от любого другого storage, который готов сохранить его файлы.

                                                                            Data have gravity © netapp. Я их не люблю, но слова золотые.
                                                                            • 0
                                                                              Я вообще не об этом говорил, а говорил я(цитируя вашими же словами) о:
                                                                              Референсной реализации «надёжно»
                                                                              .
                                                                              Потому что сейчас вообще нет даже близко стандартизированного интерфейса для хранилищ. От чтения того, как это реализовано у Mesos, Kubernetes и иже с ними, становится плохо, но приходится этим пользоваться(ну или как минимум переложить администрирование самого хранилища на вендора(AWS, GCE...))
                                                                              • 0
                                                                                Помимо стандартов доступа есть ещё проблема хранения. Если кто-то решит проблему хранения достаточно хорошо, то он победит. Проблема (в смысле не «вычислительная», а «общечеловеческая») состоит в том, что попытка решить проблему (вычислительную) каждый раз накладывает нечеловеческие ограничения на инфраструктуру и выкатывает огромные требования по постоянному maintananace. Я не видел ни одной распределённой системы хранения данных, которую бы можно было «просто запустить и использовать». Всегда миллиард ручек у которых есть 100 комбинаций положений когда оно работает, и 1000000000100 положений при которых оно либо не работает, либо «будут большие проблемы в будущем».
                                                                                • 0
                                                                                  Мы сейчас говорим о стандартизации API хранилища в контейнерах или нет?
                                                                                  Про проблемы, плюсы и минусы распределенных систем хранения известно всем давно и какого-либо универсального решения не предвидится ввиду физических ограничений.

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

                                                                                  Для чего допустим мне нужна стандартизация — подключить любую POSIX-совместимую систему к контейнеру.
                                                                                  К примеру, довольно стабильную MooseFS.
                                                                                  Сейчас же, как вы правильно заметили, мы зависим от плагинов, предоставляемых вендором — каждый со своей реализацией, что есть несомненно бардак.
                                                                      • 0
                                                                        Тык я про это в комменте ниже и говорю)
                                                                        не кладите данные в контейнер
                                                                        целевое место зависит от данных, которые вы хотите юзать
                                                                        если речь про настройки приложений — юзайте config-server (consul, spring-cloud-config-server и иже с ними)
                                                                        если речь про СУБД — выносите на отдельные хосты, вне экосистемы докера
                                                                        и это же написано в оригинальном комменте — не надо засовывать их в докер или даже на хосты с докером
                                                                        а приложениями только стучите в них
                                                                        • +2
                                                                          Так вот, можно не увидеть референсную модель приложения на докере с персистентными данными?

                                                                          Пусть во внешней СУБД. Но как именно? Потому что пока это выгляди так: мы будем играться в куличики в песочнице, а проблемы будут решать взрослые. Как — не знаю, но куличики у нас прикольные, всем срочно лепить куличики.
                                                                  • +4
                                                                    > отчего они вобще ходили по хостам и руками поднимали контейнеры?

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

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

                                                                      Жесть какая, хоть бы унылый swarm заюзали
                                                                      • +3

                                                                        Если у вас в HFT финансах что-то легло, то вас "автоподнятие" не спасет. Даже может хуже сделать.

                                                                • +1
                                                                  А в чем проблема ставить в докер приложения со стейтом при условии использования external volumes?
                                                                  • +2
                                                                    ну во первых
                                                                    1) Проблема в том что никто не использует докер просто так
                                                                    всего его оркестрируют ( это mesos, kuber и прочие) — а это предполагает что ваши приложения готовы уехать с одного хост на другой в любой момент времени и как угодно часто, просто потому что оркестратор так решил ( перераспределяет ли ресурсы, упал ли хост — не важно), соответственно все ваши данные должны скидываться не просто на диск, а в какое-то облачное/сетевое хранилище, что добавляет немало проблем.
                                                                    2) стейт это вобще говоря не только про данные на харде, но и про данные в оперативке, которые бывают почему-то важны

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

                                                                    Миграцию контейнера со стейтом по слухам дорабатывают в докере — к примеру вот https://criu.org/Docker
                                                                    This feature is available in the experimental mode for Docker

                                                                    где-то видел и интервью автора по поводу работы с командой докера в этом направлении
                                                                    • +1
                                                                      т.е для java-ee серверов докер не подходит?
                                                                      • 0
                                                                        Давайте дождемся ответов на мои вопросы ниже, может чего нового узнаем :)
                                                                        • 0

                                                                          В общем случае — нет.

                                                                          • +3

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


                                                                            Если ваш сервер ближе к традиционному серверу РСУБД чем к некэширующему прокси, горизонтально не масштабируется или масштабируется плохо, скорость работы с диском критична, да она ещё и монопольной должна быть, для системы важно чтобы держались длительные соединения между сервером и клиентом, да ещё по статическим IP, рестарт сервера надолго парализует эффективную работу клиентов даже если несколько инстансов сервера ещё нормально работают, сильная привязка к версиям ядра ОС и т. д., и т. п., то даже при идеальной работе докера, без всех этих ужасных багов из поста (я не сталкивался с крашами и зависаниями, но СУБД у нас пока даже не планируется докеризировать даже в тест-среде, только в дев, максимум в проде редис как хранилище сессий и кэша) то, вполне вероятно, основной плюс докера для вас будет лишь обеспечение единого (почти) рантайма в дев- тест- и прод-средах, которое может оказаться проще и дешевле достигнуть другими средствами типа виртуалок в дев- и тест-средах и параметризуемых средств управления хостами типа ansible, chef и т. п., а докером много времени потратите на "прибивание" сервера к хостам, дискам и прочей "стабильности".


                                                                            Если же лишь малая часть вашей системы имеет подобные требования и(или) особенности (как вариант — такую часть легко выделить из имеющегося монолита или классического SOAP), а остальное устойчиво к многочисленным рестартам, клиенты к инстансам особо не привязаны (по типу http keep alive — соединение держим чтобы не тратить время даже на дешевый хэндшейк, но ничего страшного если порвётся и новое установится с другим инстансом), кэширование в памяти бесплатный бонус, диск особо не нужен, нужен лишь в ридонли и(или) нормально работает с сетевой шарой будь то nfs/smb или какие-то облачные хранилища, то подумать о переводе остальных частей имеет смысл, если сейчас испытываете заметные трудности с обеспечением идентичности разных сред или горизонтальным масштабированием.

                                                                            • +1
                                                                              Спасибо за большой ответ…
                                                                              Если я правильно понял — в докере по хорошему не должна быть завязка на состояние (базу, кеши, сессии, ...) — тогда и проблем не будет.
                                                                              Видимо java-ee принятно считать монструозным интерпрайсом, хотя это давно не так.
                                                                              • 0

                                                                                Скажем так, обычно без особых проблем докеризируются сервисы, которые в "bare metal" мире легко переживают смерть сервера и разворачивание его с нуля (не с бэкапов) на новом. То есть сервисы даунтайм которых может и останавливает работу пользователей, но новый поднятый инстанс позволяет продолжить без необходимости кучу действий по восстановлению информации с умершего сервера или бэкапов производить

                                                                          • +2
                                                                            1) Проблема в том что никто не использует докер просто так
                                                                            всего его оркестрируют ( это mesos, kuber и прочие) — а это предполагает что ваши приложения готовы уехать с одного хост на другой в любой момент времени и как угодно часто, просто потому что оркестратор так решил ( перераспределяет ли ресурсы, упал ли хост — не важно), соответственно все ваши данные должны скидываться не просто на диск, а в какое-то облачное/сетевое хранилище, что добавляет немало проблем.

                                                                            1)Названные вами системы оркестрации поддерживают в так называемых pod-ах локальные разделы с привязкой к хосту(чем это отличается от запуска приложений на этом же хосте без контейнеров я слабо понимаю — при падении/уничтожении хоста теряются данные для обоих случаев)
                                                                            Так что как в этом случае поможет использование приложения вне контейнера?

                                                                            2) Названные вами системы оркестрации поддерживают remote volumes, т.е. «облачное/сетевое хранилище» — как раз тут все будет стандартизировано.

                                                                            2) стейт это вобще говоря не только про данные на харде, но и про данные в оперативке, которые бывают почему-то важны
                                                                            любят некоторые запихивать j2ee сервак в докер — это вот к примеру точно антипаттерн засовывания толстого приложения со своим рабочим стейтом, которое не может просто так взять и быстро переехать с хоста на хост

                                                                            Может я чего-то не понимаю, но как это относится к контейнерам? Как мы можем сохранить стейт в ОЗУ при краше приложения вне контейнера? Как поможет незасовывание J2EE сервака в контейнер переехать с хоста на хост?
                                                                            • +2
                                                                              Речь не про то что незасовывание в контейнер спасет стейт или поможет перезжать
                                                                              Естественно, при краше вы потеряете данные в обоих случаях

                                                                              Речь идет о том что не надо пытаться использовать технологии, которые заранее говорят, что они не сильно заботятся о времени и стабильности жизни контейнера ( и даже более того, убивают и поднимают новые, когда захотят), для случаев, когда вам нужно долгое время жизни и стабильность контейнера
                                                                              • –1
                                                                                pod'ы привязываются к хосту временно и могут быть убиты в любой момент и запущены на другой ноде
                                                                                • 0
                                                                                  Kubernetes сильно не колупал, а в Mesos если к поду прикрепить Persistent volume, то никуда он с хоста не убежит — только если Слейв пропадет.
                                                                          • +2
                                                                            Где написано, что всего этого нельзя на сайте докера?
                                                                          • –9
                                                                            Во-первых, смысл контейнеров — в экономии ресурсов, благодаря запуску множества контейнеров на одном (большом) хосте.


                                                                            facepalm
                                                                            в 2017 году, имея все средства оркестрации и масштабирования, мы пытаемся запускать все на одной большой машинке
                                                                            лучше было только когда в одном банке на собесе рассказывали, как они через sh запускают руками jar с сервисом на embedded jetty, руками прописывают его хост и порт в балансер, а потом говорят про это «У нас микросервисы, все стильно модно молодежно»
                                                                            • +7

                                                                              Автор не писал что он пытается запускать все на одной большой машинке. Он писал, что можно запустить много контейнеров на одной машинке. Вы понимаете разницу между словами "все" и "много"?

                                                                            • 0
                                                                              А как насчёт dc/os? У меня знакомый использует — всё нарадоваться не может.
                                                                              • +1
                                                                                Будет радоваться, пока что-то не сломается и он увидит внутрянку этой солянки.
                                                                                Тогда огорчится и перейдет на чистый Mesos+Marathon
                                                                                • 0

                                                                                  Ну он работал в гугле на поддержке аналогичных технологий длительное время, сейчас в другой конторе на поддержке dc/os, думаю он всё таки знает что внутри.

                                                                                  • 0
                                                                                    Ну, я не являюсь последователем Захера-Мазоха, поэтому предпочел не сталкиваться с ними — начиная от пакетирования и конфигурацией, заканчивая blackbox методами установки.
                                                                                  • 0
                                                                                    Можно для меня уточнить, что не так там внутри? На мои взгляд сам dcos уже довольно стабильный продукт
                                                                                    • +1
                                                                                      On-Cloud установка предоставляется в виде проприетарных образов виртуальных машин.

                                                                                      On-premises установка в виде 500Mb(в 2016 году) бинарного блоба.
                                                                                      Разворачивается все в /opt в виде каши пакетов, при чем система пакетирования используется проприетарная, все это дело перемешано спагетти из симлинков.

                                                                                      Таким образом, при необходимости что-то продебажить или подтюнить, у нас есть 2 пути:
                                                                                      1) Заняться мазохизмом и копать /opt/dcos
                                                                                      2) Купить сапорт Mesosphere

                                                                                      Я пошел третьим путем и использую чистый Mesos + фреймфорки.

                                                                                      А с виду да, гламурненько, красивенько.
                                                                                      • 0
                                                                                        1. Ну не вижу проблем в большом файле установки, ведь он содержит все необходимое
                                                                                        2. Если речь о этих пакетах, то не знаю насколько это можно назвать проприетарным https://github.com/dcos/dcos/tree/master/pkgpanda
                                                                                        3. Да, у dcos несомненно есть проблемы, но в целом продукт на мои взгляд не плохой(даже лучше k8s)
                                                                                        • 0
                                                                                          1) А я предпочитаю стандартные пакеты(которые легко пересобираются самому в случае нужды) ОС, а не блобы.
                                                                                          2) Я копал это в конце 2015 года — первый коммит этого репозитория — апрель 16-го.
                                                                                          3) dcos — это переусложненный внутри и упрощенный снаружи лишний уровень абстракции — не всем он нужен.
                                                                                • +5
                                                                                  Всё прямо как у нас!
                                                                                  • 0
                                                                                    Т.е. если использовать «голый» docker (core) то все стабильно?
                                                                                    А что не так с DigitalOcean?