Комментарии 16
Chroot позволит Вам запускать разные версии Centos на одном сервере.
Да, тоже вариант. Но chroot не позволит запустить какое угодно количество независимых нод, нужно будет копировать полностью файловую систему
Chroot завсегда проиграет Docker-у и по удобству использования, и по всем остальным параметрам.
не могли бы вы более детально ответить?
Например, в chroot нету контроля над происходящим внутри через cgroups
Прошу прощения, не увидел вашего ответа.
* Чтобы пользоваться chroot нужно его сперва собрать, причем воспроизводимо.
* Если свои чруты обновляем а не только держим, то приходится как-то отдельно заморачиваться с воспроизводимостью и их версионированием.
* Если держать много чрутов, размер их будет дублироваться.
* Если держать много чрутов, возникнет проблема их учитывать, а также сервисы, которые запускаются в них.
* Для сервисов, которые работают в чруте нужно держать отдельную дополнительную о том как все работает, либо выдумывать (и поддерживать!) стандартизацию
* Процессы в чрутах слушают те же самые порты, что и хост, т.е. теоретически возможна ситуация, когда процесс из чрута запустившись раньше системного сервиса откроет его порт и не даст ему запуститься, или будет мешать аналогичному процессу в другом чруте (например, если держать 2 апача в разных чрутах).
* Если не ошибаюсь, /proc в чруте общий с хостом (либо его вообще нет), т.е. root из чрута может производить атаку по сервисам вне чрута — там, где /proc используется в чруте.
* Наверное несколько субъективно, но всякий раз, когда я сталкивался с чрутами (некоторые системные сервисы в дистрах уже упакованы в чруты), это было сопряжено с каким-нибудь гемором — или конфиги туда криво копируются, или библиотеку хочется туда прокинуть, но хз как это сделать правильно или еще что-нибудь такое подобное, но довольно тупое.
* Опять таки субъективно — создавать чруты мне хотелось раза полтора или меньше, а вот docker при случае буду использовать — как раз по вышеприведенным организационным причинам.
Если подумать, можно еще что-нибудь придумать — это сходу за 5мин придумалось.
Из плюсов чрута назову, что он работает вообще где угодно, т.е. ему не нужно x64, lxc и дополнительных пакетов.
* Чтобы пользоваться chroot нужно его сперва собрать, причем воспроизводимо.
* Если свои чруты обновляем а не только держим, то приходится как-то отдельно заморачиваться с воспроизводимостью и их версионированием.
* Если держать много чрутов, размер их будет дублироваться.
* Если держать много чрутов, возникнет проблема их учитывать, а также сервисы, которые запускаются в них.
* Для сервисов, которые работают в чруте нужно держать отдельную дополнительную о том как все работает, либо выдумывать (и поддерживать!) стандартизацию
* Процессы в чрутах слушают те же самые порты, что и хост, т.е. теоретически возможна ситуация, когда процесс из чрута запустившись раньше системного сервиса откроет его порт и не даст ему запуститься, или будет мешать аналогичному процессу в другом чруте (например, если держать 2 апача в разных чрутах).
* Если не ошибаюсь, /proc в чруте общий с хостом (либо его вообще нет), т.е. root из чрута может производить атаку по сервисам вне чрута — там, где /proc используется в чруте.
* Наверное несколько субъективно, но всякий раз, когда я сталкивался с чрутами (некоторые системные сервисы в дистрах уже упакованы в чруты), это было сопряжено с каким-нибудь гемором — или конфиги туда криво копируются, или библиотеку хочется туда прокинуть, но хз как это сделать правильно или еще что-нибудь такое подобное, но довольно тупое.
* Опять таки субъективно — создавать чруты мне хотелось раза полтора или меньше, а вот docker при случае буду использовать — как раз по вышеприведенным организационным причинам.
Если подумать, можно еще что-нибудь придумать — это сходу за 5мин придумалось.
Из плюсов чрута назову, что он работает вообще где угодно, т.е. ему не нужно x64, lxc и дополнительных пакетов.
А вы действительно решили выложить в публичный доступ SSH-ключи, или просто забыли их добавить в gitignore например?
Еще бы docker не поломался со вчерашним релизом.
А что с ним? Я вчера обновлялся, вроде как все работает
Я пытаюсь сделать docker run или docker build, и через несколько секунд вижу:
Хотя на 0.6.4 этот же Dockerfile отрабатывал без проблем.
Error build: The container failed to start due to timed out.
Хотя на 0.6.4 этот же Dockerfile отрабатывал без проблем.
Не используйте 13.10, используйте 13.04. Думаю проблема у вас в этом.
Да это 13.10. Легко сказать, похерь сервер потому что не та версия. Ссылка на issue в репозитории и решение.
Сервера на 13.10, конечно, сурово держать. Не-LTS версии начиная с 13.04 поддерживаются в течение всего 9 месяцев после выхода (или в течение 3х месяцев после выхода следующей версии).
13.10 превратится в тыкву уже к лету.
13.10 превратится в тыкву уже к лету.
Дык, конец 2013, херить сервера неплохо бы уметь перед завтраком, как вынос мусора ;)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Использование Docker-контейнеров как Jenkins-нод