оукей

Примерно так я и сделал - у меня один из промежуточных слоев - сборка депенденсис и если они поменялись - ребилд будет дальше

😘

Блин, а что за смайл?

https://yopp.in/U9F

Зе сейм, слишком мелко :(

Ура, я разучил скилл "увеличение" в браузере :)

чего ?

Народ такой вопрос, есть файл в /var/lib/docker/devicemapper называется файл data, что в этом файле, а то он весит больше 10 гигов

не парься так и должно быть

и не надо удалять файл

просто я всё кручу верчу в вирутальной машине

там только images лежат по идее

и блин когда сумма образов ели ели перевалило за 6 гигов, а тут просто файл равен 10 гигам

внутри файла ? т.к. это именно файл а не директория

да да

это файл

но не файл

я постепенно задаюсь вопрос, а не ли в докере собственной какой-то чистки мусора

нет нету

вольюмы чистить руками

старые имиджи тоже

стоп

в файле дата ещё храняться данные volume ???

нет

я постепенно задаюсь вопрос, а не ли в докере собственной какой-то чистки мусора

docker image -a

вот вам немного докера, континиус интегрейшан и всей хуйни. поломалась документация у докера

https://docs.docker.com/swarm/reference/join/

а чо там поломалось?

у меня норм

скорее всего это cdn сломался

наверно

да, оно за cloudfront

Да все пашет. Это Росчтототам наверное заблочил опять

Слушайте, у меня близкий вопрос. А как тогда ребилдить модули для того же нпма или пипа, когда поменялись packages.json /requirements.txt ?

Типа если он из кеша берет слой.

Если меняется пакадж - все следующие слои будет ребилдится

Если ты пакадж копируешь (а как еще ты узнаешь что ставить?)

А если зависимости глубже и у тебя нет завязки на версию в пакадже (как у нас) - перед пакаджем еще копировать разрезолвенные зависимости как отдельный файл

Чет не въехал

То есть он проверяет и мд5 файликов которые мы копируем внутрь имиджа ? И если он поменялся, ниже билд пойдет ?

Не проверяет

Просто COPY всегда новый образ собирает

Тогда это бестолковая херь

А есть вариант ребилдить пекежжи тока в случае изменения файла ?

хотя не, чот я запутался

это ADD вроде новый образ делает. и то не всегда :)

Кто-то тут,мягко говоря,не прав

Да, сверяется хеш при каждом копировании

Не слушай диванных докероводов

Да, сверяется хеш при каждом копировании

да-да, всё так. я ошибся

Не слушай диванных докероводов

окай гай ) вобще этот вариант крутой. получается если они не менялись, мы в билд просто строчкой ниже положим новый код и все. нада замутить !

бинго!

А еще если много разных имаджей с похожей базой - между ними можно расшарить общий кеш и еще уменьшить время билда ;)

ах блядь

вот теперь я вспомнил почему у нас оно не работало :(

и почему не всё так просто с тем чтоб собрать все зависимости и почему мы их собираем предварительно :(

пичаль

кстати

если у нас COPY $PROJECT_NAME /var/www/$PROJECT_NAME

если $PROJECT_NAME поменялся, будет новый слой, так?

у нас просто 4 имаджа с такой конструкцией, в целом если для каждого имаджа такой слой будет кешироваться, то срать

кеш слоев все равно будет

короче, перефразирую. У меня сейчас есть COPY $PROJECT_NAME /var/www/$PROJECT_NAME. Если я сделаю COPY $PROJECT_NAME/foo /var/www/$PROJECT_NAME/foo COPY $PROJECT_NAME /var/www/$PROJECT_NAME оно первый copy закеширует?

пемеренные окружения они в твоем мире

потому что /foo меняется очень редко

а докер их видит уже разрезолвинными

ага, норм

а с двумя COPY?

каждый копи - отдельный слой

ну я вон там выше пример привёл

тоесть у меня папка с проектом в среднем весит 50 мегабайт

из них 45 мегабайт это зависимости

вынести их из папки это очень страшный геморой

вот если я сделаю сначала слой который копирует зависимости, а потом уже весь проект, я просто сделаю лишний слой с зависимостями?

в теории можно ещё один ADD добавить, в котором эту папочку выпиливать

и потом уже копировать

много статей было на предмет правильного с точки зрения потребления места инженеринга слоев.

и тут обсуждали тоже

почитай статьи вышедшие после 1,10