Comments 18
Что-то концептуально схожее происходит с репозиторием git.
В docker можно модифицировать промежуточный слой, с применением всех изменений к дочерним?
В docker можно модифицировать промежуточный слой, с применением всех изменений к дочерним?
Действительно, создатели явно поглядывали в сторону git :) Есть даже команды docker pull/push. В тексте есть отсылка к ним — в месте про скачивание/отправку образов. К сожалению, на русском эта отсылка пропадает.
Что касается изменения промежуточных слоев, то встроенной возможности сделать это нет. Все нижние слои доступны только для чтения. Можно, наверное, поиграться с импортом и экспортом. Но, на мой взгляд, оно того просто не стоит — легче внести изменения «поверх» или пересобрать образ, изменив Dockerfile.
Что касается изменения промежуточных слоев, то встроенной возможности сделать это нет. Все нижние слои доступны только для чтения. Можно, наверное, поиграться с импортом и экспортом. Но, на мой взгляд, оно того просто не стоит — легче внести изменения «поверх» или пересобрать образ, изменив Dockerfile.
Слишком много текста до строчки «docker export 7423d238b | docker import — sample:flat». Надо было в начале статьи в спойлере спрятать. А потом уже рассказывать, чем это плохо, какие возможности есть…
У меня главный вопрос: так можно или нет выбрать набор слоев, чтобы сжать именно их?
У меня главный вопрос: так можно или нет выбрать набор слоев, чтобы сжать именно их?
Если вы имеете ввиду «взять готовый слой, сжать, поставить обратно» — то нет.
Нет. Сжать несколько слоев в один.
Допустим у меня есть контейнер с пятью слоями. Первый — база, а пятый — конкретный конфиг чего-то.
В бою будет много контейнеров на базе первого и четвертого слоев.
Внимание вопрос.
Я могу сказать, возьми со второго по четвертый и сожми? Он мне сделает новый контейнер со слоями: первый, сжатый, пятый? Можно с другими идентификаторами.
Допустим у меня есть контейнер с пятью слоями. Первый — база, а пятый — конкретный конфиг чего-то.
В бою будет много контейнеров на базе первого и четвертого слоев.
Внимание вопрос.
Я могу сказать, возьми со второго по четвертый и сожми? Он мне сделает новый контейнер со слоями: первый, сжатый, пятый? Можно с другими идентификаторами.
Каждый слой хранит лишь изменения относительно предыдущего. Поэтому нельзя взять какой-то слой, не хватая те, которые находятся «под» ним (со второго по четвертый, например). Однако, любой слой можно использовать для создания образа — либо просто запустив его с помощью
docker run и сделав коммит, либо «схлопнув» его, как описано в статье. Получившийся образ можно использовать так же, как и любой другой, в том числе и в качестве основы для других образов.Я поискал в интернете немного. Нашел еще несколько умных мыслей, которых я не увидел в статье, хотя им там самое место.
В статье есть замечательная мысль, которая вкратце звучит так:
— надо сделать некий setup.sh, прописать в нем все скачивания, установки, обновления и т.д.
— использовать только один вызов ADD и один RUN.
С докером работал мало (но было интересно), поэтому если кто меня поправит — буду рад.
PS. там же в статье я наткнулся на интересный инструмент. Просто оставлю это здесь. Вдруг кому пригодится.
В статье есть замечательная мысль, которая вкратце звучит так:
— надо сделать некий setup.sh, прописать в нем все скачивания, установки, обновления и т.д.
— использовать только один вызов ADD и один RUN.
С докером работал мало (но было интересно), поэтому если кто меня поправит — буду рад.
PS. там же в статье я наткнулся на интересный инструмент. Просто оставлю это здесь. Вдруг кому пригодится.
Если единственная цель setup-файла в том, чтобы установить нужные пакеты, то в нем нет особого смысла. Этого же можно добиться одной инструкцией RUN с группированными командами. Эффект будет тот же. Скрипт удобен для каких-то более сложных действий, где нужно проверять какие-либо условия, вроде значений переменных окружения, например.
Хм. Тогда есть ли разница между:
и
Думаю есть и большая. Собственно это из статьи и вытекает.
Так почему бы просто не ввести себе в привычку использовать setup.sh?
RUN apt-get updateRUN apt-get upgradeRUN apt-get cleanи
RUN apt-get update && apt-get upgrade && apt-get cleanДумаю есть и большая. Собственно это из статьи и вытекает.
Так почему бы просто не ввести себе в привычку использовать setup.sh?
Разница, конечно, будет. Главный минус использования стороннего скрипта для установки зависимостей в том, что это лишает вас возможности использовать кэш docker. В случае дополнения Dockerfile новой инструкцией, docker постарается взять предыдущие слои из кэша, что может значительно ускорить процесс создания нового образа. В случае же с setup.sh весь скрипт выполнится заново.
Ну, пример с «создали файл в 1 Гб, удалили файл в 1 Гб» — это, конечно, интересный эксперимент, а что вы такого делаете в настоящих контейнерах, что они до 1 Гб разрастаются с дебиановского образа в 85 Мб?
Если это вопрос ко мне, то я — не автор статьи. Я лишь перевел.
А насчет настоящих контейнеров: автор в начале говорит, что они по первой использовали
А насчет настоящих контейнеров: автор в начале говорит, что они по первой использовали
ubuntu, которая сама по себе весит около 200 Мб. Что они делали, чтобы собрать гигабайтный образ я не знаю :) Возможно, они не разбивали контейнеры по задачам, т.е. делали «толстые» контейнеры по принципу «все-в-одном»: ruby/python, nginx/apache, mysql/postgre и, бог знает, что еще. Я сначала тоже пользовался ubuntu:trusty, не группировал команды и не чистил кэш apt — получались довольно немаленькие образы.
Если честно, я не могу понять, почему размер контейнера это проблема? Если мы говорим о каком-то реальном deployment pipeline, то у нас будет какой-то Dockerfile примерного такого вида
так вот, все что до вызова ADD src/ будет меняться крайне редко, соответственно, при следующем деплое будет качаться только тот слой, который содержит исходики, а там выше хоть 2 гига, хоть 3, они меняются достаточно редко, поэтому никуда не качаются. Разве нет? Поясните, кто в теме?
FROM debian:wheezy
RUN apt-get install ...
ADD src/ src/
ENTRYPOINT binaryfile
так вот, все что до вызова ADD src/ будет меняться крайне редко, соответственно, при следующем деплое будет качаться только тот слой, который содержит исходики, а там выше хоть 2 гига, хоть 3, они меняются достаточно редко, поэтому никуда не качаются. Разве нет? Поясните, кто в теме?
Ну, это для некомпилируемых языков. Для компилируемых будет еще после ADD запуск компиляции, наверное, или что-то в этом роде.
Для меня больший размер означает меньшую мобильность. Это если говорить об образах, лежащих в репозиториях — как в публичных, так и приватных (у команды разработчиков может быть свой). В первую очередь, конечно, это проблема для публично доступных образов. Например, если зайти на страницу mysql, то можно увидеть жалобы пользователей на размер в 2-3 Гб (к счастью, сейчас его уменьшили до ~235 Мб). Т.е. тот, кто хотел тогда поднять у себя простой LAMP-стек был вынужден качать несколько гигабайт просто потому, что разработчики не позаботились о несложной оптимизации. Может также возникнуть ситуация, когда вы хотите передать другому человеку точную копию своего окружения: вы либо заставите его собирать все с нуля из Dockerfile-ов, либо передадите ему готовые образы, что при оптимальном размере может сэкономить кучу времени.
Спасибо за статью! Особо не углублялся в слои, н ов свое время потратил довольно много времени чтобы разобраться с контейнерами и образами чтобы разобраться почему образы так быстро распухают если их не контролировать. В итоге все же запилил для себя универсальный образ с нужным стеком ПО, а все конфиги вынес монтируемую директорию. Теперь в образ вообще ничего не коммичу.
Кстати, а вы пробовали запускать иксы в Docker? Пробовал образ с подключением по VNC и установленным Firefox. Больше ничего полезного по этой теме не нашел.
Кстати, а вы пробовали запускать иксы в Docker? Пробовал образ с подключением по VNC и установленным Firefox. Больше ничего полезного по этой теме не нашел.
Не пробовал запускать ничего подобного, но, натыкался на этот репозиторий: rogaha/docker-desktop. Возможно, он окажется полезен.
Sign up to leave a comment.
Оптимизация образов Docker