Комментарии 10
Не обязательно уменьшать контейнер до максимума, куда интереснее уменьшать количество стадий.
Тут тоже возможны перегибы, когда всё ужимается до 4-5 слоёв, с уникальной rootfs для каждого образа при том, что они различаются только какой-нибудь мелочёвкой типа конфигов или пользовательского приложения.
Ага и при этом имеем ад с безопасностью и обновлениями, в теории и на конференциях все красиво, на практике, через пол года-год от создания всего это счастья в нижнем слое вылезает какая-либо критическая уязвимость (привет ssl) и мы получаем необходимость пересобрать все контейнеры, что на порядки больше чем при работе с виртуалками и контейнерами типа OVZ, обновления для типа "контейнер на приложение" — это полная пересборка контейнера, нельзя просто так взять и наложить системный патч на нижнем уровне, получив заплатку на верхнем, автоматизация наложения обновленей по листам безопасности превращается в страшный геморрой. Лично мое мнение, что неизменяемый контейнер на приложение — это тупиковая ветвь эволюции контейнеризации и мне кажется что больше перспектив у изменяемых линкованных контейнеров, когда можно наложить изменения на нижный уровень и получить их на верхнем, но это взгляд админа, программисту удобней собрать все в кучу, забить на безопасность и не подстраиваться под окружение пользователя, мне кажется из-за этого докер сейчас так популярен.
А для этого есть сервер с CI. Перестраиваем корневой образ и все остальные вслед за ним, не вижу проблем.
На верхнем уровне мы можем иметь свое приложение собранное со старой "дырявой" библиотекой, так что пересборка корневого образа в данном случае не даст ничего, на нижнем уровне будет заплатка, верхний так и останется дырявым и следить за всеми библиотеками внутри каждого контейнера и приложения создает огромный пласт работы и на практике на безопасность просто забивают, обновили корневой образ, а то что выше, "так кто их помнит".
Пересборка нижнего уровня влечет за собой пересборку верхних уровней. Если же апдейта не было для верхнего уровня как спасет другая архитектура? Ну запатчим мы систему, а библиотека так же останется дырявой.
Так в этом и основная сложность, имея архитектуру типа "контейнер на услугу" мы обновляем намного меньше контейнеров, чем имея "контейнер на приложение". Утрированный пример: имеем сервер со 100 контейнерами типа OVZ на которых крутятся веб сервера вида: nginx+mysql+php+node.js+ssh+ftp+exim+dovecot… еще 10 стандартных сервисов, итого в среднем 20 сервисов на контейнер, в случае изменяемых контейнеров мы в полуавтоматическом режиме накладываем апдейты безопасности для всех этих сервисов во всех контейнерах сразу, грубо говоря однострочник на ansible.
А теперь представим что та же ситуация в докере, контейнеров уже не 100 а 100*20=2000 и каждый нам надо пересобрать соблюдая порядок уровней наследования, а затем ввести в продашкин поочередно заменяя страрые на новые.
Чтоб не разводить дубль дискуссии, которая была не так давно, просмотрите аргументы за и против в этой теме:
https://habrahabr.ru/post/277699/#comment_8780799
А теперь представим что та же ситуация в докере, контейнеров уже не 100 а 100*20=2000 и каждый нам надо пересобрать соблюдая порядок уровней наследования, а затем ввести в продашкин поочередно заменяя страрые на новые.
Чтоб не разводить дубль дискуссии, которая была не так давно, просмотрите аргументы за и против в этой теме:
https://habrahabr.ru/post/277699/#comment_8780799
Угу, я согласен что рулить привычным способом для повторяющихся приложений на одной машине это не самый быстрый способ(например для хостеров). С другой стороны если построение контейнеров автоматизированно и требуется быстрый деплой то контейнер весьма неплохой способ, все же требует оптимизации под конкретную задачу. Обновить 9k+ контейнеров где обновился всего один слой не такая уж и долгая задача. И если нижние тяжелые слои одинаковые, они обновляются один раз, а дальше выкачиваются только нужное.
Я полностью согласен, что каждой задаче свой инструмент.
Я полностью согласен, что каждой задаче свой инструмент.
Ну подождите, вы так говорите, как будто вы эти контейнеры (образы) руками собираете. На деле вам надо просто заменить базовый образ, пересобрать все зависимые от него и переразлить контейнеры. То есть, по сути, поменять 1 докерфайл и запустить Docker CI, который пересоберет зависимые образы.
Всем привет. Подскажите какие продакшн-архитектуры чаще всего применяются в CoreOS для хранения Docker-образов?
Подключаем физический диск и форматируем в LVM для хранения image образов?
NFS я так понимаю не вариант.
Спасибо.
Подключаем физический диск и форматируем в LVM для хранения image образов?
NFS я так понимаю не вариант.
Спасибо.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Немного о контейнерах