Наша дискуссия было про другое, если я уловил мысль — про создание временных контейнеров при docker build. Потом этот временный контейнер commit'ится и получается промежуточный образ.
Мысль свою разверните. И, да, я не путаю. Потому что у Вас в стандартном докере бежит стандартная… Дистрибьюция линукса. Со стандартным пакетным менеджером. И делая apt install Вы туда тащите кучу всего. Даже не разбираясь нужно оно или нет. Причем. Что интересно. Чем более "жирный" образ — тем меньше желания залезать ему под капот (а получить образ на 3-4 ГиБ с pytorch, cuda etc — легко, хотя это и экстремальный случай)
Качайте только официальные образы, там обычно все норм
У официальных образов другие проблемы есть. Например, достаточно ограниченный набор "ручек" для настройки, спорные дефолты. Поэтому набирают силу и клиентскую массу альтернативные образы — например, от bitnami, которые позволяют согласно 12-factor передавать все или хотя бы бОльшую часть ключей через переменные окружения.
завернуть приложение вместе с его окружением в одну сущность (образ) с минимумом лишнего хлама.
К сожалению, разрабы думают про это обратное — для них докер удобный способ замести весь мусор (в случае языков вроде python, js@node.js, ruby и пр.) в контейнер и больше об этом не думать. Не мешает? Ну, и ладно.
Т.е. если речь про тестирование/разработку — к докеру по сути-то вопросов особо и не возникает. ) Удобно. Быстро. Как правило — не вызывает особой головной боли. Но не нужно из него делать… универсальное решение всех проблем.
К сожалению, тут у меня пробел, но насколько мне известно — windows containers позволяют запускать только Вин-приложения, но не линукс-контейнеры… Так что универсальностью тут и не пахнет.
Вы сами-то такие старые сервера видели? Если да, то пора бы их уже обновлять.
Касательно centos — там вообще по умолчанию до последнего времени был devicemapper и ничего… как-то жили..
если у вас Docker 18.06 или старше
старше — в смысле новее версия или более ранняя? Я бы рекомендовал выражать свои мысли точнее ) Ну, и в 18.06, по-моему, overlay уже нормально работал.
Во-первых: всегда можно залить фото как файл, будет 1-в-1, но не в рамках безлимита.
Где гарантия, что завтра под соусом заботы о пользователе, завтра гугль не взбеленится и автоматически не переконвертирует мои фото-файлы?
В-третьих: не будь такого ограничения, кто бы мне помешал заливать файлы по нескольку десятков гигабайт? Если никто, то никто бы и не предложил безлимитного хранилища.
Это логично, но это капиталистический вопрос. Покупаю свой собственный сторедж — ты управляешь рисками. Пользуюсь гуглом (бесплатно и даже по подписке) — ты сам являешься товаром и странно ожидать от сервиса того, что он будет дарить место за так (стоимость хранения, поддержки и пр.)
Это нечестно. У вас предаллоцированные ресурсы. Если вы упретесь в количество нод и все равно придется провижионить новые, то это будет от дней (баре метал) до минут (облако) и все равно спайк вы пропустите. В этом отношении — докер поможет, но за счёт того, что у вас есть резерв в кластере прямо сейчас. Читай — недоутилизированные ресурсы, за которые вы платите. И, да, в принципе, с тем же успехом можно и без докера — больше вопрос выбора оркестратора, который сможет запускать приложение в виде дополнительных реплик.
И, повторюсь опять, если требуется поднимать сами ноды (ВМ) — то из готовых образов со всем необходимым они даже подниматься будут быстрее, чем с докером, т.к. ему ещё имиджи надо стянуть с софтом… Но это больше вопрос первого, "холодного" старта
Поддержу. Но скорее запуск контейнера триггерит не CMD. А именно вторая инструкция после FROM :-) но это детали реализации. Давайте в них не углубляться. Просто если коллега изначально правильно написал БЫ про ENTRYPOINT + CMD....
Контейнер докера легковесный. Существующие образы содержат только самое необходимое для работы одного приложения. Докер — не полноценная виртуалка. Скорее, это эмулятор операционной системы.
К сожалению, это полуправда. Дело в том, что большинство образов на докерхаб содержат избыточные компоненты. Вот глядишь и понимаешь, что чтобы это заработало — надо все переписать на golang'е, компилировать в статический бинарь и именно его уже класть в FROM: scratch
Тогда заживём. А пока мусора в образах больше, чем полезной нагрузки...
Докер — мультиплатформенный. Даже дизайнер, имея самые общие представления о работе контейнеров, может поставить себе докер и запустить проект.
К сожалению, если он не сидит под линуксом, то его может очень быстро настигнуть разочаровании в докере. В маке и под виндой докер работает через выделенную вм, а это означает сразу более низкую производительность. В первую очередь — по дисковым операциям. Отчасти проблему решает docker-sync
А ещё сетевое взаимодействие становится сложнее.
Слои — не панацея. Даже правильное их расположение не решает проблему, когда по факту нужно "ромбической наследование" слоев. А оно, между прочим оказывается нужно достаточно часто. И я даже не знаю — благо ли это, что его нет в докере или нет. Т.к. наследование ромбиком это всегда путь отстрелить себе ногу (например, в обоих родительских образах есть одинаковые каталоги-файлы по имени, но разные по содержимому). Лучше бы diff докачивался не послойно, а пофайлово. Ей-Богу.
Так же не понятно как обеспечивать взаимодействие контейнеров: как создавать виртуальные сети, маппить порты, задавать переменные окружения?
Переоцениваете важность и нужность виртсетей. Зачастую лучше вообще избегать докер-сетей. Сложно. Вносят penalty при сетевом взаимодействии. И пр
Ресурсы — как правило не проблема. Понятно, что для статического сайтика, завернутого в докер, оверхед от ещё одной копии ОСи будет больше, но это разговоры из серии "вам шашечки или ехать" — может вообще не стоило пытаться самому разворачивать хостинг тогда, а взять готовое SaaS решение? Нужно инструмент выбирать под задачу, а не наоборот.
Касательно уплотнения ресурсов. Ну, да, докер поможет. Но обратная сторона — а как же стабильность? Не боитесь огрести от того, что ядро общее и некоторые ресурсы ядра не изолируются? В случае если говорим про кубернетИс, то давайте говорить про него, а не про докер. Тем более, что рантаймы в к8с меняются. И, да, он умеет управлять виртуалками тоже (!!!!)
По сборке для квм — смотрите в сторону hashicorp packer. Можно собирать готовые образа вм под облачные платформы и все основные гипервизоры.
Насчёт виртуалки — при запуске на другой архитектуре процессора могут быть нюансы. Могут быть нюансы при смене типа гипервизора. Но, в целом, да — за исключением вопроса производительности и драйверов, виртуалка переедет и запустится.
Перевод отличный, но интересно узнать ваше мнение. Собственное. Потому что многие вещи, описанные в статье… ну, спорные…
Например, live-restore. Отличный способ себе пострелять по ногам, когда радикально меняются настройки докер демона (я не проверял, но есть подозрение, что та же смена storage driver + liverestore все сломает).
Еще есть как минимум два сценария использования докера — на машине разработчика в режиме разработки и на тестовых/промышленных средах. А вот для последних рекомендации актуальны. Вряд ли кто-то будет бридж на машине разработчика спуфить )
Мой тоже. Но я сообразил, что коллеги так перевели "recorder" (лучше бы написали — "записывающий CD-привод", а ниже в комментах уже предложили "резак").
даже более того — насколько я помню (я не очень хороший вэб-разраб), что при определенных условиях, если у нас есть приложения на поддоменах a.b.TLD и c.d.TLD, то они могут видеть свои куки и общие куки для домена b.TLD.
И там еще целая эпопея была, чтобы отличать двухкомпонентные TLD вроде co.uk от субдоменов.
Наша дискуссия было про другое, если я уловил мысль — про создание временных контейнеров при docker build. Потом этот временный контейнер commit'ится и получается промежуточный образ.
Мысль свою разверните. И, да, я не путаю. Потому что у Вас в стандартном докере бежит стандартная… Дистрибьюция линукса. Со стандартным пакетным менеджером. И делая apt install Вы туда тащите кучу всего. Даже не разбираясь нужно оно или нет. Причем. Что интересно. Чем более "жирный" образ — тем меньше желания залезать ему под капот (а получить образ на 3-4 ГиБ с pytorch, cuda etc — легко, хотя это и экстремальный случай)
У официальных образов другие проблемы есть. Например, достаточно ограниченный набор "ручек" для настройки, спорные дефолты. Поэтому набирают силу и клиентскую массу альтернативные образы — например, от bitnami, которые позволяют согласно 12-factor передавать все или хотя бы бОльшую часть ключей через переменные окружения.
К сожалению, разрабы думают про это обратное — для них докер удобный способ замести весь мусор (в случае языков вроде python, js@node.js, ruby и пр.) в контейнер и больше об этом не думать. Не мешает? Ну, и ладно.
Т.е. если речь про тестирование/разработку — к докеру по сути-то вопросов особо и не возникает. ) Удобно. Быстро. Как правило — не вызывает особой головной боли. Но не нужно из него делать… универсальное решение всех проблем.
К сожалению, тут у меня пробел, но насколько мне известно — windows containers позволяют запускать только Вин-приложения, но не линукс-контейнеры… Так что универсальностью тут и не пахнет.
Вы сами-то такие старые сервера видели? Если да, то пора бы их уже обновлять.
Касательно centos — там вообще по умолчанию до последнего времени был devicemapper и ничего… как-то жили..
старше — в смысле новее версия или более ранняя? Я бы рекомендовал выражать свои мысли точнее ) Ну, и в 18.06, по-моему, overlay уже нормально работал.
Где гарантия, что завтра под соусом заботы о пользователе, завтра гугль не взбеленится и автоматически не переконвертирует мои фото-файлы?
Это логично, но это капиталистический вопрос. Покупаю свой собственный сторедж — ты управляешь рисками. Пользуюсь гуглом (бесплатно и даже по подписке) — ты сам являешься товаром и странно ожидать от сервиса того, что он будет дарить место за так (стоимость хранения, поддержки и пр.)
Можно, но набегут сторонники того, что в тесте и в проде должны быть идентичные образы (в разработке — по ВОЗМОЖНОСТИ — тоже)
Бородатые админы и разработчики под Виндовс… даже не знаю… плачут или смеются....
Это нечестно. У вас предаллоцированные ресурсы. Если вы упретесь в количество нод и все равно придется провижионить новые, то это будет от дней (баре метал) до минут (облако) и все равно спайк вы пропустите. В этом отношении — докер поможет, но за счёт того, что у вас есть резерв в кластере прямо сейчас. Читай — недоутилизированные ресурсы, за которые вы платите. И, да, в принципе, с тем же успехом можно и без докера — больше вопрос выбора оркестратора, который сможет запускать приложение в виде дополнительных реплик.
И, повторюсь опять, если требуется поднимать сами ноды (ВМ) — то из готовых образов со всем необходимым они даже подниматься будут быстрее, чем с докером, т.к. ему ещё имиджи надо стянуть с софтом… Но это больше вопрос первого, "холодного" старта
Aufs уже в новых дистрибутивах не используют. Там overlay2. По сути для пользователя то же самое
Поддержу. Но скорее запуск контейнера триггерит не CMD. А именно вторая инструкция после FROM :-) но это детали реализации. Давайте в них не углубляться. Просто если коллега изначально правильно написал БЫ про ENTRYPOINT + CMD....
К сожалению, это полуправда. Дело в том, что большинство образов на докерхаб содержат избыточные компоненты. Вот глядишь и понимаешь, что чтобы это заработало — надо все переписать на golang'е, компилировать в статический бинарь и именно его уже класть в FROM: scratch
Тогда заживём. А пока мусора в образах больше, чем полезной нагрузки...
К сожалению, если он не сидит под линуксом, то его может очень быстро настигнуть разочаровании в докере. В маке и под виндой докер работает через выделенную вм, а это означает сразу более низкую производительность. В первую очередь — по дисковым операциям. Отчасти проблему решает docker-sync
А ещё сетевое взаимодействие становится сложнее.
Слои — не панацея. Даже правильное их расположение не решает проблему, когда по факту нужно "ромбической наследование" слоев. А оно, между прочим оказывается нужно достаточно часто. И я даже не знаю — благо ли это, что его нет в докере или нет. Т.к. наследование ромбиком это всегда путь отстрелить себе ногу (например, в обоих родительских образах есть одинаковые каталоги-файлы по имени, но разные по содержимому). Лучше бы diff докачивался не послойно, а пофайлово. Ей-Богу.
Переоцениваете важность и нужность виртсетей. Зачастую лучше вообще избегать докер-сетей. Сложно. Вносят penalty при сетевом взаимодействии. И пр
Ресурсы — как правило не проблема. Понятно, что для статического сайтика, завернутого в докер, оверхед от ещё одной копии ОСи будет больше, но это разговоры из серии "вам шашечки или ехать" — может вообще не стоило пытаться самому разворачивать хостинг тогда, а взять готовое SaaS решение? Нужно инструмент выбирать под задачу, а не наоборот.
Касательно уплотнения ресурсов. Ну, да, докер поможет. Но обратная сторона — а как же стабильность? Не боитесь огрести от того, что ядро общее и некоторые ресурсы ядра не изолируются? В случае если говорим про кубернетИс, то давайте говорить про него, а не про докер. Тем более, что рантаймы в к8с меняются. И, да, он умеет управлять виртуалками тоже (!!!!)
По сборке для квм — смотрите в сторону hashicorp packer. Можно собирать готовые образа вм под облачные платформы и все основные гипервизоры.
Все правильно. В Амазон так и можно деплоиться.
Насчёт виртуалки — при запуске на другой архитектуре процессора могут быть нюансы. Могут быть нюансы при смене типа гипервизора. Но, в целом, да — за исключением вопроса производительности и драйверов, виртуалка переедет и запустится.
Перевод отличный, но интересно узнать ваше мнение. Собственное. Потому что многие вещи, описанные в статье… ну, спорные…
Например, live-restore. Отличный способ себе пострелять по ногам, когда радикально меняются настройки докер демона (я не проверял, но есть подозрение, что та же смена storage driver + liverestore все сломает).
Еще есть как минимум два сценария использования докера — на машине разработчика в режиме разработки и на тестовых/промышленных средах. А вот для последних рекомендации актуальны. Вряд ли кто-то будет бридж на машине разработчика спуфить )
Мой тоже. Но я сообразил, что коллеги так перевели "recorder" (лучше бы написали — "записывающий CD-привод", а ниже в комментах уже предложили "резак").
А еще упомянуть необходимость резервирования коммутаторов, ввода питания и пр… Все-таки экономия должна быть разумной, а не оголтелой.
даже более того — насколько я помню (я не очень хороший вэб-разраб), что при определенных условиях, если у нас есть приложения на поддоменах a.b.TLD и c.d.TLD, то они могут видеть свои куки и общие куки для домена b.TLD.
И там еще целая эпопея была, чтобы отличать двухкомпонентные TLD вроде co.uk от субдоменов.
Первая проблема она и для куков в общем-то имеет место быть… Не вижу в этой проблеме ничего уникального. Касательно токена… Ну… э… Не знаю.