Мне 37 лет, что по программистским меркам равняется 99 годам. Я достаточно стар, чтобы помнить первые дни публичного Интернета и первых интернет-провайдеров. Впервые я вышел в онлайн через провайдера, который назывался Internet Access Cincinnati (IAC). Он предоставлял доступ по диалапу к серверу Sun SparcStation 10, где пользователи могли запускать почтенные в своей древности терминальные приложения вроде elm (почтовый клиент), emacs, lynx (текстовый веб-браузер), и конечно IRC.Позже добавили возможность звонить на терминальный сервер CSLIP (предшественник PPP) и подключаться напрямую к Интернету с собственного компьютера под Linux или Windows (при наличии Trumpet WinSock) с настоящим IP-адресом.
Но вернёмся к той SparcStation. Машина была оборудована двумя CPU, которые работали на чудовищной частоте 33 Мгц, и она могла вместить аж 512 МБ памяти, хотя я сомневаюсь, что слоты там были забиты по максимуму. Оперативная память очень дорого стоила в те времена. Сервер с такими скромными ресурсами обслуживал 50-100 активных пользователей одновременно, обрабатывал почту для десятков тысяч, держал IRC-чат, поддерживал ранний HTTP 1.0 через NCSA HTTPd и добровольно выполнял роль FTP-зеркала для Slackware Linux. В целом он неплохо справлялся с нагрузкой и часто показывал аптайм 1-2 месяца.
Уверен, вы предчувствуете напыщенную речь о том, как в наше время распухли программы. Если так, то вы правы. Но отличие этой речи от других подобных в том, что она выдвигает логическую гипотезу, которая может объяснить главные причины такого разбухания. На мой взгляд, это последствия того, что очень простые варианты дизайна прошлого пошли не по той дороге.
Я вспомнил SparcStation, потому что хотел бы начать с очень глупого вопроса: зачем нам виртуализация? Или контейнеры? Как мы пришли к этому взрыву сложности вложений ОС->VM->контейнеры->… вместо простоты многопользовательских операционных систем?
Виртуализация обходится дорого
Мой стартап ZeroTier (прошу прощения за рекламу) работает на облачной инфраструктуре, разбросанной по многим дата-центрам, провайдерам и континентам. Большинство узлов, которые составляют облачное присутствие, выступают стабильными опорными точками в Интернете и последними ретрансляторами. Они принимают и отправляют пакеты. Им нужна полоса и немного CPU, но очень мало памяти или места на диске. Взять к примеру один из резервных ретрансляторов TCP (TCP fallback relay): он обычно передаёт 5-10 Мбит/с трафика, но программному обеспечению требуется лишь 10 МБ памяти и менее одного мегабайта (!!!) места на диске. Он также использует менее 1% ресурсов CPU.
Однако его виртуальная машина занимает 8 ГБ места на диске и по крайней мере 768 МБ памяти. Всё это нужно для хранения полной базовой инсталляции CentOS Linux, полного комплекта стандартных приложений и инструментов, системных сервисов вроде systemd и cron, а также сервера OpenSSH для удалённого доступа. Большое потребление RAM — прямое следствие виртуализации, эдакого «хака, чтобы обмануть ядро, будто оно работает на собственном оборудовании». Вся эта память должна быть доступна VM, потому что ядра как будто работают на отдельных машинах со своей локальной памятью, так что гипервизор вынужден подчиниться. (Современные гипервизоры могут в некоторой степени резервировать память про запас, но излишнее резервирование повышает риск ухудшения производительности при резком повышении нагрузки).
Контейнеры немного более эффективны, чем гипервизоры. Они не задействуют собственное ядро Linux и не тратят лишнюю память на гипервизор, но по-прежнему несут в себе по крайней мере часть всего дистрибутива Linux всего лишь для выполнения одной или нескольких программ. Контейнер для запуска 10-мегабайтной программки может весить несколько гигабайт, а для управления контейнерами нужен свой собственный пухлый набор приложений.
Спросите кого угодно, зачем нам всё это нужно. Он скажет о безопасности, изоляции и масштабируемости — и будет прав.
В старые времена, до виртуализации и контейнеров, компаниям вроде ZeroTier приходилось размещать собственное оборудование в дата-центрах. Это неудобно и не очень выгодно. Виртуализация позволяет обслуживать сотни пользователей с одного очень мощного сервера (моя виртуальная машина на 768 МБ, вероятно, крутится на 16-24-ядерном монстре Xeon с 256+ ГБ памяти).
Сотни пользователей — это же как… хм… та старая SparcStation на 33 МГц...?
Сегодняшний софт на порядки более громоздкий и сложный, чем программы, которые работали на старом сервере IAC, и хотя отчасти это стало результатом увеличения уровней абстракций и ненужного распухания, но при этом нельзя не отметить реальное увеличение функциональности и гигантский рост обрабатываемых данных. Я не говорю, что мы должны впихнуть нагрузку от сотни типичных современных пользователей в кофеварку. Но я считаю, что мы должны иметь возможность вместить хотя бы несколько сайтов Wordpress (это типичный пример задачи, которую принято размещать в виртуальной машине) на Raspberry Pi — на компьютере, который примерно в 100 раз превосходит старый сервер по мощности CPU, в несколько раз по RAM и в 10-20 раз по объёму постоянной памяти.
RPi стоит $30 и потребляет менее 15 Вт. Нужно ли говорить, сколько стоит одна монструозная VM и сколько она потребляет?
Время для Pi!
Проделаем маленький мысленный эксперимент, где попытаемся установить RPi в качестве терминального сервера для группы пользователей, которые хотят вести блоги Wordpress. Веб-сервер и небольшая база данных вместе займут примерно 10-20 МБ памяти, а у нашего RPi — 1024 МБ, так что он сможет хостить по крайней мере 50 сайтов маленького или среднего размера. (В реальности большая часть RAM избыточна или неактивна, так что со свопом или KSM наш RPi захостит несколько сотен сайтов, но будем консервативными).
Сначала установим Linux. Это наследник Unix, многопользовательская операционная система (верно?), так что создадим 50 аккаунтов. Каждый из этих пользователей теперь может залогиниться. Входящая сессия SSH и шелл занимают всего один-два мегабайта в памяти, а у нашего RPi больше тысячи, так что на данный момент всё должно идти гладко.
Да, да, пока что игнорируем безопасность. Позже займёмся этим вопросом. Но если никто из наших пользователей не будет плохо себя вести, то все они сейчас скачивают и распаковывают Wordpress. Всё хорошо. Проблемы начнутся, когда они приступят к установке.
Шаг первый: установить базу данных MySQL.
А, так это просто! Набираем "sudo apt-get install..."
Погодите… sudo? Предоставление прав sudo означает, что вы с тем же успехом могли и не заводить отдельные аккаунты для пользователей.
Оказывается, что вы можете установить MySQL в собственную домашнюю директорию. Если хотите скомпилировать его или вручную распаковать пакет Debian и отредактировать какие-то конфигурационные файлы, то можете сделать это без специальных привилегий. Ему нужно будет использовать папки /home/yourname/… но в итоге вы получите собственный локальный сервер MySQL, работающий в вашем собственном локальном пространстве пользователя.
Шаг второй: сконфигурировать веб-сервер для работы PHP.
Не будем ворчать… снова используем "sudo apt-get install", чтобы загрузить все необходимые компоненты, собрать их вместе и запустить. Оказывается, это тоже можно сделать, и после бритья яка [бесполезные на первый взгляд действия, которые на самом деле необходимы: например, мы решаем проблему, которая решает другую проблему, которая через несколько уровней рекурсии решает реальную проблему, над которой мы работаем, слэнг Массачусетского технологического института — прим.пер.] наш собственный веб-сервер с PHP готов к работе.
Затем вы сталкиваетесь с чем-то вроде "bind: permission denied". Хм? Немного покопавшись, вы находите, что порт 80, то есть веб-порт по умолчанию, является привилегированным портом. Вам нужны права рута, чтобы привязаться к нему.
Неважно. Просто изменим порт. Но этой значит, что теперь всем придётся вводить URL вашего сайта с дурацким :### на конце хоста, чтобы подключиться к нестандартному порту.
Яйца!
Сейчас вы осознали, что без ограничения на привилегированные порты всё значимое в системе Unix не следовало оставлять под рутом и тогда вы могли по крайней мере обеспечить лучшую безопасность системных сервисов. Но не поэтому я назвал этот раздел «яйца». Я назвал его так, потому что для понимания более широких последствий ограничения на привилегированные порты нужно отвлечься на минуту и поговорить о яйцах.
Яички — это жизненно важный орган. Размещение их в маленьком мешочке за пределами мужского тела было глупо, не говоря уже о странном внешнем виде. Самки нашего вида сконструированы более логично: их яичники спрятаны глубоко внутри живота, где они гораздо лучше защищены от ударов, пинков, мечей, заборов и старых тёток.
Зависимость от первоначально выбранного пути — концепция из экономической теории и эволюционной биологии — пытается объяснить, откуда берутся такие причудливые конструкции. Суть в том, что решения, принятые в прошлом, ограничивают в принятии решений, которые легко могли бы быть приняты в настоящем.
Мужские яички находятся за пределами тела, потому что определённые ферменты в мужской сперме лучше функционируют при температуре чуть ниже температуры тела. Это «решение» было принято очень давно, вероятно (если верить самой простой и поэтому наиболее вероятной гипотезе), когда мы либо не были теплокровными, либо имели меньшую температуру тела. Репродуктивные органы — это то, что биологи называют крайне консервативной системой, то есть они не склонны часто изменяться, потому что любые мутации репродуктивной системы с большой вероятностью вычеркнут особь из генетического пула. В результате, «легче» (в смысле пересечения эволюционного графа вероятностей) поместить мужские яички в пикантного вида мешочек между ног, чем вернуться назад и эффективно переработать сперму для работы при более высокой температуре.
Даже если бы мутации для функционирования спермы при более высокой температуре были настолько же вероятны, как те мутации, которые привели к появлению сленгового слова «зависать», не факт, что это бы произошло. Может быть, эти конкретные мутации не произошли бы из-за случайности, не оставив эволюционной системе самообучения никаких вариантов, кроме… э-э-э… неудачного. Ладно-ладно, я закончил.
Технологическую эволюцию движут разумные (по крайней мере, так мы считаем) агенты, но во многих отношениях она похожа на биологическую эволюцию. Как только принято решение, устанавливается путь для будущих решений и система с большей вероятностью движется по проторенной дороге. Иногда изменение старого решения обходится дороже, чем смириться с ним, а иногда это простая инерция.
Возьмите эти странные круглые 12-вольтовые штекеры в автомобилях. Изначально они предназначались для прикуривателей сигарет. Когда стали популярными различные портативные электронные устройства, инженеры задумались, как подключить их к автомобилю. Договориться с автопроизводителями на установку розетки не удалось, так же как уговорить пользователей установить розетки самостоятельно механическим способом, но поскольку во всех автомобилях есть прикуриватели… ну тогда… ответ очевиден. Сделаем розетку, которая помещается в разъём прикуривателя. Теперь автомобили часто даже не выпускают с прикуривателями, но в них есть эта розетка в разъёме прикуривателя, потому что куда же человеку подключить свой смартфон?
(USB постепенно заменяет прикуриватели, но в большинстве машин они по-прежнему установлены).
Не выбранный путь
К этому моменту вы должны были понять, к чему мы ведём. Unix изначально был разработан как многопользовательская система с разделением времени, и с этой целью добавлялись многие функции, чтобы ресурсы системы можно было использовать совместно. Там есть система разрешений для доступа к файлам с пользователями и группами, а на новых системах досконально отрегулированные списки контроля доступа. Там есть квоты на каждого пользователя по памяти, диску и использованию CPU, чтобы какой-то один пользователь не захватил все ресурсы системы. Там есть изоляция процессов, защита памяти и так далее. Но по какой-то причине никто даже не подумал адаптировать её сетевой слой для мультиаренды (мультитенантности) сетевых сервисов. Может быть, в то время привилегированные порты по-прежнему имели смысл и были уместны. Или просто никто не подумал об этом.
Привилегированные порты изначально были функцией безопасности. В те времена все компьютеры принадлежали организациям и управлялись штатными системными администраторами, а сети были закрыты для посторонних устройств (если такие устройства вообще существовали). Список портов, к которым имеет доступ только рут, позволял любому системному сервису знать, что какое-то входящее соединение инициировано программой с разрешения системного администратора.
В начале 90-х, когда Интернет начал становиться публичной сетью, многие системы и сети по-прежнему работали таким образом и полагались на привилегированные порты как на критический механизм аутентификации. Так что когда начали распространяться веб-сайты и каждый захотел иметь собственные веб-серверы на собственных IP-адресах, показалось более концептуально очевидным и менее хлопотным реализовать виртуализацию операционных систем и оставить остальную часть стека в неприкосновенности.
Виртуализация ОС полезна для других целей: для тестирования и отладки кода, для поддержки древнего ПО, которое должно работать на старых (или иных) операционных системах или версиях ядра, и это подливает масла в огонь. В конце концов, вместо адаптации сетевого стека Unix к нуждам мультиаренды мы просто закинули коробки внутрь коробок и пошли дальше.
Всё это сделано за счёт лишнего расхода железа и энергии. Рискну предположить, что тот же 16-24-ядерный Xeon с примерно 256 ГБ RAM, на котором размещается, наверное, меньше сотни 768-мегабайтных VM, мог бы хостить тысячи задач пользователей, если бы они работали напрямую на том же ядре, а не были обвешаны гипервизорами и пухлыми контейнерами. Насколько меньше CO2 попадёт в атмосферу, если каждый дата-центр уменьшить в десять раз?
Контейнеры вроде Docker частично решают проблему. Вы можете сказать, что контейнеризация — это именно та мультиарендность, к которой я стремлюсь, разве что она частично придерживается наследия виртуализации, воспринимая системные образы как гигантские статично связанные бинарники. Это также шаг назад в удобстве пользования. Мне по-прежнему нужны рутовые права, чтобы запустить контейнер. Я не могу (легко) залогиниться в один контейнер и запустить другой, как я делаю с процессами на простой мультиарендной машине Unix. Вместо этого приходится выстраивать массивные консоли центрального управления и инструменты «оркестровки».
Так что можно сделать? Как мог выглядеть путь, по которому мы не пошли?
Мультиарендная работа в сети
В некоторых случаях зависимость от выбранного пути проявляет себя, потому что так много новых решений принято на основе старых, что выходит слишком дорого вернуться и изменить старое решение. Мне кажется, что в этом случае несколько простых изменений могли бы перемотать 20 лет истории DevOps и направить нас по другому пути — к гораздо более простой и кардинально более эффективной архитектуре. Это не решит всех проблем, но устранит некоторую сложность в большинстве типичных сценариев.
Шаг первый: убрать привилегированные порты. Думаю, это изменение на 1-2 строчки. Вероятно, достаточно просто удалить оператор
if. Сломается всё, что полагалось на не-криптографическую защиту вроде номера порта для безопасности, поскольку такие вещи легко подделать.Шаг второй: расширить пользовательские и групповые разрешения, а также права владения на сетевые ресурсы, введя маски разрешений UID/GID на чтение/запись/привязку (привязка вместо выполнения) для устройств и IP-адресов. По умолчанию вызов
bind() не указывает, что адрес (0.0.0.0 или ::0) будет прослушивать пакеты или соединения на всех интерфейсах, для которых текущий пользователь имеет соответствующее разрешение на привязку, а исходящие соединения по умолчанию будут направляться на первый интерфейс, принадлежащий пользователю.Шаг третий: вероятно, хорошей идеей будет разрешить в пространстве пользователя создание виртуальных сетевых устройств (tun/tap) по той же причине, по которой пользователи могут создавать свои процессы и файлы. Это не критично, но было бы хорошо. Разрешения для программ вроде tcpdump/pcap тоже придётся изменить в соответствии с новой моделью разрешений для сетевых ресурсов.
Теперь любой сервис можно запустить под обычным пользователем. Рутовый доступ нужен только для обновлений ядра системы, изменений аппаратного обеспечения или драйверов, а также для управления пользователями.
Не выбранная дорога уже заросла
Поскольку мы выбрали путь виртуализации и контейнеризации, то позволили атрофироваться способностям к многоарендности в Unix. Понадобится некоторая работа, чтобы вернуть их в форму. Но мне кажется, что это может стоить того — ради простоты и для устранения излишнего потребления ресурсов.
Нам нужно вернуться назад и усилить защиту режима пользователя. Не думаю, что это слишком тяжело. Виртуализация не обеспечивает такую защиту, как многие думают, и атаки вроде Rowhammer доказали, что VM — не панацея. Мы потратили невероятное количество человеко-часов на разработку крепкой и безопасной виртуализации и на разработку цепочки инструментов для этого, не говоря уже о том, сколько потрачено на создание экосистемы контейнеров. Думаю, что части этих усилий было бы достаточно, чтобы защитить user-space на минимальном хосте Linux от атак с повышением привилегий и утечек.
Нам нужно подтянуть другие аспекты изоляции и внедрить опции для ограничения того, что пользователь может видеть с помощью команд вроде ps и netstat — информацию следует ограничить только ресурсами пользователя. Нужно изменить пакетные менеджеры, чтобы разрешить установку пакетов в поддиректорию домашней директории пользователя, если он не рут, и т. д. Вероятно, изменения также потребуются для системных элементов вроде динамического компоновщика, чтобы пользовательским бинарникам было проще делать выбор в пользу общих библиотек в своей собственной локальной области, а не в пользу системных библиотек, если таковые имеются. Было бы хорошо, если бы системные сервисы init поддерживали и сконфигурированные пользователем сервисы, чтобы пользователям не приходилось мастерить скрипты watcher и задания cron, а также прибегать к другим хакам.
Конечный результат будет немного похож на контейнеризацию, но без неуклюжести, раздутости, изобретения велосипеда и неудобства. Вы можете развёртывать приложения в git, запускать git checkout и git pull по ssh, а оркестровка будет выполняться либо локально, либо на манер P2P, и вы сможете просто залогиниться на машину и запустить что-то, без необходимости продираться через сложную инфраструктуру управления контейнерами. Приложения станут легче, потому что большинству программ достаточно общих стандартных библиотек (libc, stdc++ и др.) и стандартных инструментов в системе, если нет каких-либо непреодолимых ограничений, вроде проблем с с совместимостью библиотек.
Заключение
Вероятно, всё это дела давно минувших дней. Скорее всего, в реальности будет выбран путь разработки по-настоящему безопасной контейнерной мультиаренды, так что с помощью контейнеров будет решена задача, которую следовало решить расширением модели разрешений Unix на сетевую подсистему в пространстве пользователя.
Цель этой статьи — показать, как маленькие решения, о которых никто не думал, могут повлечь драматические последствия для будущей эволюции технологии (и общества). Решение 1970-х годов использовать номера портов как встроенный сигнальный механизм для проверки безопасности между системами может оказаться ошибкой на триллион долларов, которая направила эволюцию платформы Unix по пути гораздо большей сложности, стоимости и большего потребления ресурсов.
Но погодите, может, не всё ещё решено. Существует более десятка дистрибутивов Linux, и большинство из них работает примерно одинаково. Переход на новую парадигму станет интересным способом выделиться для одного из этих дистрибутивов. Первым делом нужно реализовать сетевые разрешения вроде описанных выше — и предложить патч для ядра. Для обратной совместимости можно сделать так, например, что разрешения активируются через настройку sysctl, или можно выпустить модуль (если модули способны производить такие глубокие изменения).
Комментарии (86)
khim
12.07.2017 01:20+6И ещё. Бритьё быка — это садизм какой-то. За что, почему?
Як — это далеко не всякий бык! Як — это таки як:
Если вы на него посмотрите — то сразу поймёте, что просто так его не постричь: машинка сразу же забьётся. Да и потом — если вы его «побреете», то он ночью замёрзнет. Потому с него не снимают всю шерсть машинкой, как с овцы (что занимает секунды у высоких профессионалов и минуты людей с хорошими навыками), и аккуратно вычёсывают (что занимает часы).
Мелочь, а неприятно.
ValdikSS
12.07.2017 02:15+30Внезапно, все для этого уже есть: namespaces. Есть сетевые namespaces, которые, например, выделят конкретному пользователю его интерфейс с его IP-адресом, есть PID namespaces, которые не дадут посмотреть процессы других пользователей.
Есть даже готовое ПО для этого: firejail. Можно установить его в качестве шелла для пользователя, и при логине будет выполняться скрипт, переключающий пользователя в его namespace. Файловая система используется хостовая при этом.
Было бы хорошо, если бы системные сервисы init поддерживали и сконфигурированные пользователем сервисы, чтобы пользователям не приходилось мастерить скрипты watcher и задания cron, а также прибегать к другим хакам.
systemctl --userименно это и делает.
powerman
12.07.2017 13:20Именно. И так же есть решения для других упомянутых в статье проблем (использовать привилегированные порты обычный юзер может через
setcap CAP_NET_BIND_SERVICE=+eip, фильтровать какие процессы он видит можно через GrSecurity, etc.). Но — вряд ли это взлетит. Докер удобно прячет всё это под капот, а что до большого размера образов… ну, с одной стороны это не такая уж большая цена, с другой если сервисы писать на Go или просто линковать статически то образ докера может занимать несколько мегабайт, а не гигабайт.
vanburg
12.07.2017 06:15+2Я думаю, многие сейчас даже не задумываются о проблемах типа монструозности и велосипедности этих современных зоопарков vm/контейнерных технологий, и тут я решительно автора поддерживаю. Свернули не туда.
Пока читал, как раз не покидала мысль, а не начнется ли после этой статьи разработка очередного дистра но с указанными патчами?
Ведь на самом деле, на 99% хостов набор пакетов идентичен, и не так уж велик (относительно общей массы). Но, их, может, и не так много, но работа по адаптации будет адовая, конечно.
Отличное чтиво, спасибо!
SirEdvin
12.07.2017 07:14+2А куда еще можно было свернуть? Все идет к удешевлению стоимости разработки и более сложным системам. Тут без дополнительных ресурсов никуда.
hungry_ewok
12.07.2017 11:06+2>Пока читал, как раз не покидала мысль, а не начнется ли после этой статьи разработка очередного дистра но с указанными патчами?
… тут должна быть картинка про 14 несовместимых форматов…
khanid
12.07.2017 15:23+2Ведь на самом деле, на 99% хостов набор пакетов идентичен
Только в части названий. Когда дело доходит до конкретики, то может выясниться, вдруг, что вот эта вещь требует таких версий пакета А, а другая — других версий пакета А. И совершенно не факт, что подмножество версий 1 и 2 окажется друг в друге, ну или хотя бы будет пересекаться.
Примеры? Да пожалуйста. Тот же руби. Там с гемами вполне себе бардак.
Тут у одного пользователя проблемы, а что говорить о многих? Так что адаптация не просто адовая.
Отчасти это проблема и пакетных менеджеров (через yum не ставить зависимости нельзя, например).
Но только отчасти. В разработчиков это тоже упирается. Многие из них и так костылят, а тут вообще будет нечто.
Конечно, что и сейчас решается каким-нибудь ./configure --prefix =/home/vasya/software/swver04, вот только это решение вообще не попадает в категорию идентичных наборов пакетов. И в случае, описанном в статье, кстати, тоже. Всё равно это дополнительный экземпляр, который будет требовать места. А сам образ ОС в готовом виде(далеко чтобы не ходить — CentOS7 в минимальном варианте) даже за 2 Гб не переваливает.
Получается, что экономить пытаемся тупо оперативку, т.к. накладные расходы в 2 Гб места — ничто, по большому счёту.
А вот с ОЗУ и ЦП всё интереснее. Да, у виртуалок есть оверхэд. Но в идее автора тоже есть изъяны. А если по его схеме вдруг не хватает ресурсов? Вот просто у кого-то там нагрузка пиковая возникла. Пострадают все.
Приходим к идеи типа шейпинга процессорного времени и потребления ОЗУ. Опять же. Упирается в всё в то, как ОС работают в принципе. Там таких инструментов не предусмотрено. да. Можно выставлять ограничения в отдельном софте (типа БД). Но в большинстве случаев — нельзя. Получаем гигансткий несогласованный оркестр, которым надо попытаться управлять. Идеи ныне популярной контейнеризации тут ближе (хотя и ВМ, по сути, контейнер) к реальности. Возможно даже можно будет решать схожие задачи через некоторое время.
Это всё только в части идей и прикидок.
А ведь есть ещё безопасность. И ей вообще внимания не уделено кроме как «Да, да, пока что игнорируем безопасность».
Только по этой причине идеи, описанные в статье, будут взлетать плохо. если будут. Для многих безопасность — если не столп, то уж точно не та вещь, которую можно игнорировать.
И кстати, про саму идею разрешить биндиться на привилегированные порты. Ну положим, разрешили. Запустили 5 пользователей. А дальше что? Первый биндится, а остальные получают отлуп, что не удаётся забиндить сервис и создать сокет?
Или биндиться на свободные сокеты а сверху этого ещё делать некий пограничный сервис (хотя бы тот же балансировщик нагрузки, типа haproxy)? А смысл? На, например, 22 порт всё равно свой сервис вешать не станешь, да и вообще тогда такая ситуация не будет отличаться от биндинга на непривилегированный порт, т.к. и сейчас ничто не мешает развёртыванию балансировщиков для ферм с сайтами + этот балансировщик тоже должен кто-то конфигурировать, не раздавать же права на него всем пользователя, в конце концов.
Да и вообще. После прочтения у меня сложилась мысль, что автор несколько ограниченно знаком с тем, как устроены сети и ОС.
То, что он хочет, как по мне, не реализуемо в рамках той экосистемы, что сложилась сейчас. Надо менять принципы работы ОС с ресурсами, протоколы, стандарты. В общем-то, по сути, заново построить операционки, сети, софт. Сделать свой интернет с блэкджеком и шлюхами.
Так что написанное у меня вызывает очень много вопросом вкупе с отсутствием даже примерного понимания, как всё существующее можно трансформировать по направлению к означенным идеям. Да и надо ли? Вот, пожалуй, немаловажный вопрос, т.к. автор изначально гонится за соотношением количество сервисов/Ватт.
Что немного странно.
Сервисы ныне не те, что 20 лет назад. И даже не те, что 7 лет назад. К ним предъявляют совсем иные требования. По скорости разработки, функционалу и т.д. Да, я тоже противник монструозных сайтов, но рисовать сервис на чём-то, что вернёт развитие вебя лет на дцать назад — занятие так себе. Для вещей «попроще» же уже существует решение в виде shared-хостингов.
Да и эффективность энергопотребления железа возросла на порядки. Впору задумываться, а корректно ли сравнивать? Один какой-нибудь пролиант 380 может воплне затянуть сотню простых виртуалок (те самые) при потреблении в 500 Вт. Но это будут полноценные системы со всем функционалом и вспомогательным инструментарием + необязательно только http/https ресурсы. В отличие от. На этом и остановлюсь, пожалуй.jamakasi666
12.07.2017 19:42Проблему с depedency hell решили уже, посмотрите на NixOS. Выкрутились красиво не ломая совместимости с софтом и без его пересборки.
По поводу ОЗУ и ЦП вопрос бы решили, виртуализация тоже не сразу пришла и была достигнута совместно железом и софтом.
По безопасности тоже вопрос очень сильно натянут т.к. не каждому серверу и софту она необходима. Вот скажем если у меня в организации уже стоит сервер который выступает шлюзом\фаирволом\прокси с антивирем\антиддос то заморачиваться с дополнительным оверхэдом на других внутренних серверах нет никакого смысла. Тоже самое и к хостингам относится, подавляющей части веб сайтов в инете не нужно чего то сверхъестественного, грубо говоря можно глянуть и увидеть что львиной доли пользователей до лампочки что они ходят на сервак по ftp и настраивают по ssh с паролем.
В моем представление все выглядело бы примерно так:
1) Любой софт стандартный по дефолту ставит все библиотеки в shared зону оси. Это зона никак не доступна обычным пользователям.
2) Для решения depedency hell нужно прийти к сборке всего софта с привязкой к конкретной версии библиотек(сейчас это почти так но криво). Т.е. скомпиленная софтина напрямую ищет somelib-x.y.z.so а не somelib.so.
3) Именование исполняемых бинарников так же идет по принципу someprogramm-x.y.z но пользователь при мнимой установке просто получает куда нибудь в /home/someuser/bin/ симлинк с именем someprogramm.
4) Если пользователя желает некий свой софт не из репозитория или особо перекомпиленный то либы отличные от дефолтных падают в /home/someuser/privatelibs/ а бинарник все туда же в /home/someuser/bin/
5) etc также в папку пользователя.
6) сетевой стек. Ну как вариант уже выше предлагали ipv6 или действительно указание порта в dns.
В общем все это впринципе решаемые задачи, насчет секьюрности получилось бы явно не хуже чем сейчас с виртуализацией. Все это жрало бы меньше места на винтах и кушало бы заметно меньше ресурсов но при этом вероятно требовало более сложных реализаций в ОС.khanid
12.07.2017 20:53Да. Решаемые. Но мой посыл слегка в другом. Автор видит современные системы через призму своих узкоспециализированные задач и понимания мира ИТ (так-то линукса, но, по факту, там тянется всё подряд). А из того, что я описал не сказать, что оно нерешаемо (решаемо, как я упомянул, но требует изменений в стандартах, на оконечных системах (у клиентов и серверов) в протоколах и обслуживающем оборудовании), или будет более удобным. Просто всё будет работать по-другому. Не удобнее, а по-другому. По сути, работа ради работы. Это глупое занятие.
Что касательно безопасности. В периметре сети мало угроз (или скомпрометированная машина, являющаяся источником бед в сети — уже миф?)? А как же виндовый путь самурая (1 сервер — 1 роль), который, по сути, перекликается с unix-way? Автор изначально поднял вопросы, которые энтерпрайза и касаются слабо, скорее именно провайдеров хостинга, серверов и прочих подобных услуг.
А про подобное безобразное отношение к безопасности уже красиво написал grieverrr — «вьетнамское общежитие и лотерея».
Если хочется сыграть в такую лотерею, то и сейчас нет препятствий.jamakasi666
12.07.2017 21:25С посылом согласен полностью, но и автор пишет что к чему мы пришли и как бы могло бы быть. Сильно вероятно что если бы изначально пошли по пути о котором пишет автор не было бы сейчас статьи с пунктом "'Вьетнамское общежитие и лотерея обходятся дорого и сложно'" и т.д… И никто не отменял правило что любое решение имеет свои плюсы и минусы.
В периметре сети мало угроз (или скомпрометированная машина, являющаяся источником бед в сети — уже миф?)?
Ну если тачку скомпрометировали то это врядли спасет другие тачки, чем бы они обвешаны небыли. Живой пример недавняя история с «фейковым иваном» который положил кучу всего в том числе пару хостингов со всеми их виртуалками и контейнерами(не могу дать ссылку но инфа была в потоке тех дней).khanid
12.07.2017 22:37Ну это из разряда вот если бы дедушка был бы бабушкой…
Далеко ходить не надо подобных если бы очень много встречается в отношении ipv4 в темах обсуждения/статьях по ipv6.
Но по факту имеем, что имеем. И это работает по всем параметрам не так уж и плохо, тем более обкатанное практикой и ставшее стандартами де-факто.
По компрометации. Вы берёте идеальные условия, типа однородной среды и т.п. Часто это не так и эшелоны защиты едят свои мегагерцы не зря.
Gendalph
12.07.2017 20:26А вот с ОЗУ и ЦП всё интереснее. Да, у виртуалок есть оверхэд. Но в идее автора тоже есть изъяны. А если по его схеме вдруг не хватает ресурсов? Вот просто у кого-то там нагрузка пиковая возникла. Пострадают все.
Приходим к идеи типа шейпинга процессорного времени и потребления ОЗУ. Опять же. Упирается в всё в то, как ОС работают в принципе. Там таких инструментов не предусмотрено. да. Можно выставлять ограничения в отдельном софте (типа БД). Но в большинстве случаев — нельзя. Получаем гигансткий несогласованный оркестр, которым надо попытаться управлять. Идеи ныне популярной контейнеризации тут ближе (хотя и ВМ, по сути, контейнер) к реальности. Возможно даже можно будет решать схожие задачи через некоторое время.cgroups, anyone?
khanid
12.07.2017 20:59-1Хм, о cgroups я знаю только в контексте контейнеризации (которая тоже претит автору статьи).
В вопросе применения в работе для ограничения ресурсов пользователей/сервисов не разбирался.
Но даже так. Это всего лишь один из аспектов. Есть множество других, более сложных для решения вопросов.Gendalph
12.07.2017 22:47Так в том и прикол что современная контейнеризация это, по-сути, солянка из namespaces, cgroups и aufs/overlay/btrfs.
Первые два — ядерные механизмы, уже присутствующие в ядре (как минимум с Ubuntu 12.04). Если к этому добавить SELinux или AppArmor — получаем достаточный уровень изоляции.
Всё это уже можно задействовать на полную катушку в современных дистрах, где есть SystemD (там поддержка пока что наиболее полная — изоляция вплоть до сервиса).
Менять, конечно, пришлось бы уйму всего, но масса механизмов для изоляции и контроля уже существует и даже работает.
g7xd
13.07.2017 10:36Если уж на то пошло — изначально docker создавали для простоты разработки и доставки приложений, а не для того чтобы на нем в продакшене крутится
Skyroger2
12.07.2017 08:36RPi стоит $30 и потребляет менее 15 Вт. Нужно ли говорить, сколько стоит одна монструозная VM и сколько она потребляет?
Нужно конечно. 3-4 доллара в месяц для конечного потребителя она стоит вместе с электричеством, инфраструктурой, оркестрацией, маршрутизацией и прочим.
Автор хочет поставить Web сервер на RPi? Мне как-то было нужно собрать для неё QT5, а заморачиваться с кросс-компиляцией было лень. После полутора суток компиляции я таки разобрался, думаю, что даже довольно дохлая виртуалка тут посильнее будет.
jaiprakash
12.07.2017 11:16+2Raspberry Pi — на компьютере, который примерно в 100 раз превосходит старый сервер по мощности CPU
Ага, крайне спорное утверждение. Откуда он это взял?Skyroger2
12.07.2017 11:41Кстати за те же 3-4 доллара в месяц можно получить и выделенный сервер на базе ARM. И не на RPi, прости господи, а на чём-то более серверном, с SSD. Я правда не слышал, что кто-то на подобном пытался
хостить по крайней мере 50 сайтов маленького или среднего размера
, но автор может попробовать.
Areso
13.07.2017 08:20Зависит от количества хитов в сутки и их размазанности по времени. Ну и от самих скриптов на сайтах (если они есть).
khim
12.07.2017 13:58+2Ага, крайне спорное утверждение. Откуда он это взял?
С потолка. На самом деле всякие разные бенчмарки показывают разница скорее раз в 20-30… чего для целей статьи как достаточно: RPi многократно мощнее компьютеров, на которых сидели и работали одновременно десятки, а иногда и сотни, пользователей.
tankistua
12.07.2017 08:39+4Как показывает практика: если вопрос можно решить купив новый сервер — проще купить новый сервер.
Программисты дорого стоят, а на доведение системы до продакшина может уйти просто неимоверное количество времени, поэтому у нас и дальше будет виртуализация и контейнеры. Пока эта вся конструкция не перестанет работать — никто не пошевелится
Mnemonik
12.07.2017 09:42+3Мне тоже 37, но я не считаю себя динозавром и не скучаю по своему 286-му с 40 мегабайтным диском.
Контейнирезация достойное решение всех проблем описаных тут и логичная эволюция, а вот мультиаренда имеет несколько принципиальных проблем — бэкап довольно сложен и уязвим (и я сейчас говорю про бэкап и восстановление вместе как процедуру). Не уверен что можно сделать снапшот директории и так же выкатить ее обратно, особенно это коснется бинарных хранилищ типа файлов mysql.
Ну и конечно это плохо вертикально масштабируемая система — слабо себе представляю процесс при котором пользовательские директории и запущенные процессы можно будет бесшовно передавать между серверами для распределения нагрузки в кластере.
Alexeyslav
12.07.2017 10:43Мой 286-й(на самом деле 486-й) давно уже распилен на кристаллик и его 40-мегабайтный диск служит зеркальцем-талисманом.
Nakosika
12.07.2017 19:51+1У вас был жесткий диск… Зависть.
LynXzp
12.07.2017 21:49+1У Вас был гибкий диск… Зависть. (НГМД)
У Вас были касеты… Зависть.
У Вас были перфокарты… Зависть.Nakosika
13.07.2017 02:49286е далеко не все оснащались жёсткими дисками, нищеброды вроде меня ходили с пачками дискет и жутко завидовали тем, у кого были харды. Сорокет — это вообще дикая роскошь.
LynXzp
13.07.2017 10:07А у меня только 5 дюймовые дискеты. И на две-три дискеты вмещалось все. Но хранилось в пяти копиях, которые нужно было время от времени проверять и перезаписывать битые данные. Basic, системный монитор и рапира — все «ОС» (Бейсик и рапира совсем не ОС, но как-то неразрывно были связаны с неким подобием ОС хранившимся на загрузчике дискеты).
zeronice
12.07.2017 10:18+13Какие то странные расчеты… Если брать предложенный RPi с потребностями в 10 Вт, то стоит вспомнить, что сервер с двумя 18ядерными (еще и с HT) Xeon`ми и 512Гб RAM будет есть в пике 700Вт (Это если еще дисков штук 8-12 навесить) и стоит такая махина 17-18 т долларов. R pi 3 стоит $40, разница в 450 раз, но при этом все эти 450 экземпляров можно смело запустить в VM на предложенном сервере. Опустим здесь различие x86 и АРМ, так как итоговый перевес в производительности будет зависеть сильно от задач. В итоге потребление 450 Rpi будет 4.5 киловатт, против 700. И кто здесь говорит за выбросы углекислого газа?
Второй момент экологии — потребленные материалы для производства. суммарный вес 450 RPi3 — около 31 кг, предложенный x86 сервер — около 20 кг, при том, что значительную часть веса составляет добротный корпус, напрочь отсутствующий в базовой поставке Rpi.
Третий момент — надежность. Сервер априори отработает положенный срок (ведь $18k у нас еще и NextBusinessDay гарантия на три года и можно за $1k еще на два года купить), а сколько малинок передохнет за этот период? и сколько потратится ресурсов на их замену и убытки по простою?
Прочие детали типа портов опустим за скобки (в конце концов предложенная модель не подразумевает навешивать оборудование на несетевые порты)
Так что в общем итоге видна только зеленая истерика, ошибочные расчеты и крик "раньше было лучше".
Angerslave
12.07.2017 10:42+1Не нашёл сколько энергии жрёт SPARC 10, но 20-й потребляет 125 Вт (http://docs.oracle.com/cd/E19127-01/sparc20.ws/801-6189-12/801-6189-12.pdf). 125 ватт, Карл! На современном железе на 125-ти ваттах можно запустить сервисы для всего интернета того времени.
Ну и за экономику плюс. Прогресс не в сторону эфемерной "простоты" движется, а в сторону экономической эффективности. Жизнь слишком коротка, чтобы писать на ассемблере.
Zalechi
12.07.2017 15:07+21) Rpi — взяли, как пример. Теперь пофантазируйте, что можно было бы реализовать на описанном Вами «Зеоне»!
2) Автор в конце статьи уточнил, что речь идёт о фундаментальном эволюционном сдвиге, который претерпела unix/linux — негативном по его мнению. Да, автор сентимальным образом заглядывается в прошлое, что бы выразить свою позицию.
3) Конечно автор немного раздул и приукрасил, как это делают в Голливуде или современная журналистика. Однако лично я, поддерживаю такой подход, Здесь Вы прочитали не скучный, обоснованный с точки зрения автора рассказ.
mayorovp
12.07.2017 10:29+1Не все так просто, и для подобного перехода понадобится куда больше изменений.
Во-первых, часто на VDS-ке крутится не один сервис, а несколько. Хорошей практикой в таком случае является создание отдельных пользователей для каждого сервиса.
Если вместо VDS-ки выдавать пользователей на общем сервере — то пользователям понадобится механизм для создания суб-пользователей. Я еще не читал про системы, где такой механизм бы существовал.
jaiprakash
12.07.2017 11:05+6А что тогда такое обыкновенный shared hosting, где и крутятся сотни-тысячи вордпрессов на сервер?
khim
12.07.2017 14:03+2Собственно проблема в том, что вместо того, чтобы «довести до ума» shared hosting и сделать так, чтобы там можно было не только форум на PHP разместить мы перешли к системам лишь чуть более гибким, но жрущих ресурсы на два порядка больше.
jaiprakash
12.07.2017 15:06+1Видел shared'ы с пёрлом, с питоном.
Тут, например, инструкция установки ноды без спроса хостеров (не знаю, везде ли это получится).
Такое ощущение, что мода на VPS для сайтов-визиток — обычный маркетинг.
Меня смущает другое: на протяжении всей статьи автор упорно делает вид, что кроме VM ничего не используется, причём конкретно для php.Areso
13.07.2017 08:25В России это еще и гарантия, что РКН не убьет доступ одним ударом 1000 сайтов, если у вас кто-то из соседей варит галлюциногены из грибов в Eve Online.
jaiprakash
13.07.2017 12:26Выделенный IP
KorDen32
14.07.2017 10:20… вместе с которым стоимость шареда может начать превышать стоимость минимальной VPS. Упс.
jaiprakash
14.07.2017 16:33Бывает и так. И вот тут проходит водораздел: если есть айтишник — лучше VPS, т. к. и поиграться, и ресурсов побольше.
А большинство предпочитают shared, т. к. в их случае сравнивать нужно с обслуживаемым VPS.
Да и вообще, выделенный IP зачастую можно включить и выключить одной галкой, в зависимости от важности/уровня паранойи на сегодня/на месяц:Вы вложили денег в контекстную рекламу под НГ, ожидаете наплыва покупателей и тут банят кого-то из соседей
sumanai
12.07.2017 16:52+1Тоже хотел написать. Если идти дальше, используя логику автора, то зачем каждому пользователю свой MySQL сервер и инстанс PHP, которые будут занимать десятки мегабайт ОП, когда их можно расшарить? И получился шаред. И там не сотни и не тысячи, а десятки тысяч сайтов.
grieverrr
12.07.2017 17:26+1шаред-хостинг в текущем его состоянии — вьетнамское общежитие и лотерея. размещать там что-то в продакшен ни один вменяемый человек не станет.
inb4 перепись экстрималовjaiprakash
12.07.2017 18:46+1>вьетнамское общежитие и лотерея
Ну некоторым повезло с комендантом общежития и там царит полный порядок.
Очень много сайтов — визитки небольших фирм, причём не про ИТ. Если что случится — ну пару дней не придут через контекстную рекламу новые клиенты, но старые по телефону свяжутся. Далеко не у всех есть возможность поддерживать VPS, а так комендант накатывает обновления. Я уже молчу про бложики.
Статья же про сайты на вордпрессе, а не убийц фэйсбуков.grieverrr
12.07.2017 19:23На длинном промежутке времени полного порядка нет и быть не может, хотя бы из-за 0day уязвимостей типа dirty cow.
Сами же пишете про везение.jaiprakash
12.07.2017 19:28+7Зато для обычной фирмы без вменяемого айтишника, но с VPS, актуальны будут не 0day, а 1-10year уязвимости. И причём боты их найдут наверняка, даже везение не спасёт.
Areso
13.07.2017 08:33Представьте себе ситуацию. Вы вложили денег в контекстную рекламу под НГ, ожидаете наплыва покупателей и тут банят кого-то из соседей. Деньги, вбуханные на рекламу, сразу идут побоку. Поисковый трафик идет побоку. Короче, праздники успешно сфейлены.
Что касается VPS и обслуживания, уже сейчас есть немало хостингов, предлагающих обслуживание типовых VPS за скромные 400-500 рублей в месяц (комендант по расписанию, и вне расписания со срочными апдейтами безопасности). Этот вариант даже лучше своего админа, потому что свой админ может и не сильно разбираться в LAMP инфраструктуре.
Итого 1000 рублей в месяц, чтобы не беспокоиться ни за что — я считаю адекватным предложением.jaiprakash
13.07.2017 12:33>банят кого-то из соседей
Выделенный IP
>Итого 1000 рублей в месяц, чтобы не беспокоиться ни за что
Я не говорю, что шаред нужен абсолютно всем. Но большинство людей не имеет гиковского интереса к «своему», хоть и виртуальному серверу. И для них это просто лишние расходы, как в развёртывании, так и поддержании. А на выходе — всё та же визитка. Так зачем это всё?
serg_p
12.07.2017 12:20Я 1970, первая программа 1984 — первый интернет 1990. Смешно было читать про «архей». А в целом да
Scf
12.07.2017 13:30-1Разделение сети как раз не проблема, 99% софта под линукс позволяет настраивать используемые порты. Проблема — это инсталляционные пакеты, которые крайне сложно установить без прав рута. Все норовят писать в /etc, прописывать себя в сервисы и разваливаться при попытке установить как-то иначе.
Лично я всегда деплою контейнеры с --net=host и никогда об этом не жалел.mayorovp
12.07.2017 13:57+2Нет, разделение сети — это как раз проблема. На сервере-то можно порт любой прописать, тут вы правы. Но клиент будет ожидать увидеть стандартный порт для протокола, а не какой-то там еще.
allter
12.07.2017 17:28+2Так это не проблема Unix, и привелегированные порты — не причина этого. Вполне можно обойти и это, внедря поддержку DNS SRV для _http/_https в популярные браузеры, предварительно внеся соответствующие изменения в RFC на HTTP/HTTPS. Но это маловероятно из-за описанного в статье эффекта path dependence (т.к. внести изменения нужно одновременно на всех клиентах, включая устаревшие).
Автор статьи упрощает проблему, которую решает виртуализация. Проблема не только в том, что бы запустить несколько серверов на хосте, а ещё и в том, что бы можно было этот хост ремонтировать/апгрейдить и что бы у пользователей ничего не менялось. Для этого нужен «продвинутый chroot», который сейчас практически сделали под вывеской контейнеров.
Scf
15.07.2017 08:34Для собственных приложений в приватных сетях это решается через service discovery. Для публичных сетей ставится прокси, который слушает публичный порт и перенаправляет запрос на нужный экземпляр, слушающий на произвольном порту.
galserg
12.07.2017 15:14+6автор фантазирует в области, в которой он разбирается как свинья в апельсинах
начнем с того, что все 3 из моих RPi 3 в режиме самого жесткого оверклокинга и под хорошей нагрузкой по амперметру потребляют не более 0,5А
напряжение питания, кто не знает — 5 вольт. закон ома знают все?
ну остальное высосано из того же пальца.
кстати — давно есть хостинги для апликейшенов. в облаках. сейчас народ пилит хостинги контейнеров.
но скажите, кому и нахрена в 2017 году нужен бложек на вордпрессе?
а то, что нужно бизнесу — и на тысяче армов не взлетит.
и да, 14 ядер xeon — это не монстр, а самый дешевый начальный вариант из последней линейки.questor
13.07.2017 03:53+1Но согласитесь, что и не каждому бизнесу нужен свой сайт уровня Фейсбук и гмейл.
rkosolapov
13.07.2017 10:10+2но скажите, кому и нахрена в 2017 году нужен бложек на вордпрессе?
В 2017 году почти 30% сайтов работают на вордпрессе, почти 60% рынка (по баблу) заказной разработки сайтов — это вордпресс. Но да, можно продолжать мерить людей по себе и думать, что вордпресс не нужен.
Areso
13.07.2017 10:39+1Бизнес он ведь разный бывает.
Если это магазин, у которого в онлайне лишь «витрина», то ему важно а) доступность б) актуальность наличия и цен. И владельцу магазина будет абсолютно ровно на все наши гиковские технологии, до тех пор пока его удовлетворяет цена и его две основных хотелки.Alexeyslav
14.07.2017 13:43И до тех пор пока сайт не дефейснут/заразят трояном который вполне способен угробить репутацию магазина.
Areso
14.07.2017 13:47Я как-то оформил заказ на 3 Intel Stick'a по цене 600 рублей или около того. Когда пришел с деньгами забирать товар, заказ без долгих разговоров обнулили и все. И ничего, магазин работает до сих пор)
galserg
13.07.2017 13:34отвечу всем одно и то же
бизнесу — даже самому вонючему магазину — нужна SQL база с как минимум одной репликацией, плюс NOSQL для кеша и временных данных, апликейшен сервер (все чаще идет отказ от пхп в торговых решениях, но pxp-fpm тоже можно считать как таковой), веб фронтэнд, бекенд REST API, мобильная аппка, система бекапов, мониторинг инфраструктуры.
даже при минимальном к-ве покупателей онлайн — это невозможно сделать не то что на одной пи-шке, а в пределах одного физического хоста, ибо в случае падения оного — магазин превращается в тыкву.
что до 30 или 60 процентов сайтов на вордпрессе — да не вопрос, такое имеет место. но если считать по количеству посетителей — на все эти хомяки и сайты визитки ходит доли процента юзеров.Areso
14.07.2017 13:50+2В регионах до сих пор выгружают прайсы в виде xls/pdf на сайты, и ничего. У вас слишком большое предложение для малых магазинов))
slayerhabr
12.07.2017 20:10Вы потратили гораздо больше ампер*часов нашей планеты, тех пользователей который прочитали эту муру.
Кстати почему не начали с Адама и Евы?
Zalechi
12.07.2017 21:30-1Ха. А ведь это и есть эволюция. Здесь и сейчас — математика и бизнес, я и Вы вершим судьбу.
dlazerka
13.07.2017 04:20+2Всё верно, но
Мне по-прежнему нужны рутовые права, чтобы запустить контейнер.
Ну вот почему, почему, скажите мне, никто не дочитывает гайд «Install Docker» до конца? Там же написано
(то есть администратор разрешает юзерам запускать докер от своего аккаунта, точно так же, как разрешает им вообще логинится в систему).sudo usermod -aG docker $USER
Так что не нужны ему рутовые права, пускай гайд дочитает.
dlazerka
13.07.2017 04:45Контейнер для запуска 10-мегабайтной программки может весить несколько гигабайт.
Автор наверно имел ввиду образ (image).
Не знаю, не знаю, мой образ с "тяжёлой" Java+Kotlin и всякими свистелками типа Jersey REST-сервлетов весит 102.2МБ (все слои).FROM openjdk:8-jre-alpine.
Если он всё же имел ввиду потребление памяти контейнером, то и тут тоже не сходится — проверил, мой потребляет 236 МБ из
docker stats, из которых 150МБ — мой жава-сервер внутри, значит сам контейнер всего 86МБ.
Автор, похоже, что-то делает не так.
rkosolapov
13.07.2017 10:12+1Автор вообще дико ошибается в оценке стоимости оверхеда контейнеризации во-первых, во-вторых сильно ошибается в важности расхода машинных ресурсов (в той области, про которую он говорит). В итоге предлагает решать проблему, которой на самом деле нет.
Areso
13.07.2017 10:45Все зависит от цены и доступности ресурсов. К примеру, если самая дешевая VPS OpenVZ в вашей стране стоит $10 c нулевым уровнем сервиса (потому что запрещено регистрировать хостить сайты с доменном страны за рубежом, оттого конкуренции тупо нет — выбирать можно между дорогими и плохими или дорогими и очень плохими хостингами).
rkosolapov
13.07.2017 10:51Ок, спешл кейзы есть, но, наверное, к ним и подход имеет смысл искать специальный, а не общий.
Ivan_83
14.07.2017 02:05+1Согласен что виртуалками и всякими контейнерами и прочим слишком злоупотребляют: когда простенькое приложение пихают в виртуалку только чтобы криворукий админ его мог легко перенести на др сервер это перебор.
Но вот дальше, автор как то отстал от жизни.
У nginx, php-fpm вполне настраиваются папки куда можно ложить конфиги.
Можно либо добавить туда папки из хомдир хомячков либо в общих папках пошаманить с разрешениями.
А дальше реалоад в крон на каждый 5 минут и вот 80 порт шарится на кучу виртуал хостов.
Отключение привилегированных портов делается через sysctl, portrange легко задаётся.
тцпдамп и прочее — это вроде как разрешение на /dev/bpf нужно поменять.
Ещё во фре есть MAC фреймворк, написав к нему модуль или заюзав готовые можно очень гибко разрешать/запрещать отдельные сисколы для отдельных хомяков и даже реагировать на разные аргументы.
Потом, опять же 100500 интерфейсов не нужны, можно алиасами на интерфейс повешать 100500 адресов, а если хомякам нужно и исходящий адрес, то есть fib — отдельная таблица маршрутизации закрепляемая за приложением, но вроде как и за юзером можно закрепить через логинкласс.
Правда я не задумывался насколько это всё вандалоустойчиво относительно виртуализации.mayorovp
14.07.2017 09:21Конфиг nginx в папке пользователя — это попросту опасно. В конфигах-то можно разное по-написать...
Про интерфейсы вы не поняли. Автор писал про создание tun или tap-интерфейсов, на такой адрес вешать 100500 адресов алиасами нет смысла.
Gendalph
14.07.2017 11:33+1Позволю себе не согласиться: контейнеризация — отличная вещь, позволяющая добиться повторяемости результата и упрощающая горизонтальное масштабирование.
А дальше реалоад в крон на каждый 5 минут и вот 80 порт шарится на кучу виртуал хостов.
А что если кто-то намеренно сломает свой конфиг?
Правда я не задумывался насколько это всё вандалоустойчиво относительно виртуализации.
В том-то и дело что оно неустойчиво :)
Гораздо лучше контейнеризовать приложение и дать доступ к БД (если речь о Postrges или MySQL).
Рассмотрим оверхед на примере LXC:
- виртуальный сетевой интерфейс (можно отдать и железный, если есть желание)
- init
- sshd
- легковесное окружение
Это всё в совокупности занимает меньше 1ГБ места и жрет меньше 200М ОЗУ при длительной работе. Оверхед по CPU минимален.
Что мы получаем взамен?
- изоляция сети и процессов на уровне namespaces
- контроль ресурсов на уровне cgroups
- эквивалент chroot
- переносимость (можно один и тот же контейнер запустить на любом сервере, поддерживающем LXC)
Это всё реализуется и без контейнеров, но заворачивание этого всего в контейнер дает пользователю свою песочницу, почти эквивалентную VPS (нельзя грузить модули ядра и крутить sysctl, плюс ломается софт типа NFSd ввиду специфики работы с ядром).
mickvav
Так все-таки не понятно, как по мнению автора ядро должно будет решать, какому из 50-ти пользовательских апачей разных пользователей отдать прилетевшее tcp-соединение, если у сервера ровно 1 ip-ник.
khim
Назначить серверу 1000000 IP'шников, не? Всё-таки у нас IPv6 уже «на мази», а все предлагаемые изменения не пару часов займут.
ufm
На самом деле добавление в DNS возможности указать номер порта не только решает проблему «как разместить на одном ip адресе несколько тысчяч сайтов» но и в результате делает ipv6 просто ненужным.
grieverrr
а можно на пальцах
weirded
Случайно продублировал вот этот комментарий ниже
JustRamil
Разверните пожалуйста ваше утверждение.
sumanai
Так номер порта это всего лишь 65536 значений, и проблемы нехватки IPv4 это никак не решит.
Gendalph
Записи SRV так и не обрели популярности...
izzholtik
nginx'у.
khanid
Сервисы не ограничиваются http/https.
mayorovp
Сейчас у каждого контейнера — свой адрес. После гипотетического преобразования контейнеров в пользователей все эти адреса "уйдут" основному хосту, и у каждого пользователя будут права прослушивать один адрес.
g7xd
Ок, теперь попробуйте поднять 2 контейнера nginx с пробросом 80 порта в хост из обоих
Zalechi
Фантазии не хватает? Эт изи:
1) NAT — это когда некий процесс дерижирует сопоставлением «отдельных запросов через единственный мост», если так можно выразиться. Тут воображению нет предела. Хотите так, хотите сяк. Главное объяснить каждому TCP-запросу куда идти(кому отдавать и у кого забирать данные). Если честно, тут автор намудрил(в комментах ниже Вы это увидите), но, как работает NAT на уровне IP-протокола, так же можно(ассоцитивно) организовать работу некоего процесса, который будет рулить трафиком, данными отдельного пользователя…
2) PROXY
3) SOCKETS
Это всё красивые слова, НО!!! Если где и есть смысл устраивать наслоение(менджмент), то это на уровне идентификации отправителя/получателя данных…
Я лично с автором согласен в одном точно: Вместо того, что бы внедрять инновационные правила и возможности, мы/они городим костыли на старых, изживших себя технологиях, ток что бы ускорить процесс разработки и вписаться в дед-лайн. Мне кажется, что основной посыл автора именно в этом. Он мыслит академически, хотя может и не достаточно качественные решения предлагает.