Стоит ли юзать Докер для базы данных?

На продакшоне я бы не стал. Не по таким причинам, просто по ощущениям.

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

На последнем месте работы все было в докере, кроме БД, которая жила на отдельном сервере

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

Насколько это всё реально? У вас есть какая-нибудь нагруженная БД в докере на проде, как полёт?

Youtube гоняет базы данных в кубернетесе на проде

Впрочем, автор прав в некоторых местах - пользоваться докером неудобно, лучше ждать пока допилят CRI-O

ни за что не храните в докере данные

Это разве в тьюториалах не написано?

Как-то раз пробовал поднять локально Gitlab из готового контейнера. Так там в инструкции есть указания по пробросу директории для файлов БД. Хранить же данные внутри контейнера — очень странно.

https://myopsblog.wordpress.com/2017/02/06/why-databases-is-not-for-containers/

Мне кажется, тут вопрос даже не в БД, а в данных в принципе.

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

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

Аргументация про то, что де когда докер оказывается под нагрузкой, в нем ломается всё что подключено

Никогда ничего не ломалось, но у меня пиковая производительность MySQL в докер-контенере раза в два ниже, чем на хосте. Поэтому MySQL (и также Redis и т.п.) использую только общий на хосте (или в LXC — там просадки по сравнению с хостом нет), а контейнеры уже к нему обращаются.

Также, аналогично, в критических местах nginx статику отдаёт прямо с хоста, в docker-контейнере тоже проседает производительность.

Удваиваю Kubernetes. Причем с релиза 1.7 (который вышел не так давно - blog.kubernetes.io/2017/06/kubernetes-1.7-security-hardening-stateful-application-extensibility-updates.html) есть возможность хранить персистентные данные локально.

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

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

Знакомые ребятки переехали на docker. Программеры рады, админы в шоке. Админ сказал:

Докер это огромный, огромный глючный костыль

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

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

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

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

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

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

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

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

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

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

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

Похоже, сообщество пользователей Docker недооценивает угрозы зависимости на какого-то чувака из Флориды.

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

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

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

Всегда должна быть абстрактная develop и master ветка. Если develop - это глобальный репозитарий под наблюдением чувака из С-Ф, то master должен быть у вас в подвале - проверенный срез требующихся вам сервисов\данных\репозитариев.

С двух глав про data storage смеялся, автор почему-то поленился узнать немного об истории и современном состоянии дел.

Про registry тоже то ли врет, то ли ленился читать документацию

Какие зеркала? Тут нужно трёхкратное резервирование!

Вот что пишет: «Имейте по 3 инстанса всего на свете

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

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

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

Я читал статейку на хабре.

У себя решили что докер не нужен. Да и если будут нагрузки новый инстанс развернуть не долго.

Хотя и нагрузки маленькие.

что не отменяет того, что баги в обёртке, а технология одна и та же.

В общем, ESX с кучей готовых снапшотов и всё.

Какие зеркала? Тут нужно трёхкратное резервирование!

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

Это лол, но я про другое. Я про статичную инфраструктуру, не только докер-шмокер: в основном касается 3rdparty-реп, которые модно сейчас прямо с гитхаба тянуть.

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

С другой стороны Google в своём облачном хостинге на основе kubernetes запускает runtime-ы баз данных, а сами данные хранятся на отдельно стоящих сетевых ФС, которые монтируются в контейнер. Есть еще OpenShift, DigitalOcean, etc. Хотя, я, например, такой подход использую только для данных, которые потерять не страшно. Всё, что ценно на работе храним во внешних БД.

Похоже, сообщество пользователей Docker недооценивает угрозы зависимости на какого-то чувака из Флориды.

Сообщество пользователей докер в CentOS накладывает на пакет docker-а патч, который позволяет сконфигурировать server wide свой docker registry и не использовать внешний. И живет не парится.

Сообщество пользователей докера на Debian в моем несчастном лице, хардкодит внутренний registry во все configuration management конфиги.

докер и lxc контейнер

Последние несколько итераций Docker в них больше отличий, нежели общего.

OpenShift

Тот же Kubernetes под капотом, к слову.

Сообщество пользователей докер в CentOS накладывает на пакет docker-а патч, который позволяет сконфигурировать server wide свой docker registry и не использовать внешний.

А что там за нюансы с Docker в CentOS?

Я могу ошибаться, но дебианщики ж вроде решили, что докер не ок и своими силами его не пилят.

Зато docker решил наоборот и держит репу для debian.

http://www.projectatomic.io/blog/2016/08/docker-patches/

http://www.projectatomic.io/docs/docker_patches/

Спасибо за ссылки, кстати

Add-volume-support-to-docker-build.patch

Вот этот просто 11/10.

И для всего остального тоже: https://get.docker.com/

lsb_dist=''
	dist_version=''
	if command_exists lsb_release; then
		lsb_dist="$(lsb_release -si)"
	fi
	if [ -z "$lsb_dist" ] && [ -r /etc/lsb-release ]; then
		lsb_dist="$(. /etc/lsb-release && echo "$DISTRIB_ID")"
	fi
	if [ -z "$lsb_dist" ] && [ -r /etc/debian_version ]; then
		lsb_dist='debian'
	fi
	if [ -z "$lsb_dist" ] && [ -r /etc/fedora-release ]; then
		lsb_dist='fedora'
	fi
	if [ -z "$lsb_dist" ] && [ -r /etc/oracle-release ]; then
		lsb_dist='oracleserver'
	fi
	if [ -z "$lsb_dist" ] && [ -r /etc/centos-release ]; then
		lsb_dist='centos'
	fi
	if [ -z "$lsb_dist" ] && [ -r /etc/redhat-release ]; then
		lsb_dist='redhat'
	fi
	if [ -z "$lsb_dist" ] && [ -r /etc/os-release ]; then
		lsb_dist="$(. /etc/os-release && echo "$ID")"
	fi

Да, OpenShift это надстройка над Kubernetes со своей утилой управления. Я это к тому, что как минимум корпорация добра и красная шапочка в своих облачных хостингах базы в докере крутит.

Да, все именно так.

например?

Например то, что Docker уже пару лет как не использует lxc.

Общего у них - cgroups и namespaces, все.

Какое-то странное обобщение, как будто кривой Docker это все контейнеры.

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

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

катастрофичность проблемы.

катастрофичность и проблемы в головах тех кто основывает свою инфраструктуру на внешних ресурсах

накладывает на пакет docker-а патч, который позволяет сконфигурировать server wide свой docker registry и не использовать внешний.

патч ради того что делается конфигом?

И, кажется, это видео ещё не утратило актуальности. https://www.youtube.com/watch?v=PivpCKEiQOQ

А, то есть мне не показалось, а в Dockerfile вольюмы игнорируются?

А разница только в [...] фс из снапшотов

Вот поэтому и просадка по IO.

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

Патч создает возможность делать это конфигом.

У апстримного докера нет такой опции в конфиге вообще.

а --registry-mirror (registry-mirrors - в конфиге) это что?

это не оно

Вы их неправильно поняли. Вольюмы в докерфайле - это каталоги, под которые при запуске контейнера будет выделены отдельные вольюмы докера. На данный момент с точки зрения docker build они не играют никакой роли, просто галочка - вот это вынести в отдельный вольюм (их список можно посмотреть - docker volume ls). Как-либо взаимодействовать с текущей файловой системой docker build не умеет (кроме команд ADD и COPY). А вышеупомянутый патч позволяет на стадии docker build подмонтировать туда живую фс в ридонли-режиме, чего в апстриме на данный момент не реализовано.

а что это тогда?

сходи да почитай по ссылкам. Или тебе все разжевать надо?

https://github.com/moby/moby/pull/10411

сходи да почитай по ссылкам

зачем? эта опция позволяет указать репозиторий вместо дефолтного, все остальные указываются в имени имейджа, но ты вещаешь что это «не то», вот и рассказывай что «это не то»

зачем? эта опция позволяет указать репозиторий вместо дефолтного

затем что ты не понимаешь ни что делает registry-mirrors, ни что делает патч

Разжевываю:

registry-mirrors это зеркало дефолтного registry. Эта опция пересылает позволяет настроить скачивание образов с docker hub через кеширующий proxy.

https://docs.docker.com/registry/recipes/mirror/#gotcha

It’s currently not possible to mirror another private registry. Only the central Hub can be mirrored.

Патч https://github.com/moby/moby/pull/10411 - это полноценная поддержка управления docker registry по типу yum-репозиториев.

Позволяет искать образ во всех сконфигурированных репозиториях. Позволяет выключить Docker Hub в принципе и использовать только внутренние ресурсы и т.п.

затем что ты не понимаешь ни что делает registry-mirrors, ни что делает патч

не так, что делает registry-mirrors очевидно, не очевидно понять что ты хочешь такого (но теперь понятно).

Позволяет искать образ во всех сконфигурированных репозиториях.

это полезная штука, но это штука посторонняя для докера ибо они, не обупбликовали api поиска в репозитории, в итоге мы в своем инструменте реверсии апи поиска и городили просик по сторонним репозиториям «сбоку»

так что пока они не разродятся апи - это все костыли

Позволяет выключить Docker Hub в принципе

а это позволяет и registry-mirrors или просто перекрыть домен (он у них в сорцах зашит)