Комментарии 90
А можно хоть какое-то сравнение с Vagrant привести?
Vagrant — менеджер виртуальных машин, который может использовать VirtualBox, Parallels, VMWare и даже Docker. Docker запускает Linux-контейнеры и может нативно работать только под Linux. Vagrant предназначен для целей разработки и тестирования, а Docker подходит для продакшна. Более детально тут и тут.
Если вы работаете в Linux Docker вам очевидно будет приятнее. Он не требует тяжелых VirtualBox.
Особенностью докера является то, что докер-контейнер ориентирован на запуск внутри себя одного процесса. Если вы привыкли создавать образы виртуалок в Vagrant с Mysql, Nginx, Redis, etc, то в случае с докером, вам скорее всего понадобится создавать свой контейнер на сервис и затем линковать их вместе. Почему так? С одной стороны, так проще переключаться между сервисами — в секунды можно поменять MySQL на Percona или Maria. С другой — докер контейнер не совсем предназначен для того, в него заходили через ssh, как это происходит в вагранте. Такая возможность есть, но зачем ходить в запущенный контейнер через ssh, если можно просто запустить контейнер с интерактивной bash сессией?
Т.е. если вы хотите использовать докер для виртуализации, вам придется чуть поменять подход к созданию среды. Кроме того, для запуске на на Windows, Mac докер всё равно потребует от вас наличия VirtualBox.
Особенностью докера является то, что докер-контейнер ориентирован на запуск внутри себя одного процесса. Если вы привыкли создавать образы виртуалок в Vagrant с Mysql, Nginx, Redis, etc, то в случае с докером, вам скорее всего понадобится создавать свой контейнер на сервис и затем линковать их вместе. Почему так? С одной стороны, так проще переключаться между сервисами — в секунды можно поменять MySQL на Percona или Maria. С другой — докер контейнер не совсем предназначен для того, в него заходили через ssh, как это происходит в вагранте. Такая возможность есть, но зачем ходить в запущенный контейнер через ssh, если можно просто запустить контейнер с интерактивной bash сессией?
Т.е. если вы хотите использовать докер для виртуализации, вам придется чуть поменять подход к созданию среды. Кроме того, для запуске на на Windows, Mac докер всё равно потребует от вас наличия VirtualBox.
Вот насчет одного процесса на контейнер вы ошибаетесь. Главная идея докера — сделать контейнер самодостаточным. Вас никто не ограничивает в запуске процессов внутри контейнера — вот наглядное подтверждение phusion.github.io/baseimage-docker/.
Ssh внутри контейнера — это перебор, конечно, я не спорю. Но в остальном — в конейнере может сидеть все, что вам там может понадобиться.
Ssh внутри контейнера — это перебор, конечно, я не спорю. Но в остальном — в конейнере может сидеть все, что вам там может понадобиться.
Тоже использую этот образ как базовый, очень удобно.
А SSH внутри всё же использую, как-то не получается к рабочему запущенному контейнеру подключиться к интерактивной bash сессии, поэтому в некоторых контейнерах работает SSH.
А SSH внутри всё же использую, как-то не получается к рабочему запущенному контейнеру подключиться к интерактивной bash сессии, поэтому в некоторых контейнерах работает SSH.
Вот это пробовали? github.com/jpetazzo/nsenter
да, я знаю, про baseimage, но с ним получается какая-то обрезання виртуалка.
Его один процесс это runit, хотя конечно было б намного удобнее, если б это был upstart. И если запущен контейнер с upstart, вам ssh становится просто необходим, чтобы войти в этот контейнер. Потому, оценив плюсы-минусы решил всё-таки использовать несколько контейнеров.
Его один процесс это runit, хотя конечно было б намного удобнее, если б это был upstart. И если запущен контейнер с upstart, вам ssh становится просто необходим, чтобы войти в этот контейнер. Потому, оценив плюсы-минусы решил всё-таки использовать несколько контейнеров.
А виртуализация там как реализована? OpenVZ, kvm, xen? Или что-то свое похожее на openvz?
Там нет виртуализации. Там аналог lxc — микс из cgroups и namespaces. github.com/docker/libcontainer
Что-то похожее на openvz. Есть низкоуровневые LXC, работающие на основе cgroups и namespaces. Docker работает поверх LXC. Openvz тоже постепенно вроде на LXC переходит, что позволяет сильно уменьшить размер патча ядра и даже, теоретически, в итоге перейти на работу поверх ванильного ядра.
Докер решил отказаться от LXC. Последние версии используют libcontainer для контейнеризации. Та же хрень, на самом деле, но реализация другая.
Если я правильно понял, то раньше поддерживались три типа контейнеров — lxc, libvirt и systemd-nspawn и все они были внешние. А теперь в дополнение к этим они решили в сотрудничестве с parallels запилить свою вариацию на тему lxc, чтобы иметь больше свободы и не возиться с различными версиями библиотек. При этом у parallels есть свой libct со схожими задачей и подходами. Зоопарк получается… Надеюсь, придёт всё к единому знаменателю.
Может кому-то пригодится — Docker — краткое практическое руководство
НЛО прилетело и опубликовало эту надпись здесь
Допустим, у меня есть DB которая работает на отдельном хосте и есть несколько приложений, которые работают с этой DB. Как мне мигрировать все это на компьютер разработчика и обратно?
Чем больше читаю документацию к Docker, тем меньше понимаю смысл его использования. Чуть упрощая с софтом мы получаем проблемы со сложной конфигурацией и работой на разных хостах.
У кого есть опыт работы со сложными конфигурациями, пожалуйста, поделитесь им?
Чем больше читаю документацию к Docker, тем меньше понимаю смысл его использования. Чуть упрощая с софтом мы получаем проблемы со сложной конфигурацией и работой на разных хостах.
У кого есть опыт работы со сложными конфигурациями, пожалуйста, поделитесь им?
Создаете из запущенных контейнеров с базой и приложениями образ, экспортируете в файлы, копируете на компьютер разработчика, импортируете образы, создаете контейнеры и запускаете. Обратно так же.
Они на разных хостах. У них разные настройки подключения к БД. Мне кажется, с ходу так не получится.
Перенастроить подключения на другие адреса придется, но обычно это не большая проблема.
В обратную сторону опять надо перенастраивать. В общем просто докером тут не обойтись. Нужно делать большую обвязку, как мне кажется.
У Docker есть инструменты для связывания, например, ключик
--link. Плюс в инфраструктуре Docker есть уже свои новые инструменты для облегчения связывания. Вот статья на Хабре: habrahabr.ru/post/215653/Но это все работает только в пределах одного хоста?
Связывание по --link? Да. Связывание через другие инструменты, типа SkyDNS? Полагаю, что нет, хотя на этот счёт ещё подробно не разбирался, только начинаю изучать межконтейнерное взаимодействие.
если верить документации, то линк работает только между контейнерами в рамках одного хоста. Еще есть вариант когда в связанных контейнерах выставляются нужные ENV переменные.
А я говорю о другом, когда хостов несколько. Плюс когда нужно перемещать конейнеры из одной сложной среды в другую сложную среду. И тут уже непонятно, зачем нужен докер.
А я говорю о другом, когда хостов несколько. Плюс когда нужно перемещать конейнеры из одной сложной среды в другую сложную среду. И тут уже непонятно, зачем нужен докер.
>линк работает только между контейнерами
Я так и писал — «да, связывание только в пределах хоста».
>А я говорю о другом, когда хостов несколько
Вот для этого, как понимаю, всякие SkyDNS и предназначаются. Хотя при желании (если SkyDNS этот процесс не облегчает, как писал, я его ещё не щупал) можно и полноценный DNS настроить. Типа, контейнер запускается и сразу сообщает серверу имён свой новый IP.
>Плюс когда нужно перемещать конейнеры из одной сложной среды в другую сложную среду. И тут уже непонятно, зачем нужен докер.
Так, вроде бы Docker и имеет что-то на тему переноса контейнеров между хостами. Тоже не разбирался, мне пока хватает задач в рамках хоста, но в анонсах про CoreOS слышал, что там механизм переноса контейнеров с одного хоста кластера на другой из коробки есть. Хотя, может, это и не средствами Docker.
Я так и писал — «да, связывание только в пределах хоста».
>А я говорю о другом, когда хостов несколько
Вот для этого, как понимаю, всякие SkyDNS и предназначаются. Хотя при желании (если SkyDNS этот процесс не облегчает, как писал, я его ещё не щупал) можно и полноценный DNS настроить. Типа, контейнер запускается и сразу сообщает серверу имён свой новый IP.
>Плюс когда нужно перемещать конейнеры из одной сложной среды в другую сложную среду. И тут уже непонятно, зачем нужен докер.
Так, вроде бы Docker и имеет что-то на тему переноса контейнеров между хостами. Тоже не разбирался, мне пока хватает задач в рамках хоста, но в анонсах про CoreOS слышал, что там механизм переноса контейнеров с одного хоста кластера на другой из коробки есть. Хотя, может, это и не средствами Docker.
Я об этом и говорю, как только мы выходим за рамки одного хоста — начинается серьезная доработка и подключение сторонних инструментов.
Чем в таком сценарии помогает докер, мне до сих пор не понятно. Все что я видел кажется сложнее связки API облака + Puppet + Git
Чем в таком сценарии помогает докер, мне до сих пор не понятно. Все что я видел кажется сложнее связки API облака + Puppet + Git
Docker в этом случае остаётся тем же, чем и был — удобным гибким инструментом для развёртывания легковесный контейнеров :) Сам по себе он не панацея ни в каком из вариантов. Это просто полезный инструмент.
Вот, ещё одно отличное и простое решение попалось:
github.com/zettio/weave
Качаем один скриптик, запускаем docker-контейнеры через него и… они все объединяются в единую сеть (с указанными при запуске IP) с прозрачным доступом друг к другу, даже при расположении в разных сетях.
github.com/zettio/weave
Качаем один скриптик, запускаем docker-контейнеры через него и… они все объединяются в единую сеть (с указанными при запуске IP) с прозрачным доступом друг к другу, даже при расположении в разных сетях.
презжде всего Docker обеспечивает Immutable Server Pattern.
Тоесть с точки зрения девелопера вся его аппликация собирается в контейнер один раз.
Со всей конфигой, деревом зависимостей, утилит если надо. и бежит как на его ноуте, как в различных тестовых стендах, так и в облаке одинаково… Не зависомо от того что преустановленно на этих машинах.
В этом бонус…
А поскольку сам Docker инструмент в линуксовой парадигме ( один интрумент решает одну задачу — но хорошо) Docker не занимается оркестрацией…
Но есть целый зоопракр на эту тему…
— SmartStack’s components – Nerve and Synapse
— Kubernetes (google)
— попуряные решения на etcd, Serf, Zookeeper с разной степенью необходимости прикладывания ручек.
IMHO Очень интересно выглядит CoreOs. Пока мне хватает одного хоста… Но смотрю уже на них. Немног сыроваты еще.
Тоесть с точки зрения девелопера вся его аппликация собирается в контейнер один раз.
Со всей конфигой, деревом зависимостей, утилит если надо. и бежит как на его ноуте, как в различных тестовых стендах, так и в облаке одинаково… Не зависомо от того что преустановленно на этих машинах.
В этом бонус…
А поскольку сам Docker инструмент в линуксовой парадигме ( один интрумент решает одну задачу — но хорошо) Docker не занимается оркестрацией…
Но есть целый зоопракр на эту тему…
— SmartStack’s components – Nerve and Synapse
— Kubernetes (google)
— попуряные решения на etcd, Serf, Zookeeper с разной степенью необходимости прикладывания ручек.
IMHO Очень интересно выглядит CoreOs. Пока мне хватает одного хоста… Но смотрю уже на них. Немног сыроваты еще.
Как шарить Hostname, username и пароли к БД?
У Amazon Beanstalk все происходит через переменные окружения, в них хранится все это дело
У Amazon Beanstalk все происходит через переменные окружения, в них хранится все это дело
Вы правы совершенно, к докеру осознанно надо подходить. Вокруг него слишком много маркетингового буллшита, хотя технология сама по себе внимания, безусловно, заслуживает. И про сущности вы правы, ментальный оверхед там некислый получается. А выносить все процессы в отдельные докеры, не группируя их по ролям, как на мой взгляд — так полный бред.
Почитайте вот:
devopsu.com/blog/docker-misconceptions/
news.ycombinator.com/item?id=7868791
www.infoworld.com/article/2607966/application-virtualization/4-reasons-why-docker-s-libcontainer-is-a-big-deal.html
Я его собираюсь использовать группируя процессы по задачам (вебсервер, например — ngnix, php5-fpm, ssh обязательно потому что в гробу я видел «свой особый подход» и т.д.), и фактически получая более удобный в управлении lxc, не более. Основная идея состоит в том, чтобы уменьшить количество магии до минимума, магия до добра доводит редко.
Почитайте вот:
devopsu.com/blog/docker-misconceptions/
news.ycombinator.com/item?id=7868791
www.infoworld.com/article/2607966/application-virtualization/4-reasons-why-docker-s-libcontainer-is-a-big-deal.html
Я его собираюсь использовать группируя процессы по задачам (вебсервер, например — ngnix, php5-fpm, ssh обязательно потому что в гробу я видел «свой особый подход» и т.д.), и фактически получая более удобный в управлении lxc, не более. Основная идея состоит в том, чтобы уменьшить количество магии до минимума, магия до добра доводит редко.
Из того что я узнал я сделал вывод, что докеру явно не хватает возможностей по конфигурации профилей «из коробки». Приходится использовать внешний инструмент для конфигураций, но тогда в облачной среде выгоды от использования докера нет. Тот же puppet позволяет накатить любую конфигурацию на шаблонный инстанс по иерархии роль_сервера/fqdn.
А вот для работы внутри отдела разработки штука стоящая и я пожалуй буду ее внедрять.
А вот для работы внутри отдела разработки штука стоящая и я пожалуй буду ее внедрять.
>архитектуру их приложений разделить на более мелкие компоненты, которые будут запускаться в изолированных контейнерах, что позволит достичь большего ускорения, параллелизации исполнения и надежности.
А можно поподробнее, как именно размазывание компонентов по контейнерам позволит достичь большего ускорения и параллелизации по сравнению с ситуацией, когда это просто отдельные процессы?
Я тут предполагаю, что количество и производительность физических серверов не меняется
А можно поподробнее, как именно размазывание компонентов по контейнерам позволит достичь большего ускорения и параллелизации по сравнению с ситуацией, когда это просто отдельные процессы?
Я тут предполагаю, что количество и производительность физических серверов не меняется
Разбив сложную систему на составляющие проще определить, в какой возникают проблемы производительности и починить.
Мониторить виртуальные инстансы в облаке или виртуальные инстансы в виртуальных инстансах в облаке?
Мне кажется, первый вариант проще. Меньше прослоек, меньше глюков.
Мне кажется, первый вариант проще. Меньше прослоек, меньше глюков.
Образ докера — НЕ виртуальный инстанс. Это просто слепок уже настроенного и отлаженного сервиса со всеми зависимостями. Мониторинг — и там, и там — одинаковый. Однако, в случае докера резко упрощается настройка (ей, по-сути, занимаются девелоперы), доставка контейнера на целевую машину и развертывание.
Давайте проще, образ — это read-only шаблон. Его мониторить не нужно. Нужно мониторить контейнеры, которые мы получаем из образов.
А вот упрощается ли задача мониторинга нескольких контейнеров на одном виртуальном хосте? Не думаю.
А вот упрощается ли задача мониторинга нескольких контейнеров на одном виртуальном хосте? Не думаю.
А в чем разница между тем, чтобы мониторить несколько сервисов на одном инстансе, или несколько контейнеров с сервисами на одном инстансе?
Я, право, не вижу разницы. У нас, например, каждый конейтнер содержит внутри себя все неодходимое для его мониторинга — информацию о метриках, которые генерирует, проверки, которые на нем нужно производить, и т. д. При старте он просто добавляется в систему мониторинга на основе информации, которая уже зашита в него.
Я, право, не вижу разницы. У нас, например, каждый конейтнер содержит внутри себя все неодходимое для его мониторинга — информацию о метриках, которые генерирует, проверки, которые на нем нужно производить, и т. д. При старте он просто добавляется в систему мониторинга на основе информации, которая уже зашита в него.
Мне кажется, что отдельный сервисы лучше запускать в отдельных виртуальных машинах. Чем мешать туда еще и второй слой виртуализации.
Да ну нет там второго слоя виртуализации. Там просто разграничение ресурсов. И железобетонная стена между процессами. Ну и не факт, что лучше так, как вы сказали. Когда количество сервисов (и хостов) растет, выгодно перейти к host-agnostic схеме, когда при каждом новом деплое вам просто без разницы, на каком хосте запустится новый сервис. Вот, например, эти ребята могут много сказать по теме mesosphere.io/
Так, то гораздо проще добиваться отказоустойчивости и масштабироваться. Так гораздо проще поддерживать несколько разных версий кластеров. Ну и куча других преимуществ, на самом деле.
Так, то гораздо проще добиваться отказоустойчивости и масштабироваться. Так гораздо проще поддерживать несколько разных версий кластеров. Ну и куча других преимуществ, на самом деле.
Можно назвать это разграничением ресурсов, если хотите. Но я простоты не вижу. Сейчас любой более-менее продвинутый облачный хостер позволяет через api создавать инстансы, в которые можно разворачивать образы, которые могут отлично конфигурировать себя через puppet.
И на мой взгляд такая схема проще. Хотя, пойду еще почитаю.
И на мой взгляд такая схема проще. Хотя, пойду еще почитаю.
У докера есть один несравненный плюс — проще реализовывать HA. У нас много серверов, на котором вертится Proxmox VE — это Debian + OpenVZ. Как системный администратор, начинаю изучать вопрос с докером, так как развернуть HA-класер на докере гораздо проще, чем на OpenVZ. В теории)
Изучу вопрос, посмотрим затраты и плюсы при переходе ан новую платформу и, возможно, переедем.
Изучу вопрос, посмотрим затраты и плюсы при переходе ан новую платформу и, возможно, переедем.
Кстати вариант, но я бы еще посмотрел в сторону Promox API + Puppet. С докером (если я правильно понимаю) начнется развесистая конфигурация сети, например, если вдруг окажется, что разные части HA находятся на разных хостах. Да и вопрос конфигурации сервисов докер не отменяет, опять же придется использовать какой-нибудь инструмент. Но тогда появится вопрос, зачем в этом всем нужен докер.
еще 10 лет назад мы создавали «виртуальный и защищенный» образ просто используя Linux команду chroot, после чего мы получали абсолютно изолированную оболочку на базе основного ядра, ставь себе что угодно, любые пакеты, на функционал основной системы это не влияло.
Docker делает тоже самое, только легче?
Docker делает тоже самое, только легче?
Только тяжелее. LXC, лежащий в основе docker часто называют chroot на стероидах. Chroot, например, не обеспечивает изолированного сетевого стека, пространства процессов, пространства монтирования и т. п. Всё это, по умолчанию, включено в docker.
Запуская приложение в docker-контейнере вы получаете для этого приложения более высокий уровень изоляции. Например, можно запустить для разных приложений копии БД, которые биндятся на один и тот же порт не мешая друг другу (и, соответственно, разворачиваются из одного образа, т. к. конфигурацию необходимости изменять нет) дав каждому приложению доступ к своей БД.
Запуская приложение в docker-контейнере вы получаете для этого приложения более высокий уровень изоляции. Например, можно запустить для разных приложений копии БД, которые биндятся на один и тот же порт не мешая друг другу (и, соответственно, разворачиваются из одного образа, т. к. конфигурацию необходимости изменять нет) дав каждому приложению доступ к своей БД.
Dcoker это гораздо больше чем chroot.
— Aufs,
— Repo,
— API
— Лучшая изоляция
— сетеые интерефейсы
— и т.д.
Все что нужно для того что бы это полюбили девелоперы не только опсы.
— Aufs,
— Repo,
— API
— Лучшая изоляция
— сетеые интерефейсы
— и т.д.
Все что нужно для того что бы это полюбили девелоперы не только опсы.
Все-таки можно уточнить. Мы говорим девелоперам, что теперь они могут запаковать со своим приложением половину системы (библиотеки, системные тулы нужных версий) и это в таком же виде будет установлено на DEV, QA, PROD? Так?
Или это что-то другое?
Или это что-то другое?
Ну если упростить да. Только не все что запаковано переносится… между системами… только недостаающие слои
Ну вот. Опять стало менее понятно. Недостающие слои — это что? Можете привести пример, пожалуйста?
Не ну как-бы сложно в каменте обьяснить что такое Докер и с чем его едят…
Читайте разбирайтесь. Про слои наглядно тут…
docs.docker.com/terms/layer/
ну и вот на вскидку пример с консолью
tuhrig.de/layering-of-docker-images/
Читайте разбирайтесь. Про слои наглядно тут…
docs.docker.com/terms/layer/
ну и вот на вскидку пример с консолью
tuhrig.de/layering-of-docker-images/
> Мониторить виртуальные инстансы в облаке или виртуальные инстансы в виртуальных инстансах в облаке?
Тут в одном блоге одного чувака про CoreOS/Docker проскакивала вот такая картинка
Интересно, как такое можно применять, например, в классическом шаредхостинге.
и как ведется контроль за ресурсами этого «контейнера», раз уже мы заговорили про проблемы производительности
и как ведется контроль за ресурсами этого «контейнера», раз уже мы заговорили про проблемы производительности
Насчет шаред-хостинга не готов сказать — просто никогда не пользовался такими. Совсем не про то, но можете поглядеть AWS Elastic Beanstalk. С недавних пор оно умеет запускать докер-образы.
Насчет контроля за ресурсами — докер для этого использует линуксовый механизм cgroups. Можно ограничить размер используемой памяти, CPU, использование блочных устройств. Есть свои заморочки, конечно. Но в целом, если довести до ума, работает, как часы.
Насчет контроля за ресурсами — докер для этого использует линуксовый механизм cgroups. Можно ограничить размер используемой памяти, CPU, использование блочных устройств. Есть свои заморочки, конечно. Но в целом, если довести до ума, работает, как часы.
не, мне интересно понять, может ли эта фиговина не дать одному проломанному сайту нагадить остальным и хост машине и не даст ли она запустить стопицот тыщ процессов php/сендмыла, которые сожрут все что можно и что нельзя по ресурсам и укладут с la=~1500 хостовый сервер.
не городить же openvz или еще что ради такого.
не городить же openvz или еще что ради такого.
А что там с openvz? Оно же на lxc работает? По уровню изоляции, libcontainer (на котором работает докер) и lxc — близнецы-братья. Механизмы изоляции совершенно одни и те же. Просто разная реализация. Для контейнера создаются свои неймспейсы. Для каждого из них задается свой лимит памяти (на уровне cgroups, опять же). Для каждого из конейнеров, по сути, работает свой менеджер ресурсов. OOM-killer приходит вовремя.
Короче, оно спроектированно так, чтобы его можно было использовать в описанном Вами случае. Вопрос в радиусе кривизны рук админа =)
Короче, оно спроектированно так, чтобы его можно было использовать в описанном Вами случае. Вопрос в радиусе кривизны рук админа =)
Так. Возникает вопрос. Если это аналогичная OpenVZ штуковина, то из-под OpenVZ контейнера его запустить не получится, так?
Я, честно говоря, не работал с openvz, поэтому уведу тему чуть-чуть в другое русло =)
Внутри докер-контейнера можно запустить еще один демон докера. Правда, для этого корневому контейнеру (где крутится демон докера) надо выдать соответствующий набор привелегий (который, разумеется, делает этот корневой контейнер крайне небезопасным). Что произойдет с лимитами cgroups — не могу сказать, к сожалению.
Учитывая, что мехинизмы изоляции openvz и докер почти идентичны, может быть чего-то подобного можно добиться и от openvz. Но смысла в таких манипуляциях не очень много.
Внутри докер-контейнера можно запустить еще один демон докера. Правда, для этого корневому контейнеру (где крутится демон докера) надо выдать соответствующий набор привелегий (который, разумеется, делает этот корневой контейнер крайне небезопасным). Что произойдет с лимитами cgroups — не могу сказать, к сожалению.
Учитывая, что мехинизмы изоляции openvz и докер почти идентичны, может быть чего-то подобного можно добиться и от openvz. Но смысла в таких манипуляциях не очень много.
Ну смысл — разворачивать готовый контейнер на виртуалках у хостера.
Не, цель я понял. Я чуть другое имел в виду. Демону докера нужна привелегия CAP_SYS_ADMIN. Если openvz позволяет выдвать специфичные привелегии своим контейнерам, то уверен, что никакой хостер не даст CAP_SYS_ADMIN. Потому как если его дать, то какой вообще толк от такой изоляции?
демон докера запускается от рута, поэтому если какое-либо сервис в докере тоже запущен от рута (например, апач), то это потенциально небезопасно.
Это заблуждение.
лол это не заблуждение.
This means that in most cases, containers will not need «real» root privileges at all. And therefore, containers can run with a reduced capability set; meaning that «root» within a container has much less privileges than the real «root».
This means that even if an intruder manages to escalate to root within a container, it will be much harder to do serious damage, or to escalate to the host.
docs.docker.com/articles/security/
Much harder, но не impossible.
This means that in most cases, containers will not need «real» root privileges at all. And therefore, containers can run with a reduced capability set; meaning that «root» within a container has much less privileges than the real «root».
This means that even if an intruder manages to escalate to root within a container, it will be much harder to do serious damage, or to escalate to the host.
docs.docker.com/articles/security/
Much harder, но не impossible.
Пожалуйста, покажите, как вы перевели этот фрагмент. Мне кажется, вы неправильно его поняли. Ну, либо поправьте меня, если не прав я.
Здесь говорится о том, что если злоумышленник сможет получить привелегии рута внутри конейнера, хостовой системе будет по-барабану на это. Единственное, что злоумышленник сможет повредить — содержимое контейнера. Рут внутри контейнера и хостовый рут — две большие разницы.
Для того, чтобы выйти на хост, содержимое контейнера должно выбраться из неймспейсов, в которых запущено. Разумеется, механизм неймспейсов этого не предусматривает. Конечно, если в неймспейсах найдется баг и Вы сможете его эксплуатрировать — хост ваш. Но при чем тут докер? Архитектурных способов покинуть контейнер не существует. А баги — они могут быть везде.
Здесь говорится о том, что если злоумышленник сможет получить привелегии рута внутри конейнера, хостовой системе будет по-барабану на это. Единственное, что злоумышленник сможет повредить — содержимое контейнера. Рут внутри контейнера и хостовый рут — две большие разницы.
Для того, чтобы выйти на хост, содержимое контейнера должно выбраться из неймспейсов, в которых запущено. Разумеется, механизм неймспейсов этого не предусматривает. Конечно, если в неймспейсах найдется баг и Вы сможете его эксплуатрировать — хост ваш. Но при чем тут докер? Архитектурных способов покинуть контейнер не существует. А баги — они могут быть везде.
>This means that even if an intruder manages to escalate to root within a container, it will be much harder to do serious damage, or to escalate to the host.
Это значит, что если атакующий получит рут в контейнере, для него будет гораздно сложнее нанести ущерб системе, или получить доступ к хосту.
Я еще в другом месте читал, что угрозы есть, хотя может о них и неизвестно. Но если вы, например, поставите --net=«host» ('host': use the host network stack inside the container. Note: the host mode gives the container full access to local system services such as D-bus and is therefore considered insecure.), то получив рут, злоумышленник получит доступ к системе. Или например если поставлен маунт папки на хосте к папке докера, то к ней тоже будет получен доступ. Я согласен, это не «прямая уязвимость», а скорее второстепенная, но она существует, и поэтому нужно думать, когда настраиваешь контейнеры. «Архитектурных способов покинуть контейнер не существует. » — шифрование тоже невозможно было взломать, до баги в OpenSSL.
Это значит, что если атакующий получит рут в контейнере, для него будет гораздно сложнее нанести ущерб системе, или получить доступ к хосту.
Я еще в другом месте читал, что угрозы есть, хотя может о них и неизвестно. Но если вы, например, поставите --net=«host» ('host': use the host network stack inside the container. Note: the host mode gives the container full access to local system services such as D-bus and is therefore considered insecure.), то получив рут, злоумышленник получит доступ к системе. Или например если поставлен маунт папки на хосте к папке докера, то к ней тоже будет получен доступ. Я согласен, это не «прямая уязвимость», а скорее второстепенная, но она существует, и поэтому нужно думать, когда настраиваешь контейнеры. «Архитектурных способов покинуть контейнер не существует. » — шифрование тоже невозможно было взломать, до баги в OpenSSL.
Ну, начнем с конца. Баг в OpenSSL (мы же про heartbead сейчас, да?) — не является ни уязвимостью алгоритма шифрования, ни протокола. Это баг в библиотеке. Но вернемся к контейнерам. Опция --net=host тупо не создает сетевой неймспейс для контейнера. Т.е., с точки зрения сетевого уровня, содержимое контейнера запущено на хосте. Разумеется, это небезопасно. Аналогично и с маунтами — нефиг монтировать в контейнер то, к чему у контейнера не должно быть доступа. В этом плане Вы, вроде как, все правильно говорите. Но все это не имеет никакого отношения ни к контейнерам, ни к докеру. От докера можно добиться безопасности, действуя на него только снаружи — внутри контейнера можно запускать все что угодно, и вероятность того, что это «что угодно» навредит хосту, стремится к нулю. Сложность преодоления неймспейсов, которыми ограничен докер, по сути такая же, как сложность покинуть гипервизор виртуальной машины.
К тому же, мы говорим не просто о контейнерах, а о Докер контейнерах, а это немного больше чем просто контейнеры. Они запускаются и управляются через димон докера, который требует рута. Так что если найти способ эксплуатировать уязвимость в димоне, то можно получить доступ к системе. Поэтому имея рут в контейнере, можно выйти на димон (не уверен как, правда, я не супер спец), и скомпрометировать хост.
Вот именно в последнем утверждении вы и ошибаетесь. «Выйти на демон» из контейрена уже нельзя. При запуске процесса в новых неймспейсах, его связь с хостом теряется.
Начните отсюда. Тут все достаточно просто и неплохо описано blog.dotcloud.com/under-the-hood-linux-kernels-on-dotcloud-part
Начните отсюда. Тут все достаточно просто и неплохо описано blog.dotcloud.com/under-the-hood-linux-kernels-on-dotcloud-part
Какой-нить апач тоже запускается от root'а, но его child'ы запускаются уже как httpd/apache/www пользователь в зависимости от дистрибутива. Так что это не показатель
Мне вот любопытно… сделали мы сегодня кучу контейнеров с разными приложениями, таскаем их туда-сюда, запускаем, останавливаем, никакого вендор-лока и прочее масштабирование — в общем, мечта. А что мы будем делать через полтора года, когда обнаружится, что используемые сто контейнеров (с кучей уникальных отличий, накопившихся за это время) мало-мало устарели, heartbleed там очередной или что ещё — и их все нужно регулярно поддерживать и обновлять?
Сейчас у нас 3 сервера/ОС и на них 50 приложений/сервисов/сайтов, а с докером будет 53 ОС плюс те же 50 приложений.
Сейчас у нас 3 сервера/ОС и на них 50 приложений/сервисов/сайтов, а с докером будет 53 ОС плюс те же 50 приложений.
По поводу устаревания ПО решает вопрос сборка образов на основе Dockerfile и необходимостью конфигурировать все свои образы каскадно для того, чтобы изменение одного из образов влияло на изменение этого слоя в других образах, например:
— базовый образ ОС
— — базовый набор LAMP (apache, mysql, php)
— — — специфичный набор для приложения 1
— — — — приложение 1
— — — специфичный набор для приложения 2
— — — — приложение 2
…
— — — специфичный набор для приложения N
— — — — приложение N
— базовый образ ОС
— — базовый набор LAMP (apache, mysql, php)
— — — специфичный набор для приложения 1
— — — — приложение 1
— — — специфичный набор для приложения 2
— — — — приложение 2
…
— — — специфичный набор для приложения N
— — — — приложение N
В теории. Вопрос в том, что будет на практике. Каскадные изменения имеют дурную привычку всё ломать в неожиданных местах — посмотрите например на CSS… интересно, как скоро придумают БЭМ для докера? :)
Может стоит думать не только над обновлением системы, но и над обновлением собственных приложений запущенных в контейнере, тогда такого не случится.
В правильном направлении думаете. Заминусовали вас идиоты.
Сейчас как раз изучаю этот вопрос. Для себя пока грубо оцениваю ситуацию так:
— Минимум вмешательства в уже работающие контейнеры. «apt-get upgrade» хорош только при формировании базового образа, но не в регулярной работе, система начнёт засоряться и бонуса по сравнению с обычным LXC не будет. Если нужна полноценная развёрнутая навороченная гостевая система, то надо сразу настраивать LXC. Это и проще будет. Docker же не для систем, а для контейнеров — узкоспецифичных обработчиков.
— Все «вмешательства» должны быть максимально автоматизированы и по отношению к контейнеру внешними. Т.е. разворачиваем базовый образ контейнера, пушим туда наш проект и в таком виде запускаем. Тут, видимо, надо смотреть в стороны локалхостовых PaaS, типа Dokku. Пока этот вопрос не изучал.
— Объёмные персистентные данные лучше, наверное, хранить не в контейнерах, а контейнерно-независимых каталогах и томах.
В таком случае обновление будет заключаться только в организации нового контейнера и запихивании туда уже настроенной задачи. Собственно, такое решение сейчас и интересует, к нему стараюсь и подвести варианты использования.
В любом случае нужно помнить, что Docker удобен именно для контейнерного подхода. Когда крупный проект декомпозирован на много мелких независимых элементов. Если требуется (или не получается провести декомпозицию) всё использовать одной кучей, то это не контейнерный подход, тут проще сидеть в виртуальных машинах «чистого» LXC. Или вообще обходиться одной гостевой системой без всякой контейнеризации. Я до последнего времени поступал именно так (ещё весной писал на форумах, что не понимаю зачем нужен Docker). Но сейчас дозрел до понимания того, что большие задачи полезно дробить на мелкие, мелкие задачи удобно раскидывать по индивидуальным контейнерам, после чего и всплывает в поле внимания Docker…
— Минимум вмешательства в уже работающие контейнеры. «apt-get upgrade» хорош только при формировании базового образа, но не в регулярной работе, система начнёт засоряться и бонуса по сравнению с обычным LXC не будет. Если нужна полноценная развёрнутая навороченная гостевая система, то надо сразу настраивать LXC. Это и проще будет. Docker же не для систем, а для контейнеров — узкоспецифичных обработчиков.
— Все «вмешательства» должны быть максимально автоматизированы и по отношению к контейнеру внешними. Т.е. разворачиваем базовый образ контейнера, пушим туда наш проект и в таком виде запускаем. Тут, видимо, надо смотреть в стороны локалхостовых PaaS, типа Dokku. Пока этот вопрос не изучал.
— Объёмные персистентные данные лучше, наверное, хранить не в контейнерах, а контейнерно-независимых каталогах и томах.
В таком случае обновление будет заключаться только в организации нового контейнера и запихивании туда уже настроенной задачи. Собственно, такое решение сейчас и интересует, к нему стараюсь и подвести варианты использования.
В любом случае нужно помнить, что Docker удобен именно для контейнерного подхода. Когда крупный проект декомпозирован на много мелких независимых элементов. Если требуется (или не получается провести декомпозицию) всё использовать одной кучей, то это не контейнерный подход, тут проще сидеть в виртуальных машинах «чистого» LXC. Или вообще обходиться одной гостевой системой без всякой контейнеризации. Я до последнего времени поступал именно так (ещё весной писал на форумах, что не понимаю зачем нужен Docker). Но сейчас дозрел до понимания того, что большие задачи полезно дробить на мелкие, мелкие задачи удобно раскидывать по индивидуальным контейнерам, после чего и всплывает в поле внимания Docker…
В таком случае обновление будет заключаться только в организации нового контейнера и запихивании туда уже настроенной задачи.Одна из причин использования докера — возможность организовать каждому приложению необходимую для его функционирования среду. Эта среда будет (разумеется) отличаться для большинства приложений. При обновлении системы зачастую не удастся ограничиться заменой базового образа с ОС, и нужно будет так же корректировать настройки среды.
По сути это вряд ли будет сильно отличаться от традиционных усилий по обновлению парка серверов, большинство из которых настроены немного по-разному — а это обычно дохрена работы. Просто сейчас эта, довольно дорогая, задача по поддержке парка серверов возникает на достаточно больших проектах — у которых есть оный парк серверов — которые могут себе это позволить. С докером есть высокая вероятность что эта задача возникнет у каждого второго среднего проекта, который раньше жил бы на одном-двух серверах, а теперь живёт в нескольких десятках контейнеров.
Иными словами, докер облегчает установку и развёртывание приложений, но я практически уверен что это далеко не бесплатная фишка, которая сильно усложнит дальнейшую поддержку — вплоть до уровня когда использование докера окажется экономически невыгодным для задач, которые требуется активно поддерживать.
>Иными словами, докер облегчает установку и развёртывание приложений, но я практически уверен что это далеко не бесплатная фишка, которая сильно усложнит дальнейшую поддержку
Вот именно эта оценка меня и отталкивала от Docker до последнего времени. Под мои задачи он не давал ничего сверх LXC, но LXC проще поддерживать, меньше лишних сущностей. Docker был прекрасен, когда нужно запустить Hello world из контейнера, для этого буквально ничего ручками не нужно делать, но когда начинается вопрос персистентности, связывания контейнеров… Тут LXC, которая по сути представляет отдельный автономный виртуальный компьютер становится проще.
Но сейчас по мере развития проектов начинаю переходить на декомпозицию и разделение функционала и тут внезапно оказывается, что плодить LXC-контейнеры во множестве и поддерживать их индивидуально становится грустно. А вот Docker, наоборот, становится привлекательнее :) Но глобальных выводов пока не делаю, на продакшне Docker'а ещё нет, только экспериментирую. Более того, на одном из основных проектов стоит CentOS, а там ядро без поддержки aufs, так что Docker в пролёте…
Вот именно эта оценка меня и отталкивала от Docker до последнего времени. Под мои задачи он не давал ничего сверх LXC, но LXC проще поддерживать, меньше лишних сущностей. Docker был прекрасен, когда нужно запустить Hello world из контейнера, для этого буквально ничего ручками не нужно делать, но когда начинается вопрос персистентности, связывания контейнеров… Тут LXC, которая по сути представляет отдельный автономный виртуальный компьютер становится проще.
Но сейчас по мере развития проектов начинаю переходить на декомпозицию и разделение функционала и тут внезапно оказывается, что плодить LXC-контейнеры во множестве и поддерживать их индивидуально становится грустно. А вот Docker, наоборот, становится привлекательнее :) Но глобальных выводов пока не делаю, на продакшне Docker'а ещё нет, только экспериментирую. Более того, на одном из основных проектов стоит CentOS, а там ядро без поддержки aufs, так что Docker в пролёте…
Если у вас RHEL/CentOS 6.5 или выше, то докер на нем работает на ванильном ядре, используя device mapper в качестве дискового бекэнда (ещё умеет aufs, btrfz и zfs, как минимум). В 6.5 необходимо подключить EPEL, в 7 обещали в основных репозиториях (я не тестировал). В 6 пакет называется docker-io, в 7 — просто docker.
Можно через dockerfile или через chef автоматизировать тонкую настройку среды.
а внутри VMWare докер работает? Например, есть винда, на ней вмварь в которой крутится современный линукс. Можно ли внутри того линукса (который работает под вмварью) пускать докера?
Вообще несколько непонятен общий подход. Я попробую обрисовать применительно к Enterprise in-house development (на нашем примере).
Допустим, есть стандартный цикл Dev — Test — Acc — Prod. Поскольку приложения ноне многокомпонентные (БД + APP), то есть конфигурация, которая связывает их вместе. Теперь в случае с Docker, разработчик готовит среду (image) и приложение (app), скрипт установки APP в среду (deploy), скрипт конфигурирования (configure). Помимо этих объектов существует объект конфигурации на каждом этапе.
Соответственно, по этапам цикла редко ездят изменения всех этих объектов.
image — реже всех, но именно в этом и ценность — в одном месте собрано, во всех работает. По сути это материалиазация выбранного стека технологий.
deploy — чуть чаще, но неразличимо чаще. Зависит от выбранного стека технологий. Зависит от собственно требуемых настроек приложения.
configure — примерно одинаково с deploy, потому что так же зависит от стека технологий, но в тоже время больше зависит от приложения
app — чаще всех. по сути фиксирует изменения бизнес-процесса компании.
Для изменений configure необходимо также предусматривать изменение объекта конфигурации каждого этапа.
Допустим, есть стандартный цикл Dev — Test — Acc — Prod. Поскольку приложения ноне многокомпонентные (БД + APP), то есть конфигурация, которая связывает их вместе. Теперь в случае с Docker, разработчик готовит среду (image) и приложение (app), скрипт установки APP в среду (deploy), скрипт конфигурирования (configure). Помимо этих объектов существует объект конфигурации на каждом этапе.
Соответственно, по этапам цикла редко ездят изменения всех этих объектов.
image — реже всех, но именно в этом и ценность — в одном месте собрано, во всех работает. По сути это материалиазация выбранного стека технологий.
deploy — чуть чаще, но неразличимо чаще. Зависит от выбранного стека технологий. Зависит от собственно требуемых настроек приложения.
configure — примерно одинаково с deploy, потому что так же зависит от стека технологий, но в тоже время больше зависит от приложения
app — чаще всех. по сути фиксирует изменения бизнес-процесса компании.
Для изменений configure необходимо также предусматривать изменение объекта конфигурации каждого этапа.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Используем Docker и не волнуемся о vendor-lock