Сформулирую по другому — существует ли у докера возможность работать с несколькими физическими серверами — т.е. своя система репликации образов систем и контейнеров? Или все ограничивается одним сервером с его ФС?
Далее — что произойдет если докер упадет?
Из обсуждений ниже и этой фразы выходит что, докер посредством cgroups запускает на исполнение образ системы с изменениями взятыми из конфига для контейнера?
Этот код независим уже или все-таки управляется докером?
Как это работает с распределенной сложной системой? Типа удаленной загрузки?
Но при этом все процессы докера работают на физическом host сервере деля все процессоры и всю доступную память. Подход, используемый докером находится посередине между запуском всего на физическом сервере и полной виртуализацией,
деньги направляют. В какой-то момент в Apple решили что свои процессоры выпускать — себе дороже и перешли на x86. Ну и Intel тоже давил конкурентов. Сейчас вот все больше начинают переходить на ARM, т.к. х86 уже не дает нужных результатов.
Насколько я помню, кэш L1 в x86 тоже разделяет код и данные.
Не совсем так. Он хранит их отдельно — соответственно к частоте обращений. Ну и при многоядерности и/или эмуляции многоядерности — это дает неплохой прирост производительности.
в данном случае Вы запускали минимальное ядро — производили компляцию кода под свое железо, и при перезагрузке уже запускали полученный код. Конечно все это вообще работало через BIOS — или его Вы тоже произвольно меняли? Прям во время работы системы?
Извините, ошибся — это были компьютеры от Apple на базе PowerPC ()
В данном контексте упомянул, т.к. в них аппаратно была разделена память программ (для кода) и память данных. (надо заметить что зависали они тоже довольно часто, но все же меньше чем с х86 архитектурой). В принципе подобных подход в архитектуре наблюдаем в микроконтроллерах.
Т.е. Вы утверждаете что докер работает на любой архитектуре железа и напрямую к процессору не обращается? В статье и комментариях утверждается обратное.
Насчет ОС от МС — по умолчанию (для оптимизации использования памяти) ОС делает интересные «финты» с кодом и данными — и надо использовать доп системные утилиты и настройки чтобы использовать возможность действительно независимого использования кода и данных.
ну так я вас удивлю, в винде тоже реализованна такая абстракция как процесс
Да не надо меня удивлять — просто внимательно прочитайте свои же слова.
И про гипервизоры — ну хоть википедию почитайте внимательнее что-ли.
ОФФ И кстати — переход на личности, и личные характеристики говорит о невозможности аргументировать свою точку зрения и отсутствию самой возможности конструктивного решения нашего спора. Не любите критику — лучше молчите.
В таком же смысле можно сказать что любая ОС «хранит и использует разность кода от базового образа (свежеустановленного) как свои данные, которые передает на исполнение».
Ваше утверждение не верно.
Образ системы — это сохраненная копия кода и (возможно) данных на определенный момент времени. Как правило для его создания используются сторонние инструменты, т.к. обычно ОС имеет наивысший приоритет выполнения и не дает доступа к критическому коду.
Даже в обычном ПК (с х86 архитектурой) код ОС не изменяется произвольно. Я уж не говорю о других системах (ну навскидку были процессоры PowerMac или реализации суперЭВМ, встроенные системы) — для изменения кода требовался особый алгоритм и средства.
К тому что Вы описали больше подходят системы с произвольно изменяемой архитектурой к созданию которых только подошли, и в какой-то мере нейросистемы.
Можно. ОС — это и есть централизованное управление доступом к конкретным аппаратным ресурсам. И ее надежность по сравнению с гипервизором ниже. Поэтому его (гипервизор) и используют для повышения надежности — убирают слой прикладного ПО на более высокий уровень. Ну для надежности еще и дублируют (создают кластеры).
Строго говоря для надежности сложная система должна иметь несколько автономных (и/или дублированных-троированных) узлов (в идеале все — что экономически не выгодно) для гарантированного выполнения своих задач.
Докер же как мне представляется, делает с точностью до наоборот — все сводится к полной централизации. Т.е.придется прилагать усилия для обеспечения его надежной работы, а также используемых линий связи — в сложных и распределенных системах.
1. что такое «свои» данные и чем они отличаются от «не своих»
Извините, но тут уж должен направить на изучение работы процессора в защищенном режиме (хотя бы в общих чертах)
2. Что означает ваша фраза:
в системе могут работать сразу два кода.
А здесь к общим понятием запуска и работы процессов (кода) в *nix системах.
гипервизора работает поверх хост системы.
Извините — но это Вы путаете понятие гипервизора и систему виртуализации.
Чтобы попроще — гипервизор устанавливается на железо, система виртуализации — на хост-систему. И тут гипервизор более надежен — т.к. у него меньше код, а значит и меньше верятность сбоя.Также гипервизор не работает с пользовательским ПО — он работает с системным ПО — его надежность намного выше, чем хост-системы.
Работая на более низком уровне гипервизор НАМНОГО сложнее чем докер
Ничего удивительного — гипервизор реально управляет системой (ее основными функциями), а докер — всего лишь приложение и много чего передает для отработки хост-системе и работает в принципе из-под нее (с меньшим приоритетом)
И поэтому его надежность выносится отдельно от надежности хост-системы. Упрощенно.
я добавлю и больше — при горячей и память может не очищается — и в общем-то зависит от конкретной реализации железа. Уж не говорю о том что с портами и периферией происходит. Неизменно одно — процессор начинает работу с «нуля».
По приведенной ссылке — именно так — с построением древовидной структуры и приоритетом доступа.
Тоже нет. Процессы продолжат работать даже если упадет docker daemon.
пока не надо будет к нему обратится, а обратится надо будет — если вдруг перезапуск системы или сверка с изначальным образом, или чтение конфигурации…
Зависимость от хост-системы
Минимальна. В идеале её нет вовсе.
не надо лукавить — докер — одино из приложений в хост-системе — со всеми вытекающими
Если бы докер был ненадежным или некачественным продуктом, это было бы важным аргументом против.
Сбои происходят с любым ПО — насколько часто — это зависит от многих факторов. Я указал что это еще один уровень в возможном сбое. То же относится и настройке конечного ПО — это уровень возможного отказа (сбоя).
позволяя проверить ваш контейнер заранее точно в таком же окружении
В итоге мы пришли к мнению о применении у тестировщиках и девелоперах. Пользователям незачем проверять работу приложения — пользователям надо чтобы оно уже работало.
код — то, что передается на исполнение (команда процессору)
данные — то, над чем оперирует код (информация)
холодная перезагрузка — перезагрузка системы при помощи аппаратного механизма (железо)
горячая перезагрузка (hot-reload) — перезагрузка системы при помощи команды (кода) процессору
то о чем я писал — обновление и запуск ядра системы «не лету» — без перезагрузок вообще.
Насколько я понимаю — докер хранит и использует разность кода от базового образа как свои данные, которые передает на исполнение. Фактически контейнер это разностная копия данных. Так?
Также получается, что сбой в организации хранения и вызова данных для исполнения контейнера (докера) может привести к сбою работы других контейнеров — это как раз пример
Влияет в то же степени, в которой остановка сервера управления базой данных повлияет на приложение, которое его использует.
То есть при «падении» докера — «упадут» и все контейнеры — со всеми своими пользовательскими приложениями и данными? И времени до «падения» будет ровно столько, пока к докеру не обратится.
От чего зависит в итоге конечный пользователь:
Зависимость от хост-системы,
зависимость от докера,
зависимость от изначального образа для контейнера
зависимость от настройки контейнера,
зависимость настройки конечного ПО в контейнере
Сравните с работой при использовании гипервизора (который намного легче и проще хост-системы — а значит и надежнее)
В итоге:
Это более надежная система? Нет. Удобная по быстроте разворачивания? Да.
Т.е. область применения — девелоперы и тестировщики.
А если вы обновили скажем tomcat, postgre или ваш собственный код БЕЗ докера, то перегружаться не надо?
нет — не надо — во всяком случае пока этот код работает с этими данными — код будет работать, а вот при следующем вызове запустится уже обновленный новый экземпляр кода. И да — в системе могут работать сразу два кода. Даже ядро так работает. И да — даже при обновлении ядра не надо перезагружать всю систему (ну уж если не совсем все поменяли).
Это все уже давно-давно есть в *nix-ах.
Влияет в то же степени, в которой остановка сервера управления базой данных повлияет на приложение, которое его использует.
Ну и чем это не подход от МС — сбой в работе с данными приводит к сбою приложения (и соответственно с другими данными)?
Так что нового и удобного дает докер для «нетестировщиков»?
Ну ниже подняли практический вопрос из моего теоретического.
Поясняю — по статье выходит, что данная система по принципу построения мало отличается от принципа построения ОС от Майкрософт, т.е. у них — один программный код работает с раздельными данными и сбой в работе кода ведет к сбою работы со всеми данными. И в самом плачевном случае — сбою всей системы. Поэтому при установке ПО ОС надо перезагружать. Поэтому и вечные проблемы с надежностью работы.
В *nix-ах каждый код работает со своими данными — что и дает надежность.
То, что описано в статье, на мой взгляд — попытка привнести неудачный подход в надежности работы системы.
Ниже уже утверждается — да — надо перезагружаться при обновлениях, да — влияет на работоспособность всех зависимых контейнеров.
Мое мнение — этот инструмент больше подходит для тестировщиков (где надо промоделировать схожие ситуации в работе ПО и/или собрать статистику), чем для внедрения в реальные системы.
Далее — что произойдет если докер упадет?
Из обсуждений ниже и этой фразы выходит что, докер посредством cgroups запускает на исполнение образ системы с изменениями взятыми из конфига для контейнера?
Этот код независим уже или все-таки управляется докером?
Как это работает с распределенной сложной системой? Типа удаленной загрузки?
я рад что Вы весело провели время
f0rk
«Уровень ядра» — это прямое обращение к аппаратуре — т.к. у ядра ОС наивысший приоритет обычно.
Не совсем так. Он хранит их отдельно — соответственно к частоте обращений. Ну и при многоядерности и/или эмуляции многоядерности — это дает неплохой прирост производительности.
В данном контексте упомянул, т.к. в них аппаратно была разделена память программ (для кода) и память данных. (надо заметить что зависали они тоже довольно часто, но все же меньше чем с х86 архитектурой). В принципе подобных подход в архитектуре наблюдаем в микроконтроллерах.
Насчет ОС от МС — по умолчанию (для оптимизации использования памяти) ОС делает интересные «финты» с кодом и данными — и надо использовать доп системные утилиты и настройки чтобы использовать возможность действительно независимого использования кода и данных.
Да не надо меня удивлять — просто внимательно прочитайте свои же слова.
И про гипервизоры — ну хоть википедию почитайте внимательнее что-ли.
ОФФ И кстати — переход на личности, и личные характеристики говорит о невозможности аргументировать свою точку зрения и отсутствию самой возможности конструктивного решения нашего спора. Не любите критику — лучше молчите.
Ваше утверждение не верно.
Образ системы — это сохраненная копия кода и (возможно) данных на определенный момент времени. Как правило для его создания используются сторонние инструменты, т.к. обычно ОС имеет наивысший приоритет выполнения и не дает доступа к критическому коду.
Даже в обычном ПК (с х86 архитектурой) код ОС не изменяется произвольно. Я уж не говорю о других системах (ну навскидку были процессоры PowerMac или реализации суперЭВМ, встроенные системы) — для изменения кода требовался особый алгоритм и средства.
К тому что Вы описали больше подходят системы с произвольно изменяемой архитектурой к созданию которых только подошли, и в какой-то мере нейросистемы.
Докер же как мне представляется, делает с точностью до наоборот — все сводится к полной централизации. Т.е.придется прилагать усилия для обеспечения его надежной работы, а также используемых линий связи — в сложных и распределенных системах.
Извините, но тут уж должен направить на изучение работы процессора в защищенном режиме (хотя бы в общих чертах)
А здесь к общим понятием запуска и работы процессов (кода) в *nix системах.
Извините — но это Вы путаете понятие гипервизора и систему виртуализации.
Чтобы попроще — гипервизор устанавливается на железо, система виртуализации — на хост-систему. И тут гипервизор более надежен — т.к. у него меньше код, а значит и меньше верятность сбоя.Также гипервизор не работает с пользовательским ПО — он работает с системным ПО — его надежность намного выше, чем хост-системы.
Чем стандартно установленная ОС.
Ничего удивительного — гипервизор реально управляет системой (ее основными функциями), а докер — всего лишь приложение и много чего передает для отработки хост-системе и работает в принципе из-под нее (с меньшим приоритетом)
И поэтому его надежность выносится отдельно от надежности хост-системы. Упрощенно.
По приведенной ссылке — именно так — с построением древовидной структуры и приоритетом доступа.
пока не надо будет к нему обратится, а обратится надо будет — если вдруг перезапуск системы или сверка с изначальным образом, или чтение конфигурации…
не надо лукавить — докер — одино из приложений в хост-системе — со всеми вытекающими
Сбои происходят с любым ПО — насколько часто — это зависит от многих факторов. Я указал что это еще один уровень в возможном сбое. То же относится и настройке конечного ПО — это уровень возможного отказа (сбоя).
В итоге мы пришли к мнению о применении у тестировщиках и девелоперах. Пользователям незачем проверять работу приложения — пользователям надо чтобы оно уже работало.
данные — то, над чем оперирует код (информация)
холодная перезагрузка — перезагрузка системы при помощи аппаратного механизма (железо)
горячая перезагрузка (hot-reload) — перезагрузка системы при помощи команды (кода) процессору
то о чем я писал — обновление и запуск ядра системы «не лету» — без перезагрузок вообще.
Насколько я понимаю — докер хранит и использует разность кода от базового образа как свои данные, которые передает на исполнение. Фактически контейнер это разностная копия данных. Так?
Также получается, что сбой в организации хранения и вызова данных для исполнения контейнера (докера) может привести к сбою работы других контейнеров — это как раз пример
То есть при «падении» докера — «упадут» и все контейнеры — со всеми своими пользовательскими приложениями и данными? И времени до «падения» будет ровно столько, пока к докеру не обратится.
От чего зависит в итоге конечный пользователь:
Зависимость от хост-системы,
зависимость от докера,
зависимость от изначального образа для контейнера
зависимость от настройки контейнера,
зависимость настройки конечного ПО в контейнере
Сравните с работой при использовании гипервизора (который намного легче и проще хост-системы — а значит и надежнее)
В итоге:
Это более надежная система? Нет. Удобная по быстроте разворачивания? Да.
Т.е. область применения — девелоперы и тестировщики.
нет — не надо — во всяком случае пока этот код работает с этими данными — код будет работать, а вот при следующем вызове запустится уже обновленный новый экземпляр кода. И да — в системе могут работать сразу два кода. Даже ядро так работает. И да — даже при обновлении ядра не надо перезагружать всю систему (ну уж если не совсем все поменяли).
Это все уже давно-давно есть в *nix-ах.
Ну и чем это не подход от МС — сбой в работе с данными приводит к сбою приложения (и соответственно с другими данными)?
Так что нового и удобного дает докер для «нетестировщиков»?
Поясняю — по статье выходит, что данная система по принципу построения мало отличается от принципа построения ОС от Майкрософт, т.е. у них — один программный код работает с раздельными данными и сбой в работе кода ведет к сбою работы со всеми данными. И в самом плачевном случае — сбою всей системы. Поэтому при установке ПО ОС надо перезагружать. Поэтому и вечные проблемы с надежностью работы.
В *nix-ах каждый код работает со своими данными — что и дает надежность.
То, что описано в статье, на мой взгляд — попытка привнести неудачный подход в надежности работы системы.
Ниже уже утверждается — да — надо перезагружаться при обновлениях, да — влияет на работоспособность всех зависимых контейнеров.
Мое мнение — этот инструмент больше подходит для тестировщиков (где надо промоделировать схожие ситуации в работе ПО и/или собрать статистику), чем для внедрения в реальные системы.