контейнеры
On Tue, Dec 25, 2007 at 03:26:01PM +0300, Alexey Pechnikov wrote:
> > Краткий диагноз по диагонали половины субтреда:
> > Алексей, Вы боитесь того, что даже не попробовали пощупать.
> > В данном случае совершенно напрасно.
> В определенных ситуациях
Лучше оперировать _конкретными_ ситуациями, пока опыта для
обобщений недостаточно. Поверьте на слово или набейте те же
шишки, но это так.
> Но вопрос остается в силе - когда виртуализация _не может быть_
> использована? Например, для перегруженного сервера (с какими
> параметрами?), еще в каких-то случаях.
Перегруженность сервера -- зависящее от времени обстоятельство.
Например, однажды нас слэшдотили (но по некоторым признакам
удалось предпринять меры заранее и даже это пережить -- упёрлось
в два мегабита шейпера; BTW vserver там тоже использовался).
Другой пример -- постоянно перегруженный сервер обычно имеет
хорошие шансы откинуть коньки по дискам. Бишь тоже является
"временно перегруженным".
> Где граница применимости?
Думаю, в осмысленности.
В коробочки а-ля "soho-маршрутизатор" или "домашний NAS"
такое пихать не будут как минимум ещё довольно долго,
если вообще когда-нибудь (а если запихают -- то именно
для разграничения доступа и возможности восстановить корень
со службами, стоя на том, куда дотянуться не так просто).
В сервер с одним сервисом, который изрядно нагружен и по
определению может слопать всю железку -- может быть осмысленно
только в качестве уже описанного последнего довода против взлома
или неконтролируемого потребления ресурсов.
Во всех остальных случаях серверы я последние года три делаю
просто с использованием средств виртуализации -- будь то
vserver 1.x/2.x или openvz (сейчас, повторюсь, на хозяйстве
осталось две машины с vserver 1.x, которые тоже запланированы
к переезду).
Даже если сейчас или вообще там один контейнер, средства лёгкой
виртуализации дают помимо контроля возможность более гибко
приспосабливать железку к задачам (например, если бы сейчас ещё
хотели взгромождать sourceforge, то засунул бы дебиан в ещё один
контейнер и поднимал там gforge или что бы посоветовали как более
живое и уже упакованное). А также и возможность более гибко
разделять привилегии и ответственность -- можно спокойно давать
рута человеку, который компетентен в построении одного сервиса,
но в зависимость от аккуратности и внимательности которого не
хочется ставить всё остальное (особенно если этот человек --
я и есть).
> > > Веб-сервера, включая пресловутый апач (если им еще кто-то
> > > пользуется) тоже виртуальный хостинг поддерживают.
> > Это не тот "виртуальный".
> Несколько сайтов на одном ip.
А тут -- несколько операционных окружений на одной физической
системе. Разница чувствуется?
> Вроде как было придумано для экономии ресурсов (в данном случае
> ip-адресов).
Сперва появились не name-based, а IP-based vhosts. И решали они
как раз ту задачу, которую решают и средства виртуализации: как
на одну железку (не IP!) поселить несколько веб-серверов.
> Идея та же самая. На один физический сервер зарегистрировано
> много сайтов, стоит себе одна железка, на ней один апач и т.п.
Я как бы чуточку немного в курсе, Apache Master имени Brainbench
заработал в перерыве между парами на четвёртом, что ли, курсе \m/
:)
> > Пример "на пальцах" -- думаю, я подниму apache1+mod_perl+
> > mod_php4 и, скажем, apache2+mod_php5 на одном тазу, вот
> > только осмысленно будет разнести их в два, а то и в три
> > разных VE. И всем будет только лучше, как правило.
> Возможно. Вопрос: есть N подключений к апачу 1, и M к апачу 2.
> Насколько уменьшатся допустимые Nmax и Mmax после
> виртуализации?
Вот на столечко, если она из тех, что рекомендуются в этом треде
для задач веб-хостинга. Поскольку основной вклад в разумным
образом построенной системе будет всё равно не за ovz/vs.
> > <провокация>
> > И при этом используете Debian, а не ALT или Owl? Хех.
> > </провокация>
> Дебиан - понятно, а остальное, наверное, для тех, у кого нет
> дебиана :-)
Это было к перфекционизму по части безопасности и качества кода
скорее -- в дебиане свой, но по другой части :)
> > Админу писать свой -- заведомо хуже. Даже компетентному
> > разработчику, как правило, полезней поискать хорошую открытую
> > базу и отталкиваться от неё, возвращая свои наработки для
> > общей пользы, чем городить своё. Исключение мне известно
> > одно: когда мера безопасности "шоб никто не догадался" такой
> > ценой считается оправданной.
> В определенных областях хороших наработок не удается найти,
> потому и пишется свое.
Можно пример области, пути поиска наработок и ссылки на
написанное, которое лучше того, что существует?
Несомненно, это должны быть весьма ценные проекты.
> Тут уже вопрос стоит, как интегрировать с существующими
> наработками, чтоб меньше писать "с нуля". И в первую очередь
> имеет смысл выбрать, с чем стоит работать, а что лучше
> реализовать самому или поискать другую реализацию.
Не спорю.
> > > Получается, бардак растет на всех уровнях
> > Вам явно противопоказано пользоваться протоколами на основе
> > TCP/IP с таким обострённым чувством прекрасного... :)
> Скажем так, я пытаюсь понять, как "хотели лучше" разработчики и
> что у них потом получилось. И тоже стараюсь делать как лучше, а
> не ориентироваться на "как всегда".
Думаю, мы с Алексом Куклиным, равно как и существенная часть
других подписчиков -- тоже не ратуем за "как всегда". Просто
теория от практики отличается больше на практике, чем в теории.
> Администрирование и разработку разделить стало очень сложно
> (очень много готовых решений всех мастей)
Отнюдь -- разработчик-администратор "из кубиков" занимается
по сути интеграцией. Разработчик пилит или допиливает кубики,
а администратор обеспечивает функционирование того, что такой
вот интегратор получил.
> > > И, как я вижу, навык поставить виртуальную машину и
> > > запустить быдлокод в ней все увереннее заменяет собой
> > > умение писать грамотный код.
> > Можно поинтересоваться списком Ваших проектов и тем,
> > как оценивали качество хотя бы просто кода?
> Крупных решений немного - а точнее, всего два, система
> мерчендайзинга и документоборот.
И что по второму? Не стесняйтесь, многим нужен хороший --
особенно свободный -- документооборот. И многие оценят
великолепный и продуманный код. И архитектуру.
> > Про форумы всё понятно, вот только плеваться проще, чем хотя
> > бы отобрать "хорошие" и советовать людям, когда спрашивают.
> В рассылке периодически пробегают обсуждения в том числе и
> форумов. И часть из них вполне удовлетворяют достаточно строгим
> требованиям, так что выбирать есть из чего.
Разумеется.
> > Заказчик может хотеть немного странного и при этом в общем и
> > в целом быть нормальным, вменяемым и стоящим дела. Идеальных
> > (по концу работы, не по ТЗ и началу) мне ещё не встречалось.
> Если вы работаете с заказчиком с момента составления ТЗ
По совсем чужим ТЗ не работаем: лавка небольшая, и в ней все
понимают, почём фунт техзадания.
> вполне возможно сообщить, что определенные технологии и
> продукты безопаснее других и привести примеры.
Естественно. Или в случае предоставления хостинга --
предупредить о нежелательности применения некоторых продухтов:
http://www.linux.kiev.ua/ru/devel/hosting/web/
"Категорически запрещены phpBB2, phpNuke/postNuke и доступный
публично awstats."
(хотя, похоже, запрет пора перенести на IPB, а в качестве
отдельного форума рекомендовать какой SMF)
http://ho.com.ua/
"Q: И все-таки, в чем подвох для бесплатных?
A: Очень просто. Если будете сильно грузить сервер - предложим
перейти на платный вариант, или сменить хостинг, если не сильно
- оставайтесь бесплатно, винты нынче дешевые."
(знакомые)
> К разумным аргументам большинство заказчиков прислушивается.
С теми, кто совсем не прислушивается -- совсем не работаем.
> Другое дело, что собрать эти разумные аргументы сложно.
Для этого помогает экспериментирование с потенциально интересными
технологиями в песочнице или на некритичных проектах.
> Как видите, очень часто на мои вопросы отвечают "это хорошая и
> нужная технология, потому что я ее использую".
Думаю, это следствие формы вопросов.
> И только 1 (!) человек прислал результаты тестов, по которым в
> самом деле можно составить мнение.
Причём можно биться об заклад, что выгуглить их или эквивалентные
-- дело максимум получаса при наличии элементарного интереса.
Потому и предложил побольше читать, поменьше писать: пока пишешь
толковый вопрос _и при этом уточняешь его по гуглю_, зачастую
письмо выбрасывается или превращается в постановку проблемы и
найденный ответ -- мож кому ещё пригодится.
У всякого сообщества и его участников есть общий и персональный
лимит времени на ответы на вопросы. Не стоит его искать.
--
---- WBR, Michael Shigorin <mike@altlinux.ru>
------ Linux.Kiev http://www.linux.kiev.ua/
Reply to: