Кто может поделиться юзерстилями для нового Хабра на которых в комментариях не режет глаза? Потому что читать это сейчас — невозможно.
illo что-то с комментариями делать планируется? После смены шрифта под Windows на Arial стало лучше, но комментарии все еще читать тяжело.
W7, Chrome 60
Позволю себе не согласиться: контейнеризация — отличная вещь, позволяющая добиться повторяемости результата и упрощающая горизонтальное масштабирование.
А дальше реалоад в крон на каждый 5 минут и вот 80 порт шарится на кучу виртуал хостов.
А что если кто-то намеренно сломает свой конфиг?
Правда я не задумывался насколько это всё вандалоустойчиво относительно виртуализации.
В том-то и дело что оно неустойчиво :)
Гораздо лучше контейнеризовать приложение и дать доступ к БД (если речь о Postrges или MySQL).
Рассмотрим оверхед на примере LXC:
виртуальный сетевой интерфейс (можно отдать и железный, если есть желание)
init
sshd
легковесное окружение
Это всё в совокупности занимает меньше 1ГБ места и жрет меньше 200М ОЗУ при длительной работе. Оверхед по CPU минимален.
Что мы получаем взамен?
изоляция сети и процессов на уровне namespaces
контроль ресурсов на уровне cgroups
эквивалент chroot
переносимость (можно один и тот же контейнер запустить на любом сервере, поддерживающем LXC)
Это всё реализуется и без контейнеров, но заворачивание этого всего в контейнер дает пользователю свою песочницу, почти эквивалентную VPS (нельзя грузить модули ядра и крутить sysctl, плюс ломается софт типа NFSd ввиду специфики работы с ядром).
Так в том и прикол что современная контейнеризация это, по-сути, солянка из namespaces, cgroups и aufs/overlay/btrfs.
Первые два — ядерные механизмы, уже присутствующие в ядре (как минимум с Ubuntu 12.04). Если к этому добавить SELinux или AppArmor — получаем достаточный уровень изоляции.
Всё это уже можно задействовать на полную катушку в современных дистрах, где есть SystemD (там поддержка пока что наиболее полная — изоляция вплоть до сервиса).
Менять, конечно, пришлось бы уйму всего, но масса механизмов для изоляции и контроля уже существует и даже работает.
А вот с ОЗУ и ЦП всё интереснее. Да, у виртуалок есть оверхэд. Но в идее автора тоже есть изъяны. А если по его схеме вдруг не хватает ресурсов? Вот просто у кого-то там нагрузка пиковая возникла. Пострадают все.
Приходим к идеи типа шейпинга процессорного времени и потребления ОЗУ. Опять же. Упирается в всё в то, как ОС работают в принципе. Там таких инструментов не предусмотрено. да. Можно выставлять ограничения в отдельном софте (типа БД). Но в большинстве случаев — нельзя. Получаем гигансткий несогласованный оркестр, которым надо попытаться управлять. Идеи ныне популярной контейнеризации тут ближе (хотя и ВМ, по сути, контейнер) к реальности. Возможно даже можно будет решать схожие задачи через некоторое время.
Сертификаты скомпрометированы. Эти черти могут выпустить другой сертификат и подписать его, не отозвав оригинальный, давая возможность устроить MitM на HTTPS.
По-хорошему давно пора было забанить этот CA с такими приколами.
Соль вот в чем: нельзя использовать код защищенный авторскими правами, а вот если его разобрать и написать код, делающий то же самое — это уже другой код, не являющийся собственностью автора оригинального продукта.
Нет-нет, вы тут путаете один момент: cgroups — ядерный механизм, который работает.
То что JVM его не поддерживает проблема исключительно JVM, потому что если JVM попытается сожрать больше памяти чем позволяет cgroup, то апп вылетит в трубу — именно так оно и работало в Java 8, и это неоднократно поднималось на SO.
JVM уже умеет в cgroups? Docker делает изоляцию и лимитирование ресурсов через cgroups и namespaces (тут только изоляция). Для cgroups нужна поддержка, потому что иначе софт не видит лимиты, установленные cgroups, но ядро их форсит (free в контейнере, например).
Так вот, в JVM добавили эту поддержку или нет? Если нет, то это проблема JVM и отсутствия поддержки ядерных механизмов изоляции :)
Я поэтому предпочитаю читать, а не смотреть видео.
Кто может поделиться юзерстилями для нового Хабра на которых в комментариях не режет глаза? Потому что читать это сейчас — невозможно.
illo что-то с комментариями делать планируется? После смены шрифта под Windows на Arial стало лучше, но комментарии все еще читать тяжело.
W7, Chrome 60
у меня еще и предыдущий коммент порезало — слово "простая" выглядит как на скриншоте
Win 7 Chrome 60.0.3112.90 (Official Build) (64-bit)
Да, если сделать темнее фон — становится лучше.
Проблема в цвете шрифта — толи недостаточно контрастно, толи слишком контрастно — режет глаза.
У нас Mattermost и у админов в меню есть пункт Manage Members, где это всё есть.
Новый Скайп на Андроиде это такая любимая игрушка мазохиста.
У вас сколько закладок? У меня — тыщи полторы-две.
Вот я и ввожу адрес:
habи Хром мне сразу предлагает как сам Хабр так и ряд закладок оттуда. Удобно, но адрес всё равно приходится вводить.Можно еще ввести
хаб, но тогда главная будет третьей по списку, первыми будут две других закладки.А можно те 4% которые "ни туда и ни сюда" мне будут?
Позволю себе не согласиться: контейнеризация — отличная вещь, позволяющая добиться повторяемости результата и упрощающая горизонтальное масштабирование.
А что если кто-то намеренно сломает свой конфиг?
В том-то и дело что оно неустойчиво :)
Гораздо лучше контейнеризовать приложение и дать доступ к БД (если речь о Postrges или MySQL).
Рассмотрим оверхед на примере LXC:
Это всё в совокупности занимает меньше 1ГБ места и жрет меньше 200М ОЗУ при длительной работе. Оверхед по CPU минимален.
Что мы получаем взамен?
Это всё реализуется и без контейнеров, но заворачивание этого всего в контейнер дает пользователю свою песочницу, почти эквивалентную VPS (нельзя грузить модули ядра и крутить sysctl, плюс ломается софт типа NFSd ввиду специфики работы с ядром).
Так в том и прикол что современная контейнеризация это, по-сути, солянка из namespaces, cgroups и aufs/overlay/btrfs.
Первые два — ядерные механизмы, уже присутствующие в ядре (как минимум с Ubuntu 12.04). Если к этому добавить SELinux или AppArmor — получаем достаточный уровень изоляции.
Всё это уже можно задействовать на полную катушку в современных дистрах, где есть SystemD (там поддержка пока что наиболее полная — изоляция вплоть до сервиса).
Менять, конечно, пришлось бы уйму всего, но масса механизмов для изоляции и контроля уже существует и даже работает.
Существует, но не установлен. И тем не менее — грусть.
cgroups, anyone?
Записи SRV так и не обрели популярности...
wiki/Абляционная защита
Сертификаты скомпрометированы. Эти черти могут выпустить другой сертификат и подписать его, не отозвав оригинальный, давая возможность устроить MitM на HTTPS.
По-хорошему давно пора было забанить этот CA с такими приколами.
Соль вот в чем: нельзя использовать код защищенный авторскими правами, а вот если его разобрать и написать код, делающий то же самое — это уже другой код, не являющийся собственностью автора оригинального продукта.
Нет-нет, вы тут путаете один момент: cgroups — ядерный механизм, который работает.
То что JVM его не поддерживает проблема исключительно JVM, потому что если JVM попытается сожрать больше памяти чем позволяет cgroup, то апп вылетит в трубу — именно так оно и работало в Java 8, и это неоднократно поднималось на SO.
JVM уже умеет в cgroups? Docker делает изоляцию и лимитирование ресурсов через cgroups и namespaces (тут только изоляция). Для cgroups нужна поддержка, потому что иначе софт не видит лимиты, установленные cgroups, но ядро их форсит (free в контейнере, например).
Так вот, в JVM добавили эту поддержку или нет? Если нет, то это проблема JVM и отсутствия поддержки ядерных механизмов изоляции :)
А за этот каммент я вам минус в карму ткнул. Чтоб потом вопросов "за что?!" не возникало.