После двух лет разработки опубликован выпуск проекта Kata Containers 3.0, развивающего стек для организации выполнения контейнеров с использованием изоляции на базе полноценных механизмов виртуализации. Проект создан компаниями Intel и Hyper путём объединения технологий Clear Containers и runV. Код проекта написан на языках Go и Rust, и распространяется под лицензией Apache 2.0. Развитие проекта курирует рабочая группа, созданная под эгидой независимой организации OpenStack Foundation, в которой участвуют такие компании, как Canonical, China Mobile, Dell/EMC, EasyStack, Google, Huawei, NetApp, Red Hat, SUSE и ZTE...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=57904
Если ты ниначто не способен то иди пилить браузеры или очередные контейнеры.Но уже сейчас можно сказать что не взлетит и останется в вечной бете.
Если ты ни на что не способен, то иди писать комментарии на опеннет и хейтить все, что не осилил
Зачем осиливать то, что не взлетит?
Прямо в точку.
>Код проекта написан на языках Go и Rust, и распространяется под лицензией Apache 2.0.Почему гохеры и растовики не любят gpl? Видел кучу велосипедов на этих языках, почти все они под митом или другой разрешительной лицензией.
Потому что статическая линковка и особенности распространения библиотек в виде исходников.
Крупные корпорации в целом не любят gpl и его разновидности
Может, закрыть не получается? :)
Ну хотя бы, Apache 2.0 и то уже прогресс. Хоть от патентный претязаний защищает.
А зачем любить гпл, когда есть более свободные лицензии? Ну кроме фанатизма по бредням стол-мана, фонд которого предпочитает полные права на код, а не под лицензией, которую впаривает другим.
Раньше они говорили "А вот раньше запускали бы на виртуалках", хотя это было чистой ложью.Теперь они сами запускают на виртуалках.
Буквально 10 лет назад все пыхтели "фи эти виртуалки, тратят слишком много ресурсов, другое дело контейнеры, за ними будущее, а безопасность никому не нужна, а кому нужна - используйте виртуалки". Проходит 10 лет и делают виртуалки под инфраструктуру контейнеров. Во истину человечество ходит по кругу.
>Во истину человечество ходит по кругутоже мне открытие
вообще, на 90% bare metal до сих пор использую )
Дело в том, что в контейнеры "смогли" только некоторые операционные системы, в основном, это ядро Linux с прямой поддержкой cgroup и namespace ( LXC, Docker, podman ). Соответственно, это направление курируют Linux Foundation + IBM ( посредством владения Rad Hat).
Соответственно, в рамках корпоративной борьбы нужен набор технологий с похожими свойствами и API.Вот для этого и ушло где-то 10 лет.
Хотя я бы делал попроще: дробил бы приложения на эпохи потребления ( 8-бит, 16-бит, 32-бит, 64-бит ) согласно масштабу и требованиям к точности. Большинство приложений, особенно микросервисной архитектуры, не имеют явной потребности в 64-битах, а уж консольные утилиты - тем более. Это бы сильно экономило память и прочее ( интересно было бы посмотреть на 32-битные ядра на современных техпроцессах - тактовую частоту и производительность ).
https://ru.wikipedia.org/wiki/X32_ABI не взлетело
А чё не взлетело то? Вполне норм было, честные 3-5% экономии памяти.
щас бы в эпоху нодыжс, электронов, томкатов, java, npm и прочих шмяк-шмяк архитектур и подходов к разработке пытаться сэкономить на регистрах, изобретая очередной велосипед. Всю эту экономию сожрёт просто подключение очередной js обёртки вокруг "print hello word"
Всё что ты описал можно запускать только в контейнерах лишь бы это и их зависимости не распространялись по системе забиваясь в самые укромные места.
только теперь это виртуалки с кучей абстракций от контейнеров, еще больший оверхеад и усложненеи инфраструктуры
Т.е обмазываения баш скриптами и складирования всё с одну систему это капец как просто? 15 лет назад было не просто и сейчас не просто плавали знаем. А контейнеры и все остальное это упрощения. А то что у упрощений всегда есть оверхед так это всегда так.Больше железа, больше массового производства, дешевле железо. Запомни это.
с кем ты разговриваешь? он systemd до сих хейтит под каждой новостью
Это он сильно зря.
Контейнеры уже давно не средство экономии, а средство для выполнения приложений. В VM-ке получается смесь основной системы, настройки сетей, драйверов, мониторинга и прочего. Для получения VM-ки нужно или кому-то писать или самому создавать и потом поверх ставить всё. Часто эта VM-ка висит потом одна в одной копии и если она упадет, то несколько уровней начальства может быть задействовано чтобы восстановить. Апгрейд такого - еще такой квест, когда начинается конфликт библиотек и т.п. Вначале команда, занимающаяся инфраструктурой должна подготовить релиз новый со всеми делами, потом только уже приложения можно пробовать. В результате процесс на год или больше выходит и куча ручной работы. Все это знаю сам по опыту. А если нужно патчить всё каждый месяц?
Контейнер отделяет приложения от инфраструктуры. Можно использовать любую основу, не обязательно то, что стоит на хосте. Image приложения будет такой же, как у программиста, так и в production. не будет такого, что какой-то пакет новый вышел, обновился на prod и все сломалось, к примеру.
Но еще, что важно, сам контейнер можно положить уже в kubernetes, где программисту вообще ничего не нужно знать об инфраструктуре. Его приложение будет перемещаться само при сбоях. Он может использовать классные плюшки типа ingress или mesh или сквзного шифрования (важно для PCI). Патчить хосты вообще легкая задача, каждый месяц без проблем, можно автоматом просто даже. Горизонтальное масштабирование - одной командой.FYI работал как с 30 тыс физических серваков, так и 1000 приложений от разных команд.
Ну если ВМ-ка раскатывается врукопашную, то - примерно так и есть.А если ВМ-ка раскатывается из кода, то примерно одна головная боль - что в контейнеры, что в ВМ. Весомый такой кусок усложнения, который не все хостят в гитах, не рассказывают как достигли и прочие прелести волшбвы в ИТ.
Тот же Кубер - замонаешься ковырять различия в версиях АПИ и выковыривать какая ж там сейчас через месяц снова другая её туда версия...
И сколько стоит мэн, который легко этим жонглирует - косвенный показатель псевдо-простоты.
Простая вещь, устроенная из сложных. Ну - да. Это физика этого мира.
>Код проекта написан на языках Go и RustКод проекта написан на языках Go и RustНет, спасибо. Пока попользуюсь оригинальным QEMU.
> В QEMU для асинхронного ввода/вывода задействован API io_uring.Звучит интересно, сколько и чего прироста у них при этом
В далёком 1985 году я в институте работал на ЕС ЭВМ под управлением VM, у нас она называлась СВМ -- Система Виртуальных Машин. Причём сама VM существует с 1972 года.За эти 50 лет ничего не изменилось. В очередной раз переписали то же самое.
Зачем работать, если можно переписывать? Так-то прогресс в 60-х остановился.
Проблема ЕС что это не оказалось на самом деле не Единая Система. А одна из систем из зоопарка. Даже несмотря на то что это клон IBM. IBM PowerVM тоже где-то на задворках прогресса сейчас.
Я не про ЕС, а про то, что все эти виртуальные дела уже 50 лет как в продакшене. И с тех пор ничего не изменилось, ни-че-го. Никаких новых идей.И вот опять нате здрасьте, очередная перепись 50-летнего проекта с блекджеком и шлюхами. Ну ещё бы, ведь у предыдущих систем был фатальный недостаток...
Ну так все современные технологии родом из 20 века. 50-60 годы максимум. Ничего нового с тех пор прорывного не придумано. Обсасывают эволюционно старые идеи. И так везде. Те же электромобили чуть ли не с 19 века. Принципиально нового ничего нет.
> ... это клон IBMКлонирование и оказалось тупиком. Все инженера быстро превратились в продавцов IBM-комплектухи. "Запад нам поможет!" (с)
Это называется: наконец то студенты троечники открыли старый учебник.))) С какими фанфарами носились с той же Java, виртуальная машина, хотя P-код был еще в Паскале.)))
Грузины писали, судя по названию?)🇬🇪🐈
Тогда уж скорее японцы. Но, скорее, просто модное слово взяли.
Слово «kata» значит «форма», «внешность». Kata Containers — нечто, что имеет форму или внешность контейнеров. Какбыконтейнер.
Колесо Сансары дало оборот.
Память-процессор туда сюда обратно в хост систему и соседям легко отдаёт обратно?