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

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

04.07.2017 21:05

olegchir 162 30800 Источник

Примечание переводчика: в предыдущей статье о подготовке к девопс-конференциям, 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 минут. Это сильно нагнетает градус драматизма, и боль от прочитанного.

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

Поделиться с друзьями

-->

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

POS_troi
05.07.2017 00:47
#10298092
-13
О чём статья то? Ну кроме «мы попытались но не взлетели»
У меня конечно не супер прод., но и сервисы различные и БД вполне живут в докер и ни разу не испытывал проблем.

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

Сорри, не заметил что перевод, но мнение не меняет этот факт :)
1. izzholtik
  05.07.2017 00:55
  #10298098
  +16
  Чтобы не писать бесполезные комментарии, читайте статьи полностью.
  1. Barafu
    05.07.2017 01:04
    #10298104
    -8
    Прочитал полностью. Не знаю, зачем. Читается как обычная чернуха-заказуха. Очень похоже по звучанию на микрософтовские Гет Зе Врактс. Претензии заключаются в том, что Docker нет ещё 5 лет (через 5 лет напишут: "Да он древний как мамонт!") и сложно настраивать (Нет кнопочки "Пыщь! Готово")
    
    olegchir
    05.07.2017 01:41
    #10298144
    +21
    Спокойно, выдохните :-)
    Если все будут только рассказывать мимимишные истории как всё круто, не случится никакого прогресса.
    
    Автор ругается в первую очередь на баги. В багтрекере их 2596 незакрытых.
    Посмотреть можно здесь: https://github.com/moby/moby/issues
    После прочтения статьи, я на полчаса забурился в багтрекер, там попадаются очень интересные экземпляры.
    Например вот этот: https://github.com/moby/moby/issues/20997 появился в результате рейса между libnetwork и командой. Но его давно починили. А вот этот еще не починили: https://github.com/moby/moby/issues/27381.
    
    fiveze
    05.07.2017 15:25
    #10299196
    -9
    Если полагаться на количество открытых тикетов, то надо бы упомянуть и про закрытые — их 13656.
    
    Xandrmoro
    05.07.2017 17:49
    #10299508
    +16
    Шестнадцать тысяч багов за два года.
    
    Шестнадцать.
    Тысяч.
    Багов.
    В.
    Релизах.
    
    Вы действительно считаете это нормальным? Они вообще тестируют билды перед выпуском новой версии?
    
    rustler2000
    05.07.2017 19:41
    #10299662
    +2
    Да хоть капсом хоть прописью — GH не умеет объединять issues; пользователи вольны запускать в контейнерах всякое говно (по типу оракловской JVM), видят разные проблемы по разному и не могут отделить проблемы «своего» софта от проблем ядра или докера; в свежих процах тоже баги бывают, которые выглядат вообще адово (у самих на свежем железе с докером — хехе — черт знает что творилось пока дебиановский мэйллист не прочитали и микрокод не проадейтили).
    
    Поэтому этот номер какбы вообще ниачем.
    
    ExplosiveZ
    06.07.2017 12:04
    #10300408
    +1
    Oracle JVM тут причем? Отлично работает, а главное — выполняет то, что должна выполнять и не ломает обратной совместимости.
    
    rustler2000
    06.07.2017 15:57
    #10300786
    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
    
    ExplosiveZ
    06.07.2017 16:17
    #10300836
    +1
    Свою главную задачу hotspot выполняет на ура, а то, что там какая-то проблема совместимости с докером — проблема докера.
    
    Gendalph
    07.07.2017 08:20
    #10301584
    JVM уже умеет в cgroups? Docker делает изоляцию и лимитирование ресурсов через cgroups и namespaces (тут только изоляция). Для cgroups нужна поддержка, потому что иначе софт не видит лимиты, установленные cgroups, но ядро их форсит (free в контейнере, например).
    
    Так вот, в JVM добавили эту поддержку или нет? Если нет, то это проблема JVM и отсутствия поддержки ядерных механизмов изоляции :)
    
    ExplosiveZ
    07.07.2017 11:20
    #10301916
    Вот именно, докеру нужно изолировать, как это сделать — проблема докера. А то, что в JVM добавят поддержку — это доброй воли жест.
    
    Caravus
    07.07.2017 11:29
    #10301938
    Изолировать нужно не докеру — докер просто инструмент. Изоляция нужна пользователю JVM. Поддержка пользователей для разработчиков JVM — жест доброй воли?
    
    ExplosiveZ
    07.07.2017 12:11
    #10302110
    А JVM не инструмент?
    
    Caravus
    07.07.2017 12:14
    #10302128
    -2
    Конечно, тоже инструмент. Я только говорю о то что проблемы поддержки это проблемы людей, а не JVM или docker или OC на которой они работают… Перекладывать проблемы на софт — странный способ ухода от решения.
    
    Borz
    09.07.2017 13:04
    #10304028
    +1
    https://habrahabr.ru/company/ruvds/blog/324756/
    
    mayorovp
    07.07.2017 12:00
    #10302082
    +4
    С изолированием докер как раз справляется. А вот JVM в изолированном окружении, насколько я понял ситуацию, работает как-то неправильно.
    
    Gendalph
    07.07.2017 16:23
    #10302644
    +2
    Нет-нет, вы тут путаете один момент: cgroups — ядерный механизм, который работает.
    
    То что JVM его не поддерживает проблема исключительно JVM, потому что если JVM попытается сожрать больше памяти чем позволяет cgroup, то апп вылетит в трубу — именно так оно и работало в Java 8, и это неоднократно поднималось на SO.
    
    Aleks_ja
    05.07.2017 19:04
    #10299620
    +5
    Что такое? Раскритиковали ваш любимый докер?
    
    Как бы это и мой любимый докер, только после этой статьи мы его в лайве использовать не будем, хотя подумывали. По вполне объективным причинам, описанным в статье.
    
    Barafu
    05.07.2017 21:19
    #10299770
    -12
    Где? Где в статье объективные причины? Не вижу, процитируйте, пожалуйста, хотя бы одну. Я вижу только пачку натужно выдуманных придирок. Не все хотят пользоваться облаками Амазона и Гугла, а все остальные придирки одинаково применимы к любой сложной программе.
    
    Barafu
    05.07.2017 23:23
    #10299904
    -15
    Что, других аргументов, кроме минусов в карму, нет? Тролотьё тупое.
    
    Gendalph
    05.07.2017 23:53
    #10299926
    +8
    А за этот каммент я вам минус в карму ткнул. Чтоб потом вопросов "за что?!" не возникало.
    
    Gendalph
    05.07.2017 23:52
    #10299924
    +1
    Мне хватает багов в драйверах ФС, фокусов с поломкой реп и неполных реализаций API.
    
    Запустите-ка через API контейнер так же как это делается через CLI с опцией --init. Про AUFS я уже писал.
1. Gendalph
  05.07.2017 12:57
  #10298808
  +14
  Ну, если баг, приводящий к зависанию dockerd, который исправляется только ребутом всего сервера — не критичный, то я не знаю.
  
  И это при том что у нас всего 3 докеризованных приложения.
  1. madkite
    05.07.2017 17:58
    #10299520
    +1
    Так это тогда похоже баг cgroups в ядре linux, а не doker-а.
    
    Gendalph
    05.07.2017 23:45
    #10299920
    +2
    Это был баг AUFS, из-за древности ядра overlay2 недоступен, а с другими драйверами dockerd тупо не заводится.
    
    После обнов он какбы починился, теперь вместо зависания контейнера, и dockerd вслед за ним, контейнер становится "Dead" и никак не удаляется, но это лечится рестартом dockerd.
1. POS_troi
  06.07.2017 16:32
  #10300860
  -3
  а что в карму так слабо насерили? Слабаки :D

D1abloRUS
05.07.2017 00:48
#10298094
Время видимо совсем поздно или я не очень понял, а для каких целей они начали его собственно использовать, какие задачи они хотели решить docker'om или просто они пошли на волне хайпа, а их софт оказался не готов ни к микросервисам ни к докеру ни к нагрузкам, как они вообще тогда тестировали все это.
1. olegchir
  05.07.2017 01:04
  #10298106
  +11
  Судя по заметке, с точки зрения описания он им всем подошел. Так подошел, что они даже и сейчас следят за обновлениями и не выкидывают. Не понравились им баги и отношение разработчиков. Баги начались на обновлениях и других разных местах, которые на нагрузочное просто так не покажет. Да и нагрузки тогда были другие. Отношение разработчиков вообще вещь нестабильная — вон захотел CEO докера взять и название поменять, взял и поменял, ночью без объявления войны :-)
  1. NetBUG
    06.07.2017 11:09
    #10300318
    +1
    Насколько я понял, им не понравилась скорость смены технологий и то, что перед прекращением разработки технологии последняя не работала без проблем.

powernic
05.07.2017 01:13
#10298122
+5
Согласен частично со статьей, замечал как бд удалялась, хотя был создан volumes. Да и Mysql каким-то чудом вылазил из контейнера и его проц был запущен на внешней среде.
1. rustler2000
  05.07.2017 19:48
  #10299668
  Пардо, но вот вылез мускул на хост из cgroups — это докер виноват чтоли?

AndrewFoma
05.07.2017 01:28
#10298132
+7
Короче. Докер НЕ ДОЛЖЕН ЗАПУСКАТЬ базы данных в продакшене, by design.

более 100 с чем то серверов(изолированных друг от друга), всё в продакшене, есть очень нагруженные узлы (4 сервера в кластере), ну так 600 млн. записей в базу в сутки, записи — строки(в среднем 200-300 символов), всё работает через докер. Я не знаю, что у вас там, может железо.
1. olegchir
  05.07.2017 01:45
  #10298146
  +16
  Можете поделиться магической комбинацией версии дистрибутива, ядра и докера? Отправим гуманитарной помощью автору статьи. На Хакерньюзе так вообще ChromeOS советуют :)
  1. acmnu
    05.07.2017 10:40
    #10298498
    +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
  1. AndrewFoma
    06.07.2017 12:42
    #10300472
    Извините, могу писать один раз в сутки.
    Конфигурация обычная.
    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 на основном узле
1. acmnu
  05.07.2017 10:38
  #10298494
  +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. acmnu
    05.07.2017 10:48
    #10298526
    -1
    Да и диск такой нагрузкой не продавить толком.

neenik
05.07.2017 01:50
#10298154
+13
Всё — правда. Чувствуется, что выстрадано — прошли по ВСЕМ косякам. Но:
1. История неуспеха — одна, а историй успеха — больше.
2. Чуть-чуть устарело (улучшения улучшаются).
3. Мы (коммьюнити) продолжаем есть кактус.
4. Они (те, кто описан) — продолжают есть.
Так что, я бы расширил вывод:
Пользуйтесь, но помните что БЫВАЛО и так.
1. khanid
  05.07.2017 20:47
  #10299720
  +8
  История неуспеха — одна, а историй успеха — больше.
  
  Многие никогда не поделятся своей историей неуспеха. По различным соображениям.
  И, по большому счёту, у этих ребят скорее история успеха — они работают, и инструмент у них тоже, худо-бедно, но работает.
1. AEP
  07.07.2017 09:53
  #10301738
  Я бы еще расширил вывод. Пользуйтесь, но смотрите и на альтернативы. Существует НЕ ТОЛЬКО ДОКЕР. С LXC, например, не было бы проблем с aufs (поскольку он не используется), но были бы проблемы с оркестрацией (поскольку ее бы пришлось реализовывать самостоятельно).
  1. Caravus
    07.07.2017 10:48
    #10301858
    Ну без оркестрации, инфраструктуры вокруг контейнера — это не альтернатива. Я бы скорее сказал например про rkt, который сам поддерживает докер-образы (образа?), а его поддерживает, например, kubernetes, насколько я помню.

mrobespierre
05.07.2017 02:05
#10298172
+14
ого, как такое в топ прошло?

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

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

и да, проекту help всегда wanted по починке этого кошмара
1. Caravus
  05.07.2017 12:05
  #10298696
  +1
  Не смотря на то что статья вызвала негатив, и я в целом желаю докеру добра (да-да, я из тех про кого сарказм) — у докера есть серьёзные проблемы, которые сами разработчики решать не хотят, а PR — не принимают. Для примера — проблема с раздуванием образа из-за необходимости в chmod скопированных файлов.
  1. questor
    06.07.2017 11:33
    #10300362
    Я правильно понимаю, что и в 2017 эта проблема все ещё есть?
    
    Caravus
    06.07.2017 11:52
    #10300388
    +2
    К сожалению — да. Эта и кучка других проблем которые я встречаю ещё на самом старте, в самом начале использования докера. И основная проблема в первую очередь в том что никто из разработчиков не хочет это всё решать, даже при уже предложенных PR (впрочем я уже написал коммент на эту тему выше ...). Радует что докер выдал пинка всей этой индустрии, печалит что похоже докеру прийдётся умереть, освободить место для более открытых к изменениям технологий…
    
    VolCh
    06.07.2017 13:18
    #10300542
    В целом многие родовые проблемы всё же решаются. Из последнего — multi-target например.
    
    Caravus
    06.07.2017 13:20
    #10300552
    Те проблемы с которыми я сталкиваюсь висят на гитхабе с датами типа 2014 года… мультитаргет — хорошо что он есть, но мне лично он не нужен.
    
    VolCh
    06.07.2017 13:36
    #10300584
    multi-target (пускай и в несколько иной формулировке) тоже так висел.

Gryphon88
05.07.2017 03:56
#10298192
+2
Как человек, очень далекий от всего веба, спрошу:
1. Сейчас докер production ready?
2. Они его использовали/используют, героически ужёвывая кактус, или они его выкинули и пользуются чем-то другим, что решает их проблему?
3. Зачем, вот зачем писать свою собственную ФС?!
1. shurup
  05.07.2017 05:03
  #10298204
  +1
  1. «Какие известные компании используют Docker в production и для чего?»
1. netch80
  07.07.2017 09:10
  #10301644
  > Зачем, вот зачем писать свою собственную ФС?!
  
  Ну есть задача, надо её реализовать, выхлоп очевиден. Считают, что по силам написать FS. Почему нет? Может, и доведут до ума.
  Я не понял, почему aufs так пострадала — но VFS в Linux это вообще очень странный предмет. ;(

divanikus
05.07.2017 05:28
#10298212
+6
Прям как про опыт внедрения OpenStack в нашей компании написано. Тоже не взлетело (выкинули после года использования), породив бурю отрицательных эмоций. Все лень статью про это написать.
1. erlioniel
  05.07.2017 11:53
  #10298680
  Ну что же вы, мы тут как раз на OpenStack смотрели, думали, искали за и против. Возможно ваша статья была бы полезной если бы мы решили все же его взять )
  1. divanikus
    05.07.2017 13:53
    #10298958
    +1
    Если у вас небольшая/средняя инсталляция и нужны KVM/VMWare, рекомендую рассмотреть OpenNebula.
1. Caravus
  05.07.2017 12:06
  #10298698
  +6
  Поддерживаю, наберитесь сил и напишите статью, пожалуйста.
1. citius
  05.07.2017 13:30
  #10298884
  Да, очень интересно. Хотя-бы в личку если можно, основные косяки, если на статью времени нет.
1. g0dlike
  05.07.2017 13:46
  #10298938
  +2
  А на что перешли, если не секрет?
1. konstantine_tomsk
  06.07.2017 18:40
  #10301076
  Дружище соберитесь! Как раз смотрим на OpenStack т.к. напрягает юзание на прямую vsphere от VMware
  
  ПЛЮСУЮ К НАПИСАНИЮ СТАТЬИ.

D3fl4t3
05.07.2017 07:28
#10298264
+1
В свое время из-за overlayfs пришлось вручную собирать в контейнере coreutils, ибо tail -f тупо не работал на том дистрибутиве, который был в контейнере. Тот ещё кактус.

DexterHD
05.07.2017 07:48
#10298274
+5
Надо Умпутуну в radio-t накинуть. :) У него же как раз финансовая сфера, миллионы транзакций и долларов, сервера на Amazon и Docker в production.
1. olegchir
  05.07.2017 09:13
  #10298336
  Ты его знаешь? Накинь :) Иначе как-то некрасиво, если я буду со своими переводами к уважаемым сэрам лезть каждый раз
  1. Shatun
    05.07.2017 09:58
    #10298414
    В темах слушателей уже висит)
    
    kvasdopil
    05.07.2017 13:12
    #10298838
    +1
    Статья от ноября прошлого года, её там обсудили уже и не раз.
    
    questor
    06.07.2017 11:36
    #10300370
    Ссылки не подкинете?
    
    kvasdopil
    06.07.2017 12:04
    #10300406
    +1
    https://radio-t.com/p/2016/11/05/podcast-520/
    После этого пару раз статью вспоминали в следующих выпусках, но тут уж сорян, найти не могу.
    
    lega
    07.07.2017 12:14
    #10302126
    После статьи напрягся, переслушал подкаст — расслабился, вообщем все в порядке, едем дальше.

nikolayvaganov
05.07.2017 08:37
#10298296
+2
Используем в проде на 40 серверов, примерно по 20-30 контейнеров на сервер — полет нормальный. CentOS 7 если что. На Debian тоже были такие себе ощущения от докера, мог валиться без видимых причин. Ну и по опыту есть несколько простых правил, с которыми огребать проблем будете меньше:

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

SmartMaxx
05.07.2017 09:12
#10298334
+3
Н нас тут централизация/докеризация всего и вся идёт полным ходом уже больше года.
Закуплен гигантский хост на Амазоне, в него воткнут докер, на котором крутятся около 1000 контейнеров.
ПРОД
В специальном Skype канале «Central Outages» постоянная движуха — самое частое сообщение: docker daemon not responding, please restart it.
Из моего личного опыта — докер действительно хорош, если не перебарщивать с количеством контейнеров на хосте. Пока их до сотни — нормальный сервер справляется с этим зоопарком хорошо. Потом надо быть уже сильно храбрым.
Наши опсы — самые храбрые в мире :)
1. Nikon_NLG
  08.07.2017 00:25
  #10303158
  Мне интересно, какой план придумали ваши девопсы, когда у Амазона деградирует железо, и надо перезапустить инстанс.
  Держать второй про запас как-то накладно, и EBS надо перетыкать
  1. SmartMaxx
    08.07.2017 10:48
    #10303320
    Вот это — любопытный вопрос :)
    Задам-ка я его нашим опсам ;)

SirEdvin
05.07.2017 09:18
#10298342
+3
Статья отличная, но не нетленка.

Значительная часть проблем была исправлена, добавили docker system prune/docker image prune, перешли на новый релизный цикл, перешли на overlay и так далее.
1. g0dlike
  05.07.2017 13:48
  #10298944
  Ну, еще бы GC registry сделали без полной остановки, были бы вообще молодцы :)
  1. SirEdvin
    05.07.2017 13:49
    #10298950
    +1
    Вроде сторонние регистры в это умеют.
    
    g0dlike
    05.07.2017 14:08
    #10299004
    Спасибо, погуглю
    
    neenik
    05.07.2017 15:56
    #10299246
    +1
    Например, Gitlab Container Registry.
    
    jbaruch
    06.07.2017 03:51
    #10300046
    Ну и Artifactory конечно.
    
    g0dlike
    06.07.2017 10:39
    #10300264
    Мне пока https://www.sonatype.com/docker понравился, там и pypi есть и maven и все задаром :)
    А за Артефактори платить 25к в год жаба того, поддушивает.
    
    jbaruch
    06.07.2017 20:47
    #10301210
    И работает? Задаром-то?
    
    Кстати, откуда 25к взялось, когда $85 в месяц?
    
    g0dlike
    07.07.2017 09:57
    #10301754
    Ок, цены разные:
    https://www.jfrog.com/pricing/
    С поддержкой S3 — только enterprise
    https://www.jfrog.com/artifactory/versions/
    
    jbaruch
    07.07.2017 17:23
    #10302760
    Как у бесплатного Нексуса с поддержкой S3?
    Что вы подразумеваете под "поддержкой S3", кстати? Что ваши артифакты лежат на Amazon S3? Потому что если да, то вам SaaS на AWS за $98 в месяц, и в догонку вопрос "а зачем вам S3", если не секрет?
    
    g0dlike
    07.07.2017 22:21
    #10303062
    Прошу прощение за запутывание — конечно же s3 нам необходим для других артефактов, а не для слоев образов докера.
    Поддержка s3 — это значит, что софтина может через s3api положить в бакет объект и взять оттуда же. Да, наши артефакты(не docker) лежат на s3.
    ~~Что есть SaaS на AWS?~~ Понял, это Artifactory.
    Вы знаете, интересный вопрос, можно даже попробовать посмотреть в эту сторону :)
    А S3 нам нужен был(и, наверное, есть), потому что это самый дешевый и безгеморный способ отказоустойчивого хранения блобов.
    
    jbaruch
    07.07.2017 22:29
    #10303076
    Ну так я вам предлагаю другой безгеморойный способ хранить бинарники, зачем вам теперь S3?

o_serega
05.07.2017 09:18
#10298344
-1
Linux 4.x: ядро официально прекратило поддержку докера
Хотелось бы увидеть официальное заявления разработчиков ядра или сразу пишите, что Вы про AUFS.

Следующий момент:

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

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

После такого — дальше читать не тянет, но дочитаю, еще чет интересное найду)

amarao
05.07.2017 10:45
#10298514
+6
По поводу hash mismatch. Это официальный факап команды админов. Причём не докера, а автора. Потому что все пользователи чужих мирроров делятся на две группы: те, кто уже имеют локальные зеркала и тех, кто пока не понимает зачем это.

aptly — наше всё.
1. g0dlike
  05.07.2017 12:24
  #10298746
  Если б aptly умел еще и RPM, тогда было бы «наше все»*2…
  1. amarao
    05.07.2017 13:00
    #10298816
    У rpm должны же быть свои методы поддерживать консистентные мирроры. Хотя в статье обсуждался debian, так что aptly.
    
    g0dlike
    05.07.2017 13:07
    #10298834
    Да вот хотелось бы one tool to rule them all.
    Ибо aptly удобно не только для тупого зеркалирования(с чем бы, наверное, и rsync справился), но и для полного менеджмента собственными репами.
    
    Кстати, в aptly исью присутствует:
    https://github.com/smira/aptly/issues/39
    
    jbaruch
    06.07.2017 03:52
    #10300048
    +2
    Есть one tool to rule them all. Умеет и rpm, и debian и сами Докер образы, и еще много много всего.
    
    g0dlike
    06.07.2017 10:40
    #10300266
    +1
    но за 25к в год.
    Да, забыл добавить, что должно быть или недорого или бесплатно :)
    
    jbaruch
    06.07.2017 20:48
    #10301212
    -1
    $85 в месяц дорого?
    
    g0dlike
    07.07.2017 09:59
    #10301760
    ЗА 85 долларов не хватает фич, и где вы видели 85 в месяц?
    Минимальная цена — 246 в месяц
    
    jbaruch
    07.07.2017 17:20
    #10302754
    Каких фич не хватает за $85?
    И видел вот прямо на официальном сайте, в разделе pricing.
    
    g0dlike
    07.07.2017 22:23
    #10303064
    +1
    Спасибо, посмотрю на SaaS @ AWS

stCarolas
05.07.2017 11:31
#10298628
-4
Статья выглядит так, будто чуваки сделали ВСЕ что нельзя делать с докером, кубером и так далее (ставить приложения со стейтом в докер, ставить туда же в докер базы данных, запускать меньше трех инстансов), набрали много боли, а потом написали гневную статью и в выводах переписали общеизвестные истины, написанные чуть ли не в каждой статье про оркестрацию микросервисов
1. amarao
  05.07.2017 13:01
  #10298822
  +8
  При этом аргументы про «третью версию файловой системы» вы пропускаете.
  1. stCarolas
    05.07.2017 14:39
    #10299094
    -5
    так я и проблемы не вижу
    
    обновляются без обратной совместимости?
    ну ок, мы деплоимся по blue-green, уже было такое что так обновлялись месяц с версии еластика 1.4 на 5.2.2 — на таком скачке совместимость вобще раздолбана ко всем чертям
    естественно из-за blue-green нашли проблему раньше чем положили рабочую систему, доработались, поставились
    whats problem?
    
    баги из-за которого рестартует хост?
    ну ладно, у меня приложуха живет не меньше ( иногда и больше) чем в трех контейнерах на трех разных хостах в трех разным датацентрах, имея в пуле еще десяток свободных машинок, один инстанс переедет, потом вернется ( когда и тот упадет )
    неприятно, ссыплет в логи, но фатальным трудно назвать
    опять же, это должно пройти через blue-green
    
    почему чувакам было так больно от рестарта машинки?
    отчего они вобще ходили по хостам и руками поднимали контейнеры?
    непонятно
    
    еще раз, все это пилится не для того чтобы гарантировать аптаймы по несколько лет — все это пилится для того чтобы легко переживать частые падения
    
    amarao
    05.07.2017 14:55
    #10299122
    +5
    Расскажите, где в референсной модели приложений на докере хранятся персистентные данные.
    
    Спасибо.
    
    g0dlike
    05.07.2017 15:02
    #10299140
    Тут:
    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
    
    amarao
    05.07.2017 15:32
    #10299202
    +7
    Просто скажите, что «docker не умеет персистентность». Надо сказать, что вслед за персистентностью возникает вопрос консистентности и доступности. Если у меня внешнее блочное хранилище, то будет ли моя СУБД высокодоступной, если я её (при использовании внешнего хранилища) засуну в докер?
    
    Интуиция мне говорит, что нет.
    
    g0dlike
    05.07.2017 15:40
    #10299212
    Может я чего-то не понимаю, но чем Вам не нравится использование внешних вольюмов?
    
    amarao
    05.07.2017 16:08
    #10299268
    +7
    То, что не существует референсной работающей реализации докера.
    
    Есть реализация, которая полагается на «большого дядю, который делает надёжно». Референсной реализации «надёжно» — нет. Потому что если мы притащим любые средства распределённого хранения данных (ceph, gluster, etc), как тут же окажется, что нужны нормальные средства администрирования и деплоя, и что без них ничего «надёжно» не живёт. А когда появляются нормальные средства деплоя, то оказывается, что модель докера — унылое говно и с реальностью боевого продакшена не соотносится.
    
    g0dlike
    05.07.2017 16:20
    #10299314
    ОК, с этим согласен.
    Вообще говоря, может в некотором будущем ситуация изменится и вслед за CNI, получим и CSI:
    https://mesosphere.com/blog/2017/03/30/csi-towards-universal-storage-interface-for-containers/
    Но пока имеем то, что имеем — и на этом спасибо :)
    
    amarao
    07.07.2017 18:07
    #10302824
    +1
    Между N и S есть гигантская разница. Network is stateless. Следующий IP-пакет (в худших случаях — следующая сессия) может обрабатываться где угодно кем угодно). У S — если пользователь пришёл за Новый Документ (14).doc, то он хочет его получить именно оттуда, где он есть, а не от любого другого storage, который готов сохранить его файлы.
    
    Data have gravity © netapp. Я их не люблю, но слова золотые.
    
    g0dlike
    07.07.2017 22:28
    #10303072
    Я вообще не об этом говорил, а говорил я(цитируя вашими же словами) о:
    
    Референсной реализации «надёжно»
    .
    Потому что сейчас вообще нет даже близко стандартизированного интерфейса для хранилищ. От чтения того, как это реализовано у Mesos, Kubernetes и иже с ними, становится плохо, но приходится этим пользоваться(ну или как минимум переложить администрирование самого хранилища на вендора(AWS, GCE...))
    
    amarao
    08.07.2017 19:25
    #10303660
    Помимо стандартов доступа есть ещё проблема хранения. Если кто-то решит проблему хранения достаточно хорошо, то он победит. Проблема (в смысле не «вычислительная», а «общечеловеческая») состоит в том, что попытка решить проблему (вычислительную) каждый раз накладывает нечеловеческие ограничения на инфраструктуру и выкатывает огромные требования по постоянному maintananace. Я не видел ни одной распределённой системы хранения данных, которую бы можно было «просто запустить и использовать». Всегда миллиард ручек у которых есть 100 комбинаций положений когда оно работает, и 1000000000¹⁰⁰ положений при которых оно либо не работает, либо «будут большие проблемы в будущем».
    
    g0dlike
    09.07.2017 12:12
    #10303978
    Мы сейчас говорим о стандартизации API хранилища в контейнерах или нет?
    Про проблемы, плюсы и минусы распределенных систем хранения известно всем давно и какого-либо универсального решения не предвидится ввиду физических ограничений.
    
    Поэтому сейчас важно именно реализовать стандарт доступа, которого нет.
    
    Для чего допустим мне нужна стандартизация — подключить любую POSIX-совместимую систему к контейнеру.
    К примеру, довольно стабильную MooseFS.
    Сейчас же, как вы правильно заметили, мы зависим от плагинов, предоставляемых вендором — каждый со своей реализацией, что есть несомненно бардак.
    
    stCarolas
    05.07.2017 16:04
    #10299254
    Тык я про это в комменте ниже и говорю)
    не кладите данные в контейнер
    целевое место зависит от данных, которые вы хотите юзать
    если речь про настройки приложений — юзайте config-server (consul, spring-cloud-config-server и иже с ними)
    если речь про СУБД — выносите на отдельные хосты, вне экосистемы докера
    и это же написано в оригинальном комменте — не надо засовывать их в докер или даже на хосты с докером
    а приложениями только стучите в них
    
    amarao
    05.07.2017 16:09
    #10299270
    +2
    Так вот, можно не увидеть референсную модель приложения на докере с персистентными данными?
    
    Пусть во внешней СУБД. Но как именно? Потому что пока это выгляди так: мы будем играться в куличики в песочнице, а проблемы будут решать взрослые. Как — не знаю, но куличики у нас прикольные, всем срочно лепить куличики.
    
    olegchir
    05.07.2017 15:08
    #10299156
    +4
    > отчего они вобще ходили по хостам и руками поднимали контейнеры?
    
    он написал там — у них нету автоматического оркестратора с автопереездами, автоподнятиями и прочей автопочинкой. Наверное, смотрят на мониторинге алерты, и руками поднимают что упало. Как собственно, и большая часть мира, которая до высоких технологий еще не добралась
    
    полное падение сервиса для них смертельно, потому что это не просто какие-то транзакции, а высокочастотный трейдинг. Сервис поднимется через секунду, но через секунду уже будет ненужно
    
    g0dlike
    05.07.2017 15:13
    #10299170
    -1
    у них нету автоматического оркестратора
    
    Жесть какая, хоть бы унылый swarm заюзали
    
    Regis
    05.07.2017 18:28
    #10299572
    +3
    Если у вас в HFT финансах что-то легло, то вас "автоподнятие" не спасет. Даже может хуже сделать.
1. g0dlike
  05.07.2017 13:50
  #10298952
  +1
  А в чем проблема ставить в докер приложения со стейтом при условии использования external volumes?
  1. stCarolas
    05.07.2017 14:23
    #10299052
    +2
    ну во первых
    1) Проблема в том что никто не использует докер просто так
    всего его оркестрируют ( это mesos, kuber и прочие) — а это предполагает что ваши приложения готовы уехать с одного хост на другой в любой момент времени и как угодно часто, просто потому что оркестратор так решил ( перераспределяет ли ресурсы, упал ли хост — не важно), соответственно все ваши данные должны скидываться не просто на диск, а в какое-то облачное/сетевое хранилище, что добавляет немало проблем.
    2) стейт это вобще говоря не только про данные на харде, но и про данные в оперативке, которые бывают почему-то важны
    
    любят некоторые запихивать j2ee сервак в докер — это вот к примеру точно антипаттерн засовывания толстого приложения со своим рабочим стейтом, которое не может просто так взять и быстро переехать с хоста на хост
    
    Миграцию контейнера со стейтом по слухам дорабатывают в докере — к примеру вот https://criu.org/Docker
    
    This feature is available in the experimental mode for Docker
    
    где-то видел и интервью автора по поводу работы с командой докера в этом направлении
    
    sapl
    05.07.2017 14:56
    #10299126
    +1
    т.е для java-ee серверов докер не подходит?
    
    g0dlike
    05.07.2017 14:59
    #10299134
    Давайте дождемся ответов на мои вопросы ниже, может чего нового узнаем :)
    
    Regis
    05.07.2017 18:32
    #10299578
    В общем случае — нет.
    
    VolCh
    06.07.2017 08:37
    #10300110
    +3
    Скорее зависит не от того на чём написан сервер, а от того как он написан и чего ожидают клиенты. Если для клиента критично поддерживать постоянное соединение с сервером, архитектура системы не поддерживает распределения атомарных запросов по нескольким инстансам сервера, а связывает их в длительные сеансы взаимодействия со сложным хендшейком (или просто эффективно сервер работает только после долгого прогрева внутреннего кэша), то чтобы достоинства докера хорошо себя показали придётся много дополнительной работы делать.
    
    Если ваш сервер ближе к традиционному серверу РСУБД чем к некэширующему прокси, горизонтально не масштабируется или масштабируется плохо, скорость работы с диском критична, да она ещё и монопольной должна быть, для системы важно чтобы держались длительные соединения между сервером и клиентом, да ещё по статическим IP, рестарт сервера надолго парализует эффективную работу клиентов даже если несколько инстансов сервера ещё нормально работают, сильная привязка к версиям ядра ОС и т. д., и т. п., то даже при идеальной работе докера, без всех этих ужасных багов из поста (я не сталкивался с крашами и зависаниями, но СУБД у нас пока даже не планируется докеризировать даже в тест-среде, только в дев, максимум в проде редис как хранилище сессий и кэша) то, вполне вероятно, основной плюс докера для вас будет лишь обеспечение единого (почти) рантайма в дев- тест- и прод-средах, которое может оказаться проще и дешевле достигнуть другими средствами типа виртуалок в дев- и тест-средах и параметризуемых средств управления хостами типа ansible, chef и т. п., а докером много времени потратите на "прибивание" сервера к хостам, дискам и прочей "стабильности".
    
    Если же лишь малая часть вашей системы имеет подобные требования и(или) особенности (как вариант — такую часть легко выделить из имеющегося монолита или классического SOAP), а остальное устойчиво к многочисленным рестартам, клиенты к инстансам особо не привязаны (по типу http keep alive — соединение держим чтобы не тратить время даже на дешевый хэндшейк, но ничего страшного если порвётся и новое установится с другим инстансом), кэширование в памяти бесплатный бонус, диск особо не нужен, нужен лишь в ридонли и(или) нормально работает с сетевой шарой будь то nfs/smb или какие-то облачные хранилища, то подумать о переводе остальных частей имеет смысл, если сейчас испытываете заметные трудности с обеспечением идентичности разных сред или горизонтальным масштабированием.
    
    sapl
    06.07.2017 10:20
    #10300214
    +1
    Спасибо за большой ответ…
    Если я правильно понял — в докере по хорошему не должна быть завязка на состояние (базу, кеши, сессии, ...) — тогда и проблем не будет.
    Видимо java-ee принятно считать монструозным интерпрайсом, хотя это давно не так.
    
    VolCh
    06.07.2017 13:35
    #10300582
    Скажем так, обычно без особых проблем докеризируются сервисы, которые в "bare metal" мире легко переживают смерть сервера и разворачивание его с нуля (не с бэкапов) на новом. То есть сервисы даунтайм которых может и останавливает работу пользователей, но новый поднятый инстанс позволяет продолжить без необходимости кучу действий по восстановлению информации с умершего сервера или бэкапов производить
    
    g0dlike
    05.07.2017 14:59
    #10299132
    +2
    1) Проблема в том что никто не использует докер просто так
    всего его оркестрируют ( это mesos, kuber и прочие) — а это предполагает что ваши приложения готовы уехать с одного хост на другой в любой момент времени и как угодно часто, просто потому что оркестратор так решил ( перераспределяет ли ресурсы, упал ли хост — не важно), соответственно все ваши данные должны скидываться не просто на диск, а в какое-то облачное/сетевое хранилище, что добавляет немало проблем.
    
    1)Названные вами системы оркестрации поддерживают в так называемых pod-ах локальные разделы с привязкой к хосту(чем это отличается от запуска приложений на этом же хосте без контейнеров я слабо понимаю — при падении/уничтожении хоста теряются данные для обоих случаев)
    Так что как в этом случае поможет использование приложения вне контейнера?
    
    2) Названные вами системы оркестрации поддерживают remote volumes, т.е. «облачное/сетевое хранилище» — как раз тут все будет стандартизировано.
    
    2) стейт это вобще говоря не только про данные на харде, но и про данные в оперативке, которые бывают почему-то важны
    любят некоторые запихивать j2ee сервак в докер — это вот к примеру точно антипаттерн засовывания толстого приложения со своим рабочим стейтом, которое не может просто так взять и быстро переехать с хоста на хост
    
    Может я чего-то не понимаю, но как это относится к контейнерам? Как мы можем сохранить стейт в ОЗУ при краше приложения вне контейнера? Как поможет незасовывание J2EE сервака в контейнер переехать с хоста на хост?
    
    stCarolas
    05.07.2017 16:24
    #10299324
    +2
    Речь не про то что незасовывание в контейнер спасет стейт или поможет перезжать
    Естественно, при краше вы потеряете данные в обоих случаях
    
    Речь идет о том что не надо пытаться использовать технологии, которые заранее говорят, что они не сильно заботятся о времени и стабильности жизни контейнера ( и даже более того, убивают и поднимают новые, когда захотят), для случаев, когда вам нужно долгое время жизни и стабильность контейнера
    
    slayerhabr
    05.07.2017 22:43
    #10299858
    -1
    pod'ы привязываются к хосту временно и могут быть убиты в любой момент и запущены на другой ноде
    
    g0dlike
    06.07.2017 10:41
    #10300274
    Kubernetes сильно не колупал, а в Mesos если к поду прикрепить Persistent volume, то никуда он с хоста не убежит — только если Слейв пропадет.
1. VolCh
  05.07.2017 21:52
  #10299812
  +2
  Где написано, что всего этого нельзя на сайте докера?

stCarolas
05.07.2017 11:37
#10298644
-9
Во-первых, смысл контейнеров — в экономии ресурсов, благодаря запуску множества контейнеров на одном (большом) хосте.

facepalm
в 2017 году, имея все средства оркестрации и масштабирования, мы пытаемся запускать все на одной большой машинке
лучше было только когда в одном банке на собесе рассказывали, как они через sh запускают руками jar с сервисом на embedded jetty, руками прописывают его хост и порт в балансер, а потом говорят про это «У нас микросервисы, все стильно модно молодежно»
1. mayorovp
  05.07.2017 14:56
  #10299124
  +7
  Автор не писал что он пытается запускать все на одной большой машинке. Он писал, что можно запустить много контейнеров на одной машинке. Вы понимаете разницу между словами "все" и "много"?

rionnagel
05.07.2017 14:22
#10299048
А как насчёт dc/os? У меня знакомый использует — всё нарадоваться не может.
1. g0dlike
  05.07.2017 15:03
  #10299142
  +1
  Будет радоваться, пока что-то не сломается и он увидит внутрянку этой солянки.
  Тогда огорчится и перейдет на чистый Mesos+Marathon
  1. rionnagel
    05.07.2017 19:22
    #10299648
    Ну он работал в гугле на поддержке аналогичных технологий длительное время, сейчас в другой конторе на поддержке dc/os, думаю он всё таки знает что внутри.
    
    g0dlike
    05.07.2017 19:51
    #10299672
    Ну, я не являюсь последователем Захера-Мазоха, поэтому предпочел не сталкиваться с ними — начиная от пакетирования и конфигурацией, заканчивая blackbox методами установки.
  1. gurinderu
    06.07.2017 12:28
    #10300446
    Можно для меня уточнить, что не так там внутри? На мои взгляд сам dcos уже довольно стабильный продукт
    
    g0dlike
    06.07.2017 13:15
    #10300532
    +1
    On-Cloud установка предоставляется в виде проприетарных образов виртуальных машин.
    
    On-premises установка в виде 500Mb(в 2016 году) бинарного блоба.
    Разворачивается все в /opt в виде каши пакетов, при чем система пакетирования используется проприетарная, все это дело перемешано спагетти из симлинков.
    
    Таким образом, при необходимости что-то продебажить или подтюнить, у нас есть 2 пути:
    1) Заняться мазохизмом и копать /opt/dcos
    2) Купить сапорт Mesosphere
    
    Я пошел третьим путем и использую чистый Mesos + фреймфорки.
    
    А с виду да, гламурненько, красивенько.

soar
05.07.2017 16:22
#10299318
+5
Всё прямо как у нас!
1. lega
  05.07.2017 17:44
  #10299492
  Т.е. если использовать «голый» docker (core) то все стабильно?
  А что не так с DigitalOcean?
  1. soar
    05.07.2017 18:40
    #10299592
    Если говорить о Docker как об упаковщике приложений — то проблем я не нашел.
    DigitalOcean — пытаются быть крутыми, но уж очень часто у них всё работает не так, как хотелось бы. Мы держали у них серверов на $2 килобакса в месяц, пришлось переезжать.

farcaller
05.07.2017 17:24
#10299460
Заметка: Kubernetes требует для своего запуска докер. Он будет подвержен всем проблемам докера. (Например, не пытайтесь запустить Kubernetes ни на чем, кроме CoreOS).
Забавно. K8S официально поддерживается как минимум на ubuntu и centos же.
1. rustler2000
  05.07.2017 20:04
  #10299678
  ага — и rkt в конце H1 2016 года в доках у k8s упоминается уже =)

lehha
05.07.2017 22:17
#10299836
+4
Фух, меня пронесло мимо этой технологии. Я сохранил свои не седые волосы.

NLO
06.07.2017 01:57
#10299998
НЛО прилетело и опубликовало эту надпись здесь

CombatPenguin
06.07.2017 02:02
#10300004
+3
А тем временем Google и RedHat форкнули Docker: https://www.certdepot.net/death-of-docker/
1. g0dlike
  06.07.2017 10:43
  #10300278
  +2
  И Mesos от него курс держит:
  http://mesos.apache.org/documentation/latest/mesos-containerizer/
  http://mesos.apache.org/documentation/latest/container-image/

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

Вы вообще в курсе про volumes и volume drivers/plugins?
https://docs.docker.com/engine/tutorials/dockervolumes/
https://docs.docker.com/engine/extend/legacy_plugins/#volume-plugins
1. dipspb
  06.07.2017 02:49
  #10300032
  Упс… Это перевод был :) Сорри, вопрос снят
1. VolCh
  06.07.2017 08:55
  #10300122
  +1
  Наличие томов и плагинов для них не отменяет того факта, что необходимость сколь-нибудь длительного хранения состояния (и не только на диске), необходимость расшаривать данные между сервисами (банально файлопомойку между веб- и апп-сервером) значительно усложняет докеризацию сервисов. Без томов, поддерживающих разные варианты шаринга данных, докер вряд ли бы вообще взлетел, оставаясь в лучшем случае весьма специализированным средством масштабирования стейтлесс-сервисов типа некэширующих прокси или php-приложений, которые и так рождены, чтобы умереть :).
  
  Да и с ними сейчас какой особый смысл заворачивать в контейнер что-то типа MySQL или PostgreSQL, если вам нужно держать один инстанс мастера и пару слэйвов и для этого у вас три хоста, а нагрузка и(или) бюджет не позволяет держать базы на сетевых хранилищах, только на локальных дисках? максимум имеет смысл, если всё остальное (что-то типа nginx+php) прекрасно докеризируется, получаете кучу плюсов от этого и испытываете сложности со связью докеризированного и недокеризированного окружения, когда --add-host явно недостаточно.
  1. dipspb
    06.07.2017 12:24
    #10300436
    Что значит «не отменяет того факта», если тома как раз эту задачу и решают?! Мне вообще непонятно, с какого перепугу автор исходного поста принял решение персистить всё в файловую систему контейнера. Естественно, что они огребли на этом кучу проблем со временем и потом долго воевали с собственной же ошибкой.
    
    VolCh
    06.07.2017 13:42
    #10300596
    Означает, что настройка и эксплуатация системы в докере сильно осложняется как только возникает необходимость в персистентных данных, переживающих смерть контейнера, особенно если новый может быть поднят на другой ноде, да ещё если нужно обеспечить к ним доступ извне контейнера-"владельца". Докер не предлагает решений "из коробки" по организации чего-то типа распределенной файловой системы. Максимум — монтировать хост директорию на директорию контейнера без всякой синхронизации хостов друг с другом. Была бы хоть какая-то дефолтная, пускай медленная и не очень надежная было бы гораздо проще. А так на каждый чих нужно думать как лучше организовать хранение данных. При том крайне желательно глубоко разбираясь в механизмах томов.
    
    dipspb
    06.07.2017 18:57
    #10301086
    -1
    Судя по вашему ответу, я не уверен, что вы поняли разницу между томами и тем способом хранения, который описан в статье. Именно для того, чтобы быть независимыми от контейнера, чтобы разделять доступ, предоставлять доступ извне — для всего этого тома и сделаны.

caban
06.07.2017 07:07
#10300076
Меня стало интересно, а в чём плюс докера? Его использует много людей, а можно какой-то типовой сценарий, где можно понять всю его прелесть?
1. VolCh
  06.07.2017 09:35
  #10300154
  +4
  По факту, докер — удобный (ну… на любителя) интерфейс к средствам ядра (Linux прежде всего) оркестрации процессов с изоляцией их друг от друга: chroot, cgroups, вот этот вот всё… Шарится по умолчанию только ядро, для шаринга остального нужны дополнительные усилия, иногда весьма нетривиальные.
  
  Типовых сценария два, вроде как:
  
  Обеспечение идентичного (почти) окружения в разных окружениях типа дев-, тест-, CI, прод. Грубо, чтобы развернуть локально систему из десятков демонов, включая СУБД, новому разработчику на проекте нужно лишь установить докер и пару-тройку команд (включая git clone) выполнить. Разворачивание/обновление нового продакшена тоже не сильно отличается. Конкуренты тут вбокс/вмваре воркстейшн, вагрант, а также ансибль, чиф и т. п. Докер позиционируется как более дешевая (прежде всего по потребляемым ресурсам в рантайме) и гибкая (если шаринг ядра устраивает) альтернатива им.
  
  Обеспечение горизонтального масштабирования в продакшене. Оркестрирование сервисами, их обнаружение, связь между ними, регуляция количества инстансов, мониторинг, единые точки сбора логов и т. п. Тут основные конкуренты видимо системы типа вмваре нетсфера с тулингами разными, а также облачные хостинги. Плюс есть, грубо говоря, высокоуровневые обвязки для докера типа Кубернейтс от Гугла, которые эти манипуляции позволяют делать проще, используя докер как тупую систему сборки и запуска контейнеров из образов. Хотя могут и аналогичные бэкенды использовать — докер, наверное, лишь самый раскрученный из них.
  
  В целом главный плюс — написал несколько условно декларативных файлов, собрал один раз, залил в репозиторий (реестр) и запускаешь везде систему из множества демонов в любом количестве инстансов имея практически идентичные окружения, изолированные от всего остального.
  
  На моей практике больше всего усилий приходится прилагать как раз для преодоления изоляции. Типичный кейс без стандартного решения от команды докера: крутится с десяток nginx и другой десяток php-fpm в контейнерах, представляющих попарно веб-сервисы, каждый nginx думает, что он слушает 80 порт и является дефолтным сервером (без подобной конфигурации смысла в докере мало в моих кейсах), каждый отдаёт статику и "проксирует" "php" запросы на 9000 порт хоста app-fpm и нужно а) обеспечить доступ извне к каждому nginx отдельно, да ещё желательно по https и б) обеспечить шаринг между nginx и php-fpm пользовательской статики. В локальном окружении последний вопрос почти незначим, но если хочется единообразно разворачивать систему и локально и в продакшене, да ещё на нескольких нодах кластера, да с возможностью отдельно масштабировать количество процессов nginx и php-fpm — придётся попотеть.
  1. g0dlike
    06.07.2017 10:46
    #10300280
    Вообще-то Dockerfile самый что ни на есть императивный подход.
    Декларативный — это, скажем, saltstack.
    Сравните:
    
    RUN apt-get install nano
    
    nano: - pkg.installed
    
    dipspb
    06.07.2017 12:25
    #10300440
    Это уровень создания имиджа, там без императивного сложно будет. На уровне использования есть вполне декларативный docker-compose.
    
    g0dlike
    06.07.2017 13:19
    #10300548
    Ну, я думал, вы о докерфайлах и говорите :)
    
    В целом главный плюс — написал несколько условно декларативных файлов, собрал один раз, залил в репозиторий (реестр)
    
    VolCh
    06.07.2017 14:02
    #10300616
    Потому и написал "условно". Содержимое файла императивно в целом типа башскрипта, но по сути он описывает конечный образ.

truezemez
06.07.2017 08:09
#10300104
+2
Чувствую боль автора.

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

Волосы у меня начали шевелиться когда докер начал раздавать одинаковый IP-адрес нескольким контейнерам. Например, у меня 2 контейнера: public_web и private_web. Докер дал им одинаковый IP и когда я зашел на public_web, то увидел private_web — в этот момент доверие к докеру было утеряно безвозвратно.

https://github.com/moby/moby/issues/22334
https://github.com/moby/moby/issues/11199
https://github.com/moby/moby/issues/10096
https://github.com/moby/moby/issues/19086
https://github.com/moby/moby/issues/18535

ViGo5190
06.07.2017 09:47
#10300164
-3
Да, статья является хорошим жизненным уроком. И многие выводы, полученные кровью эксплуатации, являются реальностью новых технологий. Но давайте задумаемся, как бы выглядела статья в журнале от человека, который пересел с лошади на автомобиль

До машин все ездили на лошадях с повозками. Это было невероятно удобно:
- покормил и едешь дальше
- отходы сами утилизируются (а иногда их даже покупают!)
- лошадь пришла в негодность — пристрелил
- лошади сами воспроизводятся!
- для обслуживание подков есть кузнецы
- плохой кузнец — можно пристрелить
- новое поколение лошадей совместимо со старыми
А сейчас с машинами одни проблемы. Давайте разберемся.

Машины: проблемы эксплуатации
Машины: каждое новое поколение слабо совместимо со старыми

Производители машин просто издеваются над потребителями! Каждая новая версия любимой модели отличается от старой и детали не совместимы. Если вы поклонник определенной марки и модели, то вам придется смириться с тем, что через 5-10 лет и пару поколений вы не найдете запчастей на свою версию авто.

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

Машины: баги редко исправляются

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

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

Машины: огромные требование к обслуживанию

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

Бонус: отходы утилизируются сами, например: выхлопные газы сами уходят в небо..

Машины: сложности утилизации

Лошадь можно просто пристрелить. Некоторые даже едят лошадей. То есть лошадь в голодное время может прокормить хозяина! А машины что? прокормить собой не могут. Пристрелить нельзя. Просто выкинуть тоже — налог то все равно придется платить.

Бонус: можно дождаться пока машину подожгут и получить страховку(не делайте так).

Дороги
Дороги: плохая совместимость с авто

Лошадь — универсальное средство передвижение, которое может пройти везде. А вот машины, по большей части, ездят по дорогам. И хорошим дорогам. Тяжело найти дорогу, которая совместима с вашим авто. Я протестировал разные сборки дорог в России, и не нашел ни одной дороги полностью совместимой с моим авто. Всегда есть какие-то проблемы в реализации дорог: плохое покрытие, непродуманные развязки, etc.

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

Вывод: вам придется иметь несколько авто для разных типов дорог.

Дороги: скорость

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

Некоторые модели авто до сих пор не совместимы с новыми дорогами! На скорости их кидает, заносит — ужас на дороге.

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

Топливо

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

Хуже того, просто пропатчив ядро двигателя, вы не сможете добиться поддержки новых типов топлива!

Бонус: топливо постоянно дорожает, не смотря на колебания цен на нефть.

Вывод: вам придется обновлять автопарк и покупать машины с двигателями, имеющими в ядре поддержку нового топлива

Бюрократия

С лошадьми все было просто: У кого лошадь, тот и хозяин. Украл лошадь — она твоя. Никто не докажет. А сейчас: номера, свидетельства о регистрации и постановки на учет, и прочее-прочее..

И ведь каждая бумажка требует материальных вложений.

Бонус: в большинстве стран Вам придется покупать страховку, без которой — в случае аварии — будет не очень приятно.

Disclaimer

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

kursoriks
06.07.2017 16:03
#10300798
-1
Полезная статья, хороший инструмент, пошел стартовать старый добрый батник в несколько строк, на синхронизацию файлов с FTP.

konstantine_tomsk

06.07.2017 19:21

#10301112

Комментарий на habrahabr

Единственный способ очищать место — это запускать следующий хак каждый день, скорей всего по крону:
docker images -q -a | xargs --no-run-if-empty docker rmi  

Простой, без геморойный, способ это заюзать контейнер gitlab'овцев с прокинутым docker сокет который будет за тебя удалять не запущенные контейнеры и не используемые образы, как настроишь.

Но в рамках использования в ci это может оказаться не приемлемым. Допустим вы сбилдили новый docker образ, а затем, при успешном билде, вам необходимо его запушить в ваше rejestry. То в этот момент если у вас на диске критически мало места gitlab-runner-docker-cleanup может снести ваш, только что сбилденный, образ.

Поэтому лично мы делаем по другому:
1. Т.к. CI сервера создаются и управляются SaltStack'ом мы просто вешаем маяк(beacon) который в случае переполнения больше 95% раздела /var/lib/docker маякнёт об этом на salt шину событий и salt-master отреагирует на это событие кинув в pipeline той CI системы к которой подключён данный сервер таску на очистку раздела /var/lib/docker
2. docker раздел /var/lib/docker лежит на отдельном диске который, таким образом таска очистки тупо пересоздаёт с нуля файловую систему:

service docker stop && umount /var/lib/docker && mkfs.ext4 -F /dev/sdb && mount /var/lib/docker && service docker start

Это делается меньше чем за <10 секунд и не выполняет лишних(ненужных) операций чтения записи, тем самым бережёт дорогущие ssd диски.

neenik

07.07.2017 00:27

#10301424

docker system prune -a

konstantine_tomsk

07.07.2017 15:24

#10302528

Благодарю.

Эта фича появилась совсем недавно:

root@kos-pc:~# docker images 
REPOSITORY           TAG                 IMAGE ID            CREATED             SIZE
ftps                 latest              ec1586e2fa6b        6 months ago        183.9 MB
<none>               <none>              94e2a35c0867        6 months ago        183.9 MB
<none>               <none>              6fadfd9be53f        6 months ago        183.9 MB
<none>               <none>              64bcc95e2202        6 months ago        183.9 MB
ubuntu               latest              104bec311bcd        6 months ago        129 MB
morrisjobke/webdav   latest              440ff0fa165c        8 months ago        235.6 MB
cloudesire/webdav    latest              90b56fe81cf1        14 months ago       202.3 MB
root@kos-pc:~# docker system prune -a
docker: 'system' is not a docker command.
See 'docker --help'.
root@kos-pc:~# docker help | grep prune
root@kos-pc:~# docker help | grep pr
    pause     Pause all processes within one or more containers
    top       Display the running processes of a container
    unpause   Unpause all processes within one or more containers
    wait      Block until a container stops, then print its exit code
root@kos-pc:~# docker --version
Docker version 1.12.5, build 7392c3b
root@kos-pc:~# apt-get update && apt-get install -y docker-engine
....
Fetched 644 kB in 7s (87.0 kB/s)                                                                                                                               
Reading package lists... Done
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages will be upgraded:
  docker-engine
1 upgraded, 0 newly installed, 0 to remove and 252 not upgraded.
Need to get 27.8 MB of archives.
After this operation, 9,294 kB disk space will be freed.
Get:1 https://apt.dockerproject.org/repo/ debian-wheezy/main docker-engine amd64 17.05.0~ce-0~debian-wheezy [27.8 MB]
Fetched 27.8 MB in 44s (624 kB/s)                                                                                                                              
Reading changelogs... Done
(Reading database ... 194992 files and directories currently installed.)
Preparing to unpack .../docker-engine_17.05.0~ce-0~debian-wheezy_amd64.deb ...
Unpacking docker-engine (17.05.0~ce-0~debian-wheezy) over (1.12.5-0~debian-wheezy) ...
Processing triggers for man-db (2.7.0.2-5) ...
Processing triggers for systemd (215-17+deb8u5) ...
Setting up docker-engine (17.05.0~ce-0~debian-wheezy) ...
Installing new version of config file /etc/init.d/docker ...
Installing new version of config file /etc/default/docker ...
Installing new version of config file /etc/init/docker.conf ...
Installing new version of config file /etc/bash_completion.d/docker ...
Processing triggers for systemd (215-17+deb8u5) ...
root@kos-pc:~# docker images 
REPOSITORY           TAG                 IMAGE ID            CREATED             SIZE
ftps                 latest              ec1586e2fa6b        6 months ago        184MB
<none>               <none>              94e2a35c0867        6 months ago        184MB
<none>               <none>              6fadfd9be53f        6 months ago        184MB
<none>               <none>              64bcc95e2202        6 months ago        184MB
ubuntu               latest              104bec311bcd        6 months ago        129MB
morrisjobke/webdav   latest              440ff0fa165c        8 months ago        236MB
cloudesire/webdav    latest              90b56fe81cf1        14 months ago       202MB
root@kos-pc:~# docker system prune -a
WARNING! This will remove:
	- all stopped containers
	- all volumes not used by at least one container
	- all networks not used by at least one container
	- all images without at least one container associated to them
Are you sure you want to continue? [y/N] y
Deleted Containers:
fdc092a849cd9f5500cdc4bac5c2fd465b7440d54ace8b50c86b41ae49ce996d
0ac9c16aee083d33e4aaa7f3238ac368823e2ce8b88a1d4c63a40b9129f0df42
626e0357f1fde36b508e8c870e744805e446837b51b0761f19a277335b6a8018
32298e905660dd725777b7678042fd5070482784b71b836575a3363c83940c36

Deleted Volumes:
1c0bf6794364e34968cb3ee7935da91c3139c0998a98bd4af0b3803a54a9c826
21f9e1c9d3867c7dfc01564fbcddc2067ce72796d13bf946921045fe768f3c79
50531368fd787b4a0b5f941e8f53504a7a724c0f03806d09608d8908070cf874
69a34deffd1ed471cd5721d3c172a52a871383a17976187139fbd4d6d1f85a25
db3e0e98df167313c633b0b5f56dc87b7133f2e9cf43935205b35f2ef42ddd2e
ed036fa6ff33475c0ba1f4d93b8b0a345bedd87677408277c5bd0ffbb63d0b38
03d04514b5108d7a96f6931616e11b25a45dc3e6f42cf90df1fda7ea75011c32

Deleted Images:
untagged: cloudesire/webdav:latest
untagged: cloudesire/webdav@sha256:f1dc7ea00982daaca6726092662b34607cdc844337f9e182e22c771ada5be7d5
deleted: sha256:90b56fe81cf1b52cf04fc68bdacb5e8e92d884e78d6798dc5354584d690569da
deleted: sha256:410c327e98b5ff8050a1ae2eaf4ab3d77e70d4e04bd6bfaf6656809482b9e55d
deleted: sha256:694ff153e21433c8e386c0f2440385ff18f538688ae1b64e62c7fdc6e7203431
deleted: sha256:3d8b2dd73aaa4cf807bdacd6eb2185fc7ebfde91d5556026e16f76f4b225b74f
deleted: sha256:0d2b43dc8596adac2120c6c013de66ddf9453ec05a6a8cd94fa7bbaaaccb2c5f
deleted: sha256:6123690f5cc3a65a0ee06e2632fb0a56be7cee531729aad942748dd277774cd0
deleted: sha256:e722b95af0f6a54924998d67376d2a9ecd69b6d3004284bac176976c49e0ad32
deleted: sha256:f2d46f115acd0cf70996883f6ba9cdc83e5a3d590fad8330adfff898275751dc
deleted: sha256:c6532dbe282e7eecb5110afac45d62e766517e22325cf1f9ee8a41196b438049
deleted: sha256:0a33d0dc7807fde99537013867eab5296a30563f9a5fb040677d2bf8372f4d93
deleted: sha256:18f1b23c6b99ba139046f932eb9bbd9f4a0f7defcf4a647ce635e7db3d7da2b4
deleted: sha256:595d1d53a534d62d96eb8443aa471affadac811f4a80ecc87bed11564ecff097
deleted: sha256:64bcc95e2202553b74f4325cb37bf11e7934034869ef70a77ad613ba712c5c66
deleted: sha256:4eae6d1be2a04b65fff27201c6416f695f678f1ed7cb0355a9effbdc111312ba
deleted: sha256:f7bac2ab6b10fd652999c69a2ce947c1287b7108566a72ab81434fcf108db27c
deleted: sha256:6fadfd9be53f223244142c3e064537f455c53c8c57645be5dd99d29bf97dafd8
deleted: sha256:6aea83cc6df13d32a843b176576e05b3fc3b66d8778dd1da49179b56b7e1a970
deleted: sha256:cb31465fb4622caa0706eaf475aaec24a7f99775da1560a502e2c818dc017bc8
untagged: ftps:latest
deleted: sha256:ec1586e2fa6bcc45afd8843b1b3cfe6a6381399d5da6df0604d9091401f585df
deleted: sha256:cc1bc742dc6a101ca0643a14bfce4725fe710ad4a4e587b1b9c67d32817d7994
deleted: sha256:62d43895bac0fe934bde47c370260b6b3a8089fab94239e0337d756078e5176a
deleted: sha256:d679d2cbbd3c61c5ad23405e047135c32498611e673b0bdfcae899a65a67bfe6
deleted: sha256:6a936b9b673fc34f17aaccb294d5f0402cc03779322260d86f721a03a9f97785
deleted: sha256:9bdf3a3b13fa539fb7255d38eec09f9e62462a8c1dcf78207292e8f4cdafb7ab
deleted: sha256:d74d9b3c482956a54cf9ea79174c99d1917ec951fb80c8ca414add165fc73245
deleted: sha256:d6991ed7d7ad4e0ac3dfb9acaa3e32973443a032ee925f3ef5a1ba2d41f1229d
deleted: sha256:4a0e972a1191362e9e9c8fd3d4af5f16efae34cd0f381fbcf8ee49498e9e5978
deleted: sha256:54ab3bf962104b46785e7a9d204569b7c4d13337c2a56545ca6a3a806d676690
deleted: sha256:5d273a4fb62abbb86157f6f17f52db7ae98390be78159f6f4345235c6bc5bbee
deleted: sha256:fdc66a6aeeea30213a3f5d01381068657f78ed898dc83adac866a54ede74a7d3
deleted: sha256:ee9221b490955d21682b154da326938c94c44172956fb85a55edf3a97c8b3747
deleted: sha256:53b702567dae179275719ebd0bb56d0b6370e6d5d6c343889766821c545c0ce6
deleted: sha256:8ae47ee97fa0d074c05be7f2783be34337229b83e55f40c79e581aa03fa593ed
deleted: sha256:94e2a35c0867ab81c97eb3aa6ea6f42a25d280b9b6c1580bc90037beba90387d
deleted: sha256:008989073a57fecd42f10483878fbfecb7059d7008581a182a9067fcd7a29646
deleted: sha256:cd28f4a6ff20ed1e6b63fd23e858204726c25a5a3e14a968d2d35950b007bce5
deleted: sha256:035bdf6ee506e6190e2558428dee350aeae66dd83513aa082e1cdc95dc228d18
deleted: sha256:5b4bc153e438ae5b5c08e341358b892b21ff26cda234bc7e5e176d2e0cd34a03
deleted: sha256:932fe0d52295ade16eef8e7fba6bf18df2659080c7686c99528286dc19e8fac4
deleted: sha256:4072e5e16317e524cb282eea86ee78d76024ffc57d1390a14ca6eaceb54fbba6
deleted: sha256:fb5ff5fe8424c466d6e67c847e294b71bcb17ddddc036bd7ab48d44112d6a196
deleted: sha256:bca35918d9e984e9976a8c50b3eea92fcdec8707f64d8978e98dc67587478004
deleted: sha256:6b68b3dd2e313b2f03d432d9cb75b5719155c671b004d24be229dabfa7e6419e
deleted: sha256:b93301c6ed1642bedc6c9c81fe24b82b9dbcd45fe5d84c04431d7535a3aea9bf
deleted: sha256:e4ee8c70aa3efa0da00710a212ef2551be4fff79ab36920da17e42d19e7f4785
deleted: sha256:9e1adcd354b76f2c0be300f88f9f1d02e088085bf6a80e70b40b3b347124fa97
deleted: sha256:43a64b9f13c374a67abd081145550776cff7eb06e9c393d81930358e1976bb80
deleted: sha256:bcda2462a29482c799329ddd476d5d0fbf5ee76dc53e8ae6d88ab4778802c068
deleted: sha256:e0e914fbcdf48f06a38818b6049745fb1137d09f1e2ce726963693d6fb26d442
deleted: sha256:3752dbf61b14f31e67efab487a0b2a8211d830d836827c25bd7c95a2358d0a91
untagged: morrisjobke/webdav:latest
untagged: morrisjobke/webdav@sha256:047ee10e9c203359be976b293b36e86c309c6d3f1bde3fb5889ac068e3057760
deleted: sha256:440ff0fa165ced0ab6ee7640b8d0a0b9703db098ea1afd85c98b38b2af318270
deleted: sha256:e35807ec5accbf4007063ec6b1cd5a79eebf367362a936d2c5d8179ed15297fd
deleted: sha256:4ce07e3650515c2660dd1b5114dd0a26bd1100c0e5bed63badb5a919dd80cb70
deleted: sha256:914c3c74204f47c90acb3eaf8c8a56a5e2b8950b260715ed5331b6aad0f20163
deleted: sha256:cd8ac35891e60684726b0f8a02816bbe50e3be06ef0d7f58ffb5cf40151be393
deleted: sha256:447ffbeae728e539e04ca7ca8a9d1e1a6b32da2d6910aaf0b369a38f33cbbc49
deleted: sha256:34278cf4633bf6f8050079c5863578f1b2d3a9ad503e134fd91d4c99db6e1dc8
deleted: sha256:48046d55e8ed8c0dfde52fc3565e7c6d5cd0c194d41145df9d4cf03fa22f9eb7
deleted: sha256:253442bb18cf7314e6bf884a5d655d9d961c74a61c7aaaf9fec39d66a4c5c35e
deleted: sha256:2eeebe704364492211d739e1cc9f6a819c2f172c2c0e657b18583118bab3477e
deleted: sha256:dcb51132955240083a8f32d0cd34a79bfb78ed2abd9e379b6013806072ec757c
deleted: sha256:d53aefb0cbd70ce6e5fd39f675edc1251e25fd4e4d97fa0012ff1359ad9c54c5
deleted: sha256:abb67a92a62ea1f47ac19ea88f089b042fc7f6304507653853aa6c2bcf1b0a3a
deleted: sha256:041d7eb3a5ffb3de9f347ca292f6a965ffac877a2aaa7a51cda7351fbd830d67
deleted: sha256:2a46e827da9992067481634e155caa2742dd342be04075ac904a09c93666c7a6
untagged: ubuntu:latest
untagged: ubuntu@sha256:7a64bc9c8843b0a8c8b8a7e4715b7615e4e1b0d8ca3c7e7a76ec8250899c397a
deleted: sha256:104bec311bcdfc882ea08fdd4f5417ecfb1976adea5a0c237e129c728cb7eada
deleted: sha256:f086cebe1dd257beedaa235e4eef280f603273b4c15cbe6db929ab64f100c302
deleted: sha256:84cfefd72f9a8be0b92adfb93664e9bc8d740829152f1ab76b2a8393d56d8db8
deleted: sha256:f7309529402984109c74a95ee5d68c0a5aa57241070890a09c76be48a8cd773f
deleted: sha256:23f1e9516742d68eaa2439dd50693bf7294fcd64d69d9643e51a4be64aa0b97c
deleted: sha256:32d75bc97c4173417b54eb2a417ea867637c3014dc1b0dd550f11ab490cbb09f

Total reclaimed space: 4.239GB
root@kos-pc:~# docker images 
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
root@kos-pc:~#

Caravus
07.07.2017 15:37
#10302570
apt-get update && apt-get install -y docker-engine

Он теперь docker-ce, насколько я помню — меняли.

Merkat0r
07.07.2017 00:02
#10301410
+1
О, Шиллен, какая же годная статья…

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

Сколько ж мне таких крови то выпило :))
И ведь спрашиваешь — а зачем? — ну как, этож ~~святой грааль~~ докер!

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