LINUX.ORG.RU
ФорумAdmin

Плюсы докера

 


0

5

В чем плюсы докера? Создать образ, нашинковать его барахлом уже настроенным (nginx, mongo, redis в моем случае) или ставить отдельно все? Удобно, если сервер новый настраивать, быстро... а если не так часто меняются то... Как и для чего вы его используете?

★★★★
Ответ на: комментарий от anc

Ну вы тоже говорите. (с) анекдот.

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

Связка EC2+S3+Route53+DynamoDB+Lambda проверена лично в боевых условиях. И масштабируемость и восстановление из бекапов и перенос между регионами планеты, с Калифорнии (us-west1) во Франкфурт (eu-central-1).

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

К обычным облакам я тоже отношусь очень скептически, но с Амазоном есть личный многолетний опыт с боевыми ситуациями когда случалось всякое.

Obezyan
()
Ответ на: комментарий от pekmop1024

дык, кто-то просто не умеет считать деньги (ну или ему на них срать)

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

Obezyan
()
Ответ на: комментарий от Obezyan

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

Для начала, уточню необходимую капасити. А то если вам нескольких стоек из 36 DL325 (возьмем для примера типичную general compute node - EPYC 7713, 768GB, 10*3.6TB 10k HDD) в каждой локации много, то говорить особо не о чем, выигрыша не будет.

Профит в 4 раза начинается где-то с момента, когда этих серверов пара клеток.

pekmop1024 ★★★★★
()
Последнее исправление: pekmop1024 (всего исправлений: 1)
Ответ на: комментарий от zg

Так ведь основная фишка облаков - их масштабируемость. Тебе, для максимальной нагрузки, нужно сразу купить мощное железо. Но максимальная нагрузка у тебя не всегда и значительное время твоё железо будет просто простаивать. Облако работает иначе.

После определенных размеров простой железа стоит в разы дешевле масштабирования облаков. Вплоть до того, что все серверы держат включенными для равномерной нагрузки на PDU, пренебрегая потреблением неиспользуемых. Такие дела.

pekmop1024 ★★★★★
()
Ответ на: комментарий от pekmop1024

То что вы предлагаете в десятки раз дороже и просто не нужно, мы не биржа и не финтех. Да и что толку от такого количества стоек если на них нет Route 53 и Lambda? Админом ДЦ-хоста тут не обойтись. К тому же все ваше автоматическое масштабирование заключается в том что «дешевле держать ненагруженные стойки включенными». Ну и кто тут деньги считать не умеет?

У нас Xeon Gold разных поколений на разных континентах. Нам хватает, пики обычно в последние 1.5 месяца в году, доходит до 10 млн запросов в сутки на сервер. В такие моменты остается ~20% запаса по процу что нас полностью устраивает.

Короче, как я и думал, альтернативы по соотношению цена/качество/возможности просто не существует на текущий момент. Есть либо откровенно хуже варианты типо облаков от ДЦ, либо сильно дороже в виде рядов стоек, но без функционала из коробки.

Obezyan
()
Последнее исправление: Obezyan (всего исправлений: 1)

Управление конфигурацией и воспроизводимость, только в более удобном виде. Нажал docker build или docker compose up, задав нужное в .env и оно поднялось. Можно поделиться своими наработками с инторнетом, как вон можно найти кучу примеров docker compose того или иного сервиса на GitHub.

Альтернатива этому только LXC/виртуалки и конфигурять их Ansible и скриптами. Но это не так удобно. В Ansible надо вкатываться, знать что такое инвентарь и нафига. Скрипты каждый пишет кто во что горазд и под себя. Там нет единого стандарта. Можешь хоть на пых-пыхе скрипт конфигуряния написать, просто потому что можешь. А Dockerfile и compose – это стандарт.

Ориентация на одноразовость контейнеров. Нужно обновить? Собери новый и замени. Данные и приложение разделены.

Никто не ведёт речи, что всего этого нельзя добиться без Docker. И это лишь один из подходов. Просто они сделали удобный инструментарий и выстрелили.

egzakharovich
()
Ответ на: комментарий от egzakharovich

Под ваше описание попадают AppImg/snap пакеты программ, где в контейнере всё нужное для их работы и от хоста нужен минимум, сопоставимый с docker-движком

Просто они сделали удобный инструментарий и выстрелили.

Вот и все плюсы докера. За нас всё сделали и оно пока работает. А если забросят?

futurama ★★★★★
()
Последнее исправление: futurama (всего исправлений: 1)
Ответ на: комментарий от futurama

Под это описание подходит много чего.

flatpak вообще в теории является сахаром над podman bwrap. Потому что любое графическое приложение можно собирать с помощью Dockerfile, а затем запустить с помощью грамотно составленного compose, где все необходимые доступы прописаны.

distrobox какой-нибудь этому подтверждение.

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

egzakharovich
()
Ответ на: комментарий от Obezyan

При переносе на новую версию разработка старой версии прекращается. Часть людей работают на поддержанием старой версии, часть - пилят на новую.

Неа, одни и те-же люди могут одновременно поддерживать то что есть, разрабатывать новую версию и править баги в старой и все на одном рабочем месте.

Разные тестовые сервера (хоть в железе хоть виртуальные) с разным набором зависимостей.

У меня есть небольшой опыт работы DevOps(без dev только) и там было просто, репозиторий который разработчики себе копировали, запускали код через compose и могли его отлаживать не дергая тестовый сервер и других девелоперов. Потом что-то пушили в репозиторий и код через CI/CD собирался на сервере (там уже k8s был). Придумано не мною, сами девелоперы сказали что так раньше работали и им так удобно.

Kolins ★★★★★
()
Ответ на: комментарий от Obezyan

нет Route 53 и Lambda

Узкий специалист подобен флюсу.

Админом ДЦ-хоста тут не обойтись.

Во времена ковида мы подняли локацию полностью удаленно. Только там были не DL325, а DL360 - ну, не было тогда DL325 с такими процессорами в наличии. Какого админа тебе надобно, человече? Что у серверов и свитчей, что у PDU есть REST API и вебморды, все это отлично рулится удаленно и автоматизируется до уровня твоих любимых облаков.

Короче, как я и думал, альтернативы по соотношению цена/качество/возможности просто не существует на текущий момент

А если он еще и религиозный фанатик, то все совсем плохо.

pekmop1024 ★★★★★
()

Песочница с хорошей воспроизводимостью и простой конфигурацией.

К примеру зачем мне ставить и настраивать системный постгрес, когда я могу за полминуты запустить контейнер с нужной версией, примонтировать куда оно будет писать данные и сразу пользоваться? Легко поднять, легко выбросить, легко объяснить другому как повторить, легко содержать сотню этих постгресов под каждый проект.

Аналогично для всякой рассыпухи библиотек. Мне зачем это всё на основной системе, разруливать конфикты между проектами, ставить что-то из мутных источников потому что в дистре чего-то не хватает? Make && make install это практически то же самое что curl | bash, зачем лишний раз рисковать?

Короче, быстрая дешёвая виртуалка, что тут ещё добавить.

neumond
()

Плюс в том, что позволяет сдерживать порывы типичного софта раскидывать своё всякое по всем закоулкам системы. Ну и в целом привносит адекватный package management в Linux. К сожалению 30 лет развития дистрибутивов не привели ни к чему, пришлось всю систему менять.

vbr ★★★★★
()
Последнее исправление: vbr (всего исправлений: 2)
Ответ на: комментарий от pekmop1024

После определенных размеров простой железа стоит в разы дешевле масштабирования облаков. Вплоть до того, что все серверы держат включенными для равномерной нагрузки на PDU, пренебрегая потреблением неиспользуемых. Такие дела.

Дешевли, пока не случилось чего-то непредвиденного или дешевли всегда? Что будет, если в он-прем случится пожар или сбой электропитания или тракторист из соседней деревни порвёт кабель связи? Ну и просто выход из строя железа со временем. Может ли он-прем обеспечить такой же уровень failover, который предоставляет AWS и подобные ему облака?

zg
()
Ответ на: комментарий от Kolins

Неа, одни и те-же люди могут одновременно поддерживать то что есть, разрабатывать новую версию и править баги в старой и все на одном рабочем месте.

Еще и в один день. Я понимаю, и соболезную, серьезно. Постоянное переключение контекста ведет к снижению эффективности и выгоранию. Это не правильный подход - галерный. То что докер помогает этот подход использовать не делает ему чести.

У меня есть небольшой опыт работы DevOps(без dev только) и там было просто, репозиторий который разработчики себе копировали, запускали код через compose и могли его отлаживать не дергая тестовый сервер и других девелоперов. Потом что-то пушили в репозиторий и код через CI/CD собирался на сервере (там уже k8s был). Придумано не мною, сами девелоперы сказали что так раньше работали и им так удобно.

Большинство моих CI/CD в своей основе используют git hooks и cron. Этого достаточно чтобы одним кликом развернуть коммит на тестовом сервере, прогнать все тесты (как unit так e2e запуская безголовый chromium в консоли и тыкая несуществующим курсором в html дерево) и при успешном прохождении смерджить в прод.

Тоже самое можно было сделать на Docker и k8s, но зачем? Иx использование это буквально - skill issue в данном случае.

Obezyan
()
Ответ на: комментарий от pekmop1024

Узкий специалист подобен флюсу.

Похоже, что вы это о себе. Ваши рассуждения это рассуждения админа хостинг конторы. Буквально: когда ты молоток, все вокруг выглядит как гвоздь DL325.

Еще раз, вы предложили решение гораздо дороже, еще и локальное. Как вы раскидаете свои стойки по континентам и странам? Сколько договоров и с кем нужно будет заключить и поддерживать вместо одного аккаунта в амазоне?

Какого админа тебе надобно, человече?

Настройте мне свою альтернативу Lambda. Это Serverless FaaS поэтому у админов тут - лапки.

Постарайтесь понять о чем я говорю - просто голые стойки без готовой инфраструктуры нафиг не нужны, солить что ли эти процы. Амазон предлагает готовое решние, комплексное. Железо+сервисы.

Вы можете предложить железо, но дороже и вы не можете предложить сервисы (например Lambda) на том же уровне.

Вы можете настроить аналог Route 53 упоровшись и раскидав стойки по миру. Но вы не сможете продать такое решение вместе с железом потому что у Aмазона стоимость одного миллиона запросов $0.4, а после миллиарда - $0.2/млн запросов. Т.е в пике этот сервис обходится клиенту в $4 в день. Осознайте масштаб пропасти между тем о чем вы говорите и тем о чем я пишу.

А если он еще и религиозный фанатик, то все совсем плохо.

Да я не против стоек и обычного хостинга. Просто каждой задаче свой инструмент. Мы как раз и выросли из стойки в Скандинавии.

Obezyan
()
Последнее исправление: Obezyan (всего исправлений: 1)
Ответ на: комментарий от zg

В свете текущих нацпольных событий, обсуждать которые тут табу, AWS таки действительно может вызывать опасения для россиян.

Я Крымчанин, живу в Крыму. 11 год по санкциями, 3й год под двойными. Пользуюсь Амазоном, работаю над проектами по всему миру, официально, в белую (ИП). Кто хочет - ищет способ, кто не хочет - ищет причину.

Но неужели в России нет ни одного аналога AWS?

Нет. Они не покрывают весь мир и не предоставляют такой набор сервисов. Если вам необходимо локальное покрытие, например - СНГ, то облаков и просто хостинга в России полно на любой вкус и цвет. С этим проблем нет никаких. Проблемы начинаются при переходе на международный уровень. Прямые аналоги Amazon мне неизвестны.

Obezyan
()
Ответ на: комментарий от Kolins

затем что конкретно в том проекте были динамические контейнеры и прочая микросервисная лабудень

Это был риторический вопрос. Большинство проектов на планете не имеют нормального системного архитектора. Это - данность в которой мы живем. Отсюда имеем расцвет докера, js на бекенде и прочее.

Obezyan
()
Ответ на: комментарий от vbr

Прямые аналоги Amazon это GCP и Azure. AWS, конечно, гигант, но явно не единственный выбор во вселенной.

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

У Амазона даже свой вид DevOPs есть. Специалисты которые настраивают стыковку Амазон сервисов и пишут всякие конфигурации политик ресурсов. Это следующий уровень после K8S девопсов.

Obezyan
()
Последнее исправление: Obezyan (всего исправлений: 1)

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

s-warus ★★★
()
Ответ на: комментарий от urxvt

Не «безплатно», но «всё в одном».

Потому что Ansible никак не участвует в процессе инициализации нового контейнера или виртуальной машины, это делает соответствующий инструмент в виде Proxmox/LXD/Incus… Но если сильно хочется, можно воспользоваться модулем и запустить процесс прямо из плейбука. Как запрограммируешь, так и будет.

Ansible никак тебе не может собрать готовый контейнер из Dockerfile и положить его в registry. Чтобы использовать в качестве шаблона для запуска твоих сервисов. Но можно написать плейбук, который будет это делать со свежезапущенным LXC/виртуалкой через SSH. А потом обратится к API твоего Proxmox/LXD/Incus, погасит контейнер и выгрузит образ…

Птички совершенно о разном и о разных подходах. Блядский конвеер vs оркестратор сотни локалхостов.

egzakharovich
()
Ответ на: комментарий от egzakharovich

сделал свой контейнер и заказчику потестить закинул.

/thread

А заказчик просил докер-контейнер? Если нет, то как он его потестит? Может у заказчика есть proxmox и он может lxc контейнер потестить

futurama ★★★★★
()
Ответ на: комментарий от Obezyan

Похоже, что вы это о себе. Ваши рассуждения это рассуждения админа хостинг конторы. Буквально: когда ты молоток, все вокруг выглядит как гвоздь DL325.

Страшно сказать, но единственный хостинг, который я когда-либо админил, моя собственная машина на хецнере, которая до сих пор онлайн, так как дорога мне как память.

Еще раз, вы предложили решение гораздо дороже, еще и локальное. Как вы раскидаете свои стойки по континентам и странам? Сколько договоров и с кем нужно будет заключить и поддерживать вместо одного аккаунта в амазоне?

Я потому и спросил о капасити. Конечно же, когда у тебя два десятка серверов всего, тебе облака зайдут. В остальном проблем никаких нет, ни с локациями, ни с подрядчиками, ни со smart hands для чего-то срочного.

Настройте мне свою альтернативу Lambda. Это Serverless FaaS поэтому у админов тут - лапки.

Опуская уход в частности от общего, интересно, кого ты так презрительно админами называешь? Тебя они в детстве джойстиком насиловали, что ли?

Вы можете настроить аналог Route 53 упоровшись и раскидав стойки по миру. Но вы не сможете продать такое решение вместе с железом потому что у Aмазона стоимость одного миллиона запросов $0.4, а после миллиарда - $0.2/млн запросов. Т.е в пике этот сервис обходится клиенту в $4 в день. Осознайте масштаб пропасти между тем о чем вы говорите и тем о чем я пишу.

Кто про что, а вшивый про баню. Ладно, разговор бессмесленен, ты застрял в своей узкой области и не видишь ничего вокруг. Ни как устроены вещи, ни как можно сделать их по-другому, ничего. Узкий специалист. Как ругательство.

И да, мне не надо ничего продавать. Данная инфра - она сугубо для того, чтобы ранить внутренний продукт. Ну, формально сервисов там, конечно же, не один, но сути не это не меняет. Это не субподряд и тем более не хостинг.

pekmop1024 ★★★★★
()
Ответ на: комментарий от pekmop1024

Кстати, раз уж ты так фанатеешь от Route 53, могу тебя ткнуть пальцем в альтернативу в случае он-према - Akamai. Гораздо удобнее и надежнее. И не надо мне писать в стиле «я же говорил, что облака рулят». Облака хороши на своем месте. Как и он-прем, и другие вещи.

А вот быть фанатичным неофитом чего-либо - непрофессионально.

pekmop1024 ★★★★★
()
Ответ на: комментарий от zg

Дешевли, пока не случилось чего-то непредвиденного или дешевли всегда? Что будет, если в он-прем случится пожар или сбой электропитания или тракторист из соседней деревни порвёт кабель связи? Ну и просто выход из строя железа со временем. Может ли он-прем обеспечить такой же уровень failover, который предоставляет AWS и подобные ему облака?

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

Железо - оно на гарантии. Те же HPE и Dell сами своих инженеров отправляют в ЦОДы, мы им только тикетами доступ создаем. Как гарантия приближается к концу - железку выводят и в утиль. Она к тому времени (обычно это 5 лет) уже несколько раз окупила свою стоимость, и заработала на несколько новых.

pekmop1024 ★★★★★
()
Ответ на: комментарий от futurama

Нет, в том аксепте, что вы докапываетесь до шашечек, как представитель женского пола, имеющий проблемы с половой и личной жизнью.

Упуская контекст треда о том, что речь идёт про докер.

И что докер позволяет вот так вот просто взять и скинуть заказчику, у которого тоже есть докер, готовый контейнер (архив) или рецепт (Dockerfile) по созданию требуемого ему сервиса, чтобы протестировать у себя. А уровень воспроизводимости настолько хорош, что неважно, какой у заказчика дистрибутив, лишь бы поддерживал docker engine.

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

egzakharovich
()
Ответ на: комментарий от futurama

А где вы видите минусы?

Ну хорошо, допустим, нет докера. Только Proxmox. Как в Proxmox добиться повторяемой сборки LXC контейнера по рецепту, аналогичному Dockerfile?

Это ли не плюс, иметь такую возможность?

egzakharovich
()
Ответ на: комментарий от pekmop1024

Опуская уход в частности от общего, интересно, кого ты так презрительно админами называешь? Тебя они в детстве джойстиком насиловали, что ли?

Ни в коем случае. Текст сообщения не передает интонации. За битого админа жмень небитых девопсов дают. К настоящим админам у меня только уважение. Много лет проработал бок о бок с такими. Но есть админы, например, банков (частое явление) - выросшие из студентов которых больше никуда не взяли, у которых гонора выше крыши (я работаю в Банке, а знаний хер да маленько) и все вопросы решают заявкой на покупку доп оборудования.

Кто про что, а вшивый про баню. Ладно, разговор бессмесленен, ты застрял в своей узкой области и не видишь ничего вокруг. Ни как устроены вещи, ни как можно сделать их по-другому, ничего. Узкий специалист. Как ругательство.

Вы избежали темы доступности продукта в мире сославшись на «ранить внутренний продукт». Это так по-детски. Буквально, поведение админа из Банка. Ну да ладно, тут половина ЛОРа таких.

Застрявшие в свое локальном мирке истово отстаивающих свою точку зрения, не понимая что буквально говорят о совершенно другом кейсе.

Obezyan
()
Ответ на: комментарий от Obezyan

Вы избежали темы доступности продукта в мире сославшись на «ранить внутренний продукт». Это так по-детски. Буквально, поведение админа из Банка. Ну да ладно, тут половина ЛОРа таких.

А ты зачем мои слова выворачиваешь, кроме ad hominem, аргументов не осталось? Ты же знаешь, что продукт предоставляется наружу (натурально, триллионы запросов обслуживаются), я об этом писал в этом треде. Тьху, балаболка.

Застрявшие в свое локальном мирке истово отстаивающих свою точку зрения, не понимая что буквально говорят о совершенно другом кейсе.

Я вообще ничего не отстаиваю. Делюсь с общественностью фактом - облака не являются универсальным решением, и не являются самым недорогим решением. Это инструмент. Его нужно по назначению применять.

А у тебя четко прослеживается фанатизм, к сожалению.

pekmop1024 ★★★★★
()
Ответ на: комментарий от firkax

ты не думал, что может быть зря упускаешь полезный инструмент, который твоей работе будет помогать?

докер как «философия» (секта группового мышления) - это одно. докер как инструмент - другое

asdpm
()
Ответ на: комментарий от asdpm

Да, вот эти товарищи с докером наперевес просто потому что могут - бесят… Согласен. Ну, так это как с некоторыми языками программирования - сами языки не виноваты в том, на них дятлы пишут.

Это вопрос порога вхождения. Чем он ниже, тем больше дятлов.

pekmop1024 ★★★★★
()
Последнее исправление: pekmop1024 (всего исправлений: 1)
Ответ на: комментарий от egzakharovich

Вы не сказали за счет чего у докера можно «добиться повторяемой сборки»

в dockerfile директивы, а содержание подтягивается из неконтролируемых вами источников.

На доверии эта повторяемость.

С lxc тоже самое. Откуда будешь его разворачивать, оттуда и повторяемость

futurama ★★★★★
()
Ответ на: комментарий от asdpm

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

firkax ★★★★★
()
Ответ на: комментарий от pekmop1024

Кстати, раз уж ты так фанатеешь от Route 53, могу тебя ткнуть пальцем в альтернативу в случае он-према - Akamai. Гораздо удобнее и надежнее. И не надо мне писать в стиле «я же говорил, что облака рулят». Облака хороши на своем месте. Как и он-прем, и другие вещи.

Вы пропустил тут момент где я объяснял что облака хороши для конкретного кейса, моего. В ответ вы начали рассказывать как хороши стойки для вашего кейса. Вы правы в том что они хороши для вашей задачи, я с этим не спорю. Но зачем вы пытаетесь убедить меня что они хороши для моей задачи если это не так, я не понимаю.

Akamai. Гораздо удобнее и надежнее.

Вот, уже лучше. не удобнее и не надежнее, но уже можно сравнивать при прочих равных. Akamai имеет действительно хороший, интеллектуальный роутинг траффика, но заточен он больше под CDN, как CloudFlare, это не то пальто.

Также, Akamai позволяет решить одну задачу (предоставляет один сервис), тогда как Амаzon позволяет решить кучу задач (предоставляет множество сервисов) в одной экосистеме.

А вот быть фанатичным неофитом чего-либо - непрофессионально.

Полностью согласен.

Obezyan
()
Ответ на: комментарий от futurama

А почему вообще у вас так бомбит с докера? Это же по сути тоненькая обвязка над механизмами ядра. Из реальных претензий к нему я могу придумать разве что необходимость работы демона под рутом, но если это так пугает, то можно просто взять podman и запускать те же образы через него.

С моей колокольни докер отличается от flatpak или apt только большей популярностью и возможностью работы не только в линуксах.

NeOlip ★★
()
Ответ на: комментарий от futurama

Ну, Dockerfile это не Nix, конечно. И не имеет повторяемости на уровне 99%.

Но в основном, если взять рандомный Dockerfile из интернетов, то он скорее заведётся, чем нет. Особенно, если вместо :latest будет привязка к определённой версии FROM.

egzakharovich
()
Ответ на: комментарий от firkax

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

Э, а в чем разница? Я с jails особо не работал, но на первый взгляд freebsd jails и linux containers это братья близнецы. Скорее всего имело место копирование первых вторыми, учитывая тот факт, что в freebsd легковесные контейнеры появились заметно раньше.

MirandaUser2
()
Ответ на: комментарий от MirandaUser2

В начале 2000ых была куча шаред хостингов на FreeBSD (кто-то помнит мастерхост?), использующих jails. Oно конечно не совсем контейнер, но уже и не chroot. А в линуксах тогда это все было сильно примитивнее.

pekmop1024 ★★★★★
()