Комментарии 245
Докер работает только в Линуксе (и уже в винде, не?)
С оговорками, через клиентскую прослойку к виртуальной машине в VirtualBox.
Кстати, nginx нормально из коробки не заработал, какой-то баг с sendfile и виртуальной машиной.
Как раз в Линуксе он работает без прослоек.
У меня nginx заработал из коробки, и даже с
У меня nginx заработал из коробки, и даже с
sendfile on;. У вас какая операционка/виртуалка? Радует то, что деньки фразочки «а на моей машине всё работает» уже сочтены ;) 
Радует то, что деньки фразочки «а на моей машине всё работает» уже сочтены ;)
С учетом, что докер это всего лишь изоляция процессов, а не виртуализация, то явно не сочтены.
Автор комментария скорее всего комментировал ваше "и уже в винде, не?". В общем, повторю — docker-daemon для Windows нет и не уверен будет ли вообще (хотя какая-то партнёрская программа у них с Microsoft наладилась уже давненько, может и пилят что-то под капотом), вот что сделали для Windows, так это собрали клиент docker-cli (aka docker), так что просто из Windows можно управлять удалёнными docker-daemon'ами (ну и docker-swarm'ами).
Я себе слабо представляю ситуацию с контейнерами в виндоусе. Если есть здесь кто-то, кто ждет докер-демон под виндоус, как я ждал его под линукс, расскажите, пожалуйста, зачем он вам?
Ждал я их, чтобы разворачивать обычные линуксовые образы под виндой. Но, судя по всему то, что "пилят что-то под капотом", будет, как и в линуксе, оберткой над ядром, а значит разворачивать на виндовых серверах линуксовые образы не получится, только контейнеры чисто под винду либо платформонезависимые (дата волумы, например)
То есть вы ожидали появления возможности запуска ELF исполняемых файлов на винде без виртуалок да ещё и сразу в контейнерах с контролем ресурсов? Line (по аналогии с Wine)? Грандиозная идея :)
Типа того :) Мысль такая не самому в голову пришла, меня убеждали что в вин2016 нативная поддержка докера.
ну дык она там и есть, уже доступна в превью, только вся суть контейнеров в том, что процессы в нем на ядре хоста исполняются, а тут само собой понятно, какие это дает ограничения
Ну, я примерно из этих соображений говорил "не может быть, что контейнер от убынты на винде нативно запустится", а меня убеждали в обратном.
Ну вообще, линукс на венде запускают.
Вообще, я в курсе. И даже, как это сейчас называется, пуш-реквестил куда-то куда-то откуда-то.
Вот думал что МС что-то из подобных проектов развила, когда меня убедили наши админы, что, как минимум, официальные образы нашего основного стека поднимутся. По сути не соврали почти — условный "LAMP" можно уже нативно поднять в докере под виндой… Но как-то осадочек остался — если "вдруг" у нас примут решение, что девелоперы должны будут поддерживать винду, то придётся искать варианты...
Вот думал что МС что-то из подобных проектов развила, когда меня убедили наши админы, что, как минимум, официальные образы нашего основного стека поднимутся. По сути не соврали почти — условный "LAMP" можно уже нативно поднять в докере под виндой… Но как-то осадочек остался — если "вдруг" у нас примут решение, что девелоперы должны будут поддерживать винду, то придётся искать варианты...
colinux, к сожалению, мертв.
Там давно есть свой App-V, а контейнеры с управлением через docker включат в Windows Server 2016.
Пока кто-то ждёт, кто-то уже пользуется)
1) https://ru.wikipedia.org/wiki/VMware_ThinApp
2) http://www.cameyo.com/
Хотя с nix конечно рядом не стояло...
1) https://ru.wikipedia.org/wiki/VMware_ThinApp
2) http://www.cameyo.com/
Хотя с nix конечно рядом не стояло...
Все верно, коммент был о Windows-хосте.
И кстати, на локальной машине запускать докер не вижу смысла для себя, так как для пущей изоляции и приближенности к продакшену использую
docker-machine всегда. 
Расскажите, пожалуйста, где всё-таки Вами хранятся сгенерированные образы: к примеру, Вы поднимаете какой-то микросервис на рубине, делаете образ на основе образа из Docker Hub.
Что дальше, куда складывать? Туда же идут обновлённые каждый день в процессе разработки новые версии?
Что дальше, куда складывать? Туда же идут обновлённые каждый день в процессе разработки новые версии?
либо пушить в тот же docker hub (за денежку есть приватные репозитории) либо поднять свой docker-distribution. Помимо docker hub есть еще сервисы.
Грубо говоря docker build && docker push
Грубо говоря docker build && docker push
Добавлю, что во время разработки запуск образов происходит локально, их не нужно никуда заливать, всё происходит внутри машины с докером.
Ну собственно прямая аналогия с git/hg. Пушим только если хотим поделиться с другими.
Я про docker-distribution, который объединяет машины разработчиков и сервера.
Спасибо, теперь чуть понятнее.
Спасибо, теперь чуть понятнее.
Персонально я не использовал еще docker-distribution ни для чего.
который объединяет машины разработчиков и сервера.
Это просто репозиторий образов. Я использую его для своих проектов (потому что docker hub немного дорогова-то для меня выходит, у меня только 6 проектов на докере а количество репозиториев уже подходит к полусотне, что же будет через пару месяцев).
Как мне рассказали после презентации МС, Докер работает нативно на Винде уже, но со своими образами. То есть ставим в Докерфайле что-то вроде FROM Windows7, и далее виндовой консолью рулим.
Понравилась статья, хотелось бы что-то более приближенное к разработке увидеть в следующих статьях.
Пробовал работать в нем, но как-то забросил,написал .sh установочный файл, который устанавливает все программы, прописывает нужное в конфигах и запускает.
Можно задать несколько вопросов:
Один контейнер — одна задача?
Т.е. есть контейнер с БД (mongoDB, MySQL, etc.), контейнер с Nginx, контейнер с данными (PureFTPd, ProFTPd, etc.)?
Каким образом я смогу соединяться с БД из контейнера с данными? В конфигах Nginx, какой будет root папка (получается она из другого контейнера)?
Когда я отправлю на Docker Hub проект, то получается если был контейнер с БД, то данные тоже отправится и при запуске на другой машине уже всё будет готово и БД и все файлы?
Пробовал работать в нем, но как-то забросил,
Можно задать несколько вопросов:
Один контейнер — одна задача?
Т.е. есть контейнер с БД (mongoDB, MySQL, etc.), контейнер с Nginx, контейнер с данными (PureFTPd, ProFTPd, etc.)?
Каким образом я смогу соединяться с БД из контейнера с данными? В конфигах Nginx, какой будет root папка (получается она из другого контейнера)?
Когда я отправлю на Docker Hub проект, то получается если был контейнер с БД, то данные тоже отправится и при запуске на другой машине уже всё будет готово и БД и все файлы?
НЛО прилетело и опубликовало эту надпись здесь
Один контейнер — одна задача?
Да. Но это лучше будет рассмотреть в отдельной статье про микросервисы. Докер, как платформа позволяет запускать несколько задач в контейнере, но лучше пересесть на микросервисы.
Т.е. есть контейнер с БД, контейнер с Nginx, контейнер с данными?
Да. Но для данных желательно использовать именованный volume, который подключается к двум контейнерам для расшаривания данных между ними.
Каким образом я смогу соединяться с БД из контейнера с данными?
Лучше никаким не связываться. Пусть пускает в себя по FTP и больше ничего не умеет. А данные кладет в volume.
В конфигах Nginx, какой будет root папка (получается она из другого контейнера)?
Да, папка будет из другого контейнера, или, лучше, из именованного volume.
Когда я отправлю на Docker Hub проект, то получается если был контейнер с БД, то данные тоже отправится и при запуске на другой машине уже всё будет готово и БД и все файлы?
Данные не принято хранить в контейнерах. Они должны храниться за пределами контейнеров. И мы опять говорим о микросервисах. Это прекрасно, значит быть второй статье.
Но можно и запихнуть файлы базы данных в контейнер, например, для быстрого разворачивания тестового окружения и спроса изменений простым перезапуском.
Да. Но это лучше будет рассмотреть в отдельной статье про микросервисы. Докер, как платформа позволяет запускать несколько задач в контейнере, но лучше пересесть на микросервисы.
А аргументы Phusion в пользу использования baseimage-docker еще актуальны в последних версиях Docker? Вообще, целесообразно ли его использовать? В сообществе Docker, на первый взгляд, никто его не использует.
Данные не принято хранить в контейнерах. Они должны храниться за пределами контейнеров.
А в чем проблема использовать Data Volume Containers? Реально интересно, так как на этот счет какие-то полярные мнения в сообществе Docker'а.
P.S. Статью про микросервисы было бы очень интересно почитать
А в чем проблема использовать Data Volume Containers?
Да, собственно, ни в чём. Главное, данные не в них хранить, а использовать их лишь как единый интерфейс к данным, хранящимся на хосте, на сетевой шаре, где угодно ещё.
Ну так вся суть Data Volume Container'а же в том, что данные храним именно в нем (главное, не удалять этот контейнер). Если мы используем папку на хосте, то какой тогда вообще смысл в отдельном контейнере для этого? Плюс, в случае папки на хосте, мы привязываем сервис работы с данными к определенному хосту Swarm-кластера и вынуждены настраивать этот хост особым образом.
с версии 1.9 data-only контейнеры не нужны. Все фиксится named volumes. Там же добавили драйвера для волумов, так что можно в качестве оного подключить распределенную файловую систему например.
Ну в документации Докера как раз написано про Data-Only Containers как один из вариантов. Я читал про
--volume-driver, который позволяет использовать, например, Flocker. А что именно поменялось с 1.9 в этом плане? Реально интересно, ибо сам еще новичок в Docker (и DevOps вообще), и хотя активно отслеживаю эту тему — не всегда понятно, какой из доступных опций лучше воспользоваться.Документация чуть отстала от реальности, потому я обычно отслеживаю изменения через github ишусы.
Поменялось то что теперь можно создать волум отдельно от контейнера, и мэпить его. Это невилирует необходимость держать контейнер-пустышку как промежуточное звено. Там же вся соль была в том, что волумы закрепляются за конкретными инстансами контейнеров, по хэшу. А сами волумы имен не имели. Вот это и поправили.
Поменялось то что теперь можно создать волум отдельно от контейнера, и мэпить его. Это невилирует необходимость держать контейнер-пустышку как промежуточное звено. Там же вся соль была в том, что волумы закрепляются за конкретными инстансами контейнеров, по хэшу. А сами волумы имен не имели. Вот это и поправили.
Ага, я тоже смотрю CHANGELOG, но как-то пропустил этот момент. В документации об этом прямо совсем вскользь крупица информации и дальше большой кусок про "Data Volume Containers".
А в чем получается практическое отличие named volume (с local-драйвером) от, собственно, от bind-mount папки хоста напрямую?
А в чем получается практическое отличие named volume (с local-драйвером) от, собственно, от bind-mount папки хоста напрямую?
Если мы используем папку на хосте, то какой тогда вообще смысл в отдельном контейнере для этого?
Чтобы обычные ("кодовые") контейнеры запускались чисто, без привязки к хосту, а править конкретное место хранения можно было только в одном месте, что особенно полезно, когда данные шарятся между несколькими контейнерами.
Дописал про baseimage-docker в конец статьи. Спасибо за хороший вопрос, совсем забыл, что сам начинал изучать докер с их критической статьи :)
Предположим на секунду, что нас немного волнует безопасность… в том смысле, что злоумышленник не должен получить доступ ко всем этим микросервисам и их базам данных. Сейчас у нас пяток серверов с Hardened Gentoo, на каждом, скажем, пара десятков микросервисов. И примерно раз в сутки эти сервера обновляются (а когда случается какой-нить shellshock или heartbleed — то и несколько раз в сутки).
Теперь мы решили перенести все эти микросервисы в докер. Они все разные, написаны на разных языках, используют разные библиотеки, etc. — так что получаем мы по отдельному образу на каждый микросервис, т.е., скажем, десятков пять образов. Выкатываем их на сервера и радуемся жизни… примерно часов 10.
А потом наступает новый день и возникает необходимость обновить базовый образ Hardened Gentoo лежащий в основе всех образов микросервисов. Плюс обновить те дополнительные библиотеки и приложения, которые были доустановлены поверх базового образа в образах разных микросервисов — причём в разных образах они, естественно, будут немного отличаться, так что в /etc разных образов придётся обновлять разные конфиги, и делать это немного по-разному. И вместо обновления 5-ти примерно одинаковых (вынужденно одинаковых, разумеется) серверов внезапно нужно пересобрать 50 разных (ведь в этом суть докера — каждому приложению дать уникальную для него среду выполнения!) образов. Кому-то только что конкретно прибавилось работы.
И, в качестве вишенки на торте, после того как пересобрали все образы — перезапустить все контейнеры, ведь это единственный способ "доставить" сегодняшнее обновление системы. При этом надо отметить, что когда обновляется, например, openssl, то мы, конечно, перезапускаем все процессы куда она подгружена… но, как правило, после ежедневного обновления системы перезапускать вообще ничего не требуется, или достаточно перезапустить один сервис. И далеко не все микросервисы безболезненно можно перезапускать — кто-то долго стартует, кто-то теряет разогретые кеши, кто-то закрывает сокеты миллиона подключенных юзеров и все эти юзеры начинают судорожно переподключаться создавая этим всплеск нагрузки на пустом месте…
А приложение продолжает развиваться, и вот у нас уже не 7 серверов вместо 5-ти, а 100 образов вместо 50-ти… Хотя, вру. У нас уже давно обратно 7 серверов, а докер используется только для разработки и тестирования, где безопасность никого не волнует.
И это я ещё оставил за кадром вопрос небезопасности самого докера — а ведь это сервис, который работает под root, активно меняет настройки всей системы (так что бессмысленно даже пытаться SeLinux-ом или другой RBAC обрезать его права до необходимого минимума как принято делать для всех остальных рутовых сервисов), доступен по сети и из контейнеров, и при этом очень активно допиливается (в отличие от большинства других рутовых сервисов).
Теперь мы решили перенести все эти микросервисы в докер. Они все разные, написаны на разных языках, используют разные библиотеки, etc. — так что получаем мы по отдельному образу на каждый микросервис, т.е., скажем, десятков пять образов. Выкатываем их на сервера и радуемся жизни… примерно часов 10.
А потом наступает новый день и возникает необходимость обновить базовый образ Hardened Gentoo лежащий в основе всех образов микросервисов. Плюс обновить те дополнительные библиотеки и приложения, которые были доустановлены поверх базового образа в образах разных микросервисов — причём в разных образах они, естественно, будут немного отличаться, так что в /etc разных образов придётся обновлять разные конфиги, и делать это немного по-разному. И вместо обновления 5-ти примерно одинаковых (вынужденно одинаковых, разумеется) серверов внезапно нужно пересобрать 50 разных (ведь в этом суть докера — каждому приложению дать уникальную для него среду выполнения!) образов. Кому-то только что конкретно прибавилось работы.
И, в качестве вишенки на торте, после того как пересобрали все образы — перезапустить все контейнеры, ведь это единственный способ "доставить" сегодняшнее обновление системы. При этом надо отметить, что когда обновляется, например, openssl, то мы, конечно, перезапускаем все процессы куда она подгружена… но, как правило, после ежедневного обновления системы перезапускать вообще ничего не требуется, или достаточно перезапустить один сервис. И далеко не все микросервисы безболезненно можно перезапускать — кто-то долго стартует, кто-то теряет разогретые кеши, кто-то закрывает сокеты миллиона подключенных юзеров и все эти юзеры начинают судорожно переподключаться создавая этим всплеск нагрузки на пустом месте…
А приложение продолжает развиваться, и вот у нас уже не 7 серверов вместо 5-ти, а 100 образов вместо 50-ти… Хотя, вру. У нас уже давно обратно 7 серверов, а докер используется только для разработки и тестирования, где безопасность никого не волнует.
И это я ещё оставил за кадром вопрос небезопасности самого докера — а ведь это сервис, который работает под root, активно меняет настройки всей системы (так что бессмысленно даже пытаться SeLinux-ом или другой RBAC обрезать его права до необходимого минимума как принято делать для всех остальных рутовых сервисов), доступен по сети и из контейнеров, и при этом очень активно допиливается (в отличие от большинства других рутовых сервисов).
Что-то у вас тёплое с мягким сравнивается и делается вывод об упругости...
Давайте начнём с развёртывания (почему-то вы начали за безопасность, но я вообще не понял как вы её там подразумевали). Docker образы состояти из слоёв, если у вас есть 25 приложений на Python и 25 приложений на Java, то вам нужен 1 образ базовой системы (лично я предпочитаю Alpine Linux — 5Мб), поверх этого образа будут установлены слои для Python, общие для 25 приложений на Python, и отдельная ветка будет идти с Java окружением, а дальше будут создаваться уже слои с приложениями. Таким образом, если обновилось только 1 приложение, и его образ обновится, то серверу при обновлении нужно будет скачать всего-навсего слои с самим приложением. Подведём итог в цифрах, пусть базовая система будет Alpine Linux — 5Мб, Python слои — 50Мб, Java слои — 160Мб, а каждое приложение будет занимать по 20Мб. При обновлении одного приложения вам нужно будет пересобрать слои самого приложения и серверу нужно будет скачать 20Мб (даже меньше из-за того что слои хранятся архивами), при обновлении Python нужно пересобирать 25 образов —
Да, сама идея root-демона, который занимается неизвестно чем — не самая приятная для осознания. Однако, стоит отметить, что вы лукавите здесь, говоря, что он доступен по сети и из контейнеров. По умолчанию, docker-daemon использует UNIX-сокеты, так что доступен он только локальным пользователям у которых есть права на доступ к сокету (обычно нужно находиться в группе docker).
Давайте начнём с развёртывания (почему-то вы начали за безопасность, но я вообще не понял как вы её там подразумевали). Docker образы состояти из слоёв, если у вас есть 25 приложений на Python и 25 приложений на Java, то вам нужен 1 образ базовой системы (лично я предпочитаю Alpine Linux — 5Мб), поверх этого образа будут установлены слои для Python, общие для 25 приложений на Python, и отдельная ветка будет идти с Java окружением, а дальше будут создаваться уже слои с приложениями. Таким образом, если обновилось только 1 приложение, и его образ обновится, то серверу при обновлении нужно будет скачать всего-навсего слои с самим приложением. Подведём итог в цифрах, пусть базовая система будет Alpine Linux — 5Мб, Python слои — 50Мб, Java слои — 160Мб, а каждое приложение будет занимать по 20Мб. При обновлении одного приложения вам нужно будет пересобрать слои самого приложения и серверу нужно будет скачать 20Мб (даже меньше из-за того что слои хранятся архивами), при обновлении Python нужно пересобирать 25 образов —
50Мб + 20Мб * 25, при обновлении Java — 160Мб + 20Мб * 25, а при обновлении базового образа, да все обзразы нужно пересобрать — 5Мб + (50Мб + 20Мб * 25) + (160Мб + 20Мб * 25), но если хотите заморочиться и вы хотите сделать отдельный случай "обновления системы" без полной пересборки, когда вы знаете, что пересборка не нужна (ну, например, обновилась только динамическая библиотека), то можно такие патчи наклвадывать сверху приложений, тогда при обновлении libopenssl.so серверам нужно будет скачать слой с новой openssl.so, добавленной последним слоем в каждый образ, 50 раз.И это я ещё оставил за кадром вопрос небезопасности самого докера — а ведь это сервис, который работает под root, активно меняет настройки всей системы (так что бессмысленно даже пытаться SeLinux-ом или другой RBAC обрезать его права до необходимого минимума как принято делать для всех остальных рутовых сервисов), доступен по сети и из контейнеров, и при этом очень активно допиливается (в отличие от большинства других рутовых сервисов).
Да, сама идея root-демона, который занимается неизвестно чем — не самая приятная для осознания. Однако, стоит отметить, что вы лукавите здесь, говоря, что он доступен по сети и из контейнеров. По умолчанию, docker-daemon использует UNIX-сокеты, так что доступен он только локальным пользователям у которых есть права на доступ к сокету (обычно нужно находиться в группе docker).
Мне кажется, что powerman говорил о проблемах безопасности базовой ОС. Как вот в glibc недавно обнаружилась. И чтобы закрыть эту уязвимость нужно обновить каждый контейнер, вместо обновления одной базовой ОС на сервере.
НЛО прилетело и опубликовало эту надпись здесь
Что-то в докере за последний месяц изменилось и контейнеры подхватывают изменения базового образа на лету? Или вы неудачно выразились, имея в виду, что нужно ручками (или коммит-хуком) пересобрать все образы и рестартовать все контейнеры?
НЛО прилетело и опубликовало эту надпись здесь
Дело не в том, возможно это или нет, а в том что во всех хвалебных статьях о простоте установки говорят, а о обновлениях — нет.
При этом, я так в манах и не нашел, как запустить рекурсивную пересборку всех установленных контейнеров.
Короче, для развертывания среды разработки, для всяких тулчейнов докер хорош, но для серьезного энтерпрайза с требованиями к безопасности — нет.
Пруфы: http://www.securitylab.ru/news/473082.php. И это было через много месяцев после шеллшока.
Что делать вручную? Запускать обновление системы одной командой?
При этом, я так в манах и не нашел, как запустить рекурсивную пересборку всех установленных контейнеров.
Короче, для развертывания среды разработки, для всяких тулчейнов докер хорош, но для серьезного энтерпрайза с требованиями к безопасности — нет.
Пруфы: http://www.securitylab.ru/news/473082.php. И это было через много месяцев после шеллшока.
Конечно нужно пересобирать все контейнеры, но это проще, чем все делать вручную при каждом обновлении
Что делать вручную? Запускать обновление системы одной командой?
НЛО прилетело и опубликовало эту надпись здесь
Это вовсе не так, ответил там же чуть ниже.
Чуть выше написано, что уязвимости не в одном баше, а и в glibс и прочих системных библиотеках. И питон, и джава — всё glibс использует, и все от этой уязвимости становится дырявым
НЛО прилетело и опубликовало эту надпись здесь
Мы говорим не о простоте, а о безопасности. Самый простой путь — это вообще забить на безопасность, да.
НЛО прилетело и опубликовало эту надпись здесь
Да везде! Я хотел ttrss в docker. Что нужно? LEMP. Отлично. Берем:
Согласен, docker hub — классная тема. Но пока в docker'е не допилят разграничения прав — это будет ад.
- nginx
- mysql
- php-fpm
- php-cli (для крона/демона обновлений)
- app (ro-вольюм — собственно, сам ttrss с конфигами ко всему этому счастью)
- storage (бд+нагенеренное приложением)
ничего не потерял?
Расчехляем docker-compose… И офигеваем! - nginx — худо-бедно настроил, завёл… Э, а где мой привычный пользователь www-data?
- mysql — mysql от root'а? Окей.. .
- php-fpm
- php-cli
- app — КТО СЛОМАЛ chown?!
Вобщем, нафиг. После такого я пошел расчехлять свой любимый LXC.
Согласен, docker hub — классная тема. Но пока в docker'е не допилят разграничения прав — это будет ад.
вы же понимаете что root в контейнере это не тот же рут что и на хосте? Да и контейнеры можно поднимать от имени пользователя.
Какая разница? У меня не сервер компрометируют, а приложение. Я и без того уже перехожу на LXC, но Docker мне пока жутко неудобен, как с точки зрения устоявшихся процессов и правил так и с точки зрения сборки.
Я 2 недели пытался завернуть ttrss в Docker так как это положено делать, обломился. На LXC я получил всё за полтора часа.
Я 2 недели пытался завернуть ttrss в Docker так как это положено делать, обломился. На LXC я получил всё за полтора часа.
вместо того что бы 2 недели что-то эдакое делать, можно было бы глянуть, может кто-то за нас уже все сделал.
Ну так инструмент тут непричем. Просто вы пока не увидели преимуществ лично для вас. И если кроме вас никого больше нет — то может и не надо ничего выдумывать.
пока жутко неудобен, как с точки зрения устоявшихся процессов и правил так и с точки зрения сборки.
Ну так инструмент тут непричем. Просто вы пока не увидели преимуществ лично для вас. И если кроме вас никого больше нет — то может и не надо ничего выдумывать.
… запилив всё в один контейнер с supervisor'ом, да, что идет в разрез с идеей "один контейнер = один процесс".
В таком виде как это сделано там, лучше уж взять любой другой способ виртуализации.
В таком виде как это сделано там, лучше уж взять любой другой способ виртуализации.
другой способ виртуализации.
docker — не способ виртуализации. Ну и если вам хочется именно тру вэй — то вот. Опять же не понимаю что там надо было делать 2 недели.
один контейнер = один процесс
Не так. Один контейнер = одна обязанность. Далеко не всегда это означает один процесс, есть множество кейсов когда это неудобно (shared memory например надо организовать между процессами).
Еще раз: механизмы, предлагаемые Docker'ом не предусматривают запуск более чем одного приложения в контейнере. Если у вас в контейнере, например, php-fpm, то Docker управляет только master'ом. Docker+supervisor = костыль.
В концепции
гораздо лучше себя показывает LXC. Да, он дороже по ресурсам, немного сложнее и так далее, но! Он тоже позволяет без проблем выстроить нужное окружение и деплоить только приложение, монтируя хранилище с данными.
В концепции
контейнер = одна обязанность
гораздо лучше себя показывает LXC. Да, он дороже по ресурсам, немного сложнее и так далее, но! Он тоже позволяет без проблем выстроить нужное окружение и деплоить только приложение, монтируя хранилище с данными.
shared memory например надо организовать между процессами
Пожалуйста, mmap'ите файл из общего volume'а и получаете shared memory между контейнерами (сори за засилие англицизмов).
LXC это немного не то. Докер же нас хочет приучить к микросервисам со всеми вытекающими удобствами и неудобствами.
Я ещё относительно недавно тоже думал "Э, а где мой привычный пользователь www-data". А потом понял, что это просто дело привычки. Которая, кстати, часто заставляла идти на нарушение безопасности, когда админы говорили, что мои желания иметь для тупого nginx-fpm-приложения минимум три пользователя — ничем не обоснованный гемморой, а достаточного только www-data...
Да признайте уже что человек прав и Докер — не серебряная пуля )
Пруфы: http://www.securitylab.ru/news/473082.php. И это было через много месяцев после шеллшока.
Не забывайте, что там исследуются ВСЕ образы. Вообще все. Следовательно и старые в которых нет обновлений.
Посмотрите на это с другой стороны. Благодаря докеру можно проверить на известные уязвимости все (или только свои) образы разом.
Отличная статья, спасибо.
вы начали за безопасность, но я вообще не понял как вы её там подразумевалиБезопасность подразумевает необходимость ежедневных обновлений пакетов ОС, из-за чего почти каждый день необходимо будет пересобирать как базовый образ, так и часть образов с приложениями (если они содержат какие-то дополнительные пакеты ОС помимо самого микросервиса).
Ну и ещё она подразумевает использование hardened gcc (с PIE, SSP, …) для сборки пакетов ОС, что прямого отношения к докеру не имеет, но необходимость при обновлениях компилировать пакеты из исходников может сильно замедлить пересборку всех образов по сравнению с такой же компиляцией для упоминавшихся мной обычных серверов (потому что, как я опять же упоминал выше, сервера вынужденно стараются держать одинаковыми, поэтому на них одинаковый набор USE-флагов — в Gentoo они определяют настройки опциональных фич/зависимостей пакетов, как правило это задаёт параметры передаваемые в `./configure` — т.е. можно скомпилировать пакет один раз на build-сервере и быстро установить на все сервера как бинарный пакет, а в докере продвигается идея специализированных окружений для каждого приложения, так что набор USE-флагов может и как-бы даже должен отличаться, что приведёт к необходимости компилировать один пакет несколько раз в разных конфигурациях. (Кстати, может кто-то знает, уже появились не source-based дистрибутивы в которых все пакеты собраны hardened gcc? Когда я последний раз этим интересовался в некоторых дистрибутивах так собирали 20-30% пакетов, не больше.)
Да, сама идея root-демона, который занимается неизвестно чем — не самая приятная для осознания.Беда не столько в том, что он занимается неизвестно чем, сколько в том, что он делает слишком много всего. Обычно ту часть кода, которая работает с полными root-правами стараются вынести отдельно и держать там самый минимум кода. А докер это бинарник на 25+ MB в котором с root-правами работает всё, включая Go runtime.
Однако, стоит отметить, что вы лукавите здесь, говоря, что он доступен по сети и из контейнеров. По умолчанию, docker-daemon использует UNIX-сокеты, так что доступен он только локальным пользователямЛукавите здесь Вы. Да, по умолчанию всё именно так. Но я в своём комментарии отвечал на конкретную статью, где автор рассказывал как докер радостно создаёт сети между датацентрами так, что контейнеры этого даже не замечают, и управляет всем этим хозяйством с одной машины — через какие конкретно UNIX-сокеты, по-вашему, всё это может работать?
Безопасность подразумевает необходимость ежедневных обновлений пакетов ОС, из-за чего почти каждый день необходимо будет пересобирать как базовый образ, так и часть образов с приложениями (если они содержат какие-то дополнительные пакеты ОС помимо самого микросервиса).Поэтому я и выступаю за использование Alpine образа в качестве базового — там всего 4 пакета, которые обновляются достаточно редко (уж никак не каждый день). Однако, musl libc приносит как свои плюсы, так и свои грабли… Я не вникал в hardened gcc, но пакеты в Alpine Linux собраны с stack-smashing protection.
В общем, если у вас уже есть отлаженная схема, то я не вижу смысла её ломать просто для того чтобы ввернуть где-нибудь Docker. Однако, я уже год гоняю в продакшене 15 образов основанных на Alpine Linux, суммарным объёмом в 4ГБ и как-то вопрос пересборки меня вообще никогда не напрягал (да, Rust и Haskell из исходников пересобираются долго, но этим занятием занимается машина и не больше одного раза в неделю, так что для меня это не является критичным процессом, да и то, когда появятся пакеты в Alpine Linux — жизнь станет веселее). Ну и использую я возможности ограничений ресурсов Docker контейнеров на полную, так что без Docker я бы даже, наверно, не приступил бы ещё к написанию этого проекта, а застрял бы в дебрях LXC.
Лукавите здесь Вы. Да, по умолчанию всё именно так. Но я в своём комментарии отвечал на конкретную статью, где автор рассказывал как докер радостно создаёт сети между датацентрами так, что контейнеры этого даже не замечают, и управляет всем этим хозяйством с одной машины — через какие конкретно UNIX-сокеты, по-вашему, всё это может работать?Да, можно открыть доступ к Docker демону по сети, да, там можно настроить псевдобезопасность, и, наконец, ДА, мне это совершенно не нравится! Тут действительно можно долго познавать глубину дыры. Однако, есть другой подход — агенты, крутящиеся на сервере с Docker-daemon'ами, которые поднимают свою VPN до мастер ноды и общаются с локальными Docker-daemon'ами через UNIX-socket. Так делает как минимум Rancher и есть у меня подозрения, что так же (ну может без VPN) делают и Kubernetes, и Fleet, ну и остальные здравые люди.
Ну и использую я возможности ограничений ресурсов Docker контейнеров на полную, так что без Docker я бы даже, наверно, не приступил бы ещё к написанию этого проекта, а застрял бы в дебрях LXC.Возможно, вас заинтересуют механизмы systemd для ограничений всего.
Это конечно прикольно, но у докера плюшек побольше будет, и изоляция окружения это далеко не самая главная как по мне. И не стоит забывать про docker-swarm и т.д. То что все это можно сделать и без докера — это факт. Просто с ним проще, и небольшая команда сможет намного быстрее скейлиться и удобнее поддерживать инфраструктуру.
Да, я читал, пожалуй, все ваши статьи. В моём случае я использую всего 1 сервис, который можно было бы действительно в systemd запихнуть, но основной функционал заключается в запуске потенциально опасного кода в песочнице, для чего я и искользую Docker для запуска процессов без доступа к сети, с read-only FS, с ограничениями памяти и ресурсов ядра, а также CPU shares.
1) С версии 1.10 можно докер в юзерспейсе запустить…
http://162.242.237.67/docker-blog/2016/02/docker-engine-1-10-security/
2) Я не уверен что правильно понята идея Контейнеров+микросервисов
«Hardened Gentoo лежащий в основе всех образов микросервисов.» зачем?
Реально если ваше приложение распилино нормально на сервисы которые предоставляют наружу четко ограниченое АПИ (например порт 80) то какай вам разница бежит ваш сервис внутри контейнера на Hardened Gentoo или альпине? Какая потенциальная угроза?
Какраз докер минимизирует угрозу, так как изолирует как минимум логически вашу апликуху на сервисы которые специфичны…
Например в моем случае вообще побарабану что за версия openssl.
Её там просто нет… она там не нужна… Она нужна один раз на уровни виртуалки… также там нет обычно ничего друго-го критического молжноидаже баш убрать
Тоесь и обновлять постоянно ничего не надо, достаточно нормального цикла разработки совершенно, все критическое в основном на самой виртуалке.
Наверно найдутся конечно контейнеры которые должны быть особо защиещены но тогда дайти им правильный базовый имидж, отелите их от остльного дерева…
Помоему надуманная проблемность… И да докер не панацея… Докер отлицно подходит под архитектуры основаны на микросервисах, и отлично подходит в динамическую инфраструктуру.
Но потенциал докера не реализуется если не подумать обо всем, например о среде в которй будут запускаться контейнры…
http://162.242.237.67/docker-blog/2016/02/docker-engine-1-10-security/
2) Я не уверен что правильно понята идея Контейнеров+микросервисов
«Hardened Gentoo лежащий в основе всех образов микросервисов.» зачем?
Реально если ваше приложение распилино нормально на сервисы которые предоставляют наружу четко ограниченое АПИ (например порт 80) то какай вам разница бежит ваш сервис внутри контейнера на Hardened Gentoo или альпине? Какая потенциальная угроза?
Какраз докер минимизирует угрозу, так как изолирует как минимум логически вашу апликуху на сервисы которые специфичны…
Например в моем случае вообще побарабану что за версия openssl.
Её там просто нет… она там не нужна… Она нужна один раз на уровни виртуалки… также там нет обычно ничего друго-го критического молжноидаже баш убрать
Тоесь и обновлять постоянно ничего не надо, достаточно нормального цикла разработки совершенно, все критическое в основном на самой виртуалке.
Наверно найдутся конечно контейнеры которые должны быть особо защиещены но тогда дайти им правильный базовый имидж, отелите их от остльного дерева…
Помоему надуманная проблемность… И да докер не панацея… Докер отлицно подходит под архитектуры основаны на микросервисах, и отлично подходит в динамическую инфраструктуру.
Но потенциал докера не реализуется если не подумать обо всем, например о среде в которй будут запускаться контейнры…
Реально если ваше приложение распилино нормально на сервисы которые предоставляют наружу четко ограниченое АПИ (например порт 80) то какай вам разница бежит ваш сервис внутри контейнера на Hardened Gentoo или альпине? Какая потенциальная угроза?А в чём, по-вашему, разница между обычным сервером где стоит один такой сервис и контейнером докера? В том, что на сервере есть ещё и SSH? Так конкретно SSH никогда не была большой проблемой в плане безопасности, и всё, что делается в Hardened Gentoo — делается вовсе не ради защиты sshd. Или Вы считаете что сервера, на которых только SSH и один сервис с сетевым API, не имеют проблем с безопасностью и не нуждаются в регулярных обновлениях?
Любой сервис, который смотрит в сеть и принимает пользовательский ввод — можно пытаться ломать подсовывая ему не тот ввод, который он ожидает. А сломав его и оказавшись «всего лишь» внутри контейнера — злоумышленник внезапно получает доступ ко всему, к чему есть доступ у взломанного сервиса: базам данных, виртуальной сети связывающей его с другими контейнерами, и возможно даже к управлению самим докером (если им управлять из обычного контейнера, как упоминалось в статье).
Да, в контейнерах может не быть openssl и bash — но, скажите честно, много Вы видели базовых контейнеров без bash? И любой микросервис на питоне может, внезапно, часть своих фич реализовывать запуская конвейеры внешних утилит, т.е. тот же bash и shellshock для него будут актуальны на все 100%. А что касается openssl, то в неё напихали слишком много всего помимо самого SSL, поэтому любой микросервис который пользуется, например, хеш-функциями или AES для реализации каких-нибудь JSON Web Token или миллиона других мелких вспомогательных задач не связанных с его основной функциональностью — внезапно обычно оказывается слинкован с libcrypto.so из openssl.
НЛО прилетело и опубликовало эту надпись здесь
Это отличная новость, но никак не решение всех упомянутых проблем с безопасностью. На самом деле основная проблема с регулярными обновлениями — скорее концептуальная, а docker daemon работающий под root — техническая, причём из серии "выведи козу".
CONFIG_USER_NS (aka User Namespaces) на данный момент представляет собой одну большую дыру. В Debian/Ubuntu эту дыру решили тестировать на пользователях и каждый месяц теперь у нас CVE благоаря этой чудной штуке. В Arch Linux, например, отложили включение этой опции ядра пока дебианщики не закончат тестирование в боевых условиях.
Ну да… все эти риски понятны.
1) хакнуть баговый сервис смотрящий в сеть конечно возможно. Это не проблема докера в принципе и не достоинство это ортогональная проблема… И в 99% случает криворукие программеры вашей конторы…
Тоесть чинится релизом и деплоэмнеотм одного контейнера.
2) Вы только что описали приимущества дополнительной изоляци между контенерами.
Да проникнув в контейнер (да еще по вине сторонней библиотеки, не преспроисив себя зачем она там и точно нужна..) теоритически можно получить доступ ко всему что видит контейнер.
Но это все еще меньше чем сценарий проникновения в монилит, в которм злоумышленик увидит все.
Технологий контейнеров не избавит конечно от проблем и то что вы говорите валидно… Контейнеры без микросервисной архитектуры ИМХО достаточно бесполезны…
Но если её использовать, то можна даже увеличить безопасноть. Локализировать наиболле уязвимые сервисы или те что занимаются наиболее трепетными данными… И занятся в плотнуе их бзопасностью…
Что даже не зависимо ото контейнеров хороший паттерн и даст безопасноти больше, чем параноидальная слежка за последней версией баш на всех компах… — это.
Безопасность это комплексная проблема а не прсто пару паттернов… привычек или евристик. Она начинается с заказа, проходит через архитектуру и заканчивается конечно админами с их актуальными версиями…
По поводу имиджей, если параноить, вполне видел где-то в сети как чуваки терли все из базового имиджа… Я лично этим не занимаюсь, в моем юскейсе это лишние усилия, мои сервисы изолированы друг от друга очень основательно…
Да риск есть что в яве найдут такие баги, что кто-то то через http rest получит доступ в контейнере… (сложно представимо) но теоритически, я срочно кинусь апдейтить яву… ок.
Дыра в bash? Ок, через недельку буду развивать свой сервис пропатчу и bash а пока она никак не касается моего сервиса ибо bash не задействован.
Именно так, взвешивать и понимать риски… Разделение сситемы на сервисы помогает какраз выделить те блоки которые в опасности и не трогать остальные
1) хакнуть баговый сервис смотрящий в сеть конечно возможно. Это не проблема докера в принципе и не достоинство это ортогональная проблема… И в 99% случает криворукие программеры вашей конторы…
Тоесть чинится релизом и деплоэмнеотм одного контейнера.
2) Вы только что описали приимущества дополнительной изоляци между контенерами.
Да проникнув в контейнер (да еще по вине сторонней библиотеки, не преспроисив себя зачем она там и точно нужна..) теоритически можно получить доступ ко всему что видит контейнер.
Но это все еще меньше чем сценарий проникновения в монилит, в которм злоумышленик увидит все.
Технологий контейнеров не избавит конечно от проблем и то что вы говорите валидно… Контейнеры без микросервисной архитектуры ИМХО достаточно бесполезны…
Но если её использовать, то можна даже увеличить безопасноть. Локализировать наиболле уязвимые сервисы или те что занимаются наиболее трепетными данными… И занятся в плотнуе их бзопасностью…
Что даже не зависимо ото контейнеров хороший паттерн и даст безопасноти больше, чем параноидальная слежка за последней версией баш на всех компах… — это.
Безопасность это комплексная проблема а не прсто пару паттернов… привычек или евристик. Она начинается с заказа, проходит через архитектуру и заканчивается конечно админами с их актуальными версиями…
По поводу имиджей, если параноить, вполне видел где-то в сети как чуваки терли все из базового имиджа… Я лично этим не занимаюсь, в моем юскейсе это лишние усилия, мои сервисы изолированы друг от друга очень основательно…
Да риск есть что в яве найдут такие баги, что кто-то то через http rest получит доступ в контейнере… (сложно представимо) но теоритически, я срочно кинусь апдейтить яву… ок.
Дыра в bash? Ок, через недельку буду развивать свой сервис пропатчу и bash а пока она никак не касается моего сервиса ибо bash не задействован.
Именно так, взвешивать и понимать риски… Разделение сситемы на сервисы помогает какраз выделить те блоки которые в опасности и не трогать остальные
Пересборка контейнера — это запуск docker build. Обновление тысяч контейнеров по всему парку машин можно сделать одной командой, если использовать систему для оркестрации типа Kubernetes. Вы не делаете перезапуск вручную — вместо этого система автоматически в нужной последовательности: 1. запустит новый контейнер, 2. убедится, что он успешно поднялся, 3. добавит его в кластер, т.е. направит на него трафик, 4. снимет трафик с старого контейнера, 5. убьёт его. Перезапуск машин (для обновления ядра, например) делается совершенно аналогично — запускаются новые копии всех контейнеров, которые работают на машине, где-нибудь в другом месте; трафик направляется на новую машину, снимается со старой, машина перезапускается и возвращается в строй обратно.
Насколько я знаю, сейчас в коде ядра сам по себе рут практически не даёт никаких привилегий — всё настраивается через capabilities. Рут, который в докере, именно что урезанный, без capabilities. Т.е. UID 0 даёт возможность любой файл читать (из доступных в контейнере), открывать любые порты (но только на виртуальном интерфейсе, который в контейнере есть), но ни обратиться к устройствам, ни сделать ещё какую пакость, он не может.
Насколько я знаю, сейчас в коде ядра сам по себе рут практически не даёт никаких привилегий — всё настраивается через capabilities. Рут, который в докере, именно что урезанный, без capabilities. Т.е. UID 0 даёт возможность любой файл читать (из доступных в контейнере), открывать любые порты (но только на виртуальном интерфейсе, который в контейнере есть), но ни обратиться к устройствам, ни сделать ещё какую пакость, он не может.
Пересборка контейнера — это запуск docker build.Формально — да. Но в контексте ответа на мой комментарий пересборка контейнера подразумевает обновление установленного в нём софта, правку конфигов, разрешение конфликтов — в общем, всё то, что обычно делается при обновлении сервера. Простым запуском docker build тут обычно не обойдёшься.
Вы не делаете перезапуск вручнуюЯ тоже этим восхищён, но описанная мной проблема перезапуска не в том, что его нужно делать вручную, а в том, что многие сервисы достаточно нетривиальны, и их перезапуск — штука достаточно дорогостоящая (в плане ресурсов, производительности, etc.) чтобы делать его без веской причины каждый день.
Рут, который в докере, …… меня никогда особо и не волновал, так что не совсем понятно, к чему Вы это описали. Проблема попадания злоумышленника внутрь контейнера не в том, что он там будет root, а в том, что он получит доступ к тому (базы/сети), к чему есть доступ у работающего в контейнере сервиса.
пересборка контейнера подразумевает обновление установленного в нём софта, правку конфигов, разрешение конфликтов
Так точно. У вас базовый образ может быть ваша безопасная ОС, в Dockerfile пишется ADD /ваш/уникальный/конфиг, и запуск docker build на основе свежей версии ОС добавит тот же самый конфиг и соберёт новый образ. Понятно, что при обновлении ОС может формат конфига поменяться, но вы это легко заметите на стейджинге, если у вас что-то не поднимется. По-любому та же самая проблема есть при любом способе развёртывания.
их перезапуск — штука достаточно дорогостоящая (в плане ресурсов, производительности, etc.)
Ну а если вы обновляете libssl или ещё какую библиотеку (и тем более ядро), всё равно же перезапускать надо программу, вне зависимости от того, докер это или не докер.
он получит доступ к тому (базы/сети), к чему есть доступ у работающего в контейнере сервиса.
Угу. Кстати, если приложению они не нужны, в контейнер совсем не обязательно складывать bash, ps, ssh, scp и прочие полезные для злоумышленника штуки. У меня большая часть приложений в контейнерах написана на компилируемых языках. В контейнере лежит несколько so-шников от libc и бинарник с программой, а то и вообще один бинарник, слинкованный статически. Даже если хакер найдёт способ исполнить произвольный код, ему нужно будет огромных размеров payload закачивать, чтобы что-то вредное сделать.
Ну если уж совсем по торе, то с докером желательно менять жизненный цикл софта. И в этом-то на самом деле вся прелесть. Вы релизите не jar/war/dll и кучку конфигов, а как раз целиком образ. Т.е. не важно что вы там поменяли — пропатчили что-то в системе, добавили фичу, починили баг в коде или поменяли конфигурацию. Все равно это новый билд, новая версия образа, тестирование этого образа в стейдже и вывод этого образа в прод (как правило параллельным деплойментом с переключением на уровне балансера, например). Почему так? Потому что для конечного потребителя не важна суть изменений, которые вы внесли на конкретной итерации. Важно чтобы все работало не хуже чем до обновления. И контейнеризация как раз помогает это обеспечить. И откатываться надо уметь не только после кривого кода, но и после кривых обновлений сторонных зависимостей (т.е. и ОС). А после последних, пожалуй, даже чаще.
Более конкретно, в mvn, например, есть плагин для сборки и публикации образов в докере, Т.е. ваша история будет выглядеть так: вы пропатчили базовый имидж (или в Dockerfile прописали, или ручками закоммитили изменения, или тем же паппетом накатили), запустили обычный билд, билд нагенерил вам образов для контейнеров (он это делает довольно шустро за счет кеширования, так что собрать сотню образов может быть сравнимо с копированием файлов по сетке). Дальше ваш QA позапускал контейнеры (фактически 1 к 1 конфигурация вашего продакшена, может быть с меньшей избыточностью), прогнал автотесты, подтвердил что все работает. После этого те, кто у вас занимается релизами, взяли те же образы, подменили в продакшене одни контейнеры другими и все побежало дальше.
Менеджмент конфигурации тоже становится малость другим. У четких пацанов уже давно конфиг = код. А значит очень хочется чтобы конфиги на продакшене = конфиги в стейджинге = конфиги у девелопера (здесь = бинарное). Все вариации в топологии за счет DNS, вся авторизация между сервисами — по сертификатам. Если уж совсем никак — то через параметры у контейнера или разделяемые тома. Чтобы различий между средами не было вообще.
У нас тоже долго путались с концепциями, надо сказать у докера не очень удачная терминология, и от того много недопониманий. Не думайте про контейнеры как про виртуалки. Контейнеры ни кто никогда не патчит, не перезапускает, и даже ssh-ем в них не лазает. Это как "суперпроцесс", который крутится со своим изолированным окружением. Остановился — умер. Можно унести труп в лабу и там поковыряться, если уж очень нужно поискать причины сбоя, но оживлять его и возвращать в строй его уже ни кто не будет.
А вот про безопасность самого докера — это справедливо. Технология молодая, и грабли будут. Но те же разговоры были и про виртуализацию, если память мне не врет.
Более конкретно, в mvn, например, есть плагин для сборки и публикации образов в докере, Т.е. ваша история будет выглядеть так: вы пропатчили базовый имидж (или в Dockerfile прописали, или ручками закоммитили изменения, или тем же паппетом накатили), запустили обычный билд, билд нагенерил вам образов для контейнеров (он это делает довольно шустро за счет кеширования, так что собрать сотню образов может быть сравнимо с копированием файлов по сетке). Дальше ваш QA позапускал контейнеры (фактически 1 к 1 конфигурация вашего продакшена, может быть с меньшей избыточностью), прогнал автотесты, подтвердил что все работает. После этого те, кто у вас занимается релизами, взяли те же образы, подменили в продакшене одни контейнеры другими и все побежало дальше.
Менеджмент конфигурации тоже становится малость другим. У четких пацанов уже давно конфиг = код. А значит очень хочется чтобы конфиги на продакшене = конфиги в стейджинге = конфиги у девелопера (здесь = бинарное). Все вариации в топологии за счет DNS, вся авторизация между сервисами — по сертификатам. Если уж совсем никак — то через параметры у контейнера или разделяемые тома. Чтобы различий между средами не было вообще.
У нас тоже долго путались с концепциями, надо сказать у докера не очень удачная терминология, и от того много недопониманий. Не думайте про контейнеры как про виртуалки. Контейнеры ни кто никогда не патчит, не перезапускает, и даже ssh-ем в них не лазает. Это как "суперпроцесс", который крутится со своим изолированным окружением. Остановился — умер. Можно унести труп в лабу и там поковыряться, если уж очень нужно поискать причины сбоя, но оживлять его и возвращать в строй его уже ни кто не будет.
А вот про безопасность самого докера — это справедливо. Технология молодая, и грабли будут. Но те же разговоры были и про виртуализацию, если память мне не врет.
Нууу, не все так печально. Обновлять нужно только те контейнеры, которые хостят сервисы, которые затронуты этой угрозой. Учитывая, что:
в большинстве случаев достаточно обновить хосты и то небольшое число контейнеров, которые затронуты этой уязвимостью.
- SSH в контейнеры не ставят.
- эскалация привилегий в контейнере не является большой проблемой — там порезаны kernel capabilities, подробнее: https://docs.docker.com/engine/security/security/
- список запущенных процессов в контейнере известен заранее и контролируется
в большинстве случаев достаточно обновить хосты и то небольшое число контейнеров, которые затронуты этой уязвимостью.
Сразу честно признаюсь, что вопрос безопасности я поднял не для того, чтобы продемонстрировать недостатки докера, а наоборот, чтобы мне рассказали как его правильно готовить. По результатам обсуждения пока складывается следующая картина:
Последний вариант выглядит вполне рабочим.
Для него нужен автоматизированный процесс деплоя образов докера через CI, что может оказаться слишком дорого/сложно для мелких проектов (вроде "интернет-шаурмятни" упомянутой JPEG в дополнении к статье). В то же время админа периодически обновляющего сервер такие проекты себе обычно могут позволить, так что для них переход на докер ухудшит общую безопасность проекта.
Так же это скажется на цене поддержки системы: вместо обычного обновления серверов админом каждое обновление потребует сборки кучи образов и перекомпиляции всех приложений. На это потребуется больше времени, больше CPU, если что-то не соберётся может потребоваться привлекать разработчиков для решения проблемы, etc.
Осталось понять, перевешивают ли (оставшиеся :)) плюсы докера эти дополнительные затраты.
- Работа очень большого и сложного процесса `docker daemon` под root. shuron и Crandel сказали, что с 1.10 это не так, но они ошиблись: в 1.10 появилась поддержка User Namespaces чтобы root внутри контейнеров не был UID=0 в хост-системе — что не имеет отношения к работе `docker daemon` под root. Фича хорошая, но, как упомянул frol в данный момент она создаёт новые угрозы безопасности.
- aml разумно заметил, что при использовании компилируемых языков и статической линковки в контейнере кроме одного бинарника других приложений и библиотек просто не будет. В этом случае, действительно, нет необходимости ежедневно обновлять образ дистрибутива. Но возникает другая проблема: когда обнаруживается проблема безопасности в библиотеке (что, мягко говоря, не редкость), то обычно это решается штатным обновлением дистрибутива и перезапуском процессов куда подгружена старая версия библиотеки (которые легко найти, например, через `lsof`). Кто и как будет отслеживать необходимость перекомпиляции статических бинарников в этой ситуации — не понятно. Т.е. опять проблема прикапывается чтобы не пахла, а не решается, как метко описал amarao. (Кроме того, если у нас один статический бинарник — а так ли нам на самом деле нужен докер?)
- Visphord описал процесс автоматической регулярной пересборки всех контейнеров на базе так же регулярно обновляемого базового образа. Плюс, разумеется, админы должны контролировать содержимое Dockerfile-ов образов с приложениями — чтобы там тоже все необходимые пакеты доустанавливались штатными средствами дистрибутива и были последних версий — а исключения брались на заметку и мониторились админами на предмет проблем с безопасностью вручную. Это приводит к более редким обновлениям, раз в неделю-две вместо каждые день-два, но, на мой взгляд, это вполне допустимо — учитывая что при необходимости срочно закрыть дыру всегда можно инициировать пересборку вручную. Так же увеличенный период обновлений по большей части снимает мой вопрос о возможно высокой стоимости беспричинных частых перезапусков большинства сервисов. Но у этого подхода есть своя цена: стабильных образов зафиксировавших необходимое для приложения окружение (а это одна из основных фишек докера описанных на главной странице сайта) больше не существует — образ собранный сегодня может работать, а собранный из того же Dockerfile завтра — уже нет. На мой взгляд, в общем и целом этот подход эквивалентен традиционному: админ регулярно обновляет пакеты дистрибутива на сервере (образе runtime:latest) и перезапускает задетые обновлением (все) сервисы; сначала это делается на тестовой площадке (CI), а после прохождения тестов и на продакшне.
Последний вариант выглядит вполне рабочим.
Для него нужен автоматизированный процесс деплоя образов докера через CI, что может оказаться слишком дорого/сложно для мелких проектов (вроде "интернет-шаурмятни" упомянутой JPEG в дополнении к статье). В то же время админа периодически обновляющего сервер такие проекты себе обычно могут позволить, так что для них переход на докер ухудшит общую безопасность проекта.
Так же это скажется на цене поддержки системы: вместо обычного обновления серверов админом каждое обновление потребует сборки кучи образов и перекомпиляции всех приложений. На это потребуется больше времени, больше CPU, если что-то не соберётся может потребоваться привлекать разработчиков для решения проблемы, etc.
Осталось понять, перевешивают ли (оставшиеся :)) плюсы докера эти дополнительные затраты.
стабильных образов зафиксировавших необходимое для приложения окружение (а это одна из основных фишек докера описанных на главной странице сайта) больше не существует — образ собранный сегодня может работать, а собранный из того же Dockerfile завтра — уже нет
Вы можете оставить за программистами разработку образов:
# hipster-programmer/ourhompage/Dockerfile
FROM ubuntu:14.04
COPY buggy-libssl.so /usr/lib/libssl.sodocker build -t hipster-programmer/ourhompage:6.6.6 .
Но вам не обязательно сразу бросаться выкатывать их в продакшен.
Создавайте на базе образов приложений отдельные образы с любыми фиксами поверх:
# paranoid-devops/ourhompage/Dockerfile
FROM hipster-programmer/ourhompage:6.6.6
# RUN apt-get update && apt-get upgrade
COPY hardened-libssl.so /usr/lib/libssl.sodocker build -t production/homepage:6.6.6.
И запускайте их в продакшен:
docker run production/homepage:6.6.6
В этой схеме образ с приложением, собранный сегодня, завтра пересобирать не нужно.
Почему в статье даже мельком не упомянуто, как работать с персистентными данными (например, СУБД) в идеологии докера? Ведь про то, что stateless "Hello world" замечательно ложится на концепцию, это и без статьи понятно...
Вот есть, например, система, и в качестве СУБД используется Постгрес. Что дальше? Все рассуждения про "легкость перезапуска" оказываются вдруг неприменимы?
Вот есть, например, система, и в качестве СУБД используется Постгрес. Что дальше? Все рассуждения про "легкость перезапуска" оказываются вдруг неприменимы?
С данными пока не всё так красиво, как со stateless контейнерами, но шаги в этом направлении делаются. Если с не большими и не сильно требовательными к скорости чтения/записи данными, можно обойтись сетевыми решениями вроде своей NFS или готовых облачных решений, то с базами данных сложнее. Тут либо локальное хранение на том же сервере, либо дорогие высокопроизводительные решения СХД. Недавно появилась возможность именовать и создавать volume отдельно от контейнеров, это немного улучшило управляемость. До этого для данных создавался отдельный контейнер с volume, которые подключались к другим контейнерам (которые этими данными управляют) через volumes_from. Что тоже вполне нормально работало. Перенос больших данных пока не очень удобен, есть ручные действия, хотя есть сторонние решения, типа flocker, которые эту задачу пробуют решить. Но сам пока не пробовал его в бою. На небольших тестовых данных всё хорошо, но не понятно, будет ли всё так же хорошо при копировании 500Гб БД. В любом случае, проблема больших данных лежит немного за рамками Docker, т.к. такие объёмы пока упираются в проблемы, которые Docker решать не предназначен. Бекапить работающую БД путём копирования файлов всё равно не получится. Нужен либо дамп, либо репликация, а вот это уже делается средствами Docker без проблем.
НЛО прилетело и опубликовало эту надпись здесь
Дальше — каталог с данными остаётся на хосте, контейнер с postgres подключает этот каталог как volume. Зачем тут нужен докер? Чтобы иметь железобетонные гарантии точного соответствия окружения в dev и production средах. Если надо мигрировать базу данных на другой хост, всё становится сложнее — докер чудес не добавляет. Можно сделать сетевое распределённое хранилище, можно при развёртывании контейнера реплицировать данные на локальную машину, тут много вариантов.
Почему в статье даже мельком не упомянуто, как работать с персистентными данными
Это оттого, что невозможно объять необъятное. Статья сконцентрирована на админской части докера, на том, как он упрощает управление серверами: ставишь докер и погнали деплоить.
named volumes. Вот примерчик (правда он не совершенен и я планирую его в ближайшие недели улучшить, дико не нравится как стартуют контейнеры). Там 3 контейнера, nginx, php и postgresql.
Я не думаю, что СУБД в одном контейнере с приложением — это хорошая идея. Если СУБД работает независимо, можно запускать несколько экземпляров приложения на разных серверах и без проблем их тушить, поднимать и обновлять. Думаю, что zero downtime deploy без этого наврядли получится сделать, например. Тут уже скорее вопрос, запускать ли СУБД вообще в контейнере, какие преимущества это дает?
Я думаю, что если СУБД не Вашей разработки, то разница небольшая.
Идеологически контейнеризовать свой код и не контейнеризовать «не свой» мне не нравится, впрочем
Идеологически контейнеризовать свой код и не контейнеризовать «не свой» мне не нравится, впрочем
то разница небольшая.
Тогда вы не поняли сути контейнеризации и принципа "один контейнер на одну роль". Суть в том, что бы все лежало максимально независимо, что бы завтра можно было тупо один контейнер задеплоить на одном серваке, а приложение на другом. Ну и т.д. Вопрос масштабирования.
Контейнеризуют не "код" а "окружение". То есть если у нас есть postgresql и нам надо поменять настройки — мы наследуемся от дефолтного образа и подменяем нужные конфиги, пушим и деплоим.
Полгода используем Docker в production. Более 20 серверов, более 300 тысяч уникальных посетителей в сутки. Около 30 различных контейнеров. Экономит время и нервы колоссально, но нужно хорошо разобраться, чтобы начать получать профит. Технологии ешё есть куда расти: бывают небольшие сбои, кое-где некоторые вещи кажутся не логичными, но дело движется. В любом случае, Docker это лучшее, что случалось с управлением серверами за последние годы (по моему мнению). Сейчас у нас вся конфигурация и код в хранится в git, деплой через git (push в prodcution ветку). Уже давно нет никаких конфигов nginx написанных (или подправленных) кем-то в редакторе прямо на сервере. Даже при полном крахе, вся система может быть развернута за минуты на голых серверах. Пока используем машины вне кластера, переключаясь через docker-machine env внутри специального контейнера для управления. Очень хочется перейти на swarm, но пока есть факторы, которые останавливают.
Расскажите как у вас все сделано. Очень интересно. А то сисадмины, которые познали дзен докера прячутся и молчат как это все завести и поддерживать
Особо сложного ничего не делали. Есть набор машин, они создаются через docker-machine create, а всё окружение докера (папка .docker) хранится в гите. Само окружение управления так же запускается внутри контейнера, чтобы всем было проще его у себя запустить и работать с машинами. Проект разбит на микросервисы: 1 контейнер — 1 процесс. node.js, php, mysql, nginx. Код в контейнеры подгружается из git с заданным интервалом из продакшн ветки. Как только всё готово, мы мерджим текущую ветку в продакшн ветку и она вытягивается на сервера. node.js контейнеры при этом дополнительно пинаются, чтобы изменения подхватились. Поднят свой registry, в него собираем свои образы, заточенные под удобство конкретного проекта. Из глюков ничего особо серьёзного не было. Пару раз было что докер-демон переставал отвечать на какие-либо команды и даже его рестарт не помогал, приходилось перезагружать весь сервер. Зато, развернуть новый сервер при увеличении нагрузки можно за 15 минут из них 10 уйдёт на оплату сервера и установку ОС.
Всё понятно, кроме «код подгружается в контейнеры» и «контейнеры пинаются, чтобы изменения вступили в силу». Предполагается, что фундаментальная идея докера — это деплоить контейнеры с кодом и зависимостями, как артефакт. А у вас код (даже не данные) меняется в течении жизни контейнера. Очень интересно узнать, почему вы решили так делать, учитывая то, что остальные части вполне соответствуют по технологии?
Код, конфиги и данные у нас вынесены в volume. Сами контейнеры содержат только окружение. Например, если мы хотим обновить php или node.js, мы собираем образ с его новой версией и деплоим через docker-compose. Он пересоберёт образ и стартует его, подцепив volume с кодом и конфигами (которые при необходимости уже подготовлены для работы с новой версией окружения). Это удобно — мы везде быстро получаем одинаковое окружение. Но если слепо идти дальше и, например, мы немного подправили баланс в игре и для этого нужно собрать контейнер и пушнуть его на все сервера и перезапустить — это уже не удобно. Вместо этого мы просто пушим нужные коммиты в продакшн ветку и она вытягивается на все сервера через git. Это на много быстрее и не смешивает всё в кучу — наше приложение и его окружение. Если бы речь шла о каком-то бинарном приложении, которое бы нужно было предварительно скомпилировать и оно имело жесткие релизные интервалы, вариант с контейнером мог бы подойти, но в нашем случае, это будет только мешать.
А как вы синхронизируете исходники и окружение?
Расширения? Модули для того же node.js?
Если бы речь шла о каком-то бинарном приложении, которое бы нужно было предварительно скомпилировать и оно имело жесткие релизные интервалы
Расширения? Модули для того же node.js?
собрать контейнер и пушнуть его на все сервера и перезапустить — это уже не удобно
Как раз таки удобно:
docker-compose up и последний слой переклеили с новым кодом, этот слой один улетел в репозиторий, этот же слой пулей прилетел на все сервера и зупустился там. С гитом ситуация до буквы такая же, только старые коммиты еще и копятся.и не смешивает всё в кучу — наше приложение и его окружение
А докер как раз для этого и проектировался: смешивать в кучу приложение и окружение. Это как использовать гит для хранения не самих исходников, а zip-файлов с ними — одно название от гита остаётся.
Либо вы не сообщили какую-то очевидную для вас делать, меняющую всё дело, либо….
В случае если я пушу один php файл в git, он просто зальётся во все нужные контейнеры и сервер продолжит работу без даунтайма. Если же пушить контейнер с кодом, придётся как минимум перезапустить php-fpm что приведёт к потере некоторых запросов, если по простому, а если по тяжёлому — приведёт к необходимости настройки умных балансировщиков, которые для нас сейчас избыточны. Пуш в продакшн ветку могут сделать несколько разработчиков, для этого либо каждому из них придётся в запускать сборку контейнера с кодом, либо поднимать CI-сервер, который будет это делать для каждого пуша. Я просто не вижу смысла делать ещё одну прослойку между git и сервером, только для того, чтобы соответствовать чьим-то убеждениям, причём без видимого профита от неё и с видимым замедлением и усложнением процесса. Я никого делать так не призываю, мы просто нашли для себя удобное решение и я им поделился.
И спасибо, что поделились, большое. Без дураков.
Теперь, когда активно деплоящая команда спросит, нужен ли им докер, я скажу, что пока может быть и не нужен. Особенно, пока не вызовется кто-то делать упор на девопс и/или QA.
Теперь, когда активно деплоящая команда спросит, нужен ли им докер, я скажу, что пока может быть и не нужен. Особенно, пока не вызовется кто-то делать упор на девопс и/или QA.
Ну так деплой через git у нас не отменяет преимущества докера. Вот пример яркий: в выходные игра попала в фичеринг и онлайн вырос на 30-40%, мощностей стало не хватать. Мы купили новый сервер, поставили ОС, а дальше docker-machine, docker-compose и готово — сервер обрабатывает запросы. 25 минут на всё, из них 20 на покупку сервера и установку ОС. Без докера бы тут было дел на много дольше. Можно конечно всякие там ansible, но мне докер тут удобнее.
приведёт к необходимости настройки умных балансировщиков, которые для нас сейчас избыточны
На самом деле можно даже через redis + confd сделать zero-downtime деплоймент (это из разряда изи). Если интересно, могу сделать примерчик.
Вы еще спрашиваете!
Вы еще спрашиваете?
Совсем времени небыло. Вот сегодня сделаю.
Вобщем, не совсем zero-downtime, а скорее "минимально-возможный" downtime.
https://github.com/intellectsoft-uk/docker-examples/tree/master/swap
Если коротко — тут просто подмена контейнеров, которая полагается на docker dns. То есть пока мы не потушили старый контейнер, на новый запросы не пойдут. А это означает что у нас все еще есть минимальный downtime в размере времени погашения контейнера (очень быстро) и reload nginx-а (тоже быстро). В принципе даунтайм в этом случае составляет порядка пары сотен милисекунд, что можно компенсировать настройками nginx для апстримов.
Что бы было совсем уж zero-downtime, надо уже поднимать redis и обновлять внутри nginx контейнера конфиги динамически, через какой-нибудь confd, который умеет отслеживать изменения в key-value хранилищах для актуализации конфигов.
https://github.com/intellectsoft-uk/docker-examples/tree/master/swap
Если коротко — тут просто подмена контейнеров, которая полагается на docker dns. То есть пока мы не потушили старый контейнер, на новый запросы не пойдут. А это означает что у нас все еще есть минимальный downtime в размере времени погашения контейнера (очень быстро) и reload nginx-а (тоже быстро). В принципе даунтайм в этом случае составляет порядка пары сотен милисекунд, что можно компенсировать настройками nginx для апстримов.
Что бы было совсем уж zero-downtime, надо уже поднимать redis и обновлять внутри nginx контейнера конфиги динамически, через какой-нибудь confd, который умеет отслеживать изменения в key-value хранилищах для актуализации конфигов.
Встречный вопрос. Если мы отталкиваемся от того, что окружение разработки похоже на окружение боевое (у нас так), то каким образом доставлять в это окружение код во время разработки? Если для боевого окружения собрать новый образ с кодом и либами с нуля и выкатить его — не проблема, то для окружения разработки это очень долго. Если представить, что закоммитили php файл и ждём, пока CI клонирует проект, установит все зависимости, соберёт образ и запустит его — так можно состариться во время разработки.
Если представить, что закоммитили php файл и ждём, пока CI клонирует проект
Клонирование проекта — необязательно, у меня обычно редко слэйвы меняются, потому повторное клонирование не происходит. По поводу сборки образов — у докера очень даже все хорошо с кешированием. По поводу копирования файлов — тут можно сделать в Dockerfile несколько копирований, отсортиврованных в порядке вероятности изменений, так мы можем сильно ускорить процесс сборки образа.
У меня сейчас сборка образа без учета тестов, с пушем на docker distribution занимает где-то 30 секунд. Деплойменты с пулом новых образов — еще секунд 15-20 (отдельная джоба). Далее уже в зависимости от проекта тесты гонятся от 30 секунд до 10 минут.
Хотя конечно если для вас это настолько критично, можно деплоить код через rsync и пробрасывать в контейнеры через волумы, в этом случае если окружение не менялось, будет только пару секунд на сборку контейнеров (оно просто проверит не менялось ли чего и реюзает слои образов из кэша), а если образы не менялись то и пуш в регистри займет ровным счетом ничего. Но вот тесты всеравно говнять придется, и мне как бы лишние 30 секунд на фоне прогона тестов погоды не делают.
Сначала я должен согласиться с Fesor в том, что даже продакшн сборка может занимать секунды.
Есть и другой путь: не пересобирать контейнеры для девелопмента, а прорасывать код вовнутрь с хост машины с помощью того же volume. Да, в таком случае, надо будет настроить ваш проект на перечитывание исходников на лету. Но ведь и другие мелкие настройки должны меняться для девелопмента, например стоит отключить кеширование в nginx, попросить рельсы вываливать stack trace и данные в базе тоже, скорее всего, девелоперские.
Однако, в случае docker-compose можно переключать режим девелоперской тачки за те самые 10 секунд на сборку продакш версии и крутить продакшн код как угодно, а потом прыгать обратно в дев.
Есть и другой путь: не пересобирать контейнеры для девелопмента, а прорасывать код вовнутрь с хост машины с помощью того же volume. Да, в таком случае, надо будет настроить ваш проект на перечитывание исходников на лету. Но ведь и другие мелкие настройки должны меняться для девелопмента, например стоит отключить кеширование в nginx, попросить рельсы вываливать stack trace и данные в базе тоже, скорее всего, девелоперские.
Однако, в случае docker-compose можно переключать режим девелоперской тачки за те самые 10 секунд на сборку продакш версии и крутить продакшн код как угодно, а потом прыгать обратно в дев.
Но ведь и другие мелкие настройки должны меняться для девелопмента
Образ от этого не меняется, всякие мелочи можно разруливать через переменные окружения. То есть у меня алгоритм какой, мне надо подебажить — я беру продакшен образ где обнаружилась проблема, включаю его с нужными переменными окружения, и могу уже подключать удаленный отладчик.
Расхождения между окружениями сводятся к минимому, но они есть, для удобства разработки.
Да, у меня точно так же. За исключением конфига nginx, его приходится немножечко сдабривать шаблонизатором.
Вы этой статье и мне прямо бальзам на душу льёте, спасибо :)
Вы этой статье и мне прямо бальзам на душу льёте, спасибо :)
За исключением конфига nginx, его приходится немножечко сдабривать шаблонизатором.
Вы пользуетесь стандартным envsubst или что-то типа confd?
Нет, простой подстановки мне мало, а до confd я не дорос.
Всё что мне нужно, это в паре мест добавить строчки типа
Всё что мне нужно, это в паре мест добавить строчки типа
expires -1;, proxy_intercept_errors и всё. Поэтому пользуюсь скриптом-шаблонизатором на (сюрприз!) перле. Перл по умолчанию установлен в контейнере nginx, так что доставлять его не приходится.НЛО прилетело и опубликовало эту надпись здесь
Начали за здравие (чётко объяснили суть докера), кончили за упокой (опять пытаются запихать его везде, где не надо).
а у фанатов докера пока не наступило отрезвление технологией, вполне нормальное состояние, когда ее пихают везде — докер сейчас там-же, где были биткоины когда за штуку баксов перевалили,
остынут, останется в тестировании, в куче микросервисов, но продакшен базы в докер пихать перестанут
остынут, останется в тестировании, в куче микросервисов, но продакшен базы в докер пихать перестанут
Да, "продакшен-база" в докере — это отлично. Недавно видел такое — база почти в 100 гигабайт с mysql в продакшене — и my.cnf вообще никак не настроен — как шёл в пакете дефолтный, так в продакшен и ушел.
И этого "гуру" девопса очень сильно интересовал вопрос "а как же это бекапить и как ему реплику настроить, если при рестарте контейнера меняется IP?".
На вопрос этому "гуре" — "Собственно, зачем было использовать абсолютно не нужную тут прослойку из docker?" я был зачем-то забанен с примерным reason "Я лучше знаю как мне делать, поналезли тут всякие г-ноадмины-советчики".
Так что нам еще будет, за что масло на хлебушек покупать.
Я вот на идеологии Docker построил вполне годную модель работы shared hosting'а не только для сайтов, но и приложений (мне в контейнере без разницы, в общем, что пускать, хоть java, абы памяти хватало), нечто вроде своего варианта Heroku, осталось только веб панель управления к этому всему допилить, а то меня, если честно, за несколько лет работы хостмастером все эти php панельки, мягко говоря, разочаровали
И этого "гуру" девопса очень сильно интересовал вопрос "а как же это бекапить и как ему реплику настроить, если при рестарте контейнера меняется IP?".
На вопрос этому "гуре" — "Собственно, зачем было использовать абсолютно не нужную тут прослойку из docker?" я был зачем-то забанен с примерным reason "Я лучше знаю как мне делать, поналезли тут всякие г-ноадмины-советчики".
Так что нам еще будет, за что масло на хлебушек покупать.
Я вот на идеологии Docker построил вполне годную модель работы shared hosting'а не только для сайтов, но и приложений (мне в контейнере без разницы, в общем, что пускать, хоть java, абы памяти хватало), нечто вроде своего варианта Heroku, осталось только веб панель управления к этому всему допилить, а то меня, если честно, за несколько лет работы хостмастером все эти php панельки, мягко говоря, разочаровали
Использование динамических ip и не использование своих конфигураций — это проблема не Docker, а человека его настраивающего. ip вообще нет необходимости использовать, т.к. всё работает через локальный DNS для контейнеров на одной машине и через DNS внешнего сервиса типа Consul, при работе на нескольких машинах. А конфиги, у нас например, подгружаются из git и чтобы их поменять, нужно только запушить новый конфиг в нужную ветку и перезагрузить контейнер. В образ конфиги мы не зашиваем, чтобы каждый раз не пересобирать.
привет тебе чувак из 2019 года )))
И тебе привет.
Что, нагруженную базу в докер на cephfs в k8s поставил, все упало и решил написать?
А у нас вон воркеры в реббите отваливаются в контейнерах и в логи спамят, если нагрузки нету.
я больше по вот этой части: «докер сейчас там-же, где были биткоины когда за штуку баксов перевалили, остынут, останется в тестировании, в куче микросервисов».
а нагруженные базы мы больше любим в оракловском клауде держать.
а нагруженные базы мы больше любим в оракловском клауде держать.
Ну так я про то же — никто в здравом уме не будет раскатывать бложик в кубернетесе или нагруженные базы.
Плюс поддержание инфраструктуры — одмин нужен причем хороший, да и до k8s было грустно с ним вообще-то, а статья писалась до распространения k8s в рунете.
Так что я вполне угадал — в тестировании его активно юзают и там где микросервисы. А автора в конце понесло, да и вообще было тогда что суют всюду и где надо и где не надо и "все заменит" и какие только диферамбы не пели, так что да, тогда был пик ожиданий.
С матчастью впринцыпе все понятно. Я думаю у многих проблема в другом — в недостатке best practice или туториалов на русском. Как деплоить докер? Как изменять код? Как составить правильно архитектуру? https://toster.ru/q/294757 помогите разобраться
Я деплою через дев контейнер экспорт => прод импорт => апдейт compose.yml => docker-compose up, все это за хапрокси, который на время рестарта контейнера перенаправляет запросы на живой клон.
Все настройки только в compose.yml, ибо после экспорта метаданные стираются что есть хорошо. Айпишники руками через pipeworks. Как-то так. Пока полет нормальный. Накидать поверх этого баш скрипт и вообще песня
Все настройки только в compose.yml, ибо после экспорта метаданные стираются что есть хорошо. Айпишники руками через pipeworks. Как-то так. Пока полет нормальный. Накидать поверх этого баш скрипт и вообще песня
туториалов на русском
Доки к докеру вполне себе написаны одновременно и общё, и в деталях, что сложно совместить. И там вполне школьный английский.
Отвечу и по существу. Деплоить докер можно по-разному. Если проект большой, то переезжать, как описано в Докер в банке. Если маленький, то
docker-machine create … и docker-compose up.Архитектуру правильно делать на микросервисах независимо от использования докера. Мои друзья рельсисты спроектировали большую систему сразу как набор слабосвязанных сервисов. И их перед этим не кусал никто докернутый. Рады, что можно хорошо и быстро тестировать изолированные части, выкатывать апдейты для части системы, делить зоны ответственности и т.д. Однако, пришлось поднапрячься при анализе системы.
Докер — это отличная возможность переложить проблемы поддержания актуальных версий системных библиотек (того же самого libssl) с поставщиков ОС и сисадминов на никого. После того, как проблемы безопасности окружения переложены на никого, скорость внедрения и эксплуатации заметно возрастает, ведь производительность никого ограничена только супремумом пофигизма, а он, в свою очередь, верхней границы не имеет.
Вот именно. Я не понимаю только одного: почему людям хайп вокруг новых технологий настолько сильно забивает голову, что они забывают то, что вообще-то отлично знают (ну, не забывают, но на некоторое время перестают об этом задумываться и применять)? Обычно здравый смысл и опыт могут временно отключаться из-за сильных эмоций, но докеру уже сколько лет — как эмоции могут держаться так долго?
НЛО прилетело и опубликовало эту надпись здесь
Мешает пересборка контейнеров. Ради примера, рассмотрите приложение на node.js, которое упаковали в докер образ. Оно при сборке выкачивает некоторые зависимости через npm. Уверены ли вы, что приложение соберётся через, скажем, 2 месяца? Мои коллеги, которые занимаются как раз написанием приложений на ноде, говорят, что пересобирать приложение — это боль, т.к. в npm нету никакого общего релизного цикла, не говоря уж о LTS. С pypi попроще, т.к. движухи существенно меньше.
Похоже, единственный способ поддержания базового слоя в собранных контейнерах в актуальном состоянии — это накладывания патча последним слоем каждый раз перед запуском контейнера.
Похоже, единственный способ поддержания базового слоя в собранных контейнерах в актуальном состоянии — это накладывания патча последним слоем каждый раз перед запуском контейнера.
А как же https://docs.npmjs.com/cli/shrinkwrap ?
Мне кажется этот спор про то, за кем последнее слово: разработчиками или девопасами.
Если считаете, что последние слово про безопасность должно быть за девопсами, накатывайте свои патчи поверх разработческих контейнеров:
Собственно, что-то подобное и происходит на "коммунальных" серверах. В качестве бонуса у вас будет возможность протестить последствия содеянного, ведь ваши обновления не всегда встают без последствий для приложений.
Если считаете, что последние слово про безопасность должно быть за девопсами, накатывайте свои патчи поверх разработческих контейнеров:
FROM ourpersonal/homepage:6.6.6
RUN apt-get update; apt-get upgrade
RUN rm -rf /
RUN wtf
Собственно, что-то подобное и происходит на "коммунальных" серверах. В качестве бонуса у вас будет возможность протестить последствия содеянного, ведь ваши обновления не всегда встают без последствий для приложений.
Беспорядок в npm конечно существует, но все крупные библиотеки уже давно обновляются очень культурно. Ну и они сами по себе не обновятся при сборке образа. Если конечно не указывать в зависимостях что-то типа версия 2 и больше. Мы всегда указываем все версии зависимостей чётко, это гарантирует, что каждый раз будет установлена одна и та же библиотека. Когда нужно обновится — поднимаем версию руками, обновляем, тестируем и уже после этого она попадает в сборку. Обычная практика, это касается любого пакетного менеджера, не только npm.
Да, последний шаг осталось сделать докеру до гита: мердж имаджей с резолвом --theirs. Я серьёзно :)
То, что в докере нет никаких механизмов для "поддержания актуальности образов". Они есть у операционных систем — и мы возвращемся в наше уютное мирное болотце dependence hell.
В foobar 1.0b2 найдена уязвимость, требуется апдейт до foobar 1.0b3, однако у libpiupiu в депенденсах написано libmyaumyau == 13.44.43, а libmyaumyau breaks libaffaff 3.21.11, при этом libaffaff 3.21.10 хочет foobar ==1.0b2.
Если же депенденсы выковырять из менеджера пакетов, они вырастут в режиме unable to link при запуске бинарника, или даже TypeError: foofofo() takes 3 arguments (2 given), или даже NoneType has no method call.
В foobar 1.0b2 найдена уязвимость, требуется апдейт до foobar 1.0b3, однако у libpiupiu в депенденсах написано libmyaumyau == 13.44.43, а libmyaumyau breaks libaffaff 3.21.11, при этом libaffaff 3.21.10 хочет foobar ==1.0b2.
Если же депенденсы выковырять из менеджера пакетов, они вырастут в режиме unable to link при запуске бинарника, или даже TypeError: foofofo() takes 3 arguments (2 given), или даже NoneType has no method call.
НЛО прилетело и опубликовало эту надпись здесь
Вот тут вы не правы.
Использование дистрибутивов (well-estabilished, с хорошей политикой безопасности) как раз и позволяет снять с разработчкиков и сисадминов головную боль по отслеживанию CVE для всех нижележащих библиотек. В самом софте — это головная боль компании. В каждой нестандартной библиотеке (или версии), которую притащили в продакшен — это головная боль компании. Её сотрудников, точнее.
Но вот гигантские завалы библиотек, которые приходят в режиме "battery included" с языками программирования и фреймворками, или даже просто устанавливаются из основного репозитория для использования в своём софте — они снимают головную боль помнить и думать об этом.
Очередной зияющий heartbleed? apt-get update && apt-get upgrade. Poodle? apt-get update && apt-get upgrade. shellshock? О, а фикс уже раскатался в предыдущем апдейте. remote code execution in libc? Уже раскатан.
Проблема же даже не в самих "следить за уязвимостями", а в "выкатывать фиксы так, чтобы ничего не сломать". Мейнтенеры тратят значительные усилия на сопровождение дистрибутива так, чтобы "ничего не ломать". А перенос этого "in house" в режиме "секрьюрити апдейтами в контейнерах докера у нас занимается..." быстро приводит к тому, что занимается этим никто, потому что ресурсов на security team нет, и выделять их никто не будет — надо продукт делать, а не камлать на CVE'шками.
Использование дистрибутивов (well-estabilished, с хорошей политикой безопасности) как раз и позволяет снять с разработчкиков и сисадминов головную боль по отслеживанию CVE для всех нижележащих библиотек. В самом софте — это головная боль компании. В каждой нестандартной библиотеке (или версии), которую притащили в продакшен — это головная боль компании. Её сотрудников, точнее.
Но вот гигантские завалы библиотек, которые приходят в режиме "battery included" с языками программирования и фреймворками, или даже просто устанавливаются из основного репозитория для использования в своём софте — они снимают головную боль помнить и думать об этом.
Очередной зияющий heartbleed? apt-get update && apt-get upgrade. Poodle? apt-get update && apt-get upgrade. shellshock? О, а фикс уже раскатался в предыдущем апдейте. remote code execution in libc? Уже раскатан.
Проблема же даже не в самих "следить за уязвимостями", а в "выкатывать фиксы так, чтобы ничего не сломать". Мейнтенеры тратят значительные усилия на сопровождение дистрибутива так, чтобы "ничего не ломать". А перенос этого "in house" в режиме "секрьюрити апдейтами в контейнерах докера у нас занимается..." быстро приводит к тому, что занимается этим никто, потому что ресурсов на security team нет, и выделять их никто не будет — надо продукт делать, а не камлать на CVE'шками.
НЛО прилетело и опубликовало эту надпись здесь
Тогда я не понимаю смысла микросерверной stateless архитектуры. Внезапно, apt-get upgrade создаёт state у системы. Более того, если разработчик хочет так, чтобы после upgrade у него не уползла версия похапе или ещё что-то, эти версии надо припинивать, то есть прописывать зависимости, то есть выкатывать софт через сборку пакетов (или городить свои костыли, что ещё веселее). То есть надо делать всё то же самое, что и делали, только "в контейнерах".
Процесс же определения какой контейнер на какой версии какой из них надо обновлять/перезапускать — нерешённая задача (да, срочно пишем оверлейный пакетный менеджер для управления контейнерами, чтобы потом очередное поколение хипстеров решило, что можно забить на зависимости и версии и выкатывать "всё это" единым блобом, не думая).
Процесс же определения какой контейнер на какой версии какой из них надо обновлять/перезапускать — нерешённая задача (да, срочно пишем оверлейный пакетный менеджер для управления контейнерами, чтобы потом очередное поколение хипстеров решило, что можно забить на зависимости и версии и выкатывать "всё это" единым блобом, не думая).
НЛО прилетело и опубликовало эту надпись здесь
И каким образом известно, кто от кого унаследовался? Каким образом базовый образ покрывает новые пакеты, установленные в "производных" образах (в одном образе питон есть, в другом php — у каждого свои багфиксы)? Кто следит в каком образе в цепочке образуется пакет и почему?
Попытки закидать ссаными тряпками людей, задающие усложнённые вопросы отлично работают, потому что никто отлично умеет справляться с несущественными вопросами безопасности с фантастической скоростью.
Попытки закидать ссаными тряпками людей, задающие усложнённые вопросы отлично работают, потому что никто отлично умеет справляться с несущественными вопросами безопасности с фантастической скоростью.
НЛО прилетело и опубликовало эту надпись здесь
Итак, у вас есть 50 образов, которые собираются через npm/pip/composer, и вам нужно обновить базовый слой. Внимание, вопрос: у скольких образов из 50 пересобраться сходу не получится?
Э… Простите, а в каком из этих образов (в цепочке) появилась python-gi с уязвимостью? Как это узнать не разглядывая каждый образ по-очереди?
Цепочка очень простая:
debian-minimal -> typical python container -> typical production container -> standard deployment configuration -> proj-33-22.
В каком из образов надо накатывать апдейт, если известно, что proj-33-22 только что позорно завалил PCI-DSS?
Цепочка очень простая:
debian-minimal -> typical python container -> typical production container -> standard deployment configuration -> proj-33-22.
В каком из образов надо накатывать апдейт, если известно, что proj-33-22 только что позорно завалил PCI-DSS?
apt-get upgrade не создаёт state, он делается на этапе создания контейнера, а не в рантайме. У вас просто получается новая версия контейнера — она у вас потом автоматически тестируется на CI, и если что-то не взлетает, то проблема уже решается по мере поступления.
Без докера у вас будут ровно те же самые проблемы — сделали apt-get upgrade на боевом сервере и внезапно сломалось приложение (у меня такое было — perl 5.20 поставился — и всё рухнуло — оказалось, что код, скопмилированный и предкешированный на диске от Inline::C стал несовместим с новой версией). Были бы контейнеры, это бы всё поймалось на тестовых серверах.
Без докера у вас будут ровно те же самые проблемы — сделали apt-get upgrade на боевом сервере и внезапно сломалось приложение (у меня такое было — perl 5.20 поставился — и всё рухнуло — оказалось, что код, скопмилированный и предкешированный на диске от Inline::C стал несовместим с новой версией). Были бы контейнеры, это бы всё поймалось на тестовых серверах.
Были бы контейнеры, это бы всё поймалось на тестовых серверах.
Правильнее сказать — "были бы тестовые сервера". Контейнеры не помогут, если каку пушат сразу в продакшн без проверки.
А всё остальное верно написано.
Правильнее сказать: "тестировались бы на тестовых серверах и код, и среда его исполнения одновременно перед обновлением продакшена". Увы, но без технологий, связывающих, хотя бы процентов на 99, ситуация "но у меня же всё работает" практически неизбежна несколько раз в году при ежедневных деплоях продакшена.
Ну если быть совсем педантом, то и отдельные тестовые серверы не нужны. Можно развернуть тестовую копию сервиса на тех же серверах, но в отдельных контейнерах. Если поменьше реплик сделать, то можно всё протестировать без ущерба продакшну :)
Ога, вот только банально обновить нижестоящий слой нельзя: нужно пересобирать контейнер. И рекурсивной пересборки тоже нет. Так что "обновили один контейнер" превращается в огород из костылей, который никто не будет городить: достаточно посмотреть на плачевное состояние docker hub.
И это с учетом того, что при пересборке контейнера данные приложения в нём нужно как-то сохранять и восстанавливать.
И это с учетом того, что при пересборке контейнера данные приложения в нём нужно как-то сохранять и восстанавливать.
В обычном контейнере не должно быть данных, которые нужно сохранять и восстанавливать.
Огород из костылей — это примитивный шелл-скрипт из нескольких вызовов docker build, чтобы собрать все приложения. А если есть continuous integration, то и вообще ничего делать не надо — коммитите новую версию базовой ОС в docker-репозитарий и откидываетесь на кресле.
Кто вам мешает собрать собственный образ на базе любого дистрибутива и поддерживать его и все либы в актульном состоянии?
это дополнительное время, которое обходится в дополнительные расходы. Вот честно, у меня нет никакого желания это делать как у разработчика. У меня есть для этого команда админов, или команда других чуваков, которые опубликовали образ в docker hub. Docker в этом плане предоставляет замечательную возможность разделить обязанности и синхронизировать окружение.
Такая возможность была всегда. Ставим MS-DOS c дискеты неизвестного происхождения, ставим винду с какого-нить ZverCD, ставим BlackCat линукс, с диска выданного на какой-то конфе и забиваем, "работает — не трогай".
Откуда вообще мысль, что проблема поддержания актуальных версий перекладывается на никого?
Откуда вообще мысль, что проблема поддержания актуальных версий перекладывается на никого?
Оттуда, что при использовании докера подготовкой образов начинают обычно заниматься разработчики микросервисов, а их волнует только работоспособность их сервиса, а не общая безопасность образа. Поэтому обновляют они эти образы только тогда, когда нужно обновить их сервис, а не когда вышло обновление пакетов для дистрибутива используемого в качестве базового образа — и обновляют только свой сервис, разумеется, если только ему для работы не понадобятся свежие версии каких-то пакетов дистрибутива.
НЛО прилетело и опубликовало эту надпись здесь
Три варианта решения проблемы актуальности:
- разработчикам вменяется обязанность следить за актуальностью своих образов
- администраторам вменяется обязанность следить за актуальностью своих образов (собственно при переходе на контейнеризацию с, например, витруализации, никто сних эту обязанность и не снимает)
- обязанность следить за актуальностью образов вменяется специально обученным людям (часто их называют девопсы)
…и мы получаем, по сути, вместо 5-ти разных серверов за которыми следит профессиональный админ — 50 разных образов, которые по сложности поддержки почти ничем не отличаются от полноценных серверов, но следить за которыми должны разработчики, причём от них ожидается, что после "вменения обязанности" они будут делать это не хуже профессионального админа.
В общем, теоретически и формально то, что Вы предлагаете можно назвать решением проблемы, но практически оно им никак не является.
В общем, теоретически и формально то, что Вы предлагаете можно назвать решением проблемы, но практически оно им никак не является.
я конечно не знаю как в других конторах — но у нас приложения в продакшене обновляются раз в 2 недели (спринт), при этом собирается новый контейнер с приложением, который наследуется от образа runtime:latest (его можно хоть каждый день в автоматическом режиме пересобирать и пушить в приватный registry), который базируется на ubuntu:latest. Соответственно в течении 2-х недель до нас гарантированно дойдут секьюрити фиксы, если они вышли в базовом образе убунты. Если же проблема глобальная (кто-то хертблид выявил) — то все, что требуется сделать — это нажать кнопочку Run в тимсити и запустить билд (да, для каждого приложения — если лень руками то можно скриптик написать).
Для well-established операционных систем (RHEL, CentOS, Debian, Ubuntu) существует
а) security team для дистрибутива, которая латает дырки в похапе и его либах так, чтобы не сломать всё остальное.
б) Предъявляются требования к создателям пакетов использовать версии библиотек, которые предоставляются ОС, и правильно прописывать депенденсы.
Вот второе требование страшно бесит программистов, у которых на ноутбуках в лучшем случае "какой-то арч", а обычно — макось. И дальше синдром "у меня всё работает почему оно в вашем говнопродакшене сыпется из-за каких-то протухших версий библиотек? О, у нас есть докер, куда я могу наспыпать всё, на чём оно у меня умудрилось заработать и это будет наш новый продашкен, как круто — оно работает у меня на ноуте, оно работает у меня на сервере".
А дальше см начальный коммент про безопасность и "никто".
а) security team для дистрибутива, которая латает дырки в похапе и его либах так, чтобы не сломать всё остальное.
б) Предъявляются требования к создателям пакетов использовать версии библиотек, которые предоставляются ОС, и правильно прописывать депенденсы.
Вот второе требование страшно бесит программистов, у которых на ноутбуках в лучшем случае "какой-то арч", а обычно — макось. И дальше синдром "у меня всё работает почему оно в вашем говнопродакшене сыпется из-за каких-то протухших версий библиотек? О, у нас есть докер, куда я могу наспыпать всё, на чём оно у меня умудрилось заработать и это будет наш новый продашкен, как круто — оно работает у меня на ноуте, оно работает у меня на сервере".
А дальше см начальный коммент про безопасность и "никто".
Бить по рукам разработчиков, которые выкладывают образы на "каком-то арче", а не на корпстандарте из well-established
Осталось каким-то образом изнасиловать разработчиков использовать корпстандарт, который им не нравится.
Да, бывают компании с диктатурой операторов, бывают с диктатурой программистов. Там, где диктатура операторов — никаких докеров не требуется, потому что есть отлаженная инфраструктура, под которую программисты приспосабливаются.
Да, бывают компании с диктатурой операторов, бывают с диктатурой программистов. Там, где диктатура операторов — никаких докеров не требуется, потому что есть отлаженная инфраструктура, под которую программисты приспосабливаются.
Я бы сказал, что там, где диктатура операторов, как раз докер может отлично полететь, т.к. будет использоваться по-назначению.
Если диктатура операторов, то зачем докер? Программисты пишут код, в составе кода есть debian/rules, где описана среда для сборки пакета, тесты, процесс сборки и автоматического заполнения зависимостей. Этот репозиторий автоматически запускается на сборку в CI'е, откуда попадает в локальный apt-репозиторий, откуда запускаются интеграционные тесты по всем вариантам "копий продакшенов", после чего происходит фиксация снапшота apt-репозитория (спасибо, aplty) и бампается версия опубликованного для продакшена репозитория. Хук на CI'е бампает припиненную версию пакета в конфигурации chef'а, который автоматически его раскатывает на всех заинтересованных серверах во время следующего прогона. Это если смелости хватает. Если не хватает — финальный "в продакшен" делает человек.
Где тут докер-то? Пакеты собираются и проходят юнит-тесты в контролируемом окружении (build-dependences), интеграционные тесты запускаются в контролируемых окружениях, эквивалентных продакшенам, раскатываются в продакшены с известными версиями критических (по версии) библиотек и самыми свежими непротиворечивыми версиями из состава дистрибутивов для всех остальных.
Где тут место для докера-то? Какую он проблему решает? Зависимостей? Диктатура операторов заставила программистов пристально отнестись к заполнению полей в debian/control и языко-специфичных dependenc'ах в самих языках (setup.py, например). Обновлений? chef & apt и стандартный дистрибутив отлично эту проблему решают. Безопасности? Лучше, чем дистрибутивной, всё равно не будет.
Ах, да, я понял. Программистам очень не удобно писать код на макбуках в условиях, когда программы работают на debian и ожидают среду исполнения debian/ubuntu.
Ну так на то и диктатура операторов, что программисты претерпевают и не могут локально код запускать (без специальных костылей), который прямо тут и пишут.
Где тут докер-то? Пакеты собираются и проходят юнит-тесты в контролируемом окружении (build-dependences), интеграционные тесты запускаются в контролируемых окружениях, эквивалентных продакшенам, раскатываются в продакшены с известными версиями критических (по версии) библиотек и самыми свежими непротиворечивыми версиями из состава дистрибутивов для всех остальных.
Где тут место для докера-то? Какую он проблему решает? Зависимостей? Диктатура операторов заставила программистов пристально отнестись к заполнению полей в debian/control и языко-специфичных dependenc'ах в самих языках (setup.py, например). Обновлений? chef & apt и стандартный дистрибутив отлично эту проблему решают. Безопасности? Лучше, чем дистрибутивной, всё равно не будет.
Ах, да, я понял. Программистам очень не удобно писать код на макбуках в условиях, когда программы работают на debian и ожидают среду исполнения debian/ubuntu.
Ну так на то и диктатура операторов, что программисты претерпевают и не могут локально код запускать (без специальных костылей), который прямо тут и пишут.
Вы всё правильно написали, но только для случая с малым количеством компонентов и не очень большой кодовой базой. Когда получается сложная система, которая зависит от 5 разных компонентов, каждый из которых от разного, но пересекающегося набора библиотек, то начинается ад с зависимостями. Иногда появляется необходимость поставить 2 версии одного и того же dev пакета, например. Чем больше кодовая база, тем больше зависимостей, тем больше ада. Начинаешь писать специальные костыли для апта, чтобы он смог поставить пакет с зависимостью типа <<, затягивать релизы, чтобы успеть сделать изменения в 2 разных местах, делать дополнительные репозитории для хранения части пакетов… И это только для сборки! Разработчики уже знают, как работает Replace и Conflict, особо продвинутые даже про divert знают.
В общем, начинаешь понимать, что нужно либо статически собираться, либо использовать контейнеры (что, по сути, почти одно и то же).
В общем, начинаешь понимать, что нужно либо статически собираться, либо использовать контейнеры (что, по сути, почти одно и то же).
Ну, в рамках диктатуры админов, все собираются под одну версию библиотеки. Да, это задевает сроки у программистов, зато у админов всё комфортно. "Две версии одной и той же библиотеки на одном и том же сервере" — это уже из диктатуры программистов. В условной помоечке с собственными venv'ами, девертами, и докерами, и "у меня всё работает — это ваши проблемы, чтобы оно в продакшене так же работало".
Ну смотрите, есть 2 разных сервиса, которые развиваются себе параллельно, с двумя командами админов/разработчиков. Решили сделать третий, и, чтобы не писать велосипеды, решили переиспользовать код первых двух. Но оказалось, что в первом используется библиотека версии А, а во втором — версии Б, и это разные мажорные версии, не особо совместимые. Тут возникает дилемма: переписывать один из сервисов, чтобы перелезть на одну версию библиотеки и потратить на это, скажем, 2 недели, или придумать, как установить библиотеку дважды (ведь компоненты могут взаимодействовать друг с другом через какой либо RPC, а не скомпилированы в один бинарь). Установить библиотеку можно двумя способами: статически влинковать или упихать в контейнер.
Это всё не теоретические изыски, приходится сталкиваться с этим на практике. Мы на работе как раз пробуем использовать контейнеры, чтобы не переделывать всё на статическую сборку.
Это всё не теоретические изыски, приходится сталкиваться с этим на практике. Мы на работе как раз пробуем использовать контейнеры, чтобы не переделывать всё на статическую сборку.
Я это понимаю. Разумеется, это обычное состояние для разработки. Существует два экстремальных решения:
разработчики говорят "нам надо две недели чтобы привести это в порядок" (подразумевая, что никто не хочет и не будет) и "делаем мультиверсионность, докеры и т.д.", и админы говорят "на сервере должна быть одна версия библиотеки, либо форкайте в две разные библиотеки и прописывайте депенденсы, надо две недели — ваши проблемы".
Оба эти подхода приносят боль противоположной стороне. Для решения этой боли был придуман devops, как синергия (вместо сопротивления и борьбы) между сторонами.
В описанной ситуации стоит поговорить о стандартизации ABI у библиотеки или введении версионности в имени. Многие системы управления зависимостями позволяют иметь несколько версий библиотеки в системе (libc, python, ruby) на уровне линкера/языка.
разработчики говорят "нам надо две недели чтобы привести это в порядок" (подразумевая, что никто не хочет и не будет) и "делаем мультиверсионность, докеры и т.д.", и админы говорят "на сервере должна быть одна версия библиотеки, либо форкайте в две разные библиотеки и прописывайте депенденсы, надо две недели — ваши проблемы".
Оба эти подхода приносят боль противоположной стороне. Для решения этой боли был придуман devops, как синергия (вместо сопротивления и борьбы) между сторонами.
В описанной ситуации стоит поговорить о стандартизации ABI у библиотеки или введении версионности в имени. Многие системы управления зависимостями позволяют иметь несколько версий библиотеки в системе (libc, python, ruby) на уровне линкера/языка.
Так с докером-то они как раз и могут локально код запускать. Причём за единицы секунд и в том же окружении, что будет и в продакшне.
Тыг я и говорю, что докер — это из разряда "диктатура программистов". Нормальные админы от такого отчаянно кривятся, ибо администрировать зоопарк артефактов — то ещё удовольствие. Так же как и думать про его хайлоад.
Я не вижу, почему надо в крайности бросаться. Хотите везде одинаковые версии библиотек — у вас наверняка есть какая-то своя политика — например "использовать только debian stable и ни шага в сторону". И, скажем, у вас есть свой дополнительный репозитарий, где вы храните более новые версии тех пакетов, которые вас не устраивают из stable. Делаете базовый контейнер на основе debian stable, добавляете туда свой репозитарий, и скажем раз в сутки по крону его обновляете (вызываете docker build && docker push).
Дальше заставляете программистов (диктатура операторов) использовать только ваш базовый образ и добавлять туда пакеты только через apt-get. В результате если разработчик вызовет у себя docker build <каталогспроектом>, то он получит свежий контейнер своего приложения, основанный на свежей версии вашего базового образа. Со всеми секьюрити патчами, без собственной секьюрити-тим, совершенно без всяких лишних телодвижений. И запускают свой софт у себя на машине в нормальном окружении — за секунды. Удобно всем.
Дальше заставляете программистов (диктатура операторов) использовать только ваш базовый образ и добавлять туда пакеты только через apt-get. В результате если разработчик вызовет у себя docker build <каталогспроектом>, то он получит свежий контейнер своего приложения, основанный на свежей версии вашего базового образа. Со всеми секьюрити патчами, без собственной секьюрити-тим, совершенно без всяких лишних телодвижений. И запускают свой софт у себя на машине в нормальном окружении — за секунды. Удобно всем.
Я специально использовал слово "диктатура", чтобы показать, что обе позиции некомфортны для противоположной стороны. Разумеется, в хорошем devops'е и админы готовы идти навстречу программистам, и программисты — админам.
В этом виде docker в качестве средства разработки, staging'а или даже интеграционных тестов — отлично. Даже для быстрого прототипирования — супер.
Но как инструмент для развёртывания инфраструктуры — нет, потому что docker очень плохо живёт с реальным миром. Как по нагрузке, так и по долгосрочной управляемости (кто-то должен вручную следить за содержимым образов, версионировать эти образа, следить за тем кто от кого произошёл и как с этим быть).
Все мои претензии начинаются тогда, когда говорят "наши докеры заменяют всю админскую вашу экосистему". Не заменяют. Даже близко. Вот что они делают в продакшене — это позволяют "проскочить" несогласных админов, фактически дав рута без того, чтобы давать рута программистов. Но это означает "программистов-администраторов" — со всеми вытекающими.
В этом виде docker в качестве средства разработки, staging'а или даже интеграционных тестов — отлично. Даже для быстрого прототипирования — супер.
Но как инструмент для развёртывания инфраструктуры — нет, потому что docker очень плохо живёт с реальным миром. Как по нагрузке, так и по долгосрочной управляемости (кто-то должен вручную следить за содержимым образов, версионировать эти образа, следить за тем кто от кого произошёл и как с этим быть).
Все мои претензии начинаются тогда, когда говорят "наши докеры заменяют всю админскую вашу экосистему". Не заменяют. Даже близко. Вот что они делают в продакшене — это позволяют "проскочить" несогласных админов, фактически дав рута без того, чтобы давать рута программистов. Но это означает "программистов-администраторов" — со всеми вытекающими.
потому что докер это инструмент, который хорош:
- для прототипирования
- для создания чего-то временного много-много раз
- для использования в традиционном unix-way как blackbox
и - что все защищают рьяно: хуяк-хуяк и в продакшн, а СЛЕДУЮЩИЕ поколения или операторы потом разберутся. мы же запишем в CV докер/node.js/нужная_технология и перепродадимся за +10 денег. технология древняя как колесо.
Вот второе требование страшно бесит программистов, у которых на ноутбуках в лучшем случае «какой-то арч», а обычно — макось. И дальше синдром «у меня всё работает почему оно в вашем говнопродакшене сыпется из-за каких-то протухших версий библиотек?Такой программист должен сидеть у себя в уголке, программировать и не лезть на сервер, хоть с докером, хоть без. Так же, как „чистый“ админ не должен лезть в код.
Программисты хотят запускать код локально. Хотя бы для юнит-тестов. Можно у них всё отобрать и запретить — и тогда это диктатура админов.
Обычно в команде всегда есть хотя бы один человек, который программист, но в то же время хотя бы на базовом уровне понимает, что там на продакшене. Обычно он посредник между программистами и админами. Он и указывает беспомощным, как можно настроить среду, чтобы запустить юнит-тесты. Вы бы это назвали диктатурой девопсов. :)
И еще, как бы это помягче выразиться. Представим, что вот есть человек, который пишет серверную часть кода на рельсах. С этим приложением потом взаимодействуют и браузеры, и мобильники, и какие-нибудь корпоративные системы. И тут выясняется, что это парень не знает ни протокола отправки почты, ни пушей, ни как запросы доходят то его рельс из нжинкса. Только ActiveRecord выучил. Это неплохо, но такой человек может быть не более чем помощником. Если над ним не будет, как вы называете, диктатуры человека, который во всем этом разбирается, у команды будут большие проблемы, как только что-то сломается.
И еще, как бы это помягче выразиться. Представим, что вот есть человек, который пишет серверную часть кода на рельсах. С этим приложением потом взаимодействуют и браузеры, и мобильники, и какие-нибудь корпоративные системы. И тут выясняется, что это парень не знает ни протокола отправки почты, ни пушей, ни как запросы доходят то его рельс из нжинкса. Только ActiveRecord выучил. Это неплохо, но такой человек может быть не более чем помощником. Если над ним не будет, как вы называете, диктатуры человека, который во всем этом разбирается, у команды будут большие проблемы, как только что-то сломается.
А почему нельзя на пограничной инфраструктуре поддерживать безопасность системы, а внутри демилитаризованной зоны уже деплоить контейнеры, которые не нуждаются в постоянных секьюрити патчах?
Потому что "демилитаризованные зоны" — это из сказочных нулевых. Все громкие уязвимости таковы, что никакие красивые ленточки с надписями "ДЕМИЛИТАРИЗОВАННАЯ ЗОНА ХАККЕРАМ ДАЛЬШЕ НЕ ХОДИТЬ" просто не работают.
Пример из свежайшего: https://googleonlinesecurity.blogspot.com.cy/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html
Один неудачный револв PTR'а — и сервер имеет RCE. In ur face, так сказать, сквозь все DMZ.
90% современного применения контейнеров — это веб-приложухи, которые жуют клиентские данные. Иногда жуют, а иногда и исполняют что попало. Какой смысл их пихать в за dmz, если уязвимость как раз в кривой санитизации ввода, например?
Пример из свежайшего: https://googleonlinesecurity.blogspot.com.cy/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html
Один неудачный револв PTR'а — и сервер имеет RCE. In ur face, так сказать, сквозь все DMZ.
90% современного применения контейнеров — это веб-приложухи, которые жуют клиентские данные. Иногда жуют, а иногда и исполняют что попало. Какой смысл их пихать в за dmz, если уязвимость как раз в кривой санитизации ввода, например?
Это значит, кстати, что веб-приложение как раз стоит на границе, а все сервисы, к которым обращается это приложение, могу деплоиться контейнерами, потому что если уж кто-то получит RCE из-за ошибок парсинга входящих данных, то актуальность версии библиотек контейнеров уже никому не помогут. А если на границе всё хорошо, то и переживать за контейнеры не стоит. Т.е. безопасность системы слабо зависит от способа деплоя.
Ща вы мне расскажите про СУБД в докере. Запасаюсь попкорном.
Нет, я сказал сервисы, а не БД. Более того, у меня нет ни одного контейнера не только в продакшене, но и на dev и qa энвах, я просто интересуюсь технологией.
А у вас очень своеобразная манера вести дискуссию.
А у вас очень своеобразная манера вести дискуссию.
А про БД в докере я расскажу не раньше, чем оракл лицензирует деплоймент в контейнере, т.к. без этого нет смысла даже рассматривать такую возможность.
Мускуль на препрод среде вполне нормально работает
Что не так с СУБД в контейнерах? Очень удобно, особенно в рамках небольших проектов и в контексте разработки. Многие вот на RDS живут не тужат, те же контейнеры только с меньшим уровнем контроля.
В статье очень не хватает раздела про область применения docker и микросервисной архитектуры — где и когда лучше обойтись традиционным окружением.
Тут обычно всё просто. Если вы не понимаете нужно вам это или нет — значит вам это не нужно. Если вы в процессе решения проблем начали пытаться изобразить то, что описано выше — вы так или иначе сами наткнетесь на докер и уже будете знать зачем он нужен.
проследим мысль. С Docker у нас каждый микросервис находится в своем маленьком контейнере. Каждый контейнер со своими элементами инфраструктуры (базы данных, очереди, кэши) связывается по виртуальной сети, как если бы они были на разных машинах. Уже неплохо. Идем дальше.
Если вспомнить про такую штуку как docker-swarm, мы можем объеденить несколько серверов в одну большую виртуальную сеть, один большой класстер. В этом случае мы работаем с master-нодой swarm-а как с обычным docker-demon, и поднимаем все контейнеры. swarm-master в зависимости от выбранной стратегии раскидает контейнеры по серверам оптимально для нас. Вообще никакой мороки с деплойментом.
Если вспомнить про такую штуку как docker-swarm, мы можем объеденить несколько серверов в одну большую виртуальную сеть, один большой класстер. В этом случае мы работаем с master-нодой swarm-а как с обычным docker-demon, и поднимаем все контейнеры. swarm-master в зависимости от выбранной стратегии раскидает контейнеры по серверам оптимально для нас. Вообще никакой мороки с деплойментом.
Upstart / SystemD / Supervisor / launchd / God.rb / SysVinit, тысячи ихДа, вроде, абсолютно все из перечисленного умеет systemd, даже Docker-образы из Docker Hub качать и запускать.
Архаичные системы запуска сервисов, основанные на статичных конфигах идут в сад. На их место приходит docker daemon, который является init-подобным процессом умеющим следить за запущенными сервисами, перезапускать отвалившиеся, хранить коды выхода, логи, а главное, скачивать любые контейнеры с любыми сервисами на любой машине, не важно какая у машины «роль».
сначала я волновался, но после
понял что вы просто фантазёр.
контейнерам всё равно где крутиться, они объединены виртуальной сетью, видят и слышат друг друга отовсюду, включая девелоперкую машину в случае живой отладки.
понял что вы просто фантазёр.
Этот аргумент называется ad hominem и является одним из самых болезненных в споре, но его очень легко обнаружить. Применять его стоит в небольших количествах, чтобы собеседник не обвинил вас в переходе на личности. Второй целью психологической игры в демагогию является доведение оппонента в споре до кондиции, и при удачном исходе поведение оппонента станет неадекватным, а потому верить вам будут намного охотнее. Напомним, вы стоите выше толпы и не стесняетесь этого, поэтому расшатывание нервов собеседнику — приём надёжный, но опасный.
Я процитирую:
Переход на личности начался прямо в начале статьи. И дело не в
Конечно, если это статья для получения красивых циферок, то все понятнее. Вы много читали про докер и вам понравилось. Но для этого есть мегамозг.
Незаменимый админ полубог на скейтборде.
Переход на личности начался прямо в начале статьи. И дело не в
потере маржи, а в том что вы ничего не понимаете в проектировании систем и вводите в заблуждение других. Например
Само собой, такой кластер упирается в ширину сети между машинами, но и это уже прорыв для рядового девопса. А если еще и NAS запилить, то уже взрослый многофункциональный кластер получается.или
Это узкая специализация делает функцию реализуемую контейнером предсказуемой и масштабируемой.
Конечно, если это статья для получения красивых циферок, то все понятнее. Вы много читали про докер и вам понравилось. Но для этого есть мегамозг.
Для того чтобы запустить контейнер не нужно получать root на сервере, морочиться с ключами и настраивать систему деплоя. С докером деплой выглядит как сборка и настройка физического сервера дома, дольшейшего его всестороннего тестирования, а затем магического перемещения в произвольное количество детацентров одной командой. Для этого достаточно запустить docker run на своём ноутбуке и докер сам секьюрно подключится к серверу по TLS и всё запустит. Внутрь контейнера тоже попасть проще простого: docker exec -it %containername% bash и у вас в руках консоль для отладки.Дать пользователю права на запуск контейнеров == дать рута.
Докер не умеет в зависимости (например, гасить/перезапускать зависимые сервисы). Compose — смех и грех, не более чем для dev. Так что супервизоры никуда не денутся, оркестрация (пусть даже в виде ansible) — тоже.
Machine недавно ещё был кривыми костылями.
Оверлейная сеть на vxlan — дело хорошее. Но оно из коробки летает без какого-либо шифрования и подписи, т. е. реально надо делать внутри private dc или поверх vpn, что сказывается на производительности.
Дать пользователю права на запуск контейнеров == дать рута.
с версии 1.9 — нет.
Докер не умеет в зависимости (например, гасить/перезапускать зависимые сервисы). Compose — смех и грех, не более чем для dev. Так что супервизоры никуда не денутся, оркестрация (пусть даже в виде ansible) — тоже.
compose я лично использую исключительно для описания зависимостей и первоначальной настроки сервисов, а потом просто по одному поднимаю. Это удобно, но надо ждать версию 1.7 (почему-то они не добавили в 1.6 project name в docker-compose.yml). В целом же полноценную оркестрацию с учетом healthcheck можно спокойно построить поверх compose.
Что до супервизоров и прочего — docker swarm умеет переподнимать упавшие контейнеры и даже перекидывать их с умершей физической машины.
Machine недавно ещё был кривыми костылями.
Сейчас это довольно прикольная штука, правда я лично жду import/export машин, сейчас это оочень неудобно и использовать можно разве что в рамках ci сервера например (для деплоймента).
Но оно из коробки летает без какого-либо шифрования и подписи, т. е. реально надо делать внутри private dc или поверх vpn, что сказывается на производительности.
Разве без шифрования? Общение же с master нодой по TLS идет со своими сертификатами. А между нодами вы так же можете SSL пустить или VPN или еще чего. Да и как правило это уже реально сильно зависит от того каким образом вы все настроили.
с версии 1.9 — нетЕсли вы про userns, то с ним пока не очень понятно, в смысле безопасности.
Разве без шифрования? Общение же с master нодой по TLS идет со своими сертификатами. А между нодами вы так же можете SSL пустить или VPN или еще чего. Да и как правило это уже реально сильно зависит от того каким образом вы все настроили.Оверлейный vxlan, про который пишет автор публикации в предпоследнем абзаце, — без шифрования. Т. е. если использовать --link между контейнерами, то весь трафик внутри должен быть шифрованным и подписанным. Много ли людей будут это делать, а не воспринимать --link, как секьюрный оверлей? Я, например, сейчас использую tinc (p2p vpn), как паллиативное решение.
Кроме того, docker пока не интегрируется нормально с firewalld (на rhel/centos 7) кроме как `--iptables=false` при запуске docker daemon. А жить без этого — самоубийство, т. к. любой порт экспонированный на хост через -p/-P становится доступен всем в интернете. Как паллиатив можно использовать --ip на внутренний ip вместо 0.0.0.0.
весь трафик внутри должен быть шифрованным и подписанным
Для этого вы можете реализовать свой драйвер для сети (или поискать готовые, думаю скоро их прибавится)
Кроме того, docker пока не интегрируется нормально с firewalld
Да, это не удобно но всегда можно позакрывать порты на хост машине.
Для этого вы можете реализовать свой драйвер для сети (или поискать готовые, думаю скоро их прибавится)Автор говорил про vxlan, который не даёт enc+mac. То, что через некоторое время наделают новых реализаций оверлейных сетей — не сомневаюсь. Но это дело будущего, реализации и стабилизации ещё ждать и ждать.
Да, это не удобно но всегда можно позакрывать порты на хост машине.Если оставить `--iptables=yes` и `--ip=0.0.0.0`, то это вам не поможет, т. к. докер запихает DNAT-правила в таблицу nat и пакеты, пришедшие на прокинутый с помощью -p/-P порт будут заDNATены до того как дойдут до таблицы filter, где их попытаются зафильтровать. Я в какой-то момент очень внимательно разглядывал, что docker запихивает в iptables.
Сейчас это довольно прикольная штука, правда я лично жду import/export машин, сейчас это оочень неудобно и использовать можно разве что в рамках ci сервера например (для деплоймента).
А можно вот тут поподробнее? Что именно неудобно и каким боком Machine пересекается с CI?
Кто-то из использующих docker в продакшене сравнивал его с otto?
«Тема хорошая. И каменты интересные.»
Как пользователь XEN/KVM, так и не смог понять, для чего докер.
Микросервисы? Зачем?
Как пользователь XEN/KVM, так и не смог понять, для чего докер.
Микросервисы? Зачем?
Отличная статья. Спасибо
Хорошая статья, и докер — это действительно революция в деплойменте, но пару пессимистичных ноток я добавлю:
- Докер не отменяет ansible. Как-то нужно ставить сам докер, обновлять хост, конфигурировать данные для контейнера (ту же базу создать или правильный конфиг подложить при деплойменте). Докер также не отменяет кучу телодвижений при разворачивании кластера, той же монги например.
- логи. логгировать в sysout/syserr — ужасная идея, т.к. а) часто у приложений куда больше типов логов, а если их сливать в sysout, то потом не отпарсишь и б) сетевое логгирование не предлагать, т.к. если отправлять логи по сети синхронно, это поднимает вопрос "что делать, если получатель логов недоступен или отвечает очень медленно".
Для логов есть sentry/logstash/elastixsearch и еще туева хуча вещей, и модули кажется ко всем яп/фреймворкам для того, чтобы логи уходили прямо туда
Сам докер "ставится" с помощью docker-machine, но вы правы, Ansible очень даже нужен для всего этого дела, хочется же как-то одной командой все настраивать.
Логи, как уже отметили выше, обрабатываются с помощью специальных утилит, и stdout — самое оно. Тут я полностью придерживаюсь того, что предлагают 12factor в качестве подхода. Инфраструктура "сама решает" куда отправить логи.
Логи, как уже отметили выше, обрабатываются с помощью специальных утилит, и stdout — самое оно. Тут я полностью придерживаюсь того, что предлагают 12factor в качестве подхода. Инфраструктура "сама решает" куда отправить логи.
Увы, 12factor не отвечает на вопросы, сформулированные выше. Если вам нужны логи в кибане не в виде текста, а в виде структурированных данных, если у вас ненадежная сеть (привет, амазон), если вас волнуют потенциальные даунтаймы и узкие места в системе, если вы не можете себе позволить потерю логов из-за сетевых проблем, то...
Мы долго думали об этом, но варианта лучше и гибче, чем писать логи в каталог, смапленный наружу, где они подхватываются логсташем, который парсит их в зависимости от их типа и шлет в кибану json-документы, не нашли.
Мы долго думали об этом, но варианта лучше и гибче, чем писать логи в каталог, смапленный наружу, где они подхватываются логсташем, который парсит их в зависимости от их типа и шлет в кибану json-документы, не нашли.
Как-то нужно ставить сам докер, обновлять хост, конфигурировать данные для контейнера
docker-machine это все хэндлит. А конфигурировать данные должны сами контейнеры (у меня для этого просто отдельный скриптик есть который при запуске контейнера все делает). Однако Ansible всеравно нужен для более тонкой конфигурации самого хоста (порты позакрывать/пооткрывать, ключи/сертификаты добавить и многое другое). Но это уже задачи чисто админов. Docker же — связующий инструмент между админами и разработчиками, что бы у последних всегда было то окружение, которое будет развернуто на сервере. Это способ улучшения взаимодействия между этими ребятами.
логи. логгировать в sysout/syserr — ужасная идея
Это поумолчанию. Там есть тонны драйверов и т.д. + никто не запрещает использовать syslog тот же.
честно говоря, поднимать ВМ для запуска докера под линуксом для меня выглядит извращением.
честно говоря, поднимать ВМ для запуска докера под линуксом для меня выглядит извращением.
О чем вы, какая VM? docker-machine помимо virtualbox может вам и дроплеты в DO создать и EC2 инстанс в AWS поднять. Эта штука нужна для того что бы управлять машинами, на которых крутятся докер демоны. Просто удаленные хосты. Выполнил одну команду — переключился на работу с удаленным хостом, запустил чего-то (например через docker-compose), пошел дальше.
Оно вам и docker поставит на удаленный сервак, и swarm master сконфигурит минимально… словом это инструмент провиженинга.
Давно, когда я был уже восторженным, но еще не очень аккуратным программистом, ленивый админ дал мне шел прямо на боевом сервере. А я как раз учился писать форкающиеся демоны. Ну, и как бывает, перепутал
if с else после форка… Вот и к вам придет такой я из прошлого и примонтирует ваш корень куда не положено, а затем случайно сделает rm /usr /local. Да и грязь выметать удобнее, и холодный старт протестить ничего не стоит, и кластерок сэмитировать можно.Спасибо за спасибо и за пессимизм. Давайте его обсудим.
Докер таки отменяет системы конфигурации внутренностей серверов. Теперь можно сконцентрироваться на более высокоуровневой задаче — оркестрации. И почему бы не ansible, да.
Да, синхронные логи — это плохо. Стоит забиться буферу на передачу, как логирующий процесс залочится на записи. Однако, если класть буфер всё так же асинхронно на диск, то почему бы не заиметь себе логи реального времени по сети?
Докер не отменяет ansible
Докер таки отменяет системы конфигурации внутренностей серверов. Теперь можно сконцентрироваться на более высокоуровневой задаче — оркестрации. И почему бы не ansible, да.
отправлять логи по сети синхронно
Да, синхронные логи — это плохо. Стоит забиться буферу на передачу, как логирующий процесс залочится на записи. Однако, если класть буфер всё так же асинхронно на диск, то почему бы не заиметь себе логи реального времени по сети?
Около года успешно используем у себя докер вместе с кубером, однако время от времени вылазят неочевидные проблемы по типу таких
В статье:
и
а еще
думаю, что и прочие амазоны с оушенами тоже не на встроенной сетевухе работают ;)
Однако, да, неочевидных проблем с такой свежей и резкой технологией ждать надо.
The Linux Kernel has a bug that causes … Docker on IPv6 … receive corrupt data.
и
Docker’s default NAT networking is not affected
а еще
Google Container Engine is likely protected from hardware errors by its virtualized network
думаю, что и прочие амазоны с оушенами тоже не на встроенной сетевухе работают ;)
Однако, да, неочевидных проблем с такой свежей и резкой технологией ждать надо.
Ну такое происходит часто с новыми штуками.
Есть много плагинов сборки логов и отправки их на анализ.
А можно вот тут поподробнее? Не слыхал, что к докеру бывают плагины.
Для него есть и драйвера логгеров, и плагины для волумов и сетей… словом… и это все еще будет развиваться но и уже немало.
Кстати, кому интересно – мы тут подняли слак для русскоязычных любителей докера. Обсуждаем все про контейнеры, начиная от кубернитса, заканчивая flanneld
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Поняв Docker