|
|
3.40, Аноним (-), 11:54, 12/12/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
Зато можно встроить пару свежих, оптимизированных бэкдоров в неведому фигню от интела. Все-равно код этой лабуды никто кроме интеоловских вассалов не будет.
| |
|
|
1.2, Аноним (-), 14:23, 11/12/2017 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
> JD.com
Серьёзно? А почему других каких-нибудь мошенников не спросили?
| |
1.4, Аноним (-), 14:36, 11/12/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
> защищающего от совершения атак, вызванных эксплуатацией уязвимостей в ядре Linux
Ядро Linux можно легко аудитить, в отличие от процессоров Intel, и какие там "особенности реализации" внедрены в аппаратную виртуализацию - только узкому кругу интеловских инженеров ведомо.
| |
|
2.44, Аноним (-), 14:49, 12/12/2017 [^] [^^] [^^^] [ответить]
| +/– |
Ядро линукс можно аудитить 100 лет подряд, и все равно багов останется больше чем в микропрошивке интел.
| |
|
1.5, пох (?), 14:47, 11/12/2017 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
чорт, жалко сlear containers - идея была хорошая, и реализация понятная.
В этой модной меганавороченной хрени никто, наверное, не разберется, включая и ее авторов.
| |
|
2.8, Crazy Alex (ok), 15:09, 11/12/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
Ну, прототип от продакшн-решения примерно тем и отличается, что он ясно-понятный. А дальше наворачиваем то, что надо в реальной жизни... и этого "навёрнутого" оказывается процентов 80-90 кода.
| |
|
3.9, пох (?), 15:17, 11/12/2017 [^] [^^] [^^^] [ответить]
| –2 +/– |
и ты уверен что вот этот весь п-ц кому-то нада в реальной жизни?
запустить единичный стремный контейнер с дополнительным уровнем изоляции - без всяких кубернетесов и прочих чудес, потому что такое ты точно не хочешь на автоматическом проде - это вполне понятная задача из реальной жизни.
| |
|
4.13, Crazy Alex (ok), 15:59, 11/12/2017 [^] [^^] [^^^] [ответить]
| +/– |
Для "единственного контейнера" мне вообще пофигу накладные расходы, обычного KVM хватит.
Я точно уверен, что дело идёт к тому, что в абсолютном большинстве случаев "ручные запуски" контейнеров уйдут, а останутся именно кубернетесы и прочее. Примерно как от явно выделенных процессов ушли к пулам (а потом к пулам потоков) потоков, которые создаются и убиваются какой-то автоматикой. И точно уверен, что с ростом сложности новые уровни безопасности будут нормой, и подход будет "отдетектиили подозрительную активность? Убиваем контейнер и перезапускаем где-то ещё с нуля, а потом (может быть) разбираемся", потому что диагностировать всё это в реальном времени никаких ресурсов не хватит.
| |
|
5.16, пох (?), 16:50, 11/12/2017 [^] [^^] [^^^] [ответить]
| –3 +/– |
так идея-то была не в этом совсем. Идея была - (чужой) стандартный докеровский или еще чей образ запустить, не разбираясь с его потрохами.
А не сетапить kvm с нуля, потом выковыривать из образа что они там наслесарили и вручную это воспроизводить.
| |
|
6.27, Crazy Alex (ok), 20:10, 11/12/2017 [^] [^^] [^^^] [ответить]
| +/– |
Ну, это у кого какая идея. У меня - что сделать надёжно изолированные друг от друга контейнеры - всё меньше шансов, а быстро поднимать/убивать их хочется. В этом плане затея как раз правильная. Если что-то подобное не предполагать то совершенно непонятно, зачем выбирать то, где "20 мб на контейнер". Для вашего случая наверняка есть какой-то другой вариант уже сейчас. Скорее всего с оверхедом по сложности и тратам ресурсов - но для "один раз что-то запустить" - не критично.
| |
|
7.34, . (?), 05:00, 12/12/2017 [^] [^^] [^^^] [ответить]
| +/– |
>Для вашего случая наверняка есть какой-то другой вариант уже сейчас. Скорее всего с оверхедом по сложности и тратам ресурсов - но для "один раз что-то запустить" - не критично.
Может Vagrant тогда?
| |
7.35, Аноним (-), 07:04, 12/12/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
Быстро запускать контейнеры это к kvm, из соспенда стартует как раз за <100мс
| |
|
|
|
|
|
|
1.12, Аноним (-), 15:57, 11/12/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
Комментаторы действительно поняли о чем речь, просто прочитав текст новости?
| |
1.14, Аноним (-), 16:26, 11/12/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Нужно как-то всё систематизировать, и в одной статье разжевать. Я уже вообще не ориентируюсь в этой куче контейнеров, и не понимаю, на надо их столько?
| |
1.33, ТехнокраД (?), 22:47, 11/12/2017 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Чего только не придумают чтобы не юзать rkt, там ведь, все доступно из коробки через stages, плюс кроме этого в комплекте с SELinux получается вполне продакшен решение. Другое дело что есть некоторые огрничения при работе в связке с k8s, но это уже отдельная тема, надо активней пинать по ишам разрабо k8s и ребят из coreos.
| |
|
2.38, пох (?), 10:00, 12/12/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Чего только не придумают чтобы не юзать rkt,
не нужно ничего придумывать, чтобы "не юзать" еще одну ненужно-ненужно обертку вокруг lxc, сделанную в режиме "зато не докер!"
> там ведь, все доступно из коробки через stages,
кроме самого rkt, который из коробки только в неведомой зверушке. При этом https://github.com/rkt/rkt/blob/master/Documentation/running-kvm-stage1.md
How does it work?
It leverages the work done by Intel with their Clear Containers system.
это я и без rkt могу (и да, перед этим там длинный список того, что у них в таком режиме не работает) - а вот сможет ли теперь что-нибудь rkt, когда интел забьет на старый проект?
> плюс кроме этого в комплекте с SELinux получается вполне продакшен решение.
на продакшн обычно некогда ковыряться с audit2allow "угадай что этой твари опять надо" и негде хранить терабайты мусора недоделанного линуксного audit.log.
К тому же контейнеры у нас такие контейнеры: https://nvd.nist.gov/vuln/detail/CVE-2015-1334
Эту дырку закрыли - новых понаделают.
| |
|
|
4.43, Аноним (-), 14:43, 12/12/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
так сварм, как часть докера, это наоборот красотуля, хотя с ростом проекта глюков всё больше
| |
|
|
|
|