Comments 175
У меня конечно не супер прод., но и сервисы различные и БД вполне живут в докер и ни разу не испытывал проблем.
Докер это инструмент, никто не обещал что он подойдёт для всех задач поголовно, прежде чем пихать его, необходимо разобраться в том что он может — чтобы потом не писать, длинные, бесполезные посты.
Сорри, не заметил что перевод, но мнение не меняет этот факт :)
Прочитал полностью. Не знаю, зачем. Читается как обычная чернуха-заказуха. Очень похоже по звучанию на микрософтовские Гет Зе Врактс. Претензии заключаются в том, что Docker нет ещё 5 лет (через 5 лет напишут: "Да он древний как мамонт!") и сложно настраивать (Нет кнопочки "Пыщь! Готово")
Если все будут только рассказывать мимимишные истории как всё круто, не случится никакого прогресса.
Автор ругается в первую очередь на баги. В багтрекере их 2596 незакрытых.
Посмотреть можно здесь: https://github.com/moby/moby/issues
После прочтения статьи, я на полчаса забурился в багтрекер, там попадаются очень интересные экземпляры.
Например вот этот: https://github.com/moby/moby/issues/20997 появился в результате рейса между libnetwork и командой. Но его давно починили. А вот этот еще не починили: https://github.com/moby/moby/issues/27381.
Шестнадцать.
Тысяч.
Багов.
В.
Релизах.
Вы действительно считаете это нормальным? Они вообще тестируют билды перед выпуском новой версии?
Поэтому этот номер какбы вообще ниачем.
Фиксы прибыли в январе 2017 :D
JVM уже умеет в cgroups? Docker делает изоляцию и лимитирование ресурсов через cgroups и namespaces (тут только изоляция). Для cgroups нужна поддержка, потому что иначе софт не видит лимиты, установленные cgroups, но ядро их форсит (free в контейнере, например).
Так вот, в JVM добавили эту поддержку или нет? Если нет, то это проблема JVM и отсутствия поддержки ядерных механизмов изоляции :)
С изолированием докер как раз справляется. А вот JVM в изолированном окружении, насколько я понял ситуацию, работает как-то неправильно.
Нет-нет, вы тут путаете один момент: cgroups — ядерный механизм, который работает.
То что JVM его не поддерживает проблема исключительно JVM, потому что если JVM попытается сожрать больше памяти чем позволяет cgroup, то апп вылетит в трубу — именно так оно и работало в Java 8, и это неоднократно поднималось на SO.
Как бы это и мой любимый докер, только после этой статьи мы его в лайве использовать не будем, хотя подумывали. По вполне объективным причинам, описанным в статье.
Где? Где в статье объективные причины? Не вижу, процитируйте, пожалуйста, хотя бы одну. Я вижу только пачку натужно выдуманных придирок. Не все хотят пользоваться облаками Амазона и Гугла, а все остальные придирки одинаково применимы к любой сложной программе.
Ну, если баг, приводящий к зависанию dockerd, который исправляется только ребутом всего сервера — не критичный, то я не знаю.
И это при том что у нас всего 3 докеризованных приложения.
Короче. Докер НЕ ДОЛЖЕН ЗАПУСКАТЬ базы данных в продакшене, by design.
более 100 с чем то серверов(изолированных друг от друга), всё в продакшене, есть очень нагруженные узлы (4 сервера в кластере), ну так 600 млн. записей в базу в сутки, записи — строки(в среднем 200-300 символов), всё работает через докер. Я не знаю, что у вас там, может железо.
На Хакерньюзе так вообще 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Конфигурация обычная.
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 на основном узле
есть очень нагруженные узлы (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%.
Всё — правда. Чувствуется, что выстрадано — прошли по ВСЕМ косякам. Но:
- История неуспеха — одна, а историй успеха — больше.
- Чуть-чуть устарело (улучшения улучшаются).
- Мы (коммьюнити) продолжаем есть кактус.
- Они (те, кто описан) — продолжают есть.
Так что, я бы расширил вывод:
Пользуйтесь, но помните что БЫВАЛО и так.
История неуспеха — одна, а историй успеха — больше.
Многие никогда не поделятся своей историей неуспеха. По различным соображениям.
И, по большому счёту, у этих ребят скорее история успеха — они работают, и инструмент у них тоже, худо-бедно, но работает.
[sarcasm] Критика докера же запрещена, а еретиков всегда сливают? [/sarcasm]
а если серьёзно, docker — чудесный инструмент, но стоит 2596 раз подумать, прежде чем тащить его в прод, да ещё и в такой области как финансы (число неслучайное, это количество issues открытых на данный момент, и большинство из них — баги)
и да, проекту help всегда wanted по починке этого кошмара
Я правильно понимаю, что и в 2017 эта проблема все ещё есть?
Как человек, очень далекий от всего веба, спрошу:
- Сейчас докер production ready?
- Они его использовали/используют, героически ужёвывая кактус, или они его выкинули и пользуются чем-то другим, что решает их проблему?
- Зачем, вот зачем писать свою собственную ФС?!
ПЛЮСУЮ К НАПИСАНИЮ СТАТЬИ.
В свое время из-за overlayfs пришлось вручную собирать в контейнере coreutils, ибо tail -f тупо не работал на том дистрибутиве, который был в контейнере. Тот ещё кактус.
Надо Умпутуну в radio-t накинуть. :) У него же как раз финансовая сфера, миллионы транзакций и долларов, сервера на Amazon и Docker в production.
1. отказывайтесь от privileged режима
2. уменьшайте количество слоев в конечных образах
3. не пилите докер там, где это не нужно
Закуплен гигантский хост на Амазоне, в него воткнут докер, на котором крутятся около 1000 контейнеров.
ПРОД
В специальном Skype канале «Central Outages» постоянная движуха — самое частое сообщение: docker daemon not responding, please restart it.
Из моего личного опыта — докер действительно хорош, если не перебарщивать с количеством контейнеров на хосте. Пока их до сотни — нормальный сервер справляется с этим зоопарком хорошо. Потом надо быть уже сильно храбрым.
Наши опсы — самые храбрые в мире :)
Статья отличная, но не нетленка.
Значительная часть проблем была исправлена, добавили docker system prune/docker image prune, перешли на новый релизный цикл, перешли на overlay и так далее.
Вроде сторонние регистры в это умеют.
Например, Gitlab Container Registry.
Ну и Artifactory конечно.
И работает? Задаром-то?
Кстати, откуда 25к взялось, когда $85 в месяц?
aptly — наше всё.
Есть one tool to rule them all. Умеет и rpm, и debian и сами Докер образы, и еще много много всего.
$85 в месяц дорого?
Каких фич не хватает за $85?
И видел вот прямо на официальном сайте, в разделе pricing.
обновляются без обратной совместимости?
ну ок, мы деплоимся по blue-green, уже было такое что так обновлялись месяц с версии еластика 1.4 на 5.2.2 — на таком скачке совместимость вобще раздолбана ко всем чертям
естественно из-за blue-green нашли проблему раньше чем положили рабочую систему, доработались, поставились
whats problem?
баги из-за которого рестартует хост?
ну ладно, у меня приложуха живет не меньше ( иногда и больше) чем в трех контейнерах на трех разных хостах в трех разным датацентрах, имея в пуле еще десяток свободных машинок, один инстанс переедет, потом вернется ( когда и тот упадет )
неприятно, ссыплет в логи, но фатальным трудно назвать
опять же, это должно пройти через blue-green
почему чувакам было так больно от рестарта машинки?
отчего они вобще ходили по хостам и руками поднимали контейнеры?
непонятно
еще раз, все это пилится не для того чтобы гарантировать аптаймы по несколько лет — все это пилится для того чтобы легко переживать частые падения
Спасибо.
Интуиция мне говорит, что нет.
Есть реализация, которая полагается на «большого дядю, который делает надёжно». Референсной реализации «надёжно» — нет. Потому что если мы притащим любые средства распределённого хранения данных (ceph, gluster, etc), как тут же окажется, что нужны нормальные средства администрирования и деплоя, и что без них ничего «надёжно» не живёт. А когда появляются нормальные средства деплоя, то оказывается, что модель докера — унылое говно и с реальностью боевого продакшена не соотносится.
Data have gravity © netapp. Я их не люблю, но слова золотые.
не кладите данные в контейнер
целевое место зависит от данных, которые вы хотите юзать
если речь про настройки приложений — юзайте config-server (consul, spring-cloud-config-server и иже с ними)
если речь про СУБД — выносите на отдельные хосты, вне экосистемы докера
и это же написано в оригинальном комменте — не надо засовывать их в докер или даже на хосты с докером
а приложениями только стучите в них
Пусть во внешней СУБД. Но как именно? Потому что пока это выгляди так: мы будем играться в куличики в песочнице, а проблемы будут решать взрослые. Как — не знаю, но куличики у нас прикольные, всем срочно лепить куличики.
он написал там — у них нету автоматического оркестратора с автопереездами, автоподнятиями и прочей автопочинкой. Наверное, смотрят на мониторинге алерты, и руками поднимают что упало. Как собственно, и большая часть мира, которая до высоких технологий еще не добралась
полное падение сервиса для них смертельно, потому что это не просто какие-то транзакции, а высокочастотный трейдинг. Сервис поднимется через секунду, но через секунду уже будет ненужно
1) Проблема в том что никто не использует докер просто так
всего его оркестрируют ( это mesos, kuber и прочие) — а это предполагает что ваши приложения готовы уехать с одного хост на другой в любой момент времени и как угодно часто, просто потому что оркестратор так решил ( перераспределяет ли ресурсы, упал ли хост — не важно), соответственно все ваши данные должны скидываться не просто на диск, а в какое-то облачное/сетевое хранилище, что добавляет немало проблем.
2) стейт это вобще говоря не только про данные на харде, но и про данные в оперативке, которые бывают почему-то важны
любят некоторые запихивать j2ee сервак в докер — это вот к примеру точно антипаттерн засовывания толстого приложения со своим рабочим стейтом, которое не может просто так взять и быстро переехать с хоста на хост
Миграцию контейнера со стейтом по слухам дорабатывают в докере — к примеру вот https://criu.org/Docker
This feature is available in the experimental mode for Docker
где-то видел и интервью автора по поводу работы с командой докера в этом направлении
В общем случае — нет.
Скорее зависит не от того на чём написан сервер, а от того как он написан и чего ожидают клиенты. Если для клиента критично поддерживать постоянное соединение с сервером, архитектура системы не поддерживает распределения атомарных запросов по нескольким инстансам сервера, а связывает их в длительные сеансы взаимодействия со сложным хендшейком (или просто эффективно сервер работает только после долгого прогрева внутреннего кэша), то чтобы достоинства докера хорошо себя показали придётся много дополнительной работы делать.
Если ваш сервер ближе к традиционному серверу РСУБД чем к некэширующему прокси, горизонтально не масштабируется или масштабируется плохо, скорость работы с диском критична, да она ещё и монопольной должна быть, для системы важно чтобы держались длительные соединения между сервером и клиентом, да ещё по статическим IP, рестарт сервера надолго парализует эффективную работу клиентов даже если несколько инстансов сервера ещё нормально работают, сильная привязка к версиям ядра ОС и т. д., и т. п., то даже при идеальной работе докера, без всех этих ужасных багов из поста (я не сталкивался с крашами и зависаниями, но СУБД у нас пока даже не планируется докеризировать даже в тест-среде, только в дев, максимум в проде редис как хранилище сессий и кэша) то, вполне вероятно, основной плюс докера для вас будет лишь обеспечение единого (почти) рантайма в дев- тест- и прод-средах, которое может оказаться проще и дешевле достигнуть другими средствами типа виртуалок в дев- и тест-средах и параметризуемых средств управления хостами типа ansible, chef и т. п., а докером много времени потратите на "прибивание" сервера к хостам, дискам и прочей "стабильности".
Если же лишь малая часть вашей системы имеет подобные требования и(или) особенности (как вариант — такую часть легко выделить из имеющегося монолита или классического SOAP), а остальное устойчиво к многочисленным рестартам, клиенты к инстансам особо не привязаны (по типу http keep alive — соединение держим чтобы не тратить время даже на дешевый хэндшейк, но ничего страшного если порвётся и новое установится с другим инстансом), кэширование в памяти бесплатный бонус, диск особо не нужен, нужен лишь в ридонли и(или) нормально работает с сетевой шарой будь то nfs/smb или какие-то облачные хранилища, то подумать о переводе остальных частей имеет смысл, если сейчас испытываете заметные трудности с обеспечением идентичности разных сред или горизонтальным масштабированием.
Если я правильно понял — в докере по хорошему не должна быть завязка на состояние (базу, кеши, сессии, ...) — тогда и проблем не будет.
Видимо java-ee принятно считать монструозным интерпрайсом, хотя это давно не так.
Скажем так, обычно без особых проблем докеризируются сервисы, которые в "bare metal" мире легко переживают смерть сервера и разворачивание его с нуля (не с бэкапов) на новом. То есть сервисы даунтайм которых может и останавливает работу пользователей, но новый поднятый инстанс позволяет продолжить без необходимости кучу действий по восстановлению информации с умершего сервера или бэкапов производить
Естественно, при краше вы потеряете данные в обоих случаях
Речь идет о том что не надо пытаться использовать технологии, которые заранее говорят, что они не сильно заботятся о времени и стабильности жизни контейнера ( и даже более того, убивают и поднимают новые, когда захотят), для случаев, когда вам нужно долгое время жизни и стабильность контейнера
Во-первых, смысл контейнеров — в экономии ресурсов, благодаря запуску множества контейнеров на одном (большом) хосте.
facepalm
в 2017 году, имея все средства оркестрации и масштабирования, мы пытаемся запускать все на одной большой машинке
лучше было только когда в одном банке на собесе рассказывали, как они через sh запускают руками jar с сервисом на embedded jetty, руками прописывают его хост и порт в балансер, а потом говорят про это «У нас микросервисы, все стильно модно молодежно»
Заметка: Kubernetes требует для своего запуска докер. Он будет подвержен всем проблемам докера. (Например, не пытайтесь запустить Kubernetes ни на чем, кроме CoreOS).
Забавно. K8S официально поддерживается как минимум на ubuntu и centos же.
Докер задуман быть stateless. Контейнеры не имеют хранилища на диске, всё что происходит — эфемерно и уходит, когда контейнер останавливатеся. Не подразумевается, что контейнеры будут хранить данные. На самом деле, они спроектированы чтобы НЕ ХРАНИТЬ данные. Любоая попытка действовать против этой философии приводит к несчастьям.
Вы вообще в курсе про volumes и volume drivers/plugins?
https://docs.docker.com/engine/tutorials/dockervolumes/
https://docs.docker.com/engine/extend/legacy_plugins/#volume-plugins
Наличие томов и плагинов для них не отменяет того факта, что необходимость сколь-нибудь длительного хранения состояния (и не только на диске), необходимость расшаривать данные между сервисами (банально файлопомойку между веб- и апп-сервером) значительно усложняет докеризацию сервисов. Без томов, поддерживающих разные варианты шаринга данных, докер вряд ли бы вообще взлетел, оставаясь в лучшем случае весьма специализированным средством масштабирования стейтлесс-сервисов типа некэширующих прокси или php-приложений, которые и так рождены, чтобы умереть :).
Да и с ними сейчас какой особый смысл заворачивать в контейнер что-то типа MySQL или PostgreSQL, если вам нужно держать один инстанс мастера и пару слэйвов и для этого у вас три хоста, а нагрузка и(или) бюджет не позволяет держать базы на сетевых хранилищах, только на локальных дисках? максимум имеет смысл, если всё остальное (что-то типа nginx+php) прекрасно докеризируется, получаете кучу плюсов от этого и испытываете сложности со связью докеризированного и недокеризированного окружения, когда --add-host явно недостаточно.
Означает, что настройка и эксплуатация системы в докере сильно осложняется как только возникает необходимость в персистентных данных, переживающих смерть контейнера, особенно если новый может быть поднят на другой ноде, да ещё если нужно обеспечить к ним доступ извне контейнера-"владельца". Докер не предлагает решений "из коробки" по организации чего-то типа распределенной файловой системы. Максимум — монтировать хост директорию на директорию контейнера без всякой синхронизации хостов друг с другом. Была бы хоть какая-то дефолтная, пускай медленная и не очень надежная было бы гораздо проще. А так на каждый чих нужно думать как лучше организовать хранение данных. При том крайне желательно глубоко разбираясь в механизмах томов.
По факту, докер — удобный (ну… на любителя) интерфейс к средствам ядра (Linux прежде всего) оркестрации процессов с изоляцией их друг от друга: chroot, cgroups, вот этот вот всё… Шарится по умолчанию только ядро, для шаринга остального нужны дополнительные усилия, иногда весьма нетривиальные.
Типовых сценария два, вроде как:
Обеспечение идентичного (почти) окружения в разных окружениях типа дев-, тест-, CI, прод. Грубо, чтобы развернуть локально систему из десятков демонов, включая СУБД, новому разработчику на проекте нужно лишь установить докер и пару-тройку команд (включая git clone) выполнить. Разворачивание/обновление нового продакшена тоже не сильно отличается. Конкуренты тут вбокс/вмваре воркстейшн, вагрант, а также ансибль, чиф и т. п. Докер позиционируется как более дешевая (прежде всего по потребляемым ресурсам в рантайме) и гибкая (если шаринг ядра устраивает) альтернатива им.
- Обеспечение горизонтального масштабирования в продакшене. Оркестрирование сервисами, их обнаружение, связь между ними, регуляция количества инстансов, мониторинг, единые точки сбора логов и т. п. Тут основные конкуренты видимо системы типа вмваре нетсфера с тулингами разными, а также облачные хостинги. Плюс есть, грубо говоря, высокоуровневые обвязки для докера типа Кубернейтс от Гугла, которые эти манипуляции позволяют делать проще, используя докер как тупую систему сборки и запуска контейнеров из образов. Хотя могут и аналогичные бэкенды использовать — докер, наверное, лишь самый раскрученный из них.
В целом главный плюс — написал несколько условно декларативных файлов, собрал один раз, залил в репозиторий (реестр) и запускаешь везде систему из множества демонов в любом количестве инстансов имея практически идентичные окружения, изолированные от всего остального.
На моей практике больше всего усилий приходится прилагать как раз для преодоления изоляции. Типичный кейс без стандартного решения от команды докера: крутится с десяток nginx и другой десяток php-fpm в контейнерах, представляющих попарно веб-сервисы, каждый nginx думает, что он слушает 80 порт и является дефолтным сервером (без подобной конфигурации смысла в докере мало в моих кейсах), каждый отдаёт статику и "проксирует" "php" запросы на 9000 порт хоста app-fpm и нужно а) обеспечить доступ извне к каждому nginx отдельно, да ещё желательно по https и б) обеспечить шаринг между nginx и php-fpm пользовательской статики. В локальном окружении последний вопрос почти незначим, но если хочется единообразно разворачивать систему и локально и в продакшене, да ещё на нескольких нодах кластера, да с возможностью отдельно масштабировать количество процессов nginx и php-fpm — придётся попотеть.
Чувствую боль автора.
Лично у меня докер периодически не может убить/остановить один или несколько контейнеров. Спасает только перезагрузка хоста.
Волосы у меня начали шевелиться когда докер начал раздавать одинаковый 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
Да, статья является хорошим жизненным уроком. И многие выводы, полученные кровью эксплуатации, являются реальностью новых технологий. Но давайте задумаемся, как бы выглядела статья в журнале от человека, который пересел с лошади на автомобиль
До машин все ездили на лошадях с повозками. Это было невероятно удобно:
- покормил и едешь дальше
- отходы сами утилизируются (а иногда их даже покупают!)
- лошадь пришла в негодность — пристрелил
- лошади сами воспроизводятся!
- для обслуживание подков есть кузнецы
- плохой кузнец — можно пристрелить
- новое поколение лошадей совместимо со старыми
А сейчас с машинами одни проблемы. Давайте разберемся.
Машины: проблемы эксплуатации
Машины: каждое новое поколение слабо совместимо со старыми
Производители машин просто издеваются над потребителями! Каждая новая версия любимой модели отличается от старой и детали не совместимы. Если вы поклонник определенной марки и модели, то вам придется смириться с тем, что через 5-10 лет и пару поколений вы не найдете запчастей на свою версию авто.
Бонус: производитель может решить, что ваша любимая модель больше не нужна и прекратить ей выпуск. совсем
Машины: баги редко исправляются
Если в машине будут найдены критические или не очень баги, то их исправят лишь при следующем релизе. Лишь некоторые баги удостаиваются исправления в текущих версиях путем отзыва и ремонта у диллера.
Бонус: даже если вы найдете баг, требующий исправления, но не признанный производителем — вам придется долго и упорно доказывать наличие бага, и скорее всего вы исправите все за свой счет.
Машины: огромные требование к обслуживанию
Машины, в отличии от лошади, не способны сами прокормить себя. Вам придется постоянно покупать запчасти, заправлять бензин и проводить прочие манипуляции. Все это требует дополнительных затрат, которых с лошадями либо не было, либо они были ниже.
Бонус: отходы утилизируются сами, например: выхлопные газы сами уходят в небо..
Машины: сложности утилизации
Лошадь можно просто пристрелить. Некоторые даже едят лошадей. То есть лошадь в голодное время может прокормить хозяина! А машины что? прокормить собой не могут. Пристрелить нельзя. Просто выкинуть тоже — налог то все равно придется платить.
Бонус: можно дождаться пока машину подожгут и получить страховку(не делайте так).
Дороги
Дороги: плохая совместимость с авто
Лошадь — универсальное средство передвижение, которое может пройти везде. А вот машины, по большей части, ездят по дорогам. И хорошим дорогам. Тяжело найти дорогу, которая совместима с вашим авто. Я протестировал разные сборки дорог в России, и не нашел ни одной дороги полностью совместимой с моим авто. Всегда есть какие-то проблемы в реализации дорог: плохое покрытие, непродуманные развязки, etc.
Бонус: можно купить машину с высокой посадкой и полным приводом. Но тогда езда по городу может превратиться в страдания: ибо большой рамный внедорожник очень тяжело припарковать в современном мегаполисе.
Вывод: вам придется иметь несколько авто для разных типов дорог.
Дороги: скорость
Новое поколение дорог, построенных для машин, принесло новые проблемы: огромные скорости движения, ранее недоступных для лошадей. Но сущность человека не изменилась, навыки и реакция лучше на стали, и, как результат, мы видим огромное количество аварий и смертей, вызванных превышением скоростных режимов.
Некоторые модели авто до сих пор не совместимы с новыми дорогами! На скорости их кидает, заносит — ужас на дороге.
Вывод: вам придется постоянно обновлять автомобиль, и следить за каждым новым релизом.
Топливо
Не смотря на попытки внедрения новых типов двигателей, потребляющих новые типы топлива, бОльшая часть авто все равно ездит на бензине/дизели. И это крайне опасно, ведь когда-нибудь бензин закончится и все текущие релизы автомобилей просто встанут и их эксплуатация станет невозможна!
Хуже того, просто пропатчив ядро двигателя, вы не сможете добиться поддержки новых типов топлива!
Бонус: топливо постоянно дорожает, не смотря на колебания цен на нефть.
Вывод: вам придется обновлять автопарк и покупать машины с двигателями, имеющими в ядре поддержку нового топлива
Бюрократия
С лошадьми все было просто: У кого лошадь, тот и хозяин. Украл лошадь — она твоя. Никто не докажет. А сейчас: номера, свидетельства о регистрации и постановки на учет, и прочее-прочее..
И ведь каждая бумажка требует материальных вложений.
Бонус: в большинстве стран Вам придется покупать страховку, без которой — в случае аварии — будет не очень приятно.
Disclaimer
Статья шуточная, и направлена лишь на осознания прогресса. каждая технология требует обкатки. И обкатка любой новой технологии — это риск. Но выживают и растут лишь те, кто следит за прогрессом и не боится нового. Вспомните историю мобильного подразделения Nokia, которое игнорировало прогресс.
А ещё можно вырыть покругу тоннель замкнутый, развешать внутри проводов, назвать его как-нибудь экстравагантно — адронный коллайдер, например, и потом втирать всем на конфернция, что ты в нём ставишь эксперименты, что-то открываешь, иногда находить какие-то вещи на поверхности земли среди камней, тащить в свой коллайдер и потом всем рассказывать, как ты это изобрёл в нём…
Прогрессивный человек! Учёный! — все будут говорить.
А если кто скажет что ты неё… (обманщик), устроить ему суицид, рассказать всем что этот человек был невменяемым алкашом. И не важно что он когда-то изобрёл колесо самым первым.
Это ответ в цвет комментарию, кто знаком с историей вокруг докера и людей на нём завязанных, поймёт намёк. Пасхалачка эдакая.
Единственный способ очищать место — это запускать следующий хак каждый день, скорей всего по крону:
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 диски.
docker system prune -a
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:~#
Люди постоянно спрашивают архитектора, почему бы не переложить %это% в докер, и лицо архитектора в такие моменты словами не передать.
Сколько ж мне таких крови то выпило :))
И ведь спрашиваешь — а зачем? — ну как, этож
ЗЫ я всегда говорил, что это несправедливо захайпленная вещь-в-себе и взлетевшая только благодаря очень агрессивному маркетингу.
Из собственной личной практики:
1. Использую несколько лет docker версии 1.12 и 17 в нескольких проектах.
Везде Ubuntu 14 или 16 с 4 версией ядра.
Один проект так вообще динамически создаёт контейнеры и постоянно их останавливает, запускает… порядка 1000 контейнеров динамически создаваемых.
Везде aufs.
Всё работает… если и бывают какие-то проблемы именно со сотороны докера, то они очень редки.
2. Удаление образов… не сталкивался с такой проблемой, места на одном сервера впритык а контейнеры бывало часто перестраивались… удаляется всё нормально.
3. AUFS нестабилен? Не заметил.
4. Про кривые ключи и мировое падение это перегиб какой-то. Ну уберите репозиторий из иточников, ставьте напрямую из файлов docker… Автоматиеский деплой на то и нужен, чтобы легко можно было всё поправить.
5. Про свой реестр образов не скажу ничего, не пользовался.
6. Релизный цикл у докера нормальный, всё живо, ошибки бывают но исправляются.
7. Хранение данных в докере — даже мыслей никогда не возникало хранить какие-то данные в контейнерах докера, все данные на хосте, а в докер только volume пробрасывается. Кто им посоветовал данные в докере вообще хранить…
Такое чувство, что авторы статьи просто не особо задумывались когда начали применять docker… и наступили на грабли, которые можно найти везде.
По моим прикидкам, это убыточная технология, которая накручивает значимость специалистов в области IT, стимулирует продажи нового желез. Ни для кого не секрет, что компании не умеют оценивать компетенцию специалиста в приложении к деятельности этой компании. Поэтому специалисты со знанием докер могут рассказывать, как удобно всю инфраструктуру переложить в кубер. А к тому времени, когда всё переложили в кубер, обратно перекладывать ещё дороже встанет.
Это как с ОС Windows. Вы её закупили в компанию, вам совершенно не выгодно выбрасывать купленную ОС и переводить всё на Linux. Потому что это будут лишние издержки. Так ошибки крупных внедрений продолжают жить. Так и с докер. Сначала тебе не понятно, как использовать, потом ты долго придумываешь на его базе, что городить, а потом убедившись, что он очень плох, не можешь с него слезть. Потому что нужно объяснять генеральному директору, что ты его бизнес всадил на дцать миллионов, просто «позырить», как это работает, а сейчас всё надо «вертать в зад».
Грустно это всё. Грустно, что очень много таких деятелей, которые понавертели всего этого. Грустно, что эти деятели набирают сотрудников, чтобы прикрывать свою «грязную ж...»
Если предположить, что у вас есть сайт, состоящий из сотни приложений, каждое из которых в разных состояниях (дев, стрэйдж, тест, препрод, прод и т.д.), количество приложений постоянно меняется, над каждым работает своя команда, количество инстансов зависит от системных метрик и от бизнес-метрик, то я не представляю как это будет работать без систем управления конфигурациями и инструментов подобных докеру… Там терраформ, кубктл скрипты, пайплайны.
Простой кейс — поднялась нагрузка. Чё делается — автоматом понимается нужное количество подов и инстансов, упала нагрузка — убиваются, экономя деньги на gcp. Просто например.
Разработчик внёс изменение в код, отправил к примеру в гитлаб, по пайплайнам оно сбилдилось, вынеслись артефакты, приложение ушло в тест, поднялись автоматом нужное количество инстансов и подов, автоматом прикрутился мониторинг и разные метрики. И всё это по заранее написанным шаблонам. А чё без практик и инструментов девопса? «Э, Вася, подними мне 7 виртуалок на хрум-хрум-ОС-0.0.1.2, макет приложения сделать надо». Ну Вася и поднимает, периодически совершая много мелких human error… часа за 3… А потом приложение внутри просто не работает)
Всё зависит от реализации подхода и надо ли его вообще применять.
Вот ещё пример — вам нужна работающая копия вашей инфраструктуры и быстро.
Но то, что подобные вещи надо измерять в цифрах — вы абсолютно правы. Там где это не выгодно (ранее, сейчас, через год) — там и не надо. Для этого и нужна бизнес-аналитика, для этого нужны тесты и данные.
У маленьких и средних не ИТ-компаний, увы, далеко не всегда есть ресурсы на многочисленные тесты, чтобы полноценно протестировать весь спектр доступных для решения их задач технологий. Берут несколько вариантов "хайповых" как правило, тестируют поверхностно и внедряют. Даже если внедрение очень удачно по цифрам, то не факт, что альтернатива не была бы ещё лучше. Я вот, например, до сих пор не могу сказать, чем бы закончилось моё первое внедрение докера от локальной разработки до продакшена, если бы в качестве оркестратора был выбран кубернетес. Это сейчас ему, грубо говоря, альтернативы нет, а тогда мне казалось, что docker swarm вполне достойная, а внедрить можно гораздо быстрее
Я взвешивал несколько лет назад по отношению к имеющемуся в компании и парочке альтернатив (в итоге альтернативы, вагрант+виртуалбокс и ансибль, дополнили докер). Я не рассматривал все известные мне варианты и, тем более, не рассматривал все возможные, а оставил только те из известных, которые по очень грубой оценке казались мне в принципе приемлемыми для компании.
Были реальные проблемы как с деплоем приложения на различные контуры, так и с локальной разработкой. Когда решили внедрять SOA/MSA, паралелльно выходя на рынки других стран (собственно внедрение SOA/MSA было обусловлено этим выходом, хотя были и другие варианты), то проблемы качественно усилились. Внедрение докер (сначала docker-compose, потом docker swarm) количество инцидентов значительно уменьшило, а трудозатраты на задачи типа "нужно развернуть эту ветку метарепозитория для разработки/тестирования" или "нужно добавить ещё один сервис на стандартном стэке" снизились практически до нуля.
Да, исследованы были не все доступные варианты, да, многие были отброшены по субъективным мотивам на этапе отбора "для участия в тендере", да, не были учтены затраты на обучение, да, не были учтены "итальянские забастовки" многих админов, которые напрямую не отказывались переходить на новые технологии, но перестали проявлять минимальную инициативу во всём, что касалось внутренней разработки и эксплуатации докер-кластеров.
И по железу затраты снизились. На первом этапе :) Потом внутренние заказчики вошли во вкус, получив возможность самим развернуть ветку своей задачи, а не создавать заявки, вовлекающие 3-5 человек, и начали лоббировать увеличение мощностей перед "генеральным" директором (исполнительным, но не суть), аргументируя, прежде всего, показателями "тайм-то-маркет" их задач, чтобы не ждать своей очереди на демо и тесты (да, главными тестировщиками у нас были внутренние заказчики в лице руководителей департаментов и подчиненные им бизнес-пользователи). Потом даже лоббировали постоянно живущие инстансы каждой задачи, но это у них не прокатило, так что получили, грубо говоря, пул инстансов, на которые раскатывали нужные им здесь и сейчас ветки.
Возможно, переход на какой-то другой стэк похожих по целям технологий принёс бы больше профита компании, но переход на докер его однозначно принёс, снизив трудозатраты на задачу (как напрямую за счёт быстрого развертывания, так и косвенно за счёт более раннего фидбэка, изменения задачи), её "тайм-ту-маркет" и увеличив прозрачность процессов разработки для внутренних заказчиков.
По моим прикидкам, это убыточная технологияа можно выложить эти прикидки?
Moby/Docker в продакшене. История провала