Comments 99
Ох, в общем как и на недавней конференции events.yandex.ru/events/yagosti/19-september-2015-linux, вы меня не убидили в нужности докера. Особенно если есть уже инфраструктура на OpenVZ/LXC.
В некоторых моментах пслд намного удобнее, например при работе с сетью. Проект Criu приносит свои плюшки. Можно сказать, что OpenVZ просто опоздал с такими модными плюшками как Docker Hub и DockerFile.
Если поднимать с 0, возможно удобно, если уже все готово — то просто модное веяние.
В некоторых моментах пслд намного удобнее, например при работе с сетью. Проект Criu приносит свои плюшки. Можно сказать, что OpenVZ просто опоздал с такими модными плюшками как Docker Hub и DockerFile.
Если поднимать с 0, возможно удобно, если уже все готово — то просто модное веяние.
Разница в том, что OpenVZ/LXC и их друзья — это для сисадминов, а docker и всякие kubernetes — для программистов/dev-ops.
В первом случае — оперируют понятием сервера, контейнера, в другом — архитектурой приложений, платформой для запуска приложений, то есть еще больше абстрагируются от физических серверов/систем.
То чем заняты админы openvz/lxc, в docker дается практически задаром, это как раньше админили физические серверы в серверной, настраивали каждый кто как мог, а сейчас — все автоматически, «в облаках».
В первом случае — оперируют понятием сервера, контейнера, в другом — архитектурой приложений, платформой для запуска приложений, то есть еще больше абстрагируются от физических серверов/систем.
То чем заняты админы openvz/lxc, в docker дается практически задаром, это как раньше админили физические серверы в серверной, настраивали каждый кто как мог, а сейчас — все автоматически, «в облаках».
Я бы с вами согласился, если бы докер мог использовать минимальное окружение для запуска приложения. По сути он так может и были тут уже статьи по минимальному докеру, но дается это тяжело.
еще раз, openvz/virtuozzo/odin просто опоздала к кормушки и теперь приходится просто дружить с докером и развивать другие фишки.
Сильно они опоздали и с открытием ядра итд итп.
еще раз, openvz/virtuozzo/odin просто опоздала к кормушки и теперь приходится просто дружить с докером и развивать другие фишки.
Сильно они опоздали и с открытием ядра итд итп.
> еще раз, openvz/virtuozzo/odin просто опоздала к кормушки и теперь приходится просто дружить с докером и развивать другие фишки. Сильно они опоздали и с открытием ядра итд итп.
А вот я не считаю, что они «просто» опоздали. Похоже, что если бы не докер, то хрен бы они почесались, чтобы сделать всем нам лучше. Хоть какая-то оживлённая конкуренция появилась. Веет от этой истории теми же мотивами, по которым Microsoft (как и любая другая — компания по выжиманию денег откуда только можно) открыла .NET и сделала полноценную шаровую версию Visual Studio (!). Никто не хочет умирать, когда можно жить и зарабатывать.
А вот я не считаю, что они «просто» опоздали. Похоже, что если бы не докер, то хрен бы они почесались, чтобы сделать всем нам лучше. Хоть какая-то оживлённая конкуренция появилась. Веет от этой истории теми же мотивами, по которым Microsoft (как и любая другая — компания по выжиманию денег откуда только можно) открыла .NET и сделала полноценную шаровую версию Visual Studio (!). Никто не хочет умирать, когда можно жить и зарабатывать.
Программисты абстрагируются-абстрагируются, абстрагируются-абстрагируются, а потом внезапно продакшен и со всем этим г-ном должны разбираться как раз сисадмины. А оно к продакшену не готово «как миллион пакетов в секунду через интерфейс пришло?» «а откуда столько зомби в системе?», а программистам пофигу, потому что у них объектное проектирование и проблемы негров их не волнуют, а они все д'Артаньяны с докером, а вокруг ужасные сисадмины со своим противным LXC, лучше докер, потому что «у меня на ноутбуке всё работает, как же оно может не работать на ферме из сотни серверов под нагрузкой?».
Ну и в финале «а как сделать так, чтобы данные из postgres не терялись при остановке контейнера?». В продакшене. Месяца через 4 после запуска.
Ну и в финале «а как сделать так, чтобы данные из postgres не терялись при остановке контейнера?». В продакшене. Месяца через 4 после запуска.
Или замечательные сисадмины создают новый голый виртуальный сервер (или несколько) для продакшена из своих заготовок, дают ужасным программистам рут доступ и говорят «как хотите так и обеспечивайте разворачивание и обновление среды исполнения, самого приложения и его баз, хоть по F5 в mc копируйте, только скажите можно ли снэпшоты снимать для бэкапов, а если нельзя, то расскажите как консистентные бэкапы делать».
Какие программисты — такие и проблемы. Если у человека не возникает вопроса о том, где хранятся файлы базы из контейнера, то это не проблема докера, так ведь?
Как раз для таких людей существует куча проектов, типа этого: github.com/sameersbn/docker-postgresql, там есть специальный раздел Persistence.
Простота использования, конечно, развращает, но это не значит, что нужно теперь пользоваться чем-то более замороченным, чтобы дисциплинировало. Нужно просто вопрос изучить. И когда он изучен, то при помощи современных сервисов можно сисадмина вообще исключить из цикла проектирования и поддержки инфраструктуры, во всяком случае до тех пор, пока она достаточно тривиальна.
Как раз для таких людей существует куча проектов, типа этого: github.com/sameersbn/docker-postgresql, там есть специальный раздел Persistence.
Простота использования, конечно, развращает, но это не значит, что нужно теперь пользоваться чем-то более замороченным, чтобы дисциплинировало. Нужно просто вопрос изучить. И когда он изучен, то при помощи современных сервисов можно сисадмина вообще исключить из цикла проектирования и поддержки инфраструктуры, во всяком случае до тех пор, пока она достаточно тривиальна.
Прежде всего вопрос «а где хранятся файлы базы» должен возникать у админа, чтобы хотя бы бэкапы делать.
Пока что из опыта (не очень большого)
— Нужно выкатить в продакшен вот это!
— А как тут…
— У нас сроки горят, нужно сейчас!
— Да, но ведь…
— Все согласовано и утверждено, ты хочешь сейчас все отметить, сорвать, убытки…
— …
И получается что через 4 месяца я сижу и думаю, как бы это все выкаченное хоть как-то привести в нормальный вид без простоев и ошибок
— Нужно выкатить в продакшен вот это!
— А как тут…
— У нас сроки горят, нужно сейчас!
— Да, но ведь…
— Все согласовано и утверждено, ты хочешь сейчас все отметить, сорвать, убытки…
— …
И получается что через 4 месяца я сижу и думаю, как бы это все выкаченное хоть как-то привести в нормальный вид без простоев и ошибок
А программисты как раз хорошие — им алгоритмы придумывать, а не вопросы персистентности данных решать.
Таким образом, продакшен из кода — это большей частью забота devops-админов и программистов, специализирующихся на software engineering. Но в этом случае devops админы хотят иметь нормальные среды выполнения и поменьше докеризмов.
Таким образом, продакшен из кода — это большей частью забота devops-админов и программистов, специализирующихся на software engineering. Но в этом случае devops админы хотят иметь нормальные среды выполнения и поменьше докеризмов.
Зачем вообще постгрес держать в контейнере? В чем глубинный смысл? Версию бд все-равно без танцев с бубном не обновить.
Потому что программистам всё нравится держать в докере, а если решения по деплою оказываются целиком у программистов, то на выходе мы получаем вот такое. Или даже хуже. (Я не на программистов гоню, просто это не совсем их работа).
Потомучто когда вы начнаете работать с контенерами это левел 0.
Левел 1 это конда вы отдате контейнер облаку и оно сомо знает где его запустить и к чему подвязать…
В контеэнрном облаке, нет других сущностей просто…
Левел 1 это конда вы отдате контейнер облаку и оно сомо знает где его запустить и к чему подвязать…
В контеэнрном облаке, нет других сущностей просто…
Ну и что минус. За грамматику? Блин пардон транслитом пишу...:(
Если у вас НЕ высоконагруженный сервис — вы конечно можете отдать весь low-level на откуп «контейнерному облаку».
Для высоких нагрузок и\или сложных сервисов вы ДОЛЖНЫ понимать, что там у этого облака внутри бегает и как оно взаимодействует. Как устроена сеть, как монтируются образы, куда уходят бэкапы, сколько ресурсов у вас реально получается на конкретной виртуалке, как работает балансер(ELB, например), что куда натится, etc. Не всегда вендоры дают эту информацию, но она всегда ценна и полезна.
А идея о том, что «отдать контейнер в облако — и пусть оно там все автоматом деплоится и конфигурится» — это пока утопия.
Для высоких нагрузок и\или сложных сервисов вы ДОЛЖНЫ понимать, что там у этого облака внутри бегает и как оно взаимодействует. Как устроена сеть, как монтируются образы, куда уходят бэкапы, сколько ресурсов у вас реально получается на конкретной виртуалке, как работает балансер(ELB, например), что куда натится, etc. Не всегда вендоры дают эту информацию, но она всегда ценна и полезна.
А идея о том, что «отдать контейнер в облако — и пусть оно там все автоматом деплоится и конфигурится» — это пока утопия.
Кто «мы» должны это понимать? Прикладные разработчики, системные администраторы, мифические девопс-инженеры?
Тот, кто отвечает за работу приложения в продуктивной среде.
Как эта роль называется в конкретной компании\команде — не суть важно.
Плох тот разработчик, который считает, что его дело — код писать, а как он дальше работает — не его забота.
Также плох и тот админ, который считает разработчиков идиотами и не в силах настроить коммуникацию с ними так, чтобы требования и нужды эксплуатации принимались во внимание.
Как эта роль называется в конкретной компании\команде — не суть важно.
Плох тот разработчик, который считает, что его дело — код писать, а как он дальше работает — не его забота.
Также плох и тот админ, который считает разработчиков идиотами и не в силах настроить коммуникацию с ними так, чтобы требования и нужды эксплуатации принимались во внимание.
На практике (да и в теории) это минимум две роли: админ не может отвечать за ошибки разработчика (например, синтаксические), а разработчик не может отвечать за ошибки админа (например, «планомерно» закончилось место на дисках).
По многолетнему опыту в средне-мелком бизнисе, как минимум один из них должен вникать в нюансы деятельности другого.
По многолетнему опыту в средне-мелком бизнисе, как минимум один из них должен вникать в нюансы деятельности другого.
Обозначьте теорию о котой пишите…
Еще раз в этом треде
habrahabr.ru/post/267441/?reply_to=8592751#comment_8591771
О DevOps не слышали?
Еще раз в этом треде
habrahabr.ru/post/267441/?reply_to=8592751#comment_8591771
О DevOps не слышали?
Например, общероссийские классификаторы должностей и занятий.
Слышали — где-то там в крупных ИТ-компаниях. Речь же о мелко-средних не ИТ-компаниях.
Слышали — где-то там в крупных ИТ-компаниях. Речь же о мелко-средних не ИТ-компаниях.
Культура DevOps не особо привязана к размеру компаний. Она больше привязана к Agile. И эта тематика скорее в мелких и средних компаниях на западе фрсируется… Большие (не считаем Гугл и Фейсбук — у них думаю все нормально) не дотепали по мнигим причинам…
У меня западный бекграунд в IT
У меня западный бекграунд в IT
Может у меня неправильное представление о DevOps, но как-то слабо представляю, что в средней компании человек на 300-500, среди которых айтишников человек пять, край — десять, будет пара людей, выделенных на техническое обслуживание процессов разработки и доставки.
Скорее всего не верное представление…
Дело не втом что кто-то выделено…
Первым делом это преодаление барьра между Опс и Дев который образовался из-за всех этих ролей в энтерпрайз деве…
Дело не в том что какие-то новые задачи… А в организации команд по решению этих задачь…
Тоесть если есть 10 айтишников то они не будут поделены функцонльно на команды Операйшнс/ Девелоперс/Тестерс.
А ориентированынно на Клиента, тоесть например:
Команда 1 (Продукт «електронный огурец»)
— 2 бывших бекэкнд кодера
— 1 бывший фрондэдшик
— 2 бывших админа…
— 1 бывший тестировщик…
-Команда 2 (Продукт «електронный огурец»)
Сервис «Все для клиента»
-3 бывших девелопера
-1 бывший админ
-1 продавец
-1 чувак разбирающийся в аналах домены.
Это не значит что фрондэщик начинает настраивать сеть постоянно… Но это может вполне означать что он начнет сам статический контент выкатывать и конфигурить лоадбэленсер к примеру…
И т.д. коммуникация совсем другая… И видимость… Вдруг выясняется что то что считал обязательным админ совершенно не интересно девелоперам и клиенту а и т.д. очень мощно может поменять Time To Market
Ведь заданиай не изменились и человеческие ресурсы не изменились…
Просто меняется их организация вокруг целей… а этим приоритеты и качество…
P.S. Комманда 2 — это уже может быть даже из Customer Oriented Development
Дело не втом что кто-то выделено…
Первым делом это преодаление барьра между Опс и Дев который образовался из-за всех этих ролей в энтерпрайз деве…
Дело не в том что какие-то новые задачи… А в организации команд по решению этих задачь…
Тоесть если есть 10 айтишников то они не будут поделены функцонльно на команды Операйшнс/ Девелоперс/Тестерс.
А ориентированынно на Клиента, тоесть например:
Команда 1 (Продукт «електронный огурец»)
— 2 бывших бекэкнд кодера
— 1 бывший фрондэдшик
— 2 бывших админа…
— 1 бывший тестировщик…
-Команда 2 (Продукт «електронный огурец»)
Сервис «Все для клиента»
-3 бывших девелопера
-1 бывший админ
-1 продавец
-1 чувак разбирающийся в аналах домены.
Это не значит что фрондэщик начинает настраивать сеть постоянно… Но это может вполне означать что он начнет сам статический контент выкатывать и конфигурить лоадбэленсер к примеру…
И т.д. коммуникация совсем другая… И видимость… Вдруг выясняется что то что считал обязательным админ совершенно не интересно девелоперам и клиенту а и т.д. очень мощно может поменять Time To Market
Ведь заданиай не изменились и человеческие ресурсы не изменились…
Просто меняется их организация вокруг целей… а этим приоритеты и качество…
P.S. Комманда 2 — это уже может быть даже из Customer Oriented Development
Мы на прошлой неделе решили полностью расформировать (по мне так уж давно) команду админов, они интгрируйтуся сейчас активно в Продакт-Команды…
Компашка 50 человек. Из них 25 ДевОпс-ников :) ).
Компашка 50 человек. Из них 25 ДевОпс-ников :) ).
Если у вас НЕ высоконагруженный сервис — вы конечно можете отдать весь low-level на откуп «контейнерному облаку».
Простите, но вы похоже не близки к теме просто…
Действительно высоконагруженые сервисы без облака нынче не мыслимы…
Контейнеры вам никак не мешают понимать что-то… ;)))
И да вам совершенно не нужно строить «сложные сервисы». Они ничем не оправданы. Очень похоже на Accidential complexity
А идея о том, что «отдать контейнер в облако — и пусть оно там все автоматом деплоится и конфигурится» — это пока утопия.
С чего вы это взяли? Бред же… Это уже давно стандарт ;)
Действительно высоконагруженые сервисы без облака нынче не мыслимы…
Если вы внимательно прочитаете мой коммент — вы не найдете противоречий со своим.
А идея о том, что «отдать контейнер в облако — и пусть оно там все автоматом деплоится и конфигурится» — это пока утопия.
С чего вы это взяли? Бред же… Это уже давно стандарт ;)
То есть вы отдаете свой контейнер, в котором запакован ваш код, в какое-то мифическое облако, а оно самостоятельно по очереди выключает воркеры из балансера, запускает новые контейнеры и добавляет их в балансер. Сами контейнеры находят внешние сервисы, которые обслуживают стейт(базы, кэша, whatever) и подключают приложения к этим базам.
Я все правильно понимаю?
То есть вы отдаете свой контейнер, в котором запакован ваш код, в какое-то мифическое облако, а оно самостоятельно по очереди выключает воркеры из балансера, запускает новые контейнеры и добавляет их в балансер. Сами контейнеры находят внешние сервисы, которые обслуживают стейт(базы, кэша, whatever) и подключают приложения к этим базам.
Я все правильно понимаю?
Именно! Точно так. ;)
И это вполне себе коммерческое облако и я тоже могу прийти со своим контейнером — и мне будет всё тоже самое?
Можете подсказать название этого облака?
Можете подсказать название этого облака?
Да любое… Если все в коробке то к примеру
cloud.google.com/container-engine
www.tutum.co
Но (ИМХО) пока лучше инвестировать немного самому…
Это несложно, но надо проникнутся…
Начать надо с распределенной конфиги и сервис-дискавери… В этом плане офигеннен Consul habrahabr.ru/post/266139
Если клауд не предлагает достаточный лоадбэленсер создате свой «умный» контейнер который слушает такие эвенты…
И т.д. В начале вам скедулер может и не нужен будет.
Но поидее лучше сразу делать… тут много вариантов… опенсорсных
Поидее github.com/kubernetes/kubernetes уже все что нужно интегрированно приносит с собой…
Но иногда имеет смысл итеративо посторить фичи
Вот тут была серия про эти дела к примеру
habrahabr.ru/post/262397
cloud.google.com/container-engine
www.tutum.co
Но (ИМХО) пока лучше инвестировать немного самому…
Это несложно, но надо проникнутся…
Начать надо с распределенной конфиги и сервис-дискавери… В этом плане офигеннен Consul habrahabr.ru/post/266139
Если клауд не предлагает достаточный лоадбэленсер создате свой «умный» контейнер который слушает такие эвенты…
И т.д. В начале вам скедулер может и не нужен будет.
Но поидее лучше сразу делать… тут много вариантов… опенсорсных
Поидее github.com/kubernetes/kubernetes уже все что нужно интегрированно приносит с собой…
Но иногда имеет смысл итеративо посторить фичи
Вот тут была серия про эти дела к примеру
habrahabr.ru/post/262397
Я вас к тому и веду. ВНЕЗАПНО выясняется, что для того, чтобы облако это умело — системным инженерам нужно позаботиться о паре _небольших_ вещей. Сервис дискавери, распределенные конфиги, автоматика переключения, автоматика деплоя, работа с лоад балансером, очередями. Репликация, бэкапы, отказоустойчивость на уровне датацентров.
Мне кажется, что это совсем _немного_ выходит за рамки заявленного «Отдать контейнер в облако и оно там все само», но все-таки выходит. Я вас по-прежнему не переубедил?
Мне кажется, что это совсем _немного_ выходит за рамки заявленного «Отдать контейнер в облако и оно там все само», но все-таки выходит. Я вас по-прежнему не переубедил?
«системным инженерам» у нас к примру роли такой нет ;)
Да не нужно вам ни очем заботится… Это же фетишь вы сами или ваша огранизация придумала. Это я вам проилюстрировал миграшн сценарий что-бы вы не выпускали ничего из рук если вам очень хочется… ;)
Берите Контейнер-Энжин Кибернетовскую и вперед… все из коробки ;)
cloud.google.com/container-engine
Да не нужно вам ни очем заботится… Это же фетишь вы сами или ваша огранизация придумала. Это я вам проилюстрировал миграшн сценарий что-бы вы не выпускали ничего из рук если вам очень хочется… ;)
Берите Контейнер-Энжин Кибернетовскую и вперед… все из коробки ;)
cloud.google.com/container-engine
Ну вот например настройка лоад-балансера в container-engine — https://cloud.google.com/container-engine/docs/tutorials/http-balancer.
Нет здесь сценария
Если лично вы не занимались настройкой этого облака под свои нужды — значит это было сделано до вас. Но было. Чудес не бывает. Были бы чудеса — мы бы могли избавиться от наших девопс и опс команд, которые обслуживают _тысячи_ хостов на AWS. Решая все те проблемы, которые, по вашему, из-коробки решаются с помощью докера. Удачи вам в вашем мире. Я пожалуй исключусь из дискуссии.
Нет здесь сценария
То есть вы отдаете свой контейнер, в котором запакован ваш код, в какое-то мифическое облако, а оно самостоятельно по очереди выключает воркеры из балансера, запускает новые контейнеры и добавляет их в балансер. Сами контейнеры находят внешние сервисы, которые обслуживают стейт(базы, кэша, whatever) и подключают приложения к этим базам.
Если лично вы не занимались настройкой этого облака под свои нужды — значит это было сделано до вас. Но было. Чудес не бывает. Были бы чудеса — мы бы могли избавиться от наших девопс и опс команд, которые обслуживают _тысячи_ хостов на AWS. Решая все те проблемы, которые, по вашему, из-коробки решаются с помощью докера. Удачи вам в вашем мире. Я пожалуй исключусь из дискуссии.
Что вас смущаесть что Лоадбэлэнсеру надо дать конфигу что бы он знал какие сервесы включать в лоадбеленсинг?
Аннотировать лейблами приритете сервицсов к ресусрасм типа ram, cpu, ssd, кастом?
Опишите ваш сценарий.
Аннотировать лейблами приритете сервицсов к ресусрасм типа ram, cpu, ssd, кастом?
Опишите ваш сценарий.
Да причем тут это вы каждый раз что-то новое вбрасываете к вашему начальному вопросу
Вы инициально спросили зачем в контенер пихать БД… Я вам обьяснил что это может вполне иметь смысл и обьясняется не только «модой» на докер.
То что Докер не панацея и так понятно.
Вы инициально спросили зачем в контенер пихать БД… Я вам обьяснил что это может вполне иметь смысл и обьясняется не только «модой» на докер.
То что Докер не панацея и так понятно.
Перенести на другой хост с минимумом танцев?
В случае с бд — минимум танцев — это реплика на другой хост с последующим переключением. Докер тут не нужен от слова «совсем».
Я использую докер для приложений. В них единственный стейт — это версия кода, который бежит внутри. Для этих целей докер — это хорошо. И то не всегда получается без танцев.
Попробуйте перевезти приложение в докере, которое всегда работало на сервере с 8 ядрами на сервер с 32 ядрами. Или с сервера без поддержки ip v6 на сервер с поддержкой. ВНЕЗАПНО выяснится, что докер не всегда обеспечивает желаемый уровень изоляции от хоста и по-прежнему от него во многом зависим.
Я использую докер для приложений. В них единственный стейт — это версия кода, который бежит внутри. Для этих целей докер — это хорошо. И то не всегда получается без танцев.
Попробуйте перевезти приложение в докере, которое всегда работало на сервере с 8 ядрами на сервер с 32 ядрами. Или с сервера без поддержки ip v6 на сервер с поддержкой. ВНЕЗАПНО выяснится, что докер не всегда обеспечивает желаемый уровень изоляции от хоста и по-прежнему от него во многом зависим.
Реальная практика — 50% запросов на реплику фэйловерятся на мастер из-за запаздывания больше 1 секунды — бизнес-требование. В случае падения сервера БД контейнеры (не важно по какой технологии) позволяют переключиться на новый инстанс на другой железке «одним кликом» или одним скриптом какого-нибудь заббикса, гарантируя (в разумных пределах) что клиенты не заметят переключения.
Слабо представляю проблемы, которые могут возникнуть при увеличении доступных физических ресурсов. Можно хоть пару примеров?
Ну да, абсолютной изоляции вроде никто не может обеспечить. Но кто обеспечивает лучшую за ту же цену?
Слабо представляю проблемы, которые могут возникнуть при увеличении доступных физических ресурсов. Можно хоть пару примеров?
Ну да, абсолютной изоляции вроде никто не может обеспечить. Но кто обеспечивает лучшую за ту же цену?
По-прежнему не понимаю, как у вас контейнеризация позволяет быстро менять железные хосты под бд. Но предположу.
Сами файлы находятся на внешнем сторадже, который монтируется в сервер и куда смотрит контейнер с субд. При падении сервера, этот же сторадж монтируется в другой сервер, где поднимается такой же контейнер — и все работает.
Если мое предположение верно — то ключом к успеху тут является внешний сторадж, а не контейнер.
Если я ошибаюсь — то поясните пожалуйста, интересно.
Два кейса из тестовой инфраструктуры:
Кейз один — приложение по-умолчанию запускается на всех физических ядрах, которое находит. Приложение тестируется на машинах с 8 ядрами, у разработчиков тоже всегда 8 ядер или меньше. Новый сервер, 32 ядра — приложение ведет себя не стабильно или не так, как ожидалось(оставим за скобками код, который так работает). Хотя казалось бы тот же образ, тот же код, тот же контейнер.
Кейз два — приложение всегда работало, не зная про ipv6. Докер работал на ядре, в котором этот механизм был отключен. Новое железо, про эту особенность никто не думал, ipv6 по-умолчанию включен. Сталкиваемся с проблемой резолвинга локалхоста — сначала резолвится ipv6 адрес, который приложение обрабатывать не умеет. А в Докере кстати нельзя убрать ipv6 адрес локалхоста из /etc/hosts, без грязных трюков и он там присутствует даже если у вас в sysctl стоит опция ipv6 all disable и в самом докере вы сказали --ipv6=False. Помогает только отключение на уровня ядра, при загрузке.
Я понимаю, что никто. Везде trade-off. Я вообще докер не ругаю, я его люблю с версии 0.5 или 0.6.
Но идеализировать технологию и все пихать в нее — это как-то странно. Всегда важно четко понимать, зачем тащить любую технологию в продакшн.
Сами файлы находятся на внешнем сторадже, который монтируется в сервер и куда смотрит контейнер с субд. При падении сервера, этот же сторадж монтируется в другой сервер, где поднимается такой же контейнер — и все работает.
Если мое предположение верно — то ключом к успеху тут является внешний сторадж, а не контейнер.
Если я ошибаюсь — то поясните пожалуйста, интересно.
Два кейса из тестовой инфраструктуры:
Кейз один — приложение по-умолчанию запускается на всех физических ядрах, которое находит. Приложение тестируется на машинах с 8 ядрами, у разработчиков тоже всегда 8 ядер или меньше. Новый сервер, 32 ядра — приложение ведет себя не стабильно или не так, как ожидалось(оставим за скобками код, который так работает). Хотя казалось бы тот же образ, тот же код, тот же контейнер.
Кейз два — приложение всегда работало, не зная про ipv6. Докер работал на ядре, в котором этот механизм был отключен. Новое железо, про эту особенность никто не думал, ipv6 по-умолчанию включен. Сталкиваемся с проблемой резолвинга локалхоста — сначала резолвится ipv6 адрес, который приложение обрабатывать не умеет. А в Докере кстати нельзя убрать ipv6 адрес локалхоста из /etc/hosts, без грязных трюков и он там присутствует даже если у вас в sysctl стоит опция ipv6 all disable и в самом докере вы сказали --ipv6=False. Помогает только отключение на уровня ядра, при загрузке.
Я понимаю, что никто. Везде trade-off. Я вообще докер не ругаю, я его люблю с версии 0.5 или 0.6.
Но идеализировать технологию и все пихать в нее — это как-то странно. Всегда важно четко понимать, зачем тащить любую технологию в продакшн.
Как уже отметили выше, Docker — инструмент разработки в первую очередь. Т.е. вместо инсталлятора/архива с приложением и длинной документацией по настройке и запуску, админ получает от разработчика уже полностью готовый к запуску образ. Этот образ можно сразу размещать на серверах и запускать. Т.е. это не средство управления ресурсами сервера, а средство поставки ПО.
И да, это не в коей мере не замена OpenVZ/LXC. Они могут даже сожительствовать в ряде случаев.
И да, это не в коей мере не замена OpenVZ/LXC. Они могут даже сожительствовать в ряде случаев.
Это все супер. Одного не могу понять, как это все обновлять?
Через Docker Hub. Докачиваются новые слои или обновленные, и готово.
А можно мне на примере?
Вот у меня есть три полноценных контейнера с php+php-fpm, mysql и rabbitmq + поверх этого живет нормальный железный сервер с nginx (фронт)
Если мне нужно это все поднять докером, и потом обновлять по мере необходимости.
Первоначальная настройка понятно — машина с php+php-fpm, mysql, rabbit, все настроили, пошли данные.
Mysql и rabbitmq мы не будем обновлять скорее всего никогда, там данные внутри. Они же потеряются при обновлении докер контейнера?
Обновление пхп — собрали образ, задеплоили в репозиторий, оттуда на хост.
Все верно?
Вот у меня есть три полноценных контейнера с php+php-fpm, mysql и rabbitmq + поверх этого живет нормальный железный сервер с nginx (фронт)
Если мне нужно это все поднять докером, и потом обновлять по мере необходимости.
Первоначальная настройка понятно — машина с php+php-fpm, mysql, rabbit, все настроили, пошли данные.
Mysql и rabbitmq мы не будем обновлять скорее всего никогда, там данные внутри. Они же потеряются при обновлении докер контейнера?
Обновление пхп — собрали образ, задеплоили в репозиторий, оттуда на хост.
Все верно?
Первоначальная настройка понятно — машина с php+php-fpm, mysql, rabbit, все настроили, пошли данные.
Mysql и rabbitmq мы не будем обновлять скорее всего никогда, там данные внутри. Они же потеряются при обновлении докер контейнера?
Не совсем, это будут отдельные контейнеры, и настройка будет скорее всего в самом образе контейнера, либо автоматически при первом запуске, то есть всё автоматизируется по максимуму.
Вот посмотрите как у меня сделано: github.com/nazar-pc/docker-webserver
Там только один data-only контейнер, остальные все stateless приложения, к которым подключается data-only контейнер чисто для данных. Скачиваете новые образы, и за несколько секунд перезапускаете всё с теми же данными, но более новыми версиями приложений.
Обновления PHP, MySQL/MariaDB и многих других можно вообще получить практически даром, в Docker Hub есть официальные образы, если вы наследуете свои образы от их образов — то с легкостью можно настроить триггеры, которые при обновлении официальных образов запустят сборку ваших. То есть вам останется только загрузить новый непосредственно у себя на сервере (что тоже можно автоматизировать).
Отличный репозиторий, многое прояснилось. Подскажите как зайти по ссш, пхпадмин? Как сменить пароли?
Там есть информация в readme.
Вкратце:
SSH — добавляете ключ как написано в readme, парольный вход отключен
PhpMyAdmin — пользователь root, пароль в /data/mysql/root_password, генерируется случайный при первом запуске.
Так что никаких паролей из коробки захардкоренных нет, все Dockerfile открыты, сборки образов автоматизированы и отражают состояние репозитория.
Вкратце:
SSH — добавляете ключ как написано в readme, парольный вход отключен
PhpMyAdmin — пользователь root, пароль в /data/mysql/root_password, генерируется случайный при первом запуске.
Так что никаких паролей из коробки захардкоренных нет, все Dockerfile открыты, сборки образов автоматизированы и отражают состояние репозитория.
А подразумевается, что это всё на одном хосте будет крутится? Я как раз в изучении докера на этом споткнулся — локально всё работает связно, а вот с деплоем хотя бы БД на отдельный хост непонятно как быть.
Посмотрите на flannel/weave — они реализуют оверлейную сеть. Насколько всё хорошо/плохо с производительностью — хз.
Flannel, например умеет как энкапсулировать в udp (т. е. трафик гонится через usespace), так и в vxlan (тогда в user space только control plane, а данные летят, как максимум в kernel space или вообще обрабатываются аппаратно, если сетевуха поддерживает).
Flannel, например умеет как энкапсулировать в udp (т. е. трафик гонится через usespace), так и в vxlan (тогда в user space только control plane, а данные летят, как максимум в kernel space или вообще обрабатываются аппаратно, если сетевуха поддерживает).
Есть Docker Swarm — с его помощью целый кластер машин с Docker выглядит как один Docker хост, а сами контейнеры запускаются там, где есть нужные ресурсы.
Есть flocker — это отдельный драйвер для томов Docker, поддерживает миграции и многие другие вещи.
В следующей версии зарелизится продвинутая сетевая подсистема, где тоже нативно и легко будут строиться оверлейные и сторонние сети как flocker для томов с данными, только для самой сети, пока система линков не настолько гибкая.
В целом всё очень неплохо, а инструментов появляется всё больше и больше.
Есть ещё kubernetes, но для меня он пока слишком замороченный, там более продвинутое управление квотами в рамках кластера.
Есть flocker — это отдельный драйвер для томов Docker, поддерживает миграции и многие другие вещи.
В следующей версии зарелизится продвинутая сетевая подсистема, где тоже нативно и легко будут строиться оверлейные и сторонние сети как flocker для томов с данными, только для самой сети, пока система линков не настолько гибкая.
В целом всё очень неплохо, а инструментов появляется всё больше и больше.
Есть ещё kubernetes, но для меня он пока слишком замороченный, там более продвинутое управление квотами в рамках кластера.
Берёте Dockerfile, меняеете версии зависимостей, пересобираете образ. Всё. Относительно mysql/rabbitmq — используйте специальные образы, которые хранят данные вне контейнера, в подключаемой директории хоста.
Через Docker Hub. Докачиваются новые слои или обновленные, и готово.Очень плохой совет. Нести в свой внутренний контур кучу левого софта, запускаемого с правами рута, — просто безумие. С безопасностью у докера всё не просто плохо: её нет. Никакой.
То говно, которое впилили для официальных образов — пшик.
Судя по тому, что обсуждается в registry api v2, возможно, станет получше. Ещё подробно не разглядывал. По первому впечатлению, appc и rkt повлиял на них сугубо положительно.
Что значит плохой совет лол. Это так работает докер. С безопастностью у него все отлично. Большинство контейнеров запускается без бинда на внешние порты, и общаться могут только с линкованными к ним контейнерами по этому этот рут внутри, как-то побоку. Если вы не способны обеспечить свою сеть безопастностью, итс ё фолл))
Контейнеры по умолчанию имеют доступ наружу. Через nat с docker0, если что.
Не говоря уже о том, что namespaces пока активно развиваются c ~2008 года и уязвимостей в ядре может быть выше крыши (на некоторые баги в ядре, касающиеся netns я уже нарывался на centos6 и centos7).
Ещё забавно, большое количество контейнеров, требующих прокидывание /var/run/docker.sock внутрь контейнера, что, очевидно, даёт права на запуск любых контейнеров.
Не говоря уже о том, что namespaces пока активно развиваются c ~2008 года и уязвимостей в ядре может быть выше крыши (на некоторые баги в ядре, касающиеся netns я уже нарывался на centos6 и centos7).
Ещё забавно, большое количество контейнеров, требующих прокидывание /var/run/docker.sock внутрь контейнера, что, очевидно, даёт права на запуск любых контейнеров.
Ещё, о птичках: CVE-2015-3629:
Libcontainer 1.6.0, as used in Docker Engine, allows local users to escape containerization («mount namespace breakout») and write to arbitrary file on the host system via a symlink attack in an image when respawning a container.
Разработчика тыкать палочкой. Это не для продуктов. Это для бессрочных проектов с штатом.
Можно сделать свой собственный dockerhub и поддерживать обновление. Это несомненно плюс.
В OpenVz есть механизм забора image, но его надо допиливать руками.
В OpenVz есть механизм забора image, но его надо допиливать руками.
>Т.е. вместо инсталлятора/архива с приложением и длинной документацией по настройке и запуску, админ получает от разработчика уже >полностью готовый к запуску образ.
В OPenvz/lxc неожиданно образы.
>Этот образ можно сразу размещать на серверах и запускать. Т.е. это не средство управления ресурсами сервера, а средство поставки ПО.
Ну не сразу, надо поставить docker.
Собсвтенно после установки openvz, вы так же можете сразу использовать контейнер с вашим ПО.
Да бы не схватить кучу минусов, я не имею ничего против докера. Наоборот это хорошо и отлично, что он поднял много шума вокруг виртуализации и вообще в тренде. Я реально хочу понять, как оно в моем случаи поможет жить?
DockerHUB? я не использую публичные вещи, я старпер и все передпочитаю делать руками сам. Я не знаю, что и кто там приготовил в image.
DockerFile? Отлично, я это все так же решаю ansible/chef/puppet.
Единственный плюс, это свежие ядро и все в ядре в отличие от openvz. Но можно смотреть и на LXC, правда с урезанным функционалом.
То, что openvz может в себе запускать докер через костыли, прекрасно.
В OPenvz/lxc неожиданно образы.
>Этот образ можно сразу размещать на серверах и запускать. Т.е. это не средство управления ресурсами сервера, а средство поставки ПО.
Ну не сразу, надо поставить docker.
Собсвтенно после установки openvz, вы так же можете сразу использовать контейнер с вашим ПО.
Да бы не схватить кучу минусов, я не имею ничего против докера. Наоборот это хорошо и отлично, что он поднял много шума вокруг виртуализации и вообще в тренде. Я реально хочу понять, как оно в моем случаи поможет жить?
DockerHUB? я не использую публичные вещи, я старпер и все передпочитаю делать руками сам. Я не знаю, что и кто там приготовил в image.
DockerFile? Отлично, я это все так же решаю ansible/chef/puppet.
Единственный плюс, это свежие ядро и все в ядре в отличие от openvz. Но можно смотреть и на LXC, правда с урезанным функционалом.
То, что openvz может в себе запускать докер через костыли, прекрасно.
UFO just landed and posted this here
Возможно вам сюда
Ну что-ж значит за вас можно порадоваться. А нам не хватило. По этой причине вынуждены искать более гибкие решения. Вот сейчас пытаемся приспособить докер и он нам пока нравится гораздо больше.
В подробности вдаваться нет необходимости, т.к. всё очень похоже на то, что было озвучено в докладе, ссылку на который привёл чуть ниже.
В подробности вдаваться нет необходимости, т.к. всё очень похоже на то, что было озвучено в докладе, ссылку на который привёл чуть ниже.
Я с нетерпением жду стабилизации appc+rkt. Товарищи из CoreOS сразу пошли от проблем докера, которые вскрылись в процессе его эксплуатации. И они, конечно, положительно влияют на docker наличием реальной и ощутимой конкуренции. Не в обиду openvz, но у docker'а в плане UX для разработчика всё куда приятнее.
Это да. Если речь идёт об исключительно админских задачах (установка и настройка стороннего софта), то разницу сложно так просто заметить. Но если нужно разрабатывать и поставлять собственный продукт, особенно на большое количество целевых серверов, то OpenVZ — это даже не смешно…
У нас тех поддержка уже на 20 клиентах начала потихоньку захлёбываться, а это только начало. Так что сейчас стараемся поскорее разобраться с докером. Да он не без недостатков. Но, всё же, гораздо удобнее под наши задачи.
У нас тех поддержка уже на 20 клиентах начала потихоньку захлёбываться, а это только начало. Так что сейчас стараемся поскорее разобраться с докером. Да он не без недостатков. Но, всё же, гораздо удобнее под наши задачи.
А этот образ кроме того, как запускаться, ещё и работать нормально умеет?
А что имеете в виду под «нормально»?
Полный список будет весьма значительным, но если утрировать, то на уровне того, что получается после apt-get install и настройки для обычного софта из состава дистрибутива.
Грубо говоря, сам образ и есть указание на официальный образ дистрибутива (типа partner-images.canonical.com/core/trusty/current/ubuntu-trusty-core-cloudimg-amd64-root.tar.gz), последовательности apt-get (или make ) исполняемых после его разворачивания, и указаний дефолтных точек входа и выхода — томов, портов и т. п.
Или вы про саму libcontainer и его обвязку?
В любом случае, конечно, будут новые баги по сравнению с официальным дистрибутивом развернутым на голом железе, но вот если сравнивать с другими технологиями виртуализации, то их количество должно быть одного порядка.
Или вы про саму libcontainer и его обвязку?
В любом случае, конечно, будут новые баги по сравнению с официальным дистрибутивом развернутым на голом железе, но вот если сравнивать с другими технологиями виртуализации, то их количество должно быть одного порядка.
Тут есть один маленький, но очень неганивный нюанс, часто девелоперы думают что они знают как должно работать на уровне системы то или иное, но на самом деле это совсем не так, в результате к контейнеру, который пришел от разрабов доверенности у хорошего админа должно быть чуть менее чем 0, поэтому выкатывать в продакшен что-то что пришло от разрабов в готовом контейнере я бы не рискнул никогда. Без обид, но практика показывает что это правда.
Ну практика вообще очень разнообразная вещь.
У нас получается так, что полной и исчерпывающей компетенции нету ни у тех ни у других. Кто-то знает одно, кто-то другое. И нужно обеспечить возможность, чтобы каждый мог крутить свои ручки.
И ещё: если между админами и разработчиками не налажен диалог, то тогда не спасёт вообще ничего. Всегда нужно согласовывать свои действия. А если попытаться свалить ответственность за всю настройку на кого-то одного, то получается ерунда.
У нас получается так, что полной и исчерпывающей компетенции нету ни у тех ни у других. Кто-то знает одно, кто-то другое. И нужно обеспечить возможность, чтобы каждый мог крутить свои ручки.
И ещё: если между админами и разработчиками не налажен диалог, то тогда не спасёт вообще ничего. Всегда нужно согласовывать свои действия. А если попытаться свалить ответственность за всю настройку на кого-то одного, то получается ерунда.
Я не совсем об этом, коммуникации это хорошо, но вот разрабы передают контейнер, в нем есть какое-то ПО, это ПО это не обязательное веб-проект на пхп, это может быть томкат, где гарантия что в нем все верно настроено? Это может быть не веб вообще, а еще это ПО может зависить от системных настроек(ядро, лимиты и т.п.), т.е. в принципе какая бы хорошая коммуникация не была, но в продакшен выкатывать проект от людей, которые не понимают бОльшей части нюансов не стоит.
В тоже время контейнеры на стендах и в разработке должны быть очень хороши.
Мне, например, контейнеры сильно помогли в сборках deb пакетов, если надо убедиться что пакет ставится со всеми нужными зависимостями на голую ОС, то это идеальный вариант, просто запускаешь Dockerfile, правишь пакет и запускаешь снова, быстро и просто.
С другой стороны можно некоторые вещи делать наоборот, например админ собирает контейнер с системой, содержащей нужные настройки и передает разрабам, а они свой проект запускают уже внутри. при таком раскладе они будут тестировать ПО в окружении идентичному боевому.
В тоже время контейнеры на стендах и в разработке должны быть очень хороши.
Мне, например, контейнеры сильно помогли в сборках deb пакетов, если надо убедиться что пакет ставится со всеми нужными зависимостями на голую ОС, то это идеальный вариант, просто запускаешь Dockerfile, правишь пакет и запускаешь снова, быстро и просто.
С другой стороны можно некоторые вещи делать наоборот, например админ собирает контейнер с системой, содержащей нужные настройки и передает разрабам, а они свой проект запускают уже внутри. при таком раскладе они будут тестировать ПО в окружении идентичному боевому.
С другой стороны можно некоторые вещи делать наоборот, например админ собирает контейнер с системой, содержащей нужные настройки и передает разрабам, а они свой проект запускают уже внутри. при таком раскладе они будут тестировать ПО в окружении идентичному боевому.
Во-о-от! А если ещё вспомнить про то, что докер может наследовать одни образы от других. То и получается следующая картина:
- Админы делают правильный базовый образ ОС
- Разрабы поверх этого добавляют приложение с минимально необходимыми настройками (В нашем случае: WildFly8 + каталоги с шаблонами + JMS очереди + Infinispan кэши + и т.д.). Можно даже многое параметризировать, по договорённости с админами
- Поверх минимального приложения амины делают итоговую настройку. Как правило уже под конкретное клиентское внедрение
Каждый делает свою работу. И всем хорошо.
Уж не знаю, вы это были или нет, но с кем-то я соглашался на этой встрече по поводу мыслей о докере, что все хорошо в меру :)
То же ядро, память, файловая система, а дистрибутивы, библиотеки и пользователи — разные.
А с чего вы взяли что пользователи разные?
В каждом контейнере свои /etc/passwd и /etc/group. Ну и права все локальны для контейнера.
Ну и что с того, что там свой /etc/passwd? username содержащийся в /etc/passwd не более чем алиас к uid'у (аналогично и с группами), и username никак не участвует в пермишенах, для этого используется исключительно uid.
Создайте в хост-системе пользователя foo c uid'ом 42, внутри контейнера создайте пользователя bar с таким же uid'ом и запустите из под него какой-либо процесс, затем в хост системе посмотрите список процессов, вы удивитесь, но с точки зрения хост-системы процесс будет запущен под пользователем foo.
А расскажите про хранение файлов. Везде пишут — что они должны удаляться после остановки контейнера (и нужно создавать общую папку с хостом). Но я чекнул, создал файл, стопнул, стартанул — все на месте.
При остановке контейнера данные не стираются. При полном удалении (а это вам нужно например, чтобы софт обновить) они теряются. Поэтому те файлы и каталоги, которые должны не теряться, надо при запуске контейнера монтировать с хост-системы как volumes.
При удалении, не остановке. Почитайте про data-only контейнеры и volumes, там есть некоторые нюансы, так же в документации вполне не плохо об этом написано.
К тому же в новых версиях Docker есть драйвера файловых систем, то есть можно делать распределённое хранение данных да и вообще много чего в этом роде.
К тому же в новых версиях Docker есть драйвера файловых систем, то есть можно делать распределённое хранение данных да и вообще много чего в этом роде.
Я наткнулся на то что docker stop, осталяет данные; docker kill — убивает, если сделать docker commit, то docker kill уже не испортит данные.
Но правильнее поднимать контейнер без изменяемых данных, т.е. все что изменяется по уму маунтить из хост-системы.
Но правильнее поднимать контейнер без изменяемых данных, т.е. все что изменяется по уму маунтить из хост-системы.
Разница между docker stop и docker kill только в том, что stop посылает сначала SIGTERM, а потом SIGKILL (если процесс не остановился за указанное время), а kill сразу посылает SIGKILL. С данными это вообще никак не связано.
Очень понравился весь абзац включая заголовок
Хотелось бы детальнее эту тему проработать?
Вы где-то наткнулись на это? Есть источник на английском? Или сами так придумали?
Docker — это инструмент объекто-ориентированного проектирования
Хотелось бы детальнее эту тему проработать?
Вы где-то наткнулись на это? Есть источник на английском? Или сами так придумали?
Если вкратце, у Docker несколько драйверов для работы с файловой системой, обычно это AUFS, и все файлы контейнеров лежат в /var/lib/docker/aufs/diff/. В /var/lib/docker/containers/ служебная информация, а не сами файлы контейнеров.Давно не используется по умолчанию. Используется devicemapper + lvm thin pool.
Вообще по бэкендам хранилища у меня впечатления смешанные:
— dm — иногда не удаляет какие-то куски, имеет неприятное свойство постепенно раздуваться без возможности вернуть место (т. к. использует sparse файлы);
— dm с выделенными разделами под данные и мета — аналогично предыдущему, только не на loop-девайсах, а на реальных дисках;
— btrfs — имеет свойство внезапно заканчиваться место (особенно, если не прочитать заранее, как она обслуживается);
— overlayfs с ядра 3.18 (бэкпортированно 3.10 в centos7) — на docker 1.7 выглядит дико нестабильно, оверлеи не всегда отмонтируются корректно и т. п.
Сейчас использую btrfs, хотя и несколько опасаюсь. Стандартные volumes не использую, только bind. Прошло чуть меньше года, всё работает нормально, но btrfs требует периодического обслуживания.
Контейнеры исполняются механизмом ядра под названием Cgroups. Служба docker запускает контейнер по команде, полученной от клиентского приложения (например, docker), и останавливает его когда в контейнере освобождается поток стандартного ввода-вывода.Процесс в контейнере исполняется, как любой другой процесс в linux. Другое дело, что для контейнера создаются нужные namespaces (netns, utsname, pid, ipc), а также создаются и конфигурируются контрольные группы (cgroups), которые ограничивают потребление ресурсов, управляют шедулингом и т. п.
Соответственно, Docker может и зависнуть. Если вы дали команду скачать образ, единственный способ прервать процесс скачивания — перезапустить службу. Авторы уже давно обсуждают что с этим делать, но воз и ныне там.После нажатия ctrl+c у вас отваливается клиент к докеру, т. к. словил SIGHUP. Образ продолжает качаться. И, если вы пытаетесь запустить docker pull того же образа повторно, то он будет висеть в ожидании, пока сервер не скачает этот образ по команде, полученной при предыдущем запуске docker pull.
Был на нескольких митапах Гугла, по теме их Google Cloud Platform. Так вот они говорят, что у них давно все только на контейнерах работает и настаивают на том, что Kubernetes это все, что нужно.
По большому счету идея не новая, но хорошо, что buzz расходится и все больше компаний используют технологии контейнеров.
По большому счету идея не новая, но хорошо, что buzz расходится и все больше компаний используют технологии контейнеров.
Sign up to leave a comment.
Мифы и рецепты Docker