Примечание переводчика: в предыдущей статье о подготовке к девопс-конференциям, 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 минут. Это сильно нагнетает градус драматизма, и боль от прочитанного.
В любом случае, чтобы ни случилось в прошлом — прошлое уже в прошлом. Наиболее важная часть — план на будущее. Это то, что вам точно нужно знать, если собираетесь внедрять Докер (или использовать Амазон вместо этого).
Автор: olegchir
