Комментарии 86
Так все-таки не понятно, как по мнению автора ядро должно будет решать, какому из 50-ти пользовательских апачей разных пользователей отдать прилетевшее tcp-соединение, если у сервера ровно 1 ip-ник.
Назначить серверу 1000000 IP'шников, не? Всё-таки у нас IPv6 уже «на мази», а все предлагаемые изменения не пару часов займут.
На самом деле добавление в DNS возможности указать номер порта не только решает проблему «как разместить на одном ip адресе несколько тысчяч сайтов» но и в результате делает ipv6 просто ненужным.
а можно на пальцах
Случайно продублировал вот этот комментарий ниже
Записи SRV так и не обрели популярности...
Сейчас у каждого контейнера — свой адрес. После гипотетического преобразования контейнеров в пользователей все эти адреса "уйдут" основному хосту, и у каждого пользователя будут права прослушивать один адрес.
Фантазии не хватает? Эт изи:
1) NAT — это когда некий процесс дерижирует сопоставлением «отдельных запросов через единственный мост», если так можно выразиться. Тут воображению нет предела. Хотите так, хотите сяк. Главное объяснить каждому TCP-запросу куда идти(кому отдавать и у кого забирать данные). Если честно, тут автор намудрил(в комментах ниже Вы это увидите), но, как работает NAT на уровне IP-протокола, так же можно(ассоцитивно) организовать работу некоего процесса, который будет рулить трафиком, данными отдельного пользователя…
2) PROXY
3) SOCKETS
Это всё красивые слова, НО!!! Если где и есть смысл устраивать наслоение(менджмент), то это на уровне идентификации отправителя/получателя данных…
Я лично с автором согласен в одном точно: Вместо того, что бы внедрять инновационные правила и возможности, мы/они городим костыли на старых, изживших себя технологиях, ток что бы ускорить процесс разработки и вписаться в дед-лайн. Мне кажется, что основной посыл автора именно в этом. Он мыслит академически, хотя может и не достаточно качественные решения предлагает.
1) NAT — это когда некий процесс дерижирует сопоставлением «отдельных запросов через единственный мост», если так можно выразиться. Тут воображению нет предела. Хотите так, хотите сяк. Главное объяснить каждому TCP-запросу куда идти(кому отдавать и у кого забирать данные). Если честно, тут автор намудрил(в комментах ниже Вы это увидите), но, как работает NAT на уровне IP-протокола, так же можно(ассоцитивно) организовать работу некоего процесса, который будет рулить трафиком, данными отдельного пользователя…
2) PROXY
3) SOCKETS
Это всё красивые слова, НО!!! Если где и есть смысл устраивать наслоение(менджмент), то это на уровне идентификации отправителя/получателя данных…
Я лично с автором согласен в одном точно: Вместо того, что бы внедрять инновационные правила и возможности, мы/они городим костыли на старых, изживших себя технологиях, ток что бы ускорить процесс разработки и вписаться в дед-лайн. Мне кажется, что основной посыл автора именно в этом. Он мыслит академически, хотя может и не достаточно качественные решения предлагает.
И ещё. Бритьё быка — это садизм какой-то. За что, почему?
Як — это далеко не всякий бык! Як — это таки як:
Если вы на него посмотрите — то сразу поймёте, что просто так его не постричь: машинка сразу же забьётся. Да и потом — если вы его «побреете», то он ночью замёрзнет. Потому с него не снимают всю шерсть машинкой, как с овцы (что занимает секунды у высоких профессионалов и минуты людей с хорошими навыками), и аккуратно вычёсывают (что занимает часы).
Мелочь, а неприятно.
Як — это далеко не всякий бык! Як — это таки як:
Если вы на него посмотрите — то сразу поймёте, что просто так его не постричь: машинка сразу же забьётся. Да и потом — если вы его «побреете», то он ночью замёрзнет. Потому с него не снимают всю шерсть машинкой, как с овцы (что занимает секунды у высоких профессионалов и минуты людей с хорошими навыками), и аккуратно вычёсывают (что занимает часы).Мелочь, а неприятно.
Внезапно, все для этого уже есть: namespaces. Есть сетевые namespaces, которые, например, выделят конкретному пользователю его интерфейс с его IP-адресом, есть PID namespaces, которые не дадут посмотреть процессы других пользователей.
Есть даже готовое ПО для этого: firejail. Можно установить его в качестве шелла для пользователя, и при логине будет выполняться скрипт, переключающий пользователя в его namespace. Файловая система используется хостовая при этом.
Есть даже готовое ПО для этого: firejail. Можно установить его в качестве шелла для пользователя, и при логине будет выполняться скрипт, переключающий пользователя в его namespace. Файловая система используется хостовая при этом.
Было бы хорошо, если бы системные сервисы init поддерживали и сконфигурированные пользователем сервисы, чтобы пользователям не приходилось мастерить скрипты watcher и задания cron, а также прибегать к другим хакам.
systemctl --user именно это и делает.
Именно. И так же есть решения для других упомянутых в статье проблем (использовать привилегированные порты обычный юзер может через setcap CAP_NET_BIND_SERVICE=+eip, фильтровать какие процессы он видит можно через GrSecurity, etc.). Но — вряд ли это взлетит. Докер удобно прячет всё это под капот, а что до большого размера образов… ну, с одной стороны это не такая уж большая цена, с другой если сервисы писать на Go или просто линковать статически то образ докера может занимать несколько мегабайт, а не гигабайт.
Я думаю, многие сейчас даже не задумываются о проблемах типа монструозности и велосипедности этих современных зоопарков vm/контейнерных технологий, и тут я решительно автора поддерживаю. Свернули не туда.
Пока читал, как раз не покидала мысль, а не начнется ли после этой статьи разработка очередного дистра но с указанными патчами?
Ведь на самом деле, на 99% хостов набор пакетов идентичен, и не так уж велик (относительно общей массы). Но, их, может, и не так много, но работа по адаптации будет адовая, конечно.
Отличное чтиво, спасибо!
Пока читал, как раз не покидала мысль, а не начнется ли после этой статьи разработка очередного дистра но с указанными патчами?
Ведь на самом деле, на 99% хостов набор пакетов идентичен, и не так уж велик (относительно общей массы). Но, их, может, и не так много, но работа по адаптации будет адовая, конечно.
Отличное чтиво, спасибо!
А куда еще можно было свернуть? Все идет к удешевлению стоимости разработки и более сложным системам. Тут без дополнительных ресурсов никуда.
>Пока читал, как раз не покидала мысль, а не начнется ли после этой статьи разработка очередного дистра но с указанными патчами?
… тут должна быть картинка про 14 несовместимых форматов…
… тут должна быть картинка про 14 несовместимых форматов…
Ведь на самом деле, на 99% хостов набор пакетов идентичен
Только в части названий. Когда дело доходит до конкретики, то может выясниться, вдруг, что вот эта вещь требует таких версий пакета А, а другая — других версий пакета А. И совершенно не факт, что подмножество версий 1 и 2 окажется друг в друге, ну или хотя бы будет пересекаться.
Примеры? Да пожалуйста. Тот же руби. Там с гемами вполне себе бардак.
Тут у одного пользователя проблемы, а что говорить о многих? Так что адаптация не просто адовая.
Отчасти это проблема и пакетных менеджеров (через yum не ставить зависимости нельзя, например).
Но только отчасти. В разработчиков это тоже упирается. Многие из них и так костылят, а тут вообще будет нечто.
Конечно, что и сейчас решается каким-нибудь ./configure --prefix =/home/vasya/software/swver04, вот только это решение вообще не попадает в категорию идентичных наборов пакетов. И в случае, описанном в статье, кстати, тоже. Всё равно это дополнительный экземпляр, который будет требовать места. А сам образ ОС в готовом виде(далеко чтобы не ходить — CentOS7 в минимальном варианте) даже за 2 Гб не переваливает.
Получается, что экономить пытаемся тупо оперативку, т.к. накладные расходы в 2 Гб места — ничто, по большому счёту.
А вот с ОЗУ и ЦП всё интереснее. Да, у виртуалок есть оверхэд. Но в идее автора тоже есть изъяны. А если по его схеме вдруг не хватает ресурсов? Вот просто у кого-то там нагрузка пиковая возникла. Пострадают все.
Приходим к идеи типа шейпинга процессорного времени и потребления ОЗУ. Опять же. Упирается в всё в то, как ОС работают в принципе. Там таких инструментов не предусмотрено. да. Можно выставлять ограничения в отдельном софте (типа БД). Но в большинстве случаев — нельзя. Получаем гигансткий несогласованный оркестр, которым надо попытаться управлять. Идеи ныне популярной контейнеризации тут ближе (хотя и ВМ, по сути, контейнер) к реальности. Возможно даже можно будет решать схожие задачи через некоторое время.
Это всё только в части идей и прикидок.
А ведь есть ещё безопасность. И ей вообще внимания не уделено кроме как «Да, да, пока что игнорируем безопасность».
Только по этой причине идеи, описанные в статье, будут взлетать плохо. если будут. Для многих безопасность — если не столп, то уж точно не та вещь, которую можно игнорировать.
И кстати, про саму идею разрешить биндиться на привилегированные порты. Ну положим, разрешили. Запустили 5 пользователей. А дальше что? Первый биндится, а остальные получают отлуп, что не удаётся забиндить сервис и создать сокет?
Или биндиться на свободные сокеты а сверху этого ещё делать некий пограничный сервис (хотя бы тот же балансировщик нагрузки, типа haproxy)? А смысл? На, например, 22 порт всё равно свой сервис вешать не станешь, да и вообще тогда такая ситуация не будет отличаться от биндинга на непривилегированный порт, т.к. и сейчас ничто не мешает развёртыванию балансировщиков для ферм с сайтами + этот балансировщик тоже должен кто-то конфигурировать, не раздавать же права на него всем пользователя, в конце концов.
Да и вообще. После прочтения у меня сложилась мысль, что автор несколько ограниченно знаком с тем, как устроены сети и ОС.
То, что он хочет, как по мне, не реализуемо в рамках той экосистемы, что сложилась сейчас. Надо менять принципы работы ОС с ресурсами, протоколы, стандарты. В общем-то, по сути, заново построить операционки, сети, софт. Сделать свой интернет с блэкджеком и шлюхами.
Так что написанное у меня вызывает очень много вопросом вкупе с отсутствием даже примерного понимания, как всё существующее можно трансформировать по направлению к означенным идеям. Да и надо ли? Вот, пожалуй, немаловажный вопрос, т.к. автор изначально гонится за соотношением количество сервисов/Ватт.
Что немного странно.
Сервисы ныне не те, что 20 лет назад. И даже не те, что 7 лет назад. К ним предъявляют совсем иные требования. По скорости разработки, функционалу и т.д. Да, я тоже противник монструозных сайтов, но рисовать сервис на чём-то, что вернёт развитие вебя лет на дцать назад — занятие так себе. Для вещей «попроще» же уже существует решение в виде shared-хостингов.
Да и эффективность энергопотребления железа возросла на порядки. Впору задумываться, а корректно ли сравнивать? Один какой-нибудь пролиант 380 может воплне затянуть сотню простых виртуалок (те самые) при потреблении в 500 Вт. Но это будут полноценные системы со всем функционалом и вспомогательным инструментарием + необязательно только http/https ресурсы. В отличие от. На этом и остановлюсь, пожалуй.
Проблему с 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.
В общем все это впринципе решаемые задачи, насчет секьюрности получилось бы явно не хуже чем сейчас с виртуализацией. Все это жрало бы меньше места на винтах и кушало бы заметно меньше ресурсов но при этом вероятно требовало более сложных реализаций в ОС.
По поводу ОЗУ и ЦП вопрос бы решили, виртуализация тоже не сразу пришла и была достигнута совместно железом и софтом.
По безопасности тоже вопрос очень сильно натянут т.к. не каждому серверу и софту она необходима. Вот скажем если у меня в организации уже стоит сервер который выступает шлюзом\фаирволом\прокси с антивирем\антиддос то заморачиваться с дополнительным оверхэдом на других внутренних серверах нет никакого смысла. Тоже самое и к хостингам относится, подавляющей части веб сайтов в инете не нужно чего то сверхъестественного, грубо говоря можно глянуть и увидеть что львиной доли пользователей до лампочки что они ходят на сервак по 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.
В общем все это впринципе решаемые задачи, насчет секьюрности получилось бы явно не хуже чем сейчас с виртуализацией. Все это жрало бы меньше места на винтах и кушало бы заметно меньше ресурсов но при этом вероятно требовало более сложных реализаций в ОС.
Да. Решаемые. Но мой посыл слегка в другом. Автор видит современные системы через призму своих узкоспециализированные задач и понимания мира ИТ (так-то линукса, но, по факту, там тянется всё подряд). А из того, что я описал не сказать, что оно нерешаемо (решаемо, как я упомянул, но требует изменений в стандартах, на оконечных системах (у клиентов и серверов) в протоколах и обслуживающем оборудовании), или будет более удобным. Просто всё будет работать по-другому. Не удобнее, а по-другому. По сути, работа ради работы. Это глупое занятие.
Что касательно безопасности. В периметре сети мало угроз (или скомпрометированная машина, являющаяся источником бед в сети — уже миф?)? А как же виндовый путь самурая (1 сервер — 1 роль), который, по сути, перекликается с unix-way? Автор изначально поднял вопросы, которые энтерпрайза и касаются слабо, скорее именно провайдеров хостинга, серверов и прочих подобных услуг.
А про подобное безобразное отношение к безопасности уже красиво написал grieverrr — «вьетнамское общежитие и лотерея».
Если хочется сыграть в такую лотерею, то и сейчас нет препятствий.
Что касательно безопасности. В периметре сети мало угроз (или скомпрометированная машина, являющаяся источником бед в сети — уже миф?)? А как же виндовый путь самурая (1 сервер — 1 роль), который, по сути, перекликается с unix-way? Автор изначально поднял вопросы, которые энтерпрайза и касаются слабо, скорее именно провайдеров хостинга, серверов и прочих подобных услуг.
А про подобное безобразное отношение к безопасности уже красиво написал grieverrr — «вьетнамское общежитие и лотерея».
Если хочется сыграть в такую лотерею, то и сейчас нет препятствий.
С посылом согласен полностью, но и автор пишет что к чему мы пришли и как бы могло бы быть. Сильно вероятно что если бы изначально пошли по пути о котором пишет автор не было бы сейчас статьи с пунктом "'Вьетнамское общежитие и лотерея обходятся дорого и сложно'" и т.д… И никто не отменял правило что любое решение имеет свои плюсы и минусы.
Ну если тачку скомпрометировали то это врядли спасет другие тачки, чем бы они обвешаны небыли. Живой пример недавняя история с «фейковым иваном» который положил кучу всего в том числе пару хостингов со всеми их виртуалками и контейнерами(не могу дать ссылку но инфа была в потоке тех дней).
В периметре сети мало угроз (или скомпрометированная машина, являющаяся источником бед в сети — уже миф?)?
Ну если тачку скомпрометировали то это врядли спасет другие тачки, чем бы они обвешаны небыли. Живой пример недавняя история с «фейковым иваном» который положил кучу всего в том числе пару хостингов со всеми их виртуалками и контейнерами(не могу дать ссылку но инфа была в потоке тех дней).
Ну это из разряда вот если бы дедушка был бы бабушкой…
Далеко ходить не надо подобных если бы очень много встречается в отношении ipv4 в темах обсуждения/статьях по ipv6.
Но по факту имеем, что имеем. И это работает по всем параметрам не так уж и плохо, тем более обкатанное практикой и ставшее стандартами де-факто.
По компрометации. Вы берёте идеальные условия, типа однородной среды и т.п. Часто это не так и эшелоны защиты едят свои мегагерцы не зря.
Далеко ходить не надо подобных если бы очень много встречается в отношении ipv4 в темах обсуждения/статьях по ipv6.
Но по факту имеем, что имеем. И это работает по всем параметрам не так уж и плохо, тем более обкатанное практикой и ставшее стандартами де-факто.
По компрометации. Вы берёте идеальные условия, типа однородной среды и т.п. Часто это не так и эшелоны защиты едят свои мегагерцы не зря.
А вот с ОЗУ и ЦП всё интереснее. Да, у виртуалок есть оверхэд. Но в идее автора тоже есть изъяны. А если по его схеме вдруг не хватает ресурсов? Вот просто у кого-то там нагрузка пиковая возникла. Пострадают все.
Приходим к идеи типа шейпинга процессорного времени и потребления ОЗУ. Опять же. Упирается в всё в то, как ОС работают в принципе. Там таких инструментов не предусмотрено. да. Можно выставлять ограничения в отдельном софте (типа БД). Но в большинстве случаев — нельзя. Получаем гигансткий несогласованный оркестр, которым надо попытаться управлять. Идеи ныне популярной контейнеризации тут ближе (хотя и ВМ, по сути, контейнер) к реальности. Возможно даже можно будет решать схожие задачи через некоторое время.
cgroups, anyone?
Хм, о cgroups я знаю только в контексте контейнеризации (которая тоже претит автору статьи).
В вопросе применения в работе для ограничения ресурсов пользователей/сервисов не разбирался.
Но даже так. Это всего лишь один из аспектов. Есть множество других, более сложных для решения вопросов.
В вопросе применения в работе для ограничения ресурсов пользователей/сервисов не разбирался.
Но даже так. Это всего лишь один из аспектов. Есть множество других, более сложных для решения вопросов.
Так в том и прикол что современная контейнеризация это, по-сути, солянка из namespaces, cgroups и aufs/overlay/btrfs.
Первые два — ядерные механизмы, уже присутствующие в ядре (как минимум с Ubuntu 12.04). Если к этому добавить SELinux или AppArmor — получаем достаточный уровень изоляции.
Всё это уже можно задействовать на полную катушку в современных дистрах, где есть SystemD (там поддержка пока что наиболее полная — изоляция вплоть до сервиса).
Менять, конечно, пришлось бы уйму всего, но масса механизмов для изоляции и контроля уже существует и даже работает.
Если уж на то пошло — изначально docker создавали для простоты разработки и доставки приложений, а не для того чтобы на нем в продакшене крутится
RPi стоит $30 и потребляет менее 15 Вт. Нужно ли говорить, сколько стоит одна монструозная VM и сколько она потребляет?Нужно конечно. 3-4 доллара в месяц для конечного потребителя она стоит вместе с электричеством, инфраструктурой, оркестрацией, маршрутизацией и прочим.
Автор хочет поставить Web сервер на RPi? Мне как-то было нужно собрать для неё QT5, а заморачиваться с кросс-компиляцией было лень. После полутора суток компиляции я таки разобрался, думаю, что даже довольно дохлая виртуалка тут посильнее будет.
Raspberry Pi — на компьютере, который примерно в 100 раз превосходит старый сервер по мощности CPU
Ага, крайне спорное утверждение. Откуда он это взял?
Кстати за те же 3-4 доллара в месяц можно получить и выделенный сервер на базе ARM. И не на RPi, прости господи, а на чём-то более серверном, с SSD. Я правда не слышал, что кто-то на подобном пытался
хостить по крайней мере 50 сайтов маленького или среднего размера, но автор может попробовать.
Ага, крайне спорное утверждение. Откуда он это взял?С потолка. На самом деле всякие разные бенчмарки показывают разница скорее раз в 20-30… чего для целей статьи как достаточно: RPi многократно мощнее компьютеров, на которых сидели и работали одновременно десятки, а иногда и сотни, пользователей.
Как показывает практика: если вопрос можно решить купив новый сервер — проще купить новый сервер.
Программисты дорого стоят, а на доведение системы до продакшина может уйти просто неимоверное количество времени, поэтому у нас и дальше будет виртуализация и контейнеры. Пока эта вся конструкция не перестанет работать — никто не пошевелится
Мне тоже 37, но я не считаю себя динозавром и не скучаю по своему 286-му с 40 мегабайтным диском.
Контейнирезация достойное решение всех проблем описаных тут и логичная эволюция, а вот мультиаренда имеет несколько принципиальных проблем — бэкап довольно сложен и уязвим (и я сейчас говорю про бэкап и восстановление вместе как процедуру). Не уверен что можно сделать снапшот директории и так же выкатить ее обратно, особенно это коснется бинарных хранилищ типа файлов mysql.
Ну и конечно это плохо вертикально масштабируемая система — слабо себе представляю процесс при котором пользовательские директории и запущенные процессы можно будет бесшовно передавать между серверами для распределения нагрузки в кластере.
Контейнирезация достойное решение всех проблем описаных тут и логичная эволюция, а вот мультиаренда имеет несколько принципиальных проблем — бэкап довольно сложен и уязвим (и я сейчас говорю про бэкап и восстановление вместе как процедуру). Не уверен что можно сделать снапшот директории и так же выкатить ее обратно, особенно это коснется бинарных хранилищ типа файлов mysql.
Ну и конечно это плохо вертикально масштабируемая система — слабо себе представляю процесс при котором пользовательские директории и запущенные процессы можно будет бесшовно передавать между серверами для распределения нагрузки в кластере.
Мой 286-й(на самом деле 486-й) давно уже распилен на кристаллик и его 40-мегабайтный диск служит зеркальцем-талисманом.
У вас был жесткий диск… Зависть.
У Вас был гибкий диск… Зависть. (НГМД)
У Вас были касеты… Зависть.
У Вас были перфокарты… Зависть.
У Вас были касеты… Зависть.
У Вас были перфокарты… Зависть.
286е далеко не все оснащались жёсткими дисками, нищеброды вроде меня ходили с пачками дискет и жутко завидовали тем, у кого были харды. Сорокет — это вообще дикая роскошь.
А у меня только 5 дюймовые дискеты. И на две-три дискеты вмещалось все. Но хранилось в пяти копиях, которые нужно было время от времени проверять и перезаписывать битые данные. Basic, системный монитор и рапира — все «ОС» (Бейсик и рапира совсем не ОС, но как-то неразрывно были связаны с неким подобием ОС хранившимся на загрузчике дискеты).
Очень много слов на тему «удобство против быстродействия»
Какие то странные расчеты… Если брать предложенный 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 еще на два года купить), а сколько малинок передохнет за этот период? и сколько потратится ресурсов на их замену и убытки по простою?
Прочие детали типа портов опустим за скобки (в конце концов предложенная модель не подразумевает навешивать оборудование на несетевые порты)
Так что в общем итоге видна только зеленая истерика, ошибочные расчеты и крик "раньше было лучше".
Не нашёл сколько энергии жрёт SPARC 10, но 20-й потребляет 125 Вт (http://docs.oracle.com/cd/E19127-01/sparc20.ws/801-6189-12/801-6189-12.pdf). 125 ватт, Карл! На современном железе на 125-ти ваттах можно запустить сервисы для всего интернета того времени.
Ну и за экономику плюс. Прогресс не в сторону эфемерной "простоты" движется, а в сторону экономической эффективности. Жизнь слишком коротка, чтобы писать на ассемблере.
1) Rpi — взяли, как пример. Теперь пофантазируйте, что можно было бы реализовать на описанном Вами «Зеоне»!
2) Автор в конце статьи уточнил, что речь идёт о фундаментальном эволюционном сдвиге, который претерпела unix/linux — негативном по его мнению. Да, автор сентимальным образом заглядывается в прошлое, что бы выразить свою позицию.
3) Конечно автор немного раздул и приукрасил, как это делают в Голливуде или современная журналистика. Однако лично я, поддерживаю такой подход, Здесь Вы прочитали не скучный, обоснованный с точки зрения автора рассказ.
2) Автор в конце статьи уточнил, что речь идёт о фундаментальном эволюционном сдвиге, который претерпела unix/linux — негативном по его мнению. Да, автор сентимальным образом заглядывается в прошлое, что бы выразить свою позицию.
3) Конечно автор немного раздул и приукрасил, как это делают в Голливуде или современная журналистика. Однако лично я, поддерживаю такой подход, Здесь Вы прочитали не скучный, обоснованный с точки зрения автора рассказ.
Не все так просто, и для подобного перехода понадобится куда больше изменений.
Во-первых, часто на VDS-ке крутится не один сервис, а несколько. Хорошей практикой в таком случае является создание отдельных пользователей для каждого сервиса.
Если вместо VDS-ки выдавать пользователей на общем сервере — то пользователям понадобится механизм для создания суб-пользователей. Я еще не читал про системы, где такой механизм бы существовал.
А что тогда такое обыкновенный shared hosting, где и крутятся сотни-тысячи вордпрессов на сервер?
Собственно проблема в том, что вместо того, чтобы «довести до ума» shared hosting и сделать так, чтобы там можно было не только форум на PHP разместить мы перешли к системам лишь чуть более гибким, но жрущих ресурсы на два порядка больше.
Видел shared'ы с пёрлом, с питоном.
Тут, например, инструкция установки ноды без спроса хостеров (не знаю, везде ли это получится).
Такое ощущение, что мода на VPS для сайтов-визиток — обычный маркетинг.
Меня смущает другое: на протяжении всей статьи автор упорно делает вид, что кроме VM ничего не используется, причём конкретно для php.
Тут, например, инструкция установки ноды без спроса хостеров (не знаю, везде ли это получится).
Такое ощущение, что мода на VPS для сайтов-визиток — обычный маркетинг.
Меня смущает другое: на протяжении всей статьи автор упорно делает вид, что кроме VM ничего не используется, причём конкретно для php.
В России это еще и гарантия, что РКН не убьет доступ одним ударом 1000 сайтов, если у вас кто-то из соседей варит галлюциногены из грибов в Eve Online.
Выделенный IP
… вместе с которым стоимость шареда может начать превышать стоимость минимальной VPS. Упс.
Бывает и так. И вот тут проходит водораздел: если есть айтишник — лучше VPS, т. к. и поиграться, и ресурсов побольше.
А большинство предпочитают shared, т. к. в их случае сравнивать нужно с обслуживаемым VPS.
Да и вообще, выделенный IP зачастую можно включить и выключить одной галкой, в зависимости от важности/уровня паранойи на сегодня/на месяц:
А большинство предпочитают shared, т. к. в их случае сравнивать нужно с обслуживаемым VPS.
Да и вообще, выделенный IP зачастую можно включить и выключить одной галкой, в зависимости от важности/уровня паранойи на сегодня/на месяц:
Вы вложили денег в контекстную рекламу под НГ, ожидаете наплыва покупателей и тут банят кого-то из соседей
шаред-хостинг в текущем его состоянии — вьетнамское общежитие и лотерея. размещать там что-то в продакшен ни один вменяемый человек не станет.
inb4 перепись экстрималов
inb4 перепись экстрималов
>вьетнамское общежитие и лотерея
Ну некоторым повезло с комендантом общежития и там царит полный порядок.
Очень много сайтов — визитки небольших фирм, причём не про ИТ. Если что случится — ну пару дней не придут через контекстную рекламу новые клиенты, но старые по телефону свяжутся. Далеко не у всех есть возможность поддерживать VPS, а так комендант накатывает обновления. Я уже молчу про бложики.
Статья же про сайты на вордпрессе, а не убийц фэйсбуков.
Ну некоторым повезло с комендантом общежития и там царит полный порядок.
Очень много сайтов — визитки небольших фирм, причём не про ИТ. Если что случится — ну пару дней не придут через контекстную рекламу новые клиенты, но старые по телефону свяжутся. Далеко не у всех есть возможность поддерживать VPS, а так комендант накатывает обновления. Я уже молчу про бложики.
Статья же про сайты на вордпрессе, а не убийц фэйсбуков.
На длинном промежутке времени полного порядка нет и быть не может, хотя бы из-за 0day уязвимостей типа dirty cow.
Сами же пишете про везение.
Сами же пишете про везение.
Представьте себе ситуацию. Вы вложили денег в контекстную рекламу под НГ, ожидаете наплыва покупателей и тут банят кого-то из соседей. Деньги, вбуханные на рекламу, сразу идут побоку. Поисковый трафик идет побоку. Короче, праздники успешно сфейлены.
Что касается VPS и обслуживания, уже сейчас есть немало хостингов, предлагающих обслуживание типовых VPS за скромные 400-500 рублей в месяц (комендант по расписанию, и вне расписания со срочными апдейтами безопасности). Этот вариант даже лучше своего админа, потому что свой админ может и не сильно разбираться в LAMP инфраструктуре.
Итого 1000 рублей в месяц, чтобы не беспокоиться ни за что — я считаю адекватным предложением.
Что касается VPS и обслуживания, уже сейчас есть немало хостингов, предлагающих обслуживание типовых VPS за скромные 400-500 рублей в месяц (комендант по расписанию, и вне расписания со срочными апдейтами безопасности). Этот вариант даже лучше своего админа, потому что свой админ может и не сильно разбираться в LAMP инфраструктуре.
Итого 1000 рублей в месяц, чтобы не беспокоиться ни за что — я считаю адекватным предложением.
>банят кого-то из соседей
Выделенный IP
>Итого 1000 рублей в месяц, чтобы не беспокоиться ни за что
Я не говорю, что шаред нужен абсолютно всем. Но большинство людей не имеет гиковского интереса к «своему», хоть и виртуальному серверу. И для них это просто лишние расходы, как в развёртывании, так и поддержании. А на выходе — всё та же визитка. Так зачем это всё?
Выделенный IP
>Итого 1000 рублей в месяц, чтобы не беспокоиться ни за что
Я не говорю, что шаред нужен абсолютно всем. Но большинство людей не имеет гиковского интереса к «своему», хоть и виртуальному серверу. И для них это просто лишние расходы, как в развёртывании, так и поддержании. А на выходе — всё та же визитка. Так зачем это всё?
Я 1970, первая программа 1984 — первый интернет 1990. Смешно было читать про «архей». А в целом да
Разделение сети как раз не проблема, 99% софта под линукс позволяет настраивать используемые порты. Проблема — это инсталляционные пакеты, которые крайне сложно установить без прав рута. Все норовят писать в /etc, прописывать себя в сервисы и разваливаться при попытке установить как-то иначе.
Лично я всегда деплою контейнеры с --net=host и никогда об этом не жалел.
Лично я всегда деплою контейнеры с --net=host и никогда об этом не жалел.
Нет, разделение сети — это как раз проблема. На сервере-то можно порт любой прописать, тут вы правы. Но клиент будет ожидать увидеть стандартный порт для протокола, а не какой-то там еще.
Так это не проблема Unix, и привелегированные порты — не причина этого. Вполне можно обойти и это, внедря поддержку DNS SRV для _http/_https в популярные браузеры, предварительно внеся соответствующие изменения в RFC на HTTP/HTTPS. Но это маловероятно из-за описанного в статье эффекта path dependence (т.к. внести изменения нужно одновременно на всех клиентах, включая устаревшие).
Автор статьи упрощает проблему, которую решает виртуализация. Проблема не только в том, что бы запустить несколько серверов на хосте, а ещё и в том, что бы можно было этот хост ремонтировать/апгрейдить и что бы у пользователей ничего не менялось. Для этого нужен «продвинутый chroot», который сейчас практически сделали под вывеской контейнеров.
Автор статьи упрощает проблему, которую решает виртуализация. Проблема не только в том, что бы запустить несколько серверов на хосте, а ещё и в том, что бы можно было этот хост ремонтировать/апгрейдить и что бы у пользователей ничего не менялось. Для этого нужен «продвинутый chroot», который сейчас практически сделали под вывеской контейнеров.
Для собственных приложений в приватных сетях это решается через service discovery. Для публичных сетей ставится прокси, который слушает публичный порт и перенаправляет запрос на нужный экземпляр, слушающий на произвольном порту.
автор фантазирует в области, в которой он разбирается как свинья в апельсинах
начнем с того, что все 3 из моих RPi 3 в режиме самого жесткого оверклокинга и под хорошей нагрузкой по амперметру потребляют не более 0,5А
напряжение питания, кто не знает — 5 вольт. закон ома знают все?
ну остальное высосано из того же пальца.
кстати — давно есть хостинги для апликейшенов. в облаках. сейчас народ пилит хостинги контейнеров.
но скажите, кому и нахрена в 2017 году нужен бложек на вордпрессе?
а то, что нужно бизнесу — и на тысяче армов не взлетит.
и да, 14 ядер xeon — это не монстр, а самый дешевый начальный вариант из последней линейки.
начнем с того, что все 3 из моих RPi 3 в режиме самого жесткого оверклокинга и под хорошей нагрузкой по амперметру потребляют не более 0,5А
напряжение питания, кто не знает — 5 вольт. закон ома знают все?
ну остальное высосано из того же пальца.
кстати — давно есть хостинги для апликейшенов. в облаках. сейчас народ пилит хостинги контейнеров.
но скажите, кому и нахрена в 2017 году нужен бложек на вордпрессе?
а то, что нужно бизнесу — и на тысяче армов не взлетит.
и да, 14 ядер xeon — это не монстр, а самый дешевый начальный вариант из последней линейки.
Но согласитесь, что и не каждому бизнесу нужен свой сайт уровня Фейсбук и гмейл.
но скажите, кому и нахрена в 2017 году нужен бложек на вордпрессе?
В 2017 году почти 30% сайтов работают на вордпрессе, почти 60% рынка (по баблу) заказной разработки сайтов — это вордпресс. Но да, можно продолжать мерить людей по себе и думать, что вордпресс не нужен.
Бизнес он ведь разный бывает.
Если это магазин, у которого в онлайне лишь «витрина», то ему важно а) доступность б) актуальность наличия и цен. И владельцу магазина будет абсолютно ровно на все наши гиковские технологии, до тех пор пока его удовлетворяет цена и его две основных хотелки.
Если это магазин, у которого в онлайне лишь «витрина», то ему важно а) доступность б) актуальность наличия и цен. И владельцу магазина будет абсолютно ровно на все наши гиковские технологии, до тех пор пока его удовлетворяет цена и его две основных хотелки.
отвечу всем одно и то же
бизнесу — даже самому вонючему магазину — нужна SQL база с как минимум одной репликацией, плюс NOSQL для кеша и временных данных, апликейшен сервер (все чаще идет отказ от пхп в торговых решениях, но pxp-fpm тоже можно считать как таковой), веб фронтэнд, бекенд REST API, мобильная аппка, система бекапов, мониторинг инфраструктуры.
даже при минимальном к-ве покупателей онлайн — это невозможно сделать не то что на одной пи-шке, а в пределах одного физического хоста, ибо в случае падения оного — магазин превращается в тыкву.
что до 30 или 60 процентов сайтов на вордпрессе — да не вопрос, такое имеет место. но если считать по количеству посетителей — на все эти хомяки и сайты визитки ходит доли процента юзеров.
бизнесу — даже самому вонючему магазину — нужна SQL база с как минимум одной репликацией, плюс NOSQL для кеша и временных данных, апликейшен сервер (все чаще идет отказ от пхп в торговых решениях, но pxp-fpm тоже можно считать как таковой), веб фронтэнд, бекенд REST API, мобильная аппка, система бекапов, мониторинг инфраструктуры.
даже при минимальном к-ве покупателей онлайн — это невозможно сделать не то что на одной пи-шке, а в пределах одного физического хоста, ибо в случае падения оного — магазин превращается в тыкву.
что до 30 или 60 процентов сайтов на вордпрессе — да не вопрос, такое имеет место. но если считать по количеству посетителей — на все эти хомяки и сайты визитки ходит доли процента юзеров.
Вы потратили гораздо больше ампер*часов нашей планеты, тех пользователей который прочитали эту муру.
Кстати почему не начали с Адама и Евы?
Кстати почему не начали с Адама и Евы?
Ха. А ведь это и есть эволюция. Здесь и сейчас — математика и бизнес, я и Вы вершим судьбу.
Всё верно, но
Так что не нужны ему рутовые права, пускай гайд дочитает.
Мне по-прежнему нужны рутовые права, чтобы запустить контейнер.Ну вот почему, почему, скажите мне, никто не дочитывает гайд «Install Docker» до конца? Там же написано
sudo usermod -aG docker $USERТак что не нужны ему рутовые права, пускай гайд дочитает.
Контейнер для запуска 10-мегабайтной программки может весить несколько гигабайт.
Автор наверно имел ввиду образ (image).
Не знаю, не знаю, мой образ с "тяжёлой" Java+Kotlin и всякими свистелками типа Jersey REST-сервлетов весит 102.2МБ (все слои). FROM openjdk:8-jre-alpine.
Если он всё же имел ввиду потребление памяти контейнером, то и тут тоже не сходится — проверил, мой потребляет 236 МБ из docker stats, из которых 150МБ — мой жава-сервер внутри, значит сам контейнер всего 86МБ.
Автор, похоже, что-то делает не так.
Автор вообще дико ошибается в оценке стоимости оверхеда контейнеризации во-первых, во-вторых сильно ошибается в важности расхода машинных ресурсов (в той области, про которую он говорит). В итоге предлагает решать проблему, которой на самом деле нет.
Все зависит от цены и доступности ресурсов. К примеру, если самая дешевая VPS OpenVZ в вашей стране стоит $10 c нулевым уровнем сервиса (потому что запрещено регистрировать хостить сайты с доменном страны за рубежом, оттого конкуренции тупо нет — выбирать можно между дорогими и плохими или дорогими и очень плохими хостингами).
Конфиг nginx в папке пользователя — это попросту опасно. В конфигах-то можно разное по-написать...
Про интерфейсы вы не поняли. Автор писал про создание tun или tap-интерфейсов, на такой адрес вешать 100500 адресов алиасами нет смысла.
Позволю себе не согласиться: контейнеризация — отличная вещь, позволяющая добиться повторяемости результата и упрощающая горизонтальное масштабирование.
А дальше реалоад в крон на каждый 5 минут и вот 80 порт шарится на кучу виртуал хостов.
А что если кто-то намеренно сломает свой конфиг?
Правда я не задумывался насколько это всё вандалоустойчиво относительно виртуализации.
В том-то и дело что оно неустойчиво :)
Гораздо лучше контейнеризовать приложение и дать доступ к БД (если речь о Postrges или MySQL).
Рассмотрим оверхед на примере LXC:
- виртуальный сетевой интерфейс (можно отдать и железный, если есть желание)
- init
- sshd
- легковесное окружение
Это всё в совокупности занимает меньше 1ГБ места и жрет меньше 200М ОЗУ при длительной работе. Оверхед по CPU минимален.
Что мы получаем взамен?
- изоляция сети и процессов на уровне namespaces
- контроль ресурсов на уровне cgroups
- эквивалент chroot
- переносимость (можно один и тот же контейнер запустить на любом сервере, поддерживающем LXC)
Это всё реализуется и без контейнеров, но заворачивание этого всего в контейнер дает пользователю свою песочницу, почти эквивалентную VPS (нельзя грузить модули ядра и крутить sysctl, плюс ломается софт типа NFSd ввиду специфики работы с ядром).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Привилегированные порты — причина глобального потепления