Представлен выпуск проекта SKUDONET 7.1, развивающего специализированный дистрибутив на базе Debian GNU/Linux, оптимизированный для развёртывания балансировщиков трафика и обратных прокси, а также для создания инфраструктуры для организации доставки приложений. Поддерживается как создание балансировщиков для HTTP/HTTPS, так и реализация сервисов для распределения по узлам произвольного TCP и UDP трафика. Управление и мониторинг за системой осуществляется через web-интерфейс. Размер загрузочного iso-образа 844 МБ. Помимо готовой сборки предоставляется репозиторий пакетов, который можно использовать для формирования окружения SKUDONET на базе уже установленных систем с Debian...Подробнее: https://www.opennet.me/opennews/art.shtml?num=61431
Опять эти дистры. В нормальном мире для того чтобы повторить сабж должно хватить одного контейнера.
видимо кому то нужна вебморда
и кто будет обновлять ваш контейнер?
Тот же, кто будет дистриб обновлять. Не, реально ради вебморды городить дистриб это куку досвидос.
Кстати откуда вообще такая искажённая логика типа если дистр то всё обновляю всеми силами, а типа контейнер то не буду обновлять. Это ведь какая то радикальная ошибка у многих в головах. Откуда она взялась? Это надо искоренять.
Обыкновенный опыт работы с контейнерами. Хрен их кто обновляет.
Зависит от разработчика. Что ему мешает не обновлять дистрибутив? Или наличие iso магическим образом заставляет разраба его поддерживать? Три раза лол, о сотнях заброшенных дистрибов ты надо понимать не в курсе?
Так это ставится на дебиан
Контейнеры тоже не с чистого листа собирают.
В смысле? Я, к примеру...
Как новая минорная версия выходит - затаскиваю на тест, потом в прод. С мажорной так же, но попароноидальнее.
"Свои" контейнеры не то, чтобы часто, но собираю заново как новая версия ОС выходит, поверх которой ПО в контейнере запускается или самого ПО.
контейнер? для высоконагруженного сервера? а весь траффик через докер? )))дистрибутив можети и перебор, а вот контейнеры точно на помойку, это все облачная мишура
Ещё один не может понять что контейнер это не виртуалка. Контейнер не тяжелее чрута.
Да-да, и костыли вроде --network host им тоже, конечно, не нужны.
С чего бы это костыли? Валидный способ настройки сети, иногда необходимый.
Да, и io на диск в контейнере - это тоже не проблема.
Перестань городит бред ну прошу тебя. Просто пиши на хост, а не оверлейфс или аналог. Если ты такой реактивный пиши на рамдиск. Ты какой то кладезь шаблонов.
если ты пишешь на хост а не на контейнер, то накой тебе контейнер?без облачного хранилища и облачных ресурсов - эти контейнеры полный бред, в принципе они и так бред, но это другая история
а еще в контейнере недоступно много физических ресурсов, например real clock,
а еще ты не работаешь с сетевым стеком напрямую, а через демон докера весь траффик,
а еще ты не можешь оценить степень загрузки системы (потому что получишь данные хоста) не обращаясь к специализированному API и т.д.я уже выше написал, что это все облачная мишура, докер это ваша дополнительная (к и так не дешевым облакам) плата за то, чтобы облачному провайдеру было удобно вам втюхивать multi-tenant попутно рассказывая сказки про масштабируемость и производительнось
ты можешь сказать, ну ОК изолируем на одном сервере разные приложения с целью безопасности, ну тогда в каком месте я был не прав, когда сказал, что это улучшенная замена shared хостингу? ну и зачем мне изоляция, которая в отличии от гипервизора не имеет аппаратной поддержки (которая тоже дырявая, но сильно меньше и в целом лучше)?
ну и опять таки это все опять не про масштабируемость и производительность
Полная чушь.В контейнер никто не пишет, - все эти данные рано или поздно потеряются. Пишут либо в его volume, либо в mount.
Демон докера не занимается сетевым стеком. Возьми podman, там и демона то нет. При запуске от root там идет сетевой ns, с обычном forward.
И никто не запрещает использовать --net host, используя сетевые возможности хоста.
Степень загрузки ты можешь оценить через htop.
У виртуальных машин аппаратная виртуализация, а не изоляция. Аппаратная изоляция - это жве физические машины.
Безопасность это не основная задача. Основная - упаковка зависимостей приложения, чтобы, особенно при большом количестве последних, не приходилось ювелирно настраивать какой-то python (и да, тебе тут тоже посоветуют venv). А также корректно запускать старье по типу python 2. Если у тебя дырявая бд с открытым доступом наружу, то данные можно будет украсть и с контейнера. Тут доступ в систему вообще не нужен. А вот какой-то майнер или руткит вогнать будет накладно. Резюмируя, это не значит, что у тебя карт-бланш на дырявый софт. Это значит, что в этом случае у тебя будет хоть какая-то защита.
Дырявая защита настолько дырявая, насколько дырявое само ядро и реализации инструментов типа runc. И, к слову, как находят - патчат, ни чем не отличаясь от другого софта. И да, вот, на последнем ядре я написал: podman run -it debian: stable /bin/bash
Напиши мне шаги побега из него. Тогда продолжим обсуждать, где там дырки.
> Полная чушь.это в твоей нестройной теории
> В контейнер никто не пишет, - все эти данные рано или поздно
> потеряются. Пишут либо в его volume, либо в mount.это не значит что тебе не надо что-то хранить на момент исполнения, ну например временные файлы или еще что-то, ты читай внимательнее, - ты вынужден будешь для таких сценариев прикручивать внешнее хранилище, либо хост либо сетевое - неважно
> Демон докера не занимается сетевым стеком. Возьми podman, там и демона то
> нет. При запуске от root там идет сетевой ns, с обычном
> forward.Docker provides different network modes (bridge, host, overlay, etc.) which determine how containers communicate with each other and the external network. The default bridge network (bridge mode) is commonly used where Docker acts as a router and traffic passes through dockerd.
> И никто не запрещает использовать --net host, используя сетевые возможности хоста.
да но это даже не дефолтовый мод
> Степень загрузки ты можешь оценить через htop.
не сможешь из контейнера, ты читаешь по диагонали, запусти htop внутри докера и посмотри
> У виртуальных машин аппаратная виртуализация, а не изоляция. Аппаратная изоляция - это
> жве физические машины.если что-то в какой-то степени от чего отделяется это называется изоляция, если изоляция физических машин предполагает сетевое взаимодействие, то изоляция тоже не является полной
и чтобы не нести пургу, лучше заглядывать в доки, чтобы определяться с терминологией и маркетинговым булшитом
File system isolation: each process container runs in a completely separate root file system.
Resource isolation: system resources like CPU and memory can be allocated differently to each process container, using cgroups.
Network isolation: each process container runs in its own network namespace, with a virtual interface and IP address of its own.
> Безопасность это не основная задача. Основная - упаковка зависимостей приложения, чтобы,
> особенно при большом количестве последних, не приходилось ювелирно настраивать какой-то
> python (и да, тебе тут тоже посоветуют venv). А также корректно
> запускать старье по типу python 2. Если у тебя дырявая бд
> с открытым доступом наружу, то данные можно будет украсть и с
> контейнера. Тут доступ в систему вообще не нужен. А вот какой-то
> майнер или руткит вогнать будет накладно. Резюмируя, это не значит, что
> у тебя карт-бланш на дырявый софт. Это значит, что в этом
> случае у тебя будет хоть какая-то защита.а зачем тогда нам Docker вместо Flatpak? и накой черт эти горе фанатики Kubernetes придумали?
я не касался ошибок конфигурирования или логических ошибок приводящих к нарушением безопасности, я говорил, о более изолированных и безопасных средах исполнения
ну и т.е. тезис про размещение нескольких приложений на одном сервере ты получается поддерживаешь?
я не против докера для такого применения, на замену шареного хостинга, сотню мелких аппов с разнородным рантаймом на один инстанс задеплоили - ОКно слушать бред про "отказоустойчивые" кластеры, которые горизонтально масштабируются в виртуальных средах - нее спасибо, буратины ))))
> Дырявая защита настолько дырявая, насколько дырявое само ядро и реализации инструментов
> типа runc. И, к слову, как находят - патчат, ни чем
> не отличаясь от другого софта. И да, вот, на последнем ядре
> я написал: podman run -it debian: stable /bin/bash
> Напиши мне шаги побега из него. Тогда продолжим обсуждать, где там дырки.ты веруешь что конкретно твоя шляпа неуязвима? первая ссылка в браузере
https://github.com/containers/podman/security/advisories/GHS...найди "шаги" сам, если тебе надо... в мои задачи это не входит
Блин, нет, не проблема, а что? Ещё раз, всё упирается в проектирование. Если у тебя дичайшее io и ты пишешь его в рут контейнера, то кто ты после этого?
если у тебя дичайшее IO то ты не будешь использовать какую-нибудь виртуализированную шляпу с трехкратным оверсейлом и каким-нибудь тормознутым Amazon EBS или аналог
> если у тебя дичайшее IO то ты не будешь использовать какую-нибудь виртуализированную
> шляпу с трехкратным оверсейлом и каким-нибудь тормознутым Amazon EBS или аналогНо подкроватный сервер на три посетителя в месяц это не случай с дичайшим IO.
Тут же просто маняврирование в теоретических теорияхМoчepaпторы бесгуются внесли мой IP в блеклист, безуспешно, впрочем не суть. Репорты в РКН на опеннет отправляю каждый день.
Затраты на работу контейнера это переключение контекста.
С точки зрения вычислительной мощности - числорубилки - это очень незначительно.
А вот для сетевой структуры - перепахивания сетевых пакетов все очень плохо.
Собственно потому такие штуки как балансировщики сетевые и делают в специальных коробках, а не писюках.
Это я уже не говорю если у тебя такой большой трафик то тогда какой тебе Линукс? Тебе нужен аппаратный балансировщик на который ты никогда не заработаешь.
Это такой способ админчиков снять с себя ответственность, не занимаясь проектированием. Я его десятки лет назад выкусил. Чтобы потом сказать "а я же говорил, что надо было покупать железа и софта на миллиард, чтобы наш онлайн магазин не упал, я предупреждал". Решается наличием в команде грамотного архитектора, который таким вот кадрам раздает по куполу.
Вот такие раздаватели по куполу потом ноют про кадровый голод. Экономики на спичках.
Понятие аппаратный сейчас очень размыто, основная часть решений де-факто программно-аппаратные, по уму аппаратным может называться девайс где из софта вообще нет, все в железе, необходимость чисто аппаратной реализации для большинства кейсов сомнительно.
не надо нести бредаппаратный балансировщик это такой же балансировщик на линуксе у которого рассчитаны аппаратные возможности под задекларированную производительность, т.е. это решение изкаропки
а внутри торчат те же ксеоны
хочешь SLA и решение из коробки - один путь, хочешь сделать свое и все сам контролировать - другой путь
Вы прослушали новости из 2005 года, stay tuned.
т.е. аргументов у тебя нет? )))
Дистрибутив в контейнере можно запустить.
Если его окружение вокруг ядра способно работать с другим ядром произвольной версии, то почему бы нет?
> В нормальном миреЕсть статическая линковка без смyзиконтейнеров.
А контейнеры бывают и не смузи. LXC - суровые нативные контейнеры. Утилиты управления написаны на C.
с теми же проблемами что и у докера, концептуально это тоже самое, ну разве дебажиться там будет проще
Концептуально одно и то же с докером - чрут. Безграмотность потрясающая. 10 лет лень 5 минут потратить на ознакомление?
Вот так глянешь сходу на название и пока не сходишь на сайт дистра, не выяснишь, что разрабы не отечественные. Подумаешь, что дистр для сети учреждения со СКУД.
Какой смысл балансить трафик внутри одной железки? Как там с кластеризацией в SKUDONET?
Сейчас тут прочитают что он на perl написан )))А главный вопрос - кто работает балансировщиком?
И на C++.
Есть perlbal сто лет как. На нем крутился хайлойд задолго до появления nginx.
От хорошей жизни ага
>кто работает балансировщиком?ZEVENET Load Balancer написан на perl
СКУДНОВАТЫЙ какой-то дистр...
Читать умеешь?>развивающего специализированный дистрибутив